什么是智能体运行框架？研究、开源项目与行业实践

两个智能体即使使用完全相同的模型，在同一基准测试中的得分也可能天差地别。OpenAI 直接测得：在 SWE-bench Lite 上，GPT-4 使用一种运行框架时得分为 2.7%，换用另一种则为 28.3%——10 倍差距完全由运行框架造成。随着行业关注点从“哪个模型最聪明”转向“哪个智能体真正能完成工作”，智能体运行框架成为决定可靠性的关键层。继续阅读，了解什么是智能体运行框架，最新论文和基准测试对运行框架设计有何发现，哪些开源运行框架值得投入时间，以及各大 AI 实验室如何设计自己的运行框架——其中包括月之暗面与自有运行框架搭配使用的开放权重模型 Kimi K3.1 Pro。

智能体运行框架是让大语言模型能够在真实环境中作为智能体运行的配套基础设施。模型负责生成 token，运行框架则负责其余一切：在每一步构建提示词，定义可用工具及其调用方式，在沙箱或终端中执行操作，将观测结果反馈给模型，施加步骤和成本限制，并记录完整轨迹以供评估或调试。

这一术语源自评测领域——“测试运行框架”是让系统在受控条件下运行的装置。在智能体 AI 中，这一概念被延伸到生产环境：运行框架既是用于衡量智能体的装置（如 SWE-bench 或 Terminal-Bench），也是用于运行智能体的框架（如 SWE-agent、OpenHands 或 Claude Code）。

Anthropic 自己的 SWE-bench 研究说得很直白：该基准测试“并非只孤立地评估 AI 模型，而是评估一个完整的‘智能体’系统”，其中智能体是“AI 模型与其周围软件支撑架构的结合”。升级后的 Claude 3.5 Sonnet 在 SWE-bench Verified 上达到 49%，依靠的并非复杂框架，而是由一个提示词和两种通用工具（Bash 工具和 Edit 工具）组成的极简运行框架。

多年来，排行榜上的提升一直被归因于模型规模。近期研究从两个方向打破了这一假设。

首先是“少即是多”的发现：2025 年 7 月，SWE-bench 团队发布了 mini-SWE-agent，这是一个约 100 行 Python 的运行框架，除 bash 外不使用其他工具，消息历史完全线性，并且每项操作都通过独立的 subprocess.run 调用执行。它取得了可与复杂得多的框架竞争的基准测试分数（详见下文研究部分）。这一结论颇具挑战性：当模型足够强大时，极其简单且可预测的运行框架可能胜过重量级框架。Meta、NVIDIA、IBM、Princeton 和 Stanford 已将其用作基线。

其次是“多即是少”的发现：糟糕的运行框架——嘈杂的工具输出、无边界循环、糟糕的错误恢复——会让前沿模型显得平庸。OpenAI 发现，清理 SWE-bench 中存在缺陷的任务（详见下文 OpenAI 部分）可使测得的模型性能提升一倍以上。

这就是为什么运行框架工程已成为一门独立的学科。运行框架决定：

• 模型看到什么：提示词结构、工具 schema，以及上下文窗口中包含多少环境状态和历史记录。

• 模型能做什么：可用工具有哪些（shell、文件编辑器、浏览器、搜索），以及操作在执行前如何被解析和验证。

• 如何处理失败：重试、超时、上下文窗口填满时的上下文压缩，以及平稳终止。

• 如何衡量工作：轨迹日志、评分和成本核算——没有这些，就没有评估，也没有改进循环。

无论是研究基准测试装置还是生产级编程助手，几乎所有智能体运行框架都实现了相同的核心循环：

1. 任务接收：读取问题、指令或目标，并启动隔离环境（通常是 Docker 容器或 VM 快照）。

2. 提示词组装：将系统提示词、工具定义、任务描述以及持续累积的操作与观测历史结合起来。

3. 操作解析： 将模型输出转换为具体的工具调用——bash 命令、文件编辑或 API 请求——并拒绝格式错误的操作。

4. 执行与观察： 在环境中运行操作，捕获 stdout/stderr 或 UI 状态，并将其截断以适应上下文预算。

5. 控制流程： 强制执行步骤上限、成本上限和停止条件；决定何时寻求人类帮助或结束任务过程。

6. 记录与评分： 保存完整轨迹并评估最终状态——例如，在 SWE-bench 中运行仓库的测试套件。

每一步的设计选择都会产生累积影响。仅截断策略一项，就能显著影响长程任务的得分，因此严肃的团队会将 harness 视为可版本管理、可测试的软件，而非胶水代码。

有关智能体 harness 的学术文献，已经形成了少数几个来之不易的结论。本节不逐一罗列所有基准测试，而是梳理那些迫使该领域认真看待 harness 的研究问题。

在介绍论文之前，先快速说明一下。基准测试是一组固定任务加上一套评分规则，旨在让不同系统能在相同条件下比较。在智能体评估中，一个基准测试包含三个动态部分：任务集（真实 GitHub issue、终端命令、网页任务）、执行环境（Docker 容器、浏览器、终端）和评分器（测试套件、状态检查、人工审核）。harness 位于模型与这三者之间——它这个变量决定了模型的能力能否体现在分数上。

实际如何计分，比醒目的总分更重要。在 SWE-bench 中，智能体会生成代码补丁；随后基准测试运行两个测试套件：FAIL_TO_PASS（修复前失败、修复后必须通过的测试）和 PASS_TO_PASS（修复前通过、修复后不得失败的测试）。只有两者都通过，任务才算解决。这就是为什么测试执行和 diff 生成等 harness 功能并非可有可无的附加项——它们正是得失分的关键。

解读任何基准测试分数的三条原则：

1. 先问分数掩盖了什么。 在公开 GitHub 数据上训练的模型，可能已经见过它所测试的那些 issue——数据污染会在没有真正能力提升的情况下抬高分数。可复现环境和保留任务集是应对之策。

2. 警惕古德哈特定律： 当一项指标成为目标，它就不再是好的指标。为在某一个基准测试中取得高分而调优的 harness，可能学到的是基准测试特有的技巧，而非通用能力——这也是严肃团队会在不止一个基准测试上进行评估的原因。

3. 检查 harness，而不只是模型。 如本节其余内容所示，同一个模型因脚手架不同，得分可以是 2.7% 或 28.3%。没有注明 harness 的分数只是逸闻，并非测量结果。

最初的 SWE-bench 论文（“语言模型能解决真实世界的 GitHub 问题吗？”）提出了如今已成标准的评估方式：向模型提供一个真实 GitHub issue 和完整仓库，并评估其补丁能否让失败的测试通过。它最常被引用的结果往往被误读：当时最好的模型 Claude 2 仅解决了 1.96% 的任务。作者自己的表述是，该基准测试检验的是“远超传统代码生成的复杂推理”——但后续工作表明，差距很大一部分并非来自推理能力，而是缺少一个能够浏览仓库、运行测试并反复迭代的 harness。换言之，SWE-bench 不仅衡量了模型；它还揭示了模型周围的 harness 是缺失的一环。

SWE-agent 论文（“智能体-计算机接口实现自动化软件工程”）是该领域关于 harness 设计的奠基性文献。其核心主张是，接口设计是一阶变量：作者提出了 智能体-计算机接口（ACI）这一术语，并证明专门构建的接口——具备 linter 防护的文件编辑器、简洁的 shell 反馈、针对格式错误命令的防护措施——可将 SWE-bench 的 pass@1 从个位数低分提升至当时最先进的 12.5%。该论文持久的贡献在于其论点：“LM 智能体代表了一类新的终端用户”，他们需要为其构建的软件，就像人类需要 IDE 一样。后续每篇关于 harness 的论文都会引用这一结果。

2024 年的两篇论文将 harness 研究从代码仓库扩展到了完整的计算机环境。OSWorld 构建了首个可扩展的真实计算机环境，覆盖 Ubuntu、Windows 和 macOS，包含横跨网页与桌面应用的 369 项任务。其核心数据——人类完成 72.36% 的任务，最佳模型完成 12.24%——指出 GUI 落地（将模型输出转换为正确的点击和按键）是主要失效模式，这是 harness 问题，而非知识问题。WebArena 则从另一角度切入：提供自托管、完全可复现的网页环境（电商、论坛、GitLab、CMS），其中 GPT-4 的端到端成功率仅为 14.41%，而人类为 78.24%。两篇论文都确立了一点：harness 评估必须基于执行（检查环境最终状态），而非对模型输出进行模式匹配。

Sierra 的 τ-bench（“现实领域中工具-智能体-用户交互的基准测试”）提出了一个更微妙的观点：在生产环境中，harness 不只是包裹模型和环境——它还在调解用户。该基准测试模拟语言模型用户与拥有领域 API 和政策指南的智能体之间的动态对话，然后评估最终数据库状态。它的关键指标 pass^k（在 k 次独立试验中的成功情况）揭示了智能体的不一致性：GPT-4o 单次完成的任务不到 50%，在零售场景中 pass^8 降至 25% 以下。对 harness 构建者而言，教训是可靠性是分布属性，而非单次运行属性——只在一次运行中有效的 harness，并不是真正有效的 harness。

METR 的“衡量 AI 完成长软件任务的能力”提出了50% 任务完成时间跨度：模型能以 50% 的可靠性完成的任务长度，以人类完成时间衡量。前沿模型在 2019 年至 2025 年间，已从几分钟提升至约一小时，约每七个月翻一番。对 harness 工程而言，这是过去十年中影响最深远的发现：限制 2024 年模型的 harness，对于 2026 年模型而言已是累赘。Anthropic 的观点是，harness 中的每个组件都编码了一项关于模型不能做什么的假设——而随着模型进步，这些假设会过时。

最初的基准测试已发展为一个将这些经验落地的生态系统：

• SWE-bench Verified（与 OpenAI 合作，2024）：一个经过人工筛选、包含 500 个实例的子集，移除了定义不充分或评分不公平的任务——原始任务池中有 68.3% 被筛除，这让测得分数提升了一倍以上，并成为默认排行榜。

• SWE-smith（2025）：一条生成合成训练任务的流水线，使模型能够为智能体式 harness 进行训练，而不只是接受其评估。

• mini-SWE-agent（2025）：这个约 100 行的 harness 目前在 SWE-bench Verified 上已超过 74%，表明一旦模型足够强大，采用线性历史记录、仅使用 bash 的极简循环就已足够；它也正成为社区的默认基线。

• Terminal-Bench（Stanford × Laude，2025）：基于 Harbor 框架的终端任务评估，将 harness 从代码编辑扩展到系统管理。

• CodeClash（2025）和 ProgramBench（2026）：面向目标和从零开始的软件创建，将 harness 从单一 issue 修复扩展到开放式开发。

所有这些工作贯穿始终的观点是一致的：harness 不是管线设施，而是研究对象。报告分数时应同时报告 harness，保持环境可复现，并对任何无法检查其 harness 的结果保持怀疑。

大多数团队会从开源 harness 起步。以下项目兼具庞大的 GitHub 社区（领先项目拥有数万颗星标）和活跃维护：

在它们之间进行选择时，社区的经验法则是：采用能够表达任务的最简运行框架（mini-SWE-agent 的理念），只有在可量化的失败确有需要时才增加复杂性。DeepSeek Harness 则位于光谱的另一端——这是一个完全由插件驱动的平台，面向希望每一层都可替换的团队——但两者遵循同一原则：以持久、只追加的会话日志作为模型所见内容的唯一事实来源。

前沿实验室将运行框架工程视为核心 IP，其中几家以罕见的细致程度公开了自己的思路。

Anthropic 发表了最完整的运行框架工程公开资料，其架构在 Building Effective Agents（2024）、SWE-bench 运行框架文章（2024）和 Managed Agents（2026）中均有详细说明——可以将其理解为三个同心层。

执行层刻意保持极简：一个用于运行命令的 Bash 工具，以及一个用于查看和修改文件的 Edit 工具。设计工作主要用于让这些工具不易出错——要求使用绝对路径、截断过长输出，并且只在字符串唯一匹配时应用修改——这样模型很少需要从本可避免的工具故障中恢复。

会话层是位于模型上下文窗口之外、持久且只追加的事件日志。每项操作和观察结果都会记录其中；模型上下文只是该日志的投影，而不是日志本身。这种分离让发生故障的运行框架进程能够重启并在任务中途继续执行，也让运行框架成为可随时替换的“牲畜”，而非需要精心照料的宠物。

编排层——Anthropic 称之为 “元运行框架”——通过明确的接口，将“大脑”（模型及其循环）与“手”（沙箱和工具）解耦。由于大脑不再位于执行容器内，沙箱可以按需配置，凭证则可存放在沙箱永远无法接触的保险库中。他们报告的收益是结构性的，而非表面的：p50 首个 token 时间缩短约 60%，p95 缩短超过 90%，因为会话不再等待那些可能根本不会使用的容器。

三个文档记录了这一演变：Building Effective Agents（2024）、SWE-bench 运行框架文章（2024）和 Managed Agents（2026）。

OpenAI 与 SWE-bench 团队合作创建了经人工验证的 Verified 划分，正是因为运行框架需要干净的任务：他们的标注工作（93 名开发者、1,699 个样本）发现，原始基准测试中 68.3% 的任务存在问题，移除这些任务后，测得的性能提升超过一倍。同一篇文章指出，仅运行框架的选择就让 GPT-4 在 SWE-bench Lite 上的成绩从 2.7% 提升至 28.3%——他们以这一差距说明，评测必须考虑社区构建的运行框架所带来的进展。

在开源方面，Codex CLI 提供了一套完整的参考运行框架。其架构采用分层设计，与本节其他系统相呼应：核心智能体循环负责规划和工具调用；沙箱层通过按任务配置的策略隔离执行；会话层持久化保存对话，以便恢复、分叉或压缩；工具层同时提供本地 shell 访问和基于 MCP 的外部工具。该引擎没有硬编码单一界面，而是通过三种入口提供服务——用于交互式工作的终端 UI、面向 VS Code 等富客户端的 JSON-RPC 应用服务器，以及面向云端沙箱的远程代码执行服务——因此运行框架既可在本地运行，也可通过编程方式驱动。该设计采用了研究文献建议的相同取舍：最简循环、强沙箱、明确的上下文管理，以及模型与外部世界之间清晰的边界。

借助 Agent Development Kit (ADK) 和 Agent2Agent (A2A) 协议——后者于 2025 年 4 月推出，已有 Atlassian、Salesforce、SAP 和 ServiceNow 等 50 多家技术合作伙伴加入——Google 正在将运行框架层产品化。A2A 标准化了智能体如何声明能力（通过 JSON 格式的“智能体卡片”）、管理长时间运行的任务、交换产物以及协商 UI 格式，使运行框架成为可互操作的基础设施，而非量身定制的粘合层。它明确旨在补充 Anthropic 的 Model Context Protocol (MCP)，后者标准化的是运行框架中的工具侧。

Microsoft 的 AutoGen 和 Magentic-One 提供的运行框架中，编排智能体负责管理事实与进度台账——这是一种已公开的设计，用于防止朴素运行框架中常见的无限循环。Meta 和 Hugging Face 的 GAIA 创建了一个通用助手基准测试，其运行框架评测需要网页导航和文件处理的真实世界问题；Hugging Face 的 Open Agent Leaderboard 则持续推动可比较、面向运行框架的排名。

DeepSeek Harness (dsh) 将元运行框架的理念进一步发展为可组合的形式。其架构构建于 Cordis 框架之上，核心主张是：运行框架的每个部分都是可替换插件——包括模型适配器、工具注册表、会话日志，乃至智能体循环本身。

该设计基于三个基本要素。第一，持久化会话日志，它是模型所见内容的唯一事实来源；任何送达模型的内容都必须能从日志中重建，并将此作为运行时不变量强制执行。第二，能力接缝：在智能体与外部世界之间设置可替换的提供方接口，因此只要将文件系统和子进程提供方指向远程沙箱，Bash、终端和语言服务器访问也会随之迁移，无需分叉运行框架。第三，明确的轮次/步骤生命周期，通过具名扩展事件（agent/pre-step、tools/execute、agent/turn-stopping）让插件能够拦截或重写循环，而无需修改核心代码。

其结果是对 Anthropic 元运行框架理念最接近的开源实现：结构不再是固定框架，而是可通过配置替换的插件组合。上线数月即获得超过 17 万 GitHub 星标，这表明智能体运行框架正在成为独立的产品类别。

它们共同遵循的模式是：保持循环简单，将一切置于沙箱中，记录每一步，并且绝不信任缺少其生成运行框架的分数。

截至目前，本节讨论的一切——最小循环、持久化会话日志、沙箱化执行、插件架构——都基于一个共同假设：智能体所处的环境是一台计算机。终端、浏览器、文件系统、仓库。运行框架的存在，是为了让智能体能够可靠地操作这台机器。

但上文梳理的研究轨迹指向了别处。τ-bench 将用户置于运行框架之中。METR 展示了智能体承担跨越数天而非数分钟的工作。OSWorld 和 WebArena 将环境从干净的仓库带入杂乱的真实世界。方向是一致的：当智能体从编程工具走向真正的工作助手，它们需要应对的环境不再只是硅基设备——还包括人。用户有预期，团队有历史，组织有权限和制度性知识。

这种转变最直接地落在运行框架的一个子系统上：上下文管理。终端会话只有一名操作者，历史记录也有限；而长期协作则涉及十位利益相关者、数月的决策，以及不断增长的仓库。文件系统是被动的；工作关系却由隐含承诺、未尽的想法和随口做出的选择构成，持续流动。所有这些内容在进入模型前都必须被摘要、压缩或丢弃，而每一项决定都可能让智能体失去任务所需的信息。

运行框架可以压缩，但不能任意压缩。因此，上下文窗口的大小不再只是模型规格，而成为运行框架的设计参数。

月之暗面的运行框架产品组合，将本文前文定义的结构映射到一套托管技术栈中。针对智能体 × 计算机问题，其运行框架扩展了标准循环：Kimi浏览器扩展 通过 Chrome DevTools Protocol 驱动真实浏览器会话，而非无菌沙箱；操作前询问这一接缝在文件系统层面确保用户同意；Agent 集群则将长程任务的编排能力扩展至 300 个子智能体。

驱动该循环的是 Kimi K3.1 Pro——K3.1 系列的首个模型，也是月之暗面迄今能力最强的 3T 级开源权重模型，上下文窗口达 1,048,576 token。其有三项特性与运行框架设计直接相关：

• 足以延后压缩的大窗口。 一百万 token 可同时容纳正在使用的仓库、运行轨迹和参考文档。运行框架仍会截断——它始终不得不如此——但摘要开始破坏信息的阈值被大幅推后，使长程任务不再在中途悄然退化。

• 作为运行框架调节项的推理强度。 K3.1 Pro 始终会进行思考，reasoning_effort 可取值 low、high 或 max，默认值为 max。这样一来，模型的推理成本便成为由运行框架按任务设定的预算，而非固定的准入成本。

• 在任务中途加入的工具。 动态工具加载允许运行框架在系统消息中注入完整的工具定义，因此工具从该消息起即可使用——无需重启，也不必在从未使用该工具的对话中每一轮都为其 schema 付费。

月之暗面将运行框架与模型一同报告，这正是本文主张的做法。在 Terminal-Bench 4.0 上——该基准在严格的任务专属测试下，评测编程智能体完成真实、资源受限终端任务的能力——K3.1 Pro 达到 65.7%，领先 GPT-6 Astra（58.2%），仅次于 Claude Opus 5.5（66.4%）。在用于评测多步骤执行、工具使用和端到端问题解决的内部基准 Kimi Code Bench 3.0 Long-horizon 上，其得分为 61.2%，而 K3 为 55.95%。文档同样明确指出反向的耦合关系：temperature 和 top_p 等采样参数是固定的，必须从请求中省略；并且每轮之间都必须原样返回完整的助手消息——若运行框架重写该消息，下一次工具调用所依赖的推理便会丢失。

同一模型覆盖整个产品面。你可以通过 Kimi Agent 体验托管网页版，借助 Kimi Work 运行完整的本地运行框架，在终端中使用 Kimi Code，或通过 Kimi API 直接调用 kimi-k3.1-pro。kimi-k3.1-pro-highspeed 变体以约两倍的 token 价格换取两到三倍的输出速度。

无论是在评估模型还是交付产品，以下清单都适用：

1. 从任务出发，而非从框架出发。 如果智能体需要编辑代码，SWE-agent 的 ACI 这类 Bash 加编辑器的运行框架已得到验证。如果它们需要操作 GUI 或实时网络，则需要真实会话观测和点击级操作。

2. 让环境可复现。 Docker 镜像、固定版本的依赖项和设定随机种子的数据，是基准测试与轶事之间的区别。

3. 有意识地规划上下文窗口预算。 观测截断、历史摘要和压缩都是直接影响分数与成本的运行框架功能——这也正是长上下文模型能够减少运行框架必须丢弃内容的原因。

4. 实施硬性限制。 每个任务的步骤上限、实际时间超时和金额预算，既能保证智能体安全，也能让评估具有可比性。

5. 从第一天起记录完整轨迹。 每个严肃的改进循环——人工审查、失败聚类、微调——都需要消耗轨迹数据。Anthropic 的 Managed Agents 和 DeepSeek Harness 更进一步：将会话日志作为仅追加的事件流保存在运行框架循环之外，这样运行框架本身可以随时替换，而模型的上下文始终能够重建。

6. 在不止一种运行框架上进行评估。 如果你的智能体只能在一种运行框架中工作，那么构建的就是依赖该运行框架的行为，而非能力。

7. 让凭据远离沙箱——或者完全远离云端。 将智能体的执行环境视为不可信环境；把 token 存入保险库并通过代理注入，或者在本地运行整个会话，使凭据和页面内容永不离开设备——这正是 Kimi 在其本地运行框架中采用的方法。

智能体运行框架已悄然成为智能体技术栈中最重要的一层。SWE-bench、mini-SWE-agent、Terminal-Bench 和 METR 的研究表明，运行框架设计的影响力足以媲美模型升级；DeepSeek Harness、OpenHands、SWE-agent 和 Aider 等开源项目，让每个人都能使用生产级运行框架；而 Anthropic、OpenAI、Google、Microsoft 和月之暗面如今都将运行框架工程视为一等工作。

但更深层的变化在于理念。第一代运行框架解决的是智能体 × 计算机问题：为模型提供可靠的双手，以操作终端、浏览器和文件系统。下一代则在解决这些环境带来的上下文问题——工作跨越数日、涉及多个利益相关者和仓库，而没有任何摘要器能够无损压缩这些内容。运行框架正从脚手架演变为操作环境，而它需要管理什么、模型又能直接容纳什么，两者之间的界线仍在不断移动。Kimi K3.1 Pro 的百万 token 窗口是当前最清晰的例子：模型的改变，消除了过去必须由运行框架完成的工作。

无论是自行构建、采用开源框架，还是运行生产级运行框架，真正能让智能体完成任务的，都是那些将运行框架视为需要工程化、版本化和可度量的软件的团队。