点击下方“JavaEdge”，选择“设为星标”

第一时间关注技术干货！

本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！

• 🚀 魔都架构师 | 全网30W技术追随者

• 🔧 大厂分布式系统/数据中台实战专家

• 🏆 主导交易系统百万级流量调优 & 车联网平台架构

• 🧠 AIGC应用开发先行者 | 区块链落地实践者

• 🌍 以技术驱动创新，我们的征途是改变世界！

• 👉 实战干货：编程严选网

0 前言

如果你的 Agent 水平还停在“咋写条更好的 Prompt”，本文必须看完。25 年底到 26 年初，Anthropic、OpenAI、Google DeepMind、Stripe、Windsurf 等公司几乎同时公开表达了同一件事：决定 Agent 能否上线的，不是你写了哪条 Prompt，甚至不只是你选了哪个模型，而是你给模型搭了什么样的运行系统。这个运行系统，就是Harness。

1 Harness Engineering 到底是啥？

Harness 原意是“马具”：马很强、很快，但它自己不知道该往哪跑；骑手给方向，马具把力量转成可控行动。

类比AI：

• 马：模型（强大但不稳定）

• 骑手：人类工程师（定义目标）

• 马具：Harness（让模型稳定完成工作的一整套系统）

所以，Harness Engineering 不是教模型“咋回答”，而是设计模型“咋工作”。它处理的是模型外面那一整层工程问题：

• 任务咋拆解

• 上下文咋管理

• 工具咋编排

• 权限咋设定

• 状态咋交接

• 做完咋验证

• 失败咋恢复

• 啥时交还控制权给人

这不是一条 Prompt 能解决的，而是完整系统设计问题。

2 这个概念是怎么爆发的？

一个关键时间点是2026 年 2 月 5 日提出一句非常有传播力的话：

每当你发现 Agent 犯一个错误，就工程化一个方案，让它永远不再犯同样的错。

”

随后 OpenAI 在官方博客发布《Harness Engineering》，把概念推到台前。Anthropic 其实更早在做：25 年 11 月就发布《Effective Harnesses for Long-Running Agents》，并把 Claude Agent SDK 定义为通用 Harness：

• Anthropic：实践在先

• 社区：命名扩散

• OpenAI：大规模传播

3 v.s Prompt Engineering、Context Engineering

• Prompt Engineering（2022-2024 主导） ：关注“怎么问”，本质是文本层优化

• Context Engineering（2025 主导） ：关注“让模型看到什么”，包括 RAG、记忆注入、工具定义、对话历史管理等

• Harness Engineering（2026 显性化）不只管“看到什么”，还管“怎么干活、怎么验证、怎么恢复、怎么交接控制权”

一句话：

• Prompt：告诉它右转

• Context：给它地图，解释右转

• Harness：给整辆车（方向盘、刹车、护栏、维修、告警和安全机制）

Anthropic 在 2026 年 3 月也明确表达：Prompt 和 Harness 都重要，但随 Agentic Coding 进入生产，性能瓶颈越来越落在 Harness 质量。

4 为啥在25年底-26年初 爆发？

1. 模型能力抬升后，系统设计成为主要差异源模型够强，但没有好运行环境，能力发挥不出来。

2. 长任务暴露了裸模型缺陷跨多个上下文窗口时，模型常见失败模式是：

• 想一次做完所有事情，导致上下文崩坏

• 看到局部进展就提前宣布完成，不做验证

• 多步流程的成功率塌缩例如每步成功率 95%，串联 20 步后端到端成功率只剩约 36%。 所以“每步都还行”不等于“任务能完成”。

• 模型趋同，系统层成为新护城河当 GPT、Claude、Gemini 在核心能力上逐步收敛，竞争点自然转移到 Harness。

• 5 头部公司到底怎么做 Harness？

  5.1 Anthropic：从双 Agent 到三 Agent

  早期方案是双角色：

  • 初始化 Agent：建环境、写初始化脚本、建进度文件、展开需求清单

  • 执行 Agent：逐项推进、读进度、跑测试、增量提交

  核心思想：把记忆外置成工件，而不是只靠会话上下文。 如进度文件、Git 历史、结构化需求清单。

  后续演进为三角色：

  • Planner（规划）

  • Generator（实现）

  • Evaluator（验证，含交互测试）

  关键发现：评估器分离。 让模型自评时，它容易“自信但宽松”；独立、严格的评估器更容易工程化出稳定质量。

  还有一个重要观察：Harness 必须和模型能力匹配。某些在旧模型上必要的“上下文重置机制”，换到更强模型后可能反而变成负担。

  5.2 OpenAI：高吞吐案例与三大支柱

  公开案例里，一个小团队在数月内让 Codex Agent 生成大量代码并合并大量 PR。
  他们总结出的三大支柱：

  1. Context Engineering：知识持续入库，连接可观测性与运行时信号

  2. 架构约束：用确定性检查（lint/结构测试）执行规则，而非“相信模型会遵守”

  3. “垃圾回收”机制：后台 Agent 周期巡检，清理文档不一致和架构漂移

  一个值得记住的模式：

  当 Agent 卡住时，不是“再让它更努力”，而是补它缺的能力，并让该能力对 Agent 可读、可执行，再让系统自我修复。

  5.3 Google DeepMind：产品化验证与结构同构

  在数学研究 Agent 案例里，典型是三组件循环：

  • 生成（Generator）

  • 评审（Reviewer）

  • 修订（Reviser）

  这和 Anthropic 的 Planner/Generator/Evaluator 结构高度同构。
  说明“生成-评估分离”不是单点偏好，而是工程实践下的收敛模式。

  另外，Google 在框架层也加强了评测 Harness、脚手架、可观测性、图形化编排等能力。

  

  5.4 Windsurf 与 Stripe：约束反而提升性能

  Windsurf 的经验很典型： 工具给太多，Agent 反而困惑、乱调用、步骤膨胀；删掉大量工具后，步骤更短、成功率更高、成本更低。

  这指向一个反直觉原则： 提高自主性，往往需要更强约束，而不是更少约束。

  Stripe 的做法是给 Agent 预热沙箱、隔离环境，并通过统一协议接入大量内部工具，同时保持安全边界。

  6 成熟 Harness 的模块

  综合多家公司实践，可以归纳为六层：

  上下文与知识管理

  

  工具编排与权限边界

  

  验证机制与硬约束

  

  状态管理与记忆持续性

  

  可观测性与反馈回路

  

  人类接管与生命周期管理

  

  这六层合起来，才构成可生产化的 Agent Harness。

  7 这是“新瓶装旧酒”？

  Harness Engineering很多并不新：

  • CI/CD

  • Linter

  • Pre-commit Hook

  • 沙箱隔离

  • 可观测性

  • 分布式任务编排

  都来自成熟软件工程。但它也不是“完全旧酒”：

  1. 约束对象变了：从确定性代码，变成概率性推理系统

  2. 约束逻辑变了：约束不是限制创造力，而是提升系统稳定性

  3. 结构模式收敛：生成-评估分离被反复验证

  4. 代码库角色变了：不仅服务人类可读，也服务 Agent 可推理

  因此更准确的说法：Harness Engineering 是在 Agent 生产化压力下，对多种成熟工程实践的重组与再工程化。

  8 风险与局限

  概念膨胀风险 ：什么都叫 Harness，会导致概念失焦。

  过度工程化风险 ：模型升级后，一些历史补丁式模块可能变成包袱。

  证据基础不足 ：现阶段很多证据来自厂商自述，独立可复现 benchmark 仍不足。

  可复现性缺口 ：头部团队的成功案例在普通团队里是否可复制，尚未被充分验证。

  风险放大效应 ：更复杂的多 Agent 编排可能提升效率，也可能放大新型错误与污染概率。

  9 给正在做 Agent 的团队

  务实三步：

  立刻可做 ：在项目根目录创建 AGENTS.md（或等价规则文件），每出现一次重复错误就沉淀一条可执行规则。

  中期投入 ：建立确定性验证层：Linter、结构测试、Pre-commit Hook，再加基本可观测性。

  长期建设 ：设计模块化、可替换的 Harness 架构，支持模型升级时平滑迁移。

  10 总结

  • Prompt Engineering 解决“怎么说”

  • Context Engineering 解决“给模型看什么”

  • Harness Engineering 解决“让模型在什么机制里干活，并确保它把活干成”

  Agent 不难，Harness 才难。

  编程严选网：http://www.javaedge.cn/

  专注分享AI时代下软件开发全场景最新最佳实践~