《Agent记忆错误的100个案例手册》第 46–50 案例
本辑为《Agent记忆错误的100个案例手册》连载内容。
案例 46：多Agent与协作记忆错误｜consensus-protocol-deadlock
场景
三个Agent组成委员会对”是否批准用户贷款”进行投票。规则要求2/3多数同意。Agent_A基于用户的信用记录反对，Agent_B基于用户的收入证明支持，Agent_C基于抵押物价值支持。Agent_A要求重新评估收入证明，Agent_B要求重新评估信用记录，Agent_C等待前两者达成一致。
错误表现
三个Agent陷入无限循环的”要求重新评估”，没有明确的终止条件。用户的贷款申请被挂起数小时无响应。
解决方案
- 设置最大迭代轮次：超过N轮未达成共识时，升级到人工裁决或采用预设的默认决策
- 引入”仲裁Agent”：具有更高权限，在僵持时做出最终裁决
- 设计”证据权重”机制：对不同证据源赋予可信度权重，减少主观分歧
原理
多Agent共识机制（如Raft、Paxos的简化版）在没有领导者或超时机制时可能死锁。人类委员会也有类似问题，需要主席或时限来打破僵局。
案例 47：多Agent与协作记忆错误｜subagent-result-aggregation-loss
场景
主Agent将任务分解为3个子任务，分配给3个子Agent。子Agent_1返回”方案可行，但有风险X”，子Agent_2返回”方案可行”，子Agent_3返回”方案可行”。主Agent的聚合逻辑采用”多数表决”，将”可行”作为最终结论，但忽略了子Agent_1提出的风险X。
错误表现
主Agent向用户汇报”方案可行”，未提及风险X。用户执行方案后遭遇风险X，质疑Agent为何未提前警告。
解决方案
- 在聚合结果时实施”风险优先”原则：任何子Agent提出的风险/反对意见都必须显式呈现
- 使用结构化聚合：要求每个子Agent返回{“结论”: "", “风险”: [], “置信度”: 0-1}，主Agent合并所有风险列表
- 对低置信度或存在分歧的子结果进行”二次审查”：指派额外Agent专门评估争议点
原理
简单的多数表决在关键风险场景下是危险的。“少数派报告”（Minority Report）往往包含最重要的警告信息，不能被多数意见淹没。
案例 48：多Agent与协作记忆错误｜handoff-context-compression-distortion
场景
Agent_A处理用户的前半段需求后，将”状态摘要”交接给Agent_B。摘要中包含了用户的需求概述，但省略了用户强调的一个关键约束：“预算不能超过5000元”。Agent_B基于不完整的摘要继续处理，推荐了6500元的方案。
错误表现
用户看到方案后质问”我不是说了预算5000吗？“，Agent_B完全不知道这个约束，只能道歉并重新处理。
解决方案
- 在状态摘要中显式标记”硬约束”（Hard Constraints）：这些约束必须原样传递，不能被压缩或改写
- 实施”约束校验”机制：Agent_B接收摘要后，向Agent_A确认关键约束列表的完整性
- 使用不可压缩的”约束令牌”：在系统层面为硬约束分配特殊标记，确保其在任何压缩过程中保留
原理
上下文压缩（如摘要）不可避免地会丢失信息。但某些信息（约束、承诺、安全规则）是”不可丢失的”，需要在架构层面给予特殊保护。
案例 49：多Agent与协作记忆错误｜agent-capability-advertisement-mismatch
场景
服务注册中心中，Agent_A注册了自己的能力为”能处理所有PDF相关任务”。实际上Agent_A只能处理文本型PDF，不能处理扫描版PDF（图片）。编排器收到”处理扫描版PDF”的任务后，基于注册信息分配给了Agent_A。
错误表现
Agent_A尝试处理失败后报错，任务被重新分配，整体延迟增加300%。频繁的错误分配降低了系统吞吐量。
解决方案
- 实施”能力细化注册”：Agent注册能力时需提供详细的能力边界（如”PDF：仅限文本型，不支持扫描版/加密版”）
- 在任务分配前进行”能力预检”：Agent收到任务后先检查自身能否处理，不能处理时立即拒绝并说明原因
- 建立”能力-任务匹配度评分”：基于历史成功率动态调整Agent的能力评分，而非静态注册
原理
服务注册中心的能力描述往往是粗粒度的。粗粒度描述导致任务误分配，浪费计算资源并增加延迟。细粒度能力建模是高效编排的前提。
案例 50：多Agent与协作记忆错误｜multi-agent-feedback-loop-oscillation
场景
Agent_A和Agent_B协作生成内容，Agent_A先生成初稿，Agent_B审核并提出修改意见，Agent_A根据意见修改，Agent_B再次审核。Agent_B的审核标准不稳定（如对”语气正式程度”的判断前后不一），导致Agent_A在”更正式”和”更口语化”之间反复修改。
错误表现
经过10轮迭代，输出仍在两个版本间振荡，无法收敛。用户等待了5分钟仍未得到最终结果。
解决方案
- 设置最大迭代次数和收敛条件：连续两轮修改幅度小于阈值时强制终止
- 引入”评审标准冻结”：Agent_B在首次审核时输出评审标准清单，后续审核严格按清单执行
- 使用”差异评审”：Agent_B只评审当前版本与上一版本的差异，而非全量重审
原理
多Agent协作中的反馈回路如果没有收敛机制，可能出现振荡（Oscillation）。这类似于控制系统中的不稳定反馈，需要阻尼机制（如阈值、标准冻结）来确保收敛。
F. 记忆注入与安全问题（案例51-60）
来源：Agent Search