本报告对Harness Engineering（驾驭工程）在项目中的落地方法、核心原理及企业级应用进行了深入剖析。研究结合了OpenAI、Anthropic、LangChain等前沿机构的实践案例，系统性地阐述了从理论到实践的完整路径。核心发现包括：Harness Engineering是继Prompt Engineering和Context Engineering之后的第三次AI工程范式跃迁，其本质是通过构建外部控制系统来提升AI Agent的可靠性；由六大工程支柱（上下文架构、架构约束、自验证循环、上下文隔离、熵治理、可拆卸性）构成的完整技术框架；企业级实践表明，通过实施Harness Engineering可实现高达10倍的效率提升，同时将变更失败率从15%显著降低至3%以下。

从Prompt到Harness：三代AI工程范式的演进

Prompt Engineering（提示词工程）：聚焦于优化单次交互的指令设计，核心在于“怎么问”。其关注点是如何通过精心设计的提示词来引导模型产生期望的输出结果。

Context Engineering（上下文工程）：致力于管理模型可见的上下文信息，核心在于“给什么”。重点在于如何高效地组织、筛选和呈现信息，以避免上下文窗口过载导致的性能下降。

Harness Engineering（驾驭工程）：将控制范围扩展到整个运行环境，核心在于“系统怎么搭”。其核心理念是不直接优化模型本身，而是通过构建约束机制、反馈回路、工作流控制和持续改进循环来优化模型运行的“环境”，从而将不可预测的AI模型转变为可靠的企业级智能体。

核心定义与哲学

Harness Engineering可以理解为一种为AI Agent设计“缰绳 + 马鞍 + 跑道护栏 + 反馈镜子”的综合性工程方法。

用公式表示为：Agent = Model + Harness

• Model：指底层的AI模型能力。
• Harness：指外部的控制系统，包括约束、验证、反馈和隔离等机制。

其核心哲学可以概括为八个字：人类掌舵，智能体执行。这强调了人类在高层规划和监督中的核心作用，而AI则负责具体任务的执行。

Harness Engineering核心原理深度解析

构建可靠Agent的三大架构支柱

基于OpenAI、Anthropic、LangChain等行业先驱及Martin Fowler的实践，Harness Engineering可归纳为三个核心组件，如同为Agent设置的三重护栏：

1. 可读性：让Agent理解系统规则 确保Agent能够准确理解其操作环境和任务要求。

• AGENTS.md文件：为Agent量身定制的项目说明书，明确技术栈、开发命令、代码规范及验证流程。
• 渐进式披露：避免一次性信息过载，仅提供执行当前任务所需的关键规则，详细文档支持按需查阅。
• 分层结构：在Monorepo等复杂项目中，可为不同子目录配置独立的AGENTS.md文件，实现精细化管理。

2. 防御机制：实施硬约束而非软约束 通过系统和工具层面的强制规则，确保Agent行为在安全可控的边界内。

• 状态机控制任务阶段：例如，强制遵循Research（研究）→ Plan（规划）→ Execute（执行）→ Verify（验证）的流程，防止Agent跳跃或无序执行。
• 权限边界：明确禁止写入敏感目录（如.env、secrets/）。
• 防“伪完成”检测：检查工具调用记录，若Agent声称完成任务但无实际调用记录，则强制其回滚或重试。
• 循环失败检测：引入类似熔断器的机制，当检测到重复错误时，自动切换执行路径或上报。

3. 反馈回路：实现持续改进 建立自动化、结构化的反馈机制，使Agent能够从错误中学习并持续优化。

• 自动化验证：在代码修改后自动运行类型检查、代码规范检查（Lint）和单元测试。
• 执行与评审分离：由独立的Agent或会话进行代码审查，避免执行者自我评估带来的偏差。
• 错误经验持久化：将典型的错误模式及修复方案记录在.harness/lessons-learned.md等知识库中，形成从错误发现到规则优化的闭环。

六大工程支柱详解

2.2.1 上下文架构 核心理念：精准控制进入模型上下文的信息量与质量，避免信息过载导致的性能衰退。研究表明，上下文窗口利用率超过40%时，模型性能开始显著下降。 具体实现：

• 信息优先级分层：动态裁剪对话历史中的低优先级信息。
• 滚动窗口与摘要压缩：结合滑动窗口与关键信息摘要，平衡细节与记忆。
• 结构化上下文：使用分隔符、XML标签等方式清晰组织不同的上下文块。
• 延迟加载：仅在工具调用需要时，才加载相关资源（如文件、API文档）的描述。
• 健康监控：实时追踪Token使用量，达到预设阈值时触发自动清理。

2.2.2 架构约束 核心理念：利用工具和代码强制执行业务与安全规则，彻底取代Prompt中的“软”约束。 具体实现：

最近在技术社群的讨论中，“Harness”一词的出现频率陡然升高。从OpenAI的官方博客到Martin Fowler的技术文章，再到各类AI智能体（Agent）开发团队的口头禅，“Harness Engineering”似乎成了新的焦点。查阅字典，其本意是“马具”，这与人工智能有何关联？

本质上，Harness可以被理解为套在AI模型外部、用以管理和约束其行为的一整套系统。模型核心负责“思考”与生成，而Harness则负责“管控”——决定模型能调用哪些工具、可以访问哪些数据、如何对输出进行验证，以及在出现错误时如何提供安全兜底。

这套管控层并非全新概念，过去它常以“脚手架”（Scaffolding）或“包装器”（Wrapper）等名称出现。直至今年二月，OpenAI在一篇博文中正式使用并阐述了“Harness”这一术语，随即被行业广泛采纳与讨论。

那么，这套外围系统究竟有多关键？

---

同一模型，性能差异可达一倍

其重要性可以通过一个事实直观体现：使用完全相同的AI模型，仅更换或优化其外部的Harness系统，在基准测试中的得分差距可能高达一倍。

例如，LangChain团队上个月进行了一项实验。他们开发的代码生成智能体在Terminal Bench 2.0基准测试中最初得分为52.8%，排名在30名开外。随后，团队对其Harness进行了三项关键改进：

1. 在提示词中引入了“自验证循环”，要求智能体生成代码后必须自行运行测试。
2. 编写了一个中间件，用于检测并阻止智能体陷入对同一文件进行数十次无效修改的死循环。
3. 在任务启动时，预先将工作目录的环境信息注入上下文。

模型本身并未更换，仍是GPT-4（此处原文“GPT-5.2-Codex”疑为笔误，根据上下文修正为业内已知模型）。经过上述Harness优化后，得分跃升至66.5%，排名一举进入前五。

团队在博客中揭示了一个核心发现：智能体最常见的失败模式是，生成代码后仅进行“肉眼检查”，认为无误后便提交，而忽略了实际运行测试。引入强制性的自验证环节后，失败则必须修正，仅此一项改变就弥补了大部分的性能差距。

另一组由Nate B Jones在三月发布的数据更为直接：同一模型、同一套测试题目，在更换运行环境（即Harness）后，得分从42%提升至78%。

---

三人团队的构建实践

认识到Harness的重要性后，如何构建它呢？OpenAI内部提供了一个极为前沿的实践案例。

其Codex团队曾立下一个极端规则：整个代码库从零开始，必须完全由AI智能体生成。仓库结构、持续集成（CI）配置、代码格式规范等，全部由Codex编写，没有任何人类编写的代码作为初始锚点。最终，3名工程师在5个月内，通过大约1500次代码合并请求（PR），管理了约100万行由AI生成的代码。

这三位工程师的日常工作是什么？他们主要专注于：搭建初始仓库结构、编写约束规则、配置代码检查工具（Linter）、以及建立有效的反馈循环。当智能体工作卡顿时，他们思考的是：智能体缺失了哪种能力？如何让它理解并执行某项任务？随后，他们会引导Codex将所需的改进方案自行编写并提交回代码库。

可以说，他们的核心工作正是在构建和完善一套高效的Harness系统。

---

实践中的三个关键教训

构建Harness过程中最具价值的经验，往往来自踩过的“坑”。OpenAI团队总结了三点核心教训：

1. 配置文件应简洁精炼。 初期，他们创建了一份冗长的AGENTS.md文件，试图将所有规则塞入其中。结果却导致智能体因上下文过长而难以抓住重点，有效指令空间被规则文件挤占。后来他们改为维护一份约100行的核心规则索引，将详细内容移至docs/目录下，智能体仅在需要时按索引查询。

2. 代码质量需主动治理。 AI智能体会模仿仓库中现有的代码模式，包括不良实践。久而久之，冗余和低质代码会逐渐累积。团队起初每周花费20%的时间手动清理，但不堪重负。最终，他们将清理标准编码为自动化规则，交由Codex定期扫描并自动发起修复PR。

3. 规则必须被自动化执行。 将架构约束仅写在文档中，智能体未必遵守。后来，团队把关键分层规则嵌入持续集成（CI）流程，违反规则的PR会被自动阻断。这确保了规则的执行依靠系统机制，而非智能体的“自觉”。

---

工具数量：少即是多

构建Harness还有一个反直觉的经验：提供给智能体的工具并非越多越好，适度精简反而能提升其表现。

Vercel团队曾开发一个内部数据查询智能体，起初为其配备了17个专用工具。然而成功率仅80%，平均每次查询耗时近5分钟，最差情况甚至运行12分钟后仍告失败。

（图为Vercel博客中引用的内部Slack截图）

随后，团队将工具数量大幅削减至仅剩2个核心工具。结果，成功率提升至100%，且平均处理速度加快了3.5倍。

GitHub的Copilot项目也有类似发现：当工具数量从40多个减少到13个时，其任务准确率从19%大幅跃升至72%。

工具过多时，智能体需要在“选择使用哪个工具”上耗费决策时间，选错则易导致任务路径迂回。减少选项，反而能让其行动路径更直接、高效。

---

行业共识：一个核心配置文件

目前，Anthropic的Claude Code在仓库中放置了CLAUDE.md，OpenAI使用AGENTS.md，Vercel也在测试AGENTS.md的效果。这三家公司不约而同地走向了同一种实践：创建一个专门的配置文件，用以集中定义和传达对AI智能体的各项“规矩”。

至于这个文件的最佳长度、应包含的内容范畴以及如何持续更新，整个行业仍在共同探索与优化中。

---

参考资料：

1. OpenAI 官方博客：Harness Engineering
2. Martin Fowler 博客文章：Exploring Harness Engineering in Generative AI
3. LangChain 博客：Improving Deep Agents with Harness Engineering
4. Vercel 博客：How We Improved Our Agent by Removing 80% of Its Tools
5. Terminal Bench 2.0 排行榜

🤔 从一个问题开始

假设你招聘了一位毕业于哈佛大学的顶尖实习生。

他具备全方位的才能：

编写代码、撰写文章、分析问题
通晓法律、医学、编程知识
反应迅速，能够全天候工作

然而，你却发现一个令人困惑的现象：

当你要求他“帮我分析一下上周的销售数据”时，他回答：

“抱歉，我无法访问您的文件。”

当你指令他“运行一个测试看看”时，他表示：

“抱歉，我无法执行代码。”

当你希望他“明天继续跟进这个项目”时，他解释道：

“抱歉，我记不住昨天的事情（上下文容量已满）。”

问题并非出在这位实习生身上，而是你未能为他配备合适的“工作台”。

---

🔧 Harness的本质：赋予AI能力的工作台

Harness，字面意为“马具”。 正如为马匹套上鞍具，它才能拉车、供人骑行。

AI Harness = 为大型语言模型配备“工作台”，使其能够真正开展工作。

这个“工作台”具体包含哪些组件？

1️⃣ 一双手（工具集成能力） 使模型能够：

访问您的文件系统
执行代码片段
调用外部API接口
操作网页浏览器

缺乏这双手，模型就只是一个“空谈者”——能言却不能行。

2️⃣ 一个笔记本（记忆系统） 使模型能够：

记住您的个人偏好
记录项目的历史状态
回顾之前的对话内容

没有这个笔记本，模型便如同“金鱼”——只有短暂的记忆。

3️⃣ 一位项目经理（任务编排引擎） 将宏大的目标分解为可执行的步骤：

“撰写一篇文章” → 寻找热点 → 搜集资料 → 拟定大纲 → 完成初稿 → 优化润色 → 发布上线
每一步自动推进，无需人工持续监督

缺少项目经理，模型就如同“临时工”——缺乏主动性，推一步才动一步。

4️⃣ 一个保险箱（沙箱隔离环境） 防止模型产生下列风险行为：

误删系统的关键文件
执行具有危害性的指令
泄露敏感的机密信息

失去保险箱的保护，模型就像“擅长拆家的哈士奇”——能力虽强却潜藏危险。

---

🧪 测试人员的共鸣：这不就是测试框架吗？

如果您曾从事自动化测试开发，那么上述概念听起来会无比熟悉。

概念对比

AI Harness 组件	测试框架中的对应组件	核心是否一致？
工具集成	测试夹具 (Test Fixtures)	✅ 均提供“执行环境”
记忆系统	测试数据/配置管理	✅ 均负责“状态存储”
任务编排	测试运行器 (Test Runner)	✅ 均掌控“执行流程”
沙箱隔离	测试环境隔离	✅ 均旨在“防止污染”

以pytest/Junit为例： 它们的作用是将“测试代码”封装起来，使其能够：

什么是Harness？

Harness是AI Agent的控制框架，其概念类似于骑马时使用的缰绳，用以引导方向并维持稳定节奏。特别针对长时间运行的AI Agent，Harness提供了一套“缰绳”系统，确保它们能够持续、可靠地完成复杂任务，OpenAI团队正式将这一机制命名为"Harness"。
当前优秀的Harness实例包括：superpowers、deer-flow以及claude code。

为什么需要Harness？

现阶段，绝大多数大型语言模型（LLM）的“记忆”能力，即上下文窗口，相对有限，导致模型在工作一段时间后便彻底遗忘先前内容。
AI在实际应用中主要面临两大困境：

• 中途失忆：上下文窗口迅速饱和，造成关键信息丢失；
• 半途而废：为避免窗口溢出，任务被迫提前草率结束。

为了保障AI Agent在长线程任务中维持工作质量与稳定性，在记忆问题获得根本性解决之前，必须借助工程化的控制与优化策略，以此扬长避短，充分发挥现有技术潜力。

Harness如何工作？

Anthropic公司提出了一套基于任务拆解、工作交接与工作验收的解决方案：

第一步：项目经理（Plan Agent）
将整体任务拆解为若干细粒度子任务，确保每个子任务均在单个Agent记忆容量内可完成，同时构建清晰的项目框架，并详细编写“工作交接手册”。

第二步：轮班工人（Work Agent）
严格遵循手册执行具体工作：

• 每次仅聚焦于完成一个独立子任务；
• 完成任务后必须“打扫现场”：保持代码结构整洁、添加必要注释、杜绝遗留bug；
• 在“交接手册”中准确记录当前进度与关键信息，方便后续接手的工人无缝继续工作。

第三步：严格验收（Review Agent）

• 模拟真实用户场景进行全面测试；
• 一旦发现bug即刻进行修复，确保成果质量。

Harness带来的益处

总体而言，Harness为AI应用带来了以下显著优势：

• 使得模型的理论能力得以在实际场景中有效落地；
• 支持长时间处理复杂多线程任务，同时保持输出质量不受影响；
• 将AI从类似抽卡游戏的随机输出模式，转变为能够稳定交付可靠成果的高效生产力工具。

自2026年初以来，“harness engineering”这个概念以病毒般的速度席卷了整个AI工程领域。Mitchell Hashimoto为它命名，OpenAI通过一个百万行代码零手写的项目为它做了最佳广告，Stripe则以每周处理1300个AI拉取请求的实践为其背书。一时间，行业中似乎形成了一种共识：不讨论harness，就不配称为真正的AI工程师。

然而，当最初的狂热逐渐退去，一些根本性问题值得我们冷静审视。

harness究竟是什么？

“Harness”一词源自马术装备——缰绳、马鞍、嚼子——即一套用于引导强壮却不可预测的马匹走向正确方向的全套器具。在AI智能体语境中，harness就是包裹在模型外部的一系列基础设施，包括约束机制、反馈循环、文档体系、工具编排以及人工审批流程等。

模型是马，人是骑手，harness就是缰绳与辔头。没有harness约束的智能体，如同一匹在旷野上肆意奔驰的纯血马——速度惊人，姿态优雅，却难以产生任何实际价值。

这个词的中文翻译也面临挑战。“约束工程”定义过窄，因为harness的功能不仅是限制，还包括引导和赋能。“驾驭工程”在语义上较为接近，但仍存在微妙偏差——harness本质是装备（名词），而“驾驭”是一个动作（动词）。因此，中文技术圈目前基本直接沿用英文术语，仅在首次出现时附加括号说明。

有哪些真实的落地案例？

将现有案例按成熟度排序，可以清晰地看到实践路径：

Stripe Minions 是目前最为扎实的生产级应用。他们的Minions是完全自主的编码智能体，每周合并超过1300个拉取请求，且无需人工手写一行代码。其harness是一个五层管道，从Slack消息处理一直延伸到生产级PR的生成。每个Minion运行在隔离的devbox环境中，拥有完整的Shell权限，但无法触及生产系统。其智能体harness深度分叉自Block开源的Goose项目，并针对无人值守场景进行了大量改造。最关键的是，它连接了Stripe内部的集中式工具服务器，暴露了近500个工具，不同智能体按需请求工具子集。

OpenAI内部Codex项目 是“harness工程”这一术语的起源。仅凭3名工程师，在5个月内完成了百万行代码的项目，全程零手写。他们的核心洞见是：庞大的AGENTS.md文件不能当作百科全书使用。大文件会挤占宝贵的上下文窗口、内容会快速过时、且难以进行机械化验证。因此，他们将AGENTS.md缩减至约100行，仅作为“目录”使用，真正的知识库则存放在结构化的docs/目录中。

Anthropic 完成了两项引人注目的实践。一是利用16个智能体从零开始编写了一个能够编译Linux内核的C语言编译器，共计10万行Rust代码，消耗了约两万美元的API费用。其二是在近期发表的一篇文章中，他们将生成对抗网络（GAN）的思路引入harness设计——生成器负责编写代码，评估器则通过实际操作应用来打分，这种职责分离有效解决了“智能体为自己的作品打高分”的问题。

LangChain DeepAgents 是开源社区中最具系统性的实践。他们通过纯粹的harness优化，在不更换模型的情况下，将Terminal Bench 2.0的得分从52.8%提升至66.5%，排名从30名开外一跃进入前五。

一个有趣的观察是，尽管这些项目的规模与风险承受能力差异巨大，但它们却得出了高度相似的结论。

harness的八大核心组件

梳理成功实践，一个完整的harness系统大致需要包含以下组件：

上下文工程 —— 不仅仅是“写好文档”，而是设计一套上下文注入策略：决定在何时、以何种方式将信息注入模型的上下文窗口。OpenAI采用了三级架构：全局AGENTS.md（始终加载、极其简短、作为目录使用）→ 目录级规则文件（根据智能体工作位置自动加载）→ skill/docs/目录下的内容（按需延迟加载）。

测试驱动开发与静态分析 —— 确保智能体的每次修改都能被机械化验证。但这里有一个关键细节：测试本身必须为智能体设计，而非人类。测试harness不能输出数千行无用信息，以免污染上下文窗口。

可观测性集成 —— 整合开放遥测、日志系统与仪表板访问权限，使智能体能够“看见”系统的运行时状态信息。

架构约束强制执行 —— 使用ArchUnit、depguard等工具机械化地强制分层规则，而不是在文档中简单写下“不要违反分层架构”的标语。

执行环境隔离 —— 沙盒是所有其他约束层的物理保障。没有它，上层约束都只是“君子协定”。Stripe为每个Minion分配一个一次性的开发环境，任务完成后立即销毁。

工具集的精准裁剪 —— 并非将所有可用工具都暴露给智能体。Vercel的实践表明，在砍掉80%的工具后，智能体的表现反而更佳。工具过多意味着决策空间过大，智能体更容易做出错误选择。

重试与升级策略 —— 当智能体任务卡住时如何处理？Stripe的设计是：CI流程失败最多重试两次，第三次则直接标记为需要人工介入。LangChain则开发了循环检测中间件，用于识别并跳出死循环。

熵值治理机制 —— 智能体生成的代码会以不同于人类的方式积累技术债务。需要定期运行“垃圾回收”智能体，来扫描文档漂移、命名不一致以及死代码堆积等问题。

关于AGENTS.md的重要教训

OpenAI曾尝试过“一个庞大的AGENTS.md文件”方案，但以失败告终。原因非常直观：上下文窗口是稀缺资源，大文件会挤占任务描述和代码本身的空间；当所有内容都被标记为“重要”时，实际上没有任何内容是真正重要的；单体文件最终会腐烂成过时规则的坟场。

苏黎世联邦理工学院最近的研究也发现，由大语言模型生成的AGENTS.md文件对任务成功率有轻微的负面影响。智能体确实会遵循指令——因此会运行更多测试、阅读更多文件、执行更多搜索——但这些行为对于解决具体任务而言往往并非必要。

Stripe的做法更进一步——他们采用目录级规则文件，智能体在遍历文件系统时会根据所在目录自动加载相应的上下文内容。他们还兼容了Cursor的规则文件格式，从而在Minions、Cursor和Claude Code三套智能体系统之间实现同步。

因此，核心原则是：AGENTS.md文件越简短越好，只应包含智能体不可能自行推断出的关键信息。

AI编码是否需要测试驱动开发？

围绕这个问题存在讨论，但结论并不统一。

支持测试驱动开发的核心论点是：如果让智能体同时编写代码和测试，它倾向于编写“同义反复”的测试——这些测试只验证“代码实际做了什么”，而非“代码应该做什么”。让测试先行于实现，就切断了这条作弊路径。

然而，一项反直觉的实验发现被记录在TDAD论文中。单纯地给予智能体“先写测试再实现”的指令，不仅没有减少回归错误，反而将回归率从6.08%提高到了9.94%——效果比不提供任何指令更差。原因是：智能体并不需要被告知“如何进行测试驱动开发”，它需要知道的是“应该检查哪些测试”。测试驱动开发的流程本身对智能体并非关键，关键在于基于依赖关系感知的测试选择。

回顾主流的关于harness的论述，几乎没有人明确提到测试驱动开发。OpenAI的做法是“设置最少的阻塞性合并关卡，保持较短的拉取请求生命周期，测试的偶发性失败通过后续运行来解决”——这与测试驱动开发“先写测试再实现”的理念完全相反。Stripe也类似——智能体编写代码后运行测试，若持续集成失败则重试两次，第三次则请求人工介入。

实际做法大致可分为三种流派：

人类编写测试，智能体实现功能 —— 这是最受推荐的方式，测试作为刚性合约存在，但本质上是将“定义何为正确”这一最具挑战性的工作留给了人类。

快速反馈循环 —— OpenAI和Stripe所采用的方法，不追求“一次成功”，而追求“快速收敛到正确结果”。

提供测试驱动开发的上下文，而非流程 —— 不告诉智能体“先写测试再写代码”，而是为其提供一张依赖关系图，使其明确知晓“修改会影响哪些测试”。

当大模型的潜力已经强大到可以一气呵成编写数万行代码时，我们是否仍在为如何撰写提示词而烦恼？

当AI智能体已经能够自主执行包含多个步骤的复杂任务时，我们是否还仅仅将其视为对话框中的一个辅助工具？

过去两年行业吹起的泡沫正在逐渐破灭：仅依靠封装大模型的对话产品用户留存率不足5%，仅擅长调整提示词的工程师和产品经理开始面临职业发展的挑战。人们突然意识到，大模型越聪明，我们构建的产品反而越容易失控。

破局的关键并非等待更强大的模型出现，而是彻底转变玩法。今天我们要探讨的“Harness Engineering”（常译为“驭缰工程”或“驾驭工程”），正是AI原生时代席卷行业的一种全新开发范式——其核心不是让人工智能辅助人类写代码，而是由人类为AI设计一套能够稳定、可靠工作的系统。

驾驭工程的整体架构是怎样的？

从提示词到缰绳：行业经历了怎样的演进？

要理解Harness为何会成为必然，我们需要梳理近几年AI开发的演进路径。

2023至2024年，大模型刚刚破圈，最热门的是提示词工程。核心议题是“如何与AI沟通，它才能准确理解我的意图”。那时，精通Prompt编写就能获得高薪，整个行业沉浸在“提示词工匠”的狂欢中。

2025年，焦点转向了上下文工程。问题演变为“应该给AI提供哪些信息”，RAG（检索增强生成）、记忆管理、信息流组织成为技术核心。

步入2026年，两股力量彻底重塑了格局：一方面，大模型的基础能力持续增强，已在诸多领域超越普通人的平均水平；另一方面，AI智能体已能自主执行包含多步骤的长期任务。

于是，一个新的根本性问题浮出水面：如何让智能体在真实的生产任务中稳定运行而不“翻车”？

模型能力足够强大，但在执行长任务时仍易失控：上下文窗口被填满后便开始遗忘，出现错误时不知如何回退，自我评估总是趋于乐观，产出的结果可能杂乱无章且不符合要求。

这些问题并非源于模型本身，而是执行环境和工程化的缺失。Harness Engineering 正是为解决这些问题而生。

究竟什么是Harness Engineering？一个比喻讲透本质

“Harness”直译为“马具”或“挽具”，这个翻译极其精准地传达了其内涵。

试想一匹骏马：它天生拥有力量，能够奔跑、拉车。马具本身并不提供动力，它只专注于四件事：管理方向、控制节奏、保障安全、确保马匹在高速奔跑中不会失控。

一匹未被驯服、没有马具的野马，力量再大你也无法驾驭，更无法让它按照指定路线完成任务，反而可能被它掀翻在地。

将此映射到AI领域：AI智能体是那匹充满力量的野马，而Harness就是套在它身上的缰绳与鞍具。

一个更工程化的定义是：Harness是包裹在AI模型周围的一层基础设施，专门用于管理AI的长期复杂任务。它并非智能体本身，而是架设在智能体框架之上的更高层架构，负责为智能体提供预设的上下文环境、标准化的工具调用接口、生命周期管理，以及开箱即用的任务规划、文件访问、子智能体管理等能力。

用一个操作系统的类比来理解：智能体是运行中的进程，而Harness就是操作系统的内核调度系统。一个进程能成就何事，并非完全由进程自身的代码决定——内存如何分配、I/O如何调度、崩溃后如何处理，这些都是内核调度器的职责。没有调度管理的“裸奔”程序或许能快速启动，但功能极其有限，一次错误便可能导致全盘崩溃。

Harness解决的正是智能体领域的“裸奔”问题：上下文长度不足、自我评估偏差、跨任务状态丢失、长任务中途失控……这些棘手难题都交由Harness来系统化处理。

疯狂的实践：AI如何自主写出百万行代码？

空谈概念不如实战案例。行业领军者已运用这套方法论取得了惊人成果。

OpenAI案例：三人团队，五个月，零人工代码产出百万行

2026年2月，OpenAI发布的一篇博客震惊了整个技术圈：他们使用Codex智能体从零开始构建了一个软件产品。从第一次Git提交算起，历时五个月，产出约一百万行代码——没有任何一行由人工直接编写。

让我们审视这项实验的关键数据：

• 开发周期：5个月
• 初始团队：3名工程师
• 最终团队：7名工程师
• 总代码量：约100万行
• 人工编写代码：0行
• 处理PR数量：约1500个
• 效率对比：较传统手写代码模式提升近10倍
• 产品状态：已上线，拥有真实的内部日活用户并进行外部Alpha测试

最引人深思的是团队扩张后的效应。传统软件工程奉行布鲁克斯法则——“向进度落后的项目中增加人手，只会使项目更加滞后”，因为沟通成本呈指数级增长。但在Harness模式下，团队从3人扩充至7人，产能不仅未下降，反而持续增长。

原因何在？因为人与人之间消除了代码层面的直接依赖。曾经的矛盾是“我写的代码是否会与你写的冲突”，现在的问题变为“我设计的环境与你设计的环境是否兼容”——后者的耦合度天然低得多。

在整个过程中，人类工程师只专注于一件事：设计出让AI高效工作的环境，然后监督其运行。工程师的角色从“代码编写者”转变为“规则设计者”。

Anthropic案例：AI自主迭代引发的创意飞跃

Anthropic团队进行了一项更有趣的实验：他们让Claude智能体在无人干预的情况下，自主迭代开发一个前端网站。

智能体执行复杂任务时常有两个通病：第一，上下文越跑越长，直至窗口被填满，导致连贯性丢失，甚至出现“上下文焦虑”——临近限制时便草草收工；第二，自我评估往往过于乐观，无论产出质量如何，都倾向于认为“做得很好”，这在设计类等主观性较强的任务中尤为突出。

Harness如何破解这些难题？工程师为智能体添加了两大约束： 第一，实施明确的上下文切割与管理，避免无关信息堆满工作窗口。 第二，制定四项清晰的评分标准，要求智能体每次迭代后依此自行打分：

1. 设计质量：整体是否呈现连贯、统一的视觉风格？
2. 原创性：是简单套用模板，还是做出了自定义的创意决策？
3. 工艺细节：排版、间距、色彩等基础执行是否到位？
4. 功能性：用户能否直观理解界面并顺利完成操作？

这套方法效果显著。到第九次迭代时，智能体已产出一个符合要求的、虚构博物馆的深色主题着陆页，视觉效果相当精致。

第十次迭代则更为惊人：智能体完全推翻了之前的所有设计，给出了一个人类未曾预料的创意方案——将整个网站重构为一种空间体验：利用CSS透视变换渲染出带有棋盘格地板的3D房间，艺术品自由悬挂于墙面，导航通过“门廊”切换画廊房间来实现，而非传统的滚动与点击。这便是一次超越人类预设的、真正的创意飞跃。

Harness工程的核心：必须做好哪三件事？

通过案例分析，我们可以拆解Harness Engineering的核心工作，归结为三件事，其精髓可概括为：人类负责掌舵，智能体负责划桨。工程师的职责从编写代码，转向设计环境、明确意图、构建反馈循环。

核心一：设计智能体的运行环境

在传统软件工程中，“环境”通常指IDE、编译器、依赖包等。但在Harness范式下，“环境”的范畴广阔得多：你的整个代码仓库结构、架构约束、代码检查规则、文档规范、持续集成流水线……所有这些构成了智能体的运行环境。

智能体并非“在你的代码库中帮你写代码”，而是“在你精心设计的环境里，自主完成整个开发任务”。环境设计优良，智能体产出的代码自然规范统一；环境设计粗糙，智能体便会“四处乱撞”，产出难以整合的碎片化成果。

这好比城市规划：规划者无需亲手建造每一栋楼，但必须划定道路红线、规定容积率、制定建筑规范。楼房由开发商（智能体）建造，但城市的整体风貌与功能，则由规划师（工程师）的设计所决定。

核心二：将模糊意图拆解为可执行的明确任务

在传统开发流程中，产品经理撰写PRD，工程师理解需求后编码实现。在Harness模式下，工程师的工作更接近产品经理：将一个模糊的宏观目标，层层拆解为智能体能够逐步执行的具体任务。

OpenAI团队将此方法称为“深度优先工作法”，其逻辑清晰：

1. 将大型功能拆分为多个独立模块。
2. 每个模块进一步分解为设计、编码、测试、评审四个步骤。
3. 为每一步明确界定输入、输出和验收标准。
4. 引导智能体逐个模块完成构建。

这里需要强调：这并非仅仅是撰写更优质的提示词。这是整个思维模式的迁移：从思考“我如何实现这个功能”，转变为思考“我如何描述这个功能，才能让智能体独立地实现它”。两者所处的抽象层次截然不同。

核心三：构建能够快速纠错的反馈回路

这是Harness最核心的环节，也是许多人理解存在偏差的地方。

仅凭裸模型存在四大局限：缺乏记忆、无法执行代码、知识陈旧、没有工作环境。Harness通过六大组件逐一解决——文件系统负责存储与版本管理；沙箱环境赋予代码自我验证能力；AGENTS.md无需训练即可注入知识；Web Search与MCP打破知识的时间壁垒；上下文工程对抗信息熵增；编排系统与Hooks保障多智能体协作质量。贯穿始终的系统提示词，则是整套框架的神经中枢。

核心观点在于：模型提供原始智能，而Harness则让智能变得切实可用。如果你并非模型本身，那么你很可能正在构建或使用Harness的一部分。

2025年底，一位创业者在社交媒体上分享的经历迅速引发了技术圈的广泛讨论：

“我花了三个月优化Prompt，模型回答质量提升了20%。然后我花了两周搭建Harness，整体任务完成率从35%飙升到了82%。” 这条动态下，点赞最高的评论仅四个字：方向错了。

过去两年，整个行业似乎都在追逐更庞大的模型、更强的推理能力和更长的上下文窗口。从GPT-4到Claude 3.5，从Gemini Ultra到DeepSeek-V3，参数规模不断刷新纪录，基准测试分数持续攀升。每一次新模型发布，都会掀起一阵“通用人工智能即将到来”的乐观情绪。

然而，一个不容忽视的事实是：在绝大多数真实业务场景中，用户并未感受到与基准分数相匹配的能力跃升。

原因何在？或许是因为关注的焦点出现了偏差。

模型如同一台强大的引擎，但引擎本身并非汽车。一台裸露的引擎放置在地面，它无法载人、无法转向、无法制动，甚至无法自行启动。你需要底盘、变速箱、方向盘、仪表盘、燃油系统……这一整套让引擎“发挥作用”的装备，在AI智能体的世界中，正逐渐被赋予一个日益重要的名称——Harness。

智能体 = 模型 + Harness。 模型负责提供智能，Harness则负责让智能落地产生价值。

这并非一个全新的概念，但它正在成为2026年AI工程领域最核心的共识。本文将从“裸模型的四个硬伤”切入，逐一剖析Harness的六大核心组件——文件系统、Bash与沙箱、记忆系统（AGENTS.md）、Web搜索与MCP、上下文工程、编排与Hooks——旨在揭示AI智能体真正的竞争壁垒并不在模型层，而在Harness层。

阅读本文后，你将重新认识一个事实：你所编写的每一行系统提示词、搭建的每一个工具链、设计的每一套协作逻辑，都是在构建Harness。如果你不是模型本身，那么你就是Harness的一部分。

Agent = Model + Harness：一个被忽视太久的公式

在深入拆解Harness之前，我们有必要先确立一个基础的认知框架。

什么是 Agent？

“Agent”一词在2024年被过度使用。任何能调用API的聊天机器人都自称Agent，任何增加了RAG的问答系统都宣称自己是Agent。但若回归其最本质的定义—— Agent是一个能够自主感知环境、做出决策、执行行动并从结果中学习的智能体。

请注意其中的四个关键动词：感知、决策、执行、学习。裸模型能胜任哪一步？严格来说，它仅能完成“决策”——给定输入，产生输出。它无法主动感知外部世界（缺乏感官），不能真正执行行动（缺乏手脚），更无法进行持久化的学习（缺乏长期记忆）。

因此，一个真正的Agent必然是这样的结构： Agent = Model + Harness

Model是大脑，负责“思考”。Harness则是大脑之外的一切——感官系统、运动系统、记忆系统、能量系统——负责将“思考”转化为“行动”。

Harness 到底是什么？

Harness的英文原意为“挽具”，即套在马上、将马力转化为拉车动力的那套装备。这个类比十分精妙：模型是马，Harness是挽具，而Agent是马、挽具与车辆构成的完整系统。

更技术化地描述，Harness是模型之外的所有工程基础设施的集合。它至少包括：

• 模型如何接收输入（上下文构建）
• 模型的输出如何被解析与执行（工具调用、代码执行）
• 模型如何获取外部信息（搜索、API调用）
• 模型如何记住过往经历（记忆机制）
• 模型如何与其他模型或子系统协作（编排）
• 以及贯穿所有环节的安全、格式与质量约束（Hooks）

Harness不是一个单一的零件，而是一套系统工程。这也解释了为何构建一个真正高效的Agent如此困难——你并非在调整某个参数，而是在设计一整座工程架构。

这张图传达了三个核心信息：第一，Model虽处于中心，但被Harness全方位包围与支撑；第二，六大组件各司其职又相互协同；第三，系统提示词（System Prompt）贯穿所有组件，是Harness的“神经系统”。

裸模型的四个硬伤：为什么光有聪明的大脑远远不够

要理解Harness的价值，必须先正视一个现实：裸模型（Raw Model）存在四个致命的缺陷。

所谓“裸模型”，即没有任何外部工具、文件系统、搜索能力或持久化记忆的纯粹大语言模型。可以将其想象为一个被关在密闭房间里的天才——智商极高，但看不见外界，记不住昨天的对话，发出的指令也无人执行。

硬伤一：无法维持跨会话状态

这是最易被感知的痛点。你与一个裸模型进行了两小时深度对话，讨论了一个复杂的系统架构，绘制了流程图，确定了技术方案。然后你关闭窗口，次日返回——它已忘记了一切。

这并非“记忆力差”，而是根本没有记忆机制。裸模型的每一次对话都是全新的开始，前一轮的所有上下文在会话结束时即刻消失。

对于简单问答，这或许无妨。但对于任何需要持续推进的工作——撰写书籍、开发项目、管理流程——此缺陷是致命的。你需要每次都从头解释背景，重新建立共识，手动输入之前的结论。这并非在与AI协作，而是在训练一位每日失忆的实习生。

硬伤二：无法执行代码

裸模型可以“编写”代码，但不能“运行”代码。它可以生成一段Python脚本，却无法验证这段代码是否能正确执行。它可以告诉你算法的时间复杂度，但不能在真实数据集上运行一遍以证明其分析。

这意味着什么？意味着裸模型的代码输出缺乏自我验证能力。它可能写出语法正确但逻辑错误的代码，可能忽略边界条件，可能对库版本做出错误假设。而所有这些错误，只有在人类手动复制代码到本地环境运行后才会暴露。

更深层的问题是：缺乏代码执行能力，模型便失去了“编写→运行→观察→修复→迭代”的自我验证循环。此循环正是优秀程序员的核心工作方式。一个不能运行自身代码的AI编程助手，犹如一位只会在纸上绘图却从不踏足工地的建筑师——理论上完美，实践中漏洞百出。

硬伤三：无法获取实时知识

大语言模型的知识存在一个“截止日期”。截止日期之后的一切——新发布的API文档、最新的安全漏洞、上周刚更新的框架版本、今日新闻——它一无所知。

在技术领域，此问题尤为严重。前端框架每半年一次大版本更新，云服务商每季度调整产品线，开源库的不兼容变更防不胜防。你询问裸模型“React 19的use() Hook如何使用”，它可能给出基于React 18的答案，甚至虚构一个根本不存在的API。

这正是所谓“幻觉”（Hallucination）的一个重要来源：模型并非“故意”胡说，而是其知识库中根本没有正确答案，于是它基于过时信息或模式匹配，“推理”出一个看似合理实则错误的答案。

在AI领域保持前沿，需要持续跟进层出不穷的新概念。不久前，“Token”的中文译名刚被正式确定为“词元”，眼下又一个亟待厘清的新术语“Harness”进入了大众视野。

这年头想要在AI圈子里当个“全面发展的专业人士”，每天要学习的概念是真的多。从最早一个ChatGPT能指代一切AI，到后来逐步厘清Prompt是“提示词”还是“文令”、了解已显颓势的MCP（模型上下文协议）正被CLI替代、掌握风靡一时的RAG（检索增强生成）技术、明确Agent应译为“智能体”而非“代理”、知晓Skills既是“技能”也代表“专家”、以及认识Claude Code这类代码助手。

还有因“Claw”（爪子）得名的OpenClaw、以及因模型处理需求激增而被反复讨论的Token……这些堪比“颗粒度”、“对齐”的行业术语，如果你都有所涉猎，大概率能在一些探讨AI的场合中稍展学识。

如今，新的术语已然到来——何为Harness？有网友在社交媒体上用一张淘宝搜索结果截图进行回应，表示其“很好理解”。

虽然看似离谱，但若将AI视作可被驱使的“牛马”，将Harness翻译为套在AI身上的“马具”或“束缚”，也并非全无道理。事实上，Harness被正式引入智能体领域，可追溯至Anthropic去年十一月发布的一篇博客。文中探讨了当前智能体所需执行的任务日益延长，因而需要一个有效的Harness来确保其运作正常。

进入今年，随着本地化运行的智能体再度成为焦点，众多AI开发者与研究员在其技术博客中也频繁提及Harness一词。知名博主Mitchell Hashimoto提出了“Harness Engineering”的理念，其核心是：“每当发现某个智能体犯错时，就投入时间设计一个解决方案，确保它未来不再犯同样的错误。”

紧随其后，OpenAI在今年二月发布的数篇博客同样聚焦于Harness engineering。在他们看来，未来工程师的职责或许不再是编写代码，而是设计智能体的“工作环境”，而Harness正是这个环境本身。

二、为何Harness概念日益重要

无论是Anthropic最初的论述，还是后来OpenAI倡导的Harness工程，其核心叙事是一致的。

Harness是一个集环境配置、多智能体协作机制、严格架构约束与上下文管理于一体的系统性框架，旨在弥补AI存在的“上下文焦虑”与易错性缺陷。

两家顶尖AI实验室均通过大量的内部工程实践证实，让大模型自主编写数百万行代码的关键，并不完全在于模型本身的智能程度，更在于是否构建了一个强大的Harness（可理解为工作流框架或护栏系统）。

我们让Claude生成了一张示意图来完整阐述Agent Harness的概念。简而言之，Harness = 智能体的运行容器 + 安全边界 + 调度控制器。

在Anthropic的内部实验中，研究人员意外地发现AI也可能存在“心理问题”。当Claude执行长周期编码任务时，一旦感知到自身的上下文窗口即将被填满，它便会产生“上下文焦虑”。这好比临近下班的打工人，开始草率应付，急于结束手头工作。

棘手的是，Claude自身并不认为这是在敷衍。当研究员要求AI评估这些“为赶工而编写”的代码时，它无法识别其中存在的问题。面对此类状况，传统的提示词工程往往收效甚微。Anthropic研究员提出的Harness解决方案是：重构任务的组织架构。

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

• 规划师：负责将一句模糊的需求扩展为详尽的产品需求文档。
• 生成器：纯粹的执行者，仅依据文档编写代码。
• 评估器：严格的质检员兼产品经理，手握自动化测试工具，冷酷无情。

Anthropic的报告指出，应用了Harness框架的智能体在生成网页质量上显著提升，尽管付出了更高的成本与时间代价。例如，在开发一个游戏制作器的任务中：

• 未使用Harness的小组：耗时20分钟，花费9美元。结果是界面尚可，但核心功能损坏——游戏角色无法响应键盘操作。
• 使用Harness的小组：耗时6小时，花费200美元。结果是一个功能完备的游戏，包含动画系统、音效甚至AI辅助的关卡设计。

在这套体系中，生成器每完成一段代码，评估器便会像真实用户一样进行点击与测试。一旦发现Bug或设计平庸之处，便立即打回重做。在另一项设计荷兰艺术博物馆网页的任务中，前9次迭代AI都产出着常规网页。但在评估器的持续压力下，第10次迭代AI突破了模板，交付了一个独特的3D空间设计，让画作悬挂于透视棋盘格房间中，用户需以穿梭迷宫的方式浏览。

如果说Anthropic的Harness侧重于通过组织架构探索设计原理，那么OpenAI的Codex团队则是将此事提升为一种工程文化，更多地视Harness为一种工作流框架。

他们的核心约束非常明确：不写入工代码。所有代码——包括业务逻辑、测试用例、CI配置、文档、内部工具乃至监控仪表盘——均由Codex生成。工程师的职责转变为设计能让AI可靠工作的环境。

初期，他们尝试用一个超长的AGENTS.md文件来告知AI所有规则，但很快因上下文限制导致AI只能进行浅层的模式匹配，且文档难以维护而过时。后来的改进方案是：AGENTS.md仅保留100行作为“目录”，将AI引导至结构化的docs/文件夹。所有架构文档、产品规格等均由AI编写和维护，并有专门的“文档园丁”智能体定期扫描更新。

他们不干涉AI编写具体逻辑，但在Harness中设定了极其严格的Linter（代码检查工具）和物理依赖边界。业务代码必须单向调用，越界行为会被系统阻断，无法合并入主分支。在这个体系中，人类设定的规则成为AI不可违背的意志。AI如同生活在“楚门的世界”，拥有编写代码的充分自由，但这种自由永远被限定在人类设定的Harness结界之内。

综合这些研究，Harness的本质是一套系统性补偿机制，用以弥补当前AI的诸多短板：

• 针对不擅长的长期记忆：Harness利用进度文件、Git历史、结构化文档来补充。
• 针对过于宽松的自我评价：引入独立的评估智能体，配备具体标准和真实环境测试。
• 针对复杂任务中的易偏航性：通过任务分解、结构化约束和合约约定来限定范围。
• 针对缺乏代码库架构的直觉：借助文档化和自动化规范检查，将人类的判断转化为系统规则。

一个有趣的现象是，随着模型能力增强，Harness的某些部分可能变得不再必要，但新的需求又会产生。Anthropic在升级到Opus 4.6模型后，发现之前为对抗“上下文焦虑”设计的“上下文重置”机制可以直接移除，因为新模型已能自行处理。但同时，他们发现了新方向——利用Harness让AI在应用中自动集成AI功能，这是此前模型做不到的。对Harness而言，模型越强大，Harness的目标不是变得更简单，而是要去应对更艰巨的挑战。

三、Harness中文译名探讨：从“线束”到“不翻译”

在关于“继Token、Agent之后，又来了一个难以翻译的词：Harness”的讨论下，除了那张令人印象深刻的“战术胸带”截图，网友们也提出了诸多译名方案。

有人主张沿用汽车行业的成熟译法“线束”。其他提议包括“驾驭层”、“驾驭系统”、“智能体框架”、“控制框架”、“管控层”、“锚定层”，乃至认为其等同于“Scaffold（脚手架）”。更有趣的提议如“安全套”、“套马杆”，以及约束行为的“槽具”。

微博上关于Harness译法的讨论也很热烈。有观点认为，若Token可译为“智元”，那Harness或可称“智驭”。也有人觉得，如同现今少人问津的MCP，Harness概念可能只是一时之热，很快又会有新词涌现。

我们询问了Claude的看法，它给出了多个选项：“框架”过于宽泛；“执行框架”强调了运行层面但缺乏“约束”感；“驾驭层”在中文技术语境中不常见；“管控层”突出了“约束”但缺失“执行”意味；“套具”在AI领域则完全陌生。

因此，Claude最终倾向于一个实用方案：不翻译，直接使用“Harness”原词。

一个概念若能精准对应一个词语，翻译本是水到渠成。Harness之所以难以定译，是因为它在LLM工作流中，同时涵盖了“约束”、“执行”、“环境”、“系统”等多重内涵，拆分出的任何一个译名都只能表述其部分含义。正如Token最终被确定为“词元”，Harness大概率也将迎来其官方的中文译名。在那之前，当你在技术文献中邂逅此词，理解其指代何物便已足够。

未来，在某个谈及AI的场合，或许可以这样总结：“在未来，精通提示词或技能设计可能不再是核心竞争力。真正的顶尖人才，将是那些深谙如何设计Harness的人。”

---

延伸阅读资料：

1. Anthropic, 《适用于长时间运行应用程序开发的Harness设计》，2026-03-24
2. OpenAI, 《Harness工程：在智能体优先的世界中利用Codex》，2026-02-11
3. Mitchell Hashimoto, 《我的AI应用之旅》，2026-02-05
4. OpenAI, 《解锁Codex的Harness：我们如何构建App Server》，2026-02-04
5. Anthropic, 《适用于长期运行Agents的有效Harness》，2025-11-26

前置知识提示： 了解大型语言模型（LLM）的基本原理、ReAct推理模式，并拥有AI智能体（如AutoGPT、Claude Code或Cursor Agent）的使用经验。
核心观点： 模型本身正逐渐成为标准化商品，而Harness所代表的基础设施层才是构建竞争护城河的关键。

---

一、Harness的精确定义：模型与执行的桥梁

智能体 = 模型 + Harness

模型专注于“思考”过程，负责生成语言标记（token）；Harness则承担“执行”职责，将这些标记转化为实际动作——例如读取文件、调用应用程序接口（API）、执行代码或持久化保存状态。

如果将模型比喻为一匹拥有蛮力的野马，那么Harness就是驾驭它的缰绳与鞍具，将原始力量导向可控、高效的工作输出。另一个更为精确的类比是：模型如同中央处理器（CPU），Harness则是操作系统（OS）。CPU负责执行计算指令，而操作系统管理着所有外围资源与调度。没有操作系统的裸机CPU，甚至无法点亮屏幕。

LangChain工程师Vivek Trivedi给出了一个极为简洁的定义：

如果你不是模型本身，那么你所做的一切就属于Harness的范畴。

换言之，除了模型权重参数之外，所有促使智能体运转起来的代码、配置、流程逻辑，统统归属于Harness这一层。

---

二、为何仅凭模型不足以应对生产环境

大型语言模型的核心本质是：接收输入标记，并生成输出标记。它天生缺乏以下关键能力：

缺失的能力	对实际任务的影响
持久化状态	新一轮对话会丢失上一轮计算出的中间结果
访问真实文件系统	无法读取项目代码库，也无法写入新文件
执行代码	只能描述“应该如何操作”，不能实际运行程序
调用外部工具	无法查询实时数据或操控浏览器等外部应用
长时间自主工作	上下文窗口填满后，模型性能会急剧衰退（即上下文腐烂，Context Rot）

上述每一种能力缺口，都是Harness需要填补和构建的基础设施空白。

---

三、核心架构剖析：Harness的层次化组件

Harness并非单一工具，而是一套按功能分层的能力模块集合。

🧠 LLM（智能层）

⚙️ Harness（框架层）

💾 文件系统与持久化存储 + 工作空间管理

💻 Bash/代码执行 + 通用工具与自定义工具集成

🛡️ 沙箱环境 + 隔离执行与安全边界设定

📋 记忆与检索系统 + 跨会话记忆与实时知识接入

💡 规划与验证模块 + 目标分解与自验证循环

🔗 钩子与中间件 + 上下文压缩与流程拦截续接

推理引擎 → 输入提示词 → 输出动作指令

3.1 文件系统：持久化能力的基石

这是最底层、也是最关键的原始能力（primitive）。模型仅能操作其上下文窗口内的数据。缺乏文件系统，智能体就像没有笔记本的人——对话内容随风而逝，关闭会话窗口便全部遗忘。

智能体框架（Harness）到底是什么？它并非一个简单的包装，而是构建功能化人工智能的核心基础设施。本文将深入拆解其构成与价值。

智能体框架的本质：模型与框架的分离

首先，我们可以用一个简洁的公式来概括智能体的核心构成：智能体 = 模型 + 框架。如果你正在构建的不是模型本身，那么你工作的重点就是框架。这个划分虽然基础，却蕴含着深刻的设计哲学。

所谓框架（Harness），指的是除基础模型之外的一切组件，包括运行代码、配置参数、执行逻辑与状态管理。一个未经“装配”的原始模型并非智能体，它仅仅是一个能够生成文本的“大脑”。只有当框架为其注入状态管理、工具调用、反馈循环以及各类约束条件后，它才真正转变为一个能够执行具体任务的智能体。

具体而言，一个典型的框架包含以下要素：系统提示词、可供调用的工具与技能（例如 MCP 协议及其描述）、捆绑的基础设施（如文件系统、沙箱环境、浏览器）、任务编排逻辑（如子代理生成、任务交接、模型路由选择），以及确保执行确定性的各类钩子与中间件（例如上下文压缩、任务延续、代码检查）。

清晰划分模型与框架的边界，其最大益处在于迫使系统设计者围绕模型的核心智能进行思考，避免将模型能力与实现框架混为一谈，从而构建出更清晰、更可维护的系统架构。

框架存在的必要性：弥补大模型的固有局限

要理解框架为何不可或缺，需从大模型自身的局限性说起。基础模型的功能本质上相当纯粹：接收文本、图像、音频或视频作为输入，并输出相应的文本。仅此而已。

开箱即用的模型无法独立完成以下事项：在多次交互中维持持久化的状态、执行任意代码、访问实时更新的信息、或自行配置环境并安装依赖包。所有这些能力，都需要在框架层面进行设计和实现。

一个最直观的例子便是日常使用的“聊天”应用。其本质是将模型包裹在一个循环结构中，记录并管理对话历史，然后追加新的消息进行交互。这本身就是一种最基础的框架形态。其核心设计思路在于：将期望的智能体行为，翻译并实现在框架的具体功能之中。

文件系统：框架最底层的基石

核心需求：赋予智能体持久化存储的能力，使其能够与真实数据交互，将无法放入上下文的信息卸载存储，并实现跨会话的工作成果保存。

模型的认知边界严格受限于其上下文窗口，除此之外它不拥有任何持久记忆。在没有文件系统支持的情况下，用户必须手动将内容复制粘贴到上下文中，这对于追求自主性的智能体而言是完全不可行的。

解决方案自然而直接：由框架提供一套文件系统抽象以及相应的文件操作工具。文件系统堪称最基础的框架“原语”，它解锁了几项关键能力：智能体拥有了专属的工作空间，可以读取数据、代码和文档；工作可以增量式写入并卸载，无需将所有内容都塞入有限的上下文；状态能够跨越不同的会话得以持久保存；多个智能体与用户之间可以通过共享文件进行协作——那些“智能体团队”架构正是基于此运行。

在文件系统之上叠加 Git 等版本控制工具，智能体便能够追踪工作进度、回滚错误操作、开辟分支进行实验。因此，文件系统不仅仅是存储介质，它更是后续所有高级能力得以构建的坚实地基。

Bash 与代码执行：解锁通用问题解决能力

核心需求：让智能体具备自主解决问题的能力，而非每次都需要用户为其预先设计好每一个专用工具。

当前智能体的主流执行模式是 ReAct（推理-行动）循环：推理下一步该做什么，调用工具执行，观察结果，并循环往复。问题在于，如果仅提供一组固定的预定义工具，智能体的能力上限便被牢牢锁死。

与其要求用户为每一种可能的操作编写专用工具，不如直接赋予智能体一个 Bash 工具，让它自行编写代码来解决问题。框架集成 Bash 工具，模型通过自主编写和执行代码来应对各种复杂场景。这是让模型“拥有一台电脑”的关键一跃。它不再受限于预配置的工具集，而是能够通过编写代码动态创造出解决问题所需的新工具。当然，框架中仍可包含其他专用工具，但代码执行已成为智能体实现自主问题解决的默认通用策略。

沙箱环境：为安全执行装上防护网

核心需求：为智能体提供一个具备正确默认配置、能够安全执行操作、观察结果并推进任务的环境。

具备了存储和代码执行能力后，还需要一个安全的“场所”来运行这些操作。直接在本地执行智能体生成的代码风险极高，并且单一的本地机器资源也难以支撑大规模的智能体工作负载。

沙箱环境有效解决了这一问题——它为智能体提供了隔离的、安全的执行环境。框架连接到沙箱来运行代码、检查文件、安装依赖、完成任务，而非在本地直接执行。沙箱可以按需动态创建、分发到多个并行任务，并在任务完成后销毁，天然支持系统的横向扩展。

一个优秀的执行环境还需配备良好的默认工具集：预装的语言运行时和常用软件包、用于版本控制和测试的命令行工具、用于网页交互与验证的浏览器。拥有了浏览器、日志记录、屏幕截图、测试运行器等工具后，智能体便能形成自我验证的闭环——编写代码、运行测试、查看日志、修复错误，实现全流程自主化。

智能体在何处运行、拥有哪些工具、能够访问哪些资源、如何验证自身工作成果——所有这些都属于框架层面的设计决策，基础模型本身对此无能为力。

记忆与搜索：赋予智能体持续进化的知识

核心需求：智能体应当能够记住已经学习或处理过的信息，并且能够访问其训练截止日期之后出现的新知识。

模型除了其内部权重和当前的上下文内容外，不存储任何额外的知识。既然无法直接修改模型权重，“添加知识”的唯一途径便是向上下文窗口中注入信息。

文件系统在此再次扮演核心角色。框架可以支持类似 AGENTS.md 这样的记忆文件，在智能体启动时自动将其内容注入上下文。智能体在工作过程中更新这个文件，框架在下次启动时便会加载最新版本——这实现了一种持续学习机制：将某个会话中学到的经验持久化，并带入未来的会话中。

至于知识时效性问题，网络搜索工具和 MCP（模型上下文协议）工具（例如 Context7）能够帮助智能体访问训练数据截止日期之后的信息，例如新版本的库文档、最新的实时数据等。将网络搜索和查询最新上下文的工具作为基础能力直接集成到框架中，是极具价值的。

对抗上下文衰减：高效管理稀缺资源

核心需求：智能体的表现不应随着工作的推进和上下文窗口的填满而显著下降。

上下文衰减描述了一个真实存在的现象：随着上下文窗口逐渐被填满，模型的推理能力和任务完成质量会出现明显下滑。上下文是一种稀缺资源，框架必须实施有效的策略来管理它。

压缩机制用于处理上下文窗口即将耗尽的情况。若无压缩，一旦对话长度超出窗口限制，轻则导致 API 调用错误，重则致使整个任务崩溃。压缩机制能够智能地卸载并总结已有的上下文内容，从而让智能体得以继续工作。

工具调用卸载解决了大型工具输出污染上下文的问题。对于超过特定长度的工具输出结果，框架仅在上下文中保留其开头和结尾部分，完整内容则被卸载到文件系统中，待需要时再行读取。

**技能（Skills）**机制旨在解决工具过载的问题。如果在智能体启动时就将所有可用工具及其 MCP 服务器描述全部加载进上下文，那么工作尚未开始，宝贵的上下文空间便已被占满。技能通过“渐进式披露”来解决此问题——启动时仅加载简要的元数据，当真正需要使用某个特定工具时，再动态展开其详细描述。

长期自主执行：应对复杂挑战的框架策略

核心需求：使智能体能够在较长的时间跨度内，自主且可靠地完成复杂的多步骤任务。

自主软件开发被视为智能体编程的终极目标之一，但现有模型存在几个固有弱点：容易过早停止任务、难以有效分解复杂问题、在跨越多个上下文窗口时表现不一致。一个优秀的框架必须正面应对这些挑战。

在执行长期任务时，前述的基础“原语”可能变得不够用。此时需要更强大的持久状态管理、任务规划、执行观察与结果验证机制，才能在跨越多个上下文窗口的情况下持续推进任务。

文件系统与 Git 集成被用于跨会话追踪任务进度。长时间运行的任务会消耗大量 Token，文件系统将工作状态持久化保存，使得新加入的智能体或新的上下文窗口能够快速接手。对于多个并行工作的智能体而言，文件系统还充当着共享的“任务账本”。

Ralph 循环用于维持工作的持续性。这是一种特定的工具调用模式：通过框架钩子拦截模型意图“退出”或结束任务的企图，在一个全新的、干净的上下文窗口中重新注入原始任务目标，从而“强迫”智能体继续工作。每次迭代都从一个新的上下文开始，但会读取前一次迭代保存在文件系统中的状态——这使得持续的长期任务成为可能。