AI Agent 老是出错？不是模型太笨，是你缺了这层设计
你有没有遇到过这种情况：
用 GPT-4o 或者 Claude 搭了个 Agent，测试的时候跑得挺好，但一到复杂任务就翻车——中途忘记前面做了什么、步骤跳过、自我评价说"完成了"但其实根本没完成。
你开始怀疑：是不是模型不够聪明？是不是提示词写得不够好？
都不是。
问题在于你少了一层东西：Harness（线束）。
从提示词工程到 Harness 工程
AI 应用开发经历了三个阶段：
第一阶段：提示词工程（Prompt Engineering） 核心问题是"怎么问"。调整措辞、加上下文、改变语气——本质上是在优化一次对话。
问题是：它很脆弱，没有持久性，下一次对话就全忘了。
第二阶段：上下文工程（Context Engineering） 核心问题变成了"给模型看什么信息"。RAG、长上下文、记忆系统都属于这个范畴。
但它仍然是无状态的，你很难控制模型在多步骤任务中的行为。
第三阶段：Harness 工程（Harness Engineering） 核心问题是"如何结构化执行过程"。
Harness，直译是"线束"，来自汽车工程——那条把电气系统捆在一起、确保每个组件按正确顺序运行的系统。
对 AI Agent 来说，Harness 就是那个把模型、工具、状态、验证捆在一起的执行骨架。
Agent 失败，不是因为模型太弱，而是因为系统没有定义边界。
七层架构：一个生产级 Agent 的骨架
一个能真正跑在生产环境的 Agent 系统，需要七层结构：
第一层：认知层（Cognition）
给模型的不是百科全书，是一份工作描述。
系统提示要明确三件事：
- 这个 Agent 的角色是什么
- 成功的标准是什么
- 禁止做什么
同时，每次执行的任务简报要动态生成，把模型的注意力锁定在当前步骤，而不是让它自由联想。
第二层：工具层（Tools）
工具调用不能直接把原始输出塞给模型，中间需要三道处理：
- 排序：用相似度或 BM25 评分，把最相关的结果排前面
- 去重：删掉重复内容
- 截断：硬上限截断，防止工具输出把上下文撑爆
这一层相当于工具和模型之间的适配器，原始数据进来，干净数据出去。
第三层：契约与接口层（Contracts & Interfaces）
模型说话用概率，系统必须用类型。
每一个系统边界——模型输入、模型输出、工具调用——都要有严格的 JSON Schema。
数据跨边界之前，先做验证。这样能捕获那些"看起来正确但结构已经漂移"的沉默故障，比方说模型输出了个字符串，但系统期待的是数组。
第四层：编排层（Orchestration）
Agent 的执行流程不能让模型自由决定，要用有向无环图（DAG）或状态机来约束。
比如研究任务的标准流程：
规划 → 收集 → 草稿 → 验证模型可以建议下一步做什么，但系统决定哪些动作被允许执行。非法的状态转移，直接拦截。
第五层：记忆与状态层（Memory & State）
状态必须显式存在于上下文窗口之外。
分两层管理：
- 工作记忆：当前步骤需要的上下文，存在内存里
- 持久化状态：用结构化文件（比如
state.json）追踪所有待办、进行中、已完成的子任务
这样，就算上下文被清空、Agent 重启，也能从中断的地方继续跑。
第六层：评估与观察层（Evaluation & Observation）
验证不能只靠一种方式，要用异构检查：
- 规则检查：JSON Schema 验证结构
- 工具执行：真正跑代码、跑测试，看有没有报错
- LLM 评判：只用于主观判断，比如文风是否合适
重要的是，不要用同一个模型既生成内容又评判内容。
第七层：约束与恢复层（Constraints & Recovery）
失败是必然的，问题是失败之后怎么办。
核心原则：幂等性。
任何步骤失败后，都能安全重试，不会破坏整体状态，也不会把之前完成的工作重做一遍。
这一层建议最先实现，因为没有它，整个系统都脆弱。
四个你一定会踩的坑
坑一：上下文焦虑
当上下文用量超过 70% 时，模型开始变得"慌张"——跳过步骤、过早结束、输出质量下降。
不是模型变笨了，是它在帮你"省空间"。
解决方案：触发上下文重置。
1. 把当前状态保存到磁盘（state.json）
2. 终止这个 LLM 实例
3. 用干净的上下文启动新实例
4. 读取 state.json，从中断处继续就像给电脑重启一次，但进度不丢。
坑二：自我评分幻觉
让模型评价自己生成的内容，它会倾向于给自己打高分。
这不是模型在骗你，而是它没有足够的"距离感"来发现自己的问题。
解决方案：生成器和评估器分离。
在任务开始前，让两者协商一份"成功定义"：具体、可测试的验收标准。然后评估器基于干净的上下文独立运行，不继承生成器的前提假设。
更重要的是：评估器要真正执行验证——运行代码、跑浏览器测试——而不只是看内容像不像对的。
坑三：正确性幻象
当系统给出的约束互相矛盾时，模型不会报错，而是优化"看起来正确"——格式对了，但实质上没有解决问题。
解决方案：给模型客观反馈，而不是情感化评价。
不要说"这个答案不够好"，要给：
- 编译错误的堆栈信息
- 失败的测试用例
- 具体的 Schema 不匹配报告
给模型问题，而不是给它"负面评价"。
坑四：记忆膨胀
长时间运行后，持久化状态文件会越来越大，充满重复和矛盾的条目，模型读起来越来越慢，也越来越容易犯错。
解决方案：定期整合（Consolidation）。
系统空闲时，触发一个后台任务：
- 读取原始日志
- 去重、解决矛盾
- 压缩状态文件
实际案例：32K token 的状态文件，整合后压缩到 7K，信息没有丢失。
最小可行实现
不需要一次把七层全搭好。从这四件事开始：
| 组件 | 作用 |
|---|---|
state.json | 把任务状态持久化到上下文窗口外 |
| 重试包装器 | 让每个步骤都能安全重试 |
| Schema 验证 | 在边界处捕获结构漂移 |
| 工具输出截断 | 防止上下文被撑爆 |
这四件事能解决 80% 的 Agent 不稳定问题。
为什么这个视角重要
大多数人遇到 Agent 问题，第一反应是换个更大的模型，或者改提示词。
但真正的瓶颈往往不在模型，而在系统。
Harness 工程的核心思想是：让模型做它擅长的事（推理和生成），让系统做系统该做的事（约束、验证、恢复）。
模型和系统各司其职，Agent 才能真正稳定地运行在生产环境里。
如果你正在构建 AI Agent，不妨对照这七层检查一下：你的系统缺了哪几层？