Harness Engineering 是 AI 工程领域继 Prompt Engineering、Context Engineering 之后的第三次重心迁移。从演进、构成、实践三个角度把它讲透

下面从演进、构成、实践三条线把 Harness Engineering束具工程 / 驾驭层工程 讲清楚并各配 OpenAI 与 Anthropic 的可核对公开案例附链接。一、演进为什么重心会从「提示」到「上下文」再到「束具」可以把三代重心理解成问题域在变大从「一句话怎么写」到「每一步模型看见什么」再到「整套系统怎么在真实世界里跑得稳」。Prompt Engineering提示工程核心问题是单次调用里指令怎么表达才能让模型更听话、更一致。它假设瓶颈主要在「措辞与结构」。当模型较弱、任务较窄时这很有效。Context Engineering上下文工程当窗口变大、工具变多、流程变长瓶颈转移到在每一步把「该知道的」以正确粒度、顺序、预算送进模型。它处理的是信息流与记忆/检索/工具结果的编排而不仅是提示文本本身。社区里常见表述是提示工程是上下文工程的子集。Harness Engineering束具工程再往前一步即使上下文配好了生产级失败往往来自系统层——工具调用失败、越权动作、成本失控、静默退化、分布漂移、评测与线上不一致等。Harness 关注的是模型之外的执行环境循环、约束、验证、恢复、观测与治理。Martin Fowler 等讨论里会用 Agent Model Harness 这类心智模型来概括「除模型以外的部分」。一句话串起来Prompt 解决「怎么说」Context 解决「给什么信息」Harness 解决「在什么规则与反馈下持续行动并被证明可靠」。术语说明「Harness」在英文里同时让人联想到测试束具test harness与马具/缰绳——前者强调可重复的驱动与断言后者强调约束与护栏两种联想对理解这一层都成立。二、构成Harness 通常包含哪些「模块」不同团队拆分方式不同但生产级 Harness 往往反复出现以下几类构件Context 通常被嵌套在 Harness 内而不是与之并列对立模块解决什么典型手段上下文与记忆长程任务中的精度与预算分步装配、摘要、外部状态文件/DB、子代理隔离噪声工具与编排何时调用什么、失败怎么办工具协议、权限、重试、超时、并行与 handoff验证与闭环防止「看起来对」schema 校验、单测/类型检查/静态分析、LLM-as-judge慎用、验收清单护栏与安全越权、注入、数据外泄输入/输出过滤、审批、沙箱、最小权限观测与评测可调试、可回归、可对比Trace、分级评测、数据集 eval、与线上结果对照人机协同高风险决策HITL、审批队列、可恢复的检查点Fowler 一文里还有一个实用二分前馈控制guides与反馈控制sensors——前者在行动前引导后者在行动后用「对模型友好」的信号例如带修复提示的 lint驱动自纠。三、实践OpenAI 与 Anthropic 在「真实产品/公开叙述」里怎么做OpenAI公开工程博文与平台能力「Harness engineering」作为方法论Codex 五个月、零手写代码的内部实验OpenAI 在 Harness engineering: leveraging Codex in an agent-first world 中描述团队用约五个月、以 Codex 生成应用、测试、CI、文档、可观测与内部工具等全部代码强调工程重心是环境设计、意图表达、反馈闭环而不是堆提示。文中量级叙述包括约百万行代码量级、约 1500 个 PR、小团队驱动等——这是官方对「Harness」一词在 AI 工程语境下的直接用法。产品化「Codex harness」与 App ServerUnlocking the Codex harness: how we built the App Server 把 Codex harness 定义为跨 Web/CLI/IDE/macOS 等表面共享的代理循环与配套逻辑并通过 Codex App ServerJSON-RPC 把同一条 harness 暴露给不同客户端——这是典型的「把执行环境产品化、协议化」的 Harness 工作。长程任务强调循环与外部化状态而非单条神 promptRun long horizon tasks with Codex 明确把可靠性归因于 plan → 改代码 → 跑工具 → 看结果 → 修错 → 更新文档/状态 的闭环以及把 spec、计划、约束写进仓库文件作为耐久记忆——这是 Harness 层「状态与验证」的实践模板。平台侧Agents SDK 把 Harness concern 做成一等公民OpenAI Agents SDK 公开特性包含agent loop、handoff、guardrails、human-in-the-loop、tracing 等——这些正是「模型调用之外」的束具层。官方文档 Evaluate agent workflows 则把 trace 分级 → 数据集 eval 作为从调试走向可重复评测的路径。Skills Evals 的工程化闭环Testing Agent Skills Systematically with Evals 用 codex exec、JSONL 事件流、确定性检查 描述如何把技能改进从「感觉更好」变成「可证伪的回归信号」——这是 Harness 中的 evaluation harness 范本。Anthropic工程博文、System Card、安全体系Claude Code「Auto mode」用分类器替代部分人工审批Claude Code auto mode: a safer way to skip permissions 描述两层防线输入层如面向工具输出的注入探测与输出层对将执行动作做分类决策并讨论 over-eager、误读范围、注入 等失败模式——这是典型的 Harness 层安全与策略而不是改 system prompt 能单独解决的。System Card 中的 agentic safety / tool use 评测叙事例如 Claude Opus 4.6 system card 等文档中Anthropic 系统性地披露 agentic coding、工具滥用、提示注入鲁棒性、reward hacking、过度主动行为 等评估维度。对工程团队而言这些公开材料说明供应商也在把「工具型智能体」的风险当成 harness eval safeguards 问题来管。上线后检测与分类器体系Building safeguards for Claude 概述 前置评测 实时分类器检测 账户级处置 聚合监控如分层摘要——这是把 Harness 从「开发态」延伸到「运营态」的完整链条。最后你怎么判断自己是在做 Harness 而不是「还在调 prompt」若你的工作主要在回答下面这类问题你已经在 Harness 层失败时能否定位到哪次工具、哪次 handoff、哪条 guardrail改动 prompt/模型版本后能否用 trace 数据集 证明没有回归是否对权限、成本、超时、重试、人类审批有明确策略是否把「完成定义」写进了可执行的检查测试、schema、验收步骤而不只是文案OpenAI 用「五个月 Codex 实验」把结论写得很直白竞争力来自束具与闭环Anthropic 则用 Claude Code 与 safeguards 证明高自主性必须配分层检测与运营治理。两边合在一起恰好勾勒出第三次重心迁移的实质——从会聊的模型到会交付结果的系统。