OpenHuman Agent Orchestration多 Agent 协作控制平面的架构与实现【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman导读OpenHuman 是一个本地优先的个人 AI 项目面向 Mac / Windows / Linux其核心引擎用 Rust 实现支持深度研究、Agent 编排与记忆系统。本文聚焦仓库中src/openhuman/agent/orchestration模块——它是 Agent 与 Agent 之间协作的高层控制平面control plane负责父子 Agent 的血缘关系lineage、生命周期状态、等待/关闭/跟进wait/close/follow-up语义以及 UI/诊断事件。读完本文你将掌握编排层与执行引擎agent::harness的分工边界、spawn_subagent/spawn_parallel_agents等工具的调用契约、子 Agent 状态模型与终态词汇表、Codex 风格控制面spawn/wait/abort的落地形态以及当前进程内持久化设计与未来的落盘方向。一、定位控制平面与执行引擎的分层模块自述文档 开篇即明确了职责边界agent_orchestration是高层控制平面拥有父子 Agent 血缘、生命周期状态、等待/关闭/跟进语义以及 UI/诊断事件agent::harness是低层执行引擎负责 prompt 构造、策略过滤后的工具可见性、模型选择与子 Agent 循环sub-agent loops。这一分层在 mod.rs 的模块文档中进一步展开执行层面基于 TinyAgents图graph扇出——workflow_runs在图形引擎上调度阶段 DAGagent_teams通过条件路由图运行成员delegation接线可持久化的 plan→execute⇄review→finalize 图并行扇出走tinyagents_graph::parallel::map_reduce。而编排模块自身保留的是产品层持久的 SQL/JSON 运行台账run ledger、校验、取消语义、兼容事件以及 JSON-RPC/工具响应格式化。换句话说编排层只决定谁在什么时候跑、处于什么状态、如何等待与取消执行层才决定这个 Agent 具体怎么思考、能调哪些工具。这个边界是理解整个模块的关键。二、当前模块清单Current InventoryREADME 列出了当前可用的编排工具与执行通道组件职责agent_orchestration::tools::spawn_subagent运行一个类型化子 Agent返回折叠后的结果agent_orchestration::tools::spawn_parallel_agents扇出多个相互独立的类型化子 Agent 运行agent_orchestration::tools::spawn_worker_thread创建持久化的 worker-thread 转写transcriptagent::harness::subagent_runner类型化子 Agent 的规范执行路径agent::progress::AgentProgress::Subagent*与DomainEvent::Subagent*生命周期与子工具调用的遥测事件一个重要的限制在 README 中明确标注当前spawn_subagent工具拒绝dedicated_thread参数直到 worker UI 就绪为止。不过从源码看这一限制已在演进——spawn_subagent_tool_impl.rs 中的 schema 将dedicated_thread描述为Legacy compatibility flag当父上下文可用时委派现在总会创建持久化 worker 线程该参数不再决定线程的创建。三、控制面操作Codex 风格的多 Agent 控制README 明确指出编排层预期的规范操作canonical operations对标 Codex 风格的多 Agent 控制spawn_agent在 TinyAgents 的DetachedTaskRegistry中注册一个子 Agent并通过agent::harness::run_subagent运行它wait_agents等待一个或多个子 Agent 达到终态可带超时观察到终态的子 Agent 会被执行 wait 的调用方从注册表中剪除prunedabort_all向每个存活的子 Agent 发布cancelled状态并硬中止hard-abort其任务。这一设计在 ops.rs 中得到了完整实现。模块文档明确说明这个会话层曾经维护一套自研的进程内任务表HashMapString, AgentRecordJoinHandleNotify 手工终态清扫而 TinyAgents 的DetachedTaskRegistry是它的严格超集——自带状态 watch 通道、协作式取消令牌、硬中止句柄、按 owner 作用域的查找、wait/timeout 循环以及软上限终态清扫。因此spawn_agent/wait_agents/abort_all现在只是对register/wait/cancel_all的薄产品包装。源码中两个值得注意的常量ops.rsREGISTRY_SOFT_CAP: usize 256——每个会话存活子 Agent 的软上限只有表增长超过该值时才会清扫终态条目UNBOUNDED_WAIT_CHUNK: Duration Duration::from_secs(3600)——TinyAgents 的wait需要具体截止时间因此timeout_ms: None无限等待会按 1 小时为一段循环等待保持旧的永远等待契约。另外有一个行为后果值得使用者注意wait一旦观察到终态就会剪除条目因此一个子 Agent 只能被等待一次。仓库内所有调用方都是spawn 一次、wait 一次running_subagents也遵循同样的契约。曾经的内存镜像与持久化的替代者README 特别说明内存版的list_agents/message_agent/close_agent/follow_up/resume_agent/events镜像已被移除其持久化等价物位于command_center::control。这一点我们会在第六节展开。四、状态模型每个子 Agent 的稳定标识与终态词汇表README 定义了子 Agent 的状态模型每个子 Agent 具有稳定的orchestration_id、agent_id、可选的parent_agent_id、status、prompt、结果摘要、错误、时间戳与元数据。状态类型是 TinyAgents 的OrchestrationTaskStatus终态terminal values为completed、failed、cancelled、timed_out、abandoned。这个模型在 types.rs 中被序列化为可持久化的公共数据模型pub struct SpawnAgentRequest { pub agent_id: String, pub prompt: String, pub context: OptionString, // 可选上下文 pub toolkit: OptionString, // Composio 工具集 pub model: OptionString, // 本次 spawn 的模型覆盖 pub parent_agent_id: OptionString, pub metadata: BTreeMapString, String, } pub struct AgentSnapshot { pub orchestration_id: String, pub agent_id: String, pub parent_agent_id: OptionString, pub status: OrchestrationTaskStatus, pub prompt: String, pub result_summary: OptionString, pub error: OptionString, pub created_at: String, pub updated_at: String, pub metadata: BTreeMapString, String, }types.rs 的模块注释揭示了一个历史变迁编排层曾有一套宿主自有的AgentStatus拷贝控制平面迁移到 crate 的DetachedTaskRegistry后即被退役现在两套词汇表统一为 TinyAgents 的OrchestrationTaskStatus。pub use tinyagents_graph::orchestration::OrchestrationTaskStatus;这一行就是统一入口。在 tinyagents/orchestration.rs 中可以进一步看到这套状态词汇背后的运行时机制每个子任务在TaskStore中经历类型化的生命周期记账Pending → Running → Completed/Failed/Cancelled/…取代了早先自研状态枚举 watch 通道 tombstone 集合的临时方案DetachedTaskRegistry则负责进程内状态、取消、硬中止、所有权与转向steering机制。五、策略继承只加血缘与生命周期不扩大工具可见性README 对安全边界给出了明确要求策略继承被委托给agent::harness::run_subagent后者已经从父ParentExecutionContext派生子 Agent 的工具、模型路由、沙箱上下文、spawn 深度与进度。编排层只应添加血缘与生命周期语义绝不能扩大 harness 暴露给子 Agent 的工具可见性。这一约束在代码中体现为薄包装式设计AgentOrchestrationSession持有的ChildRegistry类型是DetachedTaskRegistryChildMetadata, ChildStateops.rsChildMetadata仅保留agent_id、parent_agent_id、prompt、时间戳、元数据与一个status_txwatch 发送端——没有任何工具列表字段。status_tx的设计细节值得展开它让abort_all能在 crate 硬中止任务之前先向正在wait_agents的并发等待方发布一个终态Cancelled。否则取消会直接丢弃 sender等待方看到的将是一个关闭的通道而不是一次取消。此外tinyagents/orchestration.rs 中的SteeringRunClass从另一个角度强化了安全边界Interactive用户实时聊天轮次只允许InjectMessage与协作式Pause其余全部拒绝Background分离的后台子 Agent 运行额外允许Resume、Cancel、Redirect——这是比硬AbortHandle取消更优雅、且只在安全循环边界生效每次模型调用前排空的替代方案。不在白名单内的转向命令会被 crate 以TinyAgentsError::Steering拒绝并中止运行。六、持久化进程内先行可序列化面向未来README 明确指出首个实现是进程内的process-local但状态形状是可序列化的因此后续 PR 可以在不改动调用方的前提下将编排会话持久化到应用重启、cron 恢复与线程延续thread continuation场景。当前持久化方向的最具体落地是command_center::controlcontrol.rs。它提供的四个可持久化控制动词直接对应被移除的内存镜像动词语义目标状态stop取消非终态运行cancelledretry重新排队以错误结束的运行failed/cancelled/interrupted→pendingcontinue回答awaiting_user运行使其恢复runningfollow_up记录跟进指令状态保持不变不变每个动词都是对持久化运行台账tinyagents_session::run_ledger的一次持久化状态迁移通过transition_agent_run_status写入新状态可清除error/completed_at这是 upsert 路径做不到的并追加一条run_event记录该动作进入运行时间线。允许的迁移矩阵由纯函数plan_transition定义并被无数据库的单元测试覆盖——例如stop对pending合法、对completed不合法这类规则全部可测试。与之配套的只读投影在 command_center/types.rs 中后台 Agent 命令中心把运行台账细粒度的AgentRunStatus归并为五个用户可见分组needs_input/working/completed/failed/stopped显示顺序把需要输入放在最前让阻塞中的工作最显眼AgentWorkRow则携带 run_id、kind、agent_id、bucket、父线程 id、worker 线程 id、摘要、错误、时间戳、耗时、token 消耗与费用USD等遥测字段。七、源码级深入两大核心工具的调用契约spawn_subagent单任务委派工具实现位于 spawn_subagent.rs 与其实现文件 spawn_subagent_tool_impl.rs。其语义是编排器或任何注册了该工具的父 Agent调用它把一个聚焦子任务交给专门化的子 Agent——查找全局AgentDefinitionRegistry中的定义、按定义过滤父工具注册表、构建窄化的系统 prompt、用父 Provider 跑内层工具循环最后把子 Agent 的循环历史折叠成单段文本结果作为普通tool_result返回给父 Agent。参数 schema 要点均可从源码确认参数说明agent_id必填。子 Agent idschema 从全局注册表动态生成枚举archetype是已弃用的向后兼容别名prompt必填。子 Agent 对父对话无记忆需包含其行动所需的全部上下文context可选。此前任务结果的上下文块渲染为 prompt 前的[Context]段model可选。仅本次 spawn 生效的精确模型 id保留父 Provider/路由但固定子模型toolkit可选。Composio 工具集 slug如gmail、notion、slack当agent_id integrations_agent时必填用于收窄子 Agent 可见的 Composio 动作blocking默认false传true则内联运行并直接返回子 Agent 最终输出task_key可选。可复用异步委派的确定性标识键默认取归一化的 prompt/标题fresh传true时绕过可复用子 Agent 匹配创建全新持久 worker工具的description还包含一条重要的使用纪律不要在循环里反复调用spawn_subagent来扇出——每次调用只委派单个任务、不会并发启动 worker会把整个请求串行化要并发请用spawn_parallel_agents一次调用启动多个 worker。工具对失败的分类也值得借鉴classify_subagent_failure当错误消息包含 no healthy upstream、upstream_unhealthy、provider call failed: all providers/models failed 等特征时会明确标注为上游推理不可用LLM Provider 故障/容量问题而非集成认证问题并建议避免立即重试。spawn_parallel_agents并发扇出spawn_parallel_agents.rs 实现并发扇出schema 要求tasks数组minItems: 2每个任务包含任务字段说明agent_id/prompt必填同上context/toolkit可选同上ownership可选。该 worker 的互斥文件/模块/职责边界isolationnone默认共享工作区或worktree为可编辑 worker 提供独立 git worktree 检出避免并行编辑冲突base_ref仅isolation worktree时使用head默认从当前 HEAD 分叉或fresh从仓库默认分支分叉核心规则只读与 worktree 隔离的 worker 可并行共享工作区且带写能力工具的 worker 要求互斥files:所有权否则走串行回退。该工具还绕过了全局的逐工具墙钟截止时间这是长时间并行研究任务的设计选择并通过spawn_parallel_graph实现了带取消与工作区所有权边界with_ownership_boundary的图执行。后台运行与转向running_subagents与spawn_worker_threadrunning_subagents.rs 记录了在飞in-flight异步子 Agent 的注册表每个异步子 Agent 在 TinyAgents 的DetachedTaskRegistry中以task_id为键注册并携带ArcRunQueue——转向通道使steer_subagent能在没有 crate 原生转向句柄时注入消息TinyAgentsSteeringHandle——子运行激活期间注册到进程内SteeringRegistrywatch::ReceiverSubagentStatus——使wait_subagent能阻塞到子 Agent 达到终态AbortHandle——供subagent_cancel/close_subagent停止分离工作。同时每个分离子 Agent 还会作为OrchestrationTaskKind::SubAgent写入进程级 TinyAgentsTaskStorePending → Running随后镜像为Completed/Failed/Awaiting取消路径记录Cancelled提供类型化、可查询的生命周期记录task_records。spawn_worker_thread的实现spawn_subagent.rs 中的persist_worker_thread会把 prompt 折叠为线程标题上限WORKER_THREAD_TITLE_MAX_CHARS 80与 UI 线程列表的可见字符上限保持一致创建带tasks标签的持久线程并写入用户消息。八、面向未来声明式工作流与多 Agent 团队编排目录下还有两块面向长期演进的模块值得关注workflow_runstypes.rs声明式的WorkflowDefinition阶段图——每个阶段命名要扇出的 Agent 与其依赖的阶段运行器按依赖顺序以有界并发调度WorkflowSafetyTierread_only/standard/edit_capable决定子 Agent 权限当前仅read_only先行落地可编辑层级等待引擎落地后以显式用户批准为门槛。保持声明式是为了规避任意进程内脚本执行带来的安全面。agent_teams通过条件路由图运行团队成员并提供注册控制器 schemaall_agent_team_controller_schemas等。subagent_sessions/parent_context子 Agent 会话存储与父执行上下文构造builder.rs是策略继承与血缘追踪的基础设施。README 还指出了进一步的上游迁移方向running_subagents将更多分离子 Agent 生命周期移植到 TinyAgents 任务存储这一工作跟踪于docs/tinyagents-migration-plan-2026-07-22.md的 WP-5。小结OpenHuman 的agent_orchestration模块展示了一条清晰的分层演进路线把编排与执行彻底分离把进程内自研机制逐步收敛到 TinyAgents 的类型化原语之上。当前形态下开发者可以依赖的稳定接口包括spawn_subagent单任务委派参数 schema 动态生成、spawn_parallel_agents带所有权/隔离语义的并发扇出、wait/cancel语义终态剪除、一次等待、五个终态词汇completed/failed/cancelled/timed_out/abandoned以及通过command_center::control提供的四个持久化控制动词stop / retry / continue / follow_up。无论未来是否引入跨重启持久化可序列化的AgentSnapshot状态形状都保证了调用方无需改动即可平滑迁移。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenHuman Agent Orchestration：多 Agent 协作控制平面的架构与实现
OpenHuman Agent Orchestration多 Agent 协作控制平面的架构与实现【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman导读OpenHuman 是一个本地优先的个人 AI 项目面向 Mac / Windows / Linux其核心引擎用 Rust 实现支持深度研究、Agent 编排与记忆系统。本文聚焦仓库中src/openhuman/agent/orchestration模块——它是 Agent 与 Agent 之间协作的高层控制平面control plane负责父子 Agent 的血缘关系lineage、生命周期状态、等待/关闭/跟进wait/close/follow-up语义以及 UI/诊断事件。读完本文你将掌握编排层与执行引擎agent::harness的分工边界、spawn_subagent/spawn_parallel_agents等工具的调用契约、子 Agent 状态模型与终态词汇表、Codex 风格控制面spawn/wait/abort的落地形态以及当前进程内持久化设计与未来的落盘方向。一、定位控制平面与执行引擎的分层模块自述文档 开篇即明确了职责边界agent_orchestration是高层控制平面拥有父子 Agent 血缘、生命周期状态、等待/关闭/跟进语义以及 UI/诊断事件agent::harness是低层执行引擎负责 prompt 构造、策略过滤后的工具可见性、模型选择与子 Agent 循环sub-agent loops。这一分层在 mod.rs 的模块文档中进一步展开执行层面基于 TinyAgents图graph扇出——workflow_runs在图形引擎上调度阶段 DAGagent_teams通过条件路由图运行成员delegation接线可持久化的 plan→execute⇄review→finalize 图并行扇出走tinyagents_graph::parallel::map_reduce。而编排模块自身保留的是产品层持久的 SQL/JSON 运行台账run ledger、校验、取消语义、兼容事件以及 JSON-RPC/工具响应格式化。换句话说编排层只决定谁在什么时候跑、处于什么状态、如何等待与取消执行层才决定这个 Agent 具体怎么思考、能调哪些工具。这个边界是理解整个模块的关键。二、当前模块清单Current InventoryREADME 列出了当前可用的编排工具与执行通道组件职责agent_orchestration::tools::spawn_subagent运行一个类型化子 Agent返回折叠后的结果agent_orchestration::tools::spawn_parallel_agents扇出多个相互独立的类型化子 Agent 运行agent_orchestration::tools::spawn_worker_thread创建持久化的 worker-thread 转写transcriptagent::harness::subagent_runner类型化子 Agent 的规范执行路径agent::progress::AgentProgress::Subagent*与DomainEvent::Subagent*生命周期与子工具调用的遥测事件一个重要的限制在 README 中明确标注当前spawn_subagent工具拒绝dedicated_thread参数直到 worker UI 就绪为止。不过从源码看这一限制已在演进——spawn_subagent_tool_impl.rs 中的 schema 将dedicated_thread描述为Legacy compatibility flag当父上下文可用时委派现在总会创建持久化 worker 线程该参数不再决定线程的创建。三、控制面操作Codex 风格的多 Agent 控制README 明确指出编排层预期的规范操作canonical operations对标 Codex 风格的多 Agent 控制spawn_agent在 TinyAgents 的DetachedTaskRegistry中注册一个子 Agent并通过agent::harness::run_subagent运行它wait_agents等待一个或多个子 Agent 达到终态可带超时观察到终态的子 Agent 会被执行 wait 的调用方从注册表中剪除prunedabort_all向每个存活的子 Agent 发布cancelled状态并硬中止hard-abort其任务。这一设计在 ops.rs 中得到了完整实现。模块文档明确说明这个会话层曾经维护一套自研的进程内任务表HashMapString, AgentRecordJoinHandleNotify 手工终态清扫而 TinyAgents 的DetachedTaskRegistry是它的严格超集——自带状态 watch 通道、协作式取消令牌、硬中止句柄、按 owner 作用域的查找、wait/timeout 循环以及软上限终态清扫。因此spawn_agent/wait_agents/abort_all现在只是对register/wait/cancel_all的薄产品包装。源码中两个值得注意的常量ops.rsREGISTRY_SOFT_CAP: usize 256——每个会话存活子 Agent 的软上限只有表增长超过该值时才会清扫终态条目UNBOUNDED_WAIT_CHUNK: Duration Duration::from_secs(3600)——TinyAgents 的wait需要具体截止时间因此timeout_ms: None无限等待会按 1 小时为一段循环等待保持旧的永远等待契约。另外有一个行为后果值得使用者注意wait一旦观察到终态就会剪除条目因此一个子 Agent 只能被等待一次。仓库内所有调用方都是spawn 一次、wait 一次running_subagents也遵循同样的契约。曾经的内存镜像与持久化的替代者README 特别说明内存版的list_agents/message_agent/close_agent/follow_up/resume_agent/events镜像已被移除其持久化等价物位于command_center::control。这一点我们会在第六节展开。四、状态模型每个子 Agent 的稳定标识与终态词汇表README 定义了子 Agent 的状态模型每个子 Agent 具有稳定的orchestration_id、agent_id、可选的parent_agent_id、status、prompt、结果摘要、错误、时间戳与元数据。状态类型是 TinyAgents 的OrchestrationTaskStatus终态terminal values为completed、failed、cancelled、timed_out、abandoned。这个模型在 types.rs 中被序列化为可持久化的公共数据模型pub struct SpawnAgentRequest { pub agent_id: String, pub prompt: String, pub context: OptionString, // 可选上下文 pub toolkit: OptionString, // Composio 工具集 pub model: OptionString, // 本次 spawn 的模型覆盖 pub parent_agent_id: OptionString, pub metadata: BTreeMapString, String, } pub struct AgentSnapshot { pub orchestration_id: String, pub agent_id: String, pub parent_agent_id: OptionString, pub status: OrchestrationTaskStatus, pub prompt: String, pub result_summary: OptionString, pub error: OptionString, pub created_at: String, pub updated_at: String, pub metadata: BTreeMapString, String, }types.rs 的模块注释揭示了一个历史变迁编排层曾有一套宿主自有的AgentStatus拷贝控制平面迁移到 crate 的DetachedTaskRegistry后即被退役现在两套词汇表统一为 TinyAgents 的OrchestrationTaskStatus。pub use tinyagents_graph::orchestration::OrchestrationTaskStatus;这一行就是统一入口。在 tinyagents/orchestration.rs 中可以进一步看到这套状态词汇背后的运行时机制每个子任务在TaskStore中经历类型化的生命周期记账Pending → Running → Completed/Failed/Cancelled/…取代了早先自研状态枚举 watch 通道 tombstone 集合的临时方案DetachedTaskRegistry则负责进程内状态、取消、硬中止、所有权与转向steering机制。五、策略继承只加血缘与生命周期不扩大工具可见性README 对安全边界给出了明确要求策略继承被委托给agent::harness::run_subagent后者已经从父ParentExecutionContext派生子 Agent 的工具、模型路由、沙箱上下文、spawn 深度与进度。编排层只应添加血缘与生命周期语义绝不能扩大 harness 暴露给子 Agent 的工具可见性。这一约束在代码中体现为薄包装式设计AgentOrchestrationSession持有的ChildRegistry类型是DetachedTaskRegistryChildMetadata, ChildStateops.rsChildMetadata仅保留agent_id、parent_agent_id、prompt、时间戳、元数据与一个status_txwatch 发送端——没有任何工具列表字段。status_tx的设计细节值得展开它让abort_all能在 crate 硬中止任务之前先向正在wait_agents的并发等待方发布一个终态Cancelled。否则取消会直接丢弃 sender等待方看到的将是一个关闭的通道而不是一次取消。此外tinyagents/orchestration.rs 中的SteeringRunClass从另一个角度强化了安全边界Interactive用户实时聊天轮次只允许InjectMessage与协作式Pause其余全部拒绝Background分离的后台子 Agent 运行额外允许Resume、Cancel、Redirect——这是比硬AbortHandle取消更优雅、且只在安全循环边界生效每次模型调用前排空的替代方案。不在白名单内的转向命令会被 crate 以TinyAgentsError::Steering拒绝并中止运行。六、持久化进程内先行可序列化面向未来README 明确指出首个实现是进程内的process-local但状态形状是可序列化的因此后续 PR 可以在不改动调用方的前提下将编排会话持久化到应用重启、cron 恢复与线程延续thread continuation场景。当前持久化方向的最具体落地是command_center::controlcontrol.rs。它提供的四个可持久化控制动词直接对应被移除的内存镜像动词语义目标状态stop取消非终态运行cancelledretry重新排队以错误结束的运行failed/cancelled/interrupted→pendingcontinue回答awaiting_user运行使其恢复runningfollow_up记录跟进指令状态保持不变不变每个动词都是对持久化运行台账tinyagents_session::run_ledger的一次持久化状态迁移通过transition_agent_run_status写入新状态可清除error/completed_at这是 upsert 路径做不到的并追加一条run_event记录该动作进入运行时间线。允许的迁移矩阵由纯函数plan_transition定义并被无数据库的单元测试覆盖——例如stop对pending合法、对completed不合法这类规则全部可测试。与之配套的只读投影在 command_center/types.rs 中后台 Agent 命令中心把运行台账细粒度的AgentRunStatus归并为五个用户可见分组needs_input/working/completed/failed/stopped显示顺序把需要输入放在最前让阻塞中的工作最显眼AgentWorkRow则携带 run_id、kind、agent_id、bucket、父线程 id、worker 线程 id、摘要、错误、时间戳、耗时、token 消耗与费用USD等遥测字段。七、源码级深入两大核心工具的调用契约spawn_subagent单任务委派工具实现位于 spawn_subagent.rs 与其实现文件 spawn_subagent_tool_impl.rs。其语义是编排器或任何注册了该工具的父 Agent调用它把一个聚焦子任务交给专门化的子 Agent——查找全局AgentDefinitionRegistry中的定义、按定义过滤父工具注册表、构建窄化的系统 prompt、用父 Provider 跑内层工具循环最后把子 Agent 的循环历史折叠成单段文本结果作为普通tool_result返回给父 Agent。参数 schema 要点均可从源码确认参数说明agent_id必填。子 Agent idschema 从全局注册表动态生成枚举archetype是已弃用的向后兼容别名prompt必填。子 Agent 对父对话无记忆需包含其行动所需的全部上下文context可选。此前任务结果的上下文块渲染为 prompt 前的[Context]段model可选。仅本次 spawn 生效的精确模型 id保留父 Provider/路由但固定子模型toolkit可选。Composio 工具集 slug如gmail、notion、slack当agent_id integrations_agent时必填用于收窄子 Agent 可见的 Composio 动作blocking默认false传true则内联运行并直接返回子 Agent 最终输出task_key可选。可复用异步委派的确定性标识键默认取归一化的 prompt/标题fresh传true时绕过可复用子 Agent 匹配创建全新持久 worker工具的description还包含一条重要的使用纪律不要在循环里反复调用spawn_subagent来扇出——每次调用只委派单个任务、不会并发启动 worker会把整个请求串行化要并发请用spawn_parallel_agents一次调用启动多个 worker。工具对失败的分类也值得借鉴classify_subagent_failure当错误消息包含 no healthy upstream、upstream_unhealthy、provider call failed: all providers/models failed 等特征时会明确标注为上游推理不可用LLM Provider 故障/容量问题而非集成认证问题并建议避免立即重试。spawn_parallel_agents并发扇出spawn_parallel_agents.rs 实现并发扇出schema 要求tasks数组minItems: 2每个任务包含任务字段说明agent_id/prompt必填同上context/toolkit可选同上ownership可选。该 worker 的互斥文件/模块/职责边界isolationnone默认共享工作区或worktree为可编辑 worker 提供独立 git worktree 检出避免并行编辑冲突base_ref仅isolation worktree时使用head默认从当前 HEAD 分叉或fresh从仓库默认分支分叉核心规则只读与 worktree 隔离的 worker 可并行共享工作区且带写能力工具的 worker 要求互斥files:所有权否则走串行回退。该工具还绕过了全局的逐工具墙钟截止时间这是长时间并行研究任务的设计选择并通过spawn_parallel_graph实现了带取消与工作区所有权边界with_ownership_boundary的图执行。后台运行与转向running_subagents与spawn_worker_threadrunning_subagents.rs 记录了在飞in-flight异步子 Agent 的注册表每个异步子 Agent 在 TinyAgents 的DetachedTaskRegistry中以task_id为键注册并携带ArcRunQueue——转向通道使steer_subagent能在没有 crate 原生转向句柄时注入消息TinyAgentsSteeringHandle——子运行激活期间注册到进程内SteeringRegistrywatch::ReceiverSubagentStatus——使wait_subagent能阻塞到子 Agent 达到终态AbortHandle——供subagent_cancel/close_subagent停止分离工作。同时每个分离子 Agent 还会作为OrchestrationTaskKind::SubAgent写入进程级 TinyAgentsTaskStorePending → Running随后镜像为Completed/Failed/Awaiting取消路径记录Cancelled提供类型化、可查询的生命周期记录task_records。spawn_worker_thread的实现spawn_subagent.rs 中的persist_worker_thread会把 prompt 折叠为线程标题上限WORKER_THREAD_TITLE_MAX_CHARS 80与 UI 线程列表的可见字符上限保持一致创建带tasks标签的持久线程并写入用户消息。八、面向未来声明式工作流与多 Agent 团队编排目录下还有两块面向长期演进的模块值得关注workflow_runstypes.rs声明式的WorkflowDefinition阶段图——每个阶段命名要扇出的 Agent 与其依赖的阶段运行器按依赖顺序以有界并发调度WorkflowSafetyTierread_only/standard/edit_capable决定子 Agent 权限当前仅read_only先行落地可编辑层级等待引擎落地后以显式用户批准为门槛。保持声明式是为了规避任意进程内脚本执行带来的安全面。agent_teams通过条件路由图运行团队成员并提供注册控制器 schemaall_agent_team_controller_schemas等。subagent_sessions/parent_context子 Agent 会话存储与父执行上下文构造builder.rs是策略继承与血缘追踪的基础设施。README 还指出了进一步的上游迁移方向running_subagents将更多分离子 Agent 生命周期移植到 TinyAgents 任务存储这一工作跟踪于docs/tinyagents-migration-plan-2026-07-22.md的 WP-5。小结OpenHuman 的agent_orchestration模块展示了一条清晰的分层演进路线把编排与执行彻底分离把进程内自研机制逐步收敛到 TinyAgents 的类型化原语之上。当前形态下开发者可以依赖的稳定接口包括spawn_subagent单任务委派参数 schema 动态生成、spawn_parallel_agents带所有权/隔离语义的并发扇出、wait/cancel语义终态剪除、一次等待、五个终态词汇completed/failed/cancelled/timed_out/abandoned以及通过command_center::control提供的四个持久化控制动词stop / retry / continue / follow_up。无论未来是否引入跨重启持久化可序列化的AgentSnapshot状态形状都保证了调用方无需改动即可平滑迁移。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考