跨 harness 对比：Router / 编排（任务分解、多 agent、子 agent）
总览：一个词混着三件正交的事
通读 61 个 harness 后，最重要的一个澄清是：「Router / 编排」这个标题其实压着三个互不相干的问题，各家在不同问题上落子，硬拉到一起对比很容易张冠李戴，先拆开：
- 任务分解与多 agent——主 agent 要不要、以及怎样把一个大任务拆给多个 agent。这是本维度主线。
- 模型路由——每个回合实际用哪个模型（不是拆任务，而是「这一步派哪个模型上」）。Augment 的 Prism、Gemini CLI 的 classifier、Kiro / Copilot 的 Auto、v0 的 Quick Edit、claude-flow 的 Q-learning router 都在这一支，与任务分解是两回事。
- 跨 harness 编排（harness 套 harness）——把别的 agent 运行时（Claude Code、Codex、Gemini CLI）当可委派的执行后端，一般走 ACP / MCP / A2A 开放协议。这是一条独立的互操作轴。
在任务分解主线上，最能区分谱系的问题是**「分解逻辑写在哪里、由谁做决定」**，可分四大流派：
- 写在 prompt 里、由 LLM 即兴涌现——绝大多数编码 harness 走这条路：子 agent 被建模成一个普通工具（Claude Code 的
Task/AgentTool），主模型自己决定何时调用、拆几个、拆什么，没有独立 planner 组件。Claude Code 是原型，几乎所有后来者复刻。 - 写在代码里、确定性执行——图 / DSL / 状态机驱动：LangGraph 的
Send/Command原语、CrewAI 的 Flow DSL、AutoGPT Platform 的 Block DAG、Agno 的 Workflow、Google ADK 的 Workflow 图、Semantic Kernel 的 Process Framework、Letta 的 Tool Rules DSL，以及新近的 Dynamic Workflow（Qoder / MiMo / Qwen Code 让主 agent 生成一段 JS 脚本、在沙箱里确定性agent()/parallel()/pipeline()）。 - 有一个显式的编排者角色——orchestrator-workers 模式：Anthropic 的 LeadResearcher 是这个模式的定义者和命名来源，Devin 的 map-reduce-and-manage、MetaGPT 的 TeamLeader、Comate 的 Architect、GPT-Pilot 的 ~20 角色 FSM、CAMEL 的 Workforce Coordinator、AutoClaw 的 Cluster Mode 都是它的具体化。
- 不做任务分解，改用同架构多候选选优（best-of-N）——SWE-agent 的 RetryAgent/Reviewer/Chooser、Trae 论文层的「生成→剪枝→选择」ensemble，把算力花在采样维度而非分工维度。
一个反复出现的共识：几乎没有 harness 用独立的、脱离 LLM 的 planner 做任务分解。即便编排能力最强的那几家，「拆成什么子任务」这一步仍交给 LLM，代码只负责调度、隔离、汇总。真正的例外是走确定性图 / DSL 的那一类（LangGraph 系），以及 Devin Agentic MapReduce 里的 Shard 阶段（Tree-sitter / 编译器查询做确定性分片，循环中不涉及模型）与 AutoGen MagenticOne 的 Task Ledger（结构化台账 + 停滞检测重规划）。
还有一个正交的语义分野值得单列：控制权怎么流动——是 handoff（转移后不回来，OpenAI Agents SDK / AutoGen Swarm / ADK transfer），还是 delegation / agent-as-tool（调用完控制权回到主 agent，smolagents / Pydantic-AI 及所有 Task-tool 系），还是 supervisor / 星形 hub-and-spoke（成员只对 leader 汇报，MetaGPT 强制走 TeamLeader、AgentScope 硬编码星形拓扑、Anthropic LeadResearcher 绝不把汇总下放）。
对比表
只列该维度真有实质内容的 harness。「递归深度」列 1 表示只允许一层子 agent（父→子，子不能再 spawn）。
| harness | 主要编排机制 | 子 agent 上下文 | 递归深度 | 独立 planner | 跨 harness / 远程 |
|---|---|---|---|---|---|
| Claude Code | Task/AgentTool；内置 general-purpose/explore/plan/verification；Teams | 隔离独立窗口 | 未见硬深度守卫 | 无（涌现） | worktree/remote(CCR) 隔离 |
| Codex CLI | multi_agents_v2 spawn_agent；agent_jobs CSV fan-out | 继承父级实际沙箱 | max_depth 默认 1 | 无 | — |
| Gemini CLI | 子 agent 作 function-call 工具；classifier 模型路由 | 隔离，私有 memory inbox | 递归保护（子看不到子） | 无 | A2A 远程 agent |
| opencode | task 工具；build/plan/explore/compaction agent | 真子 Session，parentID | 强制拒绝 task 递归 | 无 | — |
| Kilo Code | fork opencode；task 工具 + 追加 orchestrator/debug/ask 模式 | 子 Session，权限成本继承 | 禁子再开子 | 无 | 云端 Gas Town（私仓） |
| MiMo | fork opencode；actor(run/spawn/send) + Orchestrator peer + Dynamic Workflow | 独立 agentID 切片/worktree | — | Workflow(QuickJS) | — |
| deepagents | task 工具（明说 CC 风格）；Async 后台变体 | 临时无状态，剥离父 state | 由 subagent 声明 | 无 | LangGraph Platform |
| Factory | Custom Droids（Task）；Missions + Mission Control | fresh 窗口隔离 | — | Missions 协作规划 | 导入 CC subagent |
| Amp | Task；命名 Oracle/Librarian/Painter；createAgent API | 隔离，不继承，只回摘要 | 子间不能通信 | 无 | Orbs 远程机 |
| Qoder | 三套：Subagents + Dynamic Workflow(JS) + Cloud coordinator | 隔离/worktree | Agent() 语法限制委派 | Workflow 脚本 | A2A Agent Card |
| Kimi Code | subagent-host；AgentSwarm（一次扇 128 个） | DenyAll 策略叠加 | — | Plan Mode（受限） | — |
| Qwen Code | subagent（逆向 CC 2.1.168）+ Agent Teams + Workflow | 独立 worktree/权限/模型 | frontmatter maxTurns | Workflow orchestrator | — |
| OpenHands | delegate 工具 + 子 agent 注册表（.md frontmatter） | 独立 LocalConversation | max_children 默认 5 | 无 | ACP（宿主外部 agent） |
| goose | summon 扩展 delegate/load；sync/async 后台任务 | 独立 Agent 实例 | 禁子再 spawn | 无 | MCP subagent + ACP |
| QwenPaw | Multi-Agent Workspace + spawn_subagent(fork/worktree) + Mission Mode | 独立 workspace / worktree | 一次性不可恢复 | Mission 先 PRD 后执行 | ACP（可编排 CC/Codex） |
| Cline | spawn_agent（只读子 agent）+ Teams（peer 协调） | 仅当前 session 内 | 不允许嵌套 spawn | 无 | 团队状态持久化跨 CLI |
| Roo Code | Orchestrator/Boomerang：new_task 派生子 Task | 独立历史，不继承父上下文 | 未见显式深度守卫 | Orchestrator（空工具集） | — |
| Cursor | 内置 Explore/Bash/Browser 子 agent；文档化 Planner→Impl→Verifier | 独立 transcript 文件 | — | Orchestrator 模式 | 研究原型：千级并行 |
| Junie | .junie/agents/*.md 自动委派；code-review 专用子 agent | 隔离 | — | 无（Plan 是单 agent 两阶段） | 一引擎多 surface |
| Kiro | context-gathering / general-purpose 子 agent；Spec 任务 DAG wave 调度 | 独立窗口 | — | 自主 agent：research/code/verify | ACP + Auto 模型路由 |
| Warp | 父/子严格一层；持久服务端 mailbox；命名编排模式库 | 全局序列号保序 | 一层深 | /plan 内联编排 | 5 种 harness 类型可混编 |
| Zed | spawn_agent（不继承父历史）+ ACP 外部 agent | 独立线程，只回最终消息 | — | 无 | ACP（CC/Gemini/Codex/Cursor） |
| Copilot | 自定义 agent（infer 意图匹配）；Fleet mode（SQL todos 协调） | 受限工具集隔离 | — | 无 | Auto 模型 + Rubber Duck 互评 |
| Amazon Q | Legacy Delegate（子进程）+ 新 crate SpawnSubagent（进程内） | .amazonq/.subagents JSON | 一次一个命名 agent | 无 | — |
| Augment | 内建 research/plan/code/validate/context-gathering + Cosmos Worker/Expert | 独立窗口，分级模型 | — | Prism 回合前规划器（模型路由） | Expert-to-Expert 事件协作 |
| Continue | Subagent 工具（默认关闭 beta）；同进程递归主循环 | 临时禁用历史隔离父子 | 扁平一层 | 无 | — |
| Devin | Managed Devins 协调者 + Agentic MapReduce（Plan/Shard/Map/Reduce/Verify） | 独立 VM，不共享上下文 | map-reduce-and-manage | Shard 阶段确定性（非 LLM） | Smart Friend 跨模型委派 |
| Replit | Agent 4：自动拆任务 + 并行子 agent + 冲突解决子 agent；Kanban 调度 | 计划进/摘要出边界 | — | Plan/Build/Edit 状态机 | — |
| MetaGPT | MGXEnv 强制走 TeamLeader（hub-and-spoke）；pub/sub 消息总线 | 角色订阅过滤 | — | 共享 Planner/plan-task | — |
| GPT-Pilot | ~20 专职 agent 由 FSM 编排；epics→tasks→steps→iterations | 各 agent 自持 | CodeMonkey 同类型 fan-out | TechLead/Developer 分解 | — |
| OpenManus | PlanningFlow：一次性 LLM 生计划 + [TYPE] 标签路由 agent | 嵌套完整 agent loop | 无重规划 | PlanningTool 一次生成 | A2A server |
| GPT-Researcher | 三层：子查询分解 + 递归树 fork 实例 + LangGraph 多 agent | 子 GPTResearcher 实例 | 递归深研 | Editor 规划 sections | 条件路由真 router |
| DeerFlow | DECOMPOSE→DELEGATE→SYNTHESIZE；task 工具；SubagentLimitMiddleware | 独立图/ThreadState/trace | ≤N 并发（默认 3） | 无（lead prompt 驱动） | ACP 外部 agent |
| Anthropic | LeadResearcher orchestrator-workers + CitationAgent | 各子独立上下文窗口 | 汇总绝不下放 | 分类法（深/广/直接） | — |
| CrewAI | sequential/hierarchical(Manager)；Flow DSL；A2A | 任务 context 拼接 | — | hierarchical Manager | A2A 远程 agent |
| CAMEL | RolePlaying（论文原型）+ Workforce（Coordinator/Planner/动态 worker，DAG） | 可选 share_memory | 嵌套 Workforce 套娃 | Task Planner Agent | — |
| AutoGen | RoundRobin/Selector/Swarm/MagenticOne（GroupChatManager） | actor pub/sub 运行时 | — | MagenticOne Task Ledger | — |
| Semantic Kernel | Magentic（移植 AutoGen）/Handoff/GroupChat/Concurrent/Sequential + Process | actor 运行时 | — | Process Framework（图） | Dapr 分布式运行时 |
| LangGraph | Send/Command(goto,graph=PARENT) 原语；子图组合；条件边 | 子图 checkpointer 继承 | 子图任意嵌套 | 无内置 supervisor | — |
| Google ADK | transfer 软路由 + Sequential/Parallel/Loop agent + 2.0 Workflow 图 + agent-as-tool | 按方向规则转移 | 图动态 fan-out | Workflow DAG 调度器 | — |
| OpenAI Agents SDK | Handoffs（接管）+ agents-as-tool（返回）；托管多 agent(beta) | handoff input 可过滤 | 嵌套 | 无 | — |
| Pydantic-AI | 5 级谱系：delegation / hand-off / graph / Deep Agents | 无状态全局 agent | 第三方 subagents 嵌套 | pydantic_graph | subagent fallback 模型 |
| smolagents | 受管 agent 当可调用工具；两层树 | 记忆隔离（刻意） | 两层，无深递归 | 仅单 agent PlanningStep | — |
| Agno | Team（LLM 自主 delegate）vs Workflow（DAG 写死，CEL Router） | member 可嵌套 Team | — | Workflow 图 | — |
| AgentScope | 服务层星形团队工具（TeamCreate/AgentCreate/TeamSay）；库层单 ReAct | 星形硬约束只报 leader | — | 库层 TODO 单 agent | MessageBus（内存/Redis） |
| Letta | 多 agent groups(round_robin/supervisor/dynamic/sleeptime) + Tool Rules DSL | groups 共享 | — | Tool Rules 状态机 | — |
| Agent Zero | call_subordinate 递归子 agent（理论无限深）+ profile 化 | 子跑完整 loop | 无限深 | 无 | orchestrator 插件驱动外部 CLI |
| Plandex | 两段式 architect/planner→implementer，单线程顺序 turn | 同一 plan 内 | 无子 agent | planner 出编号子任务 | — |
| Aider | Architect/Editor 两步流水线；/ask//code 模式切换 | 第二个 Coder 实例 | 无子 agent | architect 提案 editor 落地 | — |
| claude-flow | Q-learning agent router（落盘）+ 3-tier model router；agent_spawn 只写 metadata | 委派给 CC 执行 | — | Q-learning + neural pick | 委派 Claude Code Task |
| Open Interpreter | Codex 底座 multi_agents_v2；额外 harness 路由(WireApi×Harness 映射) | 继承 turn config + role | max_depth | plan.rs TodoList | harness 仿真路由 |
| browser-use | 单 agent + prompt 内 plan_update todo | — | — | 无 | 多 agent 仅在 Cloud |
| UI-TARS | 单 agent 多 environment 路由（<environment> 标签分派 code/mcp/gui） | 同一模型自切环境 | — | 无 | — |
| AutoGPT | Classic ExecutionContext（ResourceBudget/辩论）；Platform Block DAG | .sub_agents 子根隔离 | max_depth 默认 5 | 图拓扑 + 递归 block | 参考 ADK + Anthropic 设计 |
| SWE-agent | RetryAgent 重试选优；ActionSampler 单步集成；Chooser | 无子 agent（尝试级并行） | — | 无（best-of-N） | — |
| Trae | CLI 单 agent；论文层生成→剪枝(tester)→选择(selector 多数投票) | 论文 ensemble（未落 CLI） | — | 无 | 混用 3 LLM 增多样性 |
| Hermes | delegate_task + async；MoA（8 参考模型并发顾问） | 独立 subagent_id | MAX_DEPTH 默认 1 | 无（LLM 驱动） | — |
| Comate | Architect（纯路由，仅调 agent）→ Deep Read/Actor 子 agent | 隔离 | — | Plan agent 出 plan.md | 自定义 agent 可注册为子 |
| AutoClaw | Cluster Mode 运行时多角色（案例 2~18 角色，含独立审核） | 未披露映射 | 按可分解度动态 | 强制 SOP 分阶段 | — |
未列入（该维度无实质内容 / 明确未实现）：CodeGeeX（单 agent，grep 零命中多 agent）、v0（单 agent + 组合式管线，只有 Quick Edit 模型路由）。
分组讨论
1. Task 工具系：Claude Code 定义、被集体复刻的「子 agent = 一个普通工具」
这是编码 harness 的绝对主流。Claude Code 的 AgentTool（即 Task 工具）是原型：输入 description/prompt/subagent_type/model/run_in_background，子 agent 拿到隔离的独立上下文窗口，主 agent 只看到最终摘要，任务分解完全「涌现」——没有独立 planner，模型自己决定拆几个、拆什么。内置 general-purpose / explore / plan / verification 四类子 agent，几乎成了业界的默认清单。
后来者的复刻证据链非常清晰：
- deepagents 的
task工具提示「与 Claude Code 的 Task 工具提示风格如出一辙」（dossier 原话），并把「何时并行调用子 agent」直接写进 few-shot 描述。 - Qwen Code 的子 agent frontmatter schema 是对 Claude Code 2.1.168 原生二进制做
strings逆向工程得到的——这是全 61 个里借鉴证据最直接的一条，连 deferred 未实现字段（effort/memory/isolation）都照抄了 CC 的字段名。 - Factory 直接支持导入
~/.claude/agents/的定义，把 CC 工具名/模型族重映射成自己的 Custom Droid。 - opencode 是这一系里自成一派的实现（真子
Session+parentID，deriveSubagentSessionPermission权限合并），而 Kilo Code 与 MiMo 都 fork 自 opencode：Kilo 沿用mode: subagent/primary/all三态、task工具、deriveSubagentSessionPermission，只追加了 orchestrator/debug/ask 模式；MiMo 沿用同一套目录结构（路径里仍是packages/opencode/src/），在其上叠了更重的 actor 层与 Orchestrator peer。 - Amp、Junie、Qoder、Kimi Code、Kiro、Amazon Q、OpenHands、goose、Zed、Hermes、Continue 全部是这套「子 agent 当工具、独立上下文、只回摘要、LLM 自主 fan-out」范式的变体。差异主要在三个旋钮上：递归深度（Codex
max_depth默认 1、HermesMAX_DEPTH1、OpenHandsmax_children5、AutoGPT Classic 默认 5，多数明确禁止子再 spawn 以防递归爆炸）、文件隔离（普遍用 git worktree：CC、Qwen、MiMo、QwenPaw、Qoder）、后台异步（CC 的run_in_background、goose 的 async task_id、Kilo 的 background、deepagents 的 AsyncSubAgentMiddleware）。
一个共同的「专才只读子 agent」子模式反复出现：explore / context-gathering 型子 agent 被限死只读工具集（grep/glob/read），理由是成本不对称——Augment 的 context-gathering 提示词把这个理由写得最直白：「编排器每 token 成本约是你的 20 倍，你跳过的每次搜索都会变成编排器高成本重做的搜索」，还配了结构化的 negativeFindings 反假阴性契约。Roo Code 更极端，让 Orchestrator 模式工具集为空，只能 new_task 委派，理由是「给它读文件权限会让上下文被文件读满」。
2. 显式编排者角色：orchestrator-workers 的定义与本土化
Anthropic 的多 agent 研究系统 是这个模式的命名来源与最完整披露：LeadResearcher 动态拆任务、并行生成 3-5 个 subagent、汇总，外加专职 CitationAgent。它给出的三分类法（Depth-first / Breadth-first / Straightforward）、子 agent 数量规模化规则（简单 1 个、高复杂度 5-10、硬上限 20）、以及「汇总绝不下放子 agent」的铁律，被后来很多家隐性沿用。它也诚实给出了量化代价（多 agent 用量约为 chat 的 15 倍，编码任务经济性边际）。
本土化实现里可以看到清晰的谱系：
- MetaGPT 的 MGXEnv 强制所有消息经过 TeamLeader（hub-and-spoke），是把 orchestrator 角色做进消息总线的最硬版本；AgentScope 的服务层团队工具同样把星形拓扑写死在 prompt 里（禁止成员间通信、禁止建 integrator）——两者殊途同归地用「星形」压低通信复杂度。
- Devin 的 map-reduce-and-manage 是工业化程度最高的一个：Managed Devins 协调者给每个子任务开独立 VM，Agentic MapReduce 把流程正式化成 Plan/Shard/Map/Reduce/Verify 五阶段，其中 Shard 阶段是确定性非 LLM 的（Tree-sitter/编译器查询），这是全场少数把「分片」从模型手里拿走交给代码的设计。Cognition 明确拒绝「unstructured swarms」，称其「mostly a distraction」——这个判断和 Warp 文档对 Swarm 模式「谨慎使用，更难调试」的警告、Augment 对「多 agent 有和多线程一样的竞态/死锁失败模式」的坦白，构成了一条业界共识：能塞进一个上下文就别拆。
- GPT-Pilot 是「软件公司 SOP」式的极端——约 20 个专职 agent（Wizard/SpecWriter/Architect/TechLead/Developer/CodeMonkey/…）由 FSM 编排，epics→tasks→steps→iterations 四层分解。这是比 MetaGPT 更细的角色分工，但两者共享同一个理念，也共享同一个弱点（角色多、交接多、更脆）。
- Comate 的 Architect（纯路由，「不直接调 Tools 仅调其他 Agent」）、AutoClaw 的 Cluster Mode（案例中观察到 2~18 个角色，含独立审核角色抓「71 个幽灵引用」）、Replit Agent 4 的自动拆分 + 冲突解决子 agent、Kiro 自主 agent 的 research→code→verify，都是同一模式的产品化。国产厂商（Comate/AutoClaw）的多 agent 编排普遍是 2025 下半年才上线的能力。
一个反复出现的角色是独立 verifier / reviewer：CC 的 verification-agent、Devin 的 clean-context reviewer（刻意不共享 coder 上下文）、Factory Mission 的 worker/validator 双模型、Kiro 的 verification agent、Amp 的 Oracle「第二意见」、AutoClaw 的独立审核角色——「用一个上下文干净的评审者复核生成者」几乎成了多 agent 编排的标配。
3. 确定性图 / DSL：把编排从 prompt 挪进代码
框架类 harness 走的是另一条路：不指望 LLM 即兴分解，而是让开发者显式写出编排图。LangGraph 提供最底层的原语（Send 做 map-reduce fan-out、Command(goto, graph=Command.PARENT) 做子图操纵父状态即 handoff 底座、子图作为节点组合），但本体不含 supervisor/swarm，那些在独立仓库。CrewAI（Flow DSL：@start/@listen/@router）、Agno（Workflow：Step/Router/Loop/Parallel/Condition，Router 支持 CEL 表达式）、Google ADK（Sequential/Parallel/Loop agent + 2.0 Workflow 图动态 fan-out）、Semantic Kernel（Process Framework，可跑 Dapr 分布式）都在这一层给出了各自的图/DSL 抽象。
Agno 把这个分野讲得最干脆：Team = 运行时 LLM 自主分派，Workflow = 开发者写死流程，用户按需要多少控制自选。这句话其实概括了整个第 3 组与第 1、2 组的根本区别。
一个特别的子分支是 Dynamic Workflow——LLM 生成一段确定性脚本再执行，试图兼得两者：主 agent 写出 JS 脚本，在沙箱里确定性地 agent()/parallel()/pipeline()。Qoder、MiMo、Qwen Code 都实现了，MiMo 明说「与 Anthropic Dynamic Workflow 的核心语义兼容并扩展」。动机是纯 prompt 编排在复杂工作流下会系统性失败（压缩吞步骤、模型跳阶段、两次运行路径不一致），把编排逻辑变成代码来求确定性。这是 2026 年出现的新流派，值得关注。
Letta 的 Tool Rules 是这一组里最独特的一个：它不是多 agent，而是一套声明式 DSL 约束单 agent 内的工具调用图——constrain_child_tools（父→子）、conditional（按返回值路由）、run_first/exit_loop/required_before_exit/max_count_per_step，由 ToolRulesSolver 每步算合法工具集。Letta 自己说这比多 agent groups 更常用。它把「编排」下沉到了工具级状态机，是一个值得单独借鉴的视角（配合它分层自编辑记忆的 memory 设计，Letta 整体是「状态机 + 记忆」而非「多 agent」路线）。
AutoGPT 横跨两组：Classic 版 ExecutionContext 是 prompt 涌现式（还带 MultiAgentDebate 五阶段辩论），Platform 版则是纯 Block DAG。它的文件 docstring 明确引用「Google ADK Multi-Agent Patterns」与「Anthropic Multi-Agent Research System」作为设计参考——是「谁抄谁」链条里少见的自报出处。
4. handoff vs delegation：控制权语义之争（框架层最爱纠结的点）
SDK / 框架类 harness 特别在意「控制权转移后回不回来」：
- Handoff（转移不回来）：OpenAI Agents SDK 的
Agent.handoffs（目标 agent 接管对话，NextStepHandoff换掉 current_agent）、AutoGen Swarm（读HandoffMessage.target路由，路由本身不发 LLM 调用）、Semantic Kernel Handoff（当前 agent 自己的 LLM 决定调交接函数）、ADK 的 transfer_to_agent（软路由，parent↔sub/sub→peer 方向规则）都属此类。共同点是路由决策外包给模型的常规 function-calling，编排层只做拦截和切换。 - Delegation / agent-as-tool（调用完回来）：smolagents 把受管 agent 塞进
{**tools, **managed_agents}字典当工具调、Pydantic-AI 在@agent.tool里await other_agent.run(usage=ctx.usage)共享计费、OpenAI 的Agent.as_tool()、ADK 的agent_tool.py——第 1 组所有 Task 工具本质也是这一类。
Pydantic-AI 把谱系列成正式的 5 级（单 agent / delegation / programmatic hand-off / graph / Deep Agents），并强调核心无内置主 router，子 agent 能力放在第三方 subagents-pydantic-ai（task/check_task/wait_tasks/soft/hard cancel）——类型化、克制、把编排当可选扩展，是 Pydantic-AI 一贯的设计品味。Semantic Kernel 值得一提的是它把 Planner 子系统整个删掉了（PLANNERS.md 只剩跳转 stub），改用 auto-function-invocation + orchestration + Process Framework 三者替代——一个明确的「planner 已死，编排靠工具调用 + 图」的信号。它的 Magentic 编排直接移植自 AutoGen 的 MagenticOne，runtime 也对齐 AutoGen core，是微软两个框架间的血缘。
5. 模型路由：与任务分解无关的另一条轴
这一支容易和多 agent 混淆，其实是「同一个任务这一步派哪个模型」：
- Gemini CLI 有最完整的可插拔路由策略栈：
classifierStrategy用一次独立小模型 LLM 调用把 prompt 分成 flash/pro，还有实验性本地 Gemma classifier 替代托管调用降本。 - Augment 的 Prism 是披露最深的一个：一个在每个用户回合前运行的规划器模型，从固定池里选本回合模型。核心工程约束是缓存感知——回合内切模型会驱逐 prompt cache 使成本约涨 10 倍，所以策略是「只有换模型的预期收益超过 cache 驱逐成本才换」，且决策在回合内粘性、不打断进行中的回合。量化开销也给全了（规划器占总花费 0.03%、p50 延迟 2.6s、仅 4% 回合触发）。这是模型路由里唯一给出生产 telemetry 的。
- Kiro 的 Auto、Copilot 的 Auto model selection（综合 task intent + model health）+ Rubber Duck 跨模型互评、v0 的 Quick Edit（窄范围编辑走快速专用模型）都是同一支的产品化，但算法细节多未公开。
- claude-flow 是路由里最激进的：agent router 用真 Q-learning（qTable、epsilon-greedy 指数衰减、reward 更新、落盘
.swarm/q-learning-model.json），model router 是 3-tier（含 Tier-1 确定性 codemod 直接跳过 LLM $0）。但要点破一个反差——它的agent_spawn只写 metadata、不 spawn 任何进程，所谓「60+/98/100+ agent swarm」实为一个注册表 + 让 Claude Code 去 spawn 的 prompt 指令，真正的并行性来自 Claude Code 的 Task 工具。它是编排的委派者，而非拥有者。 - Devin 的 Smart Friend（小模型判断「tricky」时中途调大模型）是跨模型委派，但 Cognition 坦白这机制在主模型明显弱于 smart friend 时「尚不可靠，是个 training problem」——罕见的把 harness 局限归因到模型训练的诚实披露。
6. 跨 harness 编排：把别人的 agent 当执行后端
这是一条完全独立的互操作轴，普遍走开放协议：
- **ACP（Agent Client Protocol，JSON-RPC over stdio）**是事实标准，Zed 自建并推动，OpenHands、goose、QwenPaw、Kiro、DeerFlow 都实现了。语义是「让一个 harness 把整轮对话委托给外部 ACP 兼容 agent（Claude Code / Codex / Gemini CLI）」，QwenPaw 的
delegate_external_agent可以字面意义上 shell out 编排 Claude Code 作为子运行时。 - **A2A（Agent2Agent）**更偏「把 agent 暴露成远程标准服务」：CrewAI、Gemini CLI（远程 agent）、Qoder（Agent Card）、OpenManus、Agent Zero 都支持。
- Warp 把这个做进了核心：
Harness枚举有 Oz/Claude/OpenCode/Gemini/Codex 五种，父/子 agent 可以跑在不同 harness 上（Warp 父派生 Claude-Code 子，反之亦然），且消息总线与 harness 无关。这是「多 harness 编排」最字面的实现。 - Agent Zero 的 orchestrator 插件走的是最朴素的路子——不搞协议，直接教 agent 通过 host CLI bridge 以 yolo/bypass 权限驱动 Claude Code/Codex/Cursor/Grok 等 headless CLI（
codex exec --dangerously-bypass-approvals-and-sandbox）。
7. 单 agent 的边缘案例：GUI 动作空间与「不拆」
几个新增 harness 恰恰以「不做多 agent」为特征，值得点出：
- browser-use 是纯单 agent，任务分解靠 system prompt 里的
plan_update（3-10 个 todo）在 context 里自维护，多 agent 属于闭源的 Browser Use Cloud。它的动作空间是浏览器（点击/输入/导航），属 tools 维度的 GUI/computer-use 一派。 - UI-TARS 的 Omni-TARS 有一个独特的「编排」定义——单 agent 多 environment 路由：把 code/mcp/gui 三个 environment 组合，模型每轮用
<environment_name>标签声明本轮用哪个环境，ComposableToolCallEngine据标签分派 parser。是同一个模型自己在多环境间切，不是多 agent。这和 Open Interpreter 的 harness 路由（WireApi × Harness严格映射到传输/仿真路由）是两种「router 但非多 agent」的典型，特别容易被误读。 - Plandex 是单线程两段式（architect/planner→implementer，一轮实现一个编号子任务），所谓「角色」只是同一流水线不同步骤的不同模型配置，不是自治 agent。Aider 的 Architect/Editor 模式是这条「两步流水线」谱系的最早、最简版本：architect 模型出纯文本方案，再构造第二个
Coder实例（用editor_model）把方案落地，没有任务树、没有 planner、没有并行 agent——它和 Plandex 一起说明「planner 与 executor 用不同模型配置」这件事，本身并不需要多 agent 机制。
8. 一个需要澄清的底座关系
AgentScope 是 QwenPaw 的底座，但有个值得点出的边界：QwenPaw 的 Goal/Mission 多模式编排是它在应用层另做的，并没有复用 AgentScope 服务层那套星形团队工具（TeamCreate/AgentCreate）。所以「QwenPaw 基于 AgentScope」在编排维度上不成立——底座提供的是单 agent ReAct worker 与 MessageBus，多 agent 编排两边各写各的。
结尾：最值得借鉴的两个设计
其一，Warp 的「持久化服务端 mailbox + 全局序列号保序」多 harness 编排。 大多数 harness 的子 agent 是进程内、一次性、只回摘要的（Task 工具系）；Warp 把 agent 间通信做成了一个可恢复、跨 harness、服务端支撑的消息总线：每个 agent 有 agent-ID 寻址的 inbox，消息和生命周期事件共享全局序列号，保证父 agent 永远不会在产生结果的消息之前观察到子 agent 的 SUCCEEDED。加上终态子 agent 仍可被「唤醒」重新派任务、以及按（model, harness, execution-mode）在会话内记忆的审批状态，这套设计把多 agent 从「fork-join 一次性」升级成了「可寻址、可恢复、可混编不同 harness」的基础设施。谁想做真正健壮的长时多 agent 系统，这是最完整的参考实现。
其二，Letta 的 Tool Rules 声明式工具调用图。 在几乎所有人都把编排交给「LLM 即兴 fan-out」或「开发者写死的 DAG」时，Letta 给出了第三条路：用一套声明式 DSL（constrain_child_tools / conditional / run_first / exit_loop / required_before_exit / max_count_per_step）约束单 agent 内部的工具调用图，由 solver 每步计算合法工具集。它的价值在于在不引入多 agent 复杂度的前提下拿到确定性编排——既避开了 prompt 涌现式的不可复现（同一任务两次跑路径不同），又不必像图/DSL 那样把整个流程写死。对绝大多数「其实不需要多 agent、只需要约束单 agent 别乱调工具」的场景，这是比 spawn 子 agent 更轻、更可控的答案。业界正在被 Dynamic Workflow（用代码换确定性）吸引，而 Tool Rules 提示了另一种更低成本的确定性来源：约束，而非重写。