多智能体配合开发的问题与解决方案

先说结论：多智能体配合开发，难的从来不是"多开几个模型"，而是四个接口的设计——谁定方案、怎么传令、怎么验真、失忆了怎么办。这四个接口没设计好，加几个 Agent 只会把错误放大几倍；设计好了，两个角色就够跑完一个十几张任务卡的完整开发周期。

下面这份清单来自一个真实跑通的桌面应用项目。先把这套协作的结构说清楚，免得读者误判：

• 业主：只做产品决策和验收签字，不看代码，不写代码；
• 出卡方 Agent：定方案与判据、出任务卡、独立复核证据、下裁决；
• 执行方 Agent：一个只能通过本地文件交互的桌面 Agent——无对外 API、无 webhook、不能被外部主动调用，只能看到一个 GUI 窗口和磁盘上的文件；
• 巡查 Agent：定时读信箱与仓库，判断进展，无事不打扰。

也就是说，干活的两端都是 Agent，人只在最外层。整个过程做了十几张卡，一张卡一个交付周期，没有一次是靠执行方"说做完了"来结案的。

下面按问题出现的频率排。

问题 1：执行方没有 API，传令和回执都没有天然通道

现象：能给执行方发消息的唯一途径是一个 GUI 窗口；它回话的唯一途径也是同一个窗口。窗口一关、会话一切、上下文一压缩，传令记录就没了。

做法：把协作降到文件层，双方只认文件。

• 建一个信箱文件，双方只往里追加，消息编号递增（MSG-95、MSG-96…），一条消息一个标题行，末尾固定写 STATUS:。
• 传令只写"读信箱第 N 条"这类指针，不在聊天窗口里传正文——窗口消息会丢，文件不会。
• 每轮开工的回执必须落文件：一行写清"本轮任务=哪张卡、依据=哪条指令、认锁的提交号、状态"。这一行是后面所有判断的锚点。

收益：一个周期下来信箱长到 80 多 KB、近百条消息，任何一条"它当时到底收到没收到"都能事后翻账，不用靠回忆。

问题 2：消息发出去，无法确认对方收到了

现象：这是最折磨人的一条。窗口注入之后画面像素级没变，看起来像没送到；重发一次，对方可能收到两条。

踩过的坑：拿"窗口抓帧 MD5 恒定"当作"没送达"的判据。这个判据是错的——某些抓帧方式拿的是窗口静态缓存，画面变了 MD5 也可能不变。同理，"窗口安静"也不能当"它停工"的判据，它可能只是这一轮说完话转空闲了。

做法：判活三件套，同时看，互相交叉。

1. 信箱有没有新增回执：最硬的信号，只要真开工一定会写；
2. 工作目录有没有写入：文件 mtime 是最诚实的进度条；
3. 进程 CPU 增量：40 秒内进程组累计涨了 5.9 秒，说明活着；十几个进程一动不动，才是真挂。

窗口画面只作参考，不作判据。

发送侧的教训（很具体但很值钱）：唤醒执行方时，先取窗口矩形、点击会话输入框坐标、再设剪贴板粘贴、最后发回车。有一次按窗口百分比点了 43%，结果点到左下角头像，弹出了账号面板、输入框根本没拿到焦点——看起来"发了"，其实一个字都没进去。改到帧内输入框中心（约横向 67.5%、纵向 78.9%）之后一次就成。坐标别猜，先抓帧量。

问题 3：执行方会自报"达标"，而数据经不起独立跑一遍

现象：交付报告写得很齐——几轮 PASS、附几个数字、结论达标。出卡方自己跑一遍，会发现轮次不够、样本被挑过、或者跑的是旧产物。

做法：三条固定动作，一条都不能省。

• 先核新鲜度：构建产物时间必须晚于源码最后一次改动，否则说明对方没有真的重建；
• 自己跑：验收脚本、单元测试、端到端测试全部按原命令自己跑，判据只认自己跑出的原值；要求对方给三轮原值而不是一句"PASS"，因为单轮绿可能是环境碰巧；
• 自己解包：报告说"导出 PDF 86 页"，不看对方的脚本结论，按 /Type /Page 独立数一遍；报告说"docx 套了 16 个样式"，就解 word/styles.xml 数 w:styleId。数对得上，这条才算成立。

真实收益：有一轮对方自报的 86 页、16 个样式、0 字符差，出卡方独立复算全部对得上，那一轮才敢结案；另一轮它漏了一个"目录 42 条对不上"的硬伤，是出卡方自己跑出来的。

问题 4：上下文一压缩就失忆，然后开始重做已结案的事

现象：周期一长（十几张卡、几天时间），执行方会重跑很早以前已结案的模块，或者把已通过的门禁再跑一遍，然后宣布"发现新问题"。既烧钱又污染结论。

做法：把记忆外置成三个文件，任何一轮都从这三个文件恢复，不依赖上下文。

再配一条纪律：卡面上写死"不许重跑已结案任务、不许私改验收脚本与断言、必须每轮开头一行自证"。跑偏一眼就能看出来，一条指令叫停，不讨论、不解释。

问题 5：执行方每说完一段就转空闲，等下一句指令

现象：最容易被误判成"停工"的一条。它回完话就停在那儿；窗口显示"等待模型响应"才是它在跑，输入框空着、发送键是箭头，是它在等人。中间隔着 20 到 30 分钟的零写入很正常——它在读代码、在想设计。

做法：把"自主推进"写成常驻约定，而不是靠每次唤醒续命。

• 指令里明确"不等回复、直接推进，每完成一节写信箱一行进展"；
• 只有三种情况允许它停下来：遇到需要出卡方裁决的取舍、时间盒到点、交付完成；
• 判定"是不是真在跑"看上一节那三件套，不看窗口。

反思一句：如果每次都要有谁来点一下输入框才能推进一段，那这套协作的成本结构是错的——人的注意力成了瓶颈。约定写清楚比唤醒技巧重要。

问题 6："分级到底放配置还是放代码"——取舍被推给上级，而上级必须给得住理由

现象：需求里有一条"检查项全部外置为配置"。落地时执行方发现冲突：项目里有一张"全仓唯一的错误码→严重程度映射表"，是上一张卡已签收的门禁；新增的码如果不进这张表，就会被"未知码按提示兜底"静默降级，该拦的不拦。执行方给了两个方案让出卡方选，没有自己拍。

这个处理是对的——风险点必须上报，不许自作主张。

但裁定必须给得住：最终选了"进唯一表、分级不外置"，理由是——需求里"外置"的目的是"换一套模板不用改程序"，而模板的差异只落在数值上；"哪一项算阻断"是产品级的安全口径，不随模板变化，它就该待在那张唯一表里。

并且顺手补一个对方没想到的洞：既然存在"未知码兜底成提示"，那就要有一条断言把这个口子堵死——凡检查产出的码必须全部存在于映射表内，缺一条直接判失败。不加这条，以后新增码漏登记，一样静默变提示，谁来兜？

这条经验值得抄走：对方上报的冲突，只裁"选哪个"是不够的，还要检查它给的选项里有没有第三个答案。

问题 7：一个开发周期里，裁决越多越乱

现象：如果每发现一个问题就下一次裁决、加一条要求，执行方会在两版要求之间来回改，前面做的东西反复推翻，成本翻倍。

做法：三条限流规则。

• 一次开发周期内最多插一条裁决，且只允许两种情况触发：已签字门禁被破坏、或证据与数值不实。其它问题记进挂账清单，留到下一张卡。
• 裁决只有三种：通过、有条件通过（必须列出可关闭的关闭条件）、不通过（列出返工项）。不许出现"基本通过""大致没问题"。
• 有条件通过的关闭条件，要么当场关闭，要么明确转到下一张卡，不许悬空。

一个可以照抄的分工表

这个分工的关键在最后一行：巡查要便宜。一个小时内没有变化就写一行状态结束，别为了"看起来在管"而每次全量重启一轮。

最后：四个接口，缺一个都跑不长

回头看，这套东西能跑完十几张卡，靠的不是模型多强，是四个接口各自成立：

1. 传令靠文件，不靠窗口；
2. 回执必须落文件，一行锚定；
3. 验真只认自己跑出的原值与自行解包的文件字节；
4. 记忆外置成三个文件，上下文丢了也能原地恢复。

多智能体配合开发真正要防的不是"模型不够聪明"，而是这四件事里任何一件悄悄失效——失效的时候，它不会报错，它只会看起来一切正常。