我给 52 个 AI「员工」做了一次留任体检，结果该被开除的是我

这 52 个 Agent，究竟谁真的上过班

把 52 个名字排成清单时，我一度觉得系统已经像个小公司：选题、研究、写作、审稿、排版、发布，每个环节都有人负责。

后来我拿一项已经完成的真实任务反查，问题马上露出来了。有些角色能给出漂亮建议，却接不到固定输入；几个名字不同的 Agent 做着同一件事；还有些角色从创建起就没有进入过一次真实流程。

我于是换了一个判断方法：不再看它叫什么，只问四句话。什么时候叫它？要给它什么？它交回什么？拿什么证明任务已经完成？

很多角色答不上来。

52 是库存数量，不是已经上岗的人数。这次体检最后查出的也不是模型不够聪明，而是我把提示词数量误当成了组织能力。

我先停止讨论模型，改查工作合同

一个 Agent 能不能留下，我现在先看六项。每项只有“有”或“没有”，不允许用“视情况而定”糊过去。

1. 触发条件：什么任务出现时应该调用它。
2. 输入合同：它必须拿到哪些文件、字段或上下文。
3. 输出合同：它交付的是建议、Markdown、JSON、截图，还是平台状态。
4. 验收证据：谁用什么结果判断它做成了。
5. 失败出口：资料不足或工具失败时，它应该停在哪。
6. 权限边界：它能读、能写、能联网，还是能执行外部动作。

六项写不齐的角色，暂时不能算正式岗位。它最多是一段参考 Prompt。

这个标准看起来苛刻，但它解决了一个常见错觉：模型输出了一段流畅文字，不代表流程向前走了一步。只有输出能被下一环节接住，工作才真的发生。

一张岗位卡到底要写到什么程度

以“文章来源核验”为例，一张可工作的岗位卡可以这样写：

触发条件：草稿里出现可核验的产品能力、价格、版本或数据。

输入：原始 URL、待核验说法、文章目标读者、截止日期。

输出：事实表，逐条包含原始来源、页面日期、支持程度和仍不确定的部分。

完成证据：每条公开事实都能回到上游页面；无法确认的内容标为待验证，没有被补成肯定句。

失败出口：页面无法访问时停止，不根据搜索摘要还原正文。

权限边界：可以只读浏览公开页面，不登录账号，不付费，不发布。

反过来看“你是一个世界级增长专家，请给我最有洞察的建议”，它只有身份，没有工作合同。模型当然可以回答，但答案无法稳定进入任何生产步骤。

我怎样给 52 个角色做分流

我没有先删文件，而是按下面五步处理。

第一步：从最近完成的任务反查真实调用

我查看的不是角色自我介绍，而是最近任务里有没有出现过它。被创建半年却从未进入真实流程的角色，不因为名字好听就获得留任资格。

这里要区分“没有价值”和“现在没有岗位”。后者可以归档，等真实需求出现再恢复，不需要永久删除。

第二步：把重复角色放到同一张桌上

只要触发条件、输入和输出高度相似，就先视为同一岗位。比如“文章审稿人”“内容质检官”“高级编辑”可能只是三种语气，不一定是三份工作。

合并时保留最清楚的输入输出合同，而不是保留最有气势的名字。

第三步：给角色做一次影子运行

影子运行的意思是：让 Agent 对一个已经完成、结果已知的历史任务再做一次，但不允许它触发外部动作。

我只比较三件事：

• 它有没有找到当时真正的阻塞点。
• 它的输出能不能直接被下一步使用。
• 它失败时有没有诚实停下。

一次表现好不能证明稳定。至少要跨三个相似任务观察，才能判断这是能力，还是刚好猜中。

第四步：按分数决定身份

我的内部处理规则很简单：

• 0 到 2 项清楚：归档为素材。
• 3 项清楚：保留为参考 Prompt。
• 4 到 5 项清楚：进入试用工作流。
• 6 项清楚：才算正式 Agent。

这不是行业标准，只是个人系统用来控制复杂度的办法。重点不是分数多精确，而是每次留任都有相同依据。

第五步：把外部权限从岗位里拆掉

研究、生成和检查可以连续发生；登录、扣费、推送、部署和发布不能因为上一步表现好就自动获得授权。

一个 Agent 可以准备发布包，但“准备完成”和“已经发布”是两个状态。真正的外部动作必须由当前任务单独授权，并从目标系统读回结果。

一个反例：五个 Agent 为什么比一个更慢

假设任务是“把一条官方更新写成一篇新手文章”。

常见的多 Agent 设计会安排研究员、分析师、写作者、审稿人和总监依次发言。表面上分工完整，实际经常发生三件事：

• 五个角色重复概括同一个来源。
• 后面的角色不知道前面的哪句话是事实、哪句话是推断。
• 最终仍然需要人重新整理成可发布文件。

更短的链路通常是：

原始来源
  -> 事实核验 Agent：输出 claims.json
  -> 平台 Writer：输出 article.md
  -> 只读质检：输出问题清单
  -> 人工决定是否修复与发布

三个角色足够，是因为每一步都留下可检查的中间产物。角色少不是目标，责任不重叠才是目标。

体检真正要看四类成本

调用成本只是最显眼的一项。多个角色互相讨论会增加 Token，但更贵的是下面三种成本。

认知成本：每次开始任务前都要先想该叫谁。

维护成本：同一规则被复制进多个角色，更新一次要改很多地方。

证据成本：输出没有结构，只能靠人重新阅读和判断。

权限成本：为了减少确认，把不必要的账号和系统权限交给 Agent。

如果新增一个角色没有减少其中至少一项成本，它大概率只是增加了组织图的面积。

什么时候应该新增第二个 Agent

我现在只在出现清楚的“交接面”时扩编。判断方法是：

1. 第一项工作已经连续重复至少三次。
2. 中间产物可以独立保存。
3. 前后两步需要不同的判断标准。
4. 拆开后，失败能定位得更快。
5. 新角色不需要获得更大的默认权限。

例如“写文章”和“检查移动端排版”适合拆开，因为两者输入输出不同，后者还可以保持只读。反过来，“资深写作者”和“首席写作者”通常没有可验证的交接面。

体检之后，我只看责任链

这次体检后，我不再用 Agent 数量描述系统成熟度。我更关心：

• 一项任务从哪里进入。
• 每一步留下什么文件。
• 谁能改变内容，谁只能检查。
• 缺证据时系统会不会停。
• 哪个状态来自本地，哪个状态来自外部平台。

52 个角色可以继续作为知识库存存在，但只有进入责任链的角色才算上岗。

如果你手里也有一长串 Agent，先不要继续扩编。挑一项最近重复做过的工作，写清触发、输入、输出、证据、失败出口和权限，再拿三个历史任务让它试跑。名单会很快自己缩短。