一个开放、按 token 预算的 Augment Context Engine 替代方案

它们的共同点

Augment Code 和 Context Engine 解决的是同一个底层问题：编码 agent 读不完你的整个仓库，而暴力搜索既浪费 token 又占满上下文。两者都为代码库建语义索引，并通过 Model Context Protocol（MCP）暴露给 agent，让它「按需要问上下文」而不是 grep。

如果你用过 Augment 的 Context Engine MCP 并认可这个思路，Context Engine 会很眼熟——区别在下面的细节里。这个共同的底子——通过 MCP 暴露一套语义索引——也是为什么在两者之间做评估只要几分钟，而不用重写 agent 的工作方式。

Context Engine 的不同之处

Context Engine 围绕「每次调用你都能控制的 token 预算」来设计，返回文件级片段而非整文件——于是你能给每次检索的成本设上限。它对任意兼容 MCP 的客户端只暴露一个工具 codebase_context：Claude Code、Cursor、Codex、Windsurf 等都能接。登录走 GitHub，且有免费额度，让你先在自己的仓库上评估再决定。

• 每次检索一道硬性 token 预算，以文件级片段返回
• 兼容任意 MCP 客户端，不绑定某一个 IDE 或 agent
• 只需理解一个工具——codebase_context——没有别的要接
• GitHub 登录，注册即送免费额度
• 增量同步 + 持续调优检索质量的反馈闭环

什么时候 Augment Code 更合适

Augment Code 是一个更宽、更偏企业的平台，自带 agent 与 IDE 集成，如果你要的是一套带厂商支持、企业级规模的一体化编码助手，它是很强的选择。Context Engine 刻意做得更窄：只做一件事——通过 MCP 提供按 token 预算的代码库上下文——让你保留已经在用的 agent。按你想要的工作方式来选；你甚至可以让 Context Engine 与另一个助手并行使用，先在自己的任务上对比再决定用哪个。

为什么我们做了一个更窄的工具，而不是一整套平台

Augment Code 的定位很宽:agent、IDE 插件、上下文引擎打包在一起。如果你想要一个厂商包办整条工作流,这是合理的选择。Context Engine 的出发点更窄——我们觉得这套组合里「决定 agent 能看到哪些代码」这一层,值得单独做好,并开放给你已经在用的任意 agent,而不是绑定一个新 agent 一起卖给你。

这个取舍体现在你要配置什么、不用配置什么上。不用装单独的 IDE,不用换 agent,也不用重新学一套工作流——只是一个 MCP 工具,把按 token 预算的上下文包返回给调用它的客户端。如果你已经用得顺手的是 Claude Code、Cursor 或别的 agent,这是你可以叠加的一层,而不是要迁移过去的平台。

去试它是一次评估,不是一次迁移

在 Augment Code 或任何别的工具旁边试 Context Engine，不需要先拆掉什么。加一段 MCP 配置，指向同一个仓库，跑几个你平时会跑的任务——追踪调用点、做一次重构、找一个 bug。因为每次调用返回的 token 预算和片段都是可见的，你能直接对比成本和答案质量，而不是只听某一方的一面之词。