Augment 如何重写 Auggie CLI harness，使任务成本比 Claude Code 低 53%

你花费的每一个 token 都应该尽可能换来更多完成的工作，这是 Cosmos 和 Auggie CLI 背后的核心原则之一。早在它体现在任何面向客户的东西之前，它就已经在驱动工程决策了。每个 token 的价值有两个  杠杆。一个是上下文引擎：更好的上下文意味着用更少的 token 得到更好的答案。另一个是 harness：agent 循环、工具面、会话管理，以及一切将模型能力转化为完成任务的东西。我们首先构建了业界领先的 上下文引擎，现在我们又在改进 harness 上做了重大投入。

今年早些时候，我们从零开始重建了 Auggie CLI 的 harness。在 SWE-bench Pro 上，在相同的通过率下，Auggie v2 完成一个任务花费 $1.27，而 Claude Code 花费 $2.70。这便宜了 53%。尽管 v1 已经比 Claude Code 便宜 27%，但我们知道还能做得更多，这次重建大约将效率差距翻了一倍，同时没有牺牲任何质量。

达到这一点花了三个月有意识的原型设计，最终以 fork Pi 收尾——这是 Mario Zechner 开发的一个出色的极简开源编码 harness——并将我们的上下文引擎移入其扩展系统。主要的心得是：做减法。更少的工具意味着每次调用的负担更小，而一次好的检索能省下十轮探索。

为什么要重新审视一个获胜的 harness

第一个 Auggie CLI 于 2025 年底发布，从一开始就在基准测试中具有竞争力。重建一个正在获胜的东西需要一个比不安分更好的理由。我们有两个。

第一个是，harness 编码了关于模型不能做什么的假设，而模型能力发展得如此之快，以至于这些假设需要被频繁地重新审视。V1 的宽工具面对于它所针对的模型来说是合理的。工具的数量、它们 schema 的大小、循环的形状：所有这些都会被序列化到每一个请求中，而每一次能力跃升都会改变哪些部分仍然有帮助、哪些现在成了客户每次调用都要为之付费的开销。  结果证明这正是大部分钱花掉的地方，所以我会再回到这一点。

第二个原因是结构性的。V1 增长得很快；几个月内它就有了大约 1,020 个 TypeScript 文件和 250k 行代码，并且它有着每个快速增长的代码库都熟悉的失败模式：耦合。TUI、agent 循环、会话持久化和工具实现彼此都相互了解。更改进程管理工具意味着要动渲染器。更改检索意味着要动 agent 循环。每个新功能的成本都比上一个略高一点。

一月份，我们开始研究 v2 应该建立在什么之上。

量两次

我们花了一月到三月评估基础，节奏是有意为之的。CLI 是开发者每天体验 Augment 的方式，而更换它的基础是那种需要量两次再下刀的改动。

第一个原型是在一月份基于 Vercel AI SDK 的。它非常擅长它被设计来做的事情：流式原语和提供商抽象。我们被那个方案吸引，是为了支持另一个核心原则——模型无关，但它是一个 LLM SDK，而不是一个 agent harness，所以对我们的用途来说，agent 循环、工具编排、会话持久化、压缩以及整个 TUI 都得由我们自己编写和维护。我们构建了足够运行评估的部分，但结果并不足以证明我们永远要拥有的那些 harness 代码量是合理的。

第二个原型是在二月份基于 Mastra 构建的。这个原型进展很大：基于 OpenTUI 和 React 的 TUI、带语法高亮的流式 markdown、我们的代码库检索集成、主题化。Mastra 是一个能力很强的框架，但它面向的是一类比终端编码代理更广泛的代理应用，所以我们仍然要自己编写大部分困难的部分。而且用 React 协调器来驱动终端，对于 CLI 所需来说依赖太多了。

第三个是在三月份基于 Pi 构建的。Pi 是 Mario Zechner 开发的一个极简终端编码工具，已经在其他生产代理中得到验证。在架构上，它完全契合我们的问题：小巧的核心、我们真正可以构建其上的扩展系统，以及一个专为终端打造的 TUI 库，而不是一个面向终端的 Web 框架。

Pi 究竟是什么

Pi 不是单体式架构。Auggie v2 由三个小包加上一个扩展层组装而成：pi-ai，一个跨主要提供商的统一 LLM API；pi-agent-core，带有传输抽象和状态管理的代理循环；以及 pi-tui，终端 UI 库。

渲染也尝试了三次

V1 使用了 Ink，这是 2024-2025 年构建 Node CLI 的默认选择。Ink 底层运行 React 和 Yoga 布局引擎。两者都很可靠，但它们在转录内容和终端之间加了两层，所以每个渲染 bug 都变成了一场需要穿过 React 协调器和 flexbox 引擎的调试过程。而且还有一些我们从未设法绕过的限制：整个转录内容重绘时会闪烁，布局偶尔也会出错。

AI SDK 和 Mastra 原型转向了 OpenTUI，它维护一个虚拟终端缓冲区并使其与真实缓冲区保持同步。这解决了闪烁问题，但在此过程中你放弃了原生缓冲区：转录内容不再是终端回滚缓冲区中的纯文本，因此点击链接和选择文本进行复制不再像终端用户期望的那样工作。OpenTUI 对两者都有变通方案，但它们以一种用户体验换取另一种，而且并非所有人都认同这一改变。

pi-tui 的机制是三者中最简单的。一个组件渲染为一个字符串数组，每行一个字符串。每一帧，TUI 将新行与上一帧的行进行差异比较，只重绘发生变化的行，并用同步输出（CSI 2026）包裹，这样终端会完整显示每一帧，而不是只画一半。输出是原生终端缓冲区中的普通行，因此回滚、链接点击和文本选择都像以往一样正常工作。路径中没有协调器或布局引擎。当渲染出错时，bug 就在一个返回字符串的函数里。

有了坚实的基础，我们就可以利用扩展系统让 Auggie 真正成为 Auggie。

扩展模型

扩展是模块，它们通过利用一个简单的 API 来拦截生命周期事件、添加 UI、自定义渲染等，从而扩展 Pi 的行为。

我们专有的上下文引擎本身就是一个扩展。它通过 pi.registerTool() 注册 codebase-retrieval 工具，并通过事件总线接收共享的 Augment API 客户端，没有在工具框架中刻入侵入式钩子。我们最大的差异化功能通过社区包也会使用的同一个公共 API 接入。

它还直接解决了耦合问题。更改上下文引擎不会触及 packages/pi-extensions/context-engine/ 之外的任何内容。该仓库自己的贡献指南现在建议优先在 packages/pi-extensions/* 中进行更改，因为功能以扩展 PR 的形式落地，而不是对核心进行手术式修改。Auggie v2 目前提供十多个第一方扩展，包括 context-engine、subagents、lsp、mcp、tool-permissions 和 plugins。每一个都是自包含的包，带有自己的测试，由宿主通过单个 index.ts 导入。

回报是可衡量的：架构稳定后，我们的提交率大约翻了一番，从 5 月的 92 次提交增加到 6 月的 221 次，子代理、LSP、插件市场、带 OAuth 的 MCP 以及 ACP 编辑器支持都以独立的扩展 PR 形式落地。

每个 token 的价值从何而来

发布速度很少足以成为重写软件的理由，我们着手通过这个新平台来提高效率。

先看 SWE-bench Pro 表格（731 个实例，三个代理均使用 opus4.7）：

SWE-bench Pro：与 Auggie v1 和 Claude Code 相比，Auggie v2 在保持通过率的同时降低了成本和墙钟时间。

通过率彼此相差在一个百分点以内，因此质量相同。在相同的任务集上，v2 比 v1 少用约 32% 的输出 token，缓存读取流量少约 38%。按实例计算，它在 88% 的任务上比 v1 更便宜，在 97% 的任务上比 Claude Code 更便宜。

SWE-bench Pro 上每个实例的成本与时间：Auggie v2 比 Auggie v1 和 Claude Code 都更快、更便宜。

有三个因素驱动了这一点，其中最大的是工具面。V1 为所有事情都暴露了一个专用工具：launch-process、read-process、kill-process、str-replace-editor、save-file 等等。但如今的模型不再需要那种性质的专用工具。V2 给模型一个 bash 工具和三个文件工具，read、edit 和 write。这种收窄在每次请求中带来双重回报。每个工具 schema 都会被序列化到每次 LLM 调用中，因此宽泛的工具集在整个会话生命周期内都是对缓存读取 token 的持续征税。它还会引入编排开销，模型花费输出 token 来挑选和排序狭窄的工具，而一次 bash 调用本可以完成这项工作。

用检索代替探索是第二个因素。上下文引擎的 codebase-retrieval 在单次调用中回答跨文件问题。没有它，代理会耗费轮次遍历目录并读取文件来重建相同的图景，为此花费输出 token 和墙钟时间。这也是速度优势叠加的地方：更少的轮次，更短的会话。平均墙钟时间为 330 秒，而 Claude Code 为 409 秒，整个基准测试从 83 小时降至 67 小时。

压缩是第三个因素。我们再次利用 Pi 的扩展系统，将压缩变成一个专用子系统，而不是像许多其他 harness 那样作为回退行为。它用专门的更便宜的模型总结较早的历史，逐字保留第一条用户消息，以便原始任务在总结后仍然存在，并在达到限制之前主动触发，而不是对溢出错误做出反应。

在 Terminal Bench 2.0 上，同样的架构在成本下降的同时提升了质量。任务通过率从 70.8% 提升到 74.2%，每个通过试验的成本从 $1.26 降至 $1.11。

Terminal-Bench 2.0：与 v1 相比，Auggie v2 提高了任务和试验通过率，同时降低了每次试验的成本。

开源的力量

我们对 pi-mono 的分叉不仅仅是一个快照：我们在自己的命名空间下重新划分了包的范围，并且仍然同步上游的改进，最近的是 pi v0.74.0。更新日志的第一行说明 auggie-v2 是从 pi-mono 的 coding-agent 包分叉而来，并链接到上游更新日志以了解分叉前的历史。

Pi 是优秀的作品，其维护者的设计原则——保持一切最小化，不要复杂化已经足够的东西——正是这次重建在两次尝试停滞之后得以成功的原因。Pi 也在生产环境中得到了验证。致 pi 社区：谢谢你们，而且由于 pi 包通常能与 Auggie 配合使用，如果你构建了一个，不妨试试。

推出

Cosmos 云代理现在正在获得 v2。用户体验刻意保持不变，因此你在不知不觉中继承了 token 效率。CLI 的推出将在 9 月/10 月进行：v2 成为 Auggie CLI，v1 被弃用。可见的差异是 TUI，无闪烁、转录 markdown，以及将大段粘贴折叠为紧凑 [paste #1 +45 lines] 行的粘贴标记，还有扩展驱动的功能集：/fork、插件、技能、子代理、带 OAuth 的 MCP 和 LSP。

质量相同，成本约为领先替代方案的一半，并且在一个基础上，下一个功能的构建比上一个更便宜。这类收益正是你做出大胆决定从头重建的原因。