Agent Harness：真正决定 AI Agent 上限的，不是模型，而是执行底座

如果说大模型是大脑，那么 Agent Harness 就是神经系统、四肢、工作台、安全带和操作规程的总和。

过去两年，很多团队都以为把一个更强的模型接上几个工具，一个 AI Agent 就做出来了。结果往往是：演示很惊艳，上线就失控；短任务很顺，长任务就漂移；写得出第一版，跑不完最后一公里。问题不全在模型，更多时候出在模型外面那一层系统设计，也就是今天越来越多人开始强调的 Agent Harness。

截至 2026 年 4 月 25 日，这个词还不是像数据库、操作系统那样定义完全统一的标准术语，但几家一线公司已经给出了高度收敛的理解。

• LangChain 在 2026 年 3 月 10 日把它概括成一句非常干脆的话：Agent = Model + Harness
• Microsoft 在 2026 年 3 月 12 日把 harness 定义为“模型推理连接真实执行的那一层”，具体包括 shell、文件系统、审批流和长会话上下文管理
• Anthropic 从 2025 年 11 月 26 日到 2026 年 4 月 8 日连续几篇工程文章都在讲同一件事：长时任务、上下文切换、安全隔离、恢复机制、多 agent 协作，这些真正决定 agent 能不能落地，而这些东西都属于 harness，不属于模型本身

所以，理解 Agent Harness，先要丢掉一个误解：Agent 不是“会调用工具的大模型”，而是“被一整套运行机制包起来、能够持续完成工作的模型”。模型负责生成下一步判断，harness 负责让这个判断变成受控、可验证、可恢复、可持续的行动。没有 harness，模型只有语言能力；有了 harness，模型才开始具备工作能力。

很多人第一次听到 harness，会把它理解成“工具调用框架”或者“agent SDK”。这两个理解都不够。框架只是你搭东西的积木，harness 是积木搭出来之后，真正承载 agent 运行的执行外壳。它不只是告诉模型“你可以调用什么工具”，而是定义：

• 什么时候调用
• 调用完结果怎么进入上下文
• 失败如何重试
• 输出如何落盘
• 权限怎么审批
• 上下文太长怎么办
• 子任务何时拆分
• 另一个 agent 如何接棒
• 任务中断后如何恢复
• 敏感凭证如何隔离

换句话说，framework 更像开发工具，harness 更像生产运行时。

这也是为什么今天大家会越来越频繁地说：模型能力在上升，但 agent 成败的瓶颈正在外移。以前大家争论的是模型够不够聪明，现在大家发现另一个事实：再聪明的模型，如果放进一个糟糕的 harness，也只会稳定地产生混乱。它可能知道该做什么，却拿不到正确上下文；可能拿得到工具，却没有执行边界；可能能持续工作，却被冗长历史拖垮；可能能写代码，却无法验证自己有没有真的修好；可能能操作环境，却顺手把密钥也读出来。你以为你在做“AI 能力问题”，最后发现你在做的是“系统工程问题”。

Agent Harness 到底是什么

一个更精确的定义是：Agent Harness 是模型之外，所有让智能体能够安全、持续、可验证、可恢复地完成真实工作的工程机制总和。

这个定义有三个关键词。

第一个关键词是“模型之外”。只要不是模型本身的参数和推理能力，而是围绕模型搭建的代码、配置、运行环境、控制逻辑，都可以被放进 harness 的范畴。

第二个关键词是“真实工作”。如果一个系统只能在演示里回答几个问题，不能在文件系统里读写、不能调工具、不能跨会话持续推进、不能被审计和恢复，那它还不能叫成熟的 agent。

第三个关键词是“工程机制总和”。Harness 从来不是单个组件，不是一套提示词，也不是一个 SDK。它是一整层系统设计。

所以最短的说法其实可以是：Agent Harness 是把“大模型会说”变成“智能体会做”的那整套系统。

为什么它会突然变重要

因为模型的短板变了。

早期大家最头疼的是模型不够聪明，连基本理解和生成都不稳定。现在模型的推理、代码、工具使用能力都已经强到足以跑出很多惊艳 demo。瓶颈开始转移到另一个地方：如何让这些能力在复杂环境里稳定发挥。

一旦任务拉长到几十分钟、几小时，甚至跨越多个上下文窗口，问题就会集中爆发：

• 历史太长，模型开始遗忘重点
• 工具输出太多，上下文被噪音淹没
• 任务做了一半，下一轮接不上
• 模型误以为差不多做完了，提前结束
• 改了代码，却没有验证是否真的可用
• 运行环境里混着凭证和敏感信息，安全风险陡增

这些问题里，几乎没有一个是“换个更强模型”就能彻底解决的。它们都更接近工程设计问题，而不是单纯的模型能力问题。

Anthropic 在长时 agent 的实践里讲得很直白：仅靠 compaction 并不足以支撑真正的长周期任务。你还需要任务分解、结构化交接、持续验证、清晰的状态留痕，以及在必要时重置上下文、重新起一个干净的 agent 实例继续干活。这里的关键已经不是“模型够不够聪明”，而是“系统怎么让聪明持续发生”。

一个成熟的 Agent Harness 至少要解决什么

一个成熟的 Agent Harness，至少要回答下面八个问题。

1. 基本执行循环怎么跑

大模型不是天然的进程，它每次调用都只是一次“输入到输出”的推理。要让它像 agent 一样连续工作，必须有外层循环把“观察、思考、行动、再观察”串起来。

最常见的是 ReAct 式循环，但真正的 harness 不会停在一个 while loop。它要决定：

• 什么时候继续
• 什么时候停止
• 什么时候触发人工介入
• 什么时候切子任务
• 什么时候把结果交给另一个 agent

Anthropic 在做长时 coding agent 时，引入 initializer、planner、generator、evaluator 这类角色分工，本质上都是 harness 在替模型补足流程结构。

2. Agent 到底在哪里工作

一个能写代码的 agent，如果没有文件系统、shell、浏览器、测试环境，它只是会描述怎么写代码，而不是真的在写。

LangChain 把文件系统称为最基础的 harness primitive，不是没有道理。因为一旦 agent 有了 workspace，它才能把中间结果写下来，才能跨轮次延续状态，才能让多个 agent 与人类围绕共享文件协作。

再往前一步，shell 和代码执行让 agent 拿到“通用工具”，不再要求人类提前把所有能力都做成专门 API。于是 agent 才真正像一个拿到电脑的员工，而不是一个只会聊天的助手。

3. 上下文怎么管理

这是 agent 从 demo 走向生产时最容易撞墙的地方。

短任务里，上下文像免费的；长任务里，上下文是最稀缺的资源。历史太长，模型会退化、跑偏、提前收工，甚至因为“感觉快到上下文极限了”而焦虑式结束任务。

所以好的 harness 不只是做 token 压缩，而是做“任务状态提纯”：

• 哪些历史可以总结
• 哪些工具输出应该被裁剪或落盘
• 哪些阶段性结论必须保留下来
• 什么时候应该直接重置上下文，让新 agent 接棒

Microsoft 把 compaction 做成了 Agent Framework 的内建能力。Anthropic 则进一步强调，真正关键的是结构化 handoff，也就是把上一轮成果、未完成事项和下一步计划显式留下来，让新的 agent 实例能顺利接班。

4. 怎么验证 agent 不是在一本正经地胡来

一个没有验证回路的 agent，永远只能叫“会尝试的 agent”，不能叫“能交付的 agent”。

所以 harness 必须设计观察和验收机制：

• 测试
• 日志
• 浏览器结果
• 截图
• diff
• linter
• 外部 API 返回
• 人工 review 点

这些不只是工具，它们构成了 agent 的反馈系统。生成只是第一步，验证才决定 agent 能不能形成闭环。

Anthropic 在 2026 年 3 月写前端和长时开发 harness 时，把 evaluator 单独拉出来，本质就是承认一件事：生成和评估最好分离，甚至应该由不同 agent 或不同阶段完成。

5. 权限和安全边界怎么划

这部分经常被创业团队低估，直到第一次 prompt injection、误删数据、越权访问、密钥泄露出现。

Microsoft 在 agent harness 的例子里把审批流放在最前面，不是偶然。Anthropic 在 2026 年 4 月 8 日更进一步，明确提出要把 brain、session、sandbox 分离，并强调结构性修复应该是“让 token 根本不可达”，而不是只靠提示词告诉模型“别去读密钥”。

这句话非常重要，因为它揭示了 harness 和 prompt engineering 的根本区别：

• prompt 是请求模型自律
• harness 是通过系统设计让越界变难甚至不可能

真正的工程能力，永远优先选择后者。

6. 状态如何持久化，任务如何恢复

很多人做 agent 还停留在“单轮对话增强版”的阶段，一旦进程挂了，任务就死了；一旦容器挂了，历史就没了。

Anthropic 在 Managed Agents 的架构讨论里把 session、harness、sandbox 明确拆开，就是为了让 harness 崩了还能靠 session log 恢复，让 sandbox 死了能被当作一次普通工具失败处理。

这里你会发现，agent 系统开始越来越像分布式系统：

• 事件日志
• 状态恢复
• 失败重放
• 无状态执行层
• 可替换执行端

这些都不是传统 prompt 工程的范畴，而是典型的系统设计问题。

7. 多 agent 到底是不是刚需

很多团队一上来就搞 agent swarm，最后只是把单 agent 的混乱复制成多 agent 的混乱。

多 agent 不是目的，harness 才是决定多 agent 有无价值的前提。只有当共享状态、任务拆分、交接协议、上下文隔离、结果汇总、冲突处理这些机制成熟以后，多 agent 才会带来并行收益。否则它只是在加倍制造噪声。

Anthropic 的 planner-generator-evaluator，或者 LangChain 讨论的 subagents，本质上都不是“人多力量大”，而是“把不同类型的认知负担分开，减少单个上下文的拥塞”。

8. Harness 该有多复杂

这是最容易走偏的一点。因为一旦意识到 harness 很重要，工程师往往会本能地给它堆功能：更多 hook、更多规则、更多阶段、更多 agent、更多 memory、更多中间件。

问题在于，harness 的每一个组件，其实都编码了一个假设：模型自己做不好这件事，所以我要替它做。

Anthropic 在 2026 年 3 月 24 日和 2026 年 4 月 8 日都反复强调同一个原则：这些假设会随着模型进步而过时，必须不断被质疑。某个版本的模型需要 context reset，下一个版本可能就不需要；某个验证器能显著提效，另一个任务里可能只是拖慢成本。

好的 harness 不是“越重越强”，而是“只保留真正承重的结构”。

Agent Harness 和框架、工作流、Agent 平台到底什么关系

这是最容易混淆的一层。

Framework 是开发工具，解决的是“怎么搭”。

Workflow 是任务流程，解决的是“按什么顺序跑”。

Agent Platform 是产品化交付层，解决的是“怎么给团队和业务使用”。

而 Harness 是运行时执行底座，解决的是“模型如何在真实环境中稳定工作”。

所以一个团队完全可能：

• 用 LangGraph、Agent Framework 或自研框架来搭 agent
• 用一套内部 workflow 编排业务流程
• 再把它包进一个企业产品界面里
• 但真正决定它能不能稳定落地的，仍然是底层 harness 设计

这也是为什么很多“看起来像 agent 平台”的产品，实际上只做了最表面的一层：给你一个对话框和几个工具按钮，但没有真正的 long-running execution，没有状态恢复，没有审批，没有隔离，没有验证，没有交接。那不叫 harness，只能叫增强版聊天工具。

如果你要自己搭一个 Agent Harness，最务实的路线是什么

最务实的路线不是先追求“全功能”，而是按风险和收益排序。

第一步，先把 workspace、shell、日志、文件写入、基础工具循环搭起来。

第二步，做 context compaction 和结构化 handoff。

第三步，加验证回路，让 agent 能自己跑测试、看日志、查结果。

第四步，再加审批、权限和密钥隔离。

第五步，最后才考虑多 agent 并行。

顺序错了，通常会死得很快。因为你最先遇到的不是“模型不够聪明”，而是：

• 任务跑不稳
• 状态接不住
• 错误不可见
• 成本不可控

这几个问题不解决，后面所有“高级能力”都会沦为表演性质的复杂度。

为什么说它代表了 AI 工程范式的迁移

Agent Harness 的兴起，标志着 AI 工程范式的一次迁移。

过去我们说“软件吞噬世界”，后来是“模型吞噬接口”，而现在变成了“系统设计重新成为核心竞争力”。模型当然重要，但模型越来越像一种通用智力引擎。真正拉开差距的，是你围绕它搭建的工作机制：

• 怎么给它任务
• 怎么给它工具
• 怎么限制它
• 怎么帮它记
• 怎么替它验
• 怎么让它接着干
• 怎么在出错时救回来

换句话说，未来 agent 公司的护城河，不只是谁接入了最强模型，更是谁做出了最强 harness。

结语

所以，什么是 Agent Harness？

最短的答案是：它是把“大模型会说”变成“智能体会做”的那整套系统。

更完整一点的答案是：它是模型之外，所有让 agent 能够安全、持续、可验证、可恢复地完成真实工作的工程机制总和。它既是 agent 的执行壳层，也是 agent 的行为约束器、上下文调度器、权限边界、记忆载体、验证回路和恢复系统。

没有它，agent 只是一个概率分布；有了它，agent 才可能成为生产力。

今天讨论 agent，如果还只盯着模型排名，已经有点落后了。真正的问题已经变成：你的 agent 被什么样的 harness 驾驭，它能不能在复杂环境里跑足够久，能不能在风险边界内调用足够多的能力，能不能在失败之后继续推进，能不能把一次聪明变成持续可靠。

谁先把这个问题想清楚，谁才更接近真正可用的 agent。

参考资料

• LangChain, *The Anatomy of an Agent Harness*, 2026-03-10
• Microsoft Agent Framework, *Agent Harness in Agent Framework*, 2026-03-12
• Anthropic, *Effective harnesses for long-running agents*, 2025-11-26
• Anthropic, *Harness design for long-running application development*, 2026-03-24
• Anthropic, *Scaling Managed Agents: Decoupling the brain from the hands*, 2026-04-08

配图清单

00-cover.png

位置：

frontmatter（文章封面）

比例要求：

21:9 或 2:1，至少 1600×900

用途：

封面图 / 分享卡片

类型：

概念插画

主题：

"模型是大脑，harness 是让大脑能做事的整套系统"——这篇文章最核心的一句话隐喻。

画面描述：

• 主体对象：一个悬浮发光的抽象大脑/神经元结构（代表模型），周围被一套精密的机械骨架、管线、支撑臂环绕包裹（代表 harness）
• 空间关系：大脑居中偏上，机械结构从四周向内支撑、连接，形成"被托举/被驱动"的视觉关系，而不是"被困住"
• 动作：机械结构的某几个关节/管线正在传导能量或信号到大脑，暗示协作而非控制
• 情绪：精密、克制、有工程感，不浮夸
• 视觉隐喻：大脑单独存在时只是悬浮发光（有能力但无法行动），被 harness 包裹后才具备"手脚"能真正触及外部世界
• 重要元素：机械结构不宜过于科幻/赛博朋克，偏向"精密仪器/工业设计图纸"质感，呼应文章"系统工程"基调

构图要求：

• 主体位置：居中
• 留白区域：四周留白，避免关键结构被裁剪（会在文章页、发现页卡片、OG 分享图三处裁切）
• 横向还是纵向：横向

不要出现：

• UI截图
• 复杂信息
• 文字

01-model-vs-harness.png

位置：

文章开头，"没有 harness，模型只有语言能力"段落后

比例要求：

4:3

用途：

正文

类型：

概念插画

主题：

对比"孤立的模型"与"被 harness 支撑的模型"两种状态。

画面描述：

• 主体对象：左侧一个孤立悬浮的发光大脑，右侧同样的大脑被机械外骨骼/支撑结构包裹并连接到"手""工具""环境"
• 空间关系：左右分屏对比，左侧空旷、右侧充实
• 动作：右侧的机械结构正在把大脑的"判断"传导为具体动作（如伸出机械臂触碰一个物体/文件图标）
• 情绪：左侧克制孤立，右侧有行动力
• 视觉隐喻：语言能力 vs 工作能力的分界
• 重要元素：两侧需标注简短文字标签"模型"/"模型 + Harness"，因为这是概念对比图，靠画面本身不足以让读者分辨

构图要求：

• 主体位置：左右对称分布
• 留白区域：中间留一条分割线/留白
• 横向还是纵向：横向

不要出现：

• UI截图
• 复杂信息

02-eight-questions.png

位置：

"一个成熟的 Agent Harness 至少要解决什么"章节开头

比例要求：

16:9

用途：

正文（流程图/枢纽图）

类型：

流程图

主题：

Harness 需要回答的八个核心问题，围绕模型形成一张系统设计的全景图。

画面描述：

• 主体对象：中心是一个抽象模型图标，八条分支线向外辐射，连接到八个简单图标：执行循环（循环箭头）、工作空间（文件夹/终端）、上下文（书本/沙漏）、验证（对勾/放大镜）、安全边界（锁）、状态持久化（磁盘/存档）、多 agent（多个节点连接）、复杂度控制（天平）
• 空间关系：中心枢纽 + 八个外围节点，呈放射状
• 动作：无明显动作，重在结构清晰
• 情绪：系统性、工程感
• 视觉隐喻：模型只是核心，真正的能力分布在外围八个机制上
• 重要元素：八个节点必须各自标注简短文字标签（如"执行循环""工作空间"等），否则读者无法区分每个图标对应的具体问题

构图要求：

• 主体位置：模型居中
• 留白区域：八个节点之间留白均匀，避免拥挤
• 横向还是纵向：横向

不要出现：

• UI截图
• 复杂信息（每个节点保持单一图标，不要堆砌细节）

03-prompt-vs-harness.png

位置：

"权限和安全边界怎么划"章节末尾，"真正的工程能力，永远优先选择后者"段落后

比例要求：

4:3

用途：

正文

类型：

概念插画

主题：

"靠提示词请求模型自律" vs "靠系统设计让越界不可能" 两种安全思路的对比。

画面描述：

• 主体对象：左侧一扇门敞开着，门前贴着一张写字条（象征"提示词请求"），一个抽象人形/机器人图标站在门口犹豫；右侧同一扇门被物理焊死/加了实体锁链
• 空间关系：左右分屏对比
• 动作：左侧的字条在风中轻轻晃动（暗示脆弱、不可靠），右侧锁链纹丝不动
• 情绪：左侧不安、悬而未决；右侧笃定、安全
• 视觉隐喻：请求 vs 结构性阻断
• 重要元素：需要文字标签标注"Prompt：请求"和"Harness：结构性阻断"，否则读者无法分辨两侧分别代表什么策略

构图要求：

• 主体位置：左右对称
• 留白区域：中间分割留白
• 横向还是纵向：横向（但比例上偏方形以适配正文列宽）

不要出现：

• UI截图
• 复杂信息

04-layers-diagram.png

位置：

"Agent Harness 和框架、工作流、Agent 平台到底什么关系"章节末尾

比例要求：

16:9

用途：

正文（流程图/分层图）

类型：

流程图

主题：

Harness、Framework、Workflow、Agent Platform 四者的分层关系——底层不稳，上层都是表演。

画面描述：

• 主体对象：一个自下而上的四层结构图，最底层是坚实的地基（Harness / 执行底座），往上依次是 Framework（脚手架/积木）、Workflow（流程箭头）、最顶层是 Agent Platform（一个漂亮的产品界面窗口）
• 空间关系：金字塔式堆叠，越往上越"轻"、越往下越"承重"
• 动作：无
• 情绪：稳固、有工程秩序感
• 视觉隐喻：只有底座稳固，上层的产品界面才不会是"空中楼阁"
• 重要元素：四层必须逐一标注文字标签（Harness / Framework / Workflow / Agent Platform），否则读者无法分辨堆叠顺序代表什么

构图要求：

• 主体位置：居中，纵向堆叠
• 留白区域：顶部和底部留白
• 横向还是纵向：整体画布横向，内部结构纵向堆叠

不要出现：

• UI截图（顶层的"产品界面"用抽象窗口图形示意即可，不要画真实UI）
• 复杂信息