Agent Harness 到底是什么？一篇让小白也能看懂的万字入门

TL;DR

🧠 AI Agent 不等于大模型。大模型只是"大脑"，Agent 是能干活的"虚拟员工"
🔧 Agent Harness 是包在 Agent 外面的"操作系统"——让 Agent 跑得稳、摔了能爬起来、不会乱砸东西
🏭 2026 年的竞争焦点已经从"谁的模型更聪明"转移到"谁的 Harness 更靠谱"
🎯 微软、Anthropic、Google、字节、阿里都在做 Harness，路线不同但目标一样：让 Agent 在真实环境中能用

先讲个故事

你雇了一个天才实习生。

智商 180，什么问题都能回答，代码写得飞快。但问题来了——你让他独立完成一个需要三天的项目，结果：

第一天干到一半电脑蓝屏，他忘了保存，第二天从头来
你让他跑个数据脚本，他一不小心把测试数据库删了
到第三天他已经忘了第一天你跟他说的需求细节，写出来的东西完全跑偏
遇到敏感操作（比如给客户发邮件），他也不问你一声就直接发了

聪明吗？绝对聪明。能独立干活吗？不能。

大模型就是这个天才实习生。 推理能力惊人，但没有人在旁边"看着"，它就会出各种幺蛾子。

Agent Harness 就是给这个天才实习生配的"工作管理系统"——帮他保存进度、限制权限、提醒他别忘了之前的安排、遇到敏感操作先让你批准。

这就是今天要讲的全部内容。

一、先把几个容易混淆的概念掰清楚

Agent 圈子里有四个词经常混在一起说，很多文章也不区分。我用一张表拎清楚：

概念
它是什么
类比

LLM（大模型）
原始推理能力
人的大脑

Agent Framework
用来组装 Agent 的工具箱
搭积木用的乐高零件

Agent
能自主完成任务的虚拟员工
一个会用各种工具的人

Agent Harness
让 Agent 在生产环境中可靠运行的基础设施
操作系统

换一种方式理解。把计算机体系结构搬过来：

┌─────────────────────────────────────────┐
│   你的业务 App（Agent 做的具体事情）       │  ← Agent
├─────────────────────────────────────────┤
│   操作系统（调度、安全、恢复、监控）        │  ← Agent Harness
├─────────────────────────────────────────┤
│   CPU（算力）     │   RAM（临时记忆）      │  ← LLM + Context Window
└─────────────────────────────────────────┘

Framework 是"造"的阶段用的——LangChain、CrewAI、Semantic Kernel，它们提供组件，帮你搭出一个 Agent。

Harness 是"跑"的阶段用的——Agent 造好之后，得有个环境让它稳定运行。状态管理、安全隔离、上下文维护、人工审批，这些都是 Harness 的活儿。

一个不严谨但直觉正确的类比：Framework 之于 Harness，就像 React 之于 Kubernetes。React 帮你"造"应用，Kubernetes 帮你"跑"应用。造和跑是两件事。

二、为什么现在突然火了？

一个词：生产化。

2024-2025 年，大家的玩法是"给 LLM 接几个工具，写个 prompt，嗯这就是我的 Agent 了"。在 Demo 里效果不错。但一上真实业务，全是坑：

坑 1：一出错就全部白干。 Agent 跑了 20 分钟，中间网络抖动了一下，整个任务从头来。因为没有存档点。

坑 2：跑着跑着就"忘事"了。 大模型的上下文窗口就像人的短期记忆。对话超过 50 轮，早期的关键信息会被"挤掉"。Agent 开始偏离最初的目标，做着做着就不知道自己在干嘛了。业内管这叫上下文腐烂（Context Rot）。

坑 3：工具调用没人管，出了事没法追。 你让 Agent 帮你操作数据库，它直接 DROP TABLE。你让它发邮件，它给客户发了一封语无伦次的催款函。没有权限检查，没有审批流，没有审计日志。

坑 4：Token 烧钱烧到心痛。 每次都把所有工具的完整文档塞进上下文，哪怕这次根本用不到。128K 的上下文窗口，八成被无用信息占了。

这些问题有个共同特点：跟模型的智商无关。 GPT-5 也好，Claude 4 也好，模型再聪明也解决不了"中间崩了怎么恢复"的问题。因为这不是推理问题，是系统工程问题。

Agent Harness 就是来解决这类系统工程问题的。

有篇 Medium 文章标题特别到位："The Agent Harness Is the Architecture (and Your Model Is Not the Bottleneck)"——Harness 才是架构的核心，模型不是瓶颈。

三、Harness 到底管什么？五个核心能力

一个生产级的 Agent Harness 需要解决五类问题。我一个一个说。

3.1 状态持久化——"随时存档，挂了能接着来"

大模型的上下文窗口是易失性的。对话结束，记忆消失。这就像你用记事本写了一万字，电脑关机后全没了。

Harness 的做法是提供一个持久化的工作空间。Agent 在执行任务的过程中，所有中间产物——写了什么代码、改了什么文件、做到哪一步——都存在文件系统或数据库里。

如果中间出了错，不需要从头来。Harness 读取最后一个存档点，告诉 Agent "你上次做到这里了，继续"。

Anthropic 的做法： Claude Code 的 Harness 用 Git 做状态管理。每完成一个子任务就提交一次。出错了？git reset 回上一个干净状态，重新来。

AWS 的做法： AgentCore 给每个用户会话分配独立的微虚拟机（microVM），CPU、内存、文件系统完全隔离，最长支持 8 小时连续任务，中间状态全部持久化。

3.2 上下文管理——"防止天才实习生忘事"

上下文腐烂是 Agent 的头号杀手。随着对话越来越长，噪声积累，有用信息被淹没。Harness 用三个策略对抗：

压缩（Compaction）： 定期把历史对话"浓缩"成要点摘要，扔掉废话。就像你做会议记录——不是逐字记录，而是只保留结论和行动项。

按需注入（Dynamic Injection）： 不是一次性把所有资料塞给 Agent，而是根据当前任务，用 RAG 技术实时检索相关文档片段注入上下文。就像你查字典——遇到不认识的字才翻，不会把整本字典背下来。

工具输出卸载（Offloading）： Agent 调用一个工具，返回了 5 万行日志。直接塞进上下文？窗口炸了。Harness 的做法是把原始输出存到文件系统，只把摘要、关键行号或者链接给 Agent。Agent 需要细节时再去查。

微软的实现： Agent Framework 提供了 SlidingWindow（滑动窗口）和 ToolResultCompaction（工具结果压缩）两种策略，开发者可以按需选择。

3.3 安全与隔离——"别让实习生碰核按钮"

Agent 要干活，就得有工具——能执行代码、能操作文件、能调 API、能访问数据库。但这些能力如果不加限制，后果很严重。

Harness 在工具执行这一步加了一道策略门禁：

Agent 想调用一个工具
       ↓
Harness 检查策略：允许 / 拒绝 / 需要人工审批
       ↓
如果允许 → 在沙箱里执行，限制网络和文件权限
       ↓
执行结果先做 PII 脱敏，再返回给 Agent
       ↓
全程写审计日志

Salesforce 的做法： Agentforce 内置了五步工具执行验证——请求拦截、权限核验、受控执行、结果脱敏、反馈路由。每个环节都有日志。

Google 的做法： Vertex AI Agent Engine 引入了 "Agent Identity" 的概念。Agent 不再用通用的服务账号，而是有自己的身份凭据，绑定了 IAM 权限和 mTLS 证书。凭据被盗也没法在其他环境重放。

OpenAI 的做法： Code Interpreter 在一个完全隔离的沙箱环境里跑 Python。Agent 只能在沙箱内操作，碰不到宿主系统。

3.4 自动验证与反馈循环——"写完自动检查，不对就改"

一个好的 Harness 不会盲目信任 Agent 的输出。它会接入 Linter、测试运行器、类型检查器等工具。Agent 写完代码，Harness 自动跑测试。测试没过？Harness 把错误信息格式化成 Agent 能理解的反馈，让它自己改。

这个"尝试→失败→反馈→修正"的闭环，是 Agent 从"生成式 AI"进化到"闭环智能体"的关键标志。

Anthropic 的实践最有代表性。 他们受 GAN（对抗生成网络）的启发，设计了多 Agent 结构：

Planner：负责拆解任务
Generator：负责执行（写代码、改文件）
Evaluator：负责用 Playwright 做端到端 UI 测试，把测试结果反馈给 Generator

这个循环迭代 5-15 轮，直到 Evaluator 满意为止。结果远超单 Agent 直接干的效果。

Stripe 的 Minions 系统用类似思路，让 Agent 每周提交 1300+ 个 PR。每个 PR 都经过自动验证——跑测试、查 lint、过 CI，全绿才算通过。

3.5 人类监督——"关键时刻拉一下缰绳"

完全自动化是理想，但现阶段不现实。涉及钱、涉及客户、涉及敏感数据的操作，必须有人点确认。

Harness 提供 Human-in-the-Loop（HITL） 机制。技术上很简单——在工具调用前插入一个"暂停点"。Agent 说"我要给客户发邮件"，Harness 暂停执行，弹出审批界面，你点了"确认"才继续。

你现在用 Claude Code（或者类似的 AI 编码工具）时，系统弹出来问"是否允许执行这条命令？"——这就是 HITL。

微软的分级策略： Agent Framework 提供 always_require（所有工具调用都需要审批）和 never_require（完全自动）两档，以及基于工具类型的中间策略。

四、大厂都在怎么做？

理论讲够了，看看实际动作。

4.1 Anthropic：最公开、最深入的实践者

Anthropic 的公开分享是行业里最多的。他们总结了 Agent 的四大失败模式——一次性失败、提前完成、状态不一致、交接混乱——并针对每个失败模式给出了 Harness 层的解决方案。

核心理念： "模型升级后，Harness 反而要简化。" 模型越强，给它的自由度越大；但无论模型多强，Harness 的状态管理、安全隔离、验证循环不能省。

技术路径： Claude Code 就是一个 Agent Harness 产品。它内部实现了上下文压缩、文件系统工具、Shell 执行、安全审批、自动反馈修正。开发者每天用的 run_command、view_file、grep_search 这些工具，都是 Harness 提供的标准化接口。

最新进展： Agent SDK 被描述为 "Claude Code as a library"，把 Harness 的能力开放给第三方开发者。

4.2 OpenAI：提出"Harness Engineering"概念

OpenAI 提出了一个很有意思的观点：未来程序员不写代码，而是设计 Harness。

Harness Engineer 的工作：
├── 定义 Agent 的行为边界
├── 设计安全护栏和审批流
├── 编写结构化的 System Prompt
├── 搭建自动化测试与验证管道
└── 配置可观测性和成本监控

Codex 就是这个理念的产品化。底层是持久化的 Agent 循环，通过 JSON-RPC API 暴露给 Web、CLI、IDE、Mac App 多个端。支持处理百万行代码级别的开发任务。

4.3 微软：企业级全家桶

微软的路线最"重"，覆盖面最广：

Agent Framework（开源）：提供 Agent 构建和运行的完整框架，Python 和 .NET 双支持，内置 Shell Harness、上下文压缩策略、工具审批模式、OpenTelemetry 可观测性
Foundry Agent Service（托管平台）：强调 "governed, observable, integrated"，接入 Bing、SharePoint、Fabric 等微软生态的知识源
Copilot Studio（低代码）：让非技术人员也可以配置 Agent 的行为和权限
Purview（数据治理）：DLP 策略、敏感标签、审计日志，把数据安全落实到 Agent 交互的每一步

微软的哲学是：企业不缺 Agent，缺的是"治理"Agent 的能力。 所以他们把大量精力放在权限、审计、合规这些"不酷但关键"的事情上。

4.4 Google：Build / Scale / Govern 三位一体

Google 的 Vertex AI Agent Builder 定位非常明确——覆盖 Agent 从构建到扩展到治理的全生命周期。

几个亮点：

Agent Engine：托管运行时，内含会话管理（Sessions）、长期记忆（Memory Bank）、代码执行沙箱、评测服务
Agent Identity：给 Agent 分配独立身份，绑定 mTLS 证书和 IAM 权限。凭据被截获也没法重放——因为证书绑定了运行环境
Trajectory Evaluation：不仅评估 Agent 的最终输出对不对，还评估它的过程对不对——调用了哪些工具、顺序是否合理、中间有没有走弯路

Google 在治理侧也做了一个很实际的东西：Cloud API Registry 作为工具注册中心。管理员在这里审批和管理 Agent 可用的工具，防止 Agent 随便接入未经审查的 API。

4.5 字节跳动：长程任务与超级 Agent

字节的开源项目 DeerFlow 走了一条独特的路——聚焦长程任务。不是几分钟完成的简单对话，而是可能持续数小时的深度研究。

长程任务对 Harness 的要求特别苛刻：
- 上下文管理不能出纰漏，一出就是几小时的工作白费
- 需要子 Agent 分工，一个 Agent 搞不定全部
- 中间状态必须持久化，用户关掉浏览器再回来得能接着用

DeerFlow 2.0 基于 LangGraph 运行，集成了 InfoQuest 智能搜索和爬虫工具集。它本质上就是一个 SuperAgent Harness——通过沙箱、消息网关和技能系统，给 Agent 提供了完成复杂研究所需的完整"身体"。

4.6 阿里巴巴：多 Agent 协同的工业化

阿里通过 AgentScope 强调的是可扩展性和可观测性。

核心理念：Agent 不是 LLM 的薄包装，是一种应用架构。AgentScope 的设计解决四个问题：

可靠性：重复执行同样的任务，结果要一致
可伸缩：能在 K8s 或 Serverless 环境下水平扩展
人类监督：关键决策点有人工介入
可扩展：新工具、新能力可以即插即用

阿里特别看重消息中心（Message Hub） 在 Harness 中的地位。多个 Agent 协作时，谁说了什么、谁听了什么、消息怎么路由——如果搞不清楚，整个系统就是一团乱麻。

4.7 Manus：六个月重写五次 Harness

Manus 的案例最能说明问题。

他们在六个月内重写了五次 Harness。用的是同一个模型。 每次重写都提升了可靠性和任务完成率。

模型没变，变的是 Harness。

换句话说：Agent 好不好用，七成取决于 Harness 的设计，三成取决于模型的能力。

4.8 一张对比表

公司
核心产品
核心理念
开源情况

Anthropic
Claude Code + Agent SDK + MCP
模型是引擎，Harness 是整辆车
MCP 开源，SDK 部分开放

OpenAI
Codex + Agents SDK
Harness Engineering 是新型编程
Agents SDK 开源

微软
Agent Framework + Foundry
企业缺的不是 Agent，是治理能力
Agent Framework 开源

Google
Vertex AI Agent Builder
Build / Scale / Govern 三步走
ADK 开源

字节
DeerFlow
长程任务需要 SuperAgent Harness
DeerFlow 开源

阿里
AgentScope
Agent 是应用架构，不是模型包装
AgentScope 开源

AWS
Bedrock Agents + AgentCore
生产化 = 托管运行时 + 模块化治理
Strands Agents 开源

Meta
Llama Stack
开源优先，任意模型 + 任意基础设施
全栈开源

五、在你眼皮底下运行的 Harness：以 AI 编码助手为例

你现在用的 AI 编码工具（Claude Code、Cursor、GitHub Copilot Workspace），本质上就是 Agent + Harness 的产物。只不过 Harness 藏在后面，你感知不到。

以 Claude Code 为例，拆解一下它的 Harness 层在做什么：

你看到的现象
背后 Harness 在做什么

你打开项目，AI 就"认识"你的代码
Harness 提供文件系统工具，Agent 用 view_file、grep_search 主动探索代码库

AI 跑一个命令，弹窗问你"是否允许执行？"
HITL 审批机制，Harness 拦截了危险操作

AI 写了一段代码，自动跑测试说"测试没过，我来修"
反馈循环，Harness 把 lint / test 结果路由回 Agent

长对话后 AI 仍然记得最初的需求
上下文压缩和持久化，Harness 定期做摘要

AI 说"我来搜索一下这个函数在哪用了"
工具编排，Harness 提供的 grep_search 标准化工具

离开 Harness，这些体验一个都不会有。 你得到的只是一个聊天框，问一句答一句，没有文件读写，没有命令执行，没有反馈修正。

Vercel 做过一个反直觉的实验：删掉 Agent 80% 的工具。结果呢？Agent 的表现反而更好了——更少的工具意味着更少的步骤、更低的 Token 消耗、更快的响应、更高的成功率。

这说明 Harness 不是堆功能。减法是 Harness 优化的有效路径。

六、理解 Harness 的三个深层认知

到这里，概念和案例都讲了。我想把几个更深层的理解分享给你，帮你建立对这件事的"体感"。

6.1 竞争重心正在漂移

过去几年，AI 公司的竞争焦点是模型参数量和预训练数据。2026 年，重心开始向"推理侧工程"转移。

Block 公司（做 Square 和 Cash App 的那个）是个好例子。他们的 AI Agent 在风险检测领域表现出色，成功不是因为用了多牛的模型，而是因为 Harness 的治理能力——可靠的工具调用、精准的上下文管理、完善的审计链路。

行业共识已经形成：改进 Harness 带来的回报，远高于频繁切换模型。

6.2 Harness 是下一代模型的"训练数据工厂"

高质量的 Harness 会记录 Agent 的每一次行为——哪些修复路径成功了、哪些工具调用序列有效、Agent 如何从测试失败中恢复。

这些高度结构化的行为轨迹（trajectory），正在成为大模型后训练（Post-training）的核心数据。

你可能听过 "RLHF"（基于人类反馈的强化学习）。现在的趋势是 "RLEF"——基于环境反馈的强化学习。环境反馈从哪来？从 Harness 记录的执行日志来。

Harness 的设计水平，直接决定了模型进化的速度。 好的 Harness 产生高质量的轨迹数据，高质量的数据训练出更强的模型，更强的模型又让 Harness 可以更简化。这是个正反馈循环。

6.3 "USB-C 时刻"正在到来

MCP（Model Context Protocol）是 Anthropic 提出并开源的"工具连接协议"。它的野心是：让任何 Agent 都能通过同一套协议连接任何工具。

就像 USB-C 统一了充电口——你不再需要为每个设备买不同的线。

现在 Google、微软、OpenAI、Meta 都开始支持 MCP。工具接入从"每家一套插件"正在变成"统一协议的 MCP Server/Client"。

当工具可以即插即用后，单纯"拥有工具"不再是护城河。能够高效组织、编排和安全治理这些工具的 Harness，才是核心竞争力。

七、如果你想入门，怎么学？

讲了这么多，落到实处。如果你想上手 Agent Harness，这是我建议的路径。

第一步：建立概念（2-3 天）

必读材料：
- Anthropic 的 Agent 构建指南——最经典的 Harness 设计实践
- PuppyGraph《What is Agent Harness?》——最佳定义综述
- LangChain《The Anatomy of an Agent Harness》——解剖 Harness 的组成
- 微软 Agent Framework 博客——企业级视角

核心问题：当 Agent 出了 bug，你要能判断——这是模型的问题，还是 Harness 的问题？ 能区分这两件事，你就入门了。

第二步：拆解现有 Harness（1 周）

别急着从零开始造。先拆。

如果你在用 Claude Code，看它的 .claude/ 目录配置。每个配置项对应 Harness 的哪个能力？
跑一遍 LangGraph 的 StateGraph 示例。它本质上就是 Harness 的流程控制层
用 OpenAI Agents SDK 跑一个最简 Agent。注意观察：Agents、Handoffs、Guardrails、Tracing 这四个原语分别在做什么？

第三步：动手造一个最小 Harness（2 周）

按这个顺序来：

实现最小 Agent 循环——模型调用 → 工具执行 → 结果回填 → 继续循环。能跑通这个循环，你就理解了 Harness 的骨架
加入 MCP 工具接入——实现一个 MCP Client 连接文件系统 MCP Server，理解"协议化工具接入"的价值
加入多 Agent 编排——用 Supervisor + Worker 模式，让一个 Agent 分配任务给其他 Agent
加入治理门禁——在工具调用前加策略检查（允许 / 拒绝 / 需审批），写审计日志
加入可观测性——用 OpenTelemetry 采集 spans，导出到 Jaeger 或任意后端

每一步都能独立跑，不用等全部完成。

第四步：进阶实验

在同一个 Harness 下切换不同模型（Claude、GPT、Gemini），观察模型差异对 Harness 设计的影响
对你的 Agent 做红队测试——试试 prompt injection、工具滥用、数据外泄
建立评测体系，不仅评 Agent 的最终输出，还评它的工具调用轨迹

八、一个思维实验

最后留一个问题给你想。

假设明天所有大模型的推理能力突然变得完全一样——GPT、Claude、Gemini、Llama 全部同质化。

这时候，谁的 Agent 产品会胜出？

答案很明显：Harness 设计最好的那个。

因为模型是大宗商品，差别在于围绕模型的工程系统——怎么管理上下文、怎么保证安全、怎么验证输出、怎么处理故障、怎么控制成本。

2026 年的 AI 竞争，模型在趋同，Harness 在分化。

你现在每天用的 AI 编码工具，打开时觉得"挺顺手"——90% 的"顺手"来自 Harness 的设计，不是来自模型的聪明。

以上。