把任务交给多 Agent 团队前，先定好的五个约定

最近社区里多 Agent 协作的文章越来越多：有的用几个专职 Agent 分工做一个完整网站，有的用一条流水线在半小时内做出一个小游戏。热闹归热闹，真正把任务交出去的时候，成败往往不在模型够不够强，而在开始之前有没有把约定定好。下面这五个约定，是我从这类实践里提炼出来的通用做法，和具体用哪个平台、哪个框架无关。

一、先把“完成”写清楚，再谈分工
多 Agent 最常见的翻车，是每个 Agent 都觉得自己做完了，但拼起来不是用户要的东西。开始之前，先用一句话写清楚交付标准：交付物是什么、放在哪里、用什么标准验收。比如“交付一个可运行的待办清单网页，包含增删改查，本地能跑起来”，就比“做一个待办应用”好得多。交付标准最好能自动检查：页面能不能打开、接口通不通、测试跑不跑得过。标准越具体，Agent 之间扯皮就越少，返工也越少。

二、角色要少而专，不要一上来就堆人数
很多人一听多 Agent，就先搭八个角色。角色越多，沟通成本越高，上下文也越容易乱。我的经验是先从三到四个角色起步：一个负责拆任务和定接口，一个负责实现，一个负责检查和测试，必要时再加一个负责文档或部署。每个角色只做自己那部分，不要越界。实现的人不要顺手改接口，检查的人不要直接改代码只报问题。角色边界清楚，出了问题才知道该找谁改。

三、共享上下文要有一个单一来源
多个 Agent 一起工作，最怕各写各的版本。代码结构、接口定义、数据格式、关键决策，都应该写在一个共享的地方，随时可查，而不是散落在各自的对话历史里。一个简单的做法是维护一份项目说明：项目目标、技术选型、目录结构、接口清单、已完成和待办事项。每次有重要变更，先更新这份说明，再继续干活。这样新加入的 Agent 不用从头问，旧的 Agent 也不会用过期的信息。

四、设置检查点，而不是等到最后才验收
不要等到所有 Agent 都说做完了才第一次运行。把任务切成几个检查点：接口定好检查一次，核心功能跑通检查一次，完整流程走通再检查一次。每个检查点都要真实运行一次，而不是只看代码“看起来对”。检查点还有一个好处：早发现问题便宜。接口定错了，在第一个检查点改只要改接口；等到最后才发现，可能要推倒重来。

五、给 Agent 留好兜底和成本边界
交给 Agent 的任务要有边界：能调用哪些工具、能访问哪些目录、一次任务最多花多少时间、失败几次就停下来汇报。没有边界的 Agent 可能会一直尝试、一直改代码，最后产出一堆没人敢用的东西。兜底规则也很重要：遇到不确定的需求，先停下来问人，而不是猜一个继续做；遇到删除、覆盖、发布这类不可逆操作，先确认再执行。把这些规则写在任务开始的地方，比事后补救要省事得多。

结语
多 Agent 协作不是人越多越好，而是约定越清楚越好。交付标准、角色边界、共享上下文、检查点、兜底规则，这五个约定定好了，再谈用什么工具、搭几个 Agent，都会顺很多。下次你准备把一个任务交给多 Agent 团队时，不妨先花十分钟把这五个约定写下来，看看是不是比直接开工要稳。