2025 年是 Agent 的，2026 年是 Harness 的——AI 编程 Harness 架构深度解析

同一个模型，换一套 Harness，从排行榜 Top 30 跳到 Top 5。模型是商品，Harness 才是护城河。

一、引言：一场静悄悄的范式转移

2026 年 2 月，OpenAI 发了一篇只有两个词的博客------Harness Engineering。

文中披露了一个惊人实验：最初 3 人（后扩至 7 人）的团队，用 5 个月时间，让 Codex Agent 构建了一个超过 100 万行代码 的生产级应用------全程零人类手写代码。工程师的角色彻底改变了：不写代码，而是设计让 AI 写代码的系统。

几乎同一时间，LangChain 团队发布了一项对照实验：他们的编程 Agent 在 Terminal Bench 2.0 基准测试上从 52.8% 跃升至 66.5% ，从排行榜 Top 30 直接冲进 Top 5。关键的是------模型一行没换，改的只是 Harness。

改进项	做了什么	效果
自验证循环	添加提交前检查清单中间件	提交前自动捕获错误
上下文工程	启动时注入目录结构映射	Agent 从一开始就理解代码库
循环检测	追踪重复文件编辑次数	防止"死亡循环"
推理三明治	规划/验证阶段用高推理，实现阶段用中推理	在时间预算内提升质量

Stripe 的内部编程 Agent "Minions " 每周产出超过 1000 个合并的 Pull Request，从任务分配到代码合并，中间无需任何人类介入。

2025 年证明了 Agent 能干活。2026 年要解决的是让 Agent 可靠地干活。模型正在商品化，Harness 正在成为新的核心竞争力。

二、Harness 到底是什么？

马具隐喻

"Harness"一词源自马具------缰绳、马鞍、嚼子------一整套用来驾驭强大但不可预测的动物的装备。这个隐喻精准地描述了当前 AI 编程的处境：

马（模型）：强大、快速，但不知道该往哪跑
马具（Harness）：约束、护栏、反馈循环，将模型的能力导向正确方向
骑手（工程师）：提供方向，而不是亲自奔跑

没有 Harness，AI Agent 就是一匹旷野上的骏马------跑得快、看着酷，但完全不能帮你完成任何工作。

技术定义

Agent = Model + Harness

如果你不是模型本身，那你就是 Harness 的一部分。

Harness 是模型之外的一切------代码、配置和执行逻辑。它将一个"文本预测器"变成一个能采取行动、使用工具、记住上下文、处理错误、跨多步推进目标的自主代理。

具体来说，Harness 包含：

系统提示词（System Prompts）
工具、技能、MCP 及其描述
绑定基础设施（文件系统、沙箱、浏览器）
编排逻辑（子代理生成、任务交接、模型路由）
钩子/中间件（压缩、续写、Lint 检查等确定性执行逻辑）

三、Harness 的九大核心组件

基于对 Claude Code、OpenAI Codex、Cursor 等主流工具的架构分析，一个生产级 Harness 通常包含以下九大核心组件：

组件全景图

c 复制代码

┌──────────────────────────────────────────────────────────────────┐
│                     Agent Harness 架构全景                        │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ① 模型接口 ────── 抽象层，可替换不同 LLM                          │
│        │                                                         │
│  ② 工具注册表 ───── 文件读写、Shell、MCP、浏览器、Git ...            │
│        │                                                         │
│  ③ 上下文管理器 ─── 截断、压缩、检索、选择性注入                    │
│        │                                                         │
│  ④ 规划模块 ────── ReAct 循环 / 预规划 / 层级式                    │
│        │                                                         │
│  ⑤ 执行引擎 ────── 沙箱、超时、输出格式化、并行执行                 │
│        │                                                         │
│  ⑥ 记忆系统 ────── 上下文内记忆 / 外部存储 / 情景记忆 / 语义记忆    │
│        │                                                         │
│  ⑦ 反馈与观察循环 ─ stdout/stderr、进度追踪、循环检测              │
│        │                                                         │
│  ⑧ 安全与护栏 ──── 确认门控、行为过滤、范围限制、审计日志           │
│        │                                                         │
│  ⑨ 编排层 ──────── 多代理路由、生成、结果聚合、状态同步             │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

接下来逐一深度解析。

① 模型接口：可插拔的"大脑适配器"

模型接口负责 Harness 与底层 LLM 的通信。好的模型接口是一个可替换的适配器，而非硬编码依赖------你可以把 Claude 换成 GPT 或 Gemini，而不需要重写工具逻辑。

现代 Harness 将模型接口视为一个抽象层：

vbnet 复制代码

Harness → Model Interface → Claude / GPT-4o / Gemini / DeepSeek

这也是 LangChain 等框架快速增长的原因------它们标准化了模型接口，使其他所有组件都能模型无关。

② 工具注册表：Agent 的"手和脚"

工具是 Agent 能"做事"的基础。当模型需要调用工具时，它生成一个结构化请求（通常是 JSON），Harness 拦截、验证并路由到对应的执行函数。

以 Claude Code 为例，它暴露了约 19 个权限门控工具（社区分析认为算上 LSP 集成、子代理生成等可能接近 40 个），主要类别包括：

工具类别	示例
文件读写	Read、Write、Edit
Shell 执行	Bash（沙箱化）
Git 操作	提交、分支、差异对比
Web 获取	网页内容抓取
MCP 工具调用	连接外部服务
子代理生成	分发并行子任务

工具描述的质量极其重要。 模型完全依靠工具描述来决定调用哪个工具。模糊的描述产生错误的调用，精确的描述产生准确的路由。

Bash：通用万能工具

LangChain 在其架构分析中指出，Bash + 代码执行是 Harness 中最重要的"通用工具"------与其为每种操作预设工具，不如给模型一个 Shell，让它自己写代码来解决问题。模型可以"即兴设计工具"，而不是被限制在预配置的工具集中。

③ 上下文管理器：决定模型"看到什么"

语言模型的上下文窗口是有限的。一个 Agent 可能需要处理数百个文件的代码库，或者跨越数小时的对话。上下文管理器决定模型在每一步看到什么。

这是 Harness 中最容易被忽视、却最影响性能的组件。

四大策略

策略	说明
截断	上下文满时丢弃较旧的消息
压缩 (Compaction)	将历史对话智能摘要，释放空间
检索 (RAG)	按需拉入相关内容
选择性注入	只包含模型当前真正需要的文件内容

Claude Code 的 Compaction 机制

当 token 使用量达到上下文窗口的约 98% 时，Claude Code 会自动压缩：总结早期历史以释放空间。关键元数据被保留，图片和 PDF 被剥离。

陷阱：压缩可能丢失重要细节。实践建议是把关键信息写入 CLAUDE.md------Harness 会在每一轮对话中重新读取这个文件。

工具输出的上下文处理

大工具输出是真实问题。Claude Code 对 MCP 工具输出设置了 25,000 token 的默认上限，超过 10,000 token 时发出警告。超大结果会持久化到磁盘而非保留在上下文中。

LangChain 的做法类似：保留工具输出的首尾 token，将完整输出卸载到文件系统，模型在需要时可以访问。

上下文腐化（Context Rot） 是 LangChain 提出的一个重要概念：随着上下文窗口逐渐填满，模型的推理和任务完成能力会下降。Harness 的核心职责之一，就是对抗上下文腐化。

④ 规划模块：Agent 如何拆解任务

模式	说明	适用场景
反应式 (ReAct)	观察→思考→行动→观察结果→重复，无预规划	中短周期任务
预规划式	先生成任务分解方案，再逐步执行	长周期、顺序敏感的任务
层级式	高层规划器拆解目标，子代理分别执行	复杂的多步骤任务

Claude Code 倾向于反应式逐步推理。而复杂系统如 AutoGPT 则尝试显式预规划，效果参差不齐。

LangChain 提出的 "推理三明治" 策略是一个有趣的折中------在规划和验证阶段投入高推理算力，在实现阶段使用中等推理算力，在有限时间预算内最大化质量。

⑤ 执行引擎：安全地"做事"

执行引擎运行工具调用，需要处理：

沙箱化：代码执行必须隔离，防止错误脚本破坏宿主系统
超时控制：挂起的工具需要在阈值后被终止
输出格式化：工具结果需要结构化为模型可以推理的格式
并行执行：当工具调用相互独立时，可以并行执行

权限门控：推理与权限分离

Claude Code 的权限模型是一个值得学习的设计------模型决定它想做什么，一个独立系统决定是否允许。被攻破的模型无法通过"有说服力"的论证来绕过安全检查，因为那是完全不同的代码路径。

每个工具调用流经一个规则管道，按 deny → ask → allow 的顺序评估------deny 永远优先。

在 2026 年 3 月引入的 Auto 模式 中，一个运行在独立模型实例上的后台分类器评估模糊情况------它只看用户请求和工具调用，故意不看模型的散文输出，防止模型"甜言蜜语"地说服自己通过安全检查。

⑥ 记忆系统：从"失忆"到"持续学习"

记忆系统分为四个层次：

层次	说明	持久性
上下文内记忆	当前上下文窗口中的一切	会话内，会被压缩
外部记忆	数据库、向量存储、文件系统	跨会话
情景记忆	过去行动和观察的日志，用于避免重复犯错	跨会话
语义记忆	Agent 积累的事实、摘要和知识	跨会话

AGENTS.md / CLAUDE.md：记忆的文件标准

Harness 支持记忆文件标准（如 AGENTS.md、CLAUDE.md），在 Agent 启动时注入上下文。Agent 可以编辑这些文件，Harness 在下次启动时加载更新后的版本。这本质上是一种持续学习机制------Agent 从一个会话中持久存储知识，并在未来会话中注入。

文件系统：最基础的 Harness 原语

LangChain 在其架构文章中特别强调：文件系统是 Harness 中最基础的原语，因为它解锁了太多能力：

Agent 获得读写数据、代码和文档的工作区
工作可以增量卸载，而非全部塞进上下文
文件系统是天然的协作表面------多个 Agent 和人类可以通过共享文件协调
Git 在此基础上增加版本控制，Agent 可以追踪工作、回滚错误、分支实验

⑦ 反馈与观察循环：Agent 如何"知道结果"

每次行动后，Agent 需要观察结果并纳入下一次决策。设计良好的反馈循环：

捕获 stdout、stderr、返回码和结构化输出
以模型可解读的形式呈现错误
追踪目标进展
检测 Agent 是否陷入循环或偏离轨道

循环检测中间件

LangChain 的 LoopDetectionMiddleware 通过工具调用钩子追踪每个文件的编辑次数。当同一文件被编辑超过 N 次时，注入"......考虑换一种方法"的上下文提示，帮助 Agent 跳出"死亡循环"。

自验证循环

LangChain 的 PreCompletionChecklistMiddleware 在 Agent 尝试退出时拦截它，强制进行一轮验证。这是他们基准测试提分最大的单项改进。

最常见的失败模式：Agent 写了一个方案，重读自己的代码，确认"看起来没问题"，然后停止。测试是关键------它同时验证正确性并为 Agent 提供自我改进的信号。

⑧ 安全与护栏层：防止 Agent 造成真实损害

自主 Agent 可以造成真实损害。安全层包括：

确认门控：高风险操作（删除文件、发送消息、API 调用）需要人类批准
行为过滤：基于策略完全阻止某些工具调用
范围限制：限制 Agent 只能在特定目录、项目或域内操作
速率限制：防止 Agent 在循环中发起数千次 API 调用
审计日志：记录每个行动及其结果，供事后审查

⑨ 编排层：多代理协作

当任务复杂度超出单个 Agent 的能力时，需要多个 Agent 协调工作：

模式	说明
主管 + 工人	一个编排 Agent 拆解任务并委派给专业工人 Agent
对等网络	Agent 之间直接通信，传递结果和请求
流水线	线性序列，每个 Agent 的输出成为下一个的输入
并行执行	多个 Agent 同时处理独立子任务，结果在最后聚合

Claude Code 的子代理生成、LangGraph 的图编排、CrewAI 的角色编排，都是这个层的不同实现。

四、MCP：Harness 连接外部世界的桥梁

MCP（Model Context Protocol） 是 Anthropic 推出的开放标准协议，用于标准化 AI 工具与外部服务的连接。它正在成为 Harness 生态中最重要的基础设施之一。

MCP 的工作原理

arduino 复制代码

Agent Harness
    │
    ├── MCP Server A (chrome-devtools) ── 操控浏览器
    ├── MCP Server B (ApiFox) ── 调用 API 文档
    ├── MCP Server C (Figma) ── 获取设计稿
    └── MCP Server D (自定义) ── 对接内部系统

Claude Code 支持三种传输模式：HTTP （远程服务器推荐）、stdio （本地进程）和 SSE。

工具发现机制

一个精巧的设计：连接 MCP 服务器后，Harness 不会一次性加载所有工具 Schema 到上下文。它只在会话开始时加载工具名称，然后通过搜索机制在任务需要时动态发现相关工具。只有实际使用的工具才进入上下文。

这有效对抗了上下文腐化------推荐上限为 5-6 个活跃 MCP 服务器，超出后延迟会明显增加。

MCP 的安全考量

Anthropic 官方文档明确指出：第三方 MCP 服务器可能成为提示注入的攻击向量。Harness 的权限系统提供了防线，但信任边界仍在用户侧。

五、Harness 工程三大支柱

OpenAI 在其 Harness Engineering 博客中，将 Harness 工程归纳为三大支柱：

支柱一：上下文工程（Context Engineering）

确保 Agent 在正确的时间拥有正确的信息。

静态上下文：

仓库本地文档（架构规范、API 契约、风格指南）
AGENTS.md / CLAUDE.md 文件编码项目特定规则
由 Linter 验证的交叉引用设计文档

动态上下文：

可观测性数据（日志、指标、追踪）对 Agent 可访问
Agent 启动时注入目录结构映射
CI/CD 管道状态和测试结果

关键法则：从 Agent 的视角看，上下文中不存在的信息就等于不存在。 存在于 Google Docs、Slack 或人们脑子里的知识，对系统是隐形的。仓库必须是唯一真相来源。

支柱二：架构约束（Architectural Constraints）

不是告诉 Agent"写好代码"，而是机械地强制执行好代码应该是什么样子。

复制代码

依赖分层：Types → Config → Repo → Service → Runtime → UI
每一层只能导入左侧的层。这不是建议------由结构测试和 CI 验证强制执行。

约束执行工具：

确定性 Linter：自定义规则自动标记违规
LLM 审计员：让 Agent 审查另一个 Agent 的代码是否符合架构
结构测试：类似 ArchUnit，但用于 AI 生成的代码
Pre-commit Hook：提交前自动检查

悖论：约束解空间反而让 Agent 更高效。 当 Agent 可以生成任何东西时，它浪费 token 探索死胡同。当 Harness 划定清晰边界时，Agent 更快收敛到正确方案。

支柱三：熵管理（Entropy Management / "垃圾回收"）

AI 生成的代码库会随时间积累熵------文档偏离现实、命名规范分化、死代码积累。

解决方案是定期清理 Agent：

文档一致性 Agent：验证文档与当前代码匹配
约束违规扫描器：发现逃过早期检查的代码
模式执行 Agent：识别并修复偏离既定模式的代码
依赖审计 Agent：追踪并解决循环或不必要的依赖

这些 Agent 按计划运行------每天、每周或由特定事件触发------保持代码库对人类和未来 AI Agent 都健康。

六、主流工具 Harness 对比

特性	Claude Code	OpenAI Codex	Cursor	DeepSeek Harness
定位	终端自主 Agent	服务端集成 Agent	IDE 增强型 Agent	开源插件化 Agent
模型	Claude（Sonnet/Opus）	GPT-4o / Codex 系列	多模型（GPT-4o/Claude/Gemini）	多模型（V4 Pro/Flash、Kimi、Miniax）
推理模式	反应式 ReAct	多工具单轮调用	反应式 + IDE 反馈	9 子代理编排
工具数量	~19-40 个	内置（代码解释器、搜索、文件）	代码理解导向（索引、符号、Diff）	万物皆插件（Cordis）
权限模型	三层门控（Auto/Ask/Deny）	服务端管理	Diff 预览隐式审批	插件级沙箱
上下文管理	选择性读取 + Compaction	会话线程抽象	代码索引 + 按需检索	File Picker 精准拉取 + 子代理独立上下文
MCP 支持	原生支持三种传输	通过 API 扩展	有限	插件扩展
开源	闭源	闭源	闭源	MIT 完全开源
哲学	透明 + 可控	紧密集成 + 快速上手	UX 优先 + 人机协作	万物皆插件 + 专业化编排

同一个模型在不同 Harness 中表现截然不同。Opus 4.6 在 Claude Code 和其他 Harness 中的 Terminal Bench 得分差异明显。Harness 设计，而不是模型选择，才是性能的关键变量。

七、DeepSeek Harness：开源世界的重磅挑战者

2026 年 8 月 13 日，DeepSeek 正式发布了 DeepSeek Harness (dsh) 开发者预览版 (v0.1)，以 MIT 许可证开源。这是目前开源社区中最激进的 Agent Harness 尝试，直接对标 Claude Code。

DeepSeek 官方的定位非常清晰：

模型是 Agent 的灵魂，Harness 是让 Agent 感知环境、调用工具、持续推进的身体。

"万物皆插件"：Cordis 架构

DeepSeek Harness 最核心的设计决策是一切皆插件 。它构建在 Cordis 元框架之上，Cordis 内核负责插件的挂载、卸载和依赖管理。Agent 的所有能力都存在于插件中：

java 复制代码

┌──────────────────────────────────────────────────────────┐
│                DeepSeek Harness (Cordis)                  │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  插件层（一切皆可替换、扩展、组合）                         │
│                                                          │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────────┐   │
│  │ Models  │ │  Tools  │ │  Skills │ │   Sessions   │   │
│  │ 模型后端 │ │  工具集  │ │ 技能包  │ │  会话状态    │   │
│  └─────────┘ └─────────┘ └─────────┘ └──────────────┘   │
│                                                          │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────────┐   │
│  │Sandboxes│ │ Storage │ │  Loops  │ │     UI       │   │
│  │  沙箱   │ │  存储   │ │ 控制流  │ │    界面      │   │
│  └─────────┘ └─────────┘ └─────────┘ └──────────────┘   │
│                                                          │
│  ──── Cordis 内核：挂载 / 卸载 / 依赖管理 / 事件通信 ──── │
│                                                          │
└──────────────────────────────────────────────────────────┘

实际意义 ：想要不同的沙箱、自定义工具、或不同的模型后端？挂载一个插件就行，不需要 fork 源码。这与 Claude Code 等"循环、工具和 UI 焊接在一起"的一体化工具形成了本质区别。

四种运行模式

模式	说明	适用场景
Standard	完整编程 Agent：文件编辑、Shell、搜索、技能、规划、子代理	日常开发
Code	通过 Code Mode SDK 将多步操作合并为一个 TypeScript 程序	复杂编排
Minimal	极简双工具：持久化 Bash + str_replace_editor	模型基准测试
Creator	检查运行时、测试插件、构建自定义预设	Harness 开发者

注意：DeepSeek 发布的 Code Agent 基准分数是在 Minimal 模式下跑的。这意味着生产环境的实际表现高度依赖你选择的 Harness 配置。

九大专业子代理：核心差异化

这是 DeepSeek Harness 在架构上最独特的设计------它不是让一个大模型做所有事，而是拆分成 9 个专业子代理，每个子代理有独立的上下文窗口和最适合的模型：

arduino 复制代码

用户输入需求
    │
    ▼
① Planner ──── 澄清问题，拆解步骤（/in 面试模式）
    │
    ▼
② File Picker ──── 扫描代码库，只拉取相关文件（Gemini 3.1 Flash Lite）
    │
    ▼
③ Researcher ──── 联网搜索外部文档和 API（Gemini 3.1 Flash Lite）
    │
    ▼
④ Editor ──── 精确外科手术式 diff 编辑（V4 Pro / 其他）
    │
    ▼
⑤ Terminal Runner ──── 执行命令、运行测试、自动修复
    │
    ▼
⑥ Browser-use ──── 在真实浏览器中验证构建结果
    │
    ▼
⑦ Code Reviewer ──── 审查 diff，标记风险
    │
    ▼
⑧ Deep Thinker ──── 最难推理问题的"逃生舱"（GPT 5.4）
    │
    ▼
⑨ Follow-up Suggester ──── 提供 3 个后续动作建议

每个子代理的设计逻辑：

子代理	核心职责	为什么需要独立
File Picker	只拉取与任务相关的文件	减少上下文稀释，比"一股脑加载所有文件"更精准
Code Reviewer	每次改动后自动审查 diff	写代码和审查代码用独立上下文窗口，捕获率更高
Browser-use	打开真实 Chromium 实例测试	捕获"diff 看着没问题但渲染出来不对"的问题
Planner	任务前 5-7 个澄清问题	90 秒的前期访谈可以省去一小时的返工
Editor	精确 diff，只改需要改的行	避免整文件重写导致的格式漂移和隐藏 Bug
Researcher	获取代码库外的文档和 API	让 Harness 像一个"联网的开发者"而非沙箱模型
Terminal Runner	执行命令并自动反馈修复	实现"构建→测试→修复→重复"的自愈循环
Deep Thinker	调用 GPT 5.4 处理极端推理	90% 的任务用不到，但需要时天花板接近 Opus 4.7
Follow-up Suggester	每次响应后建议 3 个后续动作	把单次工具变成连续工作流

核心洞察 ：一个大模型试图在一个 Prompt 中完成所有 9 项工作，犯的错误比 9 个专业子代理各做一件事要多。专业化减少了上下文稀释------这是 DeepSeek Harness 在多文件任务上优于 Claude Code 的实际原因。

四种可选模型

模型	优势	适用场景
DeepSeek V4 Pro	最强推理，多文件逻辑	复杂功能开发
Kimi K2.6	超大上下文窗口	大型代码库分析
Miniax M2.7	更好的前端和创意输出	UI 和设计工作
DeepSeek V4 Flash	最快最便宜	快速编辑和对话

支持会话中途切换模型，这比 Claude Code 和 Cursor 的默认方案提供了更多灵活性。

可追溯性：每次运行都有完整记录

Harness 的第二个设计原则是可观测性 。模型看到的一切都被记录在仅追加的会话日志中------系统提示词、推理过程、工具调用及结果、子代理调度、每次上下文注入。

通过 Trajectory 视图 可以按来源检查记录，日志是单一事件流，支持恢复、分叉、搜索和回放任何运行历史。

DeepSeek Harness vs Claude Code

维度	DeepSeek Harness	Claude Code
开源	MIT 完全开源	闭源
架构哲学	插件化 (Cordis)，万物可替换	一体化，紧密集成
模型支持	多模型可选（V4 Pro/Flash、Kimi、Miniax）	仅 Claude 系列
子代理	9 个专业子代理，各有独立上下文	有限的子代理生成
许可证	MIT（可商用）	专有
成熟度	v0.1 预览版，快速迭代	生产就绪
生态	插件生态建设中	相对成熟
成本	开源 + 低价模型	按 token 计费，成本较高

战略意义

DeepSeek Harness 的 MIT 开源许可证是一个战略级选择。对比当前格局：

OpenAI：已远离开源路线
Anthropic：从未拥抱开源
Meta (Llama)：自定义限制性许可证

MIT 许可证的 Harness + MIT 许可证的开源模型权重 = 一个团队可以端到端运行完整的 Agent 栈，无需任何专有厂商。这为注重自主可控和数据主权的团队提供了真正的选择。

当前局限

v0.1 预览版，DeepSeek 明确警告会有不兼容的破坏性变更
核心插件和 API 仍在快速演化，不建议用于生产锁定
插件生态尚在早期建设中
多代理系统有更多运动部件，意味着更多可能出错的环节

总结：DeepSeek Harness 是目前开源社区中最值得关注的 Agent Harness 项目。"万物皆插件"的 Cordis 架构 + 9 子代理专业化编排 + MIT 许可证，让它成为 Claude Code 的真正开源竞争对手。但作为 v0.1，它更适合实验和插件开发，而非生产系统。

八、实战：搭建你自己的 Harness

Level 1：个人开发者（1-2 小时）

创建 CLAUDE.md / .cursorrules 编码项目约定
配置 Pre-commit Hook 做 Lint 和格式化
编写 Agent 可运行的测试套件
保持清晰的目录结构和一致的命名

效果：防止最常见的 Agent 错误

Level 2：小团队（1-2 天）

在 Level 1 基础上增加：

团队统一的 AGENTS.md
CI 强制执行的架构约束
共享 Prompt 模板
文档即代码（由 Linter 验证）
针对 Agent 生成 PR 的专属 Code Review 清单

效果：跨团队的 Agent 行为一致性

Level 3：工程组织（1-2 周）

在 Level 2 基础上增加：

自定义中间件层（循环检测、推理优化）
可观测性集成（Agent 读取日志和指标）
熵管理 Agent 定期运行
Harness 版本管理和 A/B 测试
Agent 性能监控仪表板
Agent 卡住时的升级策略

效果：Agent 作为自主贡献者运行

中间件架构示例

LangChain 将其 Harness 结构化为可组合的中间件层：

复制代码

Agent 请求
  → LocalContextMiddleware（映射代码库结构）
  → LoopDetectionMiddleware（防止重复）
  → ReasoningSandwichMiddleware（优化推理算力分配）
  → PreCompletionChecklistMiddleware（强制验证）
Agent 响应

每个中间件层添加特定能力，不修改核心 Agent 逻辑。模块化使 Harness 可测试、可演化。

九、常见陷阱

1. 过度工程化控制流

"如果你过度工程化控制流，下一次模型更新会打破你的系统。"

模型在快速进步。2024 年需要复杂管道的能力，现在可能一个上下文窗口就能搞定。构建可拆卸的 Harness------当模型足够聪明时，你应该能移除"聪明"的逻辑。

2. 把 Harness 当成静态的

Harness 需要随模型演化。当新模型提升了推理能力，你的推理优化中间件可能反而成为拖累。每次主要模型更新时，审查并更新 Harness 组件。

3. 忽视文档层

最有影响力的 Harness 改进往往是最简单的：更好的文档。 如果 AGENTS.md 含糊，Agent 输出就含糊。投资于精确的、机器可读的文档，作为 Agent 的基本真相。

4. 没有反馈循环

没有反馈的 Harness 是笼子，不是向导。构建：

任务完成前的自验证步骤
将测试执行作为 Agent 工作流的一部分
按任务类型统计 Agent 成功率

5. 只有人类才知道的文档

如果架构决策存在于人们脑子里或 Agent 无法访问的 Confluence 页面中，Harness 有漏洞。Agent 需要的一切必须在仓库里。

十、开发者角色的演变

以前	现在
写代码	设计让 AI 写代码的环境
调试代码	调试 Agent 行为
Review 代码	Review Agent 输出 + Harness 有效性
写测试	设计测试策略
维护文档	构建文档作为机器可读的基础设施

Harness 工程所需的核心技能：

系统思维 ------ 理解约束、反馈循环和文档如何交互
架构设计 ------ 定义可执行且有生产力的边界
规格撰写 ------ 精确到 Agent 能执行的意图表达
可观测性 ------ 构建揭示 Agent 行为模式的监控
迭代速度 ------ 快速测试和精炼 Harness 配置

十一、Harness 的未来走向

模型训练与 Harness 设计的耦合

今天的 Claude Code 和 Codex 等产品，是在模型和 Harness 共同参与下进行后训练的。模型在 Harness 设计者认为它应该擅长的领域（文件系统操作、Bash 执行、规划、并行子任务）得到强化。

这创造了一个反馈循环：发现有用的原语 → 加入 Harness → 用于训练下一代模型。随着循环重复，模型在其训练 Harness 内变得越来越强。

什么会被模型吸收？

随着模型能力提升，今天 Harness 中的某些部分会被吸收进模型：

原生规划能力增强 → 减少规划模块的上下文注入
原生自验证能力提升 → 简化验证中间件
更长上下文的一致性 → 降低 Compaction 的依赖

但正如 Prompt Engineering 今天仍然重要，Harness Engineering 很可能持续成为构建优秀 Agent 的关键。即使模型变得更聪明，精心配置的环境、正确的工具、持久状态和验证循环仍然让任何模型更高效。

开放的研究方向

编排数百个 Agent 在共享代码库上并行工作
Agent 分析自己的 Trace 以识别和修复 Harness 级失败模式
Harness 为给定任务动态组装正确的工具和上下文，而非预配置