一个还是一队：单/多 agent 的专业化收益与交接账单

演示视频里最出彩的形态，是五个角色各司其职的多 agent 系统，像一支微型软件团队。但 L14 的立场异常冷静：默认单 agent（single agent），多 agent（multi-agent）是有明确目的时才启用的例外（L14 p.23）。

这场单 / 多之辩值得深挖，争的其实是一本账：专业化（specialization）的收益，抵不抵得过角色间交接（handoff）的损耗。本篇沿 L14 p.22-28 把两造论点、中间路线与例外条款逐页摊开。

一、正方陈词：专业化的三重收益

早期多 agent 路线的代表是 CodeR：§2 把解一个 issue 拆成五个专职角色（L14 p.22）。Manager 做 issue 计划，Reproducer 复现，Fault localizer 定位，Editor 改码，Verifier 验证。同一思路的还有把软件开发流程角色化的 MetaGPT。

拆分的收益，本篇归纳为三点：

• 角色上下文更干净。每个 agent 只装自己那一步需要的上下文，不被全流程的噪声污染。
• 可独立优化。每个角色的提示词与模型可以单独调，动 Reproducer 不必牵连 Editor。
• 可配独立权限。Editor 能写文件，Verifier 可以只读，权限随角色最小化。

这三条确实像软件工程的分工常识，也是多 agent 路线持续有人做的原因。论文标题里的另一半「Task Graphs」也在提醒：角色一多，还得有专门机制编排谁先谁后。协调成本从名字里就看得见。

二、反方陈词：交接是一张真实账单

L14 p.23 给出对照的单 agent 基线：一个 agent 依次做复现、定位、编辑、测试，活动之间共享同一份上下文。复现时看到的线索，到编辑时还在视野里，零成本流转。

拆了角色，这份免费的一致性开始收费。讲义点了两项：

• 交接成本是运行时的：状态要跨角色同步，线索要在摘要里挤过窄门。
• 维护成本是工程上的：每个角色的提示词、模型与工具配置都成了一条要单独养、单独测的分支。

slides 把这条原则加了粗（L14 p.23，出处 Don’t Sleep on Single-agent Systems，2024）：有明确目的才加 agent。默认答案就是一个 agent。

三、中间路线：不拆 agent，先扩动作空间

第三条路不拆 agent，先把一个 agent 能做的事做大。L14 p.24-27 给出三级扩法。

第一级，通用工具。L14 p.24 的工具箱刻意小，只有三样：

• 编辑文件。源码 / 配置 / 文档。
• 运行命令。搜索 / 依赖 / 测试。
• 浏览。文档与视觉检查。

三样靠组合覆盖绝大多数任务，讲义称之为「通用动作空间」(general action space)。它区别于为每类任务造一个专用 agent 的地方，就在小工具集、多组合。

第二级，技能（skills，L14 p.25）：同一个 agent 的附加指令，项目惯例、常重复的流程写成文件，按需激活。前身名叫 microagents。技能是加角色的廉价替代品：新 agent 要付出交接成本，新技能只是一段按需加载的上下文，agent 还是那一个。

# L14 p.25：技能挂在 AgentContext 上，是给同一个 agent 的补充说明书
AgentContext(skills=[Skill(name="repo.md", content=..., trigger=None)])

第三级，MCP 工具（L14 p.26）：外部 server 自带工具描述与执行，内置与外部工具并用：

# L14 p.26：一个 repomix server 就把「打包整个仓库」变成可调用工具
mcp_config = {"repomix": MCPServer(command="npx", args=["-y", "repomix@1.4.2", "--mcp"])}

三级扩法的终点在 L14 p.27 得到验证：Soni 等人的 OpenHands-Versa 用编码 + 视觉浏览 + 搜索 + 文件访问的同一套工具栈，覆盖编码、研究、办公三类场景（图 1）。动作空间足够通用时，一个 agent 天然是通用问题求解器，不需要拆成五个专才。

四、例外条款：p.28 的三个「明确目的」

原则归原则，L14 p.28 列出三条真正正当的拆分理由：

• 并行。多个独立 issue 或仓库天然可并行，各开一个 agent 互不干扰。
• 独立审查。补丁检查这类任务要求审查者与作者语境分离、任务与权限独立。
• 成本控制。合适的子任务交给便宜的模型。

拆之前，还有三个权衡项要过：任务边界是否清晰、共享上下文怎么传、协调成本谁付。三条理由的共同点，是都在回答为什么这几个 agent 不该合并成一个。至于让团队看起来更像团队，算不上正当理由。

与本讲的连接

7b 伴读把 OpenHands 讲成平台全景，本篇只负责校准其中一格：slides 默认单 agent + 通用工具 + 技能，多 agent 只在命中 p.28 三条之一时启用。这跟前一篇 SDK 详解开篇的设计立场同源：先把一个 agent 的能力做厚。

• m7-single-agent-blog。官方立场原文。
• m7-coder。专业化一方的代表文献。
• m7-versa。通用动作空间的跨域证据。
• m7-openhands-paper。这一切所属平台的总锚点。

留一道判断题带回家：下次想给自己的 agent 加一个经理角色，先写下它能不能给出 p.28 式的明确目的。写不出，就先补工具、加技能，第二个 agent 不急。