月费20美元 vs 年费百万美元：AI编程Agent的两种范式

Cursor每月只需20美元，而某些企业级AI编程工具每年可以向企业收取高达500万美元。听起来它们像是同一赛道的竞争对手，实际上二者根本不在玩同一个游戏。这篇文章基于一位B站UP主的实测视频展开——他把两款工具同时放到拥有约300万行代码的开源项目Grafana上，去修复一个从社区提出至今、始终没被解决的功能需求，借此揭示两种AI编程范式的本质差异。

两种截然不同的工作单元

要理解这场对比，先得建立一个心智模型。Cursor、Claude Code、Copilot这类工具，工作粒度停留在函数、文件、或者一个小型功能上。典型场景是你开一个会话，全程盯着它工作，一边看它改代码一边给出指令，是一种高度迭代、人在回路（human-in-the-loop）的模式。

而视频中演示的Blitzy则完全相反，它的工作单元是整个项目。它可以连续运行数天，你要做的不是逐行审查它的编辑，而是在前期花大量时间打磨计划和提示词，明确告诉它要达成什么目标，然后批准一份行动方案，剩下的交给它去跑。几天后，它交回一份几乎完全成型的成果。

这两种工具本质上代表了两个完全不同的"工作单位"——一个是小步快跑的协作助手，一个是重前期规划的自动化工程系统。这也解释了为什么后者主要被企业采购，而非个人开发者。

上下文窗口：分歧的根源

为什么会存在这种割裂？答案归结于上下文。当一个Agent在处理你的代码时，所有东西都在争夺同一个上下文窗口：系统提示、工具定义、技能、对话历史……等到它真正开始编辑文件时，能同时容纳的可能只有5000到10000行代码。

这不是产品缺陷，而是Agent工作方式的数学限制。当前最大的上下文窗口约为100万tokens，根本装不下300万行代码。那么Cursor这类小型Agent是如何在庞大代码库上工作的？答案很简单：你就是那个缺失的上下文。你了解架构，知道哪三四个文件是关键，你把Agent指向它们，它就能干得漂亮。

但前提是——这必须是你自己的、你理解的代码库。一旦换成一个你从未见过的300万行代码库，你不知道哪些文件重要，不知道该遵循什么约定，Agent和你一样是"睁眼瞎"。它没法一次性把整个代码库的信息吃进去，如果你自己都不清楚，它也给不了你想要的结果。

上下文窗口（Context Window）是指大语言模型在单次推理中能够"看到"的最大文本量，通常以token计量（1个汉字约等于1-2个token，1行代码约为5-15个token）。这个窗口不仅容纳用户输入，还要装下系统提示、工具调用记录、对话历史和模型输出，实际留给代码的空间远小于标称上限。当Agent需要搜索相关文件、调用外部工具时，这些操作本身也会消耗上下文空间，形成一种"越工作越拥挤"的挤压效应。这也是为什么即便GPT-4等模型支持128K tokens的窗口，在处理大型代码库时依然捉襟见肘——工程级别的代码库动辄数百万行，远超任何当前模型的单次处理能力。

Blitzy的暴力解法：先逆向工程整个代码库

Blitzy针对的正是这个问题。在写下第一行代码之前，它会花上数天时间摄取整个代码库，把它逆向工程成一张知识图谱，理解每一个服务、每一个奇怪的约定，甚至是很多年前某人加进来的遗留代码。然后，它针对这份理解运行成千上万个Agent，而不是只在代码库的一小块视图上工作。

它会先生成一份庞大的技术规格文档和知识图谱。视频中展示的这份技术规格长达300到400页，包含系统架构、数据流、依赖关系、所用技术栈，还有大量mermaid图表、流程图和时序图。这些内容若人工整理需要极长时间。

有意思的是，Blitzy自己的工程师每天也在用Cursor和Claude Code。真正的差异不在于用了哪个更强的模型——他们会把多个模型融合使用，甚至包括已经不是前沿的旧模型。智能藏在系统编排里，而非原始的"脑力"中。换个LLM进去，结果不会有天翻地覆的变化，因为系统本身的设计才是关键。

知识图谱（Knowledge Graph）在这里指的是将代码库中各个模块、函数、服务之间的依赖与调用关系结构化表示的数据库，类似于给整个项目绘制一张"神经网络图"。Blitzy通过静态代码分析、AST（抽象语法树）解析和语义理解，将原本散落在数千个文件中的隐性知识——例如某个接口的历史演变、某段遗留代码的副作用——显式地编码进这张图谱。后续运行的成千上万个子Agent可以查询这张图谱，而无需每次都重新"阅读"原始代码，从而绕开了单个上下文窗口的容量瓶颈。这种"先建索引再执行"的架构思路，与搜索引擎爬取网页后建立倒排索引再响应查询的逻辑如出一辙。

实测Grafana：修复一个悬置多年的老需求

测试对象是Grafana社区里点赞数最高的一个issue。Grafana是一个非常流行的数据可视化平台，可以查看日志、指标、告警等。这个需求早在多年前就有Grafana贡献者回复过："听起来很有用，但暴露变量这件事相当复杂又耗时。"于是它就一直没被实现。

具体问题出在**播放列表（Playlist）**功能上。用户希望播放列表能在kiosk模式下，按照设定顺序在不同服务器（server A、B、C）和不同仪表盘之间循环切换。但实测中，它始终卡在server A，无法正确遍历host变量里的多台服务器，切换顺序也很混乱。

UP主坦言这不是一场公平对比，而这恰恰是重点。他给Cursor配上了当时的顶配模型和最高思考模式（maximum），贴入详细提示词和原始issue链接。Cursor按其一贯方式，一次处理一个文件，慢慢推进。

能跑 vs 能合并：差距在细节里

结果出人意料——Cursor版本竟然真的跑通了。修改了约26个文件、300行左右代码，涉及schema、存储桥接、编辑器、播放逻辑，还写了几个测试，看起来干净利落。playlist在kiosk模式下成功地从server A切到B再切到C。

Blitzy同样解决了问题，但PR规模完全不在一个量级：改动了83个文件，19000行新增、460行删除（其中很大一部分是markdown文档）。真正的差距在于那些"你根本想不到"的细节：

• 集成测试，以及断言"旧的播放列表能逐字节序列化成与之前完全相同"的测试，确保存量用户不受影响；
• 更新了OpenAPI规范的两个版本；
• 添加了翻译字符串、用户文档，并附带关于变量值会出现在仪表盘URL中的警告；
• 明确定义了限制：最多32个变量、每个变量64个值，超出会被拒绝并明确指出出错字段，还配了11个case的测试组来验证。

作为对照，UP主测试Cursor的版本发现它接受空变量名、允许单个变量塞进500个值、字段完全没有校验。在本地跑没问题，但推到生产环境，这些都是可能引发线上事故的隐患。

值得强调的是，Blitzy并不替代开发者。它会告诉你"完成了约250小时的工作，还剩44小时"——这些剩余工作大多是可选的验证与测试，你仍需拉下代码亲自把关。此外，当你合并PR后，改动会同步回git分支，并自动更新技术规格，让知识图谱始终保持最新。

OpenAPI规范（OpenAPI Specification，前身为Swagger）是描述RESTful API接口的标准格式文件，通常为JSON或YAML格式，定义了每个端点的请求参数、响应结构和数据类型。在大型团队协作中，OpenAPI文件是前后端联调、自动生成SDK以及接口测试的基础契约。一旦代码逻辑发生变化但OpenAPI文件未同步更新，下游服务的集成测试就会失败，甚至引发生产事故。Blitzy在PR中同步更新两个版本的OpenAPI规范，体现的正是"可合并"与"能跑"之间的本质差距：前者考虑的是整个系统的一致性，而不仅仅是本次改动的功能正确性。

结论：不同目标下的不同价值

这两款产品有着完全不同的目标，而且都达成了各自的目标。Cursor给你一个能跑的演示，成本低、交互灵活；Blitzy给你一个能在企业代码库里直接合并的PR，前期投入重、耗时长，但对企业而言价值截然不同。

一个可运行的demo很棒，但对于300万行的企业级代码库来说，一个真正可合并、经得起生产考验的pull request，才是那笔百万美元预算真正买单的东西。理解这一点，也就理解了为什么这两类工具其实并不构成直接竞争——它们服务于开发流程中的不同环节。