iii Workers 运维实战基于 Compose 声明、添加与实时观测项目级 Workers【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iiiWorkers 是 iii 系统中一切能力的载体任何进程只要通过 WebSocket 连上引擎并注册函数与触发器就成为可被整个系统路由调用的 worker。本文以官方 how-to 文档 docs/next/using-iii/workers.mdx 为骨架围绕iii Compose讲解如何声明项目级 worker、从 registry 添加现成包、执行日常运维命令并结合仓库内iii-compose的源码实现揭示身份命名空间、配置注入与生命周期背后的真实机制。读完你将能独立编写worker-compose.yaml、用iii trigger compose::*完成增删查改并理解引擎与 worker 之间的连接模型。Workers 的本质连接、注册、断开即失效文档开篇给出了 worker 的最小定义Workers 是通过WebSocket 连接 iii 引擎、并**注册函数functions和触发器类型triggers**的进程一旦 worker 断开连接它注册的函数与触发器立即停止可调用直到它重新连接引擎侧会为该连接自动做清理函数和触发器从实时注册表中移除正在执行中的调用被取消返回invocation_stopped错误。这套断开即失效模型是理解整个 Compose 编排的前提进程存活与网络连接是 worker 唯一且全部的存在依据因此需要 Compose 这样的监督者来保障进程的拉起、重启与依赖顺序。worker 的具体连接方式SDK 的registerWorker/register_worker/register_worker以及III_URL约定见 docs/next/creating-workers/workers.mdx本文聚焦部署与运维侧。Worker 身份与命名空间身份是(namespace, name)二元组一个 worker 的身份由(namespace, name)唯一确定两个不同的命名空间可以使用相同的名字互不冲突在同一命名空间内名字是独占的当一个同名同命名空间的 worker 已经在线时重复的 live owner 会被引擎以WORKER_NAMESPACE_CONFLICT拒绝。这一冲突即拒绝的语义在技术规格 tech-specs/2026-07-14-worker-compose/namespace.md 中被明确为设计原则命名空间是一个独立的运行时维度而非函数重命名——state::get在任何地方都还是state::get只是路由时多带一个命名空间参数命中失败返回清晰的FUNCTION_NOT_FOUND并列出该函数实际存在的命名空间。冲突处理的完整错误码表格见 docs/next/using-iii/namespaces.mdx。两个容易混淆的 namespace原文档特意区分了两个 namespace 概念worker-compose.yaml顶层的namespace:字段为该项目下所有容器containers选择命名空间Compose daemon 的--namespaceCLI 中写作-n用于定位该 daemon 自己的compose::*控制面函数——它是操作者寻址到众多 daemon 中那一个的地址。从源码看cli.rs 中--namespace被声明为该 daemon 应答compose::*的命名空间并应用到其加载的每个项目多个 daemon 可以挂到同一引擎正是靠它区分彼此。--up模式下省略该参数时daemon 会继承初始 compose 文件中的命名空间都没有时回落为default。SDK 侧的命名空间选择顺序worker 实际注册到哪个命名空间由 SDK 按以下优先级决定详见 docs/next/using-iii/namespaces.mdx优先级来源1SDK 中显式传入的namespace选项2worker 进程环境变量III_NAMESPACE3default兜底浏览器 SDK 无法读取进程环境只能显式传入。利用这一机制同一份 worker 镜像可以通过按部署设置III_NAMESPACE来服务多租户。用 Compose 声明项目 Workersworker-compose.yaml的结构项目级 worker 统一声明在worker-compose.yaml的containers:之下一个文件描述一个项目原文档示例# namespace: default engine: workers: configuration: {} containers: state: worker: package://api.workers.iii.dev/state version: 0.22.2 config_name: state api: worker: path://./workers/api start_after: [state] scripts: run: pnpm start关键规则package://registry 包必须给出显式的versionCompose 据此解析包图并写入锁文件path://本地目录的启动命令来自 compose 文件中的scripts.run或者其iii.worker.yamlmanifest 中的scripts.startstart_after声明启动依赖仅在同一文件内解析形成启动 DAG。启动一个项目iii compose build --file worker-compose.yaml iii compose --namespace dev --up --file worker-compose.yamliii compose build在启动前下载所有声明的package://worker--up随后复用共享的包缓存本地path://worker 会被跳过它们没有可下载的包文件中出现engine:块时daemon 会自己拥有并负责停止引擎没有该块时需通过--engine或环境变量III_URL连接一个由别处管理的引擎。从源码看命令解析cli.rs 定义默认文件名常量DEFAULT_COMPOSE_FILE worker-compose.yaml不指定--file时直接使用当前目录下这个文件因此在项目目录内运行无需再命名文件。同时注意--file仅在与--up一起使用时合法requires up否则报FileRequiresUp错误iii compose build是唯一的纯本地动作读取文件、准备 registry 包不连接也不启动引擎--namespace在解析阶段即做校验空串、含路径分隔符等都会被拒绝因为它既是引擎路由的命名空间又是~/.iii/compose下的目录名。容器字段速查表技术规格 tech-specs/2026-07-14-worker-compose/compose-file.md 给出了完整字段契约字段必填规则worker是package://registry或path://本地目录version仅 package精确或范围版本解析进 lockfilestart_after否仅限同文件内的容器 idconfig_name否该容器拥有的配置条目名config_override否稀疏 map合并覆盖拉取到的配置基值scripts否无 manifest 的path://必须提供run见下working_dir否默认path://为 worker 目录package://为 compose 文件目录校验为硬错误空containers、未知start_after、依赖环报错会打印完整路径如api - queue - database - api、package://上写run、path://既无 manifest 又无run等都会被拒绝。iii compose validate可离线运行整套规则无需引擎。scripts钩子契约同规格文档 tech-specs/2026-07-14-worker-compose/scripts.md 定义了三个钩子钩子是否阻塞触发时机失败后果pre_start是每次 spawn 前配置解析后退出码非 0 或超时 → 容器failedworker 不启动up回滚本次操作run受监督worker 进程本体崩溃 → 级联停止本地依赖者post_run否run退出后恰好一次任何退出路径告警 last_error记入 status不阻塞拆除pre_start_timeout默认60s钩子在任何 worker 类型上都执行运行在 daemon 所在主机run只对path://有意义——package://二进制的启动是隐式的以标准 CLI 契约--url --namespace --config执行解析产物。path://的启动优先级为compose 的run manifest 的scripts.start。prisma migrate这类项目级准备动作放在pre_start是规格明确推荐的用法。添加 Registry Workercompose::add是向运行中的 daemon 添加 worker 的唯一入口它解析包依赖图、把精确版本写回 compose 文件、然后重启项目iii trigger -n dev compose::add workerstate iii trigger -n dev compose::add workerqueue0.21.5-n dev寻址 dev 命名空间下的 daemon对应 daemon 的--namespace当 daemon 的工作目录不是项目目录时用file/absolute/path/worker-compose.yaml指定文件若添加的 registry 根包kind 为engine引擎已内置供应的包会被拒绝从 daemon.rs 的实现注释可以看到compose::add承诺写入精确版本因此不会留下latest这种不可复现的解析结果。已发布的 worker 包可在官方 registry 索引中查找添加前建议先查看包页面确认其 functions、triggers 与配置 schema。运维 Workers状态、日志、重启与下线原文档给出了一套完整的运维命令集iii trigger -n dev compose::status fileworker-compose.yaml iii compose logs state --follow --namespace dev iii trigger -n dev compose::restart fileworker-compose.yaml workerstate iii trigger -n dev compose::update fileworker-compose.yaml workerstate iii trigger -n dev compose::down fileworker-compose.yaml语义对照命令作用compose::status进程归属、PID、最近一次 supervisor 错误compose::restart worker只重启一个容器compose::update worker编辑该 worker 的包 pin版本锁定并重启整个项目compose::down按逆依赖顺序停止容器iii compose logs worker --follow实时查看原始 stdout/stderr两类观测视图要区分开引擎的实时连接视图用engine::workers::list与engine::workers::info看的是当前有哪些 worker 连着引擎进程级视图用compose::status看的是谁拥有这些进程、PID 是多少、最后一次 supervisor 错误是什么。从 cli.rs 可见iii compose logs还支持--tail默认行数见 logs.rs 的DEFAULT_TAIL_LINES且设有上限MAX_TAIL_LINES、--stream限定 stdout/stderr 某一流等参数日志通过已运行的 daemon 读取worker 名省略时读取项目内全部 worker 的输出。配置默认值、条目与覆盖优先级每个 worker 包都会携带默认配置。容器层有两个配置相关字段config_name为该容器命名其对应的配置-worker 条目即注册到configurationworker 下的条目 idconfig_override在容器里就地覆盖具体配置值。配置的最终生效优先级是package 默认值 已存储的配置条目值 config_override原文档示例containers: http: worker: package://api.workers.iii.dev/http version: 0.21.3 config_name: http config_override: host: 0.0.0.0 port: 3111配置如何到达 workerIII_CONFIG/III_CONFIG_NAMECompose 会把合并后的配置值通过III_CONFIG环境变量传给子进程并在声明了config_name时把条目名发布到III_CONFIG_NAME。完整的配置体系两层结构config.yaml引导 seed 与configurationworker 的 schema 校验注册表见 docs/next/using-iii/configuration.mdx。从源码看这是iii-compose精心设计的保留环境变量契约。spawn.rs 定义了 8 个保留键III_URL、III_NAMESPACE、III_COMPOSE_NAMESPACE、III_COMPOSE_FILE、III_COMPOSE_DIR、III_CONFIG、III_CONFIG_NAME、III_WORKER_NAME用户在environment/env_file中声明这些键会在解析期被拒绝而不是被静默覆盖子进程环境是宿主基线 用户 env 保留契约三层合并的结果spawn_plan。其中III_URL是 daemon 自己的连接就绪观测也走它因此一个容器指向别的引擎对 daemon 不可见III_NAMESPACE与III_WORKER_NAME是一对就绪观测键III_CONFIG与III_CONFIG_NAME是同一份交付的两半合并值写入文件、条目发布到 configuration 注册表configuration.rs 的模块注释说明 worker 只需凭III_CONFIG的文件路径读取无需任何凭据去主动拉取配置。引擎托管的例外哪些 worker 不能由项目声明以下 worker始终由引擎拥有不属于项目 containersconfigurationiii-worker-manageriii-http-functionsiii-streamiii-sandbox它们应当放在engine.workers下受 Compose 管理时或者——仅当外部 supervisor 拥有引擎时——放在引擎的config.yaml中。另有三个内部 worker 会被自动注入iii-engine-functions、iii-telemetry、iii-observability它们绝不能被添加为 Compose 的 package 根。一个常见需求要为不可信 worker 配置 RBAC 监听器就在engine.workers或直连引擎模式的config.yaml中声明iii-worker-manager其完整 schema 与命名空间级expose_functions规则见 docs/next/creating-workers/worker-manager.mdx。Compose 之外的 WorkersCompose 并不是运行 worker 的唯一方式它只是一个可选的进程监督者。对于由Kubernetes、systemd、其他主机或SDK 驱动的开发命令管理的进程只需要两样东西引擎 URL一个 worker 名以及可选命名空间。一旦连接成功它就参与同一个函数与触发器网络与其他 worker 完全对等Compose 只拥有它在文件中声明的那些进程。这正对应 docs/next/creating-workers/workers.mdx 中连接字符串是 worker 与 iii 实例之间的唯一耦合的说法——worker 进程可以部署在网络可达的任何位置SDK 侧读取III_URL即可加入。从旧版本迁移0.23 版本移除了iii worker命令、worker::*控制面函数以及引擎侧的项目 worker 自启动能力。如果你有一个旧项目在启动前请先按 upgrading 目录 中的迁移指南处理旧项目的 worker 声明方式需要转换到worker-compose.yaml Compose daemon 的模型上来否则引擎不会再替你拉起这些进程。编写 Worker从部署回到开发部署与运维解决的是进程如何活着而worker 里装了什么由 SDK 代码与 manifest 决定入口统一在 docs/next/creating-workers/workers.mdx。该文档覆盖SDK 连接代码III_URL约定、namespace选项、iii.worker.yamlmanifest、函数与触发器注册、以及发布流程。几个与本文直接相关的要点manifest项目根目录的iii.worker.yaml声明name、可选description一行人/LLM 可读摘要与scripts.startCompose 容器可用自己的scripts.run覆盖之并用pre_run/post_run做生命周期钩子生命周期状态connecting → connected → available / busy → disconnectedengine::workers::list等发现函数把拓扑变化暴露给系统其余部分断线处理调用方应捕获invocation_stopped视为取消重试需等 worker 重连需要感知拓扑变化时可绑定engine::workers-available/engine::functions-available触发器优雅关闭SDK 的shutdown会干净地关闭 WebSocket引擎随之移除注册、触发worker_disconnected事件并取消在途调用——特别适合一次性one-shot / ephemeralworker如 Kubernetes Job、serverless 容器或定时脚本。小结把本文的运维命令与 docs/next/using-iii/configuration.mdx、docs/next/using-iii/namespaces.mdx 两篇配合使用即可完整覆盖声明 → 添加 → 配置 → 观测 → 下线的项目级 worker 全生命周期。其背后的实现证据可以在 crates/iii-compose/src/cli.rs、crates/iii-compose/src/spawn.rs、crates/iii-compose/src/daemon.rs 以及 tech-specs/2026-07-14-worker-compose/ 系列规格中逐一核对。【免费下载链接】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 Workers 运维实战：基于 Compose 声明、添加与实时观测项目级 Workers
iii Workers 运维实战基于 Compose 声明、添加与实时观测项目级 Workers【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iiiWorkers 是 iii 系统中一切能力的载体任何进程只要通过 WebSocket 连上引擎并注册函数与触发器就成为可被整个系统路由调用的 worker。本文以官方 how-to 文档 docs/next/using-iii/workers.mdx 为骨架围绕iii Compose讲解如何声明项目级 worker、从 registry 添加现成包、执行日常运维命令并结合仓库内iii-compose的源码实现揭示身份命名空间、配置注入与生命周期背后的真实机制。读完你将能独立编写worker-compose.yaml、用iii trigger compose::*完成增删查改并理解引擎与 worker 之间的连接模型。Workers 的本质连接、注册、断开即失效文档开篇给出了 worker 的最小定义Workers 是通过WebSocket 连接 iii 引擎、并**注册函数functions和触发器类型triggers**的进程一旦 worker 断开连接它注册的函数与触发器立即停止可调用直到它重新连接引擎侧会为该连接自动做清理函数和触发器从实时注册表中移除正在执行中的调用被取消返回invocation_stopped错误。这套断开即失效模型是理解整个 Compose 编排的前提进程存活与网络连接是 worker 唯一且全部的存在依据因此需要 Compose 这样的监督者来保障进程的拉起、重启与依赖顺序。worker 的具体连接方式SDK 的registerWorker/register_worker/register_worker以及III_URL约定见 docs/next/creating-workers/workers.mdx本文聚焦部署与运维侧。Worker 身份与命名空间身份是(namespace, name)二元组一个 worker 的身份由(namespace, name)唯一确定两个不同的命名空间可以使用相同的名字互不冲突在同一命名空间内名字是独占的当一个同名同命名空间的 worker 已经在线时重复的 live owner 会被引擎以WORKER_NAMESPACE_CONFLICT拒绝。这一冲突即拒绝的语义在技术规格 tech-specs/2026-07-14-worker-compose/namespace.md 中被明确为设计原则命名空间是一个独立的运行时维度而非函数重命名——state::get在任何地方都还是state::get只是路由时多带一个命名空间参数命中失败返回清晰的FUNCTION_NOT_FOUND并列出该函数实际存在的命名空间。冲突处理的完整错误码表格见 docs/next/using-iii/namespaces.mdx。两个容易混淆的 namespace原文档特意区分了两个 namespace 概念worker-compose.yaml顶层的namespace:字段为该项目下所有容器containers选择命名空间Compose daemon 的--namespaceCLI 中写作-n用于定位该 daemon 自己的compose::*控制面函数——它是操作者寻址到众多 daemon 中那一个的地址。从源码看cli.rs 中--namespace被声明为该 daemon 应答compose::*的命名空间并应用到其加载的每个项目多个 daemon 可以挂到同一引擎正是靠它区分彼此。--up模式下省略该参数时daemon 会继承初始 compose 文件中的命名空间都没有时回落为default。SDK 侧的命名空间选择顺序worker 实际注册到哪个命名空间由 SDK 按以下优先级决定详见 docs/next/using-iii/namespaces.mdx优先级来源1SDK 中显式传入的namespace选项2worker 进程环境变量III_NAMESPACE3default兜底浏览器 SDK 无法读取进程环境只能显式传入。利用这一机制同一份 worker 镜像可以通过按部署设置III_NAMESPACE来服务多租户。用 Compose 声明项目 Workersworker-compose.yaml的结构项目级 worker 统一声明在worker-compose.yaml的containers:之下一个文件描述一个项目原文档示例# namespace: default engine: workers: configuration: {} containers: state: worker: package://api.workers.iii.dev/state version: 0.22.2 config_name: state api: worker: path://./workers/api start_after: [state] scripts: run: pnpm start关键规则package://registry 包必须给出显式的versionCompose 据此解析包图并写入锁文件path://本地目录的启动命令来自 compose 文件中的scripts.run或者其iii.worker.yamlmanifest 中的scripts.startstart_after声明启动依赖仅在同一文件内解析形成启动 DAG。启动一个项目iii compose build --file worker-compose.yaml iii compose --namespace dev --up --file worker-compose.yamliii compose build在启动前下载所有声明的package://worker--up随后复用共享的包缓存本地path://worker 会被跳过它们没有可下载的包文件中出现engine:块时daemon 会自己拥有并负责停止引擎没有该块时需通过--engine或环境变量III_URL连接一个由别处管理的引擎。从源码看命令解析cli.rs 定义默认文件名常量DEFAULT_COMPOSE_FILE worker-compose.yaml不指定--file时直接使用当前目录下这个文件因此在项目目录内运行无需再命名文件。同时注意--file仅在与--up一起使用时合法requires up否则报FileRequiresUp错误iii compose build是唯一的纯本地动作读取文件、准备 registry 包不连接也不启动引擎--namespace在解析阶段即做校验空串、含路径分隔符等都会被拒绝因为它既是引擎路由的命名空间又是~/.iii/compose下的目录名。容器字段速查表技术规格 tech-specs/2026-07-14-worker-compose/compose-file.md 给出了完整字段契约字段必填规则worker是package://registry或path://本地目录version仅 package精确或范围版本解析进 lockfilestart_after否仅限同文件内的容器 idconfig_name否该容器拥有的配置条目名config_override否稀疏 map合并覆盖拉取到的配置基值scripts否无 manifest 的path://必须提供run见下working_dir否默认path://为 worker 目录package://为 compose 文件目录校验为硬错误空containers、未知start_after、依赖环报错会打印完整路径如api - queue - database - api、package://上写run、path://既无 manifest 又无run等都会被拒绝。iii compose validate可离线运行整套规则无需引擎。scripts钩子契约同规格文档 tech-specs/2026-07-14-worker-compose/scripts.md 定义了三个钩子钩子是否阻塞触发时机失败后果pre_start是每次 spawn 前配置解析后退出码非 0 或超时 → 容器failedworker 不启动up回滚本次操作run受监督worker 进程本体崩溃 → 级联停止本地依赖者post_run否run退出后恰好一次任何退出路径告警 last_error记入 status不阻塞拆除pre_start_timeout默认60s钩子在任何 worker 类型上都执行运行在 daemon 所在主机run只对path://有意义——package://二进制的启动是隐式的以标准 CLI 契约--url --namespace --config执行解析产物。path://的启动优先级为compose 的run manifest 的scripts.start。prisma migrate这类项目级准备动作放在pre_start是规格明确推荐的用法。添加 Registry Workercompose::add是向运行中的 daemon 添加 worker 的唯一入口它解析包依赖图、把精确版本写回 compose 文件、然后重启项目iii trigger -n dev compose::add workerstate iii trigger -n dev compose::add workerqueue0.21.5-n dev寻址 dev 命名空间下的 daemon对应 daemon 的--namespace当 daemon 的工作目录不是项目目录时用file/absolute/path/worker-compose.yaml指定文件若添加的 registry 根包kind 为engine引擎已内置供应的包会被拒绝从 daemon.rs 的实现注释可以看到compose::add承诺写入精确版本因此不会留下latest这种不可复现的解析结果。已发布的 worker 包可在官方 registry 索引中查找添加前建议先查看包页面确认其 functions、triggers 与配置 schema。运维 Workers状态、日志、重启与下线原文档给出了一套完整的运维命令集iii trigger -n dev compose::status fileworker-compose.yaml iii compose logs state --follow --namespace dev iii trigger -n dev compose::restart fileworker-compose.yaml workerstate iii trigger -n dev compose::update fileworker-compose.yaml workerstate iii trigger -n dev compose::down fileworker-compose.yaml语义对照命令作用compose::status进程归属、PID、最近一次 supervisor 错误compose::restart worker只重启一个容器compose::update worker编辑该 worker 的包 pin版本锁定并重启整个项目compose::down按逆依赖顺序停止容器iii compose logs worker --follow实时查看原始 stdout/stderr两类观测视图要区分开引擎的实时连接视图用engine::workers::list与engine::workers::info看的是当前有哪些 worker 连着引擎进程级视图用compose::status看的是谁拥有这些进程、PID 是多少、最后一次 supervisor 错误是什么。从 cli.rs 可见iii compose logs还支持--tail默认行数见 logs.rs 的DEFAULT_TAIL_LINES且设有上限MAX_TAIL_LINES、--stream限定 stdout/stderr 某一流等参数日志通过已运行的 daemon 读取worker 名省略时读取项目内全部 worker 的输出。配置默认值、条目与覆盖优先级每个 worker 包都会携带默认配置。容器层有两个配置相关字段config_name为该容器命名其对应的配置-worker 条目即注册到configurationworker 下的条目 idconfig_override在容器里就地覆盖具体配置值。配置的最终生效优先级是package 默认值 已存储的配置条目值 config_override原文档示例containers: http: worker: package://api.workers.iii.dev/http version: 0.21.3 config_name: http config_override: host: 0.0.0.0 port: 3111配置如何到达 workerIII_CONFIG/III_CONFIG_NAMECompose 会把合并后的配置值通过III_CONFIG环境变量传给子进程并在声明了config_name时把条目名发布到III_CONFIG_NAME。完整的配置体系两层结构config.yaml引导 seed 与configurationworker 的 schema 校验注册表见 docs/next/using-iii/configuration.mdx。从源码看这是iii-compose精心设计的保留环境变量契约。spawn.rs 定义了 8 个保留键III_URL、III_NAMESPACE、III_COMPOSE_NAMESPACE、III_COMPOSE_FILE、III_COMPOSE_DIR、III_CONFIG、III_CONFIG_NAME、III_WORKER_NAME用户在environment/env_file中声明这些键会在解析期被拒绝而不是被静默覆盖子进程环境是宿主基线 用户 env 保留契约三层合并的结果spawn_plan。其中III_URL是 daemon 自己的连接就绪观测也走它因此一个容器指向别的引擎对 daemon 不可见III_NAMESPACE与III_WORKER_NAME是一对就绪观测键III_CONFIG与III_CONFIG_NAME是同一份交付的两半合并值写入文件、条目发布到 configuration 注册表configuration.rs 的模块注释说明 worker 只需凭III_CONFIG的文件路径读取无需任何凭据去主动拉取配置。引擎托管的例外哪些 worker 不能由项目声明以下 worker始终由引擎拥有不属于项目 containersconfigurationiii-worker-manageriii-http-functionsiii-streamiii-sandbox它们应当放在engine.workers下受 Compose 管理时或者——仅当外部 supervisor 拥有引擎时——放在引擎的config.yaml中。另有三个内部 worker 会被自动注入iii-engine-functions、iii-telemetry、iii-observability它们绝不能被添加为 Compose 的 package 根。一个常见需求要为不可信 worker 配置 RBAC 监听器就在engine.workers或直连引擎模式的config.yaml中声明iii-worker-manager其完整 schema 与命名空间级expose_functions规则见 docs/next/creating-workers/worker-manager.mdx。Compose 之外的 WorkersCompose 并不是运行 worker 的唯一方式它只是一个可选的进程监督者。对于由Kubernetes、systemd、其他主机或SDK 驱动的开发命令管理的进程只需要两样东西引擎 URL一个 worker 名以及可选命名空间。一旦连接成功它就参与同一个函数与触发器网络与其他 worker 完全对等Compose 只拥有它在文件中声明的那些进程。这正对应 docs/next/creating-workers/workers.mdx 中连接字符串是 worker 与 iii 实例之间的唯一耦合的说法——worker 进程可以部署在网络可达的任何位置SDK 侧读取III_URL即可加入。从旧版本迁移0.23 版本移除了iii worker命令、worker::*控制面函数以及引擎侧的项目 worker 自启动能力。如果你有一个旧项目在启动前请先按 upgrading 目录 中的迁移指南处理旧项目的 worker 声明方式需要转换到worker-compose.yaml Compose daemon 的模型上来否则引擎不会再替你拉起这些进程。编写 Worker从部署回到开发部署与运维解决的是进程如何活着而worker 里装了什么由 SDK 代码与 manifest 决定入口统一在 docs/next/creating-workers/workers.mdx。该文档覆盖SDK 连接代码III_URL约定、namespace选项、iii.worker.yamlmanifest、函数与触发器注册、以及发布流程。几个与本文直接相关的要点manifest项目根目录的iii.worker.yaml声明name、可选description一行人/LLM 可读摘要与scripts.startCompose 容器可用自己的scripts.run覆盖之并用pre_run/post_run做生命周期钩子生命周期状态connecting → connected → available / busy → disconnectedengine::workers::list等发现函数把拓扑变化暴露给系统其余部分断线处理调用方应捕获invocation_stopped视为取消重试需等 worker 重连需要感知拓扑变化时可绑定engine::workers-available/engine::functions-available触发器优雅关闭SDK 的shutdown会干净地关闭 WebSocket引擎随之移除注册、触发worker_disconnected事件并取消在途调用——特别适合一次性one-shot / ephemeralworker如 Kubernetes Job、serverless 容器或定时脚本。小结把本文的运维命令与 docs/next/using-iii/configuration.mdx、docs/next/using-iii/namespaces.mdx 两篇配合使用即可完整覆盖声明 → 添加 → 配置 → 观测 → 下线的项目级 worker 全生命周期。其背后的实现证据可以在 crates/iii-compose/src/cli.rs、crates/iii-compose/src/spawn.rs、crates/iii-compose/src/daemon.rs 以及 tech-specs/2026-07-14-worker-compose/ 系列规格中逐一核对。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
