本文将介绍成熟Harness系统的架构组成以及如何设计Harness让 Agent 稳定交付达到生产乃至商用级别。全文分为四部分1.AI 工程的三个阶段2.成熟 Harness Engineering 的六层架构3.如何应对上下文焦虑4.如何通过分离生成与评估实现自主稳定运行。AI 工程的三个阶段大型语言模型LLM应用的发展大致经历了三个不同的阶段。很多人/团队仍处于第一或第二阶段因此不明白为什么第三阶段的问题总会出现。阶段一提示词工程——模型听懂我的意思了吗大多数人都是从这里起步的。LLM 对概率分布极其敏感仔细设计角色说明、提供几个示例few-shot再加上恰当的格式约束输出就可能明显不同。这看起来像魔法效果也确实显著。对于目标明确、只需单轮交互的任务优质提示词不可或缺。但提示词很快就会遇到瓶颈。毕竟无论指令写得多好都无法让模型知道它原本不知道的事也无法让它记住几次工具调用之前发生的内容信息不足或结果不理想时提示词同样无法阻止模型自顾自地编造数据。需要注意一个常见误区以为把提示词写得更复杂、更有条理就能弥补事实依据或实时上下文的缺失。这是做不到的。阶段二上下文工程——模型掌握事实了吗意识到上述提示词的局限后你可能会开始研究上下文RAG 技术、动态检索、将工具输出传回模型以及有选择地注入对话历史。要注意上下文工程并不等同于向量数据库 RAG还包括动态注入状态、总结工具响应以及有策略地截断历史记录。RAG 只是起点。这些做法确实会带来一些突破当 Agent 能在恰当的时机获得正确的信息时能力会明显提升。但上下文工程仍然无法解决一个问题执行漂移Execution Drift。智能体会先制定出色的计划并完美执行第一步。但从第二步开始它可能误解工具返回的结果、偏离任务主线却还能继续执行后面十几步。更麻烦的是系统对此毫无察觉仍自信地执行早已偏离正轨的计划。阶段三Harness 工程——模型能持续正确地采取行动吗Harness 工程Harness Engineering是一种围绕模型构建支撑体系的工程方法通过构建确定性的系统相对于概率模型的LLM来说从而监督模型的行动、捕捉到失败、施加约束并在模型偏离轨道时能将其拉回来。Harness这个名称来自现实中的安全带具缰绳、安全系索以及用于控制的整套设施。它表达的正是这个意思。本号上一篇文章深入拆解Agent的工作机制和构成Loop、Tools、Memory、Harness 在最后将Agent总结为Agent LLM Harness这实际上是一种理解 Agent 的新视角也凸显了 Harness 对Agent性能表现以及在当前 Agent 工程实践中的重要性。换一个更好的模型也未必能解决问题原因就在于此。下面重点详细介绍 Harness 工程主要可分为六层架构。成熟Harness工程的构成六层架构Harness 可以看作 Agent 的操作系统负责监督任务执行。从设计和技术角度看它由六层组成分别应对不同场景中的问题帮助 Agent 稳定、正确地完成任务。第一层信息边界认知范围信息边界回答的是“模型能看到什么”即模型在当前上下文中接收到的内容。多余的数据不会让模型更聪明只会分散它的注意力。如果把系统规则、当前任务状态和外部证据等不同类型的信息杂乱地混在一起模型就可能漏掉约束把关键规则当成噪声。Harness 必须明确界定并分类模型能看到的内容模型的角色、当前目标、成功标准以及按类型结构化的信息。第二层工具系统执行能力没有工具时LLM 只是文本预测器配备合适的工具后它才能成为与现实世界交互的智能体。很多人在使用 Agent 的早期容易犯一个错误安装太多工具。配上n多种眼花缭乱的工具、详尽说明和各种 Skill 文档看起来似乎很强大。实际上这也会分散模型的注意力让它编造不存在的参数或误用自己并不熟悉的 API。在这一层Harness 不仅要控制可用工具还要控制何时以及如何使用工具。它既要避免模型该搜索时却盲目猜测也要在模型已经知道答案时不要让它继续搜索。还有一条不可妥协的规则绝不要把未经处理的工具输出直接传回 LLM。一次工具调用返回的几十条 JSON 记录就足以污染上下文。工具返回值必须先经过 Harness 筛选、解析和总结再交给模型。第三层执行任务的调度编排规划与路由这一层负责规划和推进任务类似现实工作中的项目管理。LLM 经常失败并非缺少某项单独的技能而是无法按顺序串联这些技能。它可能在步骤之间来回跳转、跳过验证或在掌握必要信息之前就生成结果像一个不熟悉SOP规范、行事鲁莽的新手员工。这时Harness 就需要设定清晰、严格的执行流程理解目标 → 评估信息 → 获取缺失信息 → 分析 → 生成 → 验证 → 输出这不只是搭建流程框架更是把项目管理职责从概率模型交给确定性系统。模型不必再决定先做什么、后做什么执行流程应由 Harness 规定。第四层记忆与状态连续性这一层负责状态管理让任务状态得以延续。无状态的智能体每轮都会“失忆”。如果没有明确的状态管理多步骤任务中的每一步都像是开启了一段新对话。可以将记忆及其状态分为三类1.当前任务状态——目前进行到哪一步还有什么待办哪些内容已经确认2.对话中间结果——本次会话已经得出了哪些结论3.长期记忆用户画像——跨会话保留的全局偏好和背景信息。常见的问题是把任务状态和对话历史混为一谈导致上下文窗口不断膨胀、结构混乱模型表现也随任务推进而下降。因此务必将两者分开管理。第五层评估与可观测性自我认知这一层负责验证执行结果。最初级的 Agent 往往缺少这一层它生成结果、宣布成功却没有机制判断结果是否正确。这就像一名没有导师指导的新员工做完任务就算交差也不管结果是否真的满足需求。如果设计让 Agent 自己评估验收并不可靠这相当于让运动员身兼裁判员。它可能非常乐观自信把有问题的代码说成可以正常运行即使回答没有解决实际问题也会给自己的回复打高分。事后再交给人工审核也不现实这种方式太慢更无法规模化。你大概会想到解决方法是需要独立监督和外部验收。在这一层Harness 提供独立、自动化的验证机制。自动检查输出、集成测试环境、记录详细日志、跟踪指标和分析错误都属于 Harness 的职责。系统必须持续验证自己的行动而不能只凭自我判断认定结果正确。第六层约束、验证与恢复韧性这一层回答的是“出错后如何应对和恢复”。Agent 运行时失败或结果不如预期的情况并不少见API 会超时文件格式可能出错搜索结果也可能不准确。没有恢复机制的智能体每次出错都需要人工从头重启。Harness 在这一层需要做好三件事•约束用硬编码规则明确规定智能体绝对不能做什么。•验证在输出前后设置关卡检查例如模式验证、格式检查、约束核验。•恢复设置重试逻辑和备用路径并能够回滚到最近一个已知稳定状态。如何应对上下文焦虑总体而言Harness 的六层架构为 Agent 执行任务提供了基础保障。但在实际使用中任务过程往往很长。你可能在同一个任务会话中进行十几轮甚至几十轮对话你会在一个需求后接着提出另一个需求期间还要反复修改细节、调试结果。这对 Agent 是很大的挑战也可能让前面介绍的框架失效尤其是第一层的信息边界、第四层的记忆与状态以及第五层的评估与可观测性。当上下文不断累积、接近上限时你可能会发现一些异常模型开始丢失重点和细节、忘记核心目标、得出毫无依据的结论、跳过验证步骤表现得像是急着完成任务。这意味着 Agent 已经发生了故障。Anthropic 的研究人员将这种状态称为上下文焦虑Context Anxiety。这种状态下的 Agent就像一名不断接到新需求、反复返工的员工工作越久越显得急切、不耐烦、焦虑想尽快结束任务最后草率交差。那么如何管理长对话中的上下文避免信息失控和执行跑偏最简单的办法是压缩上下文总结历史把摘要重新注入再继续执行。这种方法确实能减少 token 数量却不能真正重置模型的认知状态也无法消除注意力被稀释的问题。更彻底的办法是重启智能体。Anthropic 将这种方法称为上下文重置反思机制Context Reflect当上下文过大时把压缩后的摘要交给一个全新的智能体实例。这样可以从更干净的上下文重新开始避免混乱不断累积。这就像处理内存泄漏与其反复清理不如直接重启进程。同样不要一开始就把整套工具库交给智能体。Harness 可以采用渐进式披露Progressive Disclosure通过分层设计按需提供信息避免信息过载影响模型判断。起初只让模型看到必要的最少工具使它能在较低认知负荷下稳定决策。当模型需要某项特定能力时Harness 再动态提供相应的详细文档和参数。将生成与评估分离实现自主运行的架构Progressive Disclosure 解决的是“模型何时该看到哪些信息”Context Reflect 解决的是“何时整理状态并重新开始”。然而上下文清晰并不代表执行结果可靠。Agent 仍可能产出错误结果或把未完成的工作误判为成功。这正是前文第五层和第六层要解决的问题评估与验收、约束与恢复也是设计高性能 Agent 的关键。Anthropic 提供了一个实践范例他们构建的智能体可以连续数小时不经人工审核生成完整且可用的产品。其中的关键在于分离生成与评估的职责具体做法是设置三个角色•规划器Planner把模糊的人类需求转化为严谨的工程规格和步骤•生成器Generator依据这些规格逐步执行任务生成代码或其他输出•评估器Evaluator独立验收输出检查它是否满足 Planner 的要求而不是只听 Generator 汇报“我做完了、我做好了”。评估器在功能上与生成器解耦。 仔细看看这个架构像不像立法、行政、司法的三圈分立架构设计Evaluator 不能只看生成器写出的代码还要直接与渲染后的结果交互。在 UI 工作中它会点击界面、检查视觉布局、测试交互状态。验证应以实际结果为依据而不是只听生成器描述。就像验收不能只听会上汇报还要到现场检查。OpenAI 又将这一步推进了一层。当 Agent 写代码的速度快到人类工程师来不及审核拉取请求时OpenAI 为智能体搭建了一套完全自动化的 CI/CD持续集成持续交付流水线。Agent 会在隔离的沙盒中运行代码使用无头浏览器一种没有图形用户界面的完整浏览器引擎截取屏幕截图、读取运行日志并不断迭代直到确认部署正确。整个过程无需人工介入。这样一来“完成”不再只是“我已经生成了文本”更要升级“我运行了代码、检查了日志、发现并修复错误并在沙盒中验证了部署”。这有助于提升交付质量让结果更接近预期。核心结论回到文章开头的问题可以得出这样的结论基础模型的智能决定了它在排行榜上的理论上限。但模型在实际使用中的表现更多取决于Harness 系统是否稳健Harness Engineering 决定了基础模型的能力能否经受现实环境的考验、从失败中恢复并真正创造价值。所以模型不是瓶颈。尤其到了模型竞争的中后期更是如此。要搭建生产乃至商用级别的 AI Agent 系统把任务成功率从 60% 提升到 90%让产品从演示版demo走向商业化这中间的差距可以说完全取决于 Harness。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】