Subagent Control Plane

导言

单个 Codex 或 Claude Code 窗口的问题，不只是“subagent 开得少”，而是人无法稳定回答四个问题：派了谁、做到哪、交了什么、谁验收。调研后的结论是：AutoResearch 已经拥有最重也最重要的持久控制面；下一步不应重写一个多智能体平台，而应补齐人工 UAT，把 Archon 限定为可选的阶段工作流，把 Pi、Codex 和 Claude 作为可替换 worker。

Subagent 控制面不是增加更多 Agent — 真正的控制面需要同时暴露派工、阶段、交付和验收，而不是只显示“正在运行”。

先给结论¶

Pi 不重，但它不是控制面；Archon 不算重，但不应成为第二事实源；AutoResearch Phase 16 已经是控制面。 推荐的边界是：

Phase 16 保持唯一事实源：负责任务状态、事件、证据、检查点、副作用账本和恢复。
Archon 作为可选复合 worker：只在一个有边界的阶段内部运行 YAML 工作流，输出结构化交付件，再由 Phase 16 验收。
Pi、Codex、Claude 作为 worker backend：按成本、模型能力和工具需求选择，不让 provider 决定流程语义。
Claude Agent Teams 只用于临时并行：适合研究、审查和调试，不承担跨会话的实验真相。

因此，现在再开发一套新的调度平台是重的；把现有三层接起来并不重。按当前资产估计，Archon 小范围试点是数天量级，Pi worker adapter 也是数天量级；重写任务、证据、恢复和 UI 则会重新进入数周到数月的工程。

先验收，再升级

本机 AutoResearch 的 Phase 16 自动验证已经记录为 9/9 完成，但人工 UAT 仍是 0/8。本机 Archon 为 v0.4.1，且调研时 8088 服务未启动；官方仓库在 2026-07-20 已发布 v0.6.0。在升级 Archon 或接 Pi 前，应先完成 Phase 16 的 8 项人工验收，避免同时改变控制面、UI 和 provider。

现有系统¶

AutoResearch 不是“还缺一个多智能体框架”的空白项目。按已提交版本 89fc92d 审计，它已经具备：

固定生命周期：ENV_PREP → CODE_MODIFY → TASK_RUN → RESULT_ARCHIVE → CODE_ARCHIVE → NEXT_ANALYSIS。
fresh worker：阶段执行使用独立上下文，降低长会话污染。
独立 verifier：worker 不能自行宣布完成，只有 verifier 的 PASS 才推进状态。
持久事实：Event、Evidence、Checkpoint 和 Effect Ledger 支持重放、恢复与幂等。
只读投影：Task Board 通过 API 和 SSE 呈现状态，界面不是事实源。

一次离线 hermetic success demo 在 0.844 s 内产生 73 个事件、18 条证据和 6 次 verifier PASS，物理 submit 恰好一次。这说明“调度—执行—验证—证据”的主骨架已经闭环，真正未闭环的是人工可理解性与人工验收。

AutoResearch Subagent Control Plane — 基于 AutoResearch 已提交代码绘制的 Phase 16 控制面。图中没有把尚未接入的 Pi 或 Archon 画成现状。

工具分层¶

方案	它真正解决什么	没有解决什么	采用判断
Pi	轻量 coding harness、stateful agent runtime、模型 provider、TypeScript SDK、JSONL RPC 与事件流	持久任务板、跨进程恢复、证据真相、组织级审批	适合做 worker；不单独做控制面
Archon 0.6	YAML DAG、并行拓扑层、条件、循环、审批、恢复、typed artifacts、Web 执行视图	AutoResearch 的实验生命周期和证据语义	适合做有边界的复合阶段
Claude Agent Teams	一个 lead 管理多个独立上下文，终端内可看 teammate 与任务	跨会话恢复、稳定的持久账本；功能仍是实验性	适合一次性研究、审查、调试
Phase 16 / LangGraph	生命周期、worker/verifier 分离、事件、证据、检查点、幂等和 Task Board	provider 生态和通用可视化工作流编辑	继续作为唯一控制面
再造平台	所有语义都可自定义	重复状态机、恢复、权限、UI 和运维成本	当前不做

Pi 官方文档把它定义为可扩展 coding agent harness，并公开 SDK、RPC 与会话事件；它默认也不提供内建权限系统，生产接入仍需要容器、沙箱或受控工具面。Archon 官方工作流文档则更接近 harness builder：节点可形成 DAG，同一拓扑层可并行，审批与 typed artifact 都有明确协议。

但 Archon 的 provider 能力并不完全等价：截至 v0.6.0，Pi 节点不能使用 MCP，agents: 内联 subagent 仍是 Claude 专属；Pi 的结构化输出校验也属于 prompt 修复路径，而不是所有 provider 都具备同等 SDK 约束。因此必须用我们自己的任务与证据契约兜底，不能把 provider 特性当成控制面保证。

多智能体边界¶

MAST 多智能体失败分类 — MAST 对 1,642 条执行轨迹归纳出 14 类失败；系统设计、智能体间错位和任务验证分别占 44.2%、32.3% 和 23.5%。来源：Why Do Multi-Agent LLM Systems Fail? Figure 1。

这组结果说明，增加 agent 并不会自动增加能力。失败往往来自错误的流程结构、不同 agent 对目标理解不一致，以及缺失独立验证。下图给出的 41%–86.7% 是论文在不同系统和不同 benchmark 上观察到的失败率，不能横向当作系统排行榜，但足以说明多智能体需要工程化约束。

多智能体系统失败率证据 — 论文 Figure 5 的原始证据裁剪。不同柱对应的任务与基准不同，只用于说明失败普遍存在。

另一项覆盖 180 个配置的研究发现，协作收益高度依赖任务结构：并行、可分解任务可能受益，而工具密集或顺序推理任务会被协调开销反噬；集中式编排的错误放大也明显低于彼此独立的 agent。其工程含义不是“永远少用 agent”，而是：先证明任务可分解，再并行；先定义聚合与验证，再派工。¹

目标架构¶

推荐把 Archon 放在 Phase 16 的 worker 边界内，而不是与它并列：

Phase 16 创建阶段任务，并写入 task_id、目标、预算、允许工具、交付路径和验收规则。
简单任务直接交给 Pi、Codex 或 Claude worker；复杂且可分解的任务交给 Archon composite worker。
Archon 内部可以执行 research → design → implement → review，但只能返回 typed artifacts 和事件摘要，不能直接推进 Phase 16 状态。
独立 verifier 按证据验收；失败时生成可恢复的 remediation task，而不是让原 worker 无限自我反思。
Task Board 只读取持久事件，并明确显示 active、waiting、blocked、verifying 和 done。

这能补足“AI 流程阶段不足”，又避免把主状态机扩成几十个 agent 角色。阶段是状态，角色是执行策略，二者不应混为一谈。

落地顺序¶

P0：完成现有闭环¶

完成 Phase 16 的 8 项人工 UAT，重点检查页面能否回答四个核心问题。
为每个任务卡固定显示：owner/provider、当前 state、最近事件、artifact/evidence、verifier、阻塞原因。
把 waiting、blocked 和 failed 分开；没有事件不等于仍在运行。

P1：单一试点¶

在独立分支或 worktree 升级 Archon 0.4.1 → 0.6.x，不触碰 Phase 16 的状态语义。
选一个只读研究任务做 composite worker，例如 research → compare → independent review → report。
强制每个节点声明 output_type、文件路径和验收规则；最终只向 Phase 16 提交一个结果包。

P2：provider 适配¶

接入 Pi SDK/RPC 作为 headless worker，保留原始事件流和 session id。
根据 MCP、结构化输出和权限需求选择 provider；需要 MCP 的任务不要路由到 Pi 节点。
对副作用工具增加 allowlist、预算和幂等键，不依赖 Pi 默认权限。

最小任务契约

以后要求主 agent 使用 subagent 时，不要只写“多开几个 agent”，至少固定以下字段：

task_id:
objective:
owner_role:
allowed_tools:
input_refs:
deliverables:
acceptance_checks:
budget_and_deadline:
blocked_protocol:
independent_verifier:

主 agent 必须先发布 task board，再派工；每个 subagent 只能用交付件和证据宣告完成；最终状态由独立 verifier 写入。

总结¶

当前缺口不是 agent 数量，而是可见性、任务契约、事实持久化和独立验收。AutoResearch 已经完成了难开发的底座，因此最稳妥的路线是先验收 Phase 16，再把 Archon 当成有限工作流，把 Pi 当成轻量 worker。这样既不会太重，也能逐步获得更频繁、更可感知、交付边界更清楚的 subagent 协作。

参考文献¶

Towards a Science of Scaling Agent Systems ↩