背景

在人工智能走向自主智能体（AI Agents）的进程中，2026年标志着一个关键的转折点。过去，行业的焦点集中在提升大语言模型（LLM）的参数量和推理能力上；但如今，瓶颈已经发生了转移——AI智能体生成代码和解决方案的速度，已经远远超过了人类团队能够验证其安全性和正确性的速度。

“Harness工程”最先由业界从2025年底开始提出。它着眼于为AI智能体提供一个完整的运行环境和工作流，使模型使用工具、执行多步任务，真正“做实事

如果一个演示系统有 90% 的成功率，这仅仅是完成了“第一个九”。在实际生产中，一个包含10个步骤的 Agentic Workflow 如果每步只有 90% 的可靠性，那么它每天会失败超过6次。仅靠提示词工程（Prompt Engineering）根本无法达到生产级别的稳定性。

就是说

真正卡你的不是 Agent 写代码的能力，而是围绕它的结构、工具和反馈机制跟不上

不是我们模型的能力限制，是你没准备好给他一个适于写代码的环境！

所以我们的Harness Engineering就是相当于汽车的壳子，模型相当于我们的发动机！

在OpenAI的定义中，harness工程是一种内部方法论，将Codex（GPT系列的代码模型）等智能体嵌入到软件开发生命周期的各个环节：它包括标准化工作流、反馈循环、脚手架和验证机制，使得代码编写、测试生成、可观察性管理等任务由AI智能体自动执行

Harness工程可定义为：“将AI模型转化为可用系统所依赖的所有非模型代码、配置和执行逻辑”，使得原本无状态的模型在多步、可测、可安全的任务中表现可靠。

架构设计

Agent目前的架构划分

在目前的 AI 工程栈中，极易混淆“框架（Framework）”、“运行时（Runtime）”与“线束（Harness）”的概念。根据 LangChain 等前沿机构在2026年的最新定义，这三者在架构中扮演着截然不同、层层递进的角色：

然后我们之前划分的多个提示词工程，上下文工程，约束工程他们分别的关系是什么样子的呢？

然后如果我们去说一个包含关系的话，提示词工程是最细的，上下文包含提示词，约束工程包含上下文

在 Prompt/Context 范式下，交互模式基本是“你问我答”：人类提出问题或任务描述，模型一次性给出结果。复杂任务需要人类不断分解、重试和手动粘合中间结果。

Harness Engineering 下，交互模式变为“赛道设计”：工程师定义任务拆解策略、仓库结构、工具集合和验证流程，Agent 按既定循环（Plan‑Build‑Verify‑Fix）长时间运行，Harness 负责中途纠偏和状态持久化。人类更多在元层面对系统进行调参和改进，而非直接介入每一步代码生成。这个感觉是未来的大大的方向

Harness的核心设计

一个成熟的 Harness（例如 LangChain 研发的 deepagents 库）必须通过提供特定的工具和环境，来对抗模型上下文窗口的退化和逻辑发散。目前行业标准的 Harness 包含以下核心原语：

• 强制规划工具：Harness 强制要求智能体在采取任何行动前，调用 write_todos 等规划工具。这本质上是一个“空操作（no-op）”，但它迫使智能体将复杂的长线任务拆解为离散步骤，防止在长周期任务中迷失方向。这个的话就比如我们维护一个当前任务的步骤的文件，然后我们每次开始之前都要去读步骤，然后结束的时候都要去写入。
• 持久化文件系统：Harness 提供了一套受控的虚拟文件系统工具（如 read_file, write_file, ls, grep）。由于网络搜索或日志结果往往高达数万 Token，直接塞入会“撑爆”上下文窗口。Harness 引导智能体将庞大的输出写入文件系统作为“共享账本”，按需读取，这被称为上下文卸载（Context Offloading）。就是用文件系统来作为我们Agent的记忆！可以按需求的读取和加载。业界常用的就是提供一个沙箱的文件的文件环境！
• 子智能体隔离：在处理复杂项目时，Harness 允许主智能体派生子智能体。其核心价值在于上下文隔离：子智能体在自己独立的上下文中执行几十次工具调用，完成后仅将压缩后的最终结果返回给主智能体，从而确保主上下文的纯净性。这个也是很重要的，因为如果不隔离的话，他们的上下文混合在一起，非常混乱，我们的主Agent只去关心子Agent执行的结果，不关心的执行过程！
• 沙箱与 Ralph Loops 强制闭环：智能体生成的代码不能在宿主机直接运行。Harness 提供了安全的 Docker 沙箱环境执行 Bash 命令。 更关键的是引入了 Ralph Loops（测试优先闭环）：Harness 不允许智能体单方面宣布“任务完成”。当智能体试图退出时，Ralph Loop 会拦截退出请求，强制执行测试。如果测试失败，Harness 会将红色的报错堆栈作为客观证据反馈给模型，强制其开启新一轮迭代，直到客观测试通过。这种机制将盲目的代码生成转化为严谨的“测试驱动开发（TDD）”。这个是非常重要的！因为Ai很可能就不测试就告诉你完成了！所以这个执行完的检查钩子是非常重要的！
• 遥测与极端验证：对于关键任务，Harness 会接入遥测数据。例如 Datadog 在其 Harness 实践中，建立了一个验证金字塔：从最底层的经验法则（Telemetry）到有界验证（如 Rust Kani），甚至采用 TLA+ 形式化模型检查技术，将架构决策记录（ADRs）自动转化为状态不变量，用机器证明来彻底杜绝 AI 的违规操作。

然后我们一般都分为两个阶段：脚手架（Scaffolding）和运行时Harness

• 脚手架负责在第一个提示前构造完整的Agent（如系统提示、工具注册、子Agent初始化），我们可以称它为环境准备或者是初始化
• 运行时Harness则将一个单轮LLM推理升级为持续的、多步骤的工作循环，包括工具调度、上下文管理、安全检查和状态持久化

开发阶段：

然后可能持续推理的流程是：

1）初始化环境：建立仓库结构、配置CI/CD流水线、编写初始提示和环境模板；

2）迭代开发：Agent根据提示执行功能开发，生成代码并提交Pull Request；

3）自动验证：集成测试、静态分析和度量（比如性能指标）被Agent自发执行，或由Harness监控；

4）反馈调优：通过日志和Trace分析自动发现错误模式，工程师或子Agent据此调整提示、工具链或架构约束。

测试阶段：

然后里面毕竟重要的就是测试阶段，因为现在AI写代码是OK的，但是你不知道写的代码能不能符合你的要求！所以测试反攻是必须的！

Harness工程需要内置可度量的标准：

OpenAI实验中，Codex智能体在提交PR时必须满足基准测试和性能约束（如“启动时间小于800ms”）。这些度量通过日志（LogQL）和指标查询（PromQL）自动暴露给Agent，使其能够根据反馈自适应改进。Anthropic的做法则是在每次会话结束时让Agent提交进度文件和Git提交，以确保后续会话能无缝接续。总之，Harness工程强调“可观测性”，要求系统提供机器可读的度量（测试结果、日志、监控指标），并让智能体能够使用它们自验证。

运维阶段：

Harness工程倾向于使用容器化和临时环境。各Agent会话常在隔离的沙箱或容器中运行，生成的应用能够在这些环境中启动和测试

OpenAI实验让Codex在临时工作区启动应用，并通过Chrome DevTools获取UI快照，能够重现和修复Web界面Bug；LangChain团队使用Harbor框架在沙箱中运行Agent，并记录每一步操作到LangSmith平台。同时，安全性通过沙箱、白名单/黑名单机制以及最小权限策略来保障。例如，一个好的Harness会为代码执行、文件访问、网络请求加上资源隔离限制，以防止Agent越权操作。这使得安全成为架构设计的一部分，而非事后附加的补充。

可解释性和合规性：

Harness工程通过结构化文档和规则来增强。例如，构建可供Agent理解的文档（如质量守则、任务规范、示例项目代码）可以提高系统的透明度。结构化的测试用例（如JSON格式）和强制执行的格式规则也让Agent行为更可预测。Harness也要求对Agent的决策过程保留可追溯记录——如LangSmith跟踪了每个Agent动作的输入输出，有助于后续审计。合规性方面，重要的是把安全检查（如代码审计、依赖性扫描）纳入自动流程，并用AI Agent或自动化工具定期检查政策符合度。这些做法结合起来，提升了Agent工作流的透明度和可管理性。

数据与模型治理

Harness工程引入了可控的迭代循环。工程师负责维护知识库和提示模板（Knowledge Engineering），不断迭代改进Agent的环境约束和上下文。例如，LangChain团队通过中间件注入目录上下文和测试框架信息，教会Agent自测代码；Anthropic使用进度日志记录前置和当前状态，确保多会话间的知识传递。模型治理方面，通常由开发者管理使用的模型版本和容量（如固定使用GPT-5.2 Codex），并在Harness层面约束其行为（例如限制工具使用权限），以避免模型输出的不确定性引发安全风险。整合这些治理措施后，团队实践发生了变化：所谓“Prompt Engineer”或“Harness Engineer”角色开始出现，他们负责设计系统提示、编排工具和监控反馈循环，而传统工程师则更多地转向定义需求和维护底层架构

1
2
3
4
5
6
7
8
9
10
11
12

sequenceDiagram
    participant Codex
    participant App
    participant ChromeDevTools
    Codex->>App: Snapshot (BEFORE)，触发UI操作
    App-->>ChromeDevTools: 发送运行时事件
    ChromeDevTools-->>Codex: 返回指标/日志
    Codex->>App: Snapshot (AFTER)，应用修复，重启
    loop 直至通过
        Codex->>App: 重新运行验证
        App-->>ChromeDevTools: 反馈结果
    end

与传统软件工程相比，Harness工程的最大区别在于关注层级的提升。传统软件工程关注代码实现、算法设计和单元测试，而Harness工程则更多关注环境设计和工程流程本身。在Harness范式下，“写代码”只是代理的一部分工作，工程师的主要职责是设计可执行环境、定义高层意图，以及构建结构化反馈机制

Harness工程更加重视工具链和系统运营。ML工程关注数据获取、模型训练和评估，而Harness工程假设核心模型能力已经足够强大，重点在于如何让模型安全、高效地工作于生产环境中。

Codex实践

OpenAI 在内部进行了一场长达五个月的极端工程实验，展示了当 Harness 足够强大时，可以达到何种自动化程度。

通过部署高度定制的 Harness，一个小型的工程师团队依托 Codex 智能体，构建并发布了一个包含 100万行代码 的内部 Beta 产品 。在此期间，人类工程师没有手动编写过一行产品源代码 。

在这个百万行代码的系统中，OpenAI 引入了两项极具启发性的 Harness 机制：

1. 硬性架构约束（Architectural Constraints）：不能指望 AI 靠阅读文档来遵守架构规范。Harness 部署了确定性的自定义静态检查器（Linters）和结构测试，在机器级别强制执行业务领域之间的依赖关系边界。
2. “垃圾回收”智能体（Garbage Collection Agents）：在无人写代码的环境中，代码库熵增依然不可避免。Harness 会定期释放“垃圾回收”智能体，它们唯一的任务就是在后台巡逻，查找并修复死代码、文档漂移（Documentation Drift）以及违反架构规范的细微错误，以此来对抗系统的物理衰退。这个也是非常重要的，因为错误过时的文档会对我们产生错觉的影响

如何去做一个Harness 系统

一：

• 将 AGENTS.md 从“万能提示词”重构为“项目地图”：用约百行文字说明项目结构、关键命令、最重要的架构约束以及指向详细文档的入口，而不是堆砌所有规则和细节。

• 将在 Code Review 中反复出现的意见转化为 Linter 规则或结构化测试，并在错误信息中附带修复建议链接，让错误提示本身成为 Agent 和新人的教学材料。

二：

• 完成前强制验证（Pre‑Completion Checklist）：在所有 Agent 任务中内置“完成前必须运行测试、检查 Linter、必要时启动应用进行端到端验证”的约束，避免“幻觉式成功”。
• 跨会话进度文件：为复杂任务设计 Agent 可读写的结构化进度记录，使每次调用都从上次状态继续，缓解上下文丢失问题。
• 基础可观测性注入：确保 Agent 能方便地查询关键日志和指标，而非仅依赖编译错误信息进行调试。

三：

• 部署专门的“文档整理”和“架构一致性” Agent，定期扫描并提交清理 PR，对抗熵增。
• 提炼跨项目可复用的 Harness 模板，将自定义 Linter、结构化测试、基础文档和可观测性配置封装为“服务模板”或“平台蓝图”，在新项目中快速复用。
• 引入 Trace 分析管线，让 Agent 利用运行轨迹自动归纳失败模式并提出 Harness 改进建议，实现 Harness 自演化。