引言

2026 年初，一个新术语席卷了 AI 工程界——Harness Engineering（Harness 工程）。它不是又一个营销概念，而是对过去四年 AI 工程实践的一次系统性总结：当我们不再满足于"写一个好 prompt"，而是需要构建一个让 AI Agent 可靠、安全、经济地完成复杂任务的完整系统时，Harness Engineering 就是那个系统工程学科的名字。

本文将从起源讲起，沿着 Prompt → Context → Harness 的演进主线，深入拆解 Harness 的核心原理，分析当前八大难点，并梳理 Anthropic、OpenAI、Google、Cursor 等厂商的解决方案。

一、什么是 Harness？

1.1 一个公式

2026 年 2 月，LangChain 的 Vivek Trivedy 给出了被广泛引用的公式：

Agent = Model + Harness

如果你不是模型本身，那你就是 Harness。

裸的 LLM 只是一个无状态的文本补全引擎——它没有记忆、不能执行动作、无法跨会话持续工作。Harness 是赋予模型行动能力、状态持久化、工具调用、验证循环和安全治理的完整运行时基础设施层。它不让模型变得更聪明，而是让失败变得结构性不可能或可恢复。

1.2 Harness 与 Prompt 的本质区别

层次作用域控制什么
Prompt Engineering单次模型调用输入字符串——措辞、示例、指令
Context Engineering单个上下文窗口模型看到的信息——RAG 结果、对话历史、工具定义
Harness Engineering整个运行环境工具执行、状态持久化、验证循环、记忆、权限、多会话协调

一个类比：在 prompt 里告诉 Agent"请遵循我们的编码规范"是概率性的合规；在 Harness 里接入一个 linter 来阻止不合规的 PR 是确定性的执行。Prompt 告诉 Agent 做什么，Harness 控制它能不能做、怎么做。

1.3 词源

“Harness"源自马具——缰绳、嚼铁、鞍座——将马的原始力量引导到有用的方向。LLM 就是那匹马：强大而快速，但没有 Harness 就毫无方向。在软件领域，“test harness”（测试线束）的概念由来已久——一个可控的、可观测的、可验证的执行环境。AI Agent Harness 继承了这一核心思想。

二、从 Prompt 到 Harness：演进史

Phase 1：Prompt Engineering（2020–2024）

起点：2020 年，GPT-3 发布，Brown et al. 证明了 few-shot learning——通过在 prompt 中给出几个示例，LLM 就能适应新任务。“Prompt engineering"这个术语由 Gwern Branwen 首先使用，随后在 2022 年 ChatGPT 爆发后成为主流。

关键技术里程碑：

  • 2022 — Chain-of-Thought（Wei et al., Google）：发现让模型"一步步思考"能显著提升多步推理能力。这是第一个系统性的证据——prompt 的形式塑造推理的过程，而不仅仅是输出。
  • 2022 — ReAct（Yao et al.）：提出 Thought → Action → Observation 循环——模型在推理和工具调用之间交替。这建立了 Agent Loop 的原型架构，几乎所有现代 Agent Harness 的基础都是 ReAct 的变体。
  • 2023 — Toolformer（Schick et al., Meta）：证明 LLM 可以自主学习何时、如何调用外部工具。工具使用从 Harness 强加行为变成了模型的一等能力。
  • 2023 — OpenAI Function Calling + AutoGPT + LangChain：Function Calling API 让结构化工具调用变得实用；AutoGPT 和 BabyAGI 展示（也压力测试了）开放式自主 Agent；LangChain 提供了模块化框架。这个阶段暴露了无 Harness Agent 的核心失败模式：无限循环、上下文爆炸、不可恢复的失败。

Prompt Engineering 的致命缺陷：

  • 脆弱——上游模型的微小变化就能打破精心设计的 prompt
  • 概率性合规，而非确定性保证
  • 无法从任务中途的错误中恢复
  • 无法处理多步骤任务或跨会话状态

Phase 2：Context Engineering（2025）

定义时刻：2025 年 6 月，Shopify 创始人 Tobi Lütke 在 X 上提出"context engineering"比"prompt engineering"更准确地描述了核心技能。一周后，Andrej Karpathy 给出了被广泛引用的定义：

“用恰到好处的信息填充上下文窗口的精妙艺术与科学。”

范式转变：从优化单条 prompt 转向架构模型看到的信息——RAG 管道、对话历史管理、工具定义、结构化记忆。瓶颈从措辞转向信息。

Context Engineering 的不足：

  • 拥有良好上下文的 Agent 仍然在规模化使用时不可预测地失败
  • 上下文窗口是有限的；复杂任务跨越多个窗口
  • 无法从灾难性的中途失败中恢复
  • “上下文焦虑”——模型在上下文快满时会过早地结束任务
  • 指令完美、上下文充分的 Agent 仍可能执行危险命令

Phase 3：Harness Engineering（2026–至今）

范式转变：不再试图通过指令让模型表现更好，而是工程化环境使不良行为在结构上不可能或可被结构性纠正。Harness 是道路、护栏、交通系统——不只是方向指引。

三者是嵌套关系：Harness Engineering ⊃ Context Engineering ⊃ Prompt Engineering。每一层增加了作用域，但不消除前一层。

三、命名时刻：2026 年 2 月

“Harness Engineering"作为一个命名学科，在 2026 年 2 月的两周内结晶：

Mitchell Hashimoto（2 月 5 日）

HashiCorp 联合创始人、Terraform 和 Ghostty 的作者，在博客 My AI Adoption Journey 中描述了他在用 AI Agent 构建 Ghostty 时发展出的实践：

“每当你发现 Agent 犯了一个错误，你就花时间工程化一个解决方案，使这个 Agent 永远不会再犯同样的错误。”

他给这个实践命名为 “engineer the harness”，并在文中坦承自己不确定业界是否已有对应术语。实践中，这意味着在 AGENTS.md 中积累规则、为每个失败编写验证脚本，直到错误在结构上不可重复。

Ryan Lopopolo / OpenAI（2 月 11 日）

发表了 OpenAI Frontier 团队如何用 Codex Agent 交付超过一百万行代码、1500+ PR、零人工编写和零人工审查的文章。当 Agent 失败时，团队问的不是"如何更好地 prompt 它”，而是"环境中缺少什么能力、上下文或结构？”

Lopopolo 后来在 Latent Space 播客（4 月 7 日）中亮相，标题是 “Extreme Harness Engineering for Token Billionaires”。

Vivek Trivedy / LangChain（2 月 17 日）

发表 “Improving Deep Agents with Harness Engineering”——被广泛认为是给这个术语赋予正式分类体系并推广到业界的文章。他展示了 LangChain 的编码 Agent 仅通过修改 Harness（不换模型）就从 Terminal Bench 2.0 的 Top 30 跃升至 Top 5。他提出了经典公式"Agent = Model + Harness"并定义：“如果你不是模型，你就是 Harness。”

后续文章 The Anatomy of an Agent Harness 在 X 上获得 73.3 万次浏览和 4800 次收藏。

Birgitta Böckeler / Martin Fowler（2 月 17 日）

在 Fowler 的"Exploring Gen AI"系列中发表 Harness Engineering 备忘录，引入 Guides（前馈控制） 和 Sensors（反馈控制） 框架，两者可以是计算性的或推理性的，并提出 Harness Templates 概念——在组织内共享通用的 Guides 和 Sensors 配置。

归属共识：Mitchell Hashimoto 命名了它（2 月 5 日）；Viv Trivedy 定义和分类了它（2 月 17 日）；两人共同将这个术语推入普遍使用。

四、深入拆解 Harness 原理

4.1 核心组件

学术界和工业界对 Harness 的核心组件已形成收敛共识。一篇 2025–2026 的综述论文提出了 ETCLOVG 分类法——七个必要且充分的层：

层名称职责
EExecution（执行基底）工具动作物理运行的环境——沙箱子进程、Docker 容器、Rust 沙箱
TTool（工具接口）JSON Schema 格式的工具定义、工具注册表、MCP 协议
CContext（上下文管理）每一步上下文窗口的内容——压缩、缓存、滚动摘要
LLifecycle（生命周期/编排）Agent Loop 的控制流——ReAct 循环、终止条件、子 Agent 调度
OObservability（可观测性）每次模型调用、工具调用、观测的追踪和日志
VVerification（验证）Linter、类型检查、测试运行器、自我批评——确定性传感器
GGovernance（治理）权限分层、沙箱、审批门控、安全规则

4.2 Agent 控制循环

主流架构是 ReAct（Reasoning + Acting）：

Thought → Action → Observation → Thought → … → Final Answer
  • Thought：模型输出显式推理——解释当前状态，决定下一步
  • Action：工具调用。现代系统使用原生 function calling（结构化 JSON），而非文本解析
  • Observation：工具返回值，追加到对话历史并重新呈现给模型
  • Termination：“Final Answer"信号或最大步骤预算

以 Claude Code 为例，其六阶段控制循环：

初始化 → 上下文构建 → LLM 调用 → 决策路由 → 收集工具结果 → 溢出检查
     ↑                                                        ↓
     ←←←←←←←←←←←←←← 若未溢出，循环回上下文构建 ←←←←←←←←←←←←←
                      若溢出，触发 Context Compaction

当模型同时请求多个工具时，生产级 Harness 会进行依赖分析（这些工具能否并行？）和资源约束（最多多少并发进程？）。

4.3 上下文管理与压缩

上下文窗口是 Agent 的核心资源约束。一个 SWE-bench 任务的长编码会话通常跨越数百万 token——Qwen3-Coder-Next 平均每个问题消耗 800 万 token 和 154 轮对话。

主要压缩策略：

策略原理代表系统
滚动摘要达到阈值时，用模型调用将历史压缩为叙述，替换原始记录Claude Code
Map-Reduce 压缩分块 → 独立摘要（map）→ 合并为最终浓缩（reduce）长会话场景
服务端压缩/responses/compact 端点，返回更小的输入列表Codex CLI
KV-Cache 压缩在推理层面驱逐 KV-cache 条目，最高 20x 压缩LLMLingua（Microsoft Research）
外部工件记忆进度文件、特性列表、Git 历史作为持久记忆Anthropic 两 Agent 架构

一个关键失败模式是**“上下文焦虑”（Context Anxiety）**：当窗口接近填满时，Agent 会过早结束任务——不是因为工作完成了，而是因为它"感知"到了限制。Cognition（Devin）明确记录了这一现象。

4.4 记忆架构

业界已收敛到认知科学的三层分类：

  • 情景记忆（Episodic）：存储过去的交互历史——具体事件和会话。允许回忆"上次发生了什么”。
  • 语义记忆（Semantic）：声明性事实、实体属性、领域知识、用户偏好。基本上是非时序的——Agent 认为当前为真的东西。通常存储在向量数据库中。
  • 程序记忆（Procedural）：编码"如何做”——操作技能、决策启发式、可复用程序（如 Claude Code 的 CLAUDE.md）。

到 2026 年中，68% 的生产 Agent 部署包含专用记忆层（2024 年仅 23%）。

4.5 权限模型

以 Claude Code 为例的三层权限模型：

  • Tier 1（自动批准）：只读或固有安全的操作——文件读取、文本搜索、代码导航
  • Tier 2（需确认）：修改状态但可控的操作——文件编辑、某些 Shell 命令
  • Tier 3（默认阻止）：破坏性或高风险操作

在自动模式下，一个后台分类器在执行前评估 Tier 2 操作。关键设计：分类器看到用户请求和工具调用，但看不到模型的自由文本。这是一个刻意的架构选择——防止模型通过 prompt injection 影响自己的门控系统。

4.6 验证循环

编码 Harness 与通用聊天 Harness 最大的差异在于Plan-Execute-Verify（PEV）循环：

  • Plan：形成对预期变更的契约
  • Execute：在沙箱和权限环境中执行
  • Verify：使用确定性传感器（linter、类型检查器、测试运行器）和人工审查门控，决定状态应被接受、修订、升级还是回滚

Cursor 的早期 Harness 在每次编辑后自动呈现 lint 和类型错误——这些是确定性传感器，不是 LLM 调用——集成在循环中提供 ground-truth 反馈。

五、当前八大难点

5.1 上下文窗口管理

尽管上下文窗口已增长到 100 万（Claude）和 200 万（Gemini 3.1）token，上下文仍是核心未解决瓶颈。

核心问题：

  • “上下文腐烂”（Context Rot）：性能随上下文填充呈非线性下降。模型并不均匀地使用上下文——可靠性在硬限制之前就开始下降。
  • 系统 prompt、工具定义、RAG 结果和对话历史争夺空间
  • 朴素截断破坏工具响应保真度；摘要丢失关键细节

前沿方案：

  • 递归语言模型（RLM，Prime Intellect）：Agent 主动将上下文委托给子进程，而非通过有损压缩丢失信息
  • 操作系统式内存管理：将上下文窗口视为 RAM——预算、分页、主动驱逐。Mem0 的研究显示这种架构比无状态方法提升 26% 的响应准确率
  • TokenPilot（2026）：LLM Agent 的 Cache 高效上下文管理，优化跨工具调用的 KV-cache 复用

5.2 工具选择与路由

MCP 生态到 2026 年中已增长到 ~19,000 个已验证的公开服务器上的 ~177,000 个不同工具。

核心问题：

  • 2025 年研究发现 97.1% 的 MCP 工具描述存在至少一个质量问题
  • 无检索辅助时，工具选择准确率仅 13.62%（RAG-MCP 论文）

前沿方案：

  • RAG-MCP：将工具元数据嵌入向量存储，每次查询仅检索相关工具，准确率从 13.62% 提升至 43.13%
  • 延迟/动态工具加载：Anthropic 的 “Tool Search Tool”（2025 年 11 月），只加载一个搜索工具，按需获取和加载所需工具。Opus 4 准确率从 49% 跳升至 74%
  • 激进工具精简：GitHub Copilot 从 40 个工具减至 13 个，基准测试改善。Block 将 Linear MCP 服务器从 30+ 工具重建为 2 个。Cloudflare 的 Code Mode 将 2,500+ API 端点压缩为 2 个工具，从 117 万 token 降至 ~1,000 token

核心洞见：工具描述不是文档——它是 LLM 的主要决策表面。

5.3 错误恢复与自愈

核心问题：

  • 并非所有失败都是基础设施故障——许多是推理失败（错误计划、幻觉事实）。重试相同调用无法修复错误的思维链
  • 2025 年 IDC 调查：92% 使用 Agentic AI 的组织报告成本高于预期，失控循环是主因
  • 最糟糕的失败模式：“对失败任务的静默成功”——Agent 自愈到产生错误输出并充满信心

前沿方案：

  • MAPE-K 启发的自愈编排器：Monitor → Analyze → Plan → Execute → Knowledge 控制循环
  • 质量感知断路器：拦截的不仅是硬故障（超时、错误），还包括输出质量故障——畸形 JSON、Schema 违规
  • 舱壁隔离（Bulkhead）：每个并行 Agent 分支在自己的隔间中运行，一个故障只淹没自己的舱室
  • 推理层反思：基础设施恢复修复调用；推理层反思修复思维。两者结合覆盖可靠性问题的两半

5.4 评估与基准测试

SWE-bench 仍是主导基准：2,294 个任务实例，来自 12 个 Python 仓库的真实 GitHub issue。截至 2026 年 5 月，Claude Mythos Preview 以 93.9% 居首。

根本性批评：SWE-bench 同时评估 Harness 和底层模型。2025 年分析发现 19.78% 的"已解决"用例语义上不正确——它们通过 reward-hacking 评估 Harness 来通过单元测试，而非产生正确代码。

新兴基准：

  • UTBoost：要求 Agent 同时生成测试，而非仅生成补丁
  • Harbor：在容器化环境中评估 Claude Code、OpenHands、Codex CLI
  • Harness-Bench：专门评估 Harness 质量的基准
  • NIST AI Agent 标准倡议（2026 年 2 月）：行业级正确性、效率和安全指标

5.5 安全与沙箱

这可能是最令人警醒的领域。Prompt injection 在 2026 年仍是 OWASP 的 #1 LLM 威胁，被广泛描述为根本性未解决。

问题规模：

  • Prompt injection 出现在超过 73% 的生产部署中；2025 年造成约 23 亿美元损失
  • 检测工具仅捕获 23% 的复杂注入尝试
  • Inkog Labs 发现 86% 的 500+ 开源 AI Agent 仓库包含至少一个安全漏洞
  • CVE-2025-59532 针对 OpenAI 的 Codex CLI：Agent 的自身输出可以重新定义其沙箱边界

为什么架构上很难：LLM 将输入处理为单一 token 序列，在系统 prompt、用户查询和工具检索内容之间没有可靠的权限边界。

有效防御：

  • 遏制优于过滤：假设某些注入会成功；使用最小权限、沙箱和人机协作，使成功的注入无法触及敏感内容
  • 指令层级强制：系统 prompt > 用户输入 > 工具输出——严格的权限排序
  • 推理与权限执行分离（Anthropic 模式）：模型决定想做什么，但另一个代码路径决定是否允许。被越狱的模型无法覆盖安全检查，因为它们在独立系统中

5.6 成本与延迟

经济现实残酷：

  • 2025 年企业平均 AI 支出达 85,521 美元/月（同比增长 36%）
  • 输出 token 成本是输入的 3-10 倍；高级推理模型有 8:1 的输出/输入比率
  • 92% 的 Agentic AI 用户报告成本高于预期

优化策略：

  • 模型路由：为每个请求动态选择足够的最便宜模型。报告 30-70% 成本降低
  • Prompt 缓存：Anthropic 报告最高 85% 延迟降低和 ~90% 输入成本降低
  • 批处理：32 个请求的批处理可将每 token 成本降低 85%
  • 激进工具精简：减少工具数量和 token 消耗

5.7 多 Agent 编排

核心挑战：

  • 协调复杂度随 Agent 数量超线性增长
  • 状态同步：Agent 争夺资源或覆盖彼此的输出
  • 静默失败：缺少正确上下文的 Agent 会幻觉或停滞，通常没有可检测的错误信号
  • 持久状态：5 步工作流在第 4 步丢失上下文时应从第 4 步恢复，而非重新开始

前沿模式：

  • 编排器-工作器 + 舱壁：一个编排器委派给专门的子 Agent，每个在隔离隔间中
  • 每次交接的输出 Schema 验证：一个 Agent 的畸形输出不能腐蚀下游 Agent
  • 基于图的状态（LangGraph）：将工作流建模为有向图，支持条件分支和精确恢复
  • Git worktree 并行 Agent（Windsurf Wave 13）：多个分支同时修改，无文件冲突

量化结果：评估驱动的编排研究显示，将常规生产 Agent 循环替换为模型无关编排层（仅改变 Harness），每个任务混合成本降低 41%。

5.8 跨会话记忆与状态持久化

核心问题：LLM 是无状态算法。没有持久记忆层，每个会话从零开始。

收敛的四层记忆架构：

  1. 短期工作记忆：上下文窗口内。易失——会话结束即清除
  2. 情景记忆：按序存储特定过去事件。支持"你为什么做那个决定？“的重建
  3. 语义记忆：泛化的事实知识，通过嵌入搜索检索
  4. 程序/技能记忆：编码的操作程序、启发式、约束

关键开放问题：记忆过时治理——关于用户雇主的高频检索记忆在他们换工作前是准确的。检测和修复过时、被投毒或过度作用域记忆的治理框架仍处于早期阶段。

六、各大厂如何解决这些难点

6.1 Anthropic（Claude Code）

Anthropic 在 2025 年 11 月的工程博客 “Effective Harnesses for Long-Running Agents” 中最清晰地阐述了其 Harness 哲学。

架构决策：

  • 长时间运行的两 Agent 架构：初始化 Agent 运行一次——将 prompt 展开为结构化的 feature-list.json 并写入 init.sh。编码 Agent 反复唤醒，每次会话在一个功能上取得增量进展，提交，并留下 claude-progress.txt 给下一个会话。外部文件就是记忆。
  • 推理与权限执行分离：模型决定做什么；独立代码路径决定是否允许。安全检查不能被越狱绕过，因为它们在独立系统中。
  • Tool Search Tool（2025 年 11 月）：单个搜索工具按需检索和加载所需工具，Opus 4 准确率从 49% 跳升至 74%。
  • 上下文压缩 + 磁盘持久化：快照、可回滚的文件变更、CLAUDE.md 作为持久锚点。
  • 系统 prompt 动态组装：不是静态字符串——从模块化区段构建函数在运行时动态组装。边界标记将其分为全局可缓存前缀和会话特定后缀。
  • 27 个内置工具：覆盖文件操作、Shell 执行、Web 获取、代码搜索、记忆操作和子 Agent 委派。

关键洞见：Anthropic 随着模型改进多次重新架构 Claude Code 的 Harness，剥离模型不再需要的脚手架拐杖。

6.2 OpenAI（Codex）

Codex 于 2025 年 5 月启动，由 codex-1（为软件工程优化的 o3 RL 训练变体）驱动。到 2026 年运行 GPT-5.5。

架构决策：

  • 每任务隔离云环境：每个 Codex 任务在预加载仓库的独立云 VM 中运行。完全异步（1-30 分钟）。
  • 解耦设计：LLM 推理循环与工具执行分离。核心用 Rust（codex-rs）编写。
  • RL 训练在真实编码任务上：codex-1 被训练为迭代运行测试直到通过——奖励信号是通过测试套件。
  • AGENTS.md 文件：OpenAI 的 CLAUDE.md 等价物——存活于上下文重置的持久行为指导。
  • 规模：到 2026 年 3 月周活跃用户 200 万+；3 个工程师在 5 个月内用 Codex 构建了约 100 万行代码。
  • 极端 Harness Engineering：OpenAI Frontier 团队交付了 1500+ PR 和零人工编写代码，证明了 Harness 质量可以完全替代人工编码。

6.3 Google（Jules + Gemini CLI）

Jules 于 2024 年 12 月启动，2025 年 8 月 GA。

架构决策：

  • 队列优先于聊天：唯一围绕任务队列而非实时聊天构建的主要编码 Agent。描述任务、走开、取回 PR。这是一个明确的架构选择——默认异步。
  • 每任务隔离 Google 管理的 VM：每个任务在独立 VM 中运行。输出始终是可审查的 PR。
  • 大脑与双手解耦：Harness（执行环境、异步队列、PR 交付）稳定；底层 Gemini 模型独立升级。
  • 会话内模型路由：Gemini Pro 用于规划和困难任务；Gemini Flash 用于同一 Agent 运行中的较轻子任务。
  • 200 万 token 上下文窗口（Gemini 3.1）：大型代码库可放入上下文而无需检索增强。

6.4 IDE 集成 Agent

Cursor：

  • 三模式架构：Composer（快速内联多文件）、Agent Mode（计划后执行）、Background Agents（异步服务端）
  • 同一 Claude 模型在不同 Harness 中的表现：46% → 80%。Harness 质量是主要变量
  • Cursor 3（2026 年 4 月）：Agent 优先界面；IDE 降级为回退面板
  • 5 亿美元 ARR（2025 Q4）；估值 ~90 亿美元

Windsurf（Cascade）：

  • 从零开始构建的单一深度集成 Agentic 表面——无模式切换
  • “Flow state"模型：Agent 预测下一步需要什么（检查相关测试、类型定义），无需显式提示
  • Wave 13（2026 Q1）：使用 Git worktree 的并行 Agent——多分支同时修改

开源阵营：

  • Cline / OpenCode：完整 MCP 支持；模型无关；可脚本化和可组合。OpenCode：13.5 万 GitHub stars
  • Aider：最小足迹哲学——无 GUI、无云、专家终端助手

关键架构分叉：IDE 原生 Agent 优化 UX 深度和编辑器内自主性；开源 Harness 优化灵活性、模型无关性和 CI/CD 管道中的可组合性。

6.5 开源框架

框架核心创新规模
LangGraph基于图的有状态工作流，持久执行，对 Agent 循环的精确控制v1.0（2025.11）
CrewAI角色扮演多 Agent 协作；快速原型速度52,800 stars, 520 万/月下载
AG2 / AutoGen事件驱动架构，异步消息传递并入 Microsoft Agent Framework
OpenAI Agents SDK轻量 Python，100+ LLM 支持，追踪，护栏26,900 stars, 1030 万/月下载
OpenHands自主全栈编码 Agent，Docker 沙箱SWE-bench 72%（Claude Sonnet 4.5）

实际生产部署案例：Spotify 的"Honk"系统自 2024 年中以来已在数百个仓库中合并 1,500+ AI 生成的 PR，通过验证循环解决 Agent 可靠性问题。

七、关键学术论文

论文核心贡献
ReAct（Yao et al., 2022）建立 Thought → Action → Observation 循环——Agent Loop 的原型
SWE-agent（Yang et al., NeurIPS 2024）证明 Agent-Computer Interface 设计对编码性能的影响与模型本身一样大
Agentic Harness Engineering（arXiv:2604.25850）引入 AHE 作为闭环系统，使用可观测性数据围绕固定模型演进 Harness
Don’t Blame the LLM（arXiv:2607.03691）同一基模型在不同 Harness 中 Terminal-Bench 分数波动 30–50 个百分点
The Harness Effect（arXiv:2607.06906）形式化编排设计如何设定 token 经济学
HarnessX（arXiv:2606.14249）提出构建和演进 Harness 的通用框架
Inside the Scaffold（arXiv:2604.03515）编码 Agent 架构的源码级分类法
Dive into Claude Code（arXiv:2604.14228）分析 Claude Code 的设计空间
Agent Harness Survey（TMLR, under review）110+ 论文、23 个系统的系统性综述

八、总结

核心论点

Harness Engineering 的核心论点可以用一句话概括：可靠 AI Agent 的瓶颈不是模型能力，而是模型周围的系统工程质量。

65% 的企业 AI Agent 失败可追溯到 Harness 缺陷（上下文漂移、Schema 不对齐、状态退化），而非模型缺陷。同一模型在不同 Harness 中的性能可以波动 30-50 个百分点。在生产中运送可靠、经济可持续 Agent 的团队，都是那些把 Harness 作为主要工程表面来对待的团队。

问题-方案映射

难点当前最佳方案
上下文溢出外部工件记忆 + 增量提交 + 上下文压缩
工具过载RAG 动态工具加载 + 激进工具精简
错误恢复推理层反思 + 断路器 + 舱壁隔离
评估SWE-bench Verified + Harness 消融研究
安全推理/权限系统分离 + 沙箱遏制
成本模型路由 + Prompt 缓存 + 批处理 API
多 Agent 协调基于图的状态 + 输出 Schema 验证 + 舱壁
会话持久化四层记忆 + 多作用域标签 + 过时治理

趋势

随着模型能力趋于收敛，竞争壁垒正从模型选择转向 Harness 质量。使用同一 LLM 但不同 Harness 的两个产品，将产生截然不同的用户体验。新型 AI 工程师的角色是：系统架构师、约束设计师、反馈循环构建者、质量策展人——而非直接的代码作者。

这不是 Prompt Engineering 的替代，而是它的超集。Harness Engineering 包含 Context Engineering，后者包含 Prompt Engineering。但驱动力在每个阶段都是相同的：无论 LLM 能力多强，可靠的生产系统都需要模型周围的可执行环境作为约束性工程表面。

参考资料

博客

学术论文

行业分析