午夜咖啡午夜咖啡

jolestar 的文章与笔记。

Page

Agent 是否需要分工以及角色划分?

2026-05-31Page

Agent 的角色分工本质上是决策权力的分配。复用已有的、LLM 已经理解的人类协作模式(如 GitHub PR 工作流),比发明新规则更务实;而 AgentHome 则让角色分工从单次指令变成了可持久化、可迭代的机制。

cover

前几天和一个朋友交流 AI Coding 工作流,他遇到一个问题: 一个 Agent 写完代码后,再让另一个 Agent 来 review,但经常出现两个 Agent 越改越多、无法收敛的情况,最后还是需要人工介入。

他的做法是让两个 Agent 读同一个分支,把结果写在文档里,基于文档交流。但这种方式有一个根本问题:两个 Agent 对各自以及对方的角色认知并不一样。dev agent 很容易把 reviewer agent 的反馈当作"建议"而非"决定",讨论自然就会扩散。

而我用的是 GitHub Pull Request 工作流。这套机制已经包含在 LLM 的训练数据里,Agent 天生就理解它的运作方式。reviewer agent 明确知道自己的职责是审查 PR 并决定是否合并,dev agent 的目标则是响应 reviewer 的反馈,推动 PR 合并。它们共享同一个目标,但在职责和权力上有明确的区分。

记得有一次,reviewer 拦住了一个 PR,理由是改动超出了 issue 的边界,做了过多重构。dev agent 打算撤回重构部分,被我拦住了——我建议它继续改进重构方案。dev agent 表示了明显的担心,怕 reviewer 不合并代码。我说你放心,我是 admin,我来合并。它这才放心地继续修改。

从这个例子可以看出来:分角色,本质上是分权力。

引入 Agent 进工作流,其实就是让渡决策权。Vibe coding 让渡的是代码细节的决策权,PR 工作流让渡的是整个里程碑的推进权。而任何协作体系,都需要一套可收敛的决策机制来驱动进展。人类工作体系中已有的角色和分工,本身就蕴含了决策权力的分配——Agent 理解这套,比理解一套新发明的机制要容易得多。

不涉及权力时,还需要角色分工吗?

权力分配是角色分工的一层,但不是全部。即使没有决策权的差异,角色分工在另外两个维度也有现实价值。

第一个维度是并行。 比如 Agent 是否应该拆分成客户端开发和服务端开发?我最近在一个项目里拆分出了客户端 Agent,核心原因是客户端和服务端完全可以并行。我让它主动订阅带有 client 标签的 issue,然后自动处理。当然,如果一个特性同时牵扯到前后端,我不会让多个 Agent 接力,而是在同一个 Agent 里完成——接力的沟通成本往往高于并行。

第二个维度是领域知识的积累。 比如是否需要一个专门的测试 Agent?运维 Agent?如果你希望 Agent 能主动干活——新版本发布后自动触发端到端测试,或者定时扫描服务器日志发现问题——那就需要专门负责的 Agent。而且,Agent 在特定方向上持续积累的记忆,可以显著提高上下文效率。

角色的记忆该放在哪里?

角色分工要持久化,就必须有地方存放角色的信息。我在用 Codex 的时候,一般会用一个长期 session 来模拟。但时间长了,Agent 很容易因为上下文压缩,忘记自己的角色、职责、权力边界和工作方式。

这些信息又不适合放在仓库的 AGENTS.md 里——仓库级的约定是给团队所有人看的,而特定 Agent 的角色认知是它自己的"私有记忆"。

所以设计 Holon 的时候,我给每个 Agent 专门保留了一个 AgentHome。这个目录下的 AGENTS.md 就是 Agent 的"角色权力契约":

  • Agent 在执行过程中会把自己的角色认知、权力边界、工作约定固化到这里;
  • 即使上下文压缩,重新加载 AGENTS.md 就能恢复角色认知;
  • Agent 还可以在每次任务中迭代这份文件,让角色越来越准确。

这就和前面说的形成了闭环:AgentHome 就是 Agent 的角色权力契约,让权力分配从一次性指令变成了可演化、可持久化的机制。

总结

回到最开始的问题:Agent 是否需要分工和角色划分?

我的答案是:要看是否需要分配决策权。如果任务天然可分、边界清晰,分工和角色划分能帮助 Agent 协作收敛;如果任务牵扯紧密,在同一 Agent 内完成反而更高效。关键是理解角色分工的本质——它不是人类组织形式的机械模仿,而是一套让决策可收敛、让记忆可积累的机制。PR 工作流的例子说明,复用已有的、LLM 已经理解的人类协作模式,比发明新规则更务实。而 AgentHome 则让这种角色分工从单次指令变成了持久化的、可迭代的能力。

从这个角度看,Agent 的角色设计,其实是在设计一个微型组织的契约。

这也是我在做 Holon 时重点关注的问题。Holon 是一个为 Agent 提供持续工作环境的本地工作台,它本身不是 Agent,而是把"工作"作为基本单位,帮多个 Agent 保存状态、组织上下文、记录等待与唤醒。让 Agent 能在真实工程环境里长期工作、跨会话恢复,并围绕清晰的角色、记忆和权力边界持续交付结果。如果你也在探索多 Agent 协作可以关注这个项目。