你有没有遇到过这种情况：花了一周时间调 AI Agent，换了最强的模型、写了上百版 Prompt，demo 演示的时候效果惊艳，但一到真实场景就翻车——有时候聪明绝顶，有时候莫名其妙地跑偏、死循环、甚至胡编乱造。
成功率死活卡在 70% 左右，怎么调都不上去。
问题大概率不在模型，也不在 Prompt。你缺的是一套 Harness。
Agent = Model + Harness#
先建立一个直觉：模型是大脑，Harness 是让大脑驱动身体稳定工作的神经系统和骨架。
没有 Harness 的 Agent 就像一个天才但没有自律能力的人——偶尔灵光一现，但大多数时候在摸鱼。Harness 的作用就是让这个天才稳定产出，而不是靠运气。
北大博士后卢菁和多个一线工程团队的实践总结出了一套成熟的 Harness 六层架构，下面逐层拆解。
第一层：信息边界 — 给模型一个干净的"工作台"#
模型在噪音里是没法思考的。你有没有试过往 Prompt 里塞了十几页的规则文档，结果模型反而更蠢了？
Harness 的第一件事就是给信息划边界：
- 角色隔离：这个 Agent 现在是谁？做什么事？成功标准是什么？
- 信息分层：哪些是规章制度（不能改），哪些是当前任务（经常变），哪些是中间产物（用完可能要丢）
- 防止自我污染：模型自己生成的错误推理，如果不清理，会在后续轮次中被当成"事实"继续引用
实际操作中，这意味着你要把上下文分成几个独立区块，而不是把所有东西堆在一起。
第二层：工具系统 — 别让模型被返回结果淹没#
大模型本质上是个文本预测器，给它接上工具才有手有脚。但这里有个反直觉的陷阱：工具给多了，模型会乱用；工具返回的内容多了，模型会被淹没。
举个例子：你让 Agent 查数据库，SQL 查询返回了 200 行结果。如果你把这 200 行原封不动地丢回给模型，它的注意力会被分散，核心信息反而被淹没。
好的 Harness 会做二次过滤：先把工具返回的结果提炼、摘要，只把模型需要的"干货"喂回去。这就像一个优秀的助理——不是把所有邮件都转发给老板，而是先筛选、归纳，只给老板看真正需要决策的内容。
第三层：执行编排 — 给 Agent 铺一条铁轨#
没有编排的 Agent 是"想到哪做到哪"，有编排的 Agent 是沿着轨道走。
一个靠谱的执行流程应该是：
- 理解：先消化任务，确认理解无误
- 分析：拆解步骤，制定计划
- 执行：按计划逐步操作
- 自检：检查结果是否达标
关键在于自检不通过时的处理：不是让模型"再试一次"（它大概率会犯同样的错），而是强制回退到上一个稳定状态，换个策略重新来。
这和传统软件的 try-catch 逻辑一样——不是出了错就重试，而是要有明确的回滚策略。
第四层：记忆与状态 — 让 Agent 不再"失忆"#
你跟 Agent 说"帮我改一下刚才那段代码"，它问你"哪段？"——这就是状态管理缺失的典型症状。
Harness 需要管理三层记忆：
| 层级 | 内容 | 生命周期 |
|---|---|---|
| 对话状态 | 当前在做什么、用户刚说了什么 | 单次对话 |
| 执行结果 | 上一步跑了什么、成功还是失败 | 单次任务 |
| 用户偏好 | 这个用户喜欢什么风格、常用什么技术栈 | 跨会话 |
三层记忆要隔离管理，否则短期的执行噪音会污染长期的用户画像。
第五层：评估与观测 — 别让 Agent 自己给自己打分#
Agent 有个致命问题：它总是"自我感觉良好"。你让它写代码，它写了，然后告诉你"完成了"——但你跑一下发现根本编译不过。
成熟的 Harness 会引入一个独立的 Evaluator（评估者）。这个评估者不是 Agent 自己，而是另一个独立的模块，甚至可以是另一个 LLM：
- 代码生成场景：Evaluator 跑一下测试用例，看覆盖率
- Web 操作场景：让 AI 模拟用户去点击页面、检查结果
- 内容生成场景：检查事实准确性、格式合规性
核心理念：运动员和裁判不能是同一个人。
第六层：校验与恢复 — 失败不是终点，重头再来才是#
真实世界里，API 超时、格式错误、网络抖动是常态。Harness 的核心价值在于：失败后不慌，自动恢复。
- 输出格式不对？自动解析 + 重试
- API 超时？换一个备用方案
- 执行到一半崩了？回滚到最后一个检查点，从那里继续
这就像游戏里的自动存档——死了不用从头开始，从上一个存档点继续就好。
硅谷怎么做的？两个典型案例#
Anthropic：换个"脑子"继续干#
Anthropic 发现一个很有意思的现象：模型在执行长任务时会出现**“上下文焦虑”**——上下文窗口快满了的时候，模型开始丢细节、急着收尾、草草了事。
他们的解法很激进：Context Reflection。不是在原地压缩上下文，而是直接开一个全新的 Agent 实例，把关键状态交接过去，让新 Agent 在干净的环境里继续工作。
同时他们严格遵守生产与验收分离：Planner（计划者）和 Generator（执行者）负责干活，Evaluator（独立评估者）只盯着环境反馈打分。干活的人和检查的人是分开的。
OpenAI：工程师变成了"环境设计师"#
OpenAI 的 Agent 团队里，工程师已经不写业务代码了。他们的日常工作变成了三件事：
- 把模糊的需求拆解成 AI 能理解的小任务
- 当 Agent 失败时，不问"模型哪里不够努力"，而是问**“环境里缺了什么结构性能力”**
- 把数万字的规则文档做成目录，让 AI 按需查询（类似 Skills 理念），避免一股脑全塞进上下文
这背后的思维转变是：不再优化模型的行为，而是优化模型工作的环境。
你的 Agent 卡在哪一层？#
最后给一个快速自查清单：
- 📍 信息混乱 → 第一层（信息边界）没做好
- 📍 工具调用乱七八糟 → 第二层（工具系统）需要二次过滤
- 📍 执行没章法 → 第三层（执行编排）缺少流程约束
- 📍 多轮对话就失忆 → 第四层（记忆与状态）没有隔离管理
- 📍 自以为做完了其实没做对 → 第五层（评估与观测）缺少独立评估者
- 📍 一错就崩、从头再来 → 第六层（校验与恢复）缺少容错机制
不要一上来就六层全做。先定位卡在哪一层，单点突破，效果立竿见影。
参考来源：code秘密花园 欢老师分享 —《最近爆火的 Harness Engineering 到底是个啥？》及 AI 工程化相关讲座