随着编码模型趋于商品化，真正的差异化因素在于框架：即管理工具、工作流、编排和模型路由的控制循环。供应商原生框架目前提供最佳性能，但随着模型的演进和成本下降，拥有一个可移植、与模型无关的循环可能成为更持久的优势。

掌控循环：智能体框架实用指南

框架与模型的契合度越高，你真正拥有的部分就越少。当今最强大的编码智能体都是模型-原生配对：前沿实验室将其最佳模型与自有框架配对。Claude Code 在 Anthropic 模型上表现最强，Codex 则在 OpenAI 模型上最强。

但这种契合是有代价的：让框架感觉神奇的那部分耦合，同样也将你的工作流绑定到单一供应商的模型、价格和产品界面上。当某个模型变得过于昂贵、宕机或完全被撤除时，你的工作流也随之失效。

而随着最佳模型的每次发布改进幅度越来越小，开放权重模型的能力爆发式增长，模型正在成为商品——这也是为什么现在决定智能体成败的是框架，而非模型。

因此真正的选择不在于哪个模型，而在于你要拥有多少比例的框架。我们通过绘制领域图谱来回答这个问题，从以下几点比较各个框架：

• 能力：模型与框架的契合程度，以及其生态系统的丰富性：可调用的工具、技能和集成。

• 自由度：切换模型的难易程度，以及你真正拥有工作流的多少。

• 工作流：每个框架实际服务于什么任务、什么用户？

所有分析都基于我们明确比较的内容；先建立基准：什么是框架？

每个框架都是一个循环

框架是模型运行的一个 while 循环。单独使用时，模型只回答一次就停止。在循环中，它会编辑文件、运行测试、读取失败信息、修复代码，然后重复，直到工作完成。

主流框架都是独立发展到这一步，最终汇聚到相同的一组组成部分。它们的不同之处在于一旦循环运行，由谁控制：两个框架可以共享相同的基本循环，但感觉完全不同，这取决于你是否能读取发生的事情、接入自己的工具、以及将工作流向前推进。这个差距正是本指南其余部分要测绘的。

框架图谱

我们将现有框架放置在两个坐标轴上，并为每个框架打分（满分10分）：能力有多强，以及你有多自由。

能力的评分依据：模型与框架的契合程度，以及生态系统丰富度——它带来了多少工具，以及能调用的技能、集成和支持。自由度则评估你的设置应对变化的能力：切换和混合模型的容易程度，以及你的循环有多少被困在单一供应商的平台上。

开源和自由不是一回事。Droid 和 Cursor 是闭源的，但几乎能运行任何模型。Codex 是开源的，但在任何可能的情况下都会试图将你拉向 OpenAI 的惯例和服务。

模型原生配对在能力方面领先，其次是开放-无关工具、Pi 和辅助优先的智能体。要么选择闭源、供应商优化的性能，要么转向可互换、可移植的工作流。

自由度：离开它有多难？

当模型选择不再定义优势时，框架的真正考验是可移植性。这归结为两个问题：你能审计并复刻代码吗？你的工作流（你构建的规则、集成和配置）是跟随你，还是被困在供应商的生态系统中？

供应商正通过将你的日常循环迁移到他们自己的服务上来主动扩大这一差距——让你在浏览器和终端之间携带一个实时会话，在桌面应用内运行一个兄弟智能体，将设计稿直接交给编码智能体——所有这些都流畅地跨越只有他们才能运行的界面。这些功能很强大，但目的是让你留在平台上。

社区工具没有这样的留存动机。由于它们可以复刻，因此不能在没有你同意的情况下重新定价、悄悄降级或限制使用。在一个每月自我重生的领域里，稳健的做法是保持模型可互换，并将你的工作流存放在你拥有的地方，这样你积累的知识才会跟着你。

能力：相同的模型，更好的智能体

使用同一个模型在不同框架上运行相同的任务，结果会大相径庭；模型在自己实验室的框架内运行时，分数通常高出几分。

这些高性能默认设置很诱人，但原生优势正在缩小。复杂任务中的任何优势都可以通过将正确的步骤路由到正确的模型来重新获得。

编排，而非原始模型性能，才是新的能力。模型各有特性；有些擅长规划，有些擅长执行。未来不是一个工具附着在一个模型上，而是一个管理者协调它们。这需要一个能无摩擦切换模型的框架，让你使用前沿模型进行高级规划，使用更便宜的开放权重模型进行机械性工作。

该用哪个

正确的框架取决于手头的任务。

最佳表现，但有代价。 如果你需要最强的模型原生编码循环、最丰富的扩展表面，请使用 Claude Code；如果你的工作已经存在于 OpenAI 的终端、IDE 和云中，请使用 Codex。这些是最紧密的模型-框架配对，也是大多数人的正确默认选择。代价就在名字里：契合度越高，你的工作流可移植的部分就越少，所以把你的指令和知识保存在你能拥有的形式中，并在仅云的界面上保持浅度使用。

拥有框架。 如果你想要开源 Claude Code 的感觉并内建供应商选择，使用 OpenCode；需要自托管 SWE 智能体平台，使用 OpenHands；需要供应商中立的通用智能体，使用 Goose；希望从最小循环开始构建，使用 Pi。这些是开放的、与模型无关的、属于你的框架。更多控制意味着更多设置，当模型成为商品、将每个任务路由到正确模型成为关键时，这一层级的价值就会体现出来。

留在 IDE 中。 如果你需要最佳的日常 IDE 界面并底层支持模型选择，使用 Cursor；如果 GitHub 原生功能就足够，使用 Copilot；需要内置编排的智能体优先 IDE，使用 Antigravity；需要每次编辑前都请求批准的开放智能体，使用 Cline。这些都优化于你工作的界面，而非对循环的控制。

交接或辅助。 一种不同的工作形态，专注于委托。Devin 是全自主的云工程师。Droid 是跨终端、IDE、桌面的智能体，可运行任何模型。OpenClaw 和 Hermes 是在你的聊天界面上始终运行的个人助理，具备记忆、日程和长期运行例程。OpenClaw 跨多个界面触达你，Hermes 将其记忆和技能跨模型提供商携带——这正是本指南的核心论点，融入了一个助手之中。

在成本不那么重要、开箱即用性能最关键的场景下，租用前沿模型是正确的选择。 保持一个开放、与模型无关的逃生路径，是对这个快速变化领域发展趋势的押注，因为廉价而强大的模型已经缩小了能力差距。

框架的未来

趋势都指向同一个方向：循环和供应商平台的统治地位。

• 一个位于框架之上的层正在形成。 元框架现在在一个界面背后组合多个编码智能体，在循环之上而非内部实施预算和权限，问题跟踪器正成为智能体集群的控制平面。这给框架带来的，正是路由器给模型带来的：它重新定位了所有权问题，而非解决它。你的路由策略是存在于开放运行时还是托管控制台，决定了你的编排是可移植的，还是被困在另一个你无法导出的平台上。

• 配对组合会过时。 每个组件都编码了一个关于模型独自无法完成什么任务的假设，而这些假设会腐烂。某个框架曾围绕一个在接近上下文限制时会偷工减料的模型构建了复杂的压缩和检查点机制。下一个版本不再需要这个拐杖，脚手架就变成了累赘。有人认为最终形态是一个最小框架，因为拥有循环意味着拥有在模型变动时重新适配它的能力。

• 框架开始自我改进。 框架现在可以从自身执行轨迹中改进，尽管增益分布不均。如果循环从它记录的内容中进化，那么轨迹就变成了资产，而你只有在拥有循环的情况下才能保留它。

拥有循环

持久的资产是你构建和完善的循环，在那里，人力和资本（token）不断积累。

模型是租赁的能力，而且越来越便宜。框架是控制循环，也是锁定效应。我们通常先选模型，让框架随之而来，但模型每隔几个月就换代，而框架是你一直保留的。运行它的技能也是如此：你在任何一个模型上学到的东西会随着下一个版本的发布而重置，而你在循环中学到的东西会在所有模型上累积。拥有循环，因为模型从来都不是你能永久拥有的。