框架并不重要

模型已过时，框架才是王道。廉价的开源模型让大型AI实验室风光不再，而像OpenRouter这样的模型网关使得切换模型的成本几乎为零。价值正向上游转移，进入操控这些模型的层面：即框架。

如果你已经了解框架是什么，可以直接跳到“什么不是框架？”部分。

什么是框架

原始LLM是一个无状态函数。它接收一些输入文本，比如“橙子是什么颜色”，并返回一些输出文本，通常类似于“你说得完全正确！”

框架只是围绕LLM的一个循环，使其能够被多次调用。

看，这就是框架！有了它，我们可以永远与LLM对话。唯一的问题是，LLM不会记得你一条消息前说过什么，因为它无状态。

为了解决这个极具挑战性的问题，我们最聪明的头脑聚在一起，想出了一个绝妙的解决方案：为什么不在每次调用时把整个对话都传给LLM呢？

现在，每次你与LLM交谈，它都会记得你之前说过的话。

不过还有一个问题。它只能以文本回应。我们如何让它真正做事？我们给它工具：

基本上就是这样。这就是AGI。它记得你说过的每句话，能继续对话，能解决数十年未解的数学难题，能在股市中创造数万亿美元的价值，能在Dax发推后一秒内回复。

从这里，你可以添加MCP、技能、记忆、子代理、bash，以及你见过的智能体所做的其他一切。每个现代框架都是这个循环的某种变体。这个循环就是框架。

什么不是框架？

接口或用户界面不是框架。不存在所谓的“iMessage 框架”或“Slack 框架”。接口只是向框架发送消息并显示返回内容的媒介。

像 OpenCode 和 Codex 这样的框架，通过实现客户端-服务器架构，将这一区别体现得相当清晰。OpenCode 的服务器运行框架循环，而其 TUI 作为客户端连接。Codex 的应用服务器对 Codex CLI、其桌面应用以及诸如 VS Code 扩展之类的接口起着同样的作用。一个 Slack 机器人接口可以像 TUI 一样与 OpenCode 服务器通信，这样你就能通过 Slack 使用 OpenCode 了。你甚至可以用 Codex CLI 作为 OpenCode 服务器的前端（我不知道你为什么想这么做，但我不评判）。

系统提示、工具、记忆系统、子代理、计划模式，以及几乎所有你关心的其他代理原语，也都不是框架。它们都归结为循环已经接收的同一个变量：系统提示和工具集。MCP 只是增加了更多工具，子代理只是一个启动另一个循环的工具，而技能、记忆和计划模式则改变系统提示并添加新工具。以上述示例中的玩具框架为例，放入 Claude Code 的系统提示，复现其工具定义和实现，你基本上就得到了 Claude Code 框架（实际上可能还好一点）。

能够编辑系统提示和工具是构建一个 harness 的基本要求。如果你能自定义这两样东西，那么你应该能够在不修改 harness 代码本身的情况下，几乎完全复现另一个 harness 的行为。例如，给 Pi 提供与 OpenCode 相同的工具和系统提示，它就应该表现得像原版 OpenCode，而无需改动 Pi 的任何 harness 代码。这里有一个我（即 Codex（即 gpt-5.6-sol））制作的仓库，确实做到了这一点，你可以并排查看两个 harness 的结果：https://github.com/omnara-ai/harness-equivalence

如果一个 harness 可以用来代表任何其他 harness，那这意味着什么？

harness 并不重要

真正重要的是你提供给 harness 的系统提示和工具，以及与之交互的界面。这才是所有关键所在。这才是所有价值流向的地方。不用谢，拿这个信息去股市里赚个几百万吧。

当然，这个论点依赖于一些我刻意忽略的重大假设。如果 harness 不是采用我们那聪明的“追加整个对话”算法，而是在每一轮都重建对话状态呢？它可以使用另一个 LLM 来决定哪些内容被修剪或强调，或者将困难任务路由给超级智能的 LLM，而将简单任务交给主力模型。你无法通过给 Pi 一个系统提示和一些工具来轻易复现这样的 harness，因为差异会存在于 harness 算法本身。

看来，这才是 harness 真正能够实现差异化并创造最大杠杆的地方。可以使用的算法太多了！

但不知为何，所有流行的工具框架在管理对话状态时，方式几乎如出一辙。它们同样不进行模型路由，行为都类似于上述简单的while循环。现有对话保持不变，新内容追加其后，再次调用同一个LLM。

这种情况短期内不会改变，原因在于提示缓存。

由于提示缓存的存在，调用LLM时，如果文本前缀与上一次调用完全相同，成本会低得多（这里解释了为何更便宜）。LLM提供商已为这部分对话完成了计算，因此只需处理后续新增的内容。哪怕改动一个字母，其后的所有内容都将从头处理，并按全价计费。在Claude上，未缓存的输入成本是读取缓存中这些token的10倍（Claude定价）。

由于大家都担心在已经高昂的模型账单上再多付10倍费用，几乎每个工具框架都竭尽全力避免错过缓存。最稳妥的方法就是保持现有对话不变，仅在其末尾追加内容。这就是它们最终都沦为相同基础循环的原因。

然而，总有一个时刻，缓存无论如何都会失效，此时工具框架便可以随心所欲地重建对话。

压缩

压缩可以说是当前各工具链之间最大的差异点，至少在性能相关特性上是如此。LLM 对可传入的对话量有限制，因此当对话接近该限制时，压缩会总结或移除旧部分，以便 LLM 能继续运行。完整对话仍可存在于日志中，但模型只能看到压缩后的版本。

压缩的实现方式可以随心所欲，因为提示缓存无论如何都会失效。工具链可以修剪旧的工具结果，或使用另一个 LLM 总结较早的对话，或仅保留最后几条消息，或采用完全不同的方法。可能性无穷无尽。压缩对于长时间运行的任务尤为重要，因为它决定了 LLM 随时间记住的内容。Codex 因其压缩功能而广受赞誉，该功能通过服务器端压缩实现。这会返回不透明的加密内容，因此你无法检查压缩内容，且该压缩内容仅适用于 OpenAI 的 API（我不喜欢这种锁定，但这并非重点）。无论他们使用何种算法，效果都很好，这也是长周期任务在 Codex 上体验出色的重要原因。

在实践中，大多数工具链最终采用相同的基本算法。它们用 LLM 总结较早的历史，保留最近的消息，有时会修剪工具输出。总结提示和截断点有所不同，但仅此而已。因此，即使压缩在各工具链之间也差异不大。在最坏的情况下，你只需给工具链提供一个可搜索其对话历史的工具，这就能弥补许多糟糕的压缩问题。

强化学习过的工具链

实验室的另一个论点是，Claude Code 和 Codex 具有优势，因为它们的模型是在这些确切的工具链内部训练的。但由于 Codex 和 Claude Code 都是开源的（懂的都懂），你可以将它们的系统提示和工具实现复制到 Pi 中，而模型不会察觉到任何差异。此外，如果 AGI 因为 edit 工具接受 path 而不是 file_path 而感到困惑，那我们或许应该卖掉手里的英伟达股票。

公开基准测试也显示，这其实是个势均力敌的局面。在 Terminal-Bench 2.0 上，GPT-5.5 使用 NexAU-AHE 得分 84.7%，使用 Capy 得分 83.1%，均高于其使用 Codex 时的 82.2%。当前的 Terminal-Bench 3.0 排行榜由运行在 mini-SWE-agent 中的 Opus 5 以 42.7% 的成绩领跑，领先于榜单上所有原生模型-工具链组合。Terminal-Bench 2.1 则呈现相反趋势，原生工具链组合占据上风。

原生工具链有赢有输，而且输赢的时机和原因相当随意。在特定工具链内训练模型可能会让模型对这些工具更熟悉，但无论这种优势最初是否存在，随着模型能力的提升，它只应逐渐缩小。

结论

你无需自行构建测试框架，也不必为所有测试框架再搭建一个框架。我写这篇文章，是因为我不断看到有人在X平台上将测试框架本身视为某种深度优化问题，而我认为大多数人只需选用一个优秀的框架并继续前行，就能节省大量时间（直接用Pi就行，兄弟）。专注于你提供的系统提示和工具，以及你如何与其交互！