Token 刚定了中文名，AI 圈又多了个翻译不了的词

　　马上又来了一个亟需被认证的新词 Harness。

　　这年头想要在 AI 圈子里当个「全面发展的专业人士」，每天要学习的概念是真的多。从最早一个 ChatGPT 能指代一切 AI，我能知道 ChatGPT 就已经领先身边大多数人。

　　到后面慢慢发展到，我要去学习什么是 Prompt，是提示词还是文令、「已死的」MCP，是被 CLI 替代的模型上下文协议、RAG 是风靡一时的检索增强生成、Agent 不是代理，是智能体、Skills 是技能，也是专家、Claude Code 是代码助手。

　　还有因为爪子 Claw 得名龙虾的 OpenClaw、以及龙虾太火需要大量消耗的 Token = xxx……

　　这些堪比「颗粒度」、「对齐」的职场黑话，如果你都听过，大概率还是能在一些聊 AI 的饭局上稍微显露一波的。

　　之前 MiniMax M2.7 模型介绍博客里提到的 Agent Harness 能力

　　但现在，新的词又来了，什么是 Harness。有网友在社交媒体上用一张淘宝搜索的截图回应，表示「很好理解」。

　　很离谱，但是我们把 AI 当牛马去指挥它干活，Harness 翻译成套在 AI 身上的马具/束缚，也并不是全无道理。

　　其实 Harness 最早被真正放进 Agent 领域，还是在 Anthropic 去年十一月的一篇博客，文章里他们探讨了现在的 Agent 要执行的任务越来越长，需要一个有效的 Harness 来确保 Agent 的运作正常。

　　博客链接：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

　　到了今年本地运行的 Agent 重新搬上台面，一众 AI 开发者和研究员在自己的技术博客里，也频繁提到 Harness 这个词。知名博主 Mitchell 提到 Harness Engineering 的理念是，「每当发现某个智能体犯错时，就花时间设计一个解决方案，确保它以后不再犯同样的错误。」

　　紧接着 OpenAI 在今年二月也发了几篇博客，讲的也是 Harness engineering，在他们看来，未来工程师的工作，不是写代码，而是设计智能体的「工作环境」，Harness 就是这个工作环境。

　　在 OpenAI 官网选择中文后，直接翻译成了「工程技术」，博客链接：https://openai.com/zh-Hans-CN/index/harness-engineering/

　　为什么 Harness 开始被重视

　　无论是 Anthropic 最早的博客，还是后面 OpenAI 的 Harness 工程，它们在文章里面描述的故事都是一样的。

　　Harness 是一种包含环境配置、多 Agents 协作机制、严格架构约束和上下文管理的系统，它弥补了 AI 的「上下文焦虑」和易错性。

　　两家顶级 AI 实验室都用大量的内部工程实践证明了，让大模型自主写出百万行代码的关键，并非模型本身有多聪明，而在于构建了一个强大的 Harness（工作流框架 / 护栏系统）。

　　我们让 Claude 画了一张图，来完整介绍一下 Agent Harness，Harness = Agent 的运行容器 + 安全边界 + 调度控制器

　　在 Anthropic 的内部实验中，研究员们发现 AI 竟然也会有「心理问题」。

　　当 Claude 执行长周期的代码任务时，一旦它感觉到自己的上下文窗口快要填满了，它就会产生「上下文焦虑」。就像快要下班的打工人，开始疯狂敷衍，试图赶紧结束任务。

　　要命的是，Claude 并不觉得自己在敷衍，当研究员要求 AI 评估这些「为了下班赶紧结束任务」所编写的代码时，它发现不了其中的问题。

　　面对这种毛病，传统的提示词设计毫无用处。Anthropic 的研究员给出的 Harness 解法是：改变组织架构。

　　他设计了一个包含三个角色的 Harness 闭环：

　　规划师（Planner）：负责把一句话需求扩写成详细的产品文档。

　　生成器（Generator）：纯粹的牛马，只负责按文档写代码。

　　评估器（Evaluator）：极其冷酷的 QA 兼产品经理，手握自动化测试工具。

　　Anthropic 的报告中提到，应用了 Harness 框架的 Agent 在生成网页质量上要好很多，但是成本和时间更长。

　　要求是开发一个游戏制作器，没有 Harness 的那组，AI 跑了 20 分钟，花了 9 美元。结果是界面能看，但核心功能是坏的——游戏里的角色出现在屏幕上，但对任何键盘操作都没有反应，游戏没法玩。

　　有 Harness 的那组，跑了 6 小时，花了 200 美元。结果是游戏不只是能玩，还有动画系统、音效、AI 辅助的关卡设计。

　　在这套 Harness 里，生成器写完一段代码，评估器就会像真实用户一样去点击、测试，一旦发现 Bug 或是那种充满「AI 塑料味」的平庸设计，直接打回重做。

　　包括我们经常用来测试 AI Coding 能力的网页生成，Anthropic 也发现，Harness 的潜力相当大。在一个设计荷兰艺术博物馆网页的任务中，前 9 次迭代，AI 都在老老实实地画平庸的网页。

　　但在评估器不断施压下，第 10 次迭代，AI 突然抛弃了所有常规模板。它交出了一个特立独行的 3D 空间：画作悬挂在透视棋盘格的房间里，用户需要像走迷宫一样穿梭。

　　如果说 Anthropic 的 Harness 侧重于组织架构，去探索 Harness 的设计原理，OpenAI 的 Codex 团队则是把这件事做成了一种工程文化，更多地把 Harness 当作一种工作流框架。

　　他们的核心约束只有一条，那就是没有人工手写的代码。所有代码——业务逻辑、测试、CI 配置、文档、内部工具、生产监控仪表盘——都由 Codex 写。工程师的工作不是写代码，而是设计让 AI 能可靠工作的环境。

　　一开始他们用一个超长的 AGENTS.md 文件告诉 AI 所有的规则。但很快就因为上下文限制，导致 AI 只会进行本地模式匹配，没有真正理解。而且文件很快过时，没有人维护，AI 开始被一堆可能不再成立的规则误导。

　　一套完整的工作流程

　　后来的做法是：AGENTS.md 只有 100 行，只充当一个「目录」，把 AI 指向结构化的 docs/ 文件夹。架构文档、产品规格、设计决策、技术债务追踪，全部是可以被 AI 直接读取的版本化文件。每个 doc 由 AI 写，由 AI 维护，定期有「文档园丁」Agent 扫描过时的文档来自动更新。

　　他们不在乎 AI 怎么写具体的逻辑，但在 Harness 中设置了极其严格的 Linter（代码检查工具）和物理依赖边界。业务代码只能单向调用，越界就会被系统无情切断，根本合并不进项目主分支。

　　在这个 Harness 中，我们所设置的规则，变成了 AI 不可违背的意志。AI 就像生活在「楚门的世界」里，它拥有写代码的绝对自由，但这种自由，永远在人类设定的结界，即 Harness 之内。

　　把这些研究放在一起，其实 harness 的本质就是一套系统，用来补偿当前 AI 不擅长的事。

　　AI 不擅长长期记忆，Harness 就用进度文件、git 历史、结构化来补。

　　AI 评价自己太宽松，用独立的评估 Agent，带着具体标准和真实环境测试。

　　AI 在复杂任务里容易偏航，用任务分解、结构化、合约约定来约束范围。

　　AI 不具备对代码库架构品味的直觉，因此需要用文档和自动化规范检查，将人类的判断转化为系统规则。

　　Claude 生成的 Harness 在 AI 领域的位置信息图

　　有意思的是，随着模型能力增强，harness 的有些部分会变得不再必要，但新的部分又会出现。

　　Anthropic 在升级到 Opus 4.6 之后，发现之前为了对抗「上下文焦虑」设计的「上下文重置」机制可以直接去掉了，因为新模型已经能自己处理了。

　　但同时，他们发现了新的方向，用 harness 来让 AI 在应用里自动集成 AI 功能，这是之前模型做不到的事。

　　对 Harness 来说，模型越强，Harness 不是变得更简单，而是要去做更难的事。

　　怎么翻译 Harness

　　在那篇询问「继 token、Agent 之后，又来了一个难以翻译的词：Harness」推文下，除了给出那张炸裂的「战术胸带 Harness」截图外，还有很多网友给出了自己的翻译。

　　有人说应该叫「线束」，因为这个词在汽车行业已经很多年了。还有「驾驭层」、「驾驭系统」、「Agent 框架」、「控制框架」、「管控层」、「锚定层」、「= Scaffold 脚手架」……

　　更有意思的回复是「安全套」、「套马杆」、以及约束牛马该做什么不该做什么的「槽具」。

　　微博上关于 Harness 怎么翻译的讨论也很多，Token 可以翻译成智元的话，那 Harness 就叫智驭吧……也有人觉得和 MCP 现在无人问津的状态一样，Harness 这个概念只是现在热，过一段时间又会有新的词被造出来、被流行。

　　我们问了问 Claude，它给了好几个答案。

　　「框架」，它认为很多东西都叫框架，framework 可以，architecture 也可以；「执行框架」，强调了运行层面，但中性，没有「约束」的感觉。

　　「驾驭层」中文语境下不太用这种说法；「管控层」强调了「约束」，但是没有「执行」；「套具」在 AI 领域完全是陌生的概念。

　　所以最后它说比较实用的方案是，不翻译，就用 Harness。

　　一个概念如果能被一个词完整概括，翻译本来顺理成章的事。Harness 之所以又是一个不容易确定的词，是因为它在 LLM 这套流程里，同时包含了「约束」、「执行」、「环境」、「系统」等几层意思，拆开来哪个都只说对了一半。

　　和 Token 最终被认证为「词元」，Harness 大概率也会有自己的官方中文。在那天之前，你在技术文章里看到这个词，知道它在说什么就够了。

　　然后在某个聊到 AI 的饭局上，记得说一句，「在未来，会写提示词和 Skills 都不是核心竞争力。真正的顶级人才，是那些懂得如何设计 Harness 的人。」

　　关于 Harness 的详细内容，还可以阅读下面这些文章：

　　1、Anthropic, Harness design for long-running application development, 适用于长时间运行应用程序开发的 Harness 设计, 2026-03-24, https://www.anthropic.com/engineering/harness-design-long-running-apps

　　2、OpenAI, Harness engineering: leveraging Codex in an agent-first world, Harness 工程：在智能体优先的世界中利用 Codex, 2026-02-11, https://openai.com/index/harness-engineering/

　　3、Mitchell Hashimoto, My AI Adoption Journey, 我的 AI 应用之旅, 2026-02-05, https://mitchellh.com/writing/my-ai-adoption-journey

　　4、OpenAI, Unlocking the Codex harness: how we built the App Server, 解锁 Codex 的 Harness：我们如何构建 App Server, 2026-02-04, https://openai.com/index/unlocking-the-codex-harness/

　　5、Anthropic, Effective harnesses for long-running agents, 适用于长期运行 Agents 的有效 Harness, 2025-11-26, https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents