拆解Agent的Harness六层架构：为什么你的大模型总是跑崩

文章目录

• • 一、先讲个离谱的事
  • 二、Harness到底是个啥
  • 三、AI工程这两年走了三步
  • • 3.1 第一级：把话说清楚
    • 3.2 第二级：把信息喂对
    • 3.3 第三级：把执行驾驭住
  • 四、成熟Harness的六层架构
  • • 4.1 第一层：信息边界管理
    • 4.2 第二层：工具系统
    • 4.3 第三层：执行编排
    • 4.4 第四层：状态管理
    • 4.5 第五层：评估与观测
    • 4.6 第六层：约束、校验与失败恢复
  • 五、一线公司到底怎么玩的
  • • 5.1 Anthropic：对付"上下文焦虑"
    • 5.2 Anthropic：生产与验收必须分离
    • 5.3 OpenAI：工程师不写代码，只设计环境
  • 六、收口：上限归模型，下限归Harness

P.S. 推荐一个大神的教程给想要了解或者学习人工智能知识的读者，这个教程里内容讲解通俗易懂且风趣幽默，对我帮助很大。我想与大家分享这个宝藏教程，请点击下方链接查看，
传送门https://blog.csdn.net/qq_74013365

一、先讲个离谱的事

有个团队做Agent，效果一直上不去。

他们的操作非常标准——换最强的模型，提示词改了一百多版，温度参数从0调到1再调回0.1，恨不得把模型祖坟都刨出来调一调。

结果呢？真实场景成功率，70%都不到。

你说气不气？就像你花大价钱请了个金牌大厨，结果他炒出来的菜还是咸的，你怀疑是锅的问题，换了三口锅，还是咸。最后发现——是你没告诉他盐放多少、火候多大、炒完要不要尝一口。

后来这个团队干了一件事，成功率直接干到95%以上。

模型没换，提示词没动，参数一个没改。

改的是：任务怎么拆、状态怎么管、关键步骤怎么校验、失败了怎么捞回来。

说白了，改的全是模型外面那套东西。

这套东西，现在有了个统一的名字——Harness。

二、Harness到底是个啥

LangChain那帮人给过一个特别干净的等式：

Agent = Model + Harness

移项就是：Harness = Agent − Model。

翻译成人话：在一个Agent系统里，除了模型本身之外，所有决定它能不能稳定干活的东西，都算Harness。

这个定义为啥重要？因为它把"模型"和"系统"在账本上彻底分家了。

模型是上限，Harness是下限。

而决定一个产品能不能落地的，从来都是下限。你家天花板再高，地板塌了照样住不了人。

那个70%到95%的案例，改的全是下限。

三、AI工程这两年走了三步

Harness不是凭空蹦出来的。过去两年，AI工程其实走完了三级跳：

Prompt Engineering → Context Engineering → Harness Engineering

听着像术语流行史，实际上是AI系统要回答的三层问题在依次显形：

三层问题一层包一层，越往外越大。就像剥洋葱，剥到最后你会流泪——因为发现最外面那层才是真正难搞的。

3.1 第一级：把话说清楚

大模型刚火那阵，大家最直观的体验是：同一个模型，换个说法结果差很多。

于是全民研究提示词——角色设定、Few‑shot、风格约束、输出格式。那段时间人人都是"提示词工程师"，朋友圈到处是"万能提示词模板"，卖9块9一份，比奶茶还畅销。

为啥有效？因为大模型本质是一个对上下文极度敏感的概率生成器。你给它什么身份，它就顺着那个身份往下接；给它什么样例，它就按那个范式补全。

提示词工程的本质，不是命令模型，而是给它框一个概率分布，让它更可能落进你想要的解空间。

但它的天花板也很硬：很多任务不是你说清楚就行，是你真得知道。让模型按一套长规范写代码、回答某个产品的最新配置——提示词写得再漂亮，也替代不了事实本身。

一句话：Prompt解决的是表达问题，不是信息问题。

就像你跟一个外卖员说"请给我送一份最好吃的麻辣烫"，他表达上完全听懂了，但他不知道你家在哪、你吃不吃辣、要不要加麻酱。

3.2 第二级：把信息喂对

Agent一火，问题就变了。模型不再只是回答，而是要进真实环境做事：多轮对话、调浏览器、写代码、查数据库，多步之间传中间结果，根据反馈改计划。

问题从"一次答得对不对"变成"整条链路跑不跑得通"。

这时核心命题换成一句：模型不知道的，系统必须在合适时机把正确信息送进去。

注意，这里的"信息"远不止几段背景资料。它是所有影响模型当前决策的东西的总和——用户输入、历史对话、检索结果、工具返回、任务状态、中间产物、系统规则、安全约束、别的Agent传来的结构化结果。

Prompt只是其中一小块。就像你去餐厅吃饭，菜单只是信息的一部分，食材新不新鲜、厨师今天心情好不好、后厨有没有蟑螂，这些才是决定你这顿饭体验的关键。

RAG是这级的典型实践：先检索再塞上下文。但成熟的Context工程不止检索，它管整条链路——文档怎么切块、结果怎么排序、长文怎么压缩、历史何时保留何时摘要、工具返回要不要全暴露、多Agent间传原文还是摘要还是结构化字段。

核心信条就一句：上下文是稀缺资源，优化不是给更多，是按需给、分层给、在正确时机给。

但这级也有够不着的地方：就算信息喂对了，模型也不一定稳定执行对。它可能计划漂亮，执行却跑偏——掉工具、误读返回、长链路里悄悄偏航而系统毫无察觉。

Prompt和Context都在解决输入侧，可模型一旦连续行动，谁来监督它、约束它、拉回它？

3.3 第三级：把执行驾驭住

Harness原意是缰绳、马具。借到AI里，提醒的是件朴素的事：模型从"回答问题"走到"执行任务"，系统不只负责喂信息，还要驾驭整个过程。

前两级关注"让模型更会响应"，这级关注"让模型别跑偏、跑得稳、出了错还拉得回来"。

给你打个比方，一下就懂了：

开一辆车送重要客人去机场——

Prompt：你把任务跟司机讲清楚——走哪条路、几点到、乘客要安静。重点是把意图说清楚。

Context：你把信息喂齐——导航路线、实时路况、油量、乘客行李数量。重点是信息供给对不对。

Harness：你装了方向盘助力、车道偏离提醒、疲劳驾驶监测、备胎和保险，还要求司机每段路汇报、到站按清单验收。重点是执行全程有人盯、有偏差能纠、出事能兜底。

三者不是替代，是包含：Prompt ⊂ Context ⊂ Harness。边界一层比一层大。

你品品，是不是这个道理？很多人买车只看发动机（模型），不看安全气囊和刹车系统（Harness），结果上路第一天就追尾了。

四、成熟Harness的六层架构

把Harness摆开看，我把它归成六层。这六层从内到外，越往外越是"能不能上线"的生死线。

4.1 第一层：信息边界管理

重新站到Harness视角看Context：模型发挥稳不稳，很多时候取决于它看到了什么。

这层管三件事——

角色与目标的定义：你是谁、成功标准是什么。别让模型干着干着忘了自己是谁，这比人中年危机还可怕。

信息裁剪：越相关越好，不是越多越好。给模型塞一堆无关信息，就像你考试前把整本书都背了，结果考的是另一门课。

结构化分区：固定规则、当前任务、运行状态、外部证据各归其位。信息一乱，模型就漏重点、忘约束，甚至自我污染——自己上一轮说的错话，下一轮当成真理继续往下编。

4.2 第二层：工具系统

没工具，大模型的本质就是个文本预测器，碰不到真实世界。就像一个人脑子再好使，手脚被绑着，也只能原地嘴炮。

但Harness不是简单挂工具，它要回答三个问题：

给哪些工具？太少不够用、太多会乱用。你给一个实习生二十把钥匙，他大概率会拿错；你只给他一把，他反而知道该开哪扇门。

什么时候调？不该查别乱查、该查别硬答。有些模型特别自信，不知道的东西也敢编，编得比真的还像真的。这时候你得在系统层面拦住它：不知道就去查，别瞎扯。

工具结果怎么喂回？几十条搜索结果不能原封塞回去，要提炼筛选保相关性。不然模型看着看着就走神了——跟你刷短视频一样，本来想查个资料，结果看了半小时猫。

4.3 第三层：执行编排

解决"下一步做什么"。

很多Agent不是某一步不会，而是不会把步骤串起来——会搜、会总结、会写代码，结果想到哪做到哪，交出一堆半成品。就像一个厨师会切菜会炒菜会摆盘，但不知道先做哪个后做哪个，结果凉菜还没切，热菜已经凉了。

一条完整轨道该是：理解目标 → 判断信息够不够 → 基于结果分析 → 生成输出 → 检查不达标就修正重试。

区别于人的是：人靠经验，Agent靠这套环境、记忆和状态。

4.4 第四层：状态管理

没状态的Agent每轮都像失忆。

你跟它说"帮我写个Python脚本"，它写完了。下一轮你说"刚才那个脚本加个日志"，它问你"什么脚本？"——比金鱼记性还差。

至少要分清三类东西：当前任务状态、会话中间结果、长期记忆与用户偏好。混在一起系统必然越来越乱，就像你把袜子、内裤、衬衫全塞一个抽屉里，早上找衣服能找到怀疑人生。

4.5 第五层：评估与观测

最被轻视的一层。

很多系统不是生成不出来，是生成完了不知道自己做得好不好。没有独立评估，Agent就长期停在"自我感觉良好"。

这就像学生考完试自己给自己打分，那必须满分啊，顺便还得加个卷面分。

这层包括输出验收、环境验证、自动测试日志指标、错误归因。会做，还要知道自己有没有真做对。

4.6 第六层：约束、校验与失败恢复

这层才真正决定能不能上线。

真实环境里失败不是例外是常态——搜索不准、API超时、文档混乱、模型误解任务。没有恢复机制，每次出错只能从头再来，用户等得花儿都谢了。

这层管三件事：

约束：能做什么不能做什么。别让模型删数据库、别让它发邮件给全公司、别让它在生产环境跑rm -rf。

校验：输出前后怎么检查。生成的代码能不能跑？返回的格式对不对？引用的链接存不存在？

恢复：失败后重试、切回、回滚到稳定状态。这才是真正的工程素养——不是不出错，而是出了错能自己爬起来。

把这六层落到代码里，大概长这样（最小骨架，只为示意六层在主循环里的投影）：

def run_task(goal):
state = {"goal": goal, "steps": [], "verified": False}

while not state["verified"]:
plan = planner(state) # 编排：下一步做什么
result = executor(plan, tools) # 工具系统 + 状态管理

if not validator(result): # 评估观测 + 校验
state = recover(state, result) # 失败恢复
continue

state["steps"].append(result)
state["verified"] = evaluator(state) # 独立验收（生产/验收分离）

return state

看到没？六层不是六张孤立的图，而是同一个主循环里六个职责。缺哪一层，循环就在哪里漏。

就像木桶效应——你其他五块板再高，缺了一块，水照样流光。

五、一线公司到底怎么玩的

概念讲完，看真正有参考价值的部分——谁把Harness做进了产品。

战绩很直白：

LangChain底层模型不变，只改Harness，把自家Agent从榜单30开外杀进前5。

OpenAI用几名人类工程师加Agent搭出百万行代码的生产级应用，100%代码Agent写，耗时纯人工的十分之一。

Anthropic做到一句自然语言需求、无人干预连跑数小时，产出完整游戏和数字音频工作站。

挑两个最有迁移价值的实践讲。

5.1 Anthropic：对付"上下文焦虑"

长程自主任务里，模型会得一种病——上下文越塞越满，模型开始丢细节、丢重点，甚至出现一种微妙现象：它好像知道自己快装不下了，于是急着草草收尾。

像不像你手机内存快满了的时候，开始疯狂删照片、清缓存，连重要的聊天记录都敢删？模型也一样，它一焦虑就想赶紧结束，管你任务做没做完。

常规解法是Context Compression——压缩历史再继续。但Anthropic发现对某些模型这还不够——压缩只是变短，那种"快撑爆"的负担感没真正消失。

就像你把行李箱里的衣服卷起来塞，确实省了点空间，但箱子还是那个箱子，该关不上还是关不上。

他们做了更激进的一招：Context Reset——不在这条上下文里硬压，而是开一个干净的新Agent，把工作交接过去。

换个壳讲：像长跑接力赛，一个选手跑累了不硬撑、不靠喝咖啡死扛，而是把棒交给一个状态满格的新选手继续跑。

也像工程里遇到内存泄漏——与其一遍遍清缓存，不如直接重启进程再恢复状态。

本质都是：承认局部状态会腐化，用交接代替硬撑。这是非常典型的Harness设计——它管的不是模型能力，是运行节奏。

5.2 Anthropic：生产与验收必须分离

模型自己干活再给自己打分，几乎必然偏乐观。尤其在体验、产品完整度这类没标准答案的问题上，偏差更明显。

这就像让学生自己出题自己批卷，那必须全班满分啊，顺便还得评个三好学生。

Anthropic的解法是一条铁律：把干活的人和验收的人拆开。

Planner：把模糊需求扩成完整规格。

Generator：逐步实现。

Evaluator：像QA一样真实测试。

关键在Evaluator不只看代码，它真实操作页面、看交互、查实际结果。不是抽象审查，是具体环境验证。

这背后是个老辣的工程原则，用考试类比最清楚：让学生出题又自己批卷，必将偏乐观；必须换老师独立阅卷。

只要评估者足够独立，系统就能形成"生成→检查→修复→再检查"的有效循环。

5.3 OpenAI：工程师不写代码，只设计环境

OpenAI的实践等于重定义了Agent时代工程师的活：人类一行代码不写，只负责设计环境。

三件事——

把产品目标拆成Agent能懂的小任务。

Agent失败时不让它"更努力点"，而是问环境缺了什么能力。

建立反馈链路让Agent看见自己的工作结果。

最值得记的一句话：Agent出问题时，修复方案几乎从来不是"更努力一点"，而是确定它缺了什么结构性能力。

这是Harness思维的内核。你家孩子考试不及格，你骂他"你怎么不努力"没用，你得看看是他课本没看懂、还是笔不好使、还是考场太吵。

他们还踩过一个人人都会踩的坑：早期写了一个巨大的Agent.md，把所有规范全塞进去，结果Agent更糊涂了。

道理很简单——上下文窗口稀缺，塞满等于什么都没说。就像你给新员工一本500页的员工手册，让他一天看完，他看完只记住了"周五下午可以提前下班"。

后来改成目录页加子文档，需要时再钻进去。和Skills的渐进式披露同一个根：不一次性全给，按需索取。

更狠的是自动治理：Agent提交太快，人类Code Review根本盯不过来，于是把资深工程师的经验直接写成系统规则——模块怎么分层、哪层不能依赖哪层、什么时候必须拦截。

而且规则不只报错，还把"该怎么修"一起返回给Agent，进入下一轮上下文。

这已经不是代码规范了，是一套可持续运转的自动治理系统。相当于把一个十年经验的架构师，变成了24小时不睡觉的自动守门员。

六、收口：上限归模型，下限归Harness

把三阶段收成一句：

Prompt Engineering：把任务讲清楚。

Context Engineering：把信息喂对。

Harness Engineering：让模型在真实执行里持续做对。

Harness不取代前两者，它在更大的系统边界上把两者包了进去。

任务还是单轮生成时Prompt重要；依赖外部知识时Context关键；一旦进入长链路、可执行、低容错的真实场景——Harness几乎不可避免。

这也解释了开头那个执念为什么总落空：同样的模型，在不同产品里表现天差地别，因为真正决定上限的可能是模型，但真正决定能不能落地、能不能稳定交付的，是Harness。

AI落地的核心战场，正在从"让模型看起来更聪明"，转向"让模型在真实世界里稳定工作"。

这趟车，做Agent的人趁早想明白。

模型决定Agent能多聪明，Harness决定Agent能不能上线。前者是天花板，后者是准入证。

P.S. 推荐一个大神的教程给想要了解或者学习人工智能知识的读者，这个教程里内容讲解通俗易懂且风趣幽默，对我帮助很大。我想与大家分享这个宝藏教程，请点击下方链接查看，传送门https://blog.csdn.net/qq_74013365