从 70% 到 95% 成功率：为什么 Harness Engineering 才是 AI Agent 落地的关键？

在当前的 AI 应用开发中，正上演着一种普遍的焦虑：你动用了全球最顶尖的模型（如 GPT-4o），将提示词（Prompt）打磨了上百个版本，参数调了又调，但在进入真实业务场景时，Agent 的表现依然像开盲盒。

许多开发者都经历过这种“70% 瓶颈”：模型在 Demo 演示时表现惊艳，但在处理长链路、低容错的任务时，往往会莫名其妙地“跑偏”或由于上下文过载而“罢工”。这种不稳定性让 AI Agent 始终难以跨越从实验室到生产线的鸿沟。

作为架构师，我们需要意识到：决定系统稳定性的往往不是模型本身，而是模型外面的那一套“运行系统”。最近在硅谷顶尖技术圈火爆的 Harness Engineering（马具工程/驾驭工程），正是解决这一难题的关键“胜负手”。

--------------------------------------------------------------------------------

回顾过去两年的 AI 工程演进，我们经历了三个核心阶段。这三者并非替代关系，而是层层包含、不断深入的嵌套结构：

Prompt Engineering（提示词工程）： 解决“模型听不听得懂”的问题。侧重于语言设计，通过塑造局部概率空间（如设定角色、提供示例）来激发模型已有的能力。
Context Engineering（上下文工程）： 解决“信息够不够、准不准”的问题。侧重于信息供给，通过 RAG（检索增强生成）等手段，在合适合理的时刻将正确的信息（检索结果、动态 SOP）送入模型。
Harness Engineering（驾驭工程）： 解决“流程能不能跑对、跑稳”的问题。侧重于系统驾驭，关注模型在连续行动中的监督、约束与纠偏。

架构师洞察： 如果说 PE 和 CE 优化的是“输入”，那么 Harness 优化的则是“执行环境”。它们的关系如同圆环：最核心是指令（PE），中间是环境信息（CE），最外层是驾驭整场任务的“缰绳”（Harness）。

--------------------------------------------------------------------------------

在成熟的 AI 架构师眼中，有一个来自 Scale AI 工程师提出的经典定义：Agent = Model + Harness。

换句话说，Harness 等于 Agent 减去 Model。在一个 Agent 系统中，除了模型之外，所有决定系统能够稳定交付、不跑偏的工程化组件，都属于 Harness。

类比理解：新员工的客户拜访 想象你要派一名职场新人去完成一次重要的客户拜访：

Prompt Engineering 是你教给他的话术（如何寒暄、如何介绍产品）。
Context Engineering 是你塞给他的资料包（客户背景、产品报价单、竞品对比）。
Harness Engineering 则是你要求他必须遵循的 Checklist、关键节点的实时汇报机制、会后的录音核对复盘，以及一旦发现偏离目标后的强制纠偏方案。

--------------------------------------------------------------------------------

要构建一个成功率从 70% 提升至 95% 以上的系统，需要将 Harness 视为一套完整的“系统底座”进行模块化设计：

信息边界 (Information Boundary)： 明确角色目标，精准裁剪信息。上下文并非越多越好，过剩的信息会导致模型产生**“自我污染” (Self-Contamination)**，从而忽略核心约束。
工具系统 (Tool System)： 这不仅是“挂载”工具，而是要管理工具的供给时机，并对返回结果进行提炼。架构师需要决定：什么时候该查，什么时候不该乱查，以及如何保持工具反馈与任务的高相关性。
执行编排 (Execution Orchestration)： 为任务设定“轨道”。模拟人类的思考路径：理解目标 -> 补全信息 -> 尝试执行 -> 检查输出 -> 不满则修正。
记忆与状态管理 (Memory & State)： 严控任务状态。必须清晰区分：当前任务的中间结果、长期记忆与用户偏好。状态混乱是 Agent 在长链路任务中“失忆”的主要诱因。
评估与观测 (Evaluation & Observation)： 建立独立的验收能力。系统必须具备“环境感知”的验证能力（如模拟用户点击、检查交互日志），而不是让模型“既当裁判又当运动员”。
约束、校验与恢复 (Constraints & Recovery)： 这是落地的关键下限。承认失败是常态，建立失败后的自动重试、路径切换与状态回滚机制。

--------------------------------------------------------------------------------

Anthropic 在构建自主编码系统时，通过迭代 Harness 系统，在模型完全不变的情况下，将榜单排名从 30 名开外直接杀入前 5。其核心实践极具启发性：

Context Reflection (上下文反射)： 当对话过长、窗口过满时，模型会产生一种**“负担感”或“焦虑感”，导致其急于收尾而丢失细节。Anthropic 的做法不是简单的压缩，而是直接启动一个“干净”的新 Agent 进程进行交接，类似于工程中的进程重启**，彻底消除模型的心理负载。
生成与验收的绝对分离： 他们将 Planner（规划）、Generator（生成）与 Evaluator（评估）解耦。最核心的是，Evaluator 必须具备带具体环境的验证能力——它不只是读读代码，而是真实去操作页面、检查交互结果，确保验收的独立性与客观性。

--------------------------------------------------------------------------------

OpenAI 在构建其内部百万行代码级别的应用时，展现了令人震撼的工程效率：该应用 99% 的代码由 Agent 编写，而背后的人类工程师团队仅有寥寥数人。

从“长文档”到“动态目录”： 早期将所有规范塞进一个巨型 instructions.md 会导致模型注意力涣散。他们将其改造为“目录索引页”，只保留核心索引，详细的子文档（设计、安全规则等）按需暴露，极大节省了稀缺的窗口资源。
工程师转型为“环境设计师”： OpenAI 的工程师不再亲自写代码，而是负责：1. 拆解目标；2. 观察 Agent 失败时缺少什么能力并补全环境；3. 建立反馈链路。

架构师金句： 当 Agent 表现不佳时，解决方案几乎从来不是让它“再努力一点”，而是要反思：在当前的执行环境中，还缺失哪种结构化的能力支撑？ 这就是所谓的“自动治理”逻辑。

--------------------------------------------------------------------------------

AI 行业的胜负手正在发生转移：从单纯追求模型“智商”的上限，转向追求系统“落地”的下限。

模型决定了能力的上限，但 Harness 决定了落地的下限。如果你正面临 Agent 任务成功率的瓶颈，优化方向往往不再是更换更强的模型或重写提示词，而是去构建那套保护它不跑偏的“强力马具”。

互动思考： 在你的 Agent 系统中，你是在花更多时间试图打造一个“更聪明的大脑”，还是在构建那套确保它不失控、不跑偏的“缰绳” (Harness)？