Signal #35：Agent 的分工，不必照搬人的岗位

给 AI 安排研发任务时，很容易沿用团队已有的分工：产品 Agent 整理需求，开发 Agent 写代码，测试 Agent 检查结果。每个角色负责什么，彼此怎样配合，都能找到熟悉的参照。

不过，一项需求往往还包括评审中的补充、临时确认的规则，以及前面讨论后排除的方案。换一个 Agent 接着做，这些信息也得一起交过去。交接时漏掉一点，后面的开发和检查就可能一起受影响。

以一个假设的活动报名页为例。需求里有两条特别的规定：同一个人重复报名，要返回已有记录；活动取消后，不能再接受报名。

几个 Agent 按照前面的分工依次完成工作。最后交出的页面能打开、能填写，也能提交，但那两条规定都没实现。

回头看，问题出在第一次交接。产品 Agent 把需求整理成了“展示活动信息，填写表单，提交报名”，漏掉了重复报名和活动取消的处理。开发照着这份摘要写，测试又根据实现生成用例，后面几个环节便一路顺着做了下去。

这是一个假设的例子，却能说明一个容易被忽略的问题：角色分得清楚，不代表需求就能完整地传下去。

图 1：一个假设的需求交接过程。各环节都返回了“完成”，两条特殊规定却始终没有得到处理。

写代码时发现需求有歧义，要回头确认；方案改了，又要重新检查原来的限制。几个 Agent 如果总在读同一批资料、追问同一段讨论，就会花很多时间交接背景。

Anthropic 在近期的一篇架构建议中，提出可以尝试合并这类经常接力的 Agent：让同一个 Agent 接着处理任务，需要某种专业方法时，再加载对应的 Skill，或调用相应工具。

比如，需求里刚确认了报名限制，同一个 Agent 可以接着修改方案和代码，省去再向下一个角色解释一遍的过程。至于业务知识、编码规范和操作能力，仍然可以由不同团队维护，按需提供给它。

这样做是否有效，还要在任务中检验。但它提供了一个很实用的思路：先看几个角色之间到底在传什么，再决定有没有必要把工作拆开。

天猫数字员工的实践提供了另一个例子。

它由同一个数字员工在需求群里持续参与讨论，再根据任务调用编码、测试等执行能力。需求有补充、进展有变化，仍然可以回到同一个地方接着说。

这套做法保留了不同的执行者，同时让需求讨论和后续工作保持联系。谁来写代码、谁来跑测试，可以分别安排；此前确认了什么、现在做到哪一步，也需要持续跟进。

具体实现时，各个执行者仍可能有自己的模型上下文。派任务时该带上哪些资料，完成后怎样把结果记回原任务，都是需要解决的问题。一个统一的聊天入口，还不足以保证这些信息都能传到位。

回到报名页的例子，无论最后由几个 Agent 来做，那两条特殊规定都得跟着任务走。执行者要能查到，检查结果的人也要能查到。

需要尝试不同方向时，拆分就很有用。

美团公开的 AutoResearch 实践中，主 Agent 提出不同的实验假设，再交给各个分支分别改代码、做训练，最后汇总结果，决定下一轮往哪里走。

每个分支都有自己的问题要回答，可以先各自尝试，再拿结果比较。这样的分工有明确的用途，也不需要像前面的需求接力那样，频繁互相补充背景。

检查工作也值得单独考虑。写代码的 Agent 已经沿着一套理解做完了实现，另一个 Agent 可以从原始需求出发，重新核对成品。

前提是，它得拿到原始需求。如果只给它开发者的摘要和一份“已完成”报告，即使用了不同的模型，也可能继续漏掉同样的问题。测试报名页时，只有看到活动取消后的处理要求，才知道还应该检查这一项。

图 2：一种可供参考的安排。需要反复讨论的工作持续推进，需要分别尝试或重新检查的工作再交给其他执行者。

涉及敏感数据或高风险操作时，还需要限制各个 Agent 能调用的工具和权限。这也是拆分工作时要考虑的实际理由。

已经搭好多 Agent 流程，可以先找两个经常来回沟通的角色，看看它们为什么总要互相追问。

如果大部分问题都在补充同一份背景，可以试着把这部分工作交给同一个 Agent。拿同一批任务比较，看看需求有没有漏，结果有没有变差，调用费用、等待时间和人工返工有没有减少。

尤其要看看原本能完成、调整后却失败的任务。少了一次交接，也可能少了一项原来会做的检查。平均耗时下降了，这类问题仍然需要逐个查清。

有些角色可以合并，人的审批和验收责任仍要明确。最后谁确认需求、谁接受交付，不能随着软件流程的变化变得含糊。

人的岗位可以帮助我们梳理职责。到了 Agent 真正执行任务的时候，还得看看它们每天在忙什么：是在反复解释同一份需求，还是各自解决了一个问题、查出了一处遗漏。

分工是否有用，答案就在这些具体的工作里。