拓冰网站定制 
iii Worker Registry 完全指南浏览注册表、添加 Worker 与制品分发机制【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iiiiii 项目的 Worker Registry 是集中收录可安装 Worker 的官方索引本指南以docs/0-19-0/using-iii/workers-registry.mdx为主体结合iii-workerCLI 的源码实现系统讲解如何浏览注册表定位所需能力、通过iii worker add从三种来源安装 Worker 到config.yaml以及原生二进制与 Docker/OCI 镜像两种制品分发的底层原理。读完本文你将掌握 Worker 的发现、安装、版本管理与制品选择全流程并能读懂注册表解析与依赖图校验的源码细节。什么是 Worker RegistryWorker Registryworkers.iii.dev。注册表中的每个 Worker 页面都会列出以下元信息用于帮助你判断某个 Worker 是否满足项目需求提供的函数functionsWorker 注册的可调用函数清单提供的触发器类型trigger types例如http触发器由iii-httpWorker 提供添加后即可像 Express、FastAPI 一样暴露 HTTP 端点配置 schema该 Worker 的config.yaml配置块结构包括各字段的类型与含义支持的平台supported platforms例如 macOS、Linux、Windows 的哪些架构Agent skills随 Worker 分发的、面向 Agent 化工作负载的技能描述由skillsworker 管理顶层条目保持精简深层内容通过iii://worker/leafsection URI 按需懒加载。这些信息共同回答了项目需要某项能力时该装哪个 Worker、怎么配置它这一核心问题。除了 iii 官方注册表Worker 也可以在 Docker 以及任意 OCI 兼容的镜像仓库中找到见下文制品类型。添加 Workeriii worker add的三种来源iii worker add接受三种来源的输入无论哪种来源Worker 都会被写入项目根目录的config.yaml写入workers:列表并自动启动iii worker add iii-state # 从 iii 注册表下载并添加 Worker iii worker add ./workers/my_worker # 添加用 iii worker init 创建的本地 Worker iii worker add ghcr.io/org/worker:tag # 从 Docker 或 OCI 镜像仓库拉取并添加 Worker从 CLI 参数定义 可以看到该命令支持更细的用法参数说明WORKER[VERSION]注册表名称可带版本固定版本如iii-state1.2.0PATH本地 Worker 目录路径目录内需包含iii.worker.yamlimage:tagDocker / OCI 镜像引用如ghcr.io/org/worker:tag-f, --force强制重新下载删除已有制品后再添加--no-wait不阻塞等待引擎完成 Worker 启动默认最多等待 120 秒直到 Worker 上报 ready--reset-config丢弃config.yaml中已有的手工配置块按注册表默认重建-y, --yes当解析出的依赖图超过 32 个节点时跳过确认提示CI 等非交互环境必需三种来源的定位逻辑注册表名称如iii-state通过注册表解析服务按名称解析版本与制品 URL。若名称带版本后缀如pdfkit1.0.0则固定该版本不带则默认取最新版latest。注意iii worker add只从远程仓库或本地目录解析不读取本地 Docker daemon——本地用docker build构建的镜像无法按名称被识别如需测试应使用docker run直接运行。本地路径如./workers/my_worker目录内必须包含iii.worker.yaml清单属于本地开发中的 Worker。OCI 镜像引用如ghcr.io/org/worker:tag从任意 OCI 兼容仓库拉取镜像在微虚拟机microVM中运行。Worker 添加后由引擎的文件监听器接管Worker 通过 WebSocket 连接到引擎后其函数与触发器对整个系统及所有其它 Worker 可见断开连接则函数与触发器停止可调用直到重新连接。config.yaml 的自动写入从 config_file.rs 的实现可见iii worker add对config.yaml的修改是保格式、保注释的它逐行定位workers:列表的结尾把新条目以- name: name形式追加并视来源写入image:OCI 来源或worker_path:本地路径来源字段注册表返回的默认配置则缩进后写入config:子键。若同名 Worker 已存在CLI 会先提取旧的config:块、删除旧条目再做深度合并merge_yaml_configs/deep_merge注册表默认值作为基底用户已有的配置值覆盖其上从而保留手工修改。配置文件路径解析遵循III_CONFIG_PATH环境变量优先引擎启动每个进程时都会注入该变量确保指向引擎实际使用的配置文件否则回退到当前目录的config.yaml。制品类型原生二进制与 OCI 镜像注册表中的每个 Worker 都以两种制品形式之一发布制品类型分发方式覆盖范围原生二进制native binary每个 Worker 提供分平台的制品包括 macOS、Linux、Windows各平台各自下载对应架构的二进制Docker / OCI 兼容镜像单一镜像在所有受支持的平台上运行二进制 Worker 的一次发布可覆盖所有受支持主机同一注册表条目下可同时发布 macOS arm64/x64、Linux arm64/x64/armv7、Windows arm64/x64/x86 等平台目标无需按平台分别发布。从 registry.rs 的响应结构 可以看到二进制制品的注册表响应以binaries映射按目标三元组如aarch64-apple-darwin、x86_64-unknown-linux-gnu给出各自的下载 URL 与SHA-256 校验和安装时按当前主机目标选择对应制品。第三种制品Bundle 归档除了binary与image注册表还支持bundle制品详见 创建 Worker 的 Registry 文档注册表提供一个tar.gz归档内含 Worker 打包源码与归档根目录的iii.worker.yaml清单。iii worker add name下载后校验 SHA-256、解压到~/.iii/workers-bundle/name/再经由与本地路径 Worker 相同的 libkrun 沙箱路径运行但不启用宿主侧源码监听。bundle 适合分发 esbuild/tsdown/bun build 预构建的 JS 产物或打包的 Python Worker产物以 KB 计量而非 MB且对用户来说安装方式与 binary、OCI 完全一致。源码透视注册表解析与依赖图校验理解了使用方式后再看iii-workerCLI 如何把一个名字变成一台运行中的 Worker。解析入口与 API 契约registry.rs 中fetch_worker_info是注册表解析的入口解析前先做名称合法性校验validate_worker_name只允许字母数字、短横线、下划线、点禁止空名、禁止包含..防路径穿越、禁止以.开头保留.locks/.staging作为安装根目录内部控制目录同时拒绝换行等 YAML 注入字符测试用例 覆盖了这些攻击面。默认请求https://api.workers.iii.dev/download/{name}可用III_API_URL环境变量覆盖debug 构建下支持file://本地 fixture 便于测试携带version查询参数检测到 CI 环境变量CI、GITHUB_ACTIONS、GITLAB_CI、CIRCLECI、JENKINS_URL、TRAVIS、BUILDKITE、TF_BUILD、CODEBUILD_BUILD_ID、BITBUCKET_BUILD_NUMBER、DRONE、TEAMCITY_VERSION任一存在时额外追加citrue相关单测 验证了该行为。响应体经 serde 按type标签反序列化为binary/image/engine/bundle四种变体WorkerInfoResponseengine 类 Worker 返回 204 无制品体仅含元数据。内存安全边界MAX_REGISTRY_RESPONSE_BYTES 1 MiBContent-Length预检与流式累积双重校验防止不可信注册表在解析前分配无界内存read_registry_response。依赖解析与图校验Worker 可以声明依赖其它 Worker注册表的/resolve端点返回解析后的依赖图ResolvedWorkerGraphroot、graph 节点、edges 边每条边带 semver 范围如{from: hello-worker, to: helper, range: ^1.0.0}。安装前 validate_dependency_graph 对图做结构校验节点唯一不允许重复的 Worker 节点边引用合法每条边的端点必须是被声明的节点可达性所有节点必须能从请求的 root 到达拒绝游离载荷节点被静默安装无环用 Kahn 算法做显式环检测遍历为迭代式长依赖链不消耗调用栈。旧的硬性深度 5 / 节点数 32上限被替换为更合理的策略节点数仍是好的 UX 信号——超过LARGE_DEPENDENCY_GRAPH_THRESHOLD 32时需要操作者显式确认-y跳过但真正的资源边界由二进制与 bundle 的下载/解压字节上限保证。安装后的运行模型安装完成后Worker 制品按类型落盘二进制 Worker 位于~/.iii/workers/{name}bundle 位于~/.iii/workers-bundle/{name}/以iii.worker.yaml存在与否判定是否已安装避免空目录误判见 config_file.rs类型解析优先级为本地路径worker_path: OCI 镜像image: bundle 二进制 纯配置。iii worker add默认最多等待 120 秒让 Worker 上报 ready超时后命令返回 shellWorker 继续启动可用iii worker status/iii worker logs继续观察。版本固定、iii.lock与相关命令注册表 Worker 遵循 semver 语义化版本。安装时不指定版本则取最新发布用version后缀固定版本iii worker add iii-state1.2.0解析出的确切版本会写入项目根目录的iii.lockYAML 格式二进制 Worker 可在同一 lockfile 中固定分平台制品macOS、Linux、Windows。提交iii.lock与config.yaml可保证跨机器、跨平台的可复现安装。围绕 lockfile 与 Worker 生命周期还有一组配套命令详见 Workers 文档iii worker list # 列出 config.yaml 中声明的所有 Worker 及状态 iii worker start name # 启动一个 Worker iii worker stop -y name # 停止一个 Worker-y 跳过确认 iii worker restart name # 停止再启动 iii worker status name # 查看配置、沙箱状态与最近日志 iii worker logs name # 流式查看日志 iii worker exec name -- cmd # 在 Worker 沙箱内执行命令 iii worker reinstall name # 等价于 add --force强制重新下载 iii worker update [name] # 将 iii.lock 中的 pin 重新解析到最新允许版本 iii worker remove -y name # 从 config.yaml 移除并关闭运行进程 iii worker clear -y [name] # 同时删除 ~/.iii/ 下的下载制品 iii worker sync [--frozen] # 严格按 iii.lock 安装--frozen 为 CI 校验形态 iii worker verify # 报告 config.yaml 与 iii.lock 之间的漂移小结iii Worker Registry 是 Worker 生态的入口在 workers.iii.dev 中严格的名称校验、1 MiB 响应上限与无环依赖图校验保证安装既灵活又可审计。若需深入了解 Worker 的启动、停止、同步与移除等完整子命令集可继续阅读 Workers 文档若要了解如何创建并发布自己的 Worker 到注册表包括 bundle 制品的归档布局与清单契约可参考 创建 Worker 的 Registry 文档。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 iii Worker Registry 完全指南：浏览注册表、添加 Worker 与制品分发机制
iii Worker Registry 完全指南浏览注册表、添加 Worker 与制品分发机制【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iiiiii 项目的 Worker Registry 是集中收录可安装 Worker 的官方索引本指南以docs/0-19-0/using-iii/workers-registry.mdx为主体结合iii-workerCLI 的源码实现系统讲解如何浏览注册表定位所需能力、通过iii worker add从三种来源安装 Worker 到config.yaml以及原生二进制与 Docker/OCI 镜像两种制品分发的底层原理。读完本文你将掌握 Worker 的发现、安装、版本管理与制品选择全流程并能读懂注册表解析与依赖图校验的源码细节。什么是 Worker RegistryWorker Registryworkers.iii.dev。注册表中的每个 Worker 页面都会列出以下元信息用于帮助你判断某个 Worker 是否满足项目需求提供的函数functionsWorker 注册的可调用函数清单提供的触发器类型trigger types例如http触发器由iii-httpWorker 提供添加后即可像 Express、FastAPI 一样暴露 HTTP 端点配置 schema该 Worker 的config.yaml配置块结构包括各字段的类型与含义支持的平台supported platforms例如 macOS、Linux、Windows 的哪些架构Agent skills随 Worker 分发的、面向 Agent 化工作负载的技能描述由skillsworker 管理顶层条目保持精简深层内容通过iii://worker/leafsection URI 按需懒加载。这些信息共同回答了项目需要某项能力时该装哪个 Worker、怎么配置它这一核心问题。除了 iii 官方注册表Worker 也可以在 Docker 以及任意 OCI 兼容的镜像仓库中找到见下文制品类型。添加 Workeriii worker add的三种来源iii worker add接受三种来源的输入无论哪种来源Worker 都会被写入项目根目录的config.yaml写入workers:列表并自动启动iii worker add iii-state # 从 iii 注册表下载并添加 Worker iii worker add ./workers/my_worker # 添加用 iii worker init 创建的本地 Worker iii worker add ghcr.io/org/worker:tag # 从 Docker 或 OCI 镜像仓库拉取并添加 Worker从 CLI 参数定义 可以看到该命令支持更细的用法参数说明WORKER[VERSION]注册表名称可带版本固定版本如iii-state1.2.0PATH本地 Worker 目录路径目录内需包含iii.worker.yamlimage:tagDocker / OCI 镜像引用如ghcr.io/org/worker:tag-f, --force强制重新下载删除已有制品后再添加--no-wait不阻塞等待引擎完成 Worker 启动默认最多等待 120 秒直到 Worker 上报 ready--reset-config丢弃config.yaml中已有的手工配置块按注册表默认重建-y, --yes当解析出的依赖图超过 32 个节点时跳过确认提示CI 等非交互环境必需三种来源的定位逻辑注册表名称如iii-state通过注册表解析服务按名称解析版本与制品 URL。若名称带版本后缀如pdfkit1.0.0则固定该版本不带则默认取最新版latest。注意iii worker add只从远程仓库或本地目录解析不读取本地 Docker daemon——本地用docker build构建的镜像无法按名称被识别如需测试应使用docker run直接运行。本地路径如./workers/my_worker目录内必须包含iii.worker.yaml清单属于本地开发中的 Worker。OCI 镜像引用如ghcr.io/org/worker:tag从任意 OCI 兼容仓库拉取镜像在微虚拟机microVM中运行。Worker 添加后由引擎的文件监听器接管Worker 通过 WebSocket 连接到引擎后其函数与触发器对整个系统及所有其它 Worker 可见断开连接则函数与触发器停止可调用直到重新连接。config.yaml 的自动写入从 config_file.rs 的实现可见iii worker add对config.yaml的修改是保格式、保注释的它逐行定位workers:列表的结尾把新条目以- name: name形式追加并视来源写入image:OCI 来源或worker_path:本地路径来源字段注册表返回的默认配置则缩进后写入config:子键。若同名 Worker 已存在CLI 会先提取旧的config:块、删除旧条目再做深度合并merge_yaml_configs/deep_merge注册表默认值作为基底用户已有的配置值覆盖其上从而保留手工修改。配置文件路径解析遵循III_CONFIG_PATH环境变量优先引擎启动每个进程时都会注入该变量确保指向引擎实际使用的配置文件否则回退到当前目录的config.yaml。制品类型原生二进制与 OCI 镜像注册表中的每个 Worker 都以两种制品形式之一发布制品类型分发方式覆盖范围原生二进制native binary每个 Worker 提供分平台的制品包括 macOS、Linux、Windows各平台各自下载对应架构的二进制Docker / OCI 兼容镜像单一镜像在所有受支持的平台上运行二进制 Worker 的一次发布可覆盖所有受支持主机同一注册表条目下可同时发布 macOS arm64/x64、Linux arm64/x64/armv7、Windows arm64/x64/x86 等平台目标无需按平台分别发布。从 registry.rs 的响应结构 可以看到二进制制品的注册表响应以binaries映射按目标三元组如aarch64-apple-darwin、x86_64-unknown-linux-gnu给出各自的下载 URL 与SHA-256 校验和安装时按当前主机目标选择对应制品。第三种制品Bundle 归档除了binary与image注册表还支持bundle制品详见 创建 Worker 的 Registry 文档注册表提供一个tar.gz归档内含 Worker 打包源码与归档根目录的iii.worker.yaml清单。iii worker add name下载后校验 SHA-256、解压到~/.iii/workers-bundle/name/再经由与本地路径 Worker 相同的 libkrun 沙箱路径运行但不启用宿主侧源码监听。bundle 适合分发 esbuild/tsdown/bun build 预构建的 JS 产物或打包的 Python Worker产物以 KB 计量而非 MB且对用户来说安装方式与 binary、OCI 完全一致。源码透视注册表解析与依赖图校验理解了使用方式后再看iii-workerCLI 如何把一个名字变成一台运行中的 Worker。解析入口与 API 契约registry.rs 中fetch_worker_info是注册表解析的入口解析前先做名称合法性校验validate_worker_name只允许字母数字、短横线、下划线、点禁止空名、禁止包含..防路径穿越、禁止以.开头保留.locks/.staging作为安装根目录内部控制目录同时拒绝换行等 YAML 注入字符测试用例 覆盖了这些攻击面。默认请求https://api.workers.iii.dev/download/{name}可用III_API_URL环境变量覆盖debug 构建下支持file://本地 fixture 便于测试携带version查询参数检测到 CI 环境变量CI、GITHUB_ACTIONS、GITLAB_CI、CIRCLECI、JENKINS_URL、TRAVIS、BUILDKITE、TF_BUILD、CODEBUILD_BUILD_ID、BITBUCKET_BUILD_NUMBER、DRONE、TEAMCITY_VERSION任一存在时额外追加citrue相关单测 验证了该行为。响应体经 serde 按type标签反序列化为binary/image/engine/bundle四种变体WorkerInfoResponseengine 类 Worker 返回 204 无制品体仅含元数据。内存安全边界MAX_REGISTRY_RESPONSE_BYTES 1 MiBContent-Length预检与流式累积双重校验防止不可信注册表在解析前分配无界内存read_registry_response。依赖解析与图校验Worker 可以声明依赖其它 Worker注册表的/resolve端点返回解析后的依赖图ResolvedWorkerGraphroot、graph 节点、edges 边每条边带 semver 范围如{from: hello-worker, to: helper, range: ^1.0.0}。安装前 validate_dependency_graph 对图做结构校验节点唯一不允许重复的 Worker 节点边引用合法每条边的端点必须是被声明的节点可达性所有节点必须能从请求的 root 到达拒绝游离载荷节点被静默安装无环用 Kahn 算法做显式环检测遍历为迭代式长依赖链不消耗调用栈。旧的硬性深度 5 / 节点数 32上限被替换为更合理的策略节点数仍是好的 UX 信号——超过LARGE_DEPENDENCY_GRAPH_THRESHOLD 32时需要操作者显式确认-y跳过但真正的资源边界由二进制与 bundle 的下载/解压字节上限保证。安装后的运行模型安装完成后Worker 制品按类型落盘二进制 Worker 位于~/.iii/workers/{name}bundle 位于~/.iii/workers-bundle/{name}/以iii.worker.yaml存在与否判定是否已安装避免空目录误判见 config_file.rs类型解析优先级为本地路径worker_path: OCI 镜像image: bundle 二进制 纯配置。iii worker add默认最多等待 120 秒让 Worker 上报 ready超时后命令返回 shellWorker 继续启动可用iii worker status/iii worker logs继续观察。版本固定、iii.lock与相关命令注册表 Worker 遵循 semver 语义化版本。安装时不指定版本则取最新发布用version后缀固定版本iii worker add iii-state1.2.0解析出的确切版本会写入项目根目录的iii.lockYAML 格式二进制 Worker 可在同一 lockfile 中固定分平台制品macOS、Linux、Windows。提交iii.lock与config.yaml可保证跨机器、跨平台的可复现安装。围绕 lockfile 与 Worker 生命周期还有一组配套命令详见 Workers 文档iii worker list # 列出 config.yaml 中声明的所有 Worker 及状态 iii worker start name # 启动一个 Worker iii worker stop -y name # 停止一个 Worker-y 跳过确认 iii worker restart name # 停止再启动 iii worker status name # 查看配置、沙箱状态与最近日志 iii worker logs name # 流式查看日志 iii worker exec name -- cmd # 在 Worker 沙箱内执行命令 iii worker reinstall name # 等价于 add --force强制重新下载 iii worker update [name] # 将 iii.lock 中的 pin 重新解析到最新允许版本 iii worker remove -y name # 从 config.yaml 移除并关闭运行进程 iii worker clear -y [name] # 同时删除 ~/.iii/ 下的下载制品 iii worker sync [--frozen] # 严格按 iii.lock 安装--frozen 为 CI 校验形态 iii worker verify # 报告 config.yaml 与 iii.lock 之间的漂移小结iii Worker Registry 是 Worker 生态的入口在 workers.iii.dev 中严格的名称校验、1 MiB 响应上限与无环依赖图校验保证安装既灵活又可审计。若需深入了解 Worker 的启动、停止、同步与移除等完整子命令集可继续阅读 Workers 文档若要了解如何创建并发布自己的 Worker 到注册表包括 bundle 制品的归档布局与清单契约可参考 创建 Worker 的 Registry 文档。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考