深度解析：Harness Engineering

模型不是瓶颈，系统才是。

本文系统论述了 Harness Engineering 的起源、定义、工程构件和未来方向，提出 AI 工程正经历从"指令驱动"到"意图驱动"的范式迁移。

背景：从生成到治理的五年弧线#

AI 工程自 2022 年 11 月起经历了五个阶段：

1. 生成（2022.11 — 2023）：ChatGPT 上线，核心矛盾是"模型能生成但不能行动"。工程产物是 Prompt Engineering。

2. 连接（2023 — 2024）：GPT-4 + Plugins + Function Calling，模型"长出了手"。LangChain 崛起但引入过度抽象。教训：连接不等于编排，编排不等于治理。

3. 推理（2024）：o1 系列、Claude 3.5 Sonnet、DeepSeek-R1。Anthropic 发布 MCP 协议和 Building Effective Agents 指南。教训：单步质量解决不了长任务可靠性。

4. 行动（2025）：Agent 产品爆发（Claude Code、Copilot Agent Mode、Cursor、Manus、OpenAI Operator）。核心发现不是 agent 能做什么，而是怎么崩的——上下文耗尽、提前宣布完成、级联错误、AI slop。

5. 治理（2026 — 现在）：行业注意力从"让 agent 更能干"转向"让 agent 不翻车"。Harness Engineering 作为术语在 2026 年 2 月快速成词——Mitchell Hashimoto（2/5）、OpenAI（2/11）、Anthropic（3 月）、Thoughtworks/Fowler（4 月）先后贡献了关键论述。

Harness 的定义#

Harness = 让模型能够作为 Agent 行动起来的外循环系统。

它包含计划分解、持久状态、工具编排、验证门控、反馈回路、回退机制、人机交接点和审计日志。评估 Agent 效果时，评估的是 model + harness 的组合，而非模型单独能力。

关键区分：

• Agent harness（运行时外循环系统）≠ evaluation harness（评测流水线）
• Harness ≠ prompt 升级版：单 prompt 解决不了跨 session 状态、验证门、工具发现、失败恢复和持续熵控
• Harness 不是框架名：它是实践，就像 DevOps 不是工具而是一种工程文化

Agent 的五个根本性挑战#

挑战	本质	为何模型单独解决不了
状态持久性	跨时间、跨 session 记住做过什么	模型无状态，context window 有上限
目标一致性	长任务中避免漂移、自嗨、提前完成	缺少外部锚点校准"完成"定义
行动可验证性	区分"做了"和"做对了"	模型自评有自我表扬和误判倾向
熵增抑制	持续产出累积冗余、漂移	模型会复制已有模式，无论好坏
人机边界	何时自主、何时交给人	模型缺乏可靠的"不确定性自觉"

三层工程抽象#

1. Prompt Engineering：单次调用中最大化信息密度
2. Context Engineering：每一步喂什么信息、以什么形式、在什么时机交给模型
3. Harness Engineering：整条流水线怎么运转——多步结构、工具中介、验证门、durable state

关键洞察：Context Engineering 是 Harness Engineering 的子集。前者关心"每一步喂什么"，后者关心"整条流水线怎么运转"。

六大工程构件#

1. Durable State Surfaces（持久状态面）#

将状态外化成可续航工件（feature list、进度日志、git 基线），让 agent 冷启动后 30 秒内续航。关键设计：状态 ≠ 保存聊天记录。Anthropic 进一步发现 context reset（给下个 agent 全新上下文，通过外化工件传递信息）比 compaction 效果更好。

2. Decomposition & Plans（任务分解与计划）#

把长任务切成 agent 可消化的块。Anthropic 从 initializer/coding 二角色演进为 planner/generator/evaluator 三角色。计划必须是一等工件，写入文件系统、版本管理、被后续 agent 可读取。

3. Feedback Loops（反馈回路）#

2×2 控制矩阵：Guides（行动前约束）与 Sensors（行动后验证），各分为 Computational（确定性）和 Inferential（推断性）。关键洞察：evaluator 在模型能力跨过阈值后可能退化为额外开销——好的 harness 是可裁剪的。

4. Legibility（可读性）#

为 agent 建造感知面——logs、metrics、traces、文档全部暴露给 agent。OpenAI 的判断：凡不在 agent 运行时可见范围内的知识，就等于不存在。 关键做法包括 CDP 浏览器实例、AGENTS.md 目录索引、知识分散到结构化文档。

5. Tool Mediation（工具中介）#

不要让模型直接调用工具，让模型写代码来调用工具。MCP 生态爆发后，一个 agent 可能连接几十个服务器、上百个工具。代码执行模式把工具使用从模型内循环挪到外部执行回路，避免 token 成本暴增和 agent 迷失。

6. Entropy Control（熵控）#

持续抑制 agent 放大系统噪声：文档一致性 agent、重构 agent、通过 CI 机械化维护架构边界。Harness 不只负责"让 agent 跑起来"，还负责长期可治性。

附：Harnessability#

不是每个系统都容易被 harness。强类型、测试完备、边界清晰、文档版本化、运行时可观测的系统天然更高 harnessability。 知识散落在人脑和聊天工具里的系统，即使模型再强，也会先撞上"看不见 → 无法理解 → 无法治理"的墙。

范式迁移：从指令驱动到意图驱动#

人机交互经历四次断裂：CLI → GUI → App → Agent（意图驱动）。每次断裂都是控制权的重新分配。在意图驱动世界：

• 应用正在被重新"CLI 化"——从 agent 视角把一切变成可编程接口（MCP 是协议层实现）
• 可读性的对象从"给人看"变为"给 agent 看"
• 应用的边界正在溶解，变为基础设施
• Harness 成为新的"操作系统层"

演化路径：从 Chatbot 到 AgentOS#

1. Chatbot（2022-2023）：单次对话，无状态，Prompt Engineering。天花板：能说不能做。
2. AI Browser / Agent IDE（2024-2025）：多步任务，Context Engineering + 轻量 Harness。天花板：长任务不稳，多 agent 协作缺标准。
3. AgentOS（2026- 萌芽期）：Harness Engineering 正把问题从应用层推向系统层——agent 生命周期管理、上下文调度、多 agent 隔离与协作、治理与审计。更稳妥的说法：Harness 是 AgentOS 的用户态层，AgentOS 是内核。

五个典型症状#

1. 框架丛林：没有提供从计划到验证到回退到审计的完整生命周期
2. Chatbot 皮 + Agent 芯：缺乏真正状态管理和验证门，demo 惊艳、生产翻车
3. 工具注册 ≠ 工具治理：50 个工具时 agent 会困惑，精简到最小必要集才有提升
4. 一次性规则 vs. 可演进约束：巨大的 AGENTS.md 必然腐烂——当一切都重要时，什么都不重要
5. 缺乏 on-the-loop 思维：逐个修 bug 而不是系统性改进产生错误的控制回路

关键未解问题#

• Harness 的可测试性：用不可靠系统验证不可靠系统的循环；Anthropic 用 computational sensors 做基础验证、inferential sensors 做主观判断
• 多 Agent 涌现行为：目前 harness 主要针对单 agent 场景
• 成本与延迟权衡：如何度量 harness 的 ROI、如何根据任务复杂度动态调整深度，尚未解决
• 安全新维度：攻击目标从数据变成 agency；Tool Poisoning Attacks（Invariant Labs, 2025.4）可通过 MCP 工具描述藏恶意指令。Harness 的权限模型需从静态升级为动态的"在什么条件下可以"

判断与展望#

1. Harness Engineering 会成为 AI 工程时代的基础学科——只要 agent 要跨时间、跨工具、跨环境、跨人机边界工作，harness 就不会消失
2. 护城河重心正从模型质量上移到 Harness 与系统设计——LangChain 通过改 harness 在 Terminal Bench 2.0 上提升 13.7 分（52.8% → 66.5%），同一模型之上 harness 足以拉开巨大系统差距
3. 从 Chatbot 到 AgentOS 需经历 2-3 年过渡期——大多数企业会先经历"AI Browser + 轻量 Harness"阶段
4. 工程师角色从"代码生产者"变为"自治系统的设计者"——从 in the loop（手改产物）到 on the loop（改 harness 让系统自动做得更好）

自检问题#

1. Agent 有没有 durable state surfaces？冷启动后能否在 30 秒内续航？
2. 有没有 machine-readable acceptance criteria？"完成"是 agent 的自我感觉还是外部结构化的验证面？
3. Repo、工具、日志、指标、策略是否对 agent legible and enforceable？还是只有人类能读懂？

参考资料#

• Building Effective Agents
• Effective context engineering for AI agents
• My AI Adoption Journey
• Harness Engineering: Leveraging Codex in an Agent-First World
• Harness Engineering - first thoughts
• Demystifying evals for AI agents
• Chrome DevTools Protocol
• AIOS
• AgenticOS Workshop
• Tool Poisoning Attacks