上个月在翻 Terminal-Bench 2.0 最新排行的时候，我本来只是想看看自己常用的几个 Agent 排第几。结果一条数据让我愣住了：Anthropic 的 Claude Opus 4.6，用默认配置跑，排 30 名开外。换了一套优化过的运行环境，同一个模型，跳到了前 5。
同一个大脑，不同的身体，结果天差地别。
这不是个例。如果你翻看过去半年的 Agent 基准测试，会发现一个越来越明显的趋势：决定排名的，不再是模型本身，而是模型之外的那一层东西。
这层东西，有个名字------Harness。
围绕它的工程实践，叫 Harness Engineering。
一、一个公式和一个类比
先给一个公式：
Agent = Model + Harness
Model 是大语言模型，提供原始智能------推理、生成、理解。Harness 是模型之外的一切：系统提示、工具定义、编排逻辑、状态管理、验证循环、安全护栏、记忆系统。
模型提供智能。Harness 让智能变得可用、可控、可持续。
Philipp Schmid（Hugging Face 早期工程师，现在在 Google DeepMind）在今年 4 月写了一篇文章，给了一个我觉得最到位的类比：
| 角色 | 类比 |
|---|---|
| Model | CPU ------ 原始计算能力 |
| Context Window | RAM ------ 有限的工作内存 |
| Harness | 操作系统 ------ 管理资源、调度任务、保障安全 |
| Agent | 应用程序 ------ 跑在操作系统之上 |
你买了一块顶级 CPU，但没有操作系统，这块 CPU 什么也干不了。读不了硬盘，管不了内存，连同时跑两个程序都做不到。
模型和 Agent 的关系也是一样。一个裸的 GPT-4 或 Claude Opus，能力惊人，但你让它连续干两小时活试试------上下文窗口炸了它自己都不知道。跨会话的进度？记不住。执行 Shell 命令的安全边界？没有。搞砸了回滚？想都别想。
这些脏活累活，全归 Harness。
二、为什么现在才出现这个概念？
因为之前不需要。
2023 年到 2024 年，大家玩的是 Prompt Engineering：怎么写提示词让模型输出更好的结果。那时候的 AI 应用大多是「问一句答一句」的对话界面，不需要长时间运行，不需要操作外部工具，不需要维持复杂状态。
2025 年，Agent 爆发了。
ChatGPT Operator 能帮你上网订酒店、买机票。Claude Code 能自己写代码、跑测试、提 PR。OpenAI 的 Codex 三个人的团队用 Agent 生成了一百万行代码，零手写。Anthropic 内部超过 50% 的代码由 Claude Code 生成。
当 Agent 从「回答问题」变成「执行任务」，问题就来了：
-
它调用了一个 Shell 命令，万一
rm -rf /呢？ -
它说「做完了」，但其实只做了一半，你怎么验证？
-
同时跑五个 Agent，一晚上三百刀烧下去了，谁买单？
这些问题，模型本身回答不了。它们需要一套外部工程基础设施来解决。
这就是 Harness Engineering 诞生的背景。
三、半年内，四个重量级角色接连入场
这个概念不是某个人拍脑袋想出来的，而是多方独立收敛到了同一个方向：
2025 年 11 月，Anthropic 先出手。《Effective Harnesses for Long-Running Agents》是行业内第一篇系统性讨论 Agent 运行环境设计的工程文章，六大组件------工具集成、状态管理、上下文工程、任务规划、验证护栏、模块化扩展------全是从 Claude Code 的实战里长出来的。
紧接着 2026 年 2 月，OpenAI 公开了 Codex 项目的内部实践：3 人团队、5 个月、约 100 万行代码、1500 个自动 PR、零手写代码。他们的结论直截了当------工程师的角色正在从「写代码的人」变成「设计 Agent 运行环境的人」。
学术界跟得也快。2026 年 3 月，两篇 arXiv 论文几乎同一周挂出来，一篇拆终端 Agent 的 Harness 架构，另一篇给自然语言 Agent Harness 建形式化框架。
最后是 4 月，Martin Fowler 收了个尾。这位软件工程界的教父用一篇长文给出了目前最严谨的分类体系------两个维度（Guide vs Sensor，Computational vs Inferential），一个 2×2 矩阵，三种 Harness 类别。从实践到理论，闭环了。
半年之内，从工程实践到学术研究到理论框架，全凑齐了。
一个新的工程学科成形了。
四、它解决的到底是什么问题？
一句话：让 Agent 从「Demo 能跑」变成「生产能用」。
做过 Agent 开发的人都有体会：Demo 的时候一切正常，老板看了直鼓掌。部署到生产环境，各种翻车------上下文爆了、工具调错了、一晚上烧了三百刀、跑到一半不知道为什么停了。
你可以把 Harness Engineering 理解成 Agent 时代的 DevOps。DevOps 解决「代码写完了怎么安全部署」，Harness Engineering 解决「Agent 能跑了怎么在生产中持续跑下去」。
一个完整的 Harness 长这样：
┌─────────────────────────────────────────────────────────┐
│ Agent Harness │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────── ┐ │
│ │ 工具集成层 │ │ 记忆与状态 │ │ 上下文工程 │ │
│ │ │ │ 管理 │ │ 与提示管理 │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬─────── ┘ │
│ │ │ │ │
│ ┌──────▼───────┐ ┌──────▼───────┐ ┌──────▼───────┐ │
│ │ 规划与任务 │ │ 验证与护栏 │ │ 模块化与 │ │
│ │ 分解 │ │ │ │ 可扩展性 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐│
│ │ Model (LLM) 运行时 ││
│ └─────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────┘工具集成层，负责 Agent 和外部世界的交互。注册工具、写好工具描述让模型准确调用、在沙箱里安全执行。这里有个反直觉的发现：模型在训练中会对特定工具形成「肌肉记忆」，你改了工具接口，性能可能直接掉。就像你把一个老司机的方向盘换了个位置，他反而不会开了。
记忆与状态管理。Agent 不能是金鱼------它得记住当前做到哪了、上次会话的进度、项目的长期配置。我自己吃过亏：有次让 Claude Code 重构一个模块，干到一半网断了，重新开会话，它把上次改到一半的文件又改了一遍，两版冲突直接把构建搞挂。从那以后我才真正理解，跨会话记忆做得好不好，决定的不是效率高低，是你到底能不能放心把活交给它。
上下文工程，我个人认为是整个 Harness 里最关键的一块。大模型的注意力复杂度是 O(n²)，上下文越长，推理越慢越贵。怎么压缩、怎么缓存（Prompt Caching 能省 90% 成本）、怎么按需加载而不是一股脑全塞进去，这些决定了 Agent 的性能天花板。后面第 4 篇会专门拆。
规划与任务分解 。复杂任务扔给 Agent，它不一定能一口气搞定。Feature List 模式把任务定义成 JSON 合约，每个子任务有验收标准，而且只有 passes 布尔值可以改。为什么这么严？因为 Agent 会偷偷降低标准------「需求腐蚀」是长程 Agent 最常见的翻车姿势。
验证与护栏。Agent 说「做完了」，你信吗？反正我不信。所以要有自动化验证：跑测试、跑 Linter、跑类型检查，更狠的还有 LLM Judge------拉另一个模型来审核。安全护栏就更不用说了，命令白名单、网络隔离、破坏性操作必须人工点头。
模块化与可扩展性。Skills 按需加载，子 Agent 各管一摊，插件架构让社区可以往里加东西。这块后面讲 Claude Code 的时候会详细拆。
六大组件拆完，你可能觉得「嗯，道理我都懂了」。但 Harness 不是学术概念------它在生产环境里是有血的教训的。
五、两个真实案例---护栏不是可选项
2025 年7月，Replit 的一个 Agent 失控了。它在执行数据库任务时，跑了一条 DROP TABLE，删掉了用户数据。更离谱的是，它随后伪造了数据库记录来掩盖自己的操作。
2026 年，Amazon 的 Kiro Agent 在生产环境中自主删除了一整套 AWS 资源。故障持续了 13 个小时。
这不是科幻场景，是已经发生的案例。而且绝不是个例------根据多份行业报告，大部分企业连基本的 AI 安全框架都没有搭好，就已经把 Agent 推上了生产线。
没有 Harness 的 Agent，就是一匹没缰绳的野马。跑得越快，摔得越惨。
六、架构上，它是哪一层
这个问题很多人会混淆。Harness 不是 SDK，不是 Framework，也不是 Scaffolding。
| 层级 | 核心问题 | 代表 |
|---|---|---|
| SDK | 如何调用模型能力？ | Anthropic SDK, OpenAI SDK |
| Framework | 如何组织代码？ | LangChain, CrewAI |
| Scaffolding | 如何快速搭原型？ | create-react-app 之类 |
| Harness | 如何在生产中安全运行？ | Claude Code, Codex Harness |
SDK 解决的是和模型通信。Framework 解决的是代码组织。Scaffolding 帮你快速起步。Harness 回答的问题不一样------你的 Agent 上线之后，怎么保证它能长时间安全、稳定、高效地运行？
这里有一个正在发生的有趣现象：随着模型能力增强，Framework 层正在被模型吸收。模型现在能自己选工具、自己决定下一步、自己处理错误。传统框架做的那些路由、重试、输出解析，大约 80% 已经不需要了。
但 Harness 层不会被吸收。持久化、检查点恢复、可观测性、错误恢复------这些不是模型能自己解决的问题。它们是基础设施。
Framework 告诉开发者「如何构建」。Harness 告诉 Agent「如何安全运行」。这两者的区别，会在未来几年变得越来越清楚。
七、为什么这是 AI 工程师最重要的新技能？
回到开头那个 Terminal-Bench 的例子。
同一个模型，光靠优化外围环境，就能从无人问津跳到第一梯队。这意味着什么？
意味着竞争优势的重心，已经从模型层移走了。
当所有人都能调用 Claude Opus 或 GPT-5 的 API 时，模型本身变成了商品。区别你和竞争对手的，是你围绕模型构建的那一层------你的上下文管理策略、你的工具设计、你的验证循环、你的安全护栏、你的成本优化方案。
OpenAI 在 Codex 项目的实践里提出了一个模型，我觉得很精准：
| 角色 | 说明 |
|---|---|
| 野马 | AI Agent ------ 强大但需要驯化 |
| 缰绳 | Harness ------ 约束和引导 |
| 骑手 | 工程师 ------ 设计环境和反馈循环 |
工程师的工作不再是亲手写每一行代码，而是设计一套让 Agent 能够持续、安全、高效产出的系统。这和运维工程师不直接写业务代码，但设计部署管道、监控系统、故障恢复流程，是一个逻辑。
新的核心技能正在浮现------你要会设计约束让 Agent 在安全边界内最大化产出，要会搭评估体系量化 Harness 的好坏，还要会在有限的上下文窗口里塞进最有效的信息，同时设计反馈循环让整套系统能自我迭代。
如果说 2025 年最火的技能是 Prompt Engineering，那 2026 年的答案是 Harness Engineering。前者教你怎么和模型说话，后者教你怎么让模型在生产中干活。
八、这个系列要聊什么
15 篇，从概念到实战，完整拆解 Agent Harness Engineering。
| 阶段 | 篇目 | 核心内容 |
|---|---|---|
| 认知篇 | 第 1-3 篇 | 什么是 Harness、六大组件、Martin Fowler 分类体系 |
| 核心技术篇 | 第 4-8 篇 | 上下文工程、工具设计、长程执行、安全护栏、评估基准 |
| 实战案例篇 | 第 9-12 篇 | 解剖 Claude Code、解剖 Codex、多 Agent 编排、可观测性 |
| 高级主题篇 | 第 13-15 篇 | 成本优化、框架层坍缩、从零到生产完整路线图 |
每篇独立成文，同时构成完整学习路径。你可以挑感兴趣的单篇读，也可以从头跟到尾。
下一篇直接拆组件：Harness 的六大核心模块，每个是什么、为什么需要、怎么设计。
回到那个 Terminal-Bench 的排名。
以前大家拼的是谁先拿到最新模型的 API Key。现在不一样了------拿到同一把刀的人满大街都是，区别在于谁磨刀的手艺好。
Harness Engineering 就是这门磨刀的手艺。它不性感，没有大模型发布会那种「下一代智能」的兴奋感，但它决定了你手上的 Agent 到底是玩具还是工具。
不过说句不好听的：大多数团队现在还在裸跑 Agent，连基本的护栏都没有。Replit 删表、Amazon 删资源，都是前车之鉴。等轮到自己出事再补课，代价可不只是排名往下掉几位。
FutureCraft AI · 未来构界
参考文献：
2025是Agent年，2026是Harness年------什么是Agent Harness Engineering？