Copilot迁移80万行Rust，AI编程为何仍难交付

一边是 GitHub 自述用 AI 辅助把 Copilot 运行时改写成了超过 80 万行 Rust，另一边是 Real-SWE 的二手评测文章里，领先模型的成绩也只有 38.8%。这两条放在一起，比任何一张新模型榜单都更像程序员面对的现实。

这期聊 2026 年 9 月 14 日到 20 日值得读的 AI 动向。我更关心一个变化，模型开始接手持续运行的工程任务，开发容器、权限、会话恢复和验收也跟着成了选型条件。便宜当然好，能写当然好，但改完以后谁来确认、失败以后怎么接着跑，正在决定这些工具到底能省多少事。

一、AI 能写 80 万行代码了，为什么还做不好企业工单？

先说结论，代码生成规模和任务交付能力，得分开看。

GitHub 官方博客披露，Copilot 智能体运行时从 TypeScript、Node.js 和 V8 迁到了 Rust。超过 80 万行生产代码，大部分由 AI 智能体编写，分成 128 个 PR 合入，再逐步发布。文章称，这项工作主要由一名开发者在几个月内推进，期间团队其他成员继续开发运行时功能。

这个案例确实够大，但我最想划出来的数字是 128。

它说明这次迁移有拆分、有合并过程，也有发现回归再修复的反馈。有人决定迁什么、怎样接入现有产品、什么状态可以发布。把这些省掉，只留下「AI 独立完成大型重构」，会让准备照着干的团队低估后面的工作。

另一篇 Real-SWE 评测解读提供了另一面。文章转述的测试包含 10 个私有企业代码库任务，8 个模型，每个任务各尝试 8 次，领先模型的成绩为 38.8%，GPT-6 Astra 为 33.8%。其中一个任务，所有模型合计 64 次尝试都失败了。

别急着把 38.8% 套到自己公司的工单上。任务只有 10 个，范围又是人类工程师需要数周处理的工作，还带着模型必须自行发现的隐藏需求。文章作者也说明自己没有运行测试。这组数据适合提醒我们看失败方式，拿来预测团队下个月的交付率就太远了。

两条报道其实不冲突。迁移任务可以沿着已有行为逐步对照，复杂业务任务还要把没有写进工单的规则找出来。前端同学应该很容易理解这个区别。把一批组件改成新 API，和处理「切换企业后，旧页面偶尔显示上一家企业的数据」，需要的上下文完全不同。

回到这块，这周对工具选择更有用的变化，是我们开始看到大规模代码生产背后的组织方式。你打算让 Agent 接手的究竟是边界清楚的改写，还是需求尚未厘清的调查，应该在选模型前说清楚。

Claude Code 与 Cursor 的任务对比文章建议，跨文件、目标驱动的任务偏向 Claude Code，局部修改和补全偏向 Cursor。我认同按任务来选的思路，但不会把两者的能力画成互不重叠的区域，文章自己也提到了 Cursor 的 Agent 面板。

要我选，我会把近期真实任务分成局部编辑、跨文件迁移、业务缺陷调查三组，让候选工具面对同样的权限和验收要求。记录人工补了多少需求、返工几轮，比统计生成代码行数更容易看出谁适合留下。

二、Step 5 和 DeepSeek 这么便宜，AI 编程该换模型了吗？

模型费用开始让人心动了。

据 IT之家对 Step 5 Preview 的报道，阶跃在 9 月 20 日公布的模型采用稀疏 MoE，总参数量 600B、激活参数 27B，支持百万 Token 上下文。报道转述其 AA Intelligence Index 得分为 44，单任务成本为 Claude Opus 5 的八分之一，并介绍了覆盖 553 个代码仓库的 StepCodeBench。

这里有个坑，报道里的「开源前三」和现在就能下载完整权重不是一回事。按同一篇报道的安排，完整权重要到 10 月 15 日才释放。准备做本地部署的同学，别拿今天的在线开放替代下个月的权重交付。

另一个价格信号来自 DeepSeek V4.1 Flash 的 Agent Arena 解读。文章给出的任务成本中位数是 0.07 美元，并称其进入了性能与成本的帕累托前沿。在那组参评配置里，找不到另一个同时更便宜、表现又更好的选项，才是这句话的含义。

我对把 0.07 美元直接写进项目预算持保留意见。中位数看不到昂贵的尾部任务，也不能替我们算失败重试、工具调用和人工接管。Step 5 的八分之一，同样需要带着任务集和运行条件读。两个来源的数字不能摆在一张表里直接比大小。

真正该算的是交付一个合格结果花了多少钱。

这个账可以先用一个简单的 JavaScript 对象记起来，把失败尝试和人工复核也算进去。

const batch = {
  acceptedTasks: 12,
  modelCost: 8.4, // 包含失败和重试的模型费用
  toolCost: 2.1,
  reviewHours: 1.5,
  hourlyCost: 100, // 示例折算值，所有费用须用同一币种
};

const totalCost =
  batch.modelCost + batch.toolCost +
  batch.reviewHours * batch.hourlyCost;

const costPerAcceptedTask =
  batch.acceptedTasks > 0
    ? totalCost / batch.acceptedTasks
    : null; // 没有验收通过的任务，就没有可比较的单价

最容易算错的是 acceptedTasks，必须按相同验收条件计数，不能把模型宣布完成的次数塞进去。

再看 GPT-6 Astra，输入里的两篇文章已经提醒我们别急着抄价格。一篇发布解读称最终 API 定价尚未披露；另一篇成本分析给出了具体费率，还把发布日期写在 9 月 3 日。它们无法直接拼成一条「本周刚发布且价格已确定」的新闻。

成本分析里还有个很具体的细节。它写输入超过 272,000 Token 后，输入单价从 10 美元升到 20 美元，输出从 50 美元升到 75 美元，均按每百万 Token 计。即便按这篇文章的说法，也不能概括成输入输出全部翻倍，更不能把二手文章当作采购报价。

所以这周我会把便宜模型放进候选池，但不会立刻全量切换。真要判断换不换，我会拿仓库里最近 20 个真实任务，固定工具、权限和验收条件，连同失败成本一起跑；涉及 Astra 的预算，则等实际账户可用的模型和计费条款对上以后再落表。

三、Agent 放进开发容器，能解决哪些环境问题？

顺着上面聊，便宜模型要是一直装依赖、找命令、修环境，账单照样不好看。

VS Code 1.138 的更新报道介绍了在本地开发容器里运行智能体会话的能力。开启 chat.agentHost.devContainer.enabled，本地文件夹具有受支持的开发容器配置，并安装 Docker 后，就可以选择在对应容器中运行会话。

我觉得这条比又增加一个模型入口更贴近日常开发。

一个前端仓库往往不只是几份源码。Node 版本、包管理器、系统依赖、测试浏览器，还有项目约定的执行脚本，都能影响 Agent 是否顺利干活。工具放进项目指定的环境，至少给了我们一个更明确的起点。下次失败时，可以先区分是代码问题，还是环境没有对齐。

但容器不会自动替你处理全部权限。挂进去的目录、注入的凭证、开放的网络，仍然决定它能接触什么。隔离做到了哪一步，要看配置。

同一篇报道还介绍了扩展后的 Codex harness，涉及 ChatGPT 与 VS Code 会话延续，以及 Copilot、ChatGPT 订阅的选择。这里值得观察的是，会话、工具和运行环境正在成为产品能力的一部分。我们挑编码助手时，需要比较的东西变多了。

OpenAI Agents API 的解读文章也在讲这层能力。文章把上下文压缩、持久会话、工具按需加载、子任务分发与结果合并列为托管服务负责的工作。不过它标出的发布日期是 9 月 10 日，因此这期把它当作理解工作流变化的背景，不能再算成本周首发。

托管这些能力，对小团队有吸引力。以前写一个 Agent 演示，循环调用模型就能动；要持续跑任务，很快就得补状态保存、恢复和任务编排。现在至少出现了把这些能力作为服务提供的路线。

账也会多一层。省下多少维护时间、换来多少平台绑定、任务记录能否导出，都得一起看。文章引用的客户提效数据，我只会当作试用线索，客户工作负载和我们的仓库未必相似。

你要是也在做长任务 Agent，我会先挑一个能重复执行的仓库任务，验证容器里能否完整跑通，再在执行中断开进程，观察恢复后有没有漏掉步骤或重复操作。能从中断处可靠接上，比演示里连续跑几个小时更能说明问题。

四、后台 Agent 还在跑，用户退出后权限怎么办？

这是我觉得最容易被界面掩盖的问题。

页面关掉了，任务未必结束。用户退出当前设备、离开某个组织，或者被管理员撤掉角色时，后台 Worker 和 Agent 可能还拿着之前的授权状态继续执行。

大规模会话管理的文章把这个问题讲得很直接。会话关联的信任会进入 API、Worker、WebSocket 和 Agent。登录时身份验证通过，不能保证几个小时后的租户成员资格和敏感权限仍然有效。

过去前端可能只需要处理「接口返回未登录，跳转登录页」。当产品允许用户把任务交出去以后，登录会话与任务授权就得分别定义。退出是否取消任务，可以由产品决定；管理员撤销某项权限后，任务还可不可以继续使用这项权限，则必须有明确规则。

说实话，我更担心的不是模型忘了指令，而是系统根本没有把最新授权送到执行点。

上下文工程指南提出，在每次调用前组装当前需要的信息、工具和约束。这和会话文章正好接上。模型规划任务时看到的角色、文档范围和工具列表，不应该永远停在任务创建的那一刻。

不过，把最新权限写进提示词还不够。真正执行工具的服务端也要检查。下面这段只说明应用侧应如何传递撤销约束，toolGateway 代表你自己的执行网关，并非某个平台 SDK。

async function executeTaskAction(task, action) {
  const grant = await loadCurrentGrant(task.grantId);

  if (!grant || grant.revokedAt ||
      grant.expiresAt <= Date.now()) {
    throw new Error("任务授权已失效");
  }

  if (grant.tenantId !== task.tenantId ||
      !grant.actions.includes(action.type)) {
    throw new Error("操作超出授权范围");
  }

  return toolGateway.execute({
    action,
    grantId: grant.id,
    expectedGrantVersion: grant.version, // 执行端仍须校验当前版本
    idempotencyKey: `${task.id}:${action.id}`, // 重试复用同一操作标识
  });
}

最容易翻车的是 expectedGrantVersion 那一行，网关如果只是接收字段却不在执行时校验，前面的检查仍会留下撤销与执行之间的时间窗口。

这也解释了为什么我会把那条军事 AI 报道放在权限和执行环节讨论。The Decoder 转述 CNN 的报道称，2026 年春季的一次行动险些依据 AI 生成的错误情报登上一艘中国船只，直到行动准备阶段才发现问题。这里讲的是春季事件，不能写成上周刚发生；细节也只能按报道归属来引用。

它对业务系统的提醒很具体。一个模型判断，从生成到变成实际动作，中间有哪些检查，不能靠「模型应该知道」来补齐。

提示词里的权限边界，必须在执行端兑现。

我会在测试环境让一个任务停在写操作之前，再撤销对应授权，确认它能否被真正拦住；随后重试同一个操作，检查是否重复写入。光看聊天窗口里有没有弹出一句拒绝，验证不了这件事。

五、提取 JSON 和分发工单，还需要调用大模型吗？

不是每个请求都需要模型长篇思考。

GLiFormer 的介绍提供了一条很适合业务团队关注的路线。它接受抽取 schema，用编码器处理文本，再把抽到的内容组织成结构。报道给出的 Large 版本参数量约为 5.756 亿，嵌套 JSON 抽取成绩为 91.10 F1，并称两个检查点采用 Apache 2.0 协议，支持 CPU 和 GPU。

这个分数只能放在对应抽取评测里理解。接近某个大模型的成绩，不代表通用推理、代码能力或者所有中文文档处理都接近。

我更喜欢它对输出值的约束。按照文章描述，字段值来自源文本跨度，再经过记录分配、父子关系预测和确定性组装生成 JSON。少了逐 Token 生成值文本这一步，能减少凭空写出输入中不存在内容的机会。

但别把它读成零错误。名字可能抽错，金额可能分给另一条记录，父子关系也可能连反。结果格式合法、每个值都在原文里，仍然可能是一份业务上错误的 JSON。

回到前端常接的需求，简历录入、订单邮件解析、工单分类，很多时候需要的是把已有信息准确放进字段。这类任务值得单独评估抽取模型，没必要因为系统已经接了一个聊天 API，就让所有请求都走同一路径。

Latent Space 关于 Jev 的线索则把范围收得更窄，关注分类、路由和打分，并给出了比小型前沿模型快 100 倍、便宜 200 倍的说法。这个数我不太买账，至少现在还不能直接拿来算业务收益。现有摘录明确说完整原文未能稳定获取，对比配置和任务条件也不够清楚。

它仍然提出了一个值得试的问题。如果只是判断工单进入哪个队列，我们是不是为不需要的生成能力付了钱？

两条消息连起来，对成本的影响很实际。抽取、分类交给适合的模型，含糊的请求再交给生成模型处理，可以形成不同的执行路径。不过多接一种模型也会增加部署、监控和维护工作。请求量不大时，多维护一套服务未必划算；别只盯着单次推理费用。

我会挑一批已经有人工答案的业务样本，故意放入缺字段、重复实体、一段文本包含多笔订单的情况，比较字段准确性、记录归属和延迟。对路由任务，再单独统计分错队列的代价，尤其别让便宜的误判触发昂贵的后续流程。

六、设计系统接入 MCP，前端还需要补什么？

对前端来说，这周最值得琢磨的一条线索，是组件库开始考虑怎样被 Agent 使用。

关于 Meta Astryx 的文章称，这套设计系统基于 React 19 和 StyleX，包含超过 150 个无障碍组件，并配有 CLI 和 MCP 工具。当前引用的是二手介绍，我会先把它列入观察名单，具体接入方式和兼容性还得看项目本身。

但它提出的问题很真实。组件库有文档，不等于 Agent 每次都能找到正确组件；有 TypeScript 类型，也不等于它知道业务里什么时候该用弹窗、什么时候该进新页面。

前端做过设计系统就知道，真正容易用错的往往是组合规则。提交按钮什么时候禁用，表单报错怎样定位，加载中是否允许重复点击，空状态应该保留哪些操作。这些信息如果只存在于设计评审和同事记忆里，Agent 很难稳定复用。

所以我对 CLI、MCP 接入的期待，是让工具能查到当前版本的属性、可用示例和使用限制。它能否少写一个自制按钮，少引入一种不一致的交互，比「支持 AI」这个标签更有说服力。

另一边，Google DeepMind 的 Gemini 3.8 Live 介绍强调实时语音、视觉上下文，以及对话进行时的后台任务处理。按这份介绍，Extended Thinking 版本面向更复杂的多步任务。

这会把前端的问题从「答案怎么显示」推进到「任务进行到哪了」。用户还在说话，后台工具已经开始执行；用户中途改主意，页面应该显示哪一个目标；某个动作完成了，另一个动作失败了，要怎样解释当前状态。这些都需要明确的交互设计。

别让一个旋转图标扛下所有状态。

把这条与 Astryx 放在一起看，我的判断是，组件的价值会越来越依赖它是否能表达真实的任务状态。既要让 Agent 找到适合的组件，也要让用户看清计划、等待、执行、失败和取消之间的区别。语音听起来流畅，并不能证明后台操作已经成功。

成本同样会落在前端体验上。重复点击、取消无效、断线后重建任务，都可能带来额外调用。任务标识、重试行为和状态恢复如果没有设计清楚，模型单价再低也会浪费。

真要试这两类能力，我会让 Agent 按现有设计规范搭一张带加载、失败和重试状态的表单，检查它有没有复用组件；再用一个可取消的后台任务验证页面，看看用户中断后，界面和服务端是不是都停在同一个状态。

总结

这周我最想留下的判断是，AI 编程的选型单位正在从一次回答扩大到一项任务。模型费用只是其中一段，运行环境、上下文、权限、重试和人工验收都会影响最终结果。

我会优先关注三件事，便宜模型能否通过现有验收，编码工具能否在明确的项目环境里恢复执行，简单抽取和分类是否值得从通用模型里拆出去。新模型依然要看，但不会因为一张榜单就重写工作流。

另外，有几条热闹消息不适合按标题直接转发。Step 5 的完整权重按报道要到 10 月 15 日开放；Grok 4.8 的消息说的是马斯克预计本周完成训练、进入强化学习，不能据此写成已经可用。输入中的 Astra 和 Agents API 文章也带着此前的发布日期。这些时间差会直接影响我们现在能不能动手。

我给下周留一个可检验的判断，9 月 21 日到 27 日的新公告中，会至少有一项编码 Agent 更新，把会话恢复、执行环境或任务管理作为主要能力，而不只是增加模型选项。如果没有，这个判断就算没押中。

至于模型说自己做完了，还是打开 diff，再看验收结果。

参考

一、AI 能写 80 万行代码了，为什么还做不好企业工单？

先说结论，代码生成规模和任务交付能力，得分开看。

这个案例确实够大，但我最想划出来的数字是 128。

二、Step 5 和 DeepSeek 这么便宜，AI 编程该换模型了吗？

模型费用开始让人心动了。

真正该算的是交付一个合格结果花了多少钱。

这个账可以先用一个简单的 JavaScript 对象记起来，把失败尝试和人工复核也算进去。

const batch = {
  acceptedTasks: 12,
  modelCost: 8.4, // 包含失败和重试的模型费用
  toolCost: 2.1,
  reviewHours: 1.5,
  hourlyCost: 100, // 示例折算值，所有费用须用同一币种
};

const totalCost =
  batch.modelCost + batch.toolCost +
  batch.reviewHours * batch.hourlyCost;

const costPerAcceptedTask =
  batch.acceptedTasks > 0
    ? totalCost / batch.acceptedTasks
    : null; // 没有验收通过的任务，就没有可比较的单价

最容易算错的是 acceptedTasks，必须按相同验收条件计数，不能把模型宣布完成的次数塞进去。

三、Agent 放进开发容器，能解决哪些环境问题？

顺着上面聊，便宜模型要是一直装依赖、找命令、修环境，账单照样不好看。

我觉得这条比又增加一个模型入口更贴近日常开发。

但容器不会自动替你处理全部权限。挂进去的目录、注入的凭证、开放的网络，仍然决定它能接触什么。隔离做到了哪一步，要看配置。

四、后台 Agent 还在跑，用户退出后权限怎么办？

这是我觉得最容易被界面掩盖的问题。

页面关掉了，任务未必结束。用户退出当前设备、离开某个组织，或者被管理员撤掉角色时，后台 Worker 和 Agent 可能还拿着之前的授权状态继续执行。

说实话，我更担心的不是模型忘了指令，而是系统根本没有把最新授权送到执行点。

async function executeTaskAction(task, action) {
  const grant = await loadCurrentGrant(task.grantId);

  if (!grant || grant.revokedAt ||
      grant.expiresAt <= Date.now()) {
    throw new Error("任务授权已失效");
  }

  if (grant.tenantId !== task.tenantId ||
      !grant.actions.includes(action.type)) {
    throw new Error("操作超出授权范围");
  }

  return toolGateway.execute({
    action,
    grantId: grant.id,
    expectedGrantVersion: grant.version, // 执行端仍须校验当前版本
    idempotencyKey: `${task.id}:${action.id}`, // 重试复用同一操作标识
  });
}

最容易翻车的是 expectedGrantVersion 那一行，网关如果只是接收字段却不在执行时校验，前面的检查仍会留下撤销与执行之间的时间窗口。

它对业务系统的提醒很具体。一个模型判断，从生成到变成实际动作，中间有哪些检查，不能靠「模型应该知道」来补齐。

提示词里的权限边界，必须在执行端兑现。

五、提取 JSON 和分发工单，还需要调用大模型吗？

不是每个请求都需要模型长篇思考。

这个分数只能放在对应抽取评测里理解。接近某个大模型的成绩，不代表通用推理、代码能力或者所有中文文档处理都接近。

它仍然提出了一个值得试的问题。如果只是判断工单进入哪个队列，我们是不是为不需要的生成能力付了钱？

六、设计系统接入 MCP，前端还需要补什么？

对前端来说，这周最值得琢磨的一条线索，是组件库开始考虑怎样被 Agent 使用。

别让一个旋转图标扛下所有状态。

总结

至于模型说自己做完了，还是打开 diff，再看验收结果。

AI雷达周报

本期看点

一、AI 能写 80 万行代码了，为什么还做不好企业工单？

二、Step 5 和 DeepSeek 这么便宜，AI 编程该换模型了吗？

三、Agent 放进开发容器，能解决哪些环境问题？

四、后台 Agent 还在跑，用户退出后权限怎么办？

五、提取 JSON 和分发工单，还需要调用大模型吗？

六、设计系统接入 MCP，前端还需要补什么？

总结

参考

AI雷达周报

本期看点

一、AI 能写 80 万行代码了，为什么还做不好企业工单？

二、Step 5 和 DeepSeek 这么便宜，AI 编程该换模型了吗？

三、Agent 放进开发容器，能解决哪些环境问题？

四、后台 Agent 还在跑，用户退出后权限怎么办？

五、提取 JSON 和分发工单，还需要调用大模型吗？

六、设计系统接入 MCP，前端还需要补什么？

总结

参考