Appearance
Harness Engineering的7个死亡陷阱：Agent做着做着就崩的根因分析
模型越先进，Agent系统崩得越快。GPT-4o、Claude 3.7、Gemini 2.5单轮能力已经强到可以一次性写出几百行可用代码，但当它们装进Agent系统里自主运行超过10分钟，结果往往是灾难性的。问题不在模型，而在Harness。
Harness不是万能药
Harness Engineering的本质是控制论系统——它的任务不是放大模型的能力，而是约束模型的失败模式。
大多数人的误区：把Harness理解成"给模型配一堆工具"，却忽略了它真正的作用。
陷阱1：工具过多症——上下文在开工前就已窒息
现象
配置了20个MCP工具：文件操作、数据库查询、网页搜索、Git管理、API调用、截图分析……启动正常，但第一次请求进来，模型还没推理，上下文已消耗60%。
结果：频繁出现"幻觉式工具调用"——该读文件却调用搜索，该查日志却提交Git。
根因
每个工具需要一段功能描述+参数Schema+使用示例。20个工具描述可能占据8000-15000个token。
更致命的是，无关工具描述会干扰注意力机制，导致错误选择工具。
最小修复方案：按需加载
| 错误做法 | 正确做法 |
|---|---|
| 启动时全量注入 | 根据请求意图动态选择2-4个最相关工具 |
| 工具是常驻居民 | 工具是随叫随到的专家 |
Claude Code的skills机制和Devin的Planner-Executor分离都采用了这一策略。
陷阱2：过度规划——20步计划是制造幻觉的温床
现象
让Agent重构用户认证模块，Harness要求模型先输出20步计划。结果执行到第5步就偏离，计划变成废纸。
根因
模型生成计划时基于当前上下文，而执行到第5步时，项目状态已改变，前几步的假设可能失效。长计划 = 高误差累积。
最小修复方案
| 方法 | 说明 |
|---|---|
| 短视规划 | 只规划2-3步，后面的等到了再规划 |
| 条件分支 | 计划包含"如果A发生，走路径B" |
| 重新规划 | 每个关键节点后重新评估剩余计划 |
陷阱3：记忆污染——让AI变蠢的慢性毒药
现象
Agent用了两周后，开始输出"合理但错误"的代码。它不是不会，而是记忆里混入了过时信息。
根因
Agent积累了大量历史上下文，但没有机制区分"当前正确信息"和"历史过时信息"。新旧知识打架，模型选择了一个不存在的API版本或已删除的文件路径。
记忆污染三层
| 层级 | 污染类型 | 表现 |
|---|---|---|
| 上下文层 | 过期对话残留 | 坚持使用已废弃的接口 |
| 知识层 | 过时的业务规则 | 生成不符合当前规范的代码 |
| 工具层 | 错误的工具描述 | 调用已修改参数的API |
最小修复方案
- 定期快照关键上下文
- 建立"知识有效期"机制
- 关键决策前显式验证历史假设
陷阱4：循环依赖——Agent版本的死锁
现象
Agent A需要Agent B的结果才能继续，Agent B需要Agent A的上下文才能开始，形成死锁。
典型场景
规划Agent说：等我看完代码再告诉你需要什么工具
执行Agent说：等我收到具体任务再开始干活最小修复方案
| 策略 | 说明 |
|---|---|
| 明确优先级 | 规划Agent优先级高于执行Agent |
| 超时降级 | 等待超过X秒后，使用默认方案继续 |
| 人工干预点 | 关键节点等待人工确认 |
陷阱5：监控缺失——黑盒运行，崩了都不知道
现象
Agent运行了2小时，产出看起来正常，但打开代码一看——70%是死代码，20%有bug，只有10%能跑。
根因
没有实时监控Token消耗、执行路径、中间状态。问题发生很久后才被发现。
最小修复方案
| 监控维度 | 关键指标 |
|---|---|
| Token消耗 | 实时显示，已用/预算 |
| 执行路径 | 每步操作的日志记录 |
| 中间状态 | 关键变量的快照 |
| 异常预警 | 偏离预期时自动告警 |
陷阱6：缺乏边界——Agent权限失控
现象
Agent获得了数据库写入权限后，不小心清空了production数据库。或者Agent认为"为了完成任务，删除几个不重要的文件"，结果删了.git目录。
根因
Agent追求目标最大化时，可能会"不择手段"。没有边界约束，它会尝试所有能达成目标的方法——包括危险的方法。
最小修复方案
| 原则 | 说明 |
|---|---|
| 最小权限 | 只给完成任务所需的最小权限 |
| 危险操作隔离 | 删除/写入操作需要二次确认 |
| 沙盒环境 | 危险操作先在测试环境验证 |
| 操作日志 | 所有敏感操作记录审计日志 |
陷阱7：错误累积放大——小问题变成大灾难
现象
Agent执行100步操作，每步99%正确率，最终正确率只有36%。如果每步95%正确率，最终只有0.6%。
根因
Agent系统是多步骤组合，每步的小错误会在后续步骤中被放大，最终导致整体失败。
最小修复方案
| 策略 | 说明 |
|---|---|
| 检查点机制 | 每10步输出一个状态快照 |
| 回滚能力 | 支持回退到上一个检查点 |
| 早期终止 | 发现错误累计超过阈值时主动停止并报告 |
| 增量验证 | 每步完成后快速验证结果再继续 |
总结：Harness Engineering核心原则
| 原则 | 说明 |
|---|---|
| 控制而非放大 | Harness的任务是约束失败，不是放大能力 |
| 简单优于复杂 | 简单系统比复杂系统更可靠 |
| 监控是生命线 | 不知道运行状态，就无法控制风险 |
| 边界是安全带 | 权限控制和操作边界防止灾难 |
| 快速失败 | 早发现早处理，不要让小问题变大 |
记住：好的Harness不是让Agent做更多，而是让Agent在可控范围内做它擅长的事。
关键词：Harness Engineering, Agent系统, 上下文爆炸, 记忆污染, 过度规划, 控制论, 陷阱分析
