Harness 工程：Agent 卡在 70 分，多半不是模型不够聪明
调试 Agent 到凌晨并不稀奇：换旗舰模型、重写系统提示、把 RAG 切块参数拧来拧去，沙盒里明明还行，一上生产就忘两步前的结论、没做完却报成功、任务成功率死死卡在某个不上不下的区间。
Nick T（Ph.D.）在 Artificial Intelligence in Plain English 上那篇Harness Engineering导读，讲的就是这种挫败感。文中有个很典型的自述：同一套模型怎么折腾，生产成功率都很难从约 68% 再往上推；后来他把问题从「模型不够聪明」改判成「系统没撑住」，去重构任务拆解、状态管理、关键步骤校验和失败恢复，才把同一模型、同一批提示推到更高的任务成功率（文中自称超过 95%——这是作者场景下的经验数字，不是可复现基准，当故事读就好）。
标题里那句「好过 80% 其他 Agent」是媒体腔。真正值得留下的，是那个已经被多方复述的等式：
Agent = Model + Harness
模型负责智能；Harness 是其余一切——提示、工具与技能、沙箱与文件系统、编排、钩子、校验与恢复。LangChain 的The Anatomy of an Agent Harness把话说得更绝：如果你不是模型，你就是 harness。
图：六层 harness 与常见翻车点（中文标注示意）
多数团队卡在第几阶段
Nick 文里用三个阶段描述 LLM 应用心智的演进，很多团队其实还停在前两级，却在用第三级的问题折磨自己。
阶段 1：提示工程——模型听懂我了吗？角色、few-shot、格式约束，单轮任务上确实像魔法。天花板也明显：提示再漂亮，也塞不进模型没有的事实，管不住三轮工具调用前的决定，更拦不住它在现实扑空时一本正经地编。
阶段 2：上下文工程——模型有没有事实？RAG、动态检索、工具输出回灌、对话史裁剪。上下文对了，幻觉会少一截。但生产里失败往往不在「知不知道」，而在「知不知道之后能不能稳定地做完」。
阶段 3：Harness 工程——模型能不能可靠地行动？这里管的是边界、工具契约、编排、状态、观测、强制校验与恢复。前两阶段让模型想得更好；第三阶段让它做得更稳。
一个好用的类比：让初级同事去开关键客户会。提示是议程，上下文是资料袋；harness 则是随身清单、会中强制同步、录音纪要、跑偏纠正机制，以及报告验收标准。资料再全，缺问责设施照样翻车。
六层分别在堵哪类失败
不同作者对分层命名略有出入，Nick 文与后续解读里常见的六层大致是：
| 层 | 管什么 | 典型翻车 |
|---|---|---|
| L1 信息边界 | Agent 该知道什么、不该知道什么 | 上下文被百科全书撑爆，关键规则反而淹没 |
| L2 工具系统 | 如何发现、调用、消化工具结果 | 五十个工具一次性塞进提示，乱调、调错 |
| L3 执行编排 | 多步任务怎么排、怎么循环 | 计划与执行缠在一起，中途无法改道 |
| L4 记忆与状态 | 任务状态、交接文档、跨窗口续跑 | 聊天记录当唯一状态，一压缩就丢决策 |
| L5 评估与可观测 | 自我检查、轨迹、截图/日志 | 失败不可见，只能凭模型自信 |
| L6 约束·校验·恢复 | 机械强制、回滚、重试与降级 | 「建议一下」当安全边界，错误被放大 |
L1 的实践倾向很一致：别塞手册，塞地图。Mitchell Hashimoto 那类AGENTS.md思路——几十到上百行、每条对应过往翻车、用「任务 → 去哪看」而不是百科——和 OpenAI 把仓库当系统真源、给 Agent 地图而非巨型说明书，是同一方向。
L2 要记住工具也占上下文。Anthropic 的 Tool Search 一类做法表明：按需加载工具，能省下大量 token，准确率也更好看。原则很简单——不要一上来挂五十个工具。
L3 常见拆法是 Planner / Generator / Evaluator，或确定节点与探索节点混排的状态机。计划、执行、检查最好能分开角色或至少分开步骤。
L4 别迷信「上下文还能再压一点」。上下文质量掉下去时，与其硬压缩，不如用结构化交接文档拉起新会话（Anthropic 谈过的 Context Reset 思路）。文件系统 + Git，在 LangChain 的 harness 解剖里几乎是一等公民：可持久、可协作、可回滚。
L5 / L6 则是生产感最强的两层。能看见 DOM、截图、日志，Agent 才谈得上自检；「无法被机械强制的事，Agent 终将偏离」——把修复说明写进 linter / 策略错误信息，往往比再写三段「请务必遵守」有用。
不少实践者建议：先做 L1 和 L6 这两个书挡。没有边界会乱逛，没有恢复会把小错滚成不可收拾；中间层重要，但这两头杠杆最大。
和 Harness²、LangChain 叙事怎么对齐
如果你刚读过 Google 的 Harness²，会有熟悉感：都在说「先冻住权重，改外围脚手架」。差别是切口——Harness² 偏研究管线（Propose–Probe–Compose + 改进库）；Nick 这篇更偏工程心智与分层清单；LangChain 则从「模型做不到什么」反推 harness 原语（文件系统、bash、沙箱、记忆、抗 context rot、长程自治）。
三条线并不打架。可以粗暴记：Harness² 教你怎么迭代 harness；六层模型教你 harness 里有哪些合同；LangChain 教你每个合同为什么必然出现。
落到项目里，别一次性造航母
同一模型做 A/B：只改 harness（边界文件、工具集、校验钩子），看任务成功率与返工次数，别和换模型的实验搅在一起。
边界文件保持短：只写「去哪看」和硬规则；细则外置到可检索文档。
工具默认按需加载；对破坏性操作单独授权。
状态进文件或任务对象，别只活在对话里；上下文腐烂就交接重置。
关键步骤用机械校验（测试、lint、策略引擎），失败信息里直接写修复路径。
预算上，先把 L1 + L6 做扎实，再按痛点补 L2–L5。观测不到的「成功率」不要拿来对老板讲故事。
常见误判：把 harness 问题继续当模型问题
几类信号出现时，优先怀疑 harness，而不是急着换基座：
同一提示在沙盒稳定、在生产抖动——多半是工具权限、网络、或真实数据分布不同。
模型反复「差不多做完了」但交付物缺验收——缺的是 L6 的独立完成定义。
上下文越长越蠢——先看 L1/L4 的腐烂与压缩策略，再谈是不是模型窗口不够。
工具一多准确率掉——先做 L2 的按需装载与结果裁剪。
反过来，如果换了更强模型，在同一 harness 下分数几乎不动，也别急着再买更大的：那通常说明瓶颈根本不在智商，而在环境合同。
怎么读这篇更有用
Daily Digest 里这篇是强观点导读，完整六层展开在部分镜像里并不完整；分层细节我交叉对照了公开的 harness 工程综述与 LangChain 官方文章，数字以 Nick 原文自述为准并标明场景性。
它最有价值的不是「95%」这个广告数字，而是把团队从「再买一个更强模型」拧向「给模型装上可审计的工作环境」。和样本稿里的 Harness² 是同一大方向上的工程读物：一个偏论文与递归改进，一个偏分层与生产翻车分类。
若你的 Agent 在演示里很能打、在流水线上很脆弱，与其继续微调提示词，不如先画一张六层图，把最近三次事故钉到具体层上——往往一张图比再开一周提示词迭代更省时间。
参考来源
- Medium 导读（部分镜像/付费墙，完整原文未全量抓取）：Harness Engineering: Understand this will make your AI Agent performs better than 80% other agents — Nick T (Ph.D.) / Artificial Intelligence in Plain English
- LangChain：The Anatomy of an Agent Harness— https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
- 公开解读（六层结构交叉验证）：The Six-Layer Architecture of Harness Engineering (BSWEN)
文中成功率数字来自作者自述场景，非统一基准；分层命名在不同文章中略有出入，按合同含义理解即可。