为什么即使是最聪明的 AI 模型，也会在生产环境中崩溃，或无法按预期完成任务？
你或许也遇到过这种令人意外又着急的情况。
这往往说明，问题并不在模型本身，更可能出在可靠系统控制机制的缺失，也是上一篇文章（）提到的Harness。
本文将介绍成熟Harness系统的架构组成，以及如何设计Harness，让 Agent 稳定交付，达到生产乃至商用级别。
全文分为四部分：
- AI 工程的三个阶段；
- 成熟 Harness Engineering 的六层架构；
- 如何应对上下文焦虑；
- 如何通过分离生成与评估，实现自主稳定运行。
先从几个基本概念说起。
AI 工程的三个阶段
大型语言模型（LLM）应用的发展，大致经历了三个不同的阶段。
很多人/团队仍处于第一或第二阶段，因此不明白为什么第三阶段的问题总会出现。
阶段一：提示词工程——模型听懂我的意思了吗？
大多数人都是从这里起步的。LLM 对概率分布极其敏感：仔细设计角色说明、提供几个示例（few-shot），再加上恰当的格式约束，输出就可能明显不同。这看起来像魔法，效果也确实显著。对于目标明确、只需单轮交互的任务，优质提示词不可或缺。
但提示词很快就会遇到瓶颈。毕竟，无论指令写得多好，都无法让模型知道它原本不知道的事，也无法让它记住几次工具调用之前发生的内容；信息不足或结果不理想时，提示词同样无法阻止模型自顾自地编造数据。
需要注意一个常见误区：以为把提示词写得更复杂、更有条理，就能弥补事实依据或实时上下文的缺失。
这是做不到的。
阶段二：上下文工程——模型掌握事实了吗？
意识到上述提示词的局限后，你可能会开始研究上下文：RAG 技术、动态检索、将工具输出传回模型，以及有选择地注入对话历史。
要注意，上下文工程并不等同于向量数据库 RAG，还包括动态注入状态、总结工具响应，以及有策略地截断历史记录。RAG 只是起点。
这些做法确实会带来一些突破，当 Agent 能在恰当的时机获得正确的信息时，能力会明显提升。
但上下文工程仍然无法解决一个问题：执行漂移（Execution Drift）。
智能体会先制定出色的计划，并完美执行第一步。
但从第二步开始，它可能误解工具返回的结果、偏离任务主线，却还能继续执行后面十几步。更麻烦的是，系统对此毫无察觉，仍自信地执行早已偏离正轨的计划。
阶段三：Harness 工程——模型能持续正确地采取行动吗？
Harness 工程（Harness Engineering），是一种围绕模型构建支撑体系的工程方法：通过构建确定性的系统（相对于概率模型的LLM来说），从而监督模型的行动、捕捉到失败、施加约束，并在模型偏离轨道时能将其拉回来。
Harness这个名称来自现实中的安全带具：缰绳、安全系索，以及用于控制的整套设施。它表达的正是这个意思。
上一篇文章（）最后总结为：
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 规定。
第四层：记忆与状态（连续性）
这一层负责状态管理，让任务状态得以延续。
无状态的智能体每轮都会“失忆”。如果没有明确的状态管理，多步骤任务中的每一步都像是开启了一段新对话。
可以将记忆及其状态分为三类：
- 当前任务状态——目前进行到哪一步？还有什么待办？哪些内容已经确认？
- 对话中间结果——本次会话已经得出了哪些结论？
- 长期记忆／用户画像——跨会话保留的全局偏好和背景信息。
常见的问题是把任务状态和对话历史混为一谈，导致上下文窗口不断膨胀、结构混乱，模型表现也随任务推进而下降。因此，务必将两者分开管理。
第五层：评估与可观测性（自我认知）
这一层负责验证执行结果。
最初级的 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。