装了一堆 Agent，到底哪些真的有用？

2026-10-02 更新：删除缺乏原始记录支持的具体人数与个人体检叙述，保留自查方法，补充近期验收案例，并修正固定评分和调用门槛。

角色清单，怎样变成实际工作

选题、研究、写作、审稿、排版、发布，每个环节都可以写一份角色定义。清单列得完整，方便查找；能不能接住工作，还需要放到具体任务里看。

例如，把一条官方更新写成文章：来源由谁读取，哪些说法要核验，草稿交给谁，最后拿什么判断写完了？这些问题没有交代清楚，角色名字再专业，接手的人也要重新猜一遍。

可以先问四句话：什么时候叫它？要给它什么？它交回什么？拿什么证明任务已经完成？

本文按这个思路整理一份自查方法。先写清工作约定，再看当前条件是否成立、实际交付覆盖到哪里，最后判断这份分工是否值得保留。

先把工作约定说清楚

一个 Agent 接到任务前，先把六项说清楚。小任务可以简写，关键是接手的人能据此行动和验收。

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

六项写齐，只说明工作约定完整。缺了什么，就判断它是否影响当前任务，不能用勾选数量认定一个角色的能力。

模型输出了一段流畅文字，不代表流程已经向前走了一步。还要检查这份输出是否满足当前任务，能否被下一环节接住。

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

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

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

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

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

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

失败出口：读取失败时尝试合适的替代方式或上游来源；仍取不到完整原文，就标记相关结论未核实，并继续不依赖它的工作。不根据搜索摘要还原正文。

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

反过来看“你是一个世界级增长专家，请给我最有洞察的建议”，它只有身份，没有工作合同。这句描述本身没有交代下一环节需要什么。

怎样检查现有角色

可以按下面五步检查，再决定保留、调整或暂存。

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

从最近任务里找它的实际输入和输出。没有调用记录，就先标记“尚未验证”，不要仅凭角色自我介绍判断它已经具备工作能力。

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

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

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

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

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

先确认本轮条件成立：需要的工具能不能调用，文件或账户是否可访问，版本和权限是否适用。角色文件存在只证明保存了定义，不能代替实际调用。写了“只读”的行为约定，也不自动证明运行环境禁止写入。

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

试跑时比较三件事：

• 它有没有找到当时真正的阻塞点。
• 它的输出能不能直接被下一步使用。
• 它失败时能否如实说明缺口，留下可接续的材料。

一次表现好不能证明稳定。可以按用途和风险选择样本，覆盖资料齐全、资料不足、工具失败或环境变化的情况，不把固定次数当作统一门槛。已知答案留给验收者，避免把照着结果复述当成能力。

第四步：按实际缺口决定处理

根据实际缺口，记录一个具体处理决定：

• 工作约定清楚、输出有用：保留这次分工，再随着真实任务观察。
• 缺关键来源、工具或授权：补齐后再做依赖它的部分。
• 职责重复、交接增加返工：合并职责，或由主助手直接处理。
• 现在没有实际任务：留作按需参考，不因为暂时没调用就断言没有价值。

缺少验收证据，不能靠其他五项都填了来抵消。这是一种整理方法，重点是留下具体原因，不是做出新的认证等级。

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

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

一个 Agent 可以准备发布包，但“准备完成”和“已经发布”是两个状态。既有有效授权在原定对象、动作、任务范围内继续适用；如设有时限，也须仍在时限内。范围扩大或授权缺失时再补问，执行后从目标系统读回结果。发送或扣费的结果不明时，先核对状态，再决定是否重试，避免重复执行。

一种可能增加返工的分工

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

如果安排研究员、分析师、写作者、审稿人和总监依次发言，却没有独立问题和明确交接，就可能发生三件事：

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

一种可以检查交接的链路是：

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

这是这个场景的一种分工示例，不能据此设定所有任务都需要三个角色。每一步有可检查的中间产物，责任和交接才容易说清楚；简单任务也可以由一个助手完成。

一次实际验收，能证明到哪一步

10 月 1 日，知客在实体 Mac 与 Windows Server 云主机上做了一轮授权测试，激活、设备限制、换发和撤销等 19 项检查全部通过。

同一份验收报告也记录了问题：全新 Windows 环境缺少运行库，普通用户首次安装没有直接完成，管理员处理依赖后才继续跑通测试。

因此，这轮证明的是授权功能在指定环境下的结果。它没有证明普通用户在 Win10 或 Win11 上双击安装就能用，也没有覆盖完整评论业务。本次修订引用这份记录，没有重新运行产品测试。

这把旧文的“验收证据”说得更具体了：交回结果时，要说明完成了哪一段、哪些没覆盖、下一步由谁接。另一个 Agent 回一句“通过”，也不能代替这些证据。

体检也要看总成本

调用成本只是最显眼的一项。多个角色互相讨论会增加调用费用，还要考虑下面几种成本。

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

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

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

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

具体复盘时，还可以顺手记下等待、重复阅读和人工修补：新增角色是减少了遗漏，还是带来更多整理工作？时间和费用有记录才填，没有就写未测。

多一个角色也可能是为了覆盖一项必要检查，即使成本增加仍有理由保留。要把收益与代价一起看。本次没有单 Agent 与多 Agent 的对照记录，不能宣称修订后的方法已经更快或更便宜。

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

要不要增加第二个 Agent，可以先看有没有清楚的“交接面”：

1. 子任务可以独立回答，或一项重要结论需要另外核验。
2. 中间产物可以独立保存。
3. 前后两步需要不同的判断标准。
4. 拆开后，失败能定位得更快。
5. 新角色不需要获得更大的默认权限。

一次性任务也可以满足这些条件，不必等它重复三次。重复发生则更有利于持续观察这份分工是否值得保留。

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

最后看工作如何接起来

判断这套安排是否有用，可以看这几件事：

• 一项任务从哪里进入。
• 每一步留下什么文件。
• 谁能改变内容，谁只能检查。
• 缺证据时能否标明缺口、停住无依据的判断，并继续其他可做的部分。
• 哪个状态来自本地，哪个状态来自外部平台。

暂时用不到的角色定义可以留作参考；参与当前任务的角色，则需要交代它负责哪一步、交回了什么。

如果你手里也有一长串 Agent，挑一项真实任务，写清触发、输入、输出、证据、失败出口和权限，再核对本轮条件与实际结果。需要试跑时选有代表性的场景。最后问一句：凭这份交付，我能放心推进到哪一步？