Agent Harness 调研定义 · 六厂商 · 2024—2026 学术进展
RESEARCH MEMO · 2026-07-20

Agent Harness：定义、头部厂商布局与学术进展

简明调研备忘录｜资料截止：2026-07-20

一页结论

Agent harness 的技术实质是一组运行时能力，而不是一个已经统一的产品类别。 最小能力是驱动模型—工具—环境的多步闭环；生产系统再按任务风险组合沙箱隔离、会话/记忆、控制面与观测，以及审批、中断和恢复。不同厂商把这些能力集成成“薄 SDK + 富 API”或“厚托管运行时 + 控制面”，两种策略不能用是否填满同一组件表来简单排名。[3][5][8][9][10][11]

在这个能力谱上，Anthropic、Microsoft、OpenAI、Google 与 AWS 都有实质建设，只是产品边界不同；Meta 只能确认 2025 年历史快照，迁移后 2026 年是否仍由 Meta 直接维护未知。名称是次级但有用的产业信号：本次核验中只有 Anthropic 与 Microsoft 明确采用生产型 agent harness / Harness 原词，其余厂商主要称 SDK、framework、platform、runtime 或 stack。[1][3][5][8][10][13]

产业与学术对 harness 还有同词异指：产业语境通常指生产执行封装；学术与评测语境中的 evaluation harness 更像固定任务、环境、预算和评分协议的试验台。SWE-agent、τ-bench、OSWorld 等研究共同说明，成绩不是模型的单变量函数，而是 model × harness/scaffold × tools × environment × budget 的联合结果。[17][18][19][22]

2024 年以来，前沿进展不是简单增加工具数量，而是：从静态问答进入有状态环境；从文本答案转向环境终态；从单次成功率扩展到重复可靠性、安全属性、预算曲线与层级评分；从 agent 独占动作扩展到用户与 agent 共同改变世界。尚未充分解决的是恢复评测：在本文核验的代表样本中，基准会发现错误副作用，却很少把审批、中断、检查点恢复、安全重试和业务补偿按阶段独立评分。[18][21][24][25][26]

1. 什么是 agent harness

1.1 一个可操作的定义

本备忘录采用以下最低语义核：

Agent harness 是位于模型与任务环境之间、让模型能够持续、受控、可观察地完成多步任务的运行封装。

纳入判断分两轴：

  1. 厂商是否明确采用 agent harness 原词；
  2. 系统是否实质覆盖 harness 职责：必须驱动模型—工具—观察闭环，并在状态/上下文、副作用治理、观测/恢复三类中至少覆盖两类。

这两轴不能互相替代。只看名称，会漏掉 OpenAI Agents SDK、Google ADK/Agent Platform 与 AWS Bedrock Agents + AgentCore；只看功能，又会把任意 SDK、workflow 或 protocol 都误叫作 harness。

1.2 信息如何流动

Agent Harness 执行闭环与责任边界

图 1｜Agent Harness 执行闭环与责任边界（作者根据公开机制整理）。 Harness 从任务、会话和工具能力构造上下文；模型提出局部决策；工具或沙箱产生环境反馈；Harness 验证并持久化状态，再决定继续、停止或升级人工。模型负责策略纠偏，Harness 负责流程恢复，应用负责外部副作用语义，人类负责不可逆风险决策。检查点只能恢复编排状态，不能撤销已发送邮件、已完成转账等外部动作。

图中的四层是控制点定位，不是失败责任的正交切分。真实故障常跨层耦合：模型生成错误动作，Harness 按错误重试策略重复执行，应用又错误假设接口幂等，而人工接管触发过晚；任何单层看似正常，组合仍可能放大副作用。因此生产系统不仅要列出机制，还要明确失败如何跨层传播、由谁检测以及默认降级到哪里。

这种分工有效，是因为模型擅长条件生成和局部决策，却不是可靠的事务管理器、权限系统或持久状态存储。代价则是更多延迟、状态一致性问题、工具攻击面，以及 harness 本身对最终能力测量的显著影响。

1.3 运行时能力谱：一种分析投影

以下四层是为了比较公开能力而使用的分析投影，不是厂商共同采用的标准，也不是彼此正交的产品模块。薄 SDK 往往把职责暴露给应用组合；厚托管运行时则把 sandbox、session 与 control plane 深度耦合。表中空格只能表示公开证据不足，不能直接解释为产品能力较弱。

层核心责任典型失败
Inference loop构造上下文，驱动模型、工具与观察循环提前终止、长程漂移、错误工具选择
Execution sandbox执行代码/浏览器动作，限制文件、网络、身份和资源越权、逃逸、资源耗尽、状态泄漏
Session / state保存对话、文件、记忆、检查点与恢复键状态串扰、恢复错位、上下文膨胀
Control plane / observability部署、审批、身份、追踪、评估与人工介入无法审计、错误重试、失控副作用

这不是要求每家提供单体产品。OpenAI Agents SDK 更接近“薄 SDK + 富 API”的组合入口；AWS Bedrock Agents + AgentCore 与 Google ADK + 托管平台更接近“构建层 + 厚运行时/控制面”的组合。两类策略是在不同边界上分配责任，不应按层数多少简单排名。[5][8][9][10][11]

1.4 不应混为一谈的概念

概念主要作用与 harness 的关系
Agent SDK / framework用 API、类和 schema 组合模型、工具与 handoff可以实现 harness，但只有调用封装时还不够
Runtime托管进程/容器，处理身份、网络、扩缩与隔离常是生产 harness 底座，但未必驱动决策循环
Workflow / orchestrator规定图、路由、顺序和主体协作提供显式控制，不自动包含上下文、权限和恢复
Protocol（如 MCP）标准化工具或 agent 连接降低连接成本，不决定循环、状态和审批策略
Evaluation harness固定任务、环境、预算和评分协议测量 model+harness 联合系统，不是生产执行层
Scaffoldprompt、tool、memory、controller 等研究配置口径更宽，未必具有生产隔离、恢复和治理

2. 哪些大厂在做

2.1 运行时能力落点优先，名称分类其次

技术比较首先看各厂商把 tool loop、sandbox、state/memory、control plane/observability 与 recovery 放在哪里；“是否采用 harness 原词”只描述命名和产品边界，不代表技术强弱。

产业命名信号厂商应如何解读
明确采用原词且有工件Anthropic、Microsoft可以直接引用其 agent harness / Harness 命名，但两者运行边界仍不同
实质同类能力、采用其他官方术语OpenAI、Google、AWS应使用 SDK、framework、platform、runtime 等原名，再解释其 harness 职责
历史快照，当前归属未知Meta2025 固定版本可确认；不能用迁移后的 OGX 证明 Meta 2026 仍维护

这里的“未核到原词”不是“厂商从未使用”，更不代表厂商刻意回避该词。它只表示截至资料截止日，在本次直接核验材料中未找到足够证据。

2.2 六厂商具体在做什么

厂商官方术语/工件技术落点已确认的治理或恢复公开边界
AnthropicClaude Agent SDK；官方称其为支撑 Claude Code 的 agent harness上下文—行动—验证循环；computer use 动作接口；文件和 subagent 状态验证后纠偏，工具使用安全建议工具环境由部署者提供，不能等同于 Anthropic 托管沙箱；通用回滚未确认 [1][2]
MicrosoftAgent Framework Harness，与 Agents、Workflows 并列planning/todo、context compaction、files/memory、approval、observabilitytool approval；workflow checkpointing 与 HITLoverview 未证明代码隔离粒度或业务补偿；详情链接曾返回 404 [3]
OpenAIAgents SDK / framework，固定 v0.18.3loop、sandbox workspace、session、guardrail/HITL、tracingapproval 被实现为 interruption；RunState/session 持久化后可恢复；sandbox session 有能力变更限制官方仍称 framework；流程恢复不等于撤销已发生业务动作 [4][5][6][7]
GoogleADK；Gemini Enterprise Agent PlatformADK 负责构建 loop；平台提供 runtime、session、memory、sandbox、identity、gateway、observability/eval平台级 session、治理和观测面已读材料未把整体正式命名为 harness；补偿事务未确认 [8][9]
AWSBedrock Agents + AgentCoreAgents 负责任务分解/动作编排；AgentCore 负责 runtime、session、identity、memory、observability/securityaction group 可 return control 给应用执行和返回结果return-of-control 是控制转移，不是 rollback；AgentCore 本身不等于 planning loop [10][11][12]
MetaLlama Stack v0.1.9 历史快照统一 Agents、Tools、Memory、Safety、Evals、Telemetry API仅确认 API 面项目后来迁移为独立 OGX；2026 当前建设归属未知，恢复语义未确认 [13][14]

2.3 三种代表性技术定位

Anthropic：以“模型外执行封装”来命名。 官方工程文章把 Claude Code 的通用能力归因于一套可复用 harness：收集上下文、采取行动、验证、重复。技术重点是把文件、工具和子任务状态放到模型外部，使模型在有限上下文内持续推进。[1]

Microsoft：把 Harness 做成 Agent 与 Workflow 之间的有主张封装。 普通 Agent 提供模型和工具调用；Harness 为长程任务预装规划、压缩、文件/记忆、审批与观测；Workflow 则提供图路由、checkpoint 和 HITL。该官方分类直接表明三者不是同义词。[3]

AWS：将相关职责拆成组合式产品栈。 Bedrock Agents 负责模型驱动编排，AgentCore 负责运行托管、身份、会话、记忆与观测。按本文分析框架，这一组合分别落在 execution loop 与 production control plane，而不是一个单体 harness。[10][11]

OpenAI 和 Google（分析归纳）： 前者在 Agents SDK 中组合 sandbox agent、session、HITL 和 tracing；后者以 ADK 加托管平台覆盖构建、运行、治理和评估。这个对照描述的是公开产品边界，不代表厂商采用本文分类，也不构成能力强弱排序。[5][8][9]

3. 恢复不是一个布尔开关

对已发生的外部副作用，现有 harness 不能提供跨业务系统普遍成立的“通用 rollback”。恢复能力取决于失败发生在哪一层、谁有权限修复，以及外部动作是否可逆。

时机机制主要责任方保证边界
执行前风险评估、tool approvalHarness 提供门控，人类/应用作决策只能阻止尚未执行的动作
执行中暂停、中断、return-of-controlHarness / 应用 / 人类可转移控制权，不自动恢复外部状态
编排状态checkpoint / session resumeHarness恢复流程位置和上下文，不撤销副作用
失败确认后retryHarness 发起，应用提供幂等和结果确认非幂等动作盲重试可能重复扣款或发送
动作完成后compensating action / 人工补救应用与人类补偿不保证世界完全回到原状

OpenAI 固定源码显示审批是 run loop 的中断类型，并在中断时保存状态；AWS 提供 return-of-control；Microsoft workflow 提供 checkpoint/HITL。这些都是有价值的恢复构件，但支持其中一项不等于支持其余机制。[3][6][7][12][28][29][30][31]

4. 2024 年以来学术界发展如何

4.1 从接口优化到环境闭环

SWE-agent 将 agent-computer interface（ACI）本身作为研究变量：定制仓库导航、文件编辑和测试命令，使 LM 能在软件工程环境中反复行动和读取反馈。摘要报告其当时在 SWE-bench 上达到 12.5% pass@1；该结果属于完整系统，不能只归因于模型。[17]

OSWorld 把 agent 放进真实 Ubuntu、Windows、macOS 与应用程序，369 项任务均有初始状态配置和执行脚本。它把评分从“回答像不像”改为“环境是否变成目标状态”；v2 摘要中的人类 72.36% 与最佳模型 12.24% 只适用于当时协议和基线。[19]

TheAgentCompany 进一步构造自包含软件公司环境，让 agent 跨 Web、代码执行和同事通信完成数字工作；v3 摘要报告最强 baseline 自主完成 30%，困难长程任务仍明显受限。[23]

4.2 从单次成功到可靠性与状态正确性

τ-bench 让 agent 与模拟用户动态对话，并调用领域 API；评分器比较数据库终态与目标状态，而非只看最后一句话。pass^k 衡量连续 k 次全部成功，揭示平均成功率掩盖的波动：论文摘要报告 retail 场景 pass^8 < 25%。[18]

τ²-Bench 将环境改为 dual control：agent 和用户都能用工具改变共享世界，并建模为 Dec-POMDP。组合式任务生成器控制难度，消融把推理错误与沟通/协调错误分开；这说明现实 harness 还要指导用户完成 agent 无权执行的动作。[26]

METR 则用人类完成时间刻画任务难度，并研究成功率随 token budget 的变化。其 2024 更新发现简单 scaffold 在约 20 万 token 后趋于平台，说明增加预算并不会自动带来可靠长程行动。[22]

4.3 从功能测试到安全与不可信环境

AgentDojo 研究间接提示注入：恶意指令藏在工具返回的不可信数据中，再诱导 agent 使用已有权限执行攻击。其动态环境包含 97 个任务和 629 个安全测试案例。关键机制启示是：权限检查必须覆盖“观察如何影响后续动作”，仅限制可调用工具仍不够。[21]

ToolEmu 首版早于本调研时间窗，因此不作为 2024+ 主样本，但其 2024 修订版可作机制参照：用 LM 模拟高风险工具执行，再由安全 evaluator 检查失败。它测的是风险发现，不是 agent 的动作后回滚能力。[27]

4.4 从短任务到科研复现

CORE-Bench 以 90 篇论文构造 270 项计算复现任务，并提供并行 evaluation harness；它交叉比较通用 AutoGPT、任务专用 CORE-Agent 与两种模型，直接表明 agent 架构是独立变量。[24]

PaperBench 要求从零复现 20 篇 ICML 2024 Spotlight/Oral，将任务分为 8,316 个可评分子项，并另建 judge benchmark 验证 LLM judge。其摘要报告最佳被测组合“Claude 3.5 Sonnet (New) + 开源 scaffolding”平均 21.0%，未超过所招募的顶尖 ML 博士基线。层级 rubric 提供了稠密诊断，但 rubric 分不等于完整复现成功。[25]

4.5 系统平台与通用评测装置

AgentScope 代表框架向平台演化：以消息交换为核心，加入容错、监控、工具/知识管理和 actor-based 分布式执行。但摘要声称“robust”不等于已经通过统一恢复评测。[20]

Inspect 是典型 evaluation harness：把 dataset、agent/solver、tool、sandbox、scorer、log/viewer 组合起来，还能包住 Claude Code、Codex CLI、Gemini CLI 等外部 agent。它统一外层评测协议，却不会让这些 agent 的内部 scaffold 自动同构。[15]

4.6 路线比较

路线代表工作核心机制数据/成本依赖能力边界
接口与执行 scaffoldSWE-agent、AgentScope约束动作空间和观察格式；持久 workspace；平台容错repo、命令接口、运行环境harness 改变成绩，难与模型能力完全解耦
有状态业务交互τ-bench、τ²-BenchAPI 改变数据库；终态评分；单/双控制user simulator、policy、状态机模拟用户不等于真实用户；补偿未单测
真实计算机与组织工作OSWorld、TheAgentCompanyGUI/Web/code/communication 跨应用执行OS/app 版本、账户、环境重置环境脆弱、任务昂贵；长程恢复披露不足
科研复现CORE-Bench、PaperBench代码/数据执行；并行评分；层级 rubric/judge依赖安装、GPU/时间、judge 校准预算可比性和完整真值困难
对抗安全AgentDojo、ToolEmu不可信观察、攻击/防御、风险 evaluator攻击更新、隔离、人工验证风险发现不等于事后恢复
通用 eval harnessInspect、METR统一 dataset/tool/sandbox/scorer/log；预算曲线provider、sandbox、人类基线外层统一不消除内部 scaffold 差异

5. 最值得保留的前沿判断

  1. 运行时能力谱比产品名称更重要。 技术比较应先看 tool loop、sandbox、state/memory、control plane/observability 与 recovery 如何组合；层数或单体化程度不能直接代表强弱。
  2. 术语仍未收敛。 “Agent harness”可作为分析概念，但不是六家通用产品名。技术文档若只描述 SDK、runtime、workflow 或 eval rig，应使用更具体名称。
  3. 产业栈存在不同集成策略。 OpenAI 更接近薄 SDK + 富 API；AWS、Google 更明显地采用构建层与厚托管运行时/控制面组合。二者分配责任的边界不同。
  4. 接口与 harness 是能力的一部分。 同一模型换动作空间、观察格式、记忆、预算或重试策略，成绩可能显著变化，因此排行榜不能直接等同于模型排名。
  5. 评测正在从文本走向世界状态。 数据库终态、OS 执行脚本、安全属性和科研 artifact 比 LLM-as-judge 的最终文本更接近真实任务。
  6. 恢复责任存在需求—评测错配。 产业公开了审批、HITL、checkpoint、return-of-control 等构件；在本文核验的代表基准中，恢复尚少按阶段成为一等评测维度。分层只定位控制点，真实失败仍可能由模型、Harness、应用与人工接管的跨层耦合造成。

6. 证据边界与使用建议

参考资料

厂商与系统一手资料

  1. Anthropic, “Building agents with the Claude Agent SDK / the agent harness that powers Claude Code.” https://claude.com/blog/building-agents-with-the-claude-agent-sdk
  2. Anthropic, “Introducing computer use…”, 2024-10-22. https://www.anthropic.com/news/3-5-models-and-computer-use
  3. Microsoft, “Microsoft Agent Framework Overview”, updated 2026-07-10. https://learn.microsoft.com/en-us/agent-framework/overview/
  4. OpenAI Agents SDK, v0.18.3 tag metadata. https://api.github.com/repos/openai/openai-agents-python/git/tags/74af7f18d993fe7d75fced06fbe82ef6943564e3
  5. OpenAI Agents SDK v0.18.3 fixed README, commit 3e788a46. https://raw.githubusercontent.com/openai/openai-agents-python/3e788a46f180ebf120fdc39e3dfe48c98627be50/README.md
  6. OpenAI Agents SDK fixed tree and src/agents/run_internal/approvals.py, src/agents/run.py. https://api.github.com/repos/openai/openai-agents-python/git/trees/3e788a46f180ebf120fdc39e3dfe48c98627be50?recursive=1
  7. OpenAI Agents SDK, src/agents/sandbox/runtime_session_manager.py, fixed commit. https://raw.githubusercontent.com/openai/openai-agents-python/3e788a46f180ebf120fdc39e3dfe48c98627be50/src/agents/sandbox/runtime_session_manager.py
  8. Google Developers Blog, “Agent Development Kit: Making it easy to build multi-agent applications”, 2025-04-09. https://developers.googleblog.com/en/agent-development-kit-easy-to-build-multi-agent-applications/
  9. Google Cloud, “Gemini Enterprise Agent Platform — Scale agents.” https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale
  10. AWS, “Amazon Bedrock Agents.” https://aws.amazon.com/bedrock/agents/
  11. AWS, “Introducing Amazon Bedrock AgentCore…”, 2025-07-16. https://aws.amazon.com/blogs/aws/introducing-amazon-bedrock-agentcore-securely-deploy-and-operate-ai-agents-at-any-scale/
  12. AWS Documentation, “Return control…” and action groups. https://docs.aws.amazon.com/bedrock/latest/userguide/agents-returncontrol.html
  13. Llama Stack v0.1.9 fixed README, commit 337aa6d, 2025-03-29. https://raw.githubusercontent.com/ogx-ai/ogx/337aa6d1834380c5df0ba0127faadb3578b68285/README.md
  14. OGX current repository and migration state. https://github.com/ogx-ai/ogx
  15. UK AISI / Meridian Labs, Inspect documentation. https://inspect.aisi.org.uk/
  16. Anthropic, “Building Effective Agents”, 2024-12-19. https://www.anthropic.com/engineering/building-effective-agents

论文、基准与方法

  1. Yang et al., “SWE-agent”, arXiv:2405.15793v3. https://arxiv.org/abs/2405.15793v3
  2. Yao et al., “τ-bench”, arXiv:2406.12045v1. https://arxiv.org/abs/2406.12045v1
  3. Xie et al., “OSWorld”, arXiv:2404.07972v2. https://arxiv.org/abs/2404.07972v2
  4. Gao et al., “AgentScope”, arXiv:2402.14034v2. https://arxiv.org/abs/2402.14034v2
  5. Debenedetti et al., “AgentDojo”, arXiv:2406.13352v3. https://arxiv.org/abs/2406.13352v3
  6. METR, “An update on our general capability evaluations”, 2024-08-06. https://metr.org/blog/2024-08-06-update-on-evaluations/
  7. Xu et al., “TheAgentCompany”, arXiv:2412.14161v3. https://arxiv.org/abs/2412.14161v3
  8. Siegel et al., “CORE-Bench”, arXiv:2409.11363v2. https://arxiv.org/abs/2409.11363v2
  9. Starace et al., “PaperBench”, arXiv:2504.01848v3. https://arxiv.org/abs/2504.01848v3
  10. Barres et al., “τ²-Bench”, arXiv:2506.07982v1. https://arxiv.org/abs/2506.07982v1
  11. Ruan et al., “ToolEmu”, arXiv:2309.15817v2（首版 2023，仅作机制参照）. https://arxiv.org/abs/2309.15817v2

恢复语义的机制参照（非 agent harness 历史综述）

  1. Gray & Reuter, *Transaction Processing: Concepts and Techniques*, 1992，事务原子性、日志恢复与外部副作用边界的经典系统参照. https://www.microsoft.com/en-us/research/publication/transaction-processing-concepts-and-techniques/
  2. Garcia-Molina & Salem, “Sagas”, SIGMOD 1987，长事务以补偿事务处理已提交子动作，而非假设普遍物理回滚. https://doi.org/10.1145/38713.38742
  3. OpenAI Agents SDK v0.18.3, src/agents/run_internal/approvals.py，固定 commit 3e788a46；tool approval 的 interruption 处理实现. https://raw.githubusercontent.com/openai/openai-agents-python/3e788a46f180ebf120fdc39e3dfe48c98627be50/src/agents/run_internal/approvals.py
  4. OpenAI Agents SDK v0.18.3, src/agents/run.py，固定 commit 3e788a46；中断、session 持久化与恢复路径. https://raw.githubusercontent.com/openai/openai-agents-python/3e788a46f180ebf120fdc39e3dfe48c98627be50/src/agents/run.py
资料截止：2026-07-20 · 无远程运行依赖，可离线打开。