iii Worker 全生命周期管理从 Worker 生命周期、RBAC 访问控制到版本锁定的实战指南【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii本指南围绕 iii 项目的 WorkerWorker机制展开Worker 是通过 WebSocket 连接 iii 引擎、注册函数functions与触发器类型trigger types的进程是 iii 系统中一切可调用能力的载体。你将掌握 Worker 的完整生命周期管理——如何从 Worker Registry 添加、列出、启停、检查、更新与移除 Worker如何通过iii-worker-manager的 RBAC 监听器让不受信任的客户端安全接入以及如何借助语义化版本锁定与iii.lock锁文件实现跨机器、跨平台的可复现安装。本文以 docs/using-iii/workers.mdx.skill.md 为核心骨架并结合仓库源码crates/iii-compose、engine/src/workers/worker验证底层实现。Worker 生命周期连接即注册断开即失效在 iii 中Worker 通过WebSocket连接引擎。一个 Worker 一旦连上引擎就会立刻对整个 iii 系统以及系统内的其他 Worker可见一旦断开连接它所注册的函数与触发器便停止可被调用直到重新连接为止。这是 iii 一切能力的基础模型可用性即在线性没有常驻的离线注册表在断线后继续提供服务。从 Worker 代码侧建立连接的 SDK 调用方式属于创建 Worker 的范畴详见 docs/creating-workers/workers.mdxregisterWorker()等调用。对于当前主题只需要明确任何使用 iii SDK、调用registerWorker()并连接到一个 iii 实例的进程都是一个 Worker——即使它不是由 iii 的内置虚拟化运行。不受信任的 Worker 与访问控制RBAC默认的引擎监听器信任一切连接到它的对象这对自己运行的 Worker 是合适的。但一个不受你控制的 Worker例如浏览器客户端、第三方 Worker绝不能获得同样的无限制访问权。对于这类连接应当让它们通过iii-worker-managerWorker 接入它暴露了一个独立的基于角色的访问控制RBAC监听器iii worker add iii-worker-managerRBAC 监听器会对每一次连接运行一个你编写的 auth 函数用来准入或拒绝该连接并决定这个连接可以使用哪些函数与触发器类型。因此不受信任的 Worker 永远只能看到你授予它的那一小部分表面。配置、auth 与中间件函数签名以及完整的连接流程记录在iii-worker-managerWorker 页面。从源码看RBAC 监听器的实现位于 engine/src/workers/worker/rbac_config.rs 与 engine/src/workers/worker/rbac_session.rs。其核心数据结构RbacConfig包含字段作用auth_function_id每次 WebSocket 升级时调用一次的鉴权函数 ID接收AuthInput返回AuthResult未设置时所有连接都被放行仅靠expose_functions把关expose_functions函数过滤器列表任意一个过滤器命中即视为暴露空列表意味着除基础设施豁免外不暴露任何函数on_function_registration_function_id每次registerFunction前调用的钩子返回映射后的字段或抛错拒绝on_trigger_registration_function_id每次registerTrigger前调用的钩子on_trigger_type_registration_function_id每次registerTriggerType前调用的钩子expose_functions过滤器支持通配符与元数据两种形态例如match(api::*)、match(*::public)或带metadata的键值匹配并且可以按 namespace 作用域无 namespace 的规则只匹配defaultnamespace。rbac_session.rs中的鉴权流程则展示了完整的判定链路is_function_allowed禁止列表forbidden全局生效且优先级最高其次是会话授予的命名空间范围授权再其次是allowed_functions仅作用于defaultnamespace随后是INFRASTRUCTURE_FUNCTIONS基础设施豁免如engine::channels::create、engine::log::*、engine::baggage::*最后才落到expose_functions过滤器默认拒绝。从源码结构看这一拒绝优先、默认拒绝的设计使每个租户的授权边界可被清晰推理。iii-worker-manager的配置示例来自 engine/src/workers/worker/README.md展示了典型的生产形态——一个内部监听器供可信 Worker 使用一个公共 RBAC 监听器供不受信任客户端使用engine: workers: # 主引擎端口——内部 Worker 间流量 iii-worker-manager: port: 49134 # 公共 RBAC 监听器——鉴权、中间件与受控注册 iii-worker-manager#rbac: host: 0.0.0.0 port: 49135 middleware_function_id: my-project::middleware-function rbac: auth_function_id: my-project::auth-function on_function_registration_function_id: my-project::on-function-reg on_trigger_registration_function_id: my-project::on-trigger-reg on_trigger_type_registration_function_id: my-project::on-trigger-type-reg expose_functions: - match(api::*) - match(*::public) - metadata: public: true要点第一个iii-worker-manager条目决定主引擎端口默认49134#instance条目会启动独立的监听器各自拥有独立的端口、host、中间件与 RBAC 配置。middleware_function_id一旦设置该监听器上的每次调用都会先交给中间件由中间件决定是否通过iii.trigger调用目标函数以及返回什么可独立于 RBAC 使用。管理 Workeriii worker命令全生命周期iii workerCLI 命令覆盖项目中每个 Worker 的完整生命周期在注册表中查找新的 Worker、安装进config.yaml与iii.lock、控制运行状态、查看日志以及不再需要时将其移除。查找 Workeriii 维护着一个 Worker Registry可以在 workers.iii.dev 上浏览。注册表包含大量封装了常见服务的 Worker如state、queue、http、pdfkit等。关于 Worker Registry 的更多信息参见 docs/using-iii/workers-registry.mdx.skill.md每个 Worker 页面都会列出它提供的函数与触发器类型、配置模式、支持平台与 Agent 技能skills用来判断哪个 Worker 能满足你项目的能力缺口。除了 iii 注册表Worker 也可以在 Docker 与 OCI 兼容镜像仓库中找到。添加 Worker在添加 Worker 之前你需要先安装 iii 并运行引擎。想临时起一个 iii 实例做测试可以在一个空目录里运行iii当目录里还没有config.yaml时它会自动创建一个带空 Worker 列表的配置随时可以执行iii worker add参见默认配置。Worker 可以从三种来源添加到你的 iii 实例iii Worker RegistryDocker 或 OCI 兼容镜像仓库本地开发的 Worker创建方式见 docs/creating-workers/workers.mdx。iii worker add state # 从 iii registry 下载并添加 Worker iii worker add ./workers/my_worker # 添加用 iii worker init 创建的本地 Worker iii worker add ghcr.io/org/worker:tag # 从 Docker 或 OCI 镜像仓库拉取并添加Worker 会被写进config.yaml并自动启动。对已存在的 Worker 强制重新下载使用iii worker reinstall name等价于add --force。注册表安装会校验完整的依赖图且没有任意深度限制。如果解析出的图包含超过32 个 Workeriii 会在安装前要求确认。在 CI 等非交互环境中先在本地审阅依赖图后再使用iii worker add --yes name或iii worker reinstall --yes name。iii worker add写入的是一个不带config:块的裸- name:条目。Worker 以内置默认值启动运行时设置通过配置 Worker管理其条目可作为本地文件编辑于./config/下。如果你在config.yaml中手工写入config:块它仍然作为首次启动的一次性种子生效且重新添加 Worker 会保留该块唯一的例外是iii-sandbox它的add会写入 sandbox 的config:块因为镜像白名单必须从文件强制读取。默认情况下iii worker add编辑当前目录下的配置文件所以要在与引擎相同的目录中运行。若要安装到运行在别处的引擎不同目录、不同机器或非默认端口传入--hostiii worker add pdfkit --host localhost:49134使用--host时CLI 调用引擎的worker::add触发器由引擎在它自己的项目目录中应用安装你当前目录的任何内容都不会被改动。如果在没有配置文件no config file的目录中运行iii worker add它不会在那里创建配置命令会回退到--host localhost通过你机器上运行的引擎完成安装并打印一条说明提示。只有已持有配置文件的目录或显式传入--host才决定安装落点。一个重要的边界iii worker add从远程仓库iii registry 或 OCI registry或本地文件夹下载 Worker 镜像然后在microVM中运行它们。裸引用如caller-worker:latest只在那些远程仓库中查找iii不会从你本地 Docker daemon 读取镜像所以用docker build在本地构建的镜像不会按名称被找到。本地构建的 Docker 镜像可以像其他 Docker 镜像一样运行和测试docker run -it caller-worker:latest。从实现层面看crates/iii-compose/src/edit.rs中parse_worker的解析逻辑与上述行为完全一致以.或/开头的是本地路径Source::Path其余一律视为注册表引用Source::Package裸名称会解析为默认注册表主机api.workers.iii.dev/name源码中的DEFAULT_REGISTRY_HOST常量并支持nameversion的版本规格从右侧拆分因此带 scope 的名称可保留自己的。安装时resolve_graphcrates/iii-compose/src/registry.rs会一次性向注册表的/resolve端点请求整张依赖图——所有依赖已经以互相满足的版本被钉死而非逐个依赖解析逐次请求既慢又可能解析出不同的集合。写入containers:映射时采用文本拼接而非 serde 往返序列化从而完整保留文件中的注释、空行与引用风格参见edit.rs顶部模块注释新条目标记为# added by compose::add。锁定 Worker 版本Version Pins注册表 Worker 以semver发布。安装时不带版本说明符会挑选最新版本给注册表名称追加version可以钉住某个具体版本而不是追踪最新版iii worker add state1.2.0该钉住版本会记录在iii.lock中并在后续每次安装时重放。版本的选择、version钉住、更新以及iii.lock的记录方式详见版本管理一节。列出 Workeriii worker list显示项目config.yaml中声明的每个 Worker 及其当前状态用于查看运行中和已停止的 Worker 列表iii worker list启动与停止 Worker添加的 Worker 会随引擎自动启动。需要手动控制时使用start、stop与restart命令iii worker start name # 启动单个 Worker iii worker stop -y name # 停止单个 Worker-y 跳过确认提示 iii worker restart name # 先停止再启动需要再次强调这些命令管理的是由 iii 在内置虚拟化中为你运行的 Worker。但 iii并非必须运行一个 Worker——任何使用 iii SDK、调用registerWorker()并连接到一个 iii 实例的进程都是 Worker。这一点在创建 Worker或部署 iii 系统时会更相关。检查 Worker检查某个具体 Worker 的状态、跟踪其日志或在 Worker 的沙箱内执行命令iii worker status name # 配置、沙箱状态、最近日志 iii worker logs name # 流式输出 Worker 的日志 iii worker exec name -- command # 在 Worker 内部运行命令更新 Workeriii worker update重新解析被锁定的 Worker并将新钉住版本写回iii.lock。传入 Worker 名称则更新单个省略则更新所有被锁定的 Workeriii worker update worker-name # 更新单个 Worker iii worker update # 更新所有被锁定的 Worker移除 Workeriii worker remove将 Worker 从config.yaml中移除引擎同时拆除正在运行的 Worker 进程iii worker remove -y worker-name # -y 在 Worker 正在运行时跳过确认下载的产物在移除后会留在磁盘上。要一并删除它们使用iii worker clear -y worker-name省略名称则清空所有 Worker 的产物。Worker 技能Skills每个 Worker 还会附带用于Agentic 工作的技能skills。技能由skillsWorker 管理——它是一个正在积极开发的内容注册表型 Worker像其他任何 Worker 一样添加到项目中。技能体是懒加载的顶层条目保持精简Agent 仅在某个函数引用解析到某个iii://worker/leaf章节 URI 时才会通过该 URI 获取更深层的内容。iii 还提供高层级技能让任何 Agent 都能立即使用 iii 及其 Worker。可用的函数与触发器函数与触发器来自已连接的 Worker。要使用某个类型的触发器提供它的 Worker 必须处于连接状态。例如通过 http Worker 添加http触发器之后你就可以像在 Express 或 FastAPI 这类 Web 框架中一样为你的函数暴露端点。函数与触发器的调用方式直接用worker.trigger/iii trigger或通过可选条件门控绑定到事件上参见 docs/using-iii/triggers.mdx.skill.md。版本管理Versioningiii Worker 遵循semver。项目会把每个受管 Worker 的已解析版本记录在iii.lock中使安装在机器与平台之间可复现。版本钉住见上文锁定 Worker 版本不指定版本安装会选最新版iii worker add state1.2.0可钉住具体版本。锁文件iii.lockiii.lock是位于项目根目录的YAML 文件。它把每个受管 Worker 钉到具体的版本与来源使同一组 Worker 在不同机器与平台上以相同方式安装。二进制 Worker可以在同一个锁文件中为不同平台macOS、Linux、Windows钉住各自的产物。将iii.lock与config.yaml一起提交即可获得可复现的安装。两个命令直接操作锁文件iii worker sync # 严格按 iii.lock 安装 Worker iii worker sync --frozen # CI 形态校验锁文件而不改动本地文件 iii worker verify # 报告 config.yaml 与 iii.lock 之间的漂移iii worker update是第三个与锁文件相关的命令它把钉住版本重新解析为最新允许的版本并写回iii.lock。从源码看注册表在解析时返回的版本本身就是钉死的latest_versioncrates/iii-compose/src/registry.rs会把*解析出的具体版本交给compose::add写死而不是写一个会漂移的版本区间。每次安装时基于缓存摘要sha256校验产物二进制产物按{name}-{version}-{target}-{digest}目录缓存命中则返回Cached避免重复下载。编写 Worker创建新 Worker、在 Worker 代码中注册函数与触发器以及构建或发布 Worker 镜像不在本文范围内参见 docs/creating-workers/workers.mdx。小结Worker 的生命周期与连接强绑定连接即对整个系统可见断开即不可调用。默认引擎监听器只适用于自控 Worker不受信任的客户端应接入iii-worker-manager的 RBAC 监听器通过 auth 函数、expose_functions过滤器与注册钩子实现默认拒绝的细粒度访问控制。iii worker add支持注册表、OCI 镜像仓库与本地三种来源安装进config.yaml并自动启动超过 32 个节点的依赖图会要求确认不读本地 Docker daemon 的镜像。iii worker list/status/logs/exec/start/stop/restart/update/remove/clear/sync/verify覆盖 Worker 的完整运维闭环。iii.lock是跨机器可复现安装的关键sync --frozen用于 CIverify报告漂移update重新解析并写回新钉住版本。【免费下载链接】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 全生命周期管理：从 Worker 生命周期、RBAC 访问控制到版本锁定的实战指南
iii Worker 全生命周期管理从 Worker 生命周期、RBAC 访问控制到版本锁定的实战指南【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii本指南围绕 iii 项目的 WorkerWorker机制展开Worker 是通过 WebSocket 连接 iii 引擎、注册函数functions与触发器类型trigger types的进程是 iii 系统中一切可调用能力的载体。你将掌握 Worker 的完整生命周期管理——如何从 Worker Registry 添加、列出、启停、检查、更新与移除 Worker如何通过iii-worker-manager的 RBAC 监听器让不受信任的客户端安全接入以及如何借助语义化版本锁定与iii.lock锁文件实现跨机器、跨平台的可复现安装。本文以 docs/using-iii/workers.mdx.skill.md 为核心骨架并结合仓库源码crates/iii-compose、engine/src/workers/worker验证底层实现。Worker 生命周期连接即注册断开即失效在 iii 中Worker 通过WebSocket连接引擎。一个 Worker 一旦连上引擎就会立刻对整个 iii 系统以及系统内的其他 Worker可见一旦断开连接它所注册的函数与触发器便停止可被调用直到重新连接为止。这是 iii 一切能力的基础模型可用性即在线性没有常驻的离线注册表在断线后继续提供服务。从 Worker 代码侧建立连接的 SDK 调用方式属于创建 Worker 的范畴详见 docs/creating-workers/workers.mdxregisterWorker()等调用。对于当前主题只需要明确任何使用 iii SDK、调用registerWorker()并连接到一个 iii 实例的进程都是一个 Worker——即使它不是由 iii 的内置虚拟化运行。不受信任的 Worker 与访问控制RBAC默认的引擎监听器信任一切连接到它的对象这对自己运行的 Worker 是合适的。但一个不受你控制的 Worker例如浏览器客户端、第三方 Worker绝不能获得同样的无限制访问权。对于这类连接应当让它们通过iii-worker-managerWorker 接入它暴露了一个独立的基于角色的访问控制RBAC监听器iii worker add iii-worker-managerRBAC 监听器会对每一次连接运行一个你编写的 auth 函数用来准入或拒绝该连接并决定这个连接可以使用哪些函数与触发器类型。因此不受信任的 Worker 永远只能看到你授予它的那一小部分表面。配置、auth 与中间件函数签名以及完整的连接流程记录在iii-worker-managerWorker 页面。从源码看RBAC 监听器的实现位于 engine/src/workers/worker/rbac_config.rs 与 engine/src/workers/worker/rbac_session.rs。其核心数据结构RbacConfig包含字段作用auth_function_id每次 WebSocket 升级时调用一次的鉴权函数 ID接收AuthInput返回AuthResult未设置时所有连接都被放行仅靠expose_functions把关expose_functions函数过滤器列表任意一个过滤器命中即视为暴露空列表意味着除基础设施豁免外不暴露任何函数on_function_registration_function_id每次registerFunction前调用的钩子返回映射后的字段或抛错拒绝on_trigger_registration_function_id每次registerTrigger前调用的钩子on_trigger_type_registration_function_id每次registerTriggerType前调用的钩子expose_functions过滤器支持通配符与元数据两种形态例如match(api::*)、match(*::public)或带metadata的键值匹配并且可以按 namespace 作用域无 namespace 的规则只匹配defaultnamespace。rbac_session.rs中的鉴权流程则展示了完整的判定链路is_function_allowed禁止列表forbidden全局生效且优先级最高其次是会话授予的命名空间范围授权再其次是allowed_functions仅作用于defaultnamespace随后是INFRASTRUCTURE_FUNCTIONS基础设施豁免如engine::channels::create、engine::log::*、engine::baggage::*最后才落到expose_functions过滤器默认拒绝。从源码结构看这一拒绝优先、默认拒绝的设计使每个租户的授权边界可被清晰推理。iii-worker-manager的配置示例来自 engine/src/workers/worker/README.md展示了典型的生产形态——一个内部监听器供可信 Worker 使用一个公共 RBAC 监听器供不受信任客户端使用engine: workers: # 主引擎端口——内部 Worker 间流量 iii-worker-manager: port: 49134 # 公共 RBAC 监听器——鉴权、中间件与受控注册 iii-worker-manager#rbac: host: 0.0.0.0 port: 49135 middleware_function_id: my-project::middleware-function rbac: auth_function_id: my-project::auth-function on_function_registration_function_id: my-project::on-function-reg on_trigger_registration_function_id: my-project::on-trigger-reg on_trigger_type_registration_function_id: my-project::on-trigger-type-reg expose_functions: - match(api::*) - match(*::public) - metadata: public: true要点第一个iii-worker-manager条目决定主引擎端口默认49134#instance条目会启动独立的监听器各自拥有独立的端口、host、中间件与 RBAC 配置。middleware_function_id一旦设置该监听器上的每次调用都会先交给中间件由中间件决定是否通过iii.trigger调用目标函数以及返回什么可独立于 RBAC 使用。管理 Workeriii worker命令全生命周期iii workerCLI 命令覆盖项目中每个 Worker 的完整生命周期在注册表中查找新的 Worker、安装进config.yaml与iii.lock、控制运行状态、查看日志以及不再需要时将其移除。查找 Workeriii 维护着一个 Worker Registry可以在 workers.iii.dev 上浏览。注册表包含大量封装了常见服务的 Worker如state、queue、http、pdfkit等。关于 Worker Registry 的更多信息参见 docs/using-iii/workers-registry.mdx.skill.md每个 Worker 页面都会列出它提供的函数与触发器类型、配置模式、支持平台与 Agent 技能skills用来判断哪个 Worker 能满足你项目的能力缺口。除了 iii 注册表Worker 也可以在 Docker 与 OCI 兼容镜像仓库中找到。添加 Worker在添加 Worker 之前你需要先安装 iii 并运行引擎。想临时起一个 iii 实例做测试可以在一个空目录里运行iii当目录里还没有config.yaml时它会自动创建一个带空 Worker 列表的配置随时可以执行iii worker add参见默认配置。Worker 可以从三种来源添加到你的 iii 实例iii Worker RegistryDocker 或 OCI 兼容镜像仓库本地开发的 Worker创建方式见 docs/creating-workers/workers.mdx。iii worker add state # 从 iii registry 下载并添加 Worker iii worker add ./workers/my_worker # 添加用 iii worker init 创建的本地 Worker iii worker add ghcr.io/org/worker:tag # 从 Docker 或 OCI 镜像仓库拉取并添加Worker 会被写进config.yaml并自动启动。对已存在的 Worker 强制重新下载使用iii worker reinstall name等价于add --force。注册表安装会校验完整的依赖图且没有任意深度限制。如果解析出的图包含超过32 个 Workeriii 会在安装前要求确认。在 CI 等非交互环境中先在本地审阅依赖图后再使用iii worker add --yes name或iii worker reinstall --yes name。iii worker add写入的是一个不带config:块的裸- name:条目。Worker 以内置默认值启动运行时设置通过配置 Worker管理其条目可作为本地文件编辑于./config/下。如果你在config.yaml中手工写入config:块它仍然作为首次启动的一次性种子生效且重新添加 Worker 会保留该块唯一的例外是iii-sandbox它的add会写入 sandbox 的config:块因为镜像白名单必须从文件强制读取。默认情况下iii worker add编辑当前目录下的配置文件所以要在与引擎相同的目录中运行。若要安装到运行在别处的引擎不同目录、不同机器或非默认端口传入--hostiii worker add pdfkit --host localhost:49134使用--host时CLI 调用引擎的worker::add触发器由引擎在它自己的项目目录中应用安装你当前目录的任何内容都不会被改动。如果在没有配置文件no config file的目录中运行iii worker add它不会在那里创建配置命令会回退到--host localhost通过你机器上运行的引擎完成安装并打印一条说明提示。只有已持有配置文件的目录或显式传入--host才决定安装落点。一个重要的边界iii worker add从远程仓库iii registry 或 OCI registry或本地文件夹下载 Worker 镜像然后在microVM中运行它们。裸引用如caller-worker:latest只在那些远程仓库中查找iii不会从你本地 Docker daemon 读取镜像所以用docker build在本地构建的镜像不会按名称被找到。本地构建的 Docker 镜像可以像其他 Docker 镜像一样运行和测试docker run -it caller-worker:latest。从实现层面看crates/iii-compose/src/edit.rs中parse_worker的解析逻辑与上述行为完全一致以.或/开头的是本地路径Source::Path其余一律视为注册表引用Source::Package裸名称会解析为默认注册表主机api.workers.iii.dev/name源码中的DEFAULT_REGISTRY_HOST常量并支持nameversion的版本规格从右侧拆分因此带 scope 的名称可保留自己的。安装时resolve_graphcrates/iii-compose/src/registry.rs会一次性向注册表的/resolve端点请求整张依赖图——所有依赖已经以互相满足的版本被钉死而非逐个依赖解析逐次请求既慢又可能解析出不同的集合。写入containers:映射时采用文本拼接而非 serde 往返序列化从而完整保留文件中的注释、空行与引用风格参见edit.rs顶部模块注释新条目标记为# added by compose::add。锁定 Worker 版本Version Pins注册表 Worker 以semver发布。安装时不带版本说明符会挑选最新版本给注册表名称追加version可以钉住某个具体版本而不是追踪最新版iii worker add state1.2.0该钉住版本会记录在iii.lock中并在后续每次安装时重放。版本的选择、version钉住、更新以及iii.lock的记录方式详见版本管理一节。列出 Workeriii worker list显示项目config.yaml中声明的每个 Worker 及其当前状态用于查看运行中和已停止的 Worker 列表iii worker list启动与停止 Worker添加的 Worker 会随引擎自动启动。需要手动控制时使用start、stop与restart命令iii worker start name # 启动单个 Worker iii worker stop -y name # 停止单个 Worker-y 跳过确认提示 iii worker restart name # 先停止再启动需要再次强调这些命令管理的是由 iii 在内置虚拟化中为你运行的 Worker。但 iii并非必须运行一个 Worker——任何使用 iii SDK、调用registerWorker()并连接到一个 iii 实例的进程都是 Worker。这一点在创建 Worker或部署 iii 系统时会更相关。检查 Worker检查某个具体 Worker 的状态、跟踪其日志或在 Worker 的沙箱内执行命令iii worker status name # 配置、沙箱状态、最近日志 iii worker logs name # 流式输出 Worker 的日志 iii worker exec name -- command # 在 Worker 内部运行命令更新 Workeriii worker update重新解析被锁定的 Worker并将新钉住版本写回iii.lock。传入 Worker 名称则更新单个省略则更新所有被锁定的 Workeriii worker update worker-name # 更新单个 Worker iii worker update # 更新所有被锁定的 Worker移除 Workeriii worker remove将 Worker 从config.yaml中移除引擎同时拆除正在运行的 Worker 进程iii worker remove -y worker-name # -y 在 Worker 正在运行时跳过确认下载的产物在移除后会留在磁盘上。要一并删除它们使用iii worker clear -y worker-name省略名称则清空所有 Worker 的产物。Worker 技能Skills每个 Worker 还会附带用于Agentic 工作的技能skills。技能由skillsWorker 管理——它是一个正在积极开发的内容注册表型 Worker像其他任何 Worker 一样添加到项目中。技能体是懒加载的顶层条目保持精简Agent 仅在某个函数引用解析到某个iii://worker/leaf章节 URI 时才会通过该 URI 获取更深层的内容。iii 还提供高层级技能让任何 Agent 都能立即使用 iii 及其 Worker。可用的函数与触发器函数与触发器来自已连接的 Worker。要使用某个类型的触发器提供它的 Worker 必须处于连接状态。例如通过 http Worker 添加http触发器之后你就可以像在 Express 或 FastAPI 这类 Web 框架中一样为你的函数暴露端点。函数与触发器的调用方式直接用worker.trigger/iii trigger或通过可选条件门控绑定到事件上参见 docs/using-iii/triggers.mdx.skill.md。版本管理Versioningiii Worker 遵循semver。项目会把每个受管 Worker 的已解析版本记录在iii.lock中使安装在机器与平台之间可复现。版本钉住见上文锁定 Worker 版本不指定版本安装会选最新版iii worker add state1.2.0可钉住具体版本。锁文件iii.lockiii.lock是位于项目根目录的YAML 文件。它把每个受管 Worker 钉到具体的版本与来源使同一组 Worker 在不同机器与平台上以相同方式安装。二进制 Worker可以在同一个锁文件中为不同平台macOS、Linux、Windows钉住各自的产物。将iii.lock与config.yaml一起提交即可获得可复现的安装。两个命令直接操作锁文件iii worker sync # 严格按 iii.lock 安装 Worker iii worker sync --frozen # CI 形态校验锁文件而不改动本地文件 iii worker verify # 报告 config.yaml 与 iii.lock 之间的漂移iii worker update是第三个与锁文件相关的命令它把钉住版本重新解析为最新允许的版本并写回iii.lock。从源码看注册表在解析时返回的版本本身就是钉死的latest_versioncrates/iii-compose/src/registry.rs会把*解析出的具体版本交给compose::add写死而不是写一个会漂移的版本区间。每次安装时基于缓存摘要sha256校验产物二进制产物按{name}-{version}-{target}-{digest}目录缓存命中则返回Cached避免重复下载。编写 Worker创建新 Worker、在 Worker 代码中注册函数与触发器以及构建或发布 Worker 镜像不在本文范围内参见 docs/creating-workers/workers.mdx。小结Worker 的生命周期与连接强绑定连接即对整个系统可见断开即不可调用。默认引擎监听器只适用于自控 Worker不受信任的客户端应接入iii-worker-manager的 RBAC 监听器通过 auth 函数、expose_functions过滤器与注册钩子实现默认拒绝的细粒度访问控制。iii worker add支持注册表、OCI 镜像仓库与本地三种来源安装进config.yaml并自动启动超过 32 个节点的依赖图会要求确认不读本地 Docker daemon 的镜像。iii worker list/status/logs/exec/start/stop/restart/update/remove/clear/sync/verify覆盖 Worker 的完整运维闭环。iii.lock是跨机器可复现安装的关键sync --frozen用于 CIverify报告漂移update重新解析并写回新钉住版本。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考