多开几个 Agent，为什么项目反而更容易失控？

你把一个重要任务同时交给两个 Agent。

一个负责实现，另一个负责检查。听起来像是把速度和质量都翻了一倍。

很快，第一个改了入口，第二个也顺手改了同一段代码；一个根据旧文件提出风险，另一个已经改变了前提；两边都说自己完成了，却使用不同的验收标准。最后，你面对的不是两份可以互相印证的结果，而是两条需要重新调查的岔路。

问题不在 Agent 数量。问题在于，多开窗口只增加了并行输出，没有自动产生协作。

真正的协作必须先回答三件事：谁拥有写入权，谁只负责挑战结果，双方的证据如何汇到同一个完成标准。

并行解决的是产能，协作解决的是责任

两个 Agent 同时工作，最直观的收益是多做一些事。但只要任务之间共享文件、状态或决定，并行就会带来新的合并成本。

如果两边都能修改同一个范围，每一次局部优化都可能改变另一边正在依据的现实。如果两边都能宣布完成，失败时就很难判断是谁漏掉了边界。如果两边提交的只是各自的总结，你还要亲自把两套口径翻译成一个结论。

因此，多 Agent 是否值得使用，不取决于窗口数，而取决于责任能否保持唯一。

最简单也最可靠的结构通常不是两个执行者，而是一个执行者和一个复核者。

执行者负责让结果成立。复核者负责寻找结果不成立的证据。

这两个角色不是强弱关系，也不是一个干活、一个点评。它们处理的是两种不同风险：前者防止任务没人推进，后者防止主路径的成功掩盖边界上的失败。

第一条边界：一项任务只有一个写入所有者

高风险任务最怕模糊的共同所有权。

“你们都可以改，最后合并一下”把最困难的判断留到了最后：冲突发生时以谁的现实为准？两个修改都能运行时选择哪一个？谁负责确认没有破坏原有行为？

更清楚的做法是，在开始前指定唯一执行者。只有它可以修改任务范围内的代码、配置或内容，并负责从现状审计一直走到最终验收。

唯一写入权并不意味着其他 Agent 不能贡献。它意味着贡献必须以建议、证据或可复现反例的形式交给执行者，而不是直接改变共享现实。

这样，主路径始终只有一位所有者。出现新证据时，也只有一个地方负责吸收它、修改方案并重新验证。

第二条边界：复核者默认只读

复核者最有价值的能力，不是再写一版实现，而是站在实现之外攻击它的假设。

它可以检查真实代码和最终产物，可以运行不会改变状态的测试，可以比较需求与结果，也可以构造边界条件。但默认不修改文件、不重写方案、不替执行者接管主路径。

只读不是限制复核质量，恰恰是在保护复核独立性。

一旦复核者开始顺手修问题，它就从证据提供者变成了第二个执行者。原本清楚的责任重新混在一起，执行者可能不知道现实已经变化，复核结论也可能只证明复核者自己的版本成立。

如果复核发现必须修改的缺陷，它应提交一份可执行的反例：在哪个输入或状态下失败，如何复现，预期与实际有什么差异，证据来自哪里。由执行者决定如何修复，并重新交付同一完成标准下的结果。

第三条边界：双方必须对准同一个终点

角色分开以后，还需要一个共同坐标。

如果执行者以测试通过为完成，复核者却以真实用户流程为完成，两边即使都很认真，也会得出无法合并的结论。

开始前应先写下可观察的完成标准。例如：最终用户能从正式入口完成目标动作；原有关键行为不变；最终生成物而不只是源文件通过检查；已知高风险边界有明确证据。

执行者围绕这些条件交付结果。复核者也只围绕这些条件寻找反例。它可以补充遗漏的风险，但必须说明这个风险会破坏哪一条完成条件，而不是另起一套审美或架构标准。

这样，两份输出才真正可以合并：执行者给出成立证据，复核者给出反证或“在已检查范围内未发现反例”。

复核交付的不是意见，而是可复现证据

“这里可能有问题”“我觉得结构不够好”“建议再优化一下”，这些话会增加焦虑，却很难改变判断。

高质量复核至少包含四项信息。

第一，明确对象：哪一个用户动作、文件、状态或最终产物。

第二，复现条件：在什么输入、权限、尺寸或时序下出现。

第三，观察结果：实际发生了什么，它与完成标准如何冲突。

第四，证据位置：命令输出、截图、日志、代码路径或平台回执在哪里。

有了这些信息，执行者不需要猜复核者的意思，也不需要接受一个无法验证的权威判断。证据能直接进入修复与再验收。

什么时候值得加入第二个 Agent

并不是每个任务都需要复核者。

改一处低风险文案、整理一段明确资料，第二个 Agent 可能只增加沟通成本。任务越小、边界越清楚、失败越容易恢复，单一执行者通常越合适。

当错误代价高、影响范围跨多个入口、结果难以凭肉眼判断，或执行者容易被自己的实现假设困住时，独立复核才更有价值。比如发布前的最终用户流程、权限边界、数据迁移、支付动作、不可逆操作，以及会被大量用户直接看到的内容与界面。

判断标准不是“能不能多开”，而是第二种独立视角能否发现一种执行者不容易发现、且会改变最终决定的失败。

SoloMap 如何把协作留在同一条路径上

SoloMap 让你从一个具体路线图环节启动本地 Agent 对话，把本轮目标、完成标准、历史交接和执行结果留在项目旁。需要额外判断时，可以加入可选的第二 Agent 做只读复核与风险门禁。

重点不是让更多 Agent 同时占满终端，而是让它们看到同一个环节边界，承担不同责任，并把证据交回同一处。

执行者仍然负责交付。复核者仍然只负责挑战。最终是否接受结果，仍然由掌握产品方向的你决定。

工具可以降低交接成本，但不能替你决定责任属于谁。

用十五分钟写两张责任卡

选一个即将开始的高风险任务，不需要真的启动两个 Agent。先写两张卡。

第一张是执行者责任卡，写四行：我要交付的结果；我唯一可以修改的范围；必须保持不变的边界；证明完成所需的证据。

第二张是复核者责任卡，也写四行：我只读检查的范围；我要重点寻找的失败；反例必须怎样复现；我不能执行的写入动作。

最后，把两张卡的证据栏对齐。它们必须指向同一组完成标准，而不是各自发明一个终点。

如果写完后仍有两个角色可以修改同一个对象，边界还不清楚。如果复核者只能给出“看起来不错”，证据格式还不清楚。如果两边的完成定义不同，任务还不适合并行。

真正的多 Agent 协作，不是让更多窗口同时说话。

它是让每个角色只承担一种清晰责任，让不同证据最终支持同一个决定。

如果你正在用本地 AI Agent 推进真实项目，可以在 VS Code Marketplace 安装 SoloMap。挑一个高风险环节，先写下这两张责任卡，再决定是否需要第二个 Agent。