多 Agent 的边界——为什么只保留任务作用域内的 Subagent

角色可以配置，任务必须有唯一的生命周期真相源。

多 Agent 最容易犯的错误，是先画出 Planner、Developer、Tester、Reviewer 的组织图， 再寻找这些角色能解决的问题。看起来很专业，运行时却很快出现第二套任务状态、第二套权限、 第二套重试和取消、难以解释的消息同步，以及高昂但无法证明有效的模型调用。

Kairo 曾经实现过独立的 Team 与 Expert Team 运行时。真实产品迭代给出的结论更简单：

• 独立上下文有价值：搜索、调查和并行实现不会污染父 Agent 的主上下文。
• 有界权限有价值：子 Agent 可以继承父权限并进一步收窄工具与沙箱。
• 不同推理强度可能有价值：便宜的探索与高风险验收可以使用不同预算。
• 固定专家组织没有稳定收益：角色名不能替代明确任务和验收条件。
• 验证有价值，但它属于验收策略：Reviewer 不是必须长期存在的“团队成员”。

因此，Kairo 在公开发布前删除 Team 对象、固定 Expert 枚举、专用 Coordinator、消息总线、 独立 Starter 和脱离父任务的 spawn 工具，只保留一套任务作用域内的协作模型。

Codex 实际采用的模型

Codex 的公开设计与这个结论一致。它提供 default、worker、explorer 等内置 Subagent 角色，也允许配置自定义角色；每个 Subagent 在独立 Agent Thread 中运行，并可配置模型、 推理强度、沙箱、MCP Server 与技能。权限从父会话继承，子 Agent 可以进一步收窄。

关键点是：这些角色是运行配置，不是第二套 Team 执行引擎。 父 Agent 仍负责拆解、 委派、等待、引导与合并。公开配置中也没有“验证调用”这一角色字段；是否调用另一个模型 复核，是父任务根据风险和证据执行的验收决策。

这意味着角色分工不是完全没必要，而是应该被降级为轻量、可选、无状态的 Profile。

四个正交概念

Kairo 将协作收敛为四个概念：

概念	回答的问题	是否持有生命周期
Agent Profile	这个调用可使用哪些指令、工具、模型、推理预算和沙箱？	否
Assignment	这次具体要做什么，作用于哪些根目录，风险和验收条件是什么？	否
Agent Thread	这次独立调用的上下文、流式事件、取消和结果在哪里？	是，但归父任务所有
Acceptance Policy	什么证据足以接收结果，是否需要独立模型复核？	否，由父任务执行

Profile 不能携带任务状态；同一个 worker 可以被不同父任务并发复用。Assignment 不能用 “你是测试专家”代替目标，它必须包含明确交付物和验收标准。Agent Thread 是一次真实执行， 而 Acceptance Policy 在执行结束后基于宿主观测到的 diff、路径、工具结果与测试证据作判断。

权威生命周期

Parent Task
  ├─ 判断是否值得委派
  ├─ 创建 Assignment + 选择 Profile
  ├─ 启动独立 Agent Thread
  ├─ 转发用户中途引导 / Stop
  ├─ 捕获真实 diff、工具结果与验证命令
  ├─ 按风险执行 Acceptance Policy
  └─ 接收、要求修订或拒绝结果

这里只有 Parent Task 是终态的唯一 owner。所谓“协作面板”只是这些 Assignment 和 Agent Thread 的投影，不能自行改变状态。这样 CLI、Web、Desktop、恢复逻辑和持久化看到的是同一 份事实，不会出现 Team 已完成但 Session 仍运行、子 Agent 已取消但消息总线继续投递等分裂。

角色配置的真正价值

1. 独立上下文：核心价值

探索大型仓库、读取大量日志或比较多个方案时，隔离上下文能显著降低主对话噪声。子 Agent 只返回有界摘要和证据，父 Agent 保留用户意图、关键决策和最终责任。这是使用 Subagent 最 稳定的收益，也是即便只有一个模型仍然成立的理由。

2. 工具与权限：安全上限

Profile 可以声明只读、工作区写入或更小工具白名单，但它只能在父任务权限内继续收窄：

effective permission = parent live policy ∩ assignment roots ∩ profile ceiling

子 Agent 不能通过选择一个“高级角色”扩大权限。权限在委派时以原子快照传递，具体工作区 根目录仍由 Assignment 控制。

3. 模型与推理强度：可选优化

只有一个模型完全没有问题。默认做法应当是继承父模型与推理强度；当真实评测证明更便宜的 探索模型或更强的验收模型能改善成本/质量时，再为 Profile 覆盖。多模型路由是优化项，不是 多 Agent 成立的前提。

4. 验证调用：验收而非角色

测试、静态检查和独立模型复核都属于 Acceptance Policy。D1 只读调查通常不需要第二模型； D2 有界写入需要真实 diff 和聚焦测试；D3 认证、迁移、密钥、发布或基础设施变更不能由子 Agent 自己声明通过，必须有独立复核与宿主观测证据。

将 Reviewer 固定为团队成员会造成两个问题：低风险任务浪费一次调用，高风险任务又可能只 复述子 Agent 的自我报告。验收策略可以根据执行后的真实路径和失败工具调用升级风险，角色 名做不到这一点。

为什么删除 Team 与 Experts

旧设计的问题不是代码质量，而是概念重叠：

1. Team 与 Task 同时持有状态，终态、取消、恢复和重试会产生双写。
2. Expert 与 Profile 重复，固定 Planner/Generator/Evaluator 把工作流写死在类型系统中。
3. MessageBus 与父任务事件流重复，增加排序、背压、重放和清理语义。
4. Coordinator 与父 Agent 重复，两者都在拆解、调度、等待和合并。
5. 验证与角色绑定，无法根据实际变更风险决定验证强度。
6. UI 暴露内部组织图，用户真正关心的进度、产出、风险和可操作性反而被淹没。

删掉这些抽象并没有删掉并行、协作或专业能力。专业知识放进 Skill；执行上限放进 Profile； 具体职责放进 Assignment；独立上下文放进 Agent Thread；质量门禁放进 Acceptance Policy。

什么时候值得委派

满足至少一项时才值得创建 Subagent：

• 子任务可以独立完成，并能用清晰证据验收；
• 探索会消耗大量上下文，但只需把摘要带回主任务；
• 多个无共享写入面的调查可以并行；
• 高风险结果需要独立上下文进行复核；
• 用户明确要求并行或独立审查。

以下情况通常应由父 Agent 直接完成：

• 一两次工具调用即可完成的小任务；
• 子任务需要持续读取父 Agent 尚未稳定的隐含判断；
• 多个 Agent 会同时修改同一文件或同一外部资源；
• 无法定义产出、边界或验收证据；
• 委派成本高于被隔离的上下文成本。

产品与可观测性

前端应该展示用户可行动的事实：Assignment 目标、Profile、当前阶段、是否可引导/停止、 变更文件、测试证据、风险与验收结论。默认不展示“团队拓扑”或 Agent 之间的闲聊。

运行时应至少观测：委派接受到开始的等待时间、首次活动、持续时间、取消原因、上下文与 token 成本、变更冲突、验证升级、修订轮数和最终验收结果。只有真实评测证明并行委派提高了 端到端质量或延迟，才应扩大默认委派范围。

结论

角色分工有必要，但只应作为 Profile 级约束；独立上下文是主要收益，工具权限是安全 边界，推理强度是可选优化，验证调用是风险驱动的验收策略。Kairo 不再维护 Experts 或 Team 作为独立产品概念，所有协作统一落在 Task/Subagent/Agent Thread 上。

架构契约与删除范围见 ADR-031：Task-Scoped Agent Collaboration。 Codex 的公开行为可参考 Multi-agent 与 Configuration reference。