文章目录
1 -> 引言
生成式 AI 刚进入应用开发时，最受关注的工作是 Prompt Engineering。人们研究怎样安排措辞、提供示例、规定角色，让同一个模型输出更稳定。这个阶段没有错，只是它解决的问题越来越像局部调参。
当 AI 从回答问题变成执行任务，决定结果的因素已经移到提示词之外。Agent 要读取文件、调用工具、记住进度、处理失败、恢复运行、接受验证，并在权限边界内完成工作。模型像发动机，提示词像驾驶指令，而完整产品还需要传动、仪表、刹车、导航和道路。
本文把这套包围模型、让模型能够可靠工作的系统概括为 Harness。这个词目前并非统一标准，本文也无意用它替代提示词。它描述的是一种工程视角：通过环境、状态、工具和反馈回路，让正确行为更容易发生，让错误行为更容易被发现。
2 -> 同一个模型，为什么能跑出完全不同的结果
模型评测常给人一种错觉，仿佛能力是写在模型内部的固定数字。真实 Agent 系统不是这样。模型能否看到正确上下文，是否保留上一步推理，工具结果怎样返回，长对话如何压缩，都会显著改变最终表现。
OpenAI 在 2026 年发布的开发者指南中公布了一个很有代表性的结果：GPT-5.6 Sol 在 ARC-AGI-3 上使用标准 Harness 时得分 13.3%；启用推理保留和原生压缩后，得分提高到 38.3%，同时使用的输出 Token 约减少到原来的六分之一。模型没有更换，差异来自它工作的方式。
这组数据提示开发者，模型上限和系统表现之间存在巨大空隙。一个能力很强的模型，如果每轮都要重新理解历史、被无关工具输出淹没、无法知道任务是否真的完成，表现会像一个健忘又缺少工作条件的员工。一个较便宜的模型，如果任务边界清楚、状态稳定、验证及时，反而可能在固定流程里更可靠。
这也是为什么“换最新模型”有时会带来短暂提升，却无法治好系统性问题。新模型可能更能忍受混乱，但上下文污染、权限过宽、错误重试和验收缺失仍然存在。能力升级只是把问题推迟，并没有消除。
3 -> Harness 究竟包含什么
Harness 不是一个特定框架，而是一组让 Agent 可以工作的工程条件。Anthropic 在《Building effective agents》中使用了不同术语，却得出相近的实践结论：从简单、可组合的工作流开始，清楚设计 Agent 与工具的接口，并只在评测证明有收益时增加复杂度。这说明系统工程视角并不依赖某一家模型厂商。
第一层是任务表达。系统要把人的目标转成可执行任务，说明成功标准、边界、输入、输出和验证方式。模糊任务不一定要被拒绝，但应该先进入澄清或探索阶段，而不是直接获得高权限执行。
第二层是上下文。长期规则、项目事实、当前状态和临时证据要分开管理。Agent 不应每轮重读整个知识库，也不能只靠一段不断增长的聊天记录维持记忆。上下文路由负责在正确时间提供最小充分信息，压缩机制则要保留决策与证据，而不是只留下漂亮摘要。
第三层是工具。模型擅长判断，不擅长稳定地搬运大量数据。检索一百份文件后，筛选、排序、聚合和去重应尽可能在代码里完成，再把有限候选交给模型分析。OpenAI 将这种做法称为 Programmatic Tool Calling，其本质是把确定性工作移出模型上下文，让 Token 用在真正需要判断的地方。
第四层是状态和执行环境。长任务需要检查点、快照和可恢复运行。沙箱丢失不应让整个任务从头开始，工具超时也不应让 Agent 忘记已经完成的部分。状态必须外部化，并能回答当前阶段、已经验证的事实、未解决问题和预算剩余。
最后是验证与安全。测试、规则、第二来源、人工确认和权限策略共同决定一个结果是否可以进入下一步。Agent 可以说“完成了”，但系统应该查看目标状态是否真的改变。
把这些部件放在一起看，会发现很多被归咎于“模型不够聪明”的失败，其实来自工作环境没有给出可观察反馈。
| Harness 部件 | 缺失时的典型失败 | 可以观察的验证信号 |
|---|---|---|
| 任务契约 | 做了很多事，却没有完成用户目标 | 成功条件逐项通过 |
| 上下文路由 | 读到过期规则或被无关信息淹没 | 来源、版本和召回命中率 |
| 工具契约 | 参数猜错、把查询当成修改 | 参数校验与副作用分类 |
| 外部状态 | 对话压缩后忘记已经完成的步骤 | 检查点能恢复当前阶段 |
| 执行环境 | 一次错误污染共享项目或生产数据 | 隔离、快照与变更差异 |
| 验证器 | 把“已执行”误报成“已完成” | 测试、目标状态或第二来源 |
| 权限策略 | 模型偶尔不遵守就造成严重后果 | 拒绝日志与人工批准记录 |
这张表也给出了排障顺序：先确定失败发生在哪一层，再决定是换模型、改提示，还是修复工具和状态。若没有这一步，团队很容易用更昂贵的模型掩盖基础设施问题。
4 -> 提示词在系统中的位置变了
Harness Engineering 并不意味着 Prompt Engineering 失效。清楚的指令、例子和边界仍然重要，只是提示词不应该承担它无法可靠承担的责任。
例如，“绝对不要访问生产数据库”不应该只写在系统提示里，而应通过网络和凭据权限落实。“修改代码后必须运行测试”除了写进任务说明，还应该由 CI 检查测试结果。“只使用最新政策”不能依赖模型记忆，而要让检索层过滤版本并保留来源时间。
一个判断是否应该留在提示词里的简单方法是：如果模型偶尔不遵守会造成严重后果，就不要只靠提示词。提示词适合表达意图和偏好，基础设施负责强制约束。
优秀提示词在 Harness 中更像一份岗位说明。它告诉模型当前角色、目标和交付标准；但员工能否访问财务系统、代码能否合并、付款能否执行，不会只由岗位说明决定。
5 -> Agent 友好的工程环境是什么样
OpenAI 在Harness Engineering 实践中介绍了一项极端实验：一个内部产品的代码全部由 Codex 编写，人类工程师不手写代码，而是不断改善 Agent 的工作环境。团队的核心问题从“这一行代码怎么写”变成“Agent 缺少什么能力，怎样把它变成可理解、可强制的机制”。
这种做法不必被所有团队照搬，但它揭示了 Agent 友好环境的特征。
仓库需要容易理解。模块边界清楚，入口稳定，构建和测试命令明确，文档与代码保持一致。错误信息需要可行动，而不是只抛出一段模糊堆栈。常见操作应该被封装成可靠脚本，避免 Agent 每次重新猜测部署和迁移步骤。
验证需要靠近工作发生的位置。Agent 修改函数后可以立即跑单元测试，改界面后可以启动浏览器检查，调整数据流程后可以对小样本生成对账报告。反馈越快，错误越不容易在后续阶段放大。
一个最小执行回路可以写成下面这样。它不是生产框架，但能说明模型并不直接决定“任务完成”：动作交给工具执行，结果由验证器判断，每一步状态都写入外部检查点。
def run_task(task, agent, tools, verifier, checkpoints, max_steps=8):
state = {"task": task, "history": []}
for step in range(max_steps):
action = agent.next_action(state)
observation = tools.execute(action)
verdict = verifier.check(task, action, observation)
state["history"].append({
"step": step,
"action": action,
"observation": observation,
"verdict": verdict,
})
checkpoints.save(state)
if verdict.passed:
return {"status": "completed", "state": state}
if verdict.needs_human:
return {"status": "waiting_for_review", "state": state}
return {"status": "budget_exhausted", "state": state}
真实系统还需要处理工具超时、敏感日志、并发冲突和检查点版本，但骨架中的责任边界不应改变：模型提出下一步，确定性系统执行和记录，独立信号决定是否放行。
环境还要允许失败。独立工作区、可回滚提交、临时数据库和受控网络，让 Agent 可以大胆尝试而不破坏共享状态。这里的目标不是消灭错误，而是降低一次错误的影响，并保存足够证据让系统知道为什么失败。
6 -> 从模型中心转向任务中心
很多 AI 项目仍以模型为中心组织：先选一个模型，再寻找它能做什么。Harness 思维更接近传统产品工程：先定义任务和成功状态，再决定哪些步骤用规则、哪些用小模型、哪些需要强模型，哪些必须由人完成。
这种转向也会改变衡量方式。对于长任务，比单次 Token 价格更能暴露系统质量的，是任务连续完成率、失败后恢复时间、无效循环次数，以及错误在第几道验证中被发现。模型费用仍要计算，但应放在可靠性指标旁边看；否则一次便宜调用可能在连续重试中变成更贵的工作流。
它也会改变团队分工。产品经理需要定义可观察的完成标准，领域专家负责规则和测试样本，工程师建设工具、状态和安全边界，运营人员提供真实失败案例。提示词不再属于某个“Prompt 工程师”，而是整个执行系统的一部分。
当任务中心成为默认视角，模型就更容易替换。评测集、工具契约、状态格式和业务规则保持稳定，新模型必须在相同真实任务上证明价值，而不是只凭厂商榜单进入生产。
下一阶段的护城河，很大一部分落在模型外面。
基础模型会继续快速进步，模型之间的能力差距也会变化。应用较难复制的部分，往往是长期积累的任务数据、失败案例、工具接入、权限设计、评测体系和组织流程。这些都属于 Harness。
一家公司可以买到同样的模型 API，却买不到另一家公司几年沉淀下来的业务判断和验证闭环。后者知道哪些输入最容易出错，何时应该升级模型，哪种证据足以放行，什么操作必须停在人面前。这些系统知识比某条神奇提示词更持久。
Prompt Engineering 教会我们如何向模型表达。Harness Engineering 要解决的问题更大：如何让一个不完全可靠的模型，在真实环境里持续产生可靠结果。
当 AI 只负责回答，提示词是主要界面；当 AI 开始工作，整个工作环境都变成了提示。未来最好的 Agent 产品，不一定拥有最复杂的提示词，但一定拥有最清楚的任务、最合适的工具、最短的反馈回路和最难被绕过的边界。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/weixin_74809706/article/details/164885413
