AI 智能体生态 W29：控制平面分化与代码图谱 Token 缩减
2026 年 7 月，三种智能体控制平面架构同时分化：Mozilla Otari（网关中心）、Google Genkit Agents（框架中心）、Vercel Eve（沙箱中心）。代码图谱 MCP 工具实现 8-120x token 缩减。802 名开发者的纵向研究揭示审查瓶颈成为新结构性约束。
AI 智能体生态 W29：控制平面分化——Mozilla Otari、Google Genkit Agents 与 Vercel Eve 重塑基础设施层，代码图谱 MCP 攻击 Token 成本螺旋
TL;DR: 2026 年 7 月，三种截然不同的 AI 智能体基础设施控制平面架构同时出现——网关中心（Mozilla Otari）、框架中心（Google Genkit Agents）和沙箱中心（Vercel Eve）——各自解决不同的生产失败模式。与此同时，代码图谱 MCP 工具通过将代码库预索引为持久化知识图谱实现 8-120x token 缩减，一项 802 名开发者的纵向研究揭示 AI 编码吞吐量已达 2.09x，但审查瓶颈已成为新的结构性约束。
摘要
2026 年 7 月 7-13 日这一周，智能体基础设施发布密度前所未有：三天内五项以上重大公告，表明市场已达到临界规模——供应商必须尽快发布，否则将被锁定在新兴标准之外。但最重要的结构性变化不是发布数量——而是控制平面层本身的架构分化。
Mozilla 的 Otari、Google 的 Genkit Agents 和 Vercel 的 Eve 代表了管理智能体基础设施的三种根本不同的哲学。Otari 将自己定位为网关中心控制平面，位于应用程序和 LLM 提供商之间，管理路由、预算和治理。Genkit Agents 采用框架中心方法，将整个智能体生命周期——会话、流式传输、持久化、人工审批——打包为单一应用原语。Eve 采用沙箱中心模型，使用文件系统约定和隔离执行环境来强制数据控制和审计合规。
这种分化与 W28 识别的智能体框架整合模式截然相反。控制平面层不是收敛于主导架构，而是分裂为专业化阵营，每个阵营针对生产可靠性问题的不同切片进行优化。企业采用者面临一个新决策：哪种失败模式最重要，哪种架构能解决它？
同时，一类新的代码图谱 MCP 工具——Skeletree、code-review-graph 和 Codebase-Memory——正从不同角度攻击 token 成本螺旋。这些工具不是在运行时层限制 token 消耗（如 CLRK/Restate 流量控制），而是通过将代码库预索引为持久化知识图谱来从源头减少上下文，智能体查询图谱而非读取整个文件。声称的缩减范围从 8x 到 120x，早期基准测试表明节省是真实的，但取决于架构。
arXiv 的 2x 吞吐量纵向研究（802 名开发者，196,212 个 PR，28 个月）验证了控制平面和代码图谱都在响应的生产转变。人均吞吐量达到 2.09x——但人均审查者负载也大约翻倍，自动化审查在数量上超过了人工审查。瓶颈已从生成转移到审查，基础设施现在必须解决审查吞吐量，而不仅仅是生成速度。
背景
上周的 W28 分析识别了三个结构性转变：框架整合、协议收敛和网关控制平面作为独立基础设施层的出现。网关控制平面——以 CLRK/Restate 的智能体运行时管理流量控制为代表——被定位为框架和协议之后下一个成熟的层。
W29 揭示控制平面层正在成熟，但不是通过收敛。相反，它正在分化为三个架构阵营，每个阵营对”控制”在智能体基础设施语境中的含义有不同的心智模型。这种分化是健康的——意味着市场正在探索解空间，而不是锁定在过早的标准上——但它为企业采用者创造了新挑战，他们现在必须评估的不仅是使用哪个产品，还有哪种架构哲学与他们的生产失败模式一致。
时机很重要。7 月 7-9 日三天内五项重大智能体基础设施发布：SnapLogic MCP Builder GA、JetBrains AI for Teams、Harness Autonomous Worker Agents、IBM Bob 多智能体 + Bobalytics 和 Couchbase AI Data Plane。这种密度表明市场已达到拐点——问题不再是”我们应该构建智能体基础设施吗？“而是”我们应该采用哪种架构？“
分析
控制平面分化：三种阵营，三种失败模式
本周出现的三种控制平面架构不是同一设计的竞争实现——它们是解决同一问题的根本不同方法，各自针对不同的生产失败模式进行优化。
网关中心：Mozilla Otari
Mozilla.ai 于 7 月 6 日推出 Otari，作为开源 LLM 控制平面。Otari 位于应用程序和 LLM 提供商之间，提供路由、预算、治理、部署和可靠性的单一层。其关键差异化是明确区分”网关”和”控制平面”：网关处理执行和连接，使用静态路由和调用后 token 统计；控制平面处理策略和决策，使用动态路由、请求前预算强制和跨所有应用的全局策略。
Otari 的架构解决成本治理和提供商可靠性失败模式。当一个组织跨多个应用运行多个 LLM 提供商时，独立管理每个应用的路由逻辑、API 密钥、使用跟踪、预算强制和故障转移的操作复杂性变得不可持续。Otari 将这些关注点集中到位于应用和提供商之间的专用控制平面。
Agent Harnesses 功能特别值得注意——它为构建智能体就绪应用提供内置工具和编排，将 Otari 定位为不仅是被动网关，而是主动智能体基础设施层。开源策略（Python 98.4%，v0.2.0，GitHub 上 333 次提交）以社区驱动的替代方案挑战 Portkey 和 Helicone 等专有网关。
框架中心：Google Genkit Agents
Google 于 7 月 1 日发布 Genkit Agents API 预览版，采取了根本不同的方法。Genkit Agents 不是位于应用和提供商之间，而是将整个智能体生命周期打包为单一应用原语。chat() 接口抽象了消息历史、工具循环、流式传输、会话持久化和 HTTP 服务——对话式 AI 功能所需的一切，都在一个 API 之后。
Genkit 的架构解决开发者体验和全栈集成失败模式。当团队需要构建对话式 AI 功能——支持助手、审批工作流、任务副驾驶——消息历史、工具执行循环、流式更新、会话持久化和前端线协议的管道在每个项目上重复。Genkit 通过将其打包为框架级原语来消除这种重复。
Google 的定位很有启发性：Genkit 用于”向现有应用添加智能体功能”，而 Agent Development Kit (ADK) 用于”复杂独立多智能体系统”。这种区分映射到框架中心与平台中心的分界——Genkit 将智能体嵌入应用，而 ADK 用智能体构建应用。
Agents API 支持带自定义状态和产物的会话、文本和状态补丁及工具中断的流式传输、通过会话存储的持久化、人工审批工作流，以及带路由助手的 HTTP 服务。remoteAgent() 客户端为本地和远程智能体提供相同的 chat() 接口，消除了设计单独请求/响应协议的需要。
沙箱中心：Vercel Eve
Vercel 的 Eve 于 6 月 17 日在 Ship 大会上发布，7 月 6 日在企业安全深度解读中详述，采取了又一种方法。Eve 是文件系统优先的：智能体是一个文件目录，工具是一个 TypeScript 文件，技能是一个 Markdown 文件。文件系统是创作界面，Vercel 的云服务驱动后端。
Eve 的架构解决数据隔离和审计合规失败模式。当智能体在生产中执行代码和访问数据时，未授权访问、数据泄露和合规违规的风险成为主要关注点。Eve 通过沙箱化代码执行解决这一问题——每个智能体在隔离环境中运行（本地使用 Docker，生产中使用 Vercel Sandbox），具有严格的数据访问策略和审计跟踪。
持久化执行模型是关键差异化：每个对话存储为持久化工作流，可以暂停、在故障或部署后存活，并从最后完成的步骤恢复。这使 Eve 特别适合可靠性至关重要的长时间运行自主任务。Apache 2.0 许可证使框架本身免费，而 Vercel 的编排、状态管理和沙箱功能每月 20 美元。
Vercel 的规模赋予 Eve 可信度：该平台每天处理超过 600 万次部署，每天通过其网关流动超过 1 万亿 AI token。其中一半部署现在由 AI 编码智能体驱动。
架构对比矩阵
| 维度 | Otari（网关） | Genkit Agents（框架） | Eve（沙箱） |
|---|---|---|---|
| 主要失败模式 | 成本治理、提供商可靠性 | 开发者体验、全栈集成 | 数据隔离、审计合规 |
| 控制机制 | 策略驱动路由、请求前预算 | 框架级抽象、会话管理 | 文件系统约定、沙箱隔离 |
| 栈中位置 | 应用与提供商之间 | 应用内部 | 智能体周围 |
| 智能体模型 | Agent Harnesses（工具+编排） | 应用原语（chat() 接口） | 文件系统目录（约定优于配置） |
| 开源 | 是（Python，v0.2.0） | 是（TypeScript/Go，Beta） | 是（Apache 2.0，付费附加） |
| 最适合 | 多提供商成本管理 | 对话式 AI 功能 | 长时间运行自主任务 |
| 弱点 | 无应用级原语 | 无跨应用策略层 | Vercel 生态依赖 |
代码图谱 MCP：上下文优化层
控制平面在路由和预算层管理 token 消耗的同时，一类新工具正从源头攻击问题：代码图谱 MCP 将代码库预索引为持久化知识图谱，允许智能体只查询所需内容而非读取整个文件。
这是对 W28 识别的运行时流量控制（CLRK/Restate）的互补方法。流量控制在执行层限制 token 消耗；代码图谱从源头减少需要消耗的 token。两者从两端解决 token 成本螺旋。
code-review-graph 通过 MCP 和 CLI 提供本地优先的代码智能，在不同提示类型中实现 8.2x 平均上下文缩减，节省 22-87%。它提供 30 个 MCP 工具，并添加了上下文节省估算（v2.3.4）和分词器交叉检查（v2.3.5）以验证节省测量。
Codebase-Memory（arXiv 2603.27277）使用 Tree-Sitter 将 66 种语言解析为持久化知识图谱。在 31 个真实代码库中评估，它实现 83% 的回答质量，而文件探索智能体为 92%——9 个百分点的质量权衡——但 token 减少 10 倍，工具调用减少 2.1 倍。多阶段管道包括并行工作池、调用图遍历、影响分析和社区发现。
Skeletree 采取不同的架构方法，利用 TypeScript 编译器的类型信息进行精确代码导航。通过使用编译器而非 Tree-Sitter，它获得对 TypeScript 代码库更深的语义理解，但牺牲了 Tree-Sitter 提供的多语言广度。
codebase-memory-mcp（DeusData）声称 99% token 缩减，毫秒级索引，支持 158 种语言，通过 14 个 MCP 工具暴露。该声明较为激进，需要独立验证，但架构——静态二进制、高速索引、全面语言支持——解决了限制更学术方法采用的实践部署问题。
代码图谱 MCP 基准对比
| 工具 | 架构 | 语言 | Token 缩减 | 回答质量 | MCP 工具 |
|---|---|---|---|---|---|
| code-review-graph | 多语言图谱 | 257 | 8.2x 平均（22-87%） | 未报告 | 30 |
| Codebase-Memory | Tree-Sitter | 66 | 10x 更少 token | 83%（vs 92% 基线） | 14+ |
| Skeletree | TypeScript 编译器 | 仅 TypeScript | 显著（声称） | 未报告 | 未报告 |
| codebase-memory-mcp | 静态二进制 | 158 | 99%（声称） | 未报告 | 14 |
关键架构权衡是语言深度与广度：基于 TypeScript 编译器的工具（Skeletree）为一种语言获得更深的语义理解，而基于 Tree-Sitter 的工具（Codebase-Memory）以较浅的分析覆盖更多语言。多语言图谱方法（code-review-graph）优先考虑广度和工具数量而非单语言深度。
2x 吞吐量悖论：审查瓶颈作为结构性约束
arXiv 论文”AI 写得比人类审查得更快”（2607.01904）提供了迄今为止最严格的企业 AI 编码工具影响纵向证据。该研究在一家中型 B2B 软件公司跟踪了 802 名开发者和 196,212 个拉取请求，时间跨度从 2024 年 1 月到 2026 年 4 月，该公司于 2025 年 6 月公开承诺”2x 授权”。
核心发现——人均吞吐量在 2026 年 4 月达到授权前基线的 2.09x——是 AI 编码工具现场部署报告的最大增益之一。但结构性发现更重要：采用将代码审查围绕自动化进行了重组。人均审查者负载大约翻倍，自动化审查在数量上超过了人工审查，而合并和回退率保持稳定。
这意味着瓶颈已从代码生成转移到代码审查。AI 写代码的速度比人类审查的速度快，组织通过自动化审查来补偿——但自动化审查不是具有不同失败模式的人工审查的替代品。合并和回退率保持稳定表明自动化审查正在维持质量，但人均审查者负载翻倍表明人工审查者正在被挤压。
对基础设施的影响是直接的：
-
控制平面必须解决审查吞吐量，而不仅仅是生成吞吐量。 Otari 的预算强制、Genkit 的人工审批工作流和 Eve 的审计跟踪都涉及审查，但没有一个是为审查优化的。
-
代码图谱 MCP 可能加速审查和生成。 如果审查者可以查询持久化代码图谱而非读取整个文件，审查吞吐量可以与生成吞吐量成比例增加。
-
180% 代码产出 vs 30% 交付差距（Forbes，2026 年 6 月）是审查瓶颈问题，不是生成问题。 编写的代码多于可以审查和集成的代码，差距将扩大，直到基础设施专门解决审查。
研究还发现，增益”在资历间广泛共享，但集中在较新的代码中，且不可跨模型世代分离。“这表明吞吐量改进来自 AI 采用模式而非模型能力跳跃——这一发现对组织应如何投资 AI 工具有影响。
MCP 工具民主化：关闭服务器差距
MCP 协议已作为智能体-工具通信标准获得广泛采用，但协议采用与实际工具可用性之间存在持续差距。构建 MCP 服务器需要专业知识，大多数企业集成尚未暴露为 MCP 工具。
7 月 7 日发布的 SnapLogic MCP Builder GA 直接解决了这一差距。基于模板的功能自动将现有集成管道转换为智能体就绪的 MCP 工具，使 SnapLogic 的 1000+ 现有 Snap 连接器无需自定义 MCP 服务器开发即可供 AI 智能体访问。这是一个重要的桥梁：企业不必构建新的 MCP 原生工具，而是可以将现有集成投资暴露给智能体。
这种模式超越了 SnapLogic。RainFocus 推出了带企业级 OAuth 安全的 MCP Profiles 用于事件数据，提供按事件范围、OAuth 安全认证和双向操作。Perforce Intelligence 添加了 MCP 无关的智能体网关。JetBrains AI for Teams 同时支持 MCP 和 Agent Client Protocol (ACP) 用于供应商无关的智能体编排。
共同线索：现有企业集成供应商正在将 MCP 作为输出格式添加，而非构建新的 MCP 原生工具。 这大幅扩展了智能体可用的工具面，而不需要企业重建其集成基础设施。
企业发布浪潮：三天五项发布意味着什么
7 月 7-9 日智能体基础设施发布的密度前所未有：
- SnapLogic MCP Builder GA（7 月 7 日）：自动将集成管道转换为 MCP 工具
- JetBrains AI for Teams（7 月 7 日）：带 MCP + ACP 的供应商无关智能体开发
- Harness Autonomous Worker Agents（7 月 7 日）：后代码 DevOps 自动化
- IBM Bob 多智能体 + Bobalytics（7 月 9 日）：带成本分析的多智能体协调
- Couchbase AI Data Plane（7 月 8 日）：智能体工作负载的统一数据基础设施
这种密度表明三件事：
-
市场已达到临界规模。 供应商现在发布是因为在智能体基础设施栈中确立地位的窗口正在关闭。MCP 协议提供了足够的标准化，供应商可以在共享基础上构建。
-
栈正在分层。 每个发布占据不同层：SnapLogic 在工具/集成层，JetBrains 在 IDE/开发层，Harness 在 DevOps/交付层，IBM 在编排/协调层，Couchbase 在数据/持久化层。智能体基础设施栈正变得像 Web 栈一样分层。
-
企业就绪是差异化因素。 每个发布都强调治理、安全、可观测性或成本管理——而非智能体能力。市场已从”智能体能做事吗？“转向”智能体能安全且大规模地做事吗？“
数据点
| 指标 | 数值 | 来源 | 日期 |
|---|---|---|---|
| Otari 版本 | v0.2.0 | GitHub (mozilla-ai/otari) | 2026-07-03 |
| Vercel 日部署量 | 600 万+ | Vercel/TechCrunch | 2026-07-06 |
| Vercel 日 AI token 量 | 1 万亿+ | Vercel/SaaS Rise | 2026-07-06 |
| code-review-graph 上下文缩减 | 8.2x 平均 | code-review-graph.com | 2026-07 |
| Codebase-Memory token 缩减 | 10x 更少 token | arXiv 2603.27277 | 2026-03 |
| Codebase-Memory 回答质量 | 83%（vs 92% 基线） | arXiv 2603.27277 | 2026-03 |
| 企业 2x 吞吐量 | 2.09x | arXiv 2607.01904 | 2026-07 |
| 人均审查者负载变化 | ~2x | arXiv 2607.01904 | 2026-07 |
| AI 代码产出 vs 交付差距 | 180% vs 30% | Forbes | 2026-06 |
| SnapLogic 连接器 | 1000+ | SnapLogic | 2026-07-07 |
| Genkit Agents API 状态 | Beta（TypeScript + Go） | Google Developers Blog | 2026-07-01 |
| Eve 许可证 | Apache 2.0（$20/月附加） | Vercel | 2026-06-17 |
🔺 Scout Intel: What Others Missed
Confidence: high | Novelty Score: 82/100
控制平面分化不是碎片化——而是专业化。每种架构解决不同的生产失败模式，企业采用者可能需要多层而非选择其一。真正的洞察：代码图谱 MCP 代表新的”上下文优化”层，通过从源头减少 token 消耗来降低所有三种控制平面架构的负载。2x 吞吐量研究的审查瓶颈发现连接了所有三条线索——控制平面必须解决审查吞吐量，代码图谱可以加速审查，180%-vs-30% 产出-交付差距是审查问题而非生成问题。下一个基础设施创新将是审查专用的：使 AI 生成代码的人工审查与 AI 生成本身一样快的工具。
对工程领导者的关键启示： 根据你的主导失败模式评估控制平面架构（成本治理 → Otari，开发者体验 → Genkit，数据隔离 → Eve），并投资代码图谱 MCP 作为互补层，减少你选择的任何控制平面的负载。审查瓶颈是你的下一个扩展约束。
展望
短期（3-6 个月）
控制平面分化将在任何收敛信号出现之前加剧。预计至少还有两个网关中心进入者（可能来自云提供商）和一个沙箱中心框架。代码图谱 MCP 工具将随着基准测试成熟而围绕两三个主导实现整合。MCP 工具民主化模式（现有集成添加 MCP 作为输出格式）将随着 SnapLogic 方法证明可行而加速。
中期（6-18 个月）
“审查基础设施”类别将出现，结合控制平面元素（审批工作流、审计跟踪）与代码图谱上下文优化（通过预索引代码库加速审查）。2x 吞吐量研究将在更大规模上复制，审查瓶颈将成为 AI 编码生产力的主导叙事。预计至少一家主要云提供商推出审查专用智能体基础设施产品。
长期（18+ 个月）
智能体基础设施栈将稳定为不同层：上下文优化（代码图谱）、控制平面（网关/框架/沙箱）、编排（多智能体协调）和数据（持久化/记忆）。当前分化是市场探索解空间；收敛将通过协议层（MCP、A2A）的标准化而非架构层的标准化实现。投资于协议兼容工具而非架构特定平台的企业采用者将在栈成熟时拥有最大灵活性。
来源
- Mozilla.ai: Introducing Otari, the Open-Source LLM Control Plane
- Mozilla.ai: What is an LLM Control Plane?
- Mozilla.ai Otari 产品页
- Google Developers Blog: Build Agentic Full-Stack Apps with Genkit
- Genkit 文档: Full-Stack Agents
- InfoQ: Google Introduces Middleware Architecture for Genkit Applications
- InfoQ: Vercel Introduces Eve, an Open-Source Framework for Building AI Agents
- Techstrong.ai: Vercel Eve, a Filesystem-First Framework for Building Agents
- Vercel Eve 文档
- SaaS Rise: Vercel CEO Charts Path to Split AI Models from Deployment Agents
- code-review-graph: Local Code Intelligence for MCP
- arXiv: Codebase-Memory (2603.27277)
- arXiv: AI Writes Faster Than Humans Can Review (2607.01904)
- Forbes: AI Coding Agents Write 180% More Code But Ship Only 30% More Software
- DEVOPSdigest: IBM Bob Updated with Multi-Agent Capabilities
- InfoWorld: JetBrains to Roll Out AI Capabilities for Software Development Teams
- Deepsense.ai: The 5 Control Planes of Agentic AI Infrastructure
- Google AX: Distributed Agent Runtime
- AlphaSignal: Google’s Genkit Ships Agents API
AI 智能体生态 W29：控制平面分化与代码图谱 Token 缩减
2026 年 7 月，三种智能体控制平面架构同时分化：Mozilla Otari（网关中心）、Google Genkit Agents（框架中心）、Vercel Eve（沙箱中心）。代码图谱 MCP 工具实现 8-120x token 缩减。802 名开发者的纵向研究揭示审查瓶颈成为新结构性约束。
AI 智能体生态 W29：控制平面分化——Mozilla Otari、Google Genkit Agents 与 Vercel Eve 重塑基础设施层，代码图谱 MCP 攻击 Token 成本螺旋
TL;DR: 2026 年 7 月，三种截然不同的 AI 智能体基础设施控制平面架构同时出现——网关中心（Mozilla Otari）、框架中心（Google Genkit Agents）和沙箱中心（Vercel Eve）——各自解决不同的生产失败模式。与此同时，代码图谱 MCP 工具通过将代码库预索引为持久化知识图谱实现 8-120x token 缩减，一项 802 名开发者的纵向研究揭示 AI 编码吞吐量已达 2.09x，但审查瓶颈已成为新的结构性约束。
摘要
2026 年 7 月 7-13 日这一周，智能体基础设施发布密度前所未有：三天内五项以上重大公告，表明市场已达到临界规模——供应商必须尽快发布，否则将被锁定在新兴标准之外。但最重要的结构性变化不是发布数量——而是控制平面层本身的架构分化。
Mozilla 的 Otari、Google 的 Genkit Agents 和 Vercel 的 Eve 代表了管理智能体基础设施的三种根本不同的哲学。Otari 将自己定位为网关中心控制平面，位于应用程序和 LLM 提供商之间，管理路由、预算和治理。Genkit Agents 采用框架中心方法，将整个智能体生命周期——会话、流式传输、持久化、人工审批——打包为单一应用原语。Eve 采用沙箱中心模型，使用文件系统约定和隔离执行环境来强制数据控制和审计合规。
这种分化与 W28 识别的智能体框架整合模式截然相反。控制平面层不是收敛于主导架构，而是分裂为专业化阵营，每个阵营针对生产可靠性问题的不同切片进行优化。企业采用者面临一个新决策：哪种失败模式最重要，哪种架构能解决它？
同时，一类新的代码图谱 MCP 工具——Skeletree、code-review-graph 和 Codebase-Memory——正从不同角度攻击 token 成本螺旋。这些工具不是在运行时层限制 token 消耗（如 CLRK/Restate 流量控制），而是通过将代码库预索引为持久化知识图谱来从源头减少上下文，智能体查询图谱而非读取整个文件。声称的缩减范围从 8x 到 120x，早期基准测试表明节省是真实的，但取决于架构。
arXiv 的 2x 吞吐量纵向研究（802 名开发者，196,212 个 PR，28 个月）验证了控制平面和代码图谱都在响应的生产转变。人均吞吐量达到 2.09x——但人均审查者负载也大约翻倍，自动化审查在数量上超过了人工审查。瓶颈已从生成转移到审查，基础设施现在必须解决审查吞吐量，而不仅仅是生成速度。
背景
上周的 W28 分析识别了三个结构性转变：框架整合、协议收敛和网关控制平面作为独立基础设施层的出现。网关控制平面——以 CLRK/Restate 的智能体运行时管理流量控制为代表——被定位为框架和协议之后下一个成熟的层。
W29 揭示控制平面层正在成熟，但不是通过收敛。相反，它正在分化为三个架构阵营，每个阵营对”控制”在智能体基础设施语境中的含义有不同的心智模型。这种分化是健康的——意味着市场正在探索解空间，而不是锁定在过早的标准上——但它为企业采用者创造了新挑战，他们现在必须评估的不仅是使用哪个产品，还有哪种架构哲学与他们的生产失败模式一致。
时机很重要。7 月 7-9 日三天内五项重大智能体基础设施发布：SnapLogic MCP Builder GA、JetBrains AI for Teams、Harness Autonomous Worker Agents、IBM Bob 多智能体 + Bobalytics 和 Couchbase AI Data Plane。这种密度表明市场已达到拐点——问题不再是”我们应该构建智能体基础设施吗？“而是”我们应该采用哪种架构？“
分析
控制平面分化：三种阵营，三种失败模式
本周出现的三种控制平面架构不是同一设计的竞争实现——它们是解决同一问题的根本不同方法，各自针对不同的生产失败模式进行优化。
网关中心：Mozilla Otari
Mozilla.ai 于 7 月 6 日推出 Otari，作为开源 LLM 控制平面。Otari 位于应用程序和 LLM 提供商之间，提供路由、预算、治理、部署和可靠性的单一层。其关键差异化是明确区分”网关”和”控制平面”：网关处理执行和连接，使用静态路由和调用后 token 统计；控制平面处理策略和决策，使用动态路由、请求前预算强制和跨所有应用的全局策略。
Otari 的架构解决成本治理和提供商可靠性失败模式。当一个组织跨多个应用运行多个 LLM 提供商时，独立管理每个应用的路由逻辑、API 密钥、使用跟踪、预算强制和故障转移的操作复杂性变得不可持续。Otari 将这些关注点集中到位于应用和提供商之间的专用控制平面。
Agent Harnesses 功能特别值得注意——它为构建智能体就绪应用提供内置工具和编排，将 Otari 定位为不仅是被动网关，而是主动智能体基础设施层。开源策略（Python 98.4%，v0.2.0，GitHub 上 333 次提交）以社区驱动的替代方案挑战 Portkey 和 Helicone 等专有网关。
框架中心：Google Genkit Agents
Google 于 7 月 1 日发布 Genkit Agents API 预览版，采取了根本不同的方法。Genkit Agents 不是位于应用和提供商之间，而是将整个智能体生命周期打包为单一应用原语。chat() 接口抽象了消息历史、工具循环、流式传输、会话持久化和 HTTP 服务——对话式 AI 功能所需的一切，都在一个 API 之后。
Genkit 的架构解决开发者体验和全栈集成失败模式。当团队需要构建对话式 AI 功能——支持助手、审批工作流、任务副驾驶——消息历史、工具执行循环、流式更新、会话持久化和前端线协议的管道在每个项目上重复。Genkit 通过将其打包为框架级原语来消除这种重复。
Google 的定位很有启发性：Genkit 用于”向现有应用添加智能体功能”，而 Agent Development Kit (ADK) 用于”复杂独立多智能体系统”。这种区分映射到框架中心与平台中心的分界——Genkit 将智能体嵌入应用，而 ADK 用智能体构建应用。
Agents API 支持带自定义状态和产物的会话、文本和状态补丁及工具中断的流式传输、通过会话存储的持久化、人工审批工作流，以及带路由助手的 HTTP 服务。remoteAgent() 客户端为本地和远程智能体提供相同的 chat() 接口，消除了设计单独请求/响应协议的需要。
沙箱中心：Vercel Eve
Vercel 的 Eve 于 6 月 17 日在 Ship 大会上发布，7 月 6 日在企业安全深度解读中详述，采取了又一种方法。Eve 是文件系统优先的：智能体是一个文件目录，工具是一个 TypeScript 文件，技能是一个 Markdown 文件。文件系统是创作界面，Vercel 的云服务驱动后端。
Eve 的架构解决数据隔离和审计合规失败模式。当智能体在生产中执行代码和访问数据时，未授权访问、数据泄露和合规违规的风险成为主要关注点。Eve 通过沙箱化代码执行解决这一问题——每个智能体在隔离环境中运行（本地使用 Docker，生产中使用 Vercel Sandbox），具有严格的数据访问策略和审计跟踪。
持久化执行模型是关键差异化：每个对话存储为持久化工作流，可以暂停、在故障或部署后存活，并从最后完成的步骤恢复。这使 Eve 特别适合可靠性至关重要的长时间运行自主任务。Apache 2.0 许可证使框架本身免费，而 Vercel 的编排、状态管理和沙箱功能每月 20 美元。
Vercel 的规模赋予 Eve 可信度：该平台每天处理超过 600 万次部署，每天通过其网关流动超过 1 万亿 AI token。其中一半部署现在由 AI 编码智能体驱动。
架构对比矩阵
| 维度 | Otari（网关） | Genkit Agents（框架） | Eve（沙箱） |
|---|---|---|---|
| 主要失败模式 | 成本治理、提供商可靠性 | 开发者体验、全栈集成 | 数据隔离、审计合规 |
| 控制机制 | 策略驱动路由、请求前预算 | 框架级抽象、会话管理 | 文件系统约定、沙箱隔离 |
| 栈中位置 | 应用与提供商之间 | 应用内部 | 智能体周围 |
| 智能体模型 | Agent Harnesses（工具+编排） | 应用原语（chat() 接口） | 文件系统目录（约定优于配置） |
| 开源 | 是（Python，v0.2.0） | 是（TypeScript/Go，Beta） | 是（Apache 2.0，付费附加） |
| 最适合 | 多提供商成本管理 | 对话式 AI 功能 | 长时间运行自主任务 |
| 弱点 | 无应用级原语 | 无跨应用策略层 | Vercel 生态依赖 |
代码图谱 MCP：上下文优化层
控制平面在路由和预算层管理 token 消耗的同时，一类新工具正从源头攻击问题：代码图谱 MCP 将代码库预索引为持久化知识图谱，允许智能体只查询所需内容而非读取整个文件。
这是对 W28 识别的运行时流量控制（CLRK/Restate）的互补方法。流量控制在执行层限制 token 消耗；代码图谱从源头减少需要消耗的 token。两者从两端解决 token 成本螺旋。
code-review-graph 通过 MCP 和 CLI 提供本地优先的代码智能，在不同提示类型中实现 8.2x 平均上下文缩减，节省 22-87%。它提供 30 个 MCP 工具，并添加了上下文节省估算（v2.3.4）和分词器交叉检查（v2.3.5）以验证节省测量。
Codebase-Memory（arXiv 2603.27277）使用 Tree-Sitter 将 66 种语言解析为持久化知识图谱。在 31 个真实代码库中评估，它实现 83% 的回答质量，而文件探索智能体为 92%——9 个百分点的质量权衡——但 token 减少 10 倍，工具调用减少 2.1 倍。多阶段管道包括并行工作池、调用图遍历、影响分析和社区发现。
Skeletree 采取不同的架构方法，利用 TypeScript 编译器的类型信息进行精确代码导航。通过使用编译器而非 Tree-Sitter，它获得对 TypeScript 代码库更深的语义理解，但牺牲了 Tree-Sitter 提供的多语言广度。
codebase-memory-mcp（DeusData）声称 99% token 缩减，毫秒级索引，支持 158 种语言，通过 14 个 MCP 工具暴露。该声明较为激进，需要独立验证，但架构——静态二进制、高速索引、全面语言支持——解决了限制更学术方法采用的实践部署问题。
代码图谱 MCP 基准对比
| 工具 | 架构 | 语言 | Token 缩减 | 回答质量 | MCP 工具 |
|---|---|---|---|---|---|
| code-review-graph | 多语言图谱 | 257 | 8.2x 平均（22-87%） | 未报告 | 30 |
| Codebase-Memory | Tree-Sitter | 66 | 10x 更少 token | 83%（vs 92% 基线） | 14+ |
| Skeletree | TypeScript 编译器 | 仅 TypeScript | 显著（声称） | 未报告 | 未报告 |
| codebase-memory-mcp | 静态二进制 | 158 | 99%（声称） | 未报告 | 14 |
关键架构权衡是语言深度与广度：基于 TypeScript 编译器的工具（Skeletree）为一种语言获得更深的语义理解，而基于 Tree-Sitter 的工具（Codebase-Memory）以较浅的分析覆盖更多语言。多语言图谱方法（code-review-graph）优先考虑广度和工具数量而非单语言深度。
2x 吞吐量悖论：审查瓶颈作为结构性约束
arXiv 论文”AI 写得比人类审查得更快”（2607.01904）提供了迄今为止最严格的企业 AI 编码工具影响纵向证据。该研究在一家中型 B2B 软件公司跟踪了 802 名开发者和 196,212 个拉取请求，时间跨度从 2024 年 1 月到 2026 年 4 月，该公司于 2025 年 6 月公开承诺”2x 授权”。
核心发现——人均吞吐量在 2026 年 4 月达到授权前基线的 2.09x——是 AI 编码工具现场部署报告的最大增益之一。但结构性发现更重要：采用将代码审查围绕自动化进行了重组。人均审查者负载大约翻倍，自动化审查在数量上超过了人工审查，而合并和回退率保持稳定。
这意味着瓶颈已从代码生成转移到代码审查。AI 写代码的速度比人类审查的速度快，组织通过自动化审查来补偿——但自动化审查不是具有不同失败模式的人工审查的替代品。合并和回退率保持稳定表明自动化审查正在维持质量，但人均审查者负载翻倍表明人工审查者正在被挤压。
对基础设施的影响是直接的：
-
控制平面必须解决审查吞吐量，而不仅仅是生成吞吐量。 Otari 的预算强制、Genkit 的人工审批工作流和 Eve 的审计跟踪都涉及审查，但没有一个是为审查优化的。
-
代码图谱 MCP 可能加速审查和生成。 如果审查者可以查询持久化代码图谱而非读取整个文件，审查吞吐量可以与生成吞吐量成比例增加。
-
180% 代码产出 vs 30% 交付差距（Forbes，2026 年 6 月）是审查瓶颈问题，不是生成问题。 编写的代码多于可以审查和集成的代码，差距将扩大，直到基础设施专门解决审查。
研究还发现，增益”在资历间广泛共享，但集中在较新的代码中，且不可跨模型世代分离。“这表明吞吐量改进来自 AI 采用模式而非模型能力跳跃——这一发现对组织应如何投资 AI 工具有影响。
MCP 工具民主化：关闭服务器差距
MCP 协议已作为智能体-工具通信标准获得广泛采用，但协议采用与实际工具可用性之间存在持续差距。构建 MCP 服务器需要专业知识，大多数企业集成尚未暴露为 MCP 工具。
7 月 7 日发布的 SnapLogic MCP Builder GA 直接解决了这一差距。基于模板的功能自动将现有集成管道转换为智能体就绪的 MCP 工具，使 SnapLogic 的 1000+ 现有 Snap 连接器无需自定义 MCP 服务器开发即可供 AI 智能体访问。这是一个重要的桥梁：企业不必构建新的 MCP 原生工具，而是可以将现有集成投资暴露给智能体。
这种模式超越了 SnapLogic。RainFocus 推出了带企业级 OAuth 安全的 MCP Profiles 用于事件数据，提供按事件范围、OAuth 安全认证和双向操作。Perforce Intelligence 添加了 MCP 无关的智能体网关。JetBrains AI for Teams 同时支持 MCP 和 Agent Client Protocol (ACP) 用于供应商无关的智能体编排。
共同线索：现有企业集成供应商正在将 MCP 作为输出格式添加，而非构建新的 MCP 原生工具。 这大幅扩展了智能体可用的工具面，而不需要企业重建其集成基础设施。
企业发布浪潮：三天五项发布意味着什么
7 月 7-9 日智能体基础设施发布的密度前所未有：
- SnapLogic MCP Builder GA（7 月 7 日）：自动将集成管道转换为 MCP 工具
- JetBrains AI for Teams（7 月 7 日）：带 MCP + ACP 的供应商无关智能体开发
- Harness Autonomous Worker Agents（7 月 7 日）：后代码 DevOps 自动化
- IBM Bob 多智能体 + Bobalytics（7 月 9 日）：带成本分析的多智能体协调
- Couchbase AI Data Plane（7 月 8 日）：智能体工作负载的统一数据基础设施
这种密度表明三件事：
-
市场已达到临界规模。 供应商现在发布是因为在智能体基础设施栈中确立地位的窗口正在关闭。MCP 协议提供了足够的标准化，供应商可以在共享基础上构建。
-
栈正在分层。 每个发布占据不同层：SnapLogic 在工具/集成层，JetBrains 在 IDE/开发层，Harness 在 DevOps/交付层，IBM 在编排/协调层，Couchbase 在数据/持久化层。智能体基础设施栈正变得像 Web 栈一样分层。
-
企业就绪是差异化因素。 每个发布都强调治理、安全、可观测性或成本管理——而非智能体能力。市场已从”智能体能做事吗？“转向”智能体能安全且大规模地做事吗？“
数据点
| 指标 | 数值 | 来源 | 日期 |
|---|---|---|---|
| Otari 版本 | v0.2.0 | GitHub (mozilla-ai/otari) | 2026-07-03 |
| Vercel 日部署量 | 600 万+ | Vercel/TechCrunch | 2026-07-06 |
| Vercel 日 AI token 量 | 1 万亿+ | Vercel/SaaS Rise | 2026-07-06 |
| code-review-graph 上下文缩减 | 8.2x 平均 | code-review-graph.com | 2026-07 |
| Codebase-Memory token 缩减 | 10x 更少 token | arXiv 2603.27277 | 2026-03 |
| Codebase-Memory 回答质量 | 83%（vs 92% 基线） | arXiv 2603.27277 | 2026-03 |
| 企业 2x 吞吐量 | 2.09x | arXiv 2607.01904 | 2026-07 |
| 人均审查者负载变化 | ~2x | arXiv 2607.01904 | 2026-07 |
| AI 代码产出 vs 交付差距 | 180% vs 30% | Forbes | 2026-06 |
| SnapLogic 连接器 | 1000+ | SnapLogic | 2026-07-07 |
| Genkit Agents API 状态 | Beta（TypeScript + Go） | Google Developers Blog | 2026-07-01 |
| Eve 许可证 | Apache 2.0（$20/月附加） | Vercel | 2026-06-17 |
🔺 Scout Intel: What Others Missed
Confidence: high | Novelty Score: 82/100
控制平面分化不是碎片化——而是专业化。每种架构解决不同的生产失败模式，企业采用者可能需要多层而非选择其一。真正的洞察：代码图谱 MCP 代表新的”上下文优化”层，通过从源头减少 token 消耗来降低所有三种控制平面架构的负载。2x 吞吐量研究的审查瓶颈发现连接了所有三条线索——控制平面必须解决审查吞吐量，代码图谱可以加速审查，180%-vs-30% 产出-交付差距是审查问题而非生成问题。下一个基础设施创新将是审查专用的：使 AI 生成代码的人工审查与 AI 生成本身一样快的工具。
对工程领导者的关键启示： 根据你的主导失败模式评估控制平面架构（成本治理 → Otari，开发者体验 → Genkit，数据隔离 → Eve），并投资代码图谱 MCP 作为互补层，减少你选择的任何控制平面的负载。审查瓶颈是你的下一个扩展约束。
展望
短期（3-6 个月）
控制平面分化将在任何收敛信号出现之前加剧。预计至少还有两个网关中心进入者（可能来自云提供商）和一个沙箱中心框架。代码图谱 MCP 工具将随着基准测试成熟而围绕两三个主导实现整合。MCP 工具民主化模式（现有集成添加 MCP 作为输出格式）将随着 SnapLogic 方法证明可行而加速。
中期（6-18 个月）
“审查基础设施”类别将出现，结合控制平面元素（审批工作流、审计跟踪）与代码图谱上下文优化（通过预索引代码库加速审查）。2x 吞吐量研究将在更大规模上复制，审查瓶颈将成为 AI 编码生产力的主导叙事。预计至少一家主要云提供商推出审查专用智能体基础设施产品。
长期（18+ 个月）
智能体基础设施栈将稳定为不同层：上下文优化（代码图谱）、控制平面（网关/框架/沙箱）、编排（多智能体协调）和数据（持久化/记忆）。当前分化是市场探索解空间；收敛将通过协议层（MCP、A2A）的标准化而非架构层的标准化实现。投资于协议兼容工具而非架构特定平台的企业采用者将在栈成熟时拥有最大灵活性。
来源
- Mozilla.ai: Introducing Otari, the Open-Source LLM Control Plane
- Mozilla.ai: What is an LLM Control Plane?
- Mozilla.ai Otari 产品页
- Google Developers Blog: Build Agentic Full-Stack Apps with Genkit
- Genkit 文档: Full-Stack Agents
- InfoQ: Google Introduces Middleware Architecture for Genkit Applications
- InfoQ: Vercel Introduces Eve, an Open-Source Framework for Building AI Agents
- Techstrong.ai: Vercel Eve, a Filesystem-First Framework for Building Agents
- Vercel Eve 文档
- SaaS Rise: Vercel CEO Charts Path to Split AI Models from Deployment Agents
- code-review-graph: Local Code Intelligence for MCP
- arXiv: Codebase-Memory (2603.27277)
- arXiv: AI Writes Faster Than Humans Can Review (2607.01904)
- Forbes: AI Coding Agents Write 180% More Code But Ship Only 30% More Software
- DEVOPSdigest: IBM Bob Updated with Multi-Agent Capabilities
- InfoWorld: JetBrains to Roll Out AI Capabilities for Software Development Teams
- Deepsense.ai: The 5 Control Planes of Agentic AI Infrastructure
- Google AX: Distributed Agent Runtime
- AlphaSignal: Google’s Genkit Ships Agents API
相关情报
AI 智能体生态 W28：框架整合、协议收敛与网关控制平面
Microsoft Agent Framework 吸收 AutoGen（合并 75K+ GitHub Stars），A2A 协议覆盖 150+ 生产组织，智能体网关成为企业控制平面——三层结构首次同步收敛。框架选择对基准测试性能的影响高达 30 个百分点。
ArXiv cs.AI 周度论文追踪 — 2026年7月9日周
本周 ArXiv cs.AI 与 cs.CL 投稿揭示 241 篇论文中有 100 篇智能体相关论文，首次出现 MCP 安全漏洞披露，5 个新编排框架，12 个新基准测试。智能体密度达 41.5%。
大语言模型产品发布周报：Sonnet 5 登场，Fable 5 回归，推理速度竞赛白热化
2026年7月1-7日 — Anthropic 以5项发布主导本周，包括每百万 Token $2/$10 的 Sonnet 5 和 Fable 5 全球恢复；OpenAI 借 Cerebras 冲刺 750 tok/s；Mistral 在 AI Now 峰会推出 Vibe 智能体和物理 AI。