内部测试指标

经内部压力测试验证，新架构能够在保持极低读取延迟的同时，支撑单个代码仓库容纳 5000 个智能体（Agent）并发协作，并承受每秒高达 7200 次的代码推送（push）。

目前 Rubicon 已开启小范围定向内测（limited private preview），并计划于 2027 年初逐步扩大开放范围。

为什么要重构 Git

GitHub 观察到，随着越来越多研发工作交由全天候、高并发运行的 AI 智能体处理，传统以仓库为中心的存储与协调机制正面临新的吞吐与延迟压力。

如今 GitHub 上最繁忙的代码仓库，单秒写入峰值最多不过数十次，且往往呈短暂脉冲式突发。然而，智能体驱动的持续高吞吐正将这种瞬时突发演变为常态。有数据显示，某个典型仓库在 3 月至 5 月期间的日请求量激增约 4 倍；此后访问量始终保持陡峭的指数级上升。

每一次推送还会级联触发更多读取：持续集成流水线启动、部署系统拉取最新提交、其他协同智能体同步获取代码作为上下文。这种读取扇出效应，随着写入频率攀升被显著放大。

架构如何解耦

Rubicon 的核心思路是”减少协调、解耦存储与计算”。Git 对象具有不可变、按内容命名的特性，因此多个写入者可以几乎同时保存对象而无需互相等待；真正需要有序确认的，主要是分支、标签等引用（reference）的更新，而引用更新的数据量小得多。

新架构主要由几部分构成：Spokes 入口层负责路由、负载均衡与租户隔离；一组可动态增减的虚拟副本（virtual replica）处理读取与写入，其本地磁盘仅是随时可重建的缓存；Git 对象与 pack 文件存放于 Azure Blob Storage；引用及 pack 清单则位于独立的复制日志服务 Ref-CAS（Reference Compare-and-Swap，引用比较并交换）中，用于多副本间按顺序确认引用变化；后台压缩与垃圾回收节点直接针对持久化存储执行，不再与读取请求争用资源。

GitHub 表示，其已将 99.99999% 的代码仓库副本迁移至 Azure，并以 Azure Blob Storage 支撑虚拟副本。由于智能体通常各自推送到独立分支，多数更新不会争用同一引用，可并行复制；只有当两个推送同时修改同一引用时，才会由其中一个成功追加到日志。

意义与展望

Rubicon 首先服务于智能体驱动的开发范式，但影响不限于 AI 编程工具。若大量智能体能在同一仓库并行工作，团队可将任务拆成更多独立分支，由智能体分别执行编码、测试、修复与审查，再由开发者或自动化流程完成合并。这将推动代码托管平台从”保存开发者提交”转向”协调大规模并发软件生产”。

需要明确的是，5000 个智能体与每秒 7200 次推送均为内部测试数据，不等同于所有用户当前可获得的服务等级或商业化容量承诺。Rubicon 更像是面向下一代开发模式的基础设施预告：GitHub 正在提前重建底层存储，让单一代码仓库未来能够容纳远超传统人类协作规模的并发智能体工作流。

从”用量指标”到”业务成果”

亚马逊副总裁兼杰出工程师特克·特科维茨（Terk Terkowitz）在备忘录中指出，相比云计算等以往的技术变革，AI 对软件开发的影响来得更快、也更深刻。但衡量工程师表现的关键，仍在于他们为客户和业务带来了什么成果，而非使用 AI 的频率或数量。他提醒：”我们都必须适应变化，花时间学习，否则就有可能被甩在后面。”

亚马逊将这一阶段称为”文艺复兴开发者时代”，认为人类判断力与机器智能相结合，可以更快、更高效地开发新产品与服务。

此前，亚马逊曾统计员工使用 AI 的次数、消耗的词元数量及编写的代码行数，还根据部分数据制作排行榜，对不同团队进行比较。但备忘录警告，拿这些数据衡量工作表现，与要求员工尽可能提高数据，是两回事。过度追求指标可能适得其反——例如为增加词元消耗量而滥用 AI，却没有写出更好的软件，也没有改善客户体验。

“刷量”的教训

据《商业内幕》报道，今年早些时候，亚马逊开始追踪工程师对内部 AI 工具的使用情况，部分团队推出了以词元消耗量为依据的排行榜。此举引发部分员工不满。据报道，亚马逊曾在今年 5 月关闭一个内部排行榜，原因是发现员工为了提升排名而大量消耗词元——这种现象被外界称为”tokenmaxxing”（刷词元）。

新版准则是亚马逊迄今最明确的一次公开承认，表明公司意识到了这种风险。亚马逊认为，详细规定工程师该如何使用 AI，很快就可能因技术进步而过时，因此重点放在客户和业务能够获得的长期成果上。

不唯指标，也不放弃 AI

亚马逊并未因此降低对 AI 应用的重视。公司强调，AI 应当成为”软件工程实践的核心”，并要求工程师在日常工作中使用这项技术；备忘录还要求管理人员亲自在实际项目中使用 AI 工具，了解其能解决什么、在哪些方面仍有不足，并向团队解释判断依据。

AWS 副总裁马克·布鲁克（Marc Brooker）向 CNBC 提出用”功能流速”（feature velocity）来衡量成效——即团队交付并真正上线到用户手中的功能与变更数量。亚马逊还建议管理者重点观察两端团队：排名后 10% 的团队，要了解他们为何没能高效利用 AI；排名前 10% 的团队，则要确认大量使用 AI 是否真的加快了交付。

对于暂时无法从现有 AI 工具中受益的岗位，员工可以记录原因、与同事和管理者交流，共同寻找办法。备忘录写道：”能够说明 AI 为什么暂时帮不上忙的工程师，恰恰展现了我们希望看到的判断力。”在 AI 全面渗透软件行业的当下，亚马逊给出的答案很明确：用 AI，但不要为了用而用。

这句话出自 MIT Technology Review 旗下 Business Lab 播客 2026年9月1日的一期节目，由该刊 Insights 部门特约编辑 Megan Tatum 主持，另一位嘉宾是 Infosys 高级副总裁、负责澳大利亚、新西兰及东南亚地区金融保险、医疗与公共部门业务的 Sanjeev Tripathi。两人讨论的核心，是一次把 AI 真正用在遗留系统改造上的项目。

逼上门的技术债

Bupa 在亚太地区服务约700万客户，旗下的 My Bupa 移动应用建立在微软的 Xamarin 跨平台框架之上。而微软对 Xamarin 的支持已于2024年终止。

对一款承担投保查询、理赔办理等关键流程的应用来说，框架停止维护带来的不只是技术风险，还有实实在在的体验损耗。Sherazi 的表述很具体：「一次登录失败不是技术事件，而是一个想查看自己保障范围却没能查到的人。」

这也是她拒绝把延长支持当作解决方案的原因：「延长支持买到的是时间，不是未来。」最终的决定是重写——迁移到原生的 Swift 与 Kotlin。

AI 究竟做了什么

Tripathi 的判断是：「AI 的出现正在从根本上改变现代化改造的经济账。」在这个项目里，AI 的作用集中在三个环节，而且都不是替代人，而是压缩人力最不划算的那部分投入。

第一是代码理解与逆向工程。Infosys 团队用 AI 辅助的方式，从存量 Xamarin 代码中提取业务流程、规则与逻辑，直接生成可用于原生开发的用户故事和验收标准。以往这一步高度依赖业务分析师逐行读代码、访谈业务方。

第二是文档化。AI 驱动的发现与文档生成，节省了约400小时的人工业务分析工作量，并把接近1500个回归测试场景映射到了原生开发的需求集上。这一步的隐性价值在于知识转移：原本散落在少数老员工头脑里的系统知识，被沉淀成团队共享的资产。

第三是测试。团队用 AI 做缺陷分类与预测性缺陷分析，跑了近1400个案例，把测试资源集中投向高风险路径；同时用 AI 驱动的无障碍测试做大规模系统化验证。结果是上线时零安全类与高危级别缺陷。

综合起来，AI 辅助让交付周期相比没有 AI 的时代缩短了约60%。内部最初的估算是18个月，实际交付用了7个月。

数字之外的变化

新版应用上线后的指标变化相当直接：应用评分从3.7升到4.7；用户感知到的崩溃率在安卓端下降近24个百分点，iOS 端下降8个百分点；安卓端每次访问的登录成功率回升至77%，接近翻倍；代码库体积减少30%，应用占用空间减少18%。

功能层面实现了100%的双平台同步发版，不再出现一端有、另一端等的情况。活跃客户中约90%已迁移到新版本，独立下载量接近180万次。此外，账单处理速度提升了4倍，代码提交到测试人员手中的时间压缩到约1小时；整体功能交付速度大约快了4倍。

Sherazi 认为，真正的变化发生在决策的问法上：「过去是，我们的平台能不能支持这件事？现在是，这件事对客户来说是不是正确的。」而对最终用户，她的期待反而克制：「他们会注意到的是，当他们需要我们的时候——往往是在一个焦虑的时刻——它就是能用。」

两条不该被忽略的边界

这次对话中最值得企业技术决策者留意的，是两位嘉宾对 AI 边界的一致态度。

Tripathi 明确划线：「AI 不能替代良好的工程实践，它让组织能够更快地执行这些实践。良好架构、扎实工程与清晰业务目标的重要性会继续存在。」在他的展望中，现代化平台会成为更智能的 AI 驱动生态的底座，「AI 不只是附加功能，而是从设计到运营都内建其中」，客户体验将变得更个性化、更具预测性。

Sherazi 补充的则是组织层面的心得，尤其是改造过程中充满不确定性的阶段：「领导层在那些时刻的工作，是吸收模糊性而不是传导焦虑，因为如果人们觉得可以安心地尽早报告坏消息，几乎没有什么问题是修不好的。」

她对整个项目的定义或许是最凝练的一句总结：「我们做现代化改造，是为了赢得做下一件事的资格，并且能以周为单位而不是以年为单位完成它。」

一次非官方的越级挑战

big-pickle 是 OpenCode Zen 平台上处于「隐形」（stealth）期的免费模型，其真实身份至今没有官方确认。从泄露的提供方报错与接口签名看，它背后很可能由 DeepSeek 的基础设施在支撑。一名开发者（GitHub 账号 PhillipChaffee）在 2026 年 8 月 11 日用它完整跑完了 Scale AI 的 SWE Atlas Codebase QnA 评测：全部 124 道任务解出 63 道，任务解决率达到 50.8%。

SWE Atlas 的 Codebase QnA 任务要求模型在读懂一整个大型代码库的基础上回答工程问题，比单纯写函数更接近真实研发场景。该评测严格遵循 Scale 公开的协议——使用官方开源框架 Harbor v0.18.0、与排行榜上非第一方模型一致的 mini-swe-agent 2.4.6 极简脚手架，并以 Scale 指定的 claude-opus-4-5 作为裁判模型。整轮消耗的 6.74 亿个输入 token、430 万个输出 token 全部免费。

横向对比：免费模型的越级表现

放在 SWE Atlas QnA 官方排行榜（2026 年 7 月 28 日更新）中，big-pickle 的成绩意味着：在相同的 Mini-SWE-Agent 脚手架类别里，它压过了榜单上所有条目，包括 GLM 5.2（48.12%）与 GPT-5.6-Sol（46.00%）。在整个榜单中，只有运行在原生 Claude Code 脚手架上的 Opus 5（63.17%）与 Opus 4.8（57.26%）略高。

分语言看，TypeScript 解决率 58.1%（18/31）、Python 55.2%（16/29）、Go 50.0%（19/38）、C 语言 38.5%（10/26）；分任务类型看，代码上手（Code Onboarding）60.7%、架构与系统设计 52.3%、根因分析 45.9%、安全类 45.5%。

结果可以独立核查

开发者在仓库中放出了逐任务的裁判日志、运行配置与复现脚本，任何人都能审计。需要说明的局限包括：每个任务只跑了一次（官方协议跑三次取均值，单次标准误约正负 4.5 个百分点）；沙箱资源被主动调低至 4 CPU / 8 GB（而非声明的 16/16），但 124 条轨迹的扫描显示零超时、零内存溢出，说明这只会压低而非抬高分数；模型身份未知，结果只是 2026 年 8 月 11 日当天该别名的快照。即便把两道未评分任务按「不通过」计，严格下界 49.2% 仍高于所有 Mini-SWE-Agent 榜单条目。

来源：GitHub（PhillipChaffee/big-pickle-swe-atlas）、Scale AI SWE Atlas

官方这次没有发布博客，只在 API 文档的模型与价格页面更新了参数，随后从官方群流出的一张评测对比表成了外界了解新版能力的主要依据。

规格：百万上下文，38.4 万输出

DeepSeek-V4-Pro-0813 支持 100 万 token 上下文长度，最大输出长度达到 38.4 万 token，同时提供思考模式与非思考模式，其中思考模式默认开启。对于需要一次性读入长代码仓库、处理大规模文档，或者连续执行大量步骤的智能体任务，这样的规格意味着单次调用能承载的内容量相当可观，多轮拆分与拼接的开销随之减少。

接口能力上，新版支持 JSON 结构化输出、工具调用与 Responses API，同时兼容 OpenAI 与 Anthropic 两套请求格式，对话前缀续写处于测试阶段，FIM 补全同样是测试功能且仅限非思考模式使用。换句话说，DeepSeek 在接口层已经基本对齐了当下主流的智能体开发工具链，切换成本被压到很低。

架构方面，V4 Pro 沿用此前公开的混合专家设计，总参数规模 1.6 万亿，每次推理激活约 490 亿参数。并发限制上，Pro 版为 500，轻量的 Flash 版为 2500，产品分层意图明确：高频轻量任务走 Flash，复杂长任务走 Pro。

跑分：智能体项目全面拉升，四项超过 Opus 4.8

官方评测表最直观的信号是与预览版的落差。在考察模型在真实终端环境中执行命令、解决系统问题的 Terminal Bench 2.1 上，正式版拿到 87.9 分，预览版为 72.1 分，三个月抬升 15.8 分。面向长周期真实软件工程任务的 DeepSWE 变化更剧烈，从预览版的 12.8 分跃升至 62.7 分，接近原来的五倍——预览版在这项测试上基本处于「做不完任务」的状态。

横向对比中，V4-Pro-0813 有四个项目超过 Anthropic 上一代旗舰 Opus 4.8：

• Terminal Bench 2.1：87.9 对 85.0
• 网络安全攻防基准 Cybergym：83.3 对 78.3
• DeepSWE：62.7 对 58.0
• 工作流智能体基准 AutomationBench：31.8 对 27.2

另有 Agents’ Last Exam 一项两者打平，均为 25.7。

与更强的 Fable 5 相比，差距仍在，但个别项目已经反超。Cybergym 上 V4 Pro 以 83.3 略微领先 83.1，AutomationBench 上 31.8 高于 29.1，是表中三个模型的最高分。Terminal Bench 2.1 几乎追平，87.9 对 88.0，只差 0.1 分。需要留意的是，表中对 Fable 5 的标注是带回退机制的成绩。

短板同样清楚。代码仓库生成任务 NL2Repo 上 V4 Pro 为 61.5，落后 Opus 4.8 的 69.7；工具调用综合测试 Toolathlon-Verified 为 74.1，低于 Opus 的 76.2 与 Fable 5 的 77.9；数据科学任务 DSBench-Hard 为 67.2，不及 Opus 的 71.7；DSBench-FullStack 为 71.1，略低于 Opus 的 71.6，与 Fable 5 的 77.2 差距更明显。知识推理测试 HLE 的表现比较特殊：不带工具时 V4 Pro 只有 42.7，明显低于 Opus 的 49.8 和 Fable 5 的 53.3；一旦允许调用工具，成绩升至 60.0，反超 Opus 的 57.9，逼近 Fable 5 的 63.0。

这组数字勾勒出的画像是：单纯拼静态知识储备，V4 Pro 不占优势；一旦进入需要动手、需要连续调用工具推进的场景，它的位置明显靠前。

价格：输出每百万 token 6 元，未跟随涨价

计费标准方面，deepseek-v4-pro 每百万 token 的价格为缓存命中输入 0.025 元、缓存未命中输入 3 元、输出 6 元。同系列的 deepseek-v4-flash 对应为 0.02 元、1 元和 2 元，两项主要计费项上 Pro 恰好是 Flash 的三倍。

放到国际同类产品的价目表里，这个数字的分量会更清楚。按每百万输出 token 折算，Fable 5 定价 50 美元，GPT-5.6 Sol Max 为 30 美元，同一晚发布的 Grok 4.6 为 6 美元，而 V4 Pro 约为 0.87 美元。0.1 分的跑分差距背后，是数十倍的价格落差。

值得注意的是，DeepSeek 官网此前挂出的「计划近期整体上调 API 服务定价，预计涨幅较大」提示仍未撤下，而这次正式版并没有跟着调价。对开发者而言，这更像是一个窗口期，而非长期承诺。

来源：OpenRouter、DeepSeek 官方 API 文档

针对这个问题，Coral AI Labs 与多所高校的研究者提出了 AgentRadio——一个异步消息传递层，让智能体在各自的执行步骤之间互相传话，同时又不打断手头的正事。在一项针对生产环境代码仓库的长周期问答基准测试中，用上 AgentRadio 的四个智能体团队，把任务准确率提升到了独立作业时的近两倍，并且超过了单个智能体搭载更强模型时的成绩。这项研究由 VentureBeat 记者本·迪克森（Ben Dickson）报道，论文已公开在预印本平台 arXiv 上。

单个智能体为什么会卡住

理解代码库是长周期任务中最极端的一种。智能体需要把软件构建起来、运行它、跨多个文件追踪执行路径，还要在很长的时间跨度内把证据综合到一起。在这种条件下，单智能体系统通常会栽在”覆盖问题”上。

论文的三位共同作者任新星（Xinxing Ren）、凯勒姆·福德（Caelum Forder）和彼得·卡罗尔（Peter Carroll）向 VentureBeat 解释说，单个智能体只能沿着仓库里的一条串行路径往下走，随着上下文不断膨胀，最初制定的计划越来越难修改，调查后期的新发现也未必能反向传导回去。模型执行单个步骤通常没问题，难点在于”让每一项待办、每一处依赖、每一条互相矛盾的证据，在漫长的调查过程中始终保持活跃”。

衡量这类能力的一个基准是 SWE-Atlas QnA，题目全部是针对真实生产仓库提出的长周期自然语言问题。这些题不是靠读代码就能答出来的，智能体必须把软件跑起来、执行多条命令才能找到答案。研究团队的实验显示，单个搭载 Opus 4.6 的编码智能体只能解决其中 32.3% 的任务；换成更先进的 Opus 4.8，成功率也只有 57.2%。

把工作量分摊给多个智能体，让每个智能体面对更小、更干净的上下文，是顺理成章的下一步。问题在于，多智能体方案带来显著收益的前提是任务”可以干净地拆分”——各部分能独立解决、最后合并即可。代码库理解恰恰很少满足这个前提，子任务之间高度互相依赖：某个智能体挖出的一个关键配置文件或一个缺陷，可能会彻底改写另一个智能体的整条探索路线。

研究者指出，现有多智能体系统大体落进三种有缺陷的模式：

• 并行但彼此隔离：智能体同时开工，全程零沟通。
• 并行但按轮同步：能沟通，但只能在严格对齐的轮次边界上进行。这迫使智能体停下来等同伴跑完一轮，才能交换中间发现。轮次制隐含了一个昂贵的假设——重要发现可以等到下一个通信阶段再说。
• 有名无实的异步：只提供有限的异步能力，比如自上而下派活，没有智能体之间的横向点对点通道，共享记忆也需要智能体主动暂停工作去读取更新。

按照论文的说法，当前多智能体系统的主要瓶颈就一句话：一个正在干活的智能体，没办法同时在听。研究者写道，就他们所知，还没有哪个系统能让并发工作的智能体通过一条横向的自然语言通道，获得对彼此的被动感知。

AgentRadio 怎么运作

为了打破”干活”与”倾听”之间的互斥，研究者做出了 AgentRadio。它是一层异步消息传递机制，可以直接插进现有的编码智能体框架里，为智能体提供三个原语：

• create_thread：在参与的智能体之间开启一个会话线程。
• send_message：向线程追加一条消息，发出后立即返回，不阻塞发送方。
• wait_for_mention：阻塞进程，直到收到一条提及调用方的消息；消息送达时会附带所有线程的完整快照，让智能体立刻拿到上下文。

三者组合起来，智能体就进入了一种”被动感知”状态：可以继续做主线任务，同时在后台收发消息、更新自己掌握的信息。

AgentRadio 的代码以 Apache 2.0 协议开源在 GitHub 上，设计上足够轻量，不需要改动底层的 Claude Code、Codex CLI 等智能体框架。架构分两部分：一是消息服务器，作为独立进程充当中心枢纽，存放所有活跃线程、消息和提及记录；二是框架侧集成，智能体通过三个简单的 shell 脚本与服务器交互，每个脚本对应一个原语。

系统运行的唯一硬性要求，是智能体框架能把 shell 命令作为后台任务运行。智能体会在系统提示词里被要求常驻一个监听进程，并通过提供的脚本发消息。把 wait_for_mention 脚本放到后台跑，智能体就能一边继续工作一边异步收到通知。要接进现有技术栈，团队仍需写一个”轻量适配层，负责启动工作进程、分配身份、连接共享服务器并管理最终综合”，但这部分工作位于编码智能体的外围，不必改动底层模型。

实测：翻倍的准确率，和翻了六倍的账单

研究者在 SWE-Atlas QnA 基准的 124 个任务上验证了这套框架，覆盖系统设计、根因分析、安全和接口集成等领域。骨干模型选用 Claude Opus 4.6 和 DeepSeek V4 Pro，框架配置从单个编码智能体（B0）、经典分工的智能体团队（L1），一直排到使用 AgentRadio 异步协同的团队（L3）。

结果是：Opus 4.6 单智能体只解决 32.3% 的任务，完整的 AgentRadio 配置把这个数字提到 62.1%，接近翻倍，并且越过了 Opus 4.8 单智能体 57.2% 的成绩；DeepSeek V4 Pro 的成绩也从 29.0% 提升到 50.8%。

论文里有一个 MinIO 系统的真实案例很能说明问题。解题需要逐请求检查服务器日志，而智能体在初始规划阶段没预料到这一点。在只能协作、不能异步通信的 L2 配置下，两个智能体在执行命令时各自意识到需要这些日志，但因为无法在执行中途共享发现，一个默默放弃了，另一个也没向团队提出；到了评审阶段，整个团队一致同意了错误答案，丢掉五个评分项。启用 AgentRadio 之后，智能体做出了同样的中途发现，但其中一个立刻把服务端日志证据广播到共享工作日志上，其余智能体因为处在被动监听状态，马上吸收了这条新证据。最终这道题从不及格变成了 16 分满分。

研究者对此的总结是，关键差别在于时机：团队不需要多一个智能体，也不需要多一轮评审，它需要的只是让某个智能体的发现在其操作价值过期之前传到该传的人手里。

代价也是真金白银。固定规模的多智能体团队必然成倍推高 token 开销，研究者承认”这笔税是实实在在的”：平均每个任务的接口调用花费，从单个 Opus 智能体的 2.96 美元涨到 AgentRadio 完整方案的 19.45 美元。

不过更关键的对照实验证明，这不是单纯靠砸钱换来的。当研究者用 17.76 美元跑六次独立的 Opus 任务做算力对齐时，模型只解决了 37.9% 的任务，远低于 AgentRadio 的 62.1%。这说明 AgentRadio 的收益来自架构本身，而不是暴力堆规模。

什么时候该上多智能体

研究者同时给出了明确的边界：固定的多智能体团队不该成为所有工程任务的默认答案。判断是否需要多智能体，更有效的标准是任务里有没有”责任断点”——也就是那些”一名称职的工程师会主动叫上另一个人”的位置：工作跨越了归属边界、需要一个独立假设，或者风险高到值得单独验证。

按照他们的说法，当任务可以被拆解、拆出来的部分之间仍然互相依赖、单智能体成功率不稳定，而且答案不完整会带来实质的下游代价时，协同机制就非常合适。典型场景包括仓库级架构问题、陌生的遗留系统、跨服务的事故排查、安全分析、依赖迁移和多模块重构。反过来，对”边界清晰、影响局部、可以回滚”的活——比如一处已知的单文件改动或样板代码生成——单个智能体依然是更干净的选择。研究者的建议是：只要一份上下文还能诚实地扛住整个问题，就继续用一个智能体；只有当现有智能体不得不压缩掉证据、跨越独立的归属边界，或者需要自己验证自己的高影响结论时，才引入新的责任方。

未解的难题集中在”注意力治理与验证”上。被动感知让通信在执行期间随时可用，但它并不决定应该存在哪些智能体、哪条发现值得打断别人、该通知谁、证据强到什么程度才可以推翻原计划。如果每个智能体都收到每一条更新，通信层就退化成噪声；如果几个智能体本来就共享同一个错误假设，更快的通信只会让错误扩散得更快。

论文中一个基于 Grafana 平台的案例正好印证了这个局限：九项评分标准中有四项需要得出否定性结论，比如观察到某个数据源选择器不会自动选中。智能体跑完了相关测试，却没有一个形成那个缺失的否定假设，两种配置都在这四项上失分。研究者的评价是，被动感知能扩散某个人已经提出的想法，但它没法凭空供给一个团队里从未出现过的构想。

按照研究者的判断，下一代系统需要的是自适应的责任分配、基于证据的路由、冲突解决机制、明确的成本上限、权限管理、故障恢复，以及清晰的人工升级节点；最重要的是可追溯的来源记录，好让工程负责人能查清是哪个智能体给出了某项断言、某个动作为何被采纳。用他们的原话说：运行时间越长的智能体，让沟通变得越重要，也让追责变得更难作假。

AgentRadio 目前仍是一个使用固定四智能体团队和五阶段协议的受控研究实现，其中的原理正被改造成一款名为 Coral Code 的商业产品，思路从自上而下的刚性协议转为自下而上——工程师从自己现有的编码智能体起步，只有当证据本身需要时，才引入仓库范围的调查、专职责任分工和通信机制。

来源：VentureBeat《Four AI agents coordinating in real time outperformed Claude Opus 4.8 on enterprise coding tasks》，作者 Ben Dickson；论文数据来自 arXiv 预印本

支撑这两套系统的是同一样东西：Cloudflare Codex——一套同时写给人和智能体看的工程规范。

问题不是没规范，是规范找不着

在 Codex 之前，Cloudflare 的开发指引散落在各处：正式文档、代码仓库里的说明文件、聊天记录，以及资深工程师脑子里的经验。工程师花在找规矩上的时间，常常超过花在解决问题上的时间。更糟的是，就算翻到了某条说法，也未必能判断它是否还有效、是否权威、是否适用于眼下的情况。

公司规模越大，这套模式越撑不住。没有哪个工程师能读完所有规范，评审者也不可能逐条核对每项要求。人员在团队之间流动，沉淀下来的经验越来越难被找回，而那些没被持续提示和执行的指引，最终导致各个项目各行其是。

Cloudflare 的做法是把这些知识重建成 Codex：一套有治理机制的工程规范，智能体可以在工程师干活的当下，把相关条款调取出来并应用。

规范怎么写，又怎么生效

Codex 按领域切分，涵盖架构类（例如前端、控制平面）、横切关注点（安全、可靠性）、具体语言（TypeScript、Rust）等方向，每个领域设一名负责人，对内容、一致性和整体质量负责。

规范采用 RFC（征求意见稿）格式撰写，要求用 RFC 2119 定义的 SHOULD（建议）与 MUST（必须）关键字表述，并在文件头部保留领域、状态等元数据。任何员工只要对某个领域有兴趣和相应能力，都可以按规定结构提交合并请求发起一份 RFC，经过多轮逐步扩大范围的评审，最后由领域负责人拍板，纳入 Codex 并发布到内部站点。

关键设计在于两段式生效。RFC 进入「已批准」状态后，智能体就会开始标记违规，但只提示、不拦截；只有当它被显式提升到「已强制」状态，MUST 类要求才真正具备拦下合并的效力。这个额外的推进步骤给了团队消化新要求的时间，也照顾了那些在执行层面还需要额外准备的情况。

还有一个绕不开的工程问题：Codex 已经积累了 60 多份 RFC 且仍在增加，如果原封不动全部喂给大模型，光是语料体量就会挤爆上下文窗口，反而拉低输出质量。Cloudflare 的解法是用一个专门的智能体，自动把所有 SHOULD 和 MUST 语句抽取压缩成 JSON 结构，并附上支持惰性发现和渐进披露的元数据。每条语句都有一个稳定的标识符，即便所属 RFC 被修订也不会变化——这让同一条要求能够在不同系统间被长期追踪，对监控、分析和例外处理都是必需的。团队最初把语句抽成更简洁的 Markdown 文件，后来才换成结构化程度更高的 JSON，好让智能体能更精准地筛选自己需要的内容。

三个正在用它的地方

目前有三个智能体在日常工作中消费 Codex。

第一个是 AI 代码审查器。它从多个维度评估合并请求，Codex 合规性是其中之一。每次审查时，它先取出相关 RFC 并解析其中的语句，只有在模型或协调器需要更多上下文时才加载 RFC 全文——多数情况下，抽取出的语句已足够解释一处违规。SHOULD 与 MUST 的区别加上 RFC 的状态，共同决定审查器的反应：来自「已批准」RFC 的发现只是不阻塞的建议；一旦 RFC 进入「已强制」状态，未满足的 MUST 要求会让审查器拒绝批准或直接拦下合并，具体取决于严重程度。自今年年初 Codex 建立以来，这个审查器累计标记了近 23 万处违规，其中近 1.6 万处导致合并未获批准。

它也有明显的体验短板：受协调器框架和子智能体执行的拖累，跑完一轮通常要几分钟，工程师抱怨等待时间和返工带来的额外往返。Cloudflare 为此补了两条路。对那些可以机械校验的语言类要求，提供与 Codex 规范对齐的定制 linter（静态检查工具）配置包，毫秒级出结果；TypeScript 率先支持，并统一使用 oxlint——其维护团队 VoidZero 近期已加入 Cloudflare，Rust 版本正在开发，Go 随后跟进。此外，AI 代码审查器现在也可以通过命令行在本地运行，功能与持续集成环境中的协调器一致，结果直接打在终端里。

第二个是设计文档审查器，面向工程师在动手前撰写的技术方案。它跑在 Cloudflare Worker 上，结果和状态存进 D1 数据库，模型请求走 AI Gateway，由定时触发器发起扫描。运行时它先按领域和章节过滤 Codex，把语言特性、实现细节一类与设计无关的 RFC 排除在外，再依据严重程度对发现分级。自 2026 年 5 月初以来，它已审查近 600 份独立的开放设计文档，算上按需重跑和文档变更触发的重跑，累计调用超过 3200 次。绝大多数发现属于「重要」（65%）或「次要」（29%）级别，「严重」级别只占 6%。

第三个是事故报告审查器，把同一套方法用在事故复盘上。除了检查报告是否完整，它还评估报告有没有讲清楚发生了什么、有没有识别出促成因素、有没有记录处置过程、有没有提出有意义的后续行动项。自 2026 年 5 月以来，它已评估 200 多份事故报告，指出过遗漏后续行动项、时间线不完整、漏记检测信号等问题。这些报告中有 93% 对应的是低影响、仅限内部或预防性声明的事故；对于高危事故，这道审查已被设为强制流程的一部分，所有发现被处理完毕之前，报告不算完成。

下一步

Cloudflare 表示将把这套模式扩展到整个软件开发生命周期，让智能体在设计、实现和运维各环节一致地暴露问题。更长期的目标是让智能体不只发现问题，还能以越来越高的自主性提出修复方案，而审阅和批准仍由工程师负责。

Codex 的适用范围也在往工程之外延伸，产品、安全、合规以及信任与安全团队已开始加入各自的标准。

用负责这项工作的工程师 Timo Reimann 的话说，AI 最有用的地方，是在工程师真正动手的那个节点，把对的指引送到他面前。

来源：Cloudflare 官方博客，作者 Timo Reimann

2026 年 7 月 30 日，一项发布在 arXiv 的研究提出了一种叫“锁匠循环”的方法，用来验证把遗留 COBOL 程序自动迁移成 Java 后，两者是否真的一致。研究团队为 COBOL 源码和生成的 Java 目标各准备一套模拟运行环境，在普通服务器上并行执行；再用智能体自动构造测试输入，逐层探索程序分支；遇到“锁住的段落”就分析条件、生成等价变异，直到打开新路。

他们试了三个真实案例，代码量从 430 行到 4114 行不等，两个开源程序几乎被测满，一个接近生产规模的内部程序也达到了 91.90% 的分支覆盖率。

兼容性真，不等于正确性真

有意思的是，论文专门强调：这种验证保证的是“兼容性真”，不是“语义正确真”。也就是说，Java 不仅要复现 COBOL 的原有功能，连它自带的 bug 都要一起搬过去，否则下游业务可能把“错误结果”当规则用了好几年，一改反而引发连锁故障。

说白了，银行、保险公司用 AI 迁移老代码时，最怕的不是“改对了没有”，而是“改完之后哪儿悄悄地不一样了”。锁匠循环的价值，就是把这种“不一样”在上线前自动抓出来。

给迁移团队的一句话

如果你的团队也在考虑让 AI 重写祖传代码，建议先别急着全量替换，而是拿一个小模块做这种并排验证。毕竟老系统的命根子不是代码多先进，而是业务连续性。

来源：Agentic Method for Deterministic Validation of Legacy Code Migration（arXiv:2607.28271，作者 Andras Ferenczi 等）

影片由德斯汀·克里顿执导，汤姆·赫兰德回归主演蜘蛛侠彼得·帕克。赞达亚、雅各布·巴塔隆等原班人马悉数回归，马克·鲁法洛（绿巨人布鲁斯·班纳）、乔·博恩瑟（惩罚者）重磅加盟。

故事承接《英雄无归》结局——奇异博士的咒语让全世界遗忘了彼得·帕克的身份，包括挚友MJ和内德。四年过去，已成年的彼得独自在纽约以”全职蜘蛛侠”身份默默守护城市。长期孤身作战的巨大压力引发了他身体的”基因进化”，自产有机蛛丝的同时能力面临失控风险。与此同时，蝎子、墓石等街头反派轮番来袭，”惩罚者”弗兰克·卡塞尔也卷入其中，陷入绝境的彼得将迎来破茧重生的终极考验。

本片在动作设计上迎来重大突破：成家班受邀担任动作指导团队，将中国传统武术的写实风格与超级英雄战斗体系融合，大量使用威亚实拍与实景搭建，力求让每一次腾跃和出拳都充满真实质感。马克·鲁法洛饰演的布鲁斯·班纳将为陷入困境的彼得提供关键支援。

据灯塔专业版数据，截至7月20日该片预售总票房已突破1000万元人民币，暑期档期待值持续走高。荷兰弟在接受采访时表示：”我们打造出了有史以来最棒的一版蜘蛛侠电影。”

来源：综合多家媒体报道