Harness Engineering：Agent 时代的约束系统工程
核心命题
"Agents aren't hard; the Harness is hard."
——Anthropic & OpenAI 共同验证
2026 年 5 月 18 日，Anthropic 以超 3 亿美元收购了 SDK 生成公司 Stainless——一家被 OpenAI、Google、Cloudflare 共同使用的开发者工具初创公司。这笔收购看似是 AI 巨头之间的常规军备竞赛，但它暴露了 Agent 时代正在浮现的一个深层范式转变：竞争重心正从模型质量上移到 Agent 周围的运行环境——也就是 Harness Engineering。
Harness Engineering 不是优化 Agent 的输入（那是 Prompt Engineering），而是构建 Agent 的完整操作环境和约束系统。它的核心方法论可以概括为一句话：每次发现 Agent 犯错，就工程化一个方案，让它永远不能再犯同一个错误。
三个演化阶段
要理解 Harness Engineering 为什么是必然方向，需要回溯 Agent 开发的三个阶段：
阶段一：Prompt Engineering
通过精心设计的自然语言指令引导 Agent 行为。问题很明显——Agent 可以选择忽略 Prompt 中的约束。你写了"不要删文件"，它还是可能删。
阶段二：Context Engineering
通过结构化上下文（Skill 系统、RAG、Few-shot 示例）扩展 Agent 能力。这比纯 Prompt 更好，但约束力仍然依赖于 Agent 的"遵守意愿"。
阶段三：Harness Engineering
在 Agent 周围构建不可绕过的规则引擎、沙箱、验证管线。不是"请 Agent 不要犯错"，而是"Agent 无法犯错"。从自然语言约束升级为编译时/运行时的代码级约束。
五层技术架构
完整的 Harness 工程体系由下至上分为五层：
① 接口层：Agent 的工具总线
Agent 需要与外部世界交互。MCP（Model Context Protocol）正快速成为这个层的标准协议——它定义工具发现、调用、结果返回的统一格式。就像 USB 统一了外设连接，MCP 在统一 Agent 的工具连接。Harness 层还需要工具能力注册表（带权限声明、速率限制、成本标签），让 Agent 在调用前就知道某个工具能不能用、代价多大。
② 约束层：不可绕过的规则引擎
这是 Harness 工程最有别于 Prompt 工程的层。规则即代码（Rules-as-Code）用编译器/Lint 替代自然语言约束——生成的代码必须通过 ESLint/TypeScript 编译，失败则自动回退修正。借鉴 Kubernetes 准入控制，OPA/Rego 策略引擎在 Agent 的每个操作真正执行前进行拦截裁决。关键是：Agent 不能绕过这些约束。
实际案例：Agent 想执行 kubectl delete pod --all，策略引擎拦截 → 检查操作类型（删除）、范围（全局）、环境（生产）→ 拒绝。要求人工确认+输入生产环境名称。
③ 可观测层：决策追溯与行为审计
当部署出问题时，需要回答的核心问题是：Agent 做了什么、为什么这么做？决策链路追踪记录了 Agent 的完整推理链——就像分布式追踪的 Span，但追踪的是思维过程而非微服务调用。幻觉检测要求 Harness 独立验证 Agent 声明的结果与工具实际返回值是否一致——这个验证必须独立于 Agent 本身执行。
④ 验证层：多维度质量围栏
验证管线不是简单的 CI。完整链路是：类型检查 → Lint → 安全扫描 → 依赖审计 → 测试生成 → 测试执行 → 突变测试。每一步失败都会把错误反馈回 Agent 触发自动修复循环。SLA 围栏设定硬性指标——单次变更最大文件数 < 20、P99 响应延迟 < 200ms——超标自动回滚。
最高阶的验证是语义等价验证：Agent 重构了代码，如何确保新旧代码行为一致？务实方案是用差分模糊测试同时对旧代码和新代码输入大量随机数据，对比输出差异。
⑤ 编排层：多 Agent 协同与状态机
单个 Agent 的行为被约束在显式的有限状态机内：分析 → 规划 → 实现 → 自审 → 测试 → 修复 → 提交 → 人工审批 → 部署。每个状态有明确的进入条件、退出条件、超时时间。
多 Agent 协作有三类模式：
- Critic-Generator：一个生成，一个专职批评。不是对话，是结构化的评审→修改循环
- Orchestrator-Worker：编排 Agent 分解任务，Worker 并行执行。编排 Agent 不写代码，只分配和合并。Worker 向 Orchestrator 汇报时只传递结构化摘要，防止原始对话中的错误在多 Agent 间级联放大
- Consensus：N 个 Agent 独立解决同一问题，投票决定结果。成本高但适合高风险变更
两条反直觉的核心原则
原则一：约束不是限制，是生产力
被 Anthropic 和 OpenAI 团队反复验证的发现：Agent 产出质量与自由度的平方成反比。给 Agent 更多规则、更窄的操作范围、更严格的验证，产出质量反而更高。因为 Agent 在明确边界内操作时，所有推理资源都聚焦在边界内的最优解。
原则二：Harness 的可累积性
Prompt 技巧不可累积——每次换模型、每次换任务，之前的好 Prompt 可能完全失效。但 Harness 工程构建的 Lint 规则、验证管线、策略引擎、沙箱——无论底层模型怎么换，始终生效。这是 Harness 工程比 Prompt 工程有长期战略价值的原因。
| 维度 | Prompt Engineering | Harness Engineering |
|---|---|---|
| 作用对象 | Agent 的输入文本 | Agent 的运行环境 |
| 可绕过性 | Agent 可选择忽略 | 编译时/运行时强制 |
| 跨模型可移植性 | 低（每个模型不同） | 高 |
| 可累积性 | 低（每次从头调） | 高（约束持续增值） |
| 维护成本 | 模型升级即重写 | 只需增删规则 |
Anthropic 收购 Stainless 的 Harness 视角
回到开篇的收购事件。Stainless 做的核心产品是从 API spec 自动生成并持续维护多语言 SDK——这本质上是 Harness 工程接口层的标准化工具。当 AI Agent 需要调用外部 API 时，它需要一个可靠、自动更新的 SDK——而 Stainless 提供的就是这个。
Anthropic 收购后立即宣布关停所有托管产品，意味着 OpenAI、Google、Cloudflare 等竞争对手将失去这个 Harness 基础设施的访问权。这是典型的「买赛道」战略——买入的不是收入，是竞争对手的开发效率。
更深层看：Anthropic 正在从模型公司转型为 Agent 全栈平台——Claude（模型）+ Stainless（接口层）+ Bun（运行时）+ Vercept（计算机操作）= Agent 需要的完整 Harness 体系。
技术成熟度展望
| 层级 | 现在（2026 Q2） | 近期（12个月） | 远期（3年+） |
|---|---|---|---|
| 接口层 | MCP 趋于稳定 | 工具注册表标准化 | Agent 自动发现+动态绑定 |
| 约束层 | Lint+基础沙箱 | OPA 策略引擎普及 | 语义级约束（"不能有SQL注入"） |
| 可观测层 | 日志+基础追踪 | 决策链路结构化存储 | 完整确定性回放 |
| 验证层 | CI 自动化+测试生成 | 差分模糊测试 | 形式化语义等价验证 |
| 编排层 | 单Agent+简单回退 | 多Agent协作+FSM | 自主Agent编队+动态角色 |
结论
Agent 时代最被低估的事实是：Agent 本身不难，难的是让 Agent 不出错的 Harness 系统。Prompt 工程的边际收益在递减——再好的 Prompt 也不能阻止 Agent 执行 `rm -rf /`。Harness 工程才是把可靠性从 80% 推到 99.9% 的关键路径。
当下最值得投入的方向不是更好的 Prompt，而是构建可累积、跨模型、不可绕过的约束层——因为约束是 Agent 时代唯一能持续增值的工程资产。
参考：Epsilla Blog "Why Harness Engineering Replaced Prompting in 2026"；TechCrunch "Anthropic has acquired the dev tools startup used by OpenAI, Google, and Cloudflare" (2026-05-18)；Harness 平台 "Harness AI February 2026 Updates"