Blitzy 以 14 亿美元估值募集 2 亿美元，他们称之为超大规模代理编排 — 构建企业 codebase 的动态知识图谱，然后针对该表示并行部署成千上万的代理。关键数字：SWE-Bench Pro 66.5%(更难的变体,与大多数 lab 基准测试的 SWE-Bench Verified 子集不同),支持从 1 百万到 1 亿行代码的 codebase,每次 run 在 Google、Anthropic 和 OpenAI APIs 上有 10 万+ 次底层模型调用。平台声称在十个行业有数十家 Global 2000 企业客户,尽管具体名字未披露。架构上,这是与当前主导 builder 心智份额的单代理-CLI 类别的重大分歧 — Cursor、Claude Code、Aider 都跑单个代理做顺序推理。Blitzy 做的是带 KG grounding 的舰队规模编排。
要标注的技术架构:把现有 codebase 反向工程成结构化知识图谱是舰队规模代理工作的前提条件。没有那个表示,并行代理就会互相踩脚(同一文件被编辑两次)并在 codebase 上下文之间丢失上下文。KG 让编排器分区工作 — 代理 A 处理 auth 相关变更,代理 B 处理 billing,等等 — 而不需要每个代理都把完整 codebase 放在它的上下文中。每次 run 10 万次模型调用是成本驱动和差异化:大多数生产编码代理每个任务做 50-200 次调用。10 万次调用意味着大规模并行探索、候选生成、投票和验证,而不是顺序的 chain-of-thought。这种方法的 SWE-Bench Pro 66.5% 与 Sonnet 4.5 + Claude Code 在 SWE-Bench Verified 上达到的 82%(带并行测试时计算)是有竞争力的,但 Pro 更难所以直接比较不干净。未披露的:任务分解实际上如何工作(基于规则、学习、混合?)、每完成的延迟是什么(并行 run 应该在 wall-clock 上快,但 10 万次 API 调用意味着真正的成本)、KG 过时或错误时的失败模式,以及编排器如何处理代理分歧。
生态读法:企业编码代理正在分叉为两种架构。单代理-IDE 类别(Cursor、Claude Code、Windsurf)针对开发者坐着的紧密循环进行优化 — 快速迭代、频繁纠正、每任务低成本。Blitzy 和 Devin/Cognition 类针对「给我们一个规格,明天回来」进行优化 — 每任务高成本、循环中没有开发者,但适用于大规模重构和功能构建,这是单代理设置无法在一次会话中现实地处理的。Blitzy 瞄准的 1M-1 亿 LOC 范围是企业最佳点 — codebase 太大以至于单个 Cursor 会话无法在上下文中保持,KG-grounded 方法在那里有清晰的架构理由。10 万 API 调用经济意味着每次 run 的单位成本在数百到数千美元,这只对实质性交付物有意义,而不是交互式编辑。对评估代理平台的 builder,问题变成你的工作是「开发者需要协助」(单代理)还是「规格需要实施」(舰队) — 它们不是替代品,是不同的类别。
实际动作:如果你运行 Global-2000 级别的工程组织,代码库超过 1M LOC 且有重复的大规模重构工作,Blitzy 现在在评估池中。要求关于 KG 准确性 claim 的具体证据 — 错误描述 codebase 的知识图会以事后调试昂贵的方式静默破坏并行代理决策。在典型企业 codebase 规模的每完成成本、生产部署的错误率(不是基准分数)和编排确定性问题(同一输入的两次 run 是产生相同补丁还是不同的?)上钉住他们。对运行较小 codebase 的 builder,Cursor/Claude Code 单代理设置仍然是正确的工具 — Blitzy 的架构只有在并行优势超过编排开销时才能自付,这只在过了某个 codebase 规模才会启动。SWE-Bench Pro 66.5% 很有意思,但在独立 harness 报告之前不是可移植的信号;这是一家公司的数字,eval-honesty 纪律说要看复制。