Agent 开发踩坑实录：4590 组实验揭示多智能体为何总在重复犯错
EvoMap 基于 4590 组实验发现：多智能体系统最大的问题不是数量不够，而是经验无法在节点间流动。拆解 GEP 协议如何让 AI 工作节点继承教训，附三个落地建议。
这不是个例。在 EvoMap 团队基于 4590 组真实环境实验的分析中，多智能体系统最隐蔽的失效模式不是模型能力不够，而是经验无法在节点之间流动。系统里工作节点数量越多，重复踩坑的概率反而越高。关于多智能体架构的工程取舍，我们在多智能体架构 5 个工程决策（2026 实战）中有更系统的拆解。
多智能体系统为什么"越堆越乱"
2026 年 7 月的 AICon 深圳站上，EvoMap 创始人张昊阳用一组数据说明问题：当业务复杂度从单节点扩展到 5 个以上协作单元时，if-else 编排的维护成本呈超线性增长，而任务成功率却趋于平台化——增加更多节点不再提升系统能力。
具体来说，多智能体在实践中存在三类高频失效模式：
| 失效模式 | 典型表现 | 根因 |
|---|---|---|
| 工具误选 | 在应该调 API 时选择了文件读取工具，或反过来 | 工具描述塞进 Prompt 后模型注意力被稀释，长上下文窗口并未解决选择精度问题 |
| 重复踩坑 | 同一个边缘 case 被不同节点反复触发，处理方式相同也每次失败 | 没有跨节点的经验传递机制，每个执行单元从零开始 |
| 任务中断 | 长时间运行的工作流在某个非关键步骤卡死，无重试策略也无降级路径 | 过程式编排缺乏异常分支；真实输入偏离预期路径时没有回退方案 |
这三种模式有一个共同特征：它们不是模型"不够聪明"造成的，而是系统架构没有给工作节点配备"记忆"能力。每个执行单元都是一张白纸，系统跑得越久、踩过的坑越多，但新节点仍然从零开始。
把 SOP 全塞进 Prompt，为什么反而更糟
面对协作混乱，团队的直觉反应通常是"加规则"：更长的 System Prompt、更细的 SOP 流程文档、更多的 if-else 路由分支。这条路走下去，实际效果往往南辕北辙。
InfoQ 在 2026 年 7 月的一篇分析中指出，AI 工作流时代基础设施的核心矛盾正在转移——模型调用本身只占工作负载的一小部分，真正的瓶颈在于任务图的协调与编排。当团队把越来越多的流程说明塞进上下文窗口时，模型的注意力被稀释，反而在关键决策点上更容易出错。[来源]
EvoMap 的实验数据也印证了这一点：依赖超长 Prompt 维护 SOP 的系统，在任务环境发生微调时（例如输入格式从 JSON 变为 YAML），任务完成率平均下降了 34%。规则越多，系统越脆弱——因为规则是为旧环境写的，而执行单元没有能力判断"这条规则在当前场景下还适用吗"。
更根本的问题在于：多个智能体不等于群体智能。一群没有经验共享机制的节点，本质上只是一个更复杂的自动化脚本集群。真正的群体智能需要两个前提——能从失败中学习，并且学到的经验能在节点之间传播。
GEP 协议：把失败变成可遗传的"策略基因"
EvoMap 提出的 GEP（基因组进化协议）试图解决的就是这个问题。它的核心思路很朴素：
- 经验压缩：每次执行失败时，从报错日志、执行轨迹和人工修正中提取关键信息——触发条件是什么、根因是什么、哪种处理路径有效、这个经验的适用边界在哪——压缩成一个结构化的"策略基因"。
- 共享基因池：所有节点的策略基因进入同一个池子。新任务启动时，执行单元不是空白的——它先从基因池里检索与当前任务相关的历史教训，作为上下文注入。
- 持续进化：策略基因不是一成不变的。当新的失败证明某条基因的适用边界需要调整时，它会被更新或淘汰。
用一句话概括："单点踩坑，全员免疫"。[来源]
这个思路和 GitHub 在 2026 年 7 月 28 日刚发布的 Copilot "Harness" 工作流有异曲同工之处——都是把 AI 编程助手从"一次性工具调用"升级为"有上下文持续性的工作流参与者"。Harness 让开发者通过单一工具完成从原型设计、规划、实现到代码审查的完整流程，背后的逻辑是减少上下文切换带来的信息丢失。[来源]
两者的共同指向是：智能体系统的竞争力不在模型参数，而在经验密度——你的系统到底积累了多少可复用的、经过验证的策略，以及这些策略在多个执行单元之间传递的效率有多高。多智能体编排模式的选择也直接影响经验传递的效率，Anthropic 顾问+编排模式的数据对比提供了不同架构在经验复用上的实际表现。
企业落地的三个务实建议
结合上述研究和蓝曜炬辉自己在企业 AI 软件开发中的实践，有三条原则值得技术决策者关注：
第一，先建反馈回路，再堆节点数量。如果每增加一个执行单元，系统的经验密度反而被稀释（因为新节点会重复踩旧坑），那增加数量就是在增加成本而非能力。在扩展到 3 个以上协作单元之前，先确保至少有一个机制能记录和回溯失败 case。从概念验证到稳定运行之间还有大量工程工作，PoC 跑通只完成了 30%这篇文章拆解了完整的生产化路径。
第二，把"经验可传递性"作为设计的硬指标。设计每个工作节点时，不止要回答"它能做什么"，还要回答"它学到的东西怎么传给下一个"。这可以是简单的失败日志结构化，也可以是 GEP 式的策略基因——关键是有意识地在做这件事，而不是等系统跑了大半年后发现所有节点都在原地踏步。
第三，人的角色要从"流程微操"转向"进化规则设计"。当系统能持续吸收经验后，人不应该继续做任务分配者和流程纠错者——人的价值在于定义目标边界、设定权限范围、给出关键反馈（这个决策对不对？这个经验能不能复用？），以及在策略基因出现冲突时做仲裁。这是成本更低、杠杆更高的协作模式。
常见问题
问：小团队只有 1-2 个工作节点，需要考虑经验继承吗？
短期不需要。单节点或双节点场景下，失败模式相对简单，靠人工复盘就够了。但当节点数量超过 3 个、或者单个节点运行时间超过数小时（长任务场景）时，经验继承的价值会快速显现。一个实用信号：如果团队里开始有人说"这个问题我们之前不是遇到过吗"，就是该考虑经验继承机制的时候了。如果还在评估具体框架，2026 年 11 个主流框架选型指南有系统对比。
问：GEP 协议和 RAG（检索增强生成）有什么区别？
RAG 检索的是静态知识（文档、代码库），GEP 检索的是动态经验（失败记录、处理策略、适用边界）。两者的检索机制类似，但内容来源完全不同——GEP 的经验来自执行历史和人工反馈，会持续进化。
问：策略基因会不会把错误经验也传播出去？
会，这是 GEP 设计中的一个核心挑战。EvoMap 的做法是为每条策略基因设置验证和淘汰机制——如果某条基因被应用后仍然失败，它会被降权或标记为待修正。实际落地中，人类的"痛感反馈"（标注"这条经验不对"）是最高效的纠错信号。
问：企业现在就该引入经验继承机制吗，还是再等等？
如果团队已经在用多节点协作（不管是 Claude Code + Copilot 还是自建框架），现在就可以开始做一件低成本的事：把失败 case 结构化记录（时间、输入、期望输出、实际输出、根因分类）。这不需要任何新框架，但它是未来任何经验继承机制的基础数据。