前言
本文从 Agent 的本质出发，厘清模型与框架的关系，解释为什么 Harness 不是"零件箱"而是"操作系统"，并横向对比当下主流 Agent 框架的定位与能力差异。
一、什么是 Agent Harness？
2026 年，AI 工程圈被一个看似生僻的词汇点燃了——Agent Harness（智能体驾驭系统）。这个 2026 年初才被正式命名的概念，短短几个月就从学术预印本走进了 OpenAI、Anthropic、Stripe 等公司的核心产品架构。
Anthropic 的官方定义是：
Harness 是"模型运行所依赖的指令集与护栏"——它是持续调用模型并将模型的工具调用路由到对应基础设施的控制循环。
——来源：Anthropic 研究文章《Building trustworthy AI agents》（2026.04）
这个定义可能有些抽象。换一个更直白的比喻：
裸 LLM 就像没有操作系统的 CPU——它只能计算，但靠自己做不了任何有用的事。
你不会对着一颗裸 CPU 说"帮我写个网页"，你需要操作系统来调度资源、管理内存、驱动外设。同样，你不会直接对着一个裸大模型说"帮我完成这个项目"，你需要 Harness 来编排循环、管理上下文、路由工具调用、处理异常。
LangChain 的 Vivek Trivedy 给出了更极端的一刀切：
“如果你不是模型，那你就是 harness。”
三层工程架构：从 Prompt 到 Harness
围绕大模型的工程实践，正在经历一个清晰的演进：
Prompt Engineering 解决"怎么让模型按你的想法思考"，Context Engineering 解决"让模型在正确的时刻看到正确的信息"，而 Harness Engineering 解决的是整个运行时的可靠性——这恰恰是当前最被低估、也最关键的战场。
二、Agent 的本质：模型 + 框架
Agent ≠ 大模型
一个常见的误解是：Agent 就是一个能调用工具的大模型。事实上，Agent 是模型与框架的组合体，缺一不可。
| 组件 | 角色 | 类比 |
|---|---|---|
| Model（模型） | 核心推理引擎，负责理解、规划和生成 | CPU |
| Harness（框架） | 运行控制循环，调用模型并路由工具调用 | 操作系统 |
| Tools（工具） | 代码执行、文件操作、浏览器等外部能力 | 驱动程序/外设 |
| Environment（环境） | Agent 执行所在的系统环境 | 硬件平台 |
这是 Anthropic 提出的Agent 四层架构。模型只是其中一层——提供"算力"的那一层。
模型提供推理，框架提供"运行时"
模型的输出本质上是无状态的：给它一段 prompt，它返回一段文本。它不会记住上一轮做了什么，不会自己决定"下一步该做什么"，更不会在出错时自动重试。
这些"不是推理但至关重要"的能力，全部由框架承担：
- 编排循环：组装 prompt → 调用模型 → 解析输出 → 执行工具 → 反馈结果 → 重复
- 上下文管理：决定每次调用送入哪些信息、裁切哪些信息
- 状态持久化：保存工作进度、对话历史、中间结果
- 错误恢复：检测失败并自动重试或回退
- 安全护栏：限制行为范围，防止危险操作
没有框架的模型，就像没有操作系统的 CPU——有算力，但无法完成任何有意义的任务。
三、为什么模型需要框架？
3.1 编排循环：从"一问一答"到"持续行动"
大模型的原生交互模式是一问一答：用户发一条消息，模型回复一条消息。但真实的生产任务从来不是一步到位的。
以"生成行业报告"为例：检索资料 → 筛选有效信息 → 结构化整理 → 逐章节撰写 → 校验数据 → 格式排版，可能涉及数十步甚至上百步工具调用。
编排循环（Orchestration Loop）就是让模型从"一问一答"变成"持续行动"的核心机制。它实现的是Thought-Action-Observation（TAO）循环：
组装 prompt → 调用 LLM → 解析输出 → 执行工具调用 → 反馈结果 → 重复直到完成Anthropic 把这个循环称为“dumb loop”（笨循环）——循环本身只是机械的 while 循环，所有智能都在模型中，但没有这个笨循环，模型再聪明也走不出第一步。
循环的终止条件通常有三层：
- 模型生成无工具调用的响应（任务完成）
- 达到最大轮数限制（防止死循环）
- Token 预算耗尽 / 护栏触发 / 用户中断（安全兜底）
3.2 上下文腐烂：记忆会随步数增长而衰减
你可能遇到过这样的场景：Agent 在第 50 步时，完全忘记了第 1 步的任务目标。
这不是模型"变笨了"，而是Context Rot（上下文腐烂）——一个已被实证研究验证的现象。斯坦福"Lost in the Middle"研究证实，当关键信息落在上下文窗口的中段时，模型表现下降30%+。即使是百万 token 的窗口，指令遵循能力也会随上下文长度增长而显著衰减。
单纯放大上下文窗口解决不了这个问题：
- 成本飙升：每次调用都要发送越来越长的历史
- 信号稀释：垃圾信息持续堆积，有效信号密度下降
框架需要承担上下文工程的职责：
- 对历史交互做压缩与抽象，把"过程日志"收敛成"关键信念与约束"
- 把中间状态卸载到外部存储（文件、向量库、数据库），只在必要时重新注入
- 按任务阶段选择性注入不同类型的上下文
正如 Anthropic 的设计目标：
找到最小的一组高信号 token，把达到期望结果的概率最大化。
3.3 错误雪崩：每步99%成功率，端到端只有90%
一个残酷的数学事实：
10步流程，每步99%成功率 → 端到端只有90.4%成功率。
50 步呢？只有 60.5%。100 步？不到 37%。
在长流程任务中，错误不是"会不会发生"的问题，而是"什么时候发生、如何恢复"的问题。框架需要提供系统级的错误恢复能力：
| 错误类型 | 处理方式 |
|---|---|
| 瞬时错误（网络抖动、API 超时） | 按退避策略重试 |
| 模型可恢复错误（工具参数错误） | 作为错误结果返回，让模型自行调整 |
| 用户可修复错误（权限不足） | 中断等待人类输入 |
| 不可恢复错误 | 向上冒泡用于调试 |
生产实践中，Stripe 将重试次数上限设为 2 次——不是越多越好，而是在可靠性和延迟之间取平衡。
3.4 安全边界：模型决定"尝试做什么"，框架决定"什么被允许"
大模型可以生成任何文本，包括危险的指令。当 Agent 被赋予文件系统访问、代码执行、网络请求等能力时，安全边界就不再是"锦上添花"，而是必须存在的底线。
Anthropic 的架构分离原则非常清晰：
模型决定尝试做什么，工具系统决定什么被允许。
以 Claude Code 为例，约 40 个离散工具能力独立设卡，采用三阶段安全机制：
- 项目加载时建立信任基线
- 每次调用前执行权限检查
- 高风险操作需用户明确确认
OpenAI 则采用三级护栏架构：输入护栏 → 工具护栏 → 输出护栏，并通过Tripwire 机制在触发时立刻停机。
没有框架的模型是一个没有刹车系统的引擎——动力再强，也不敢让它上路。
四、Harness 不是零件箱，是操作系统
普通 Agent 框架 vs Harness
理解 Harness 的关键，是区分零件箱和操作系统。
| 维度 | 普通 Agent 框架 | Agent Harness |
|---|---|---|
| 角色定位 | 零件集——提供基础原语 | 系统级组件——提供完整运行时 |
| 提供内容 | 工具调用、循环控制等原语 | 内置提示词预设、工具调用策略、生命周期钩子 |
| 开发要求 | 开发者手工搭积木 | 开发者只需关注业务逻辑 |
| 核心能力 | 基础功能模块 | 编排循环、上下文工程、状态持久化、安全护栏、验证循环 |
普通框架给你一箱零件，你自己拼一台机器；Harness 给你一个操作系统，你只需要写应用程序。
Harness 的核心组件
一个完整的 Agent Harness 包含以下七层组件：
| 组件 | 功能 | 操作系统类比 |
|---|---|---|
| 编排循环（Orchestration Loop） | 控制"思考→行动→观察"循环 | 进程调度 |
| 工具管理（Tool Management） | 注册、校验、执行工具，管理工具白名单 | 驱动程序管理 |
| 上下文工程（Context Engineering） | 决定每次调用送入哪些信息、裁切哪些信息 | 内存管理 |
| 状态持久化（State Persistence） | 保存工作进度、对话历史、中间结果 | 文件系统 |
| 错误恢复（Error Recovery） | 检测失败并自动重试或回退 | 异常处理 |
| 安全护栏（Safety Guardrails） | 限制行为范围，防止危险操作 | 防火墙/权限控制 |
| 验证循环（Verification Loops） | 让 Agent 自我检查输出质量 | 单元测试 |
这个类比并非修辞——两者的职责几乎一一对应。操作系统的存在让应用程序开发者不需要关心内存分配和硬件驱动；Harness 的存在让 Agent 开发者不需要自己实现循环控制、上下文压缩和错误重试。
正如 Claude Code 作者 Boris Cherny 所说：
给模型一个自我验证的办法，质量能提升 2 到 3 倍。
这不是模型能力的提升，而是框架能力的价值。
五、主流 Agent Framework 横向对比
理解了 Harness 的概念，我们来看看当下主流框架各自的定位和 Harness 能力覆盖。
LangChain / LangGraph
LangChain 是当前生态最庞大的 LLM 应用框架（GitHub Stars 95k+，截至2026.04）。它将 LLM、向量存储、工具和内存连接成可组合的链（Chains）。
- LangGraph构建在 LangChain 之上，支持有状态、循环的智能体工作流，更像一个可验证的状态机
- LangSmith提供可观测性和追踪
- RAG 流水线是业界最佳实践
但 LangChain 的抽象层可能掩盖实际执行过程，简单任务容易过度工程化。它更像一个零件丰富的工具箱——你能用这些零件搭出任何东西，但你需要自己搭。
OpenAI Agents SDK
OpenAI 在 2026 年 4 月发布的轻量级 Python 框架，是此前 Swarm 项目的生产就绪升级版。
核心特性：
- 可配置 Harness：支持自定义编排循环
- 原生沙箱集成：与 E2B、Modal、Daytona 等沙箱供应商对接
- 三级护栏：输入护栏 → 工具护栏 → 输出护栏
- Handoffs 机制：Agent 间移交控制权
- Agents-as-tools：专家 Agent 处理受限子任务
OpenAI Agents SDK 的设计哲学是薄而通用——提供最小必要的 Harness 原语，不过度封装。
AutoGen
微软研究院的对话式多智能体框架（GitHub Stars 40k+，截至2026.04）。
- 智能体之间通过对话来解决问题
- AutoGen Studio提供可视化 UI
- 代码生成和审查场景表现优异（写代码→审核→循环直到解决）
- 微软企业级支持
AutoGen 的强项是对话式协作，但对非对话场景可能显得冗余。
CrewAI
专注于多智能体角色协作的框架（GitHub Stars 28k+，截至2026.04）。
- 核心概念：定义 Agent → 分配 Task → 创建 Crew
- 角色分工清晰：研究 Agent、写作 Agent、审核 Agent 各司其职
- 构建在 LangChain 之上，兼容其工具生态
fromcrewaiimportAgent,Task,Crew researcher=Agent(role="Researcher",goal="Find top AI tools",backstory="...")writer=Agent(role="Writer",goal="Write a summary",backstory="...")task1=Task(description="Research top 10 AI agent frameworks",agent=researcher)task2=Task(description="Write a blog post based on research",agent=writer)crew=Crew(agents=[researcher,writer],tasks=[task1,task2])crew.kickoff()CrewAI 在多智能体场景代码更简洁，但非多智能体用例灵活性较差。
Claude Code：最成熟的 Harness 实现
Anthropic 工程博客明确将Claude Code 描述为"an excellent harness"，它是目前开源生态中最成熟的 Harness 实现之一：
- 六类工具：文件操作、搜索、执行、Web 访问、代码智能、子 Agent 派生
- 三层记忆：轻量级索引（永远加载）→ 详细主题文件（按需加载）→ 原始 transcript（搜索时加载）
- 上下文压缩：接近上限时总结对话历史，保留架构决策和未解决 bug，丢弃冗余工具输出
- 验证循环：修改代码后自动跑测试，失败则分析错误并重试
- 子 Agent 编排：Fork（父上下文字节级副本）、Teammate（独立终端，基于文件通信）、Worktree（独立 git 工作树）三种执行模型
各框架 Harness 能力对比
| 能力 | LangChain/LangGraph | OpenAI Agents SDK | AutoGen | CrewAI | Claude Code |
|---|---|---|---|---|---|
| 编排循环 | ✅ LangGraph 状态机 | ✅ 可配置循环 | ✅ 对话循环 | ✅ Crew 调度 | ✅ TAO 循环 |
| 工具管理 | ✅ 100+ 集成 | ✅ 原生+托管+MCP | ✅ 函数调用 | ✅ LangChain 兼容 | ✅ 六类工具 |
| 上下文工程 | ⚠️ 需手动管理 | ⚠️ 四种策略可选 | ⚠️ 较弱 | ⚠️ 较弱 | ✅ 自动压缩 |
| 状态持久化 | ✅ Checkpoint | ✅ Session API | ⚠️ 有限 | ⚠️ 有限 | ✅ Git+文件 |
| 错误恢复 | ✅ 四类错误处理 | ✅ 重试+降级 | ⚠️ 基础 | ⚠️ 基础 | ✅ 自动修复 |
| 安全护栏 | ⚠️ 需自建 | ✅ 三级护栏 | ⚠️ 需自建 | ⚠️ 需自建 | ✅ 40 工具设卡 |
| 验证循环 | ⚠️ 需自建 | ⚠️ 需自建 | ⚠️ 需自建 | ⚠️ 需自建 | ✅ 自动测试 |
| Harness 完整度 | 中 | 中高 | 中 | 中低 | 高 |
从表中可以看出，Claude Code 是当前 Harness 能力最完整的实现，而大多数通用框架在上下文工程、安全护栏、验证循环等"系统能力"上仍需开发者自行补齐。这恰恰说明了框架（零件箱）和 Harness（操作系统）之间的差距。
六、Harness Engineering：2026 年的核心战场
三层工程架构的演进
回顾过去三年 AI 工程领域的焦点转移：
- 2023 年：Prompt Engineering 是主流——怎么写好指令，让模型按你的想法思考
- 2025 年：Context Engineering 浮出水面——模型变强了，关键不再是"怎么想"，而是"看到什么"
- 2026 年：Harness Engineering 成为焦点——上下文也管理好了，但在长流程任务中系统仍然不稳定
每一次焦点的转移，都是因为上一个层面的问题被基本解决后，下一个更深层的问题暴露出来。而 Harness Engineering 之所以成为 2026 年的核心战场，是因为它回答了一个被长期忽视的问题：
同一模型，在不同产品里表现天差地远——差异不在模型，在 Harness。
TerminalBench 的评测数据提供了有力证据：只改 Harness 不改模型，就能在榜单上移动 20+ 位。
两种控制模式：Feedforward 与 Feedback
Martin Fowler 在技术博客中分析了 Harness 的两种控制机制：
Feedforward（前馈控制）——在 Agent 行动前设好规则，预防不想要的输出：
- System prompt 中的行为准则
- 工具白名单
- 文件访问权限
- 输入护栏
Feedback（反馈控制）——在 Agent 行动后检查结果，允许自我修正：
- 执行测试确认代码正确
- 比对输出与预期格式
- 检测幻觉并重新生成
- 输出护栏
关键结论：好的 Harness 同时使用两种控制——既限制行为范围，又保留灵活性。
只用 Feedforward，系统太僵化，模型能力被过度约束；只用 Feedback，系统太松散，错误无法及时拦截。两种模式的平衡，正是 Harness Engineering 的核心艺术。
知乎上一篇文章说得好：
Harness Engineering 的核心技能栈
如果 Harness Engineering 是新战场，那么工程师需要掌握什么？
| 技能维度 | 具体能力 |
|---|---|
| 编排设计 | 单/多 Agent 决策、ReAct vs Plan-and-Execute 策略选择、子 Agent 委派 |
| 上下文工程 | 压缩策略、JIT 检索、观察遮蔽、子 Agent 浓缩 |
| 工具设计 | 最小工具集原则、只读并发/写操作串行、Schema 设计 |
| 安全设计 | Feedforward + Feedback 双控、权限分级、Tripwire 机制 |
| 可观测性 | 结构化日志、全链路追踪、失败案例归档 |
| 演化设计 | 版本化模型假设、定期复审补偿逻辑、为删除而设计 |
其中最后一条——“为删除而设计”——可能是最重要的。Harness 会编码关于"模型做不到什么"的假设，而这些假设会随模型迭代变得过时。
典型案例：Claude Sonnet 4.5 时代，模型接近上下文窗口上限时表现出"上下文焦虑"，Harness 中实现了上下文重置逻辑；到了 Opus 4.5 时代，更强的模型不再有此问题，但重置逻辑成了冗余代码，甚至干扰模型判断。
随着模型变强，Harness 应该变薄——这才是健康的演化方向。
七、总结与展望
核心要点回顾
| 概念 | 定义 |
|---|---|
| Agent | 模型 + 框架的组合体，具备自主决策能力的智能执行者 |
| Agent Framework | 开发工具库，提供构建 Agent 的基础组件——是零件箱 |
| Agent Harness | 控制系统，确保 Agent 稳定、可靠地长期运行——是操作系统 |
三者的关系：
- 模型解决"能不能推理"
- 框架解决"如何快速开发"
- Harness解决"如何稳定运行"
未来展望
AI 行业的竞争焦点正在发生根本性转移：
| 维度 | 过去 | 未来 |
|---|---|---|
| 瓶颈 | 模型能力 | 上下文耐久性、长流程稳定性 |
| 竞争焦点 | “谁的 prompt 更玄学” | “谁拥有更好的 Harness 架构” |
| 护城河 | 模型参数 | 长流程执行轨迹数据资产 |
忽视 Agent Harness，就等于忽视长流程这个真正的战场；而只盯着模型跑分、沉迷于单轮对话效果的团队，终究会在新一轮迭代中失去话语权。
现在就可以做的事
- 别再一头扎进"提示词魔法"里——把注意力转到：你的系统能否稳定跑完一个长时间的真实任务？
- 为你的 Agent 加一层最小的 Harness——日志、状态、失败记录，哪怕只有这三样也值得
- 所有新功能都问自己一句——这东西，未来如果模型变强，我能不能轻松删掉？
- 把 Harness 视作核心产品——它是连接顶级模型与真实业务的桥梁
参考资料：
- Anthropic《Building trustworthy AI agents》(2026.04)
- Martin Fowler - Agent Control Patterns (Feedforward/Feedback)
- LangChain - Agent Harness 定义 (Vivek Trivedy)
- TerminalBench 评测数据
- 斯坦福《Lost in the Middle》研究
本文首发于 CSDN，作者：Kingwu
