如果说大模型是大脑，那么 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