Mercury 3每秒1068 token，AI编程为何还慢

49 分钟的 AI 编程任务，47 分钟耗在全量测试上。另一边，新模型把生成速度喊到了每秒 1068 token。把这两条消息放一起，挺有反差。模型越跑越快，程序员却未必能早点下班，因为等待还藏在测试、工具调用和失败重试里。2026 年 10 月 22 日这份 AI 热点日报，我想沿着六条线聊模型选型、任务成本、权限、状态、并行开发和团队治理，帮你判断哪些更新该试，哪些数字先别急着信。

一、百万上下文和千 token 秒速，为什么还不能直接换编码模型？

先说结论，我会把今天这批模型放进候选名单，但不会因为「百万上下文」就调整现有开发流程。

Step 5 Preview、MiniMax M3.1 Flash 和 Mercury 3，分别把开放权重、长流程成本和生成速度推到了台前。它们在争同一件事，让 Agent 连续读文件、调用工具、修改代码时，少受容量和等待限制。

按 Step 5 Preview 的介绍文章，模型总参数为 6000 亿，每 token 激活 270 亿，支持最高百万 token 上下文，提供 BF16、FP8 和 NVFP4 权重。

这里有个坑，270 亿激活参数不能拿来估算整套部署规模。

MoE 每一步只调用部分专家，能减少参与计算的参数，但其余专家的权重仍得存放。文章自己给出的 NVFP4 部署数字，也在约 340 GB 显存这个级别。看到「开放权重」就想到团队找台闲置机器部署，预算很容易算偏。

它采用局部和全局注意力交替的设计，可以理解为同时照顾附近代码和远距离约束。不过，能访问远处的内容，与修改时真能遵守那份接口约定，还隔着实际任务测试。

上下文窗口是容量规格，仓库修改通过验收才是工作能力。

MiniMax M3.1 Flash 的介绍则更强调长流程成本。文章报告其总参数为 4280 亿、激活参数为 230 亿，生成速度中位数超过每秒 170 token，相对 M3 在线推理提速三倍、平均任务成本下降约 70%。

这些是文章转述的成绩，没有独立复测过程。尤其「平均任务成本」这几个字，必须连着任务范围、失败处理和重试规则一起读。便宜模型多绕十轮，账单未必更漂亮。

Mercury 3 的报道给出了更抢眼的每秒 1068 token。它采用文本扩散，通过多轮并行修正文本来生成内容，减少逐 token 顺序生成带来的限制。

方向有意思，这个数我持保留意见。文章对 1068 TPS 先后用了持续速度、峰值和中位数的表述，质量测试条件也不完整。它提到的浏览器测试只有 50 次，部分对照完成率又无法按每题一次的口径解释。

回到这块，前端真正关心的是改完能不能跑、交互对不对、类型和接口有没有一起收好。生成快当然有用，但它只是整个任务中的一段。

要我选，我会拿同一仓库里的三类小任务做一轮筛选，包括跨文件改接口、修一个已有测试覆盖的缺陷、按现有组件实现页面。固定工具权限、上下文和停止条件，记录验收结果、总耗时与全部调用费用，当天先判断有没有继续测的必要。

二、AI 编程费用怎么比较，为什么省 token 不一定省钱？

顺着上面聊，今天另一个明显信号是，大家开始拆模型外面的成本了。

编码 CLI 的 44 次运行测试里，两款工具使用相同名称的 Opus 5.5，Antigravity 报告的输入 token 比 Claude Code 少 68% 至 88%，完成时间短了 27%。

先别把它转成采购结论。

这组测试来自一台 Windows 11 机器、一天的运行，开发任务是一道打砖块小游戏题。更关键的是，68% 和 88% 对应两种缓存统计口径，并非多次实验形成的波动范围。缓存读取是否包含在输入里，原文没有解释清楚。

我的读法是，这条最有用的发现，是提醒我们检查系统指令、工具定义和缓存统计。团队给 Agent 挂了几十个 MCP 工具，每个工具的描述都有机会变成上下文开销，模型本身的单价只是账单的一部分。

另一个方向是缩小任务。

Intercom 的小模型替换案例提到，他们把检索前的查询归一化，从 GPT-4.1 换成微调后的 140 亿参数 Qwen。按负责人回忆，这个环节原先每月可能花费约 25 万美元，替换后省掉了其中几乎全部推理支出。

这里的适用条件很具体。任务边界窄、频率高，而且提示词调过的未训练模型已经接近要求，才进入微调和线上测试。负责最难回答的模型仍是 Claude Sonnet 4，不能把这件事读成小模型接管整个客服系统。

我会先找高频、边界清楚的辅助调用，再考虑替换最终回答模型。

schemagate 的 Text-to-SQL 实验也在做类似取舍。它先选相关表，再把必要的表结构交给模型，每题约 2100 个提示 token，在 BIRD 完整开发集 1534 道题上报告了 77.12% 执行准确率。

正常路径只生成一次 SQL，执行报错后仍会追加修复调用。隐藏测试成绩当时尚未返回，也没有同模型、同数据集的多调用对照。它能支持的判断是，精简上下文值得试，暂时撑不起「比榜单方案更划算」的结论。

说实话，很多团队在讨论便宜模型之前，还没分清模型到底收到了什么。

可以先用一份 JavaScript 记录格式，把不同工具输出的字段整理清楚，避免缓存 token 被重复相加。

const taskRecord = {
  taskId: "fix-checkout-validation",
  model: "candidate-a",
  attempts: 2,
  accepted: false,
  elapsedMs: 0,
  usage: {
    inputTokens: null,
    cacheReadTokens: null,
    outputTokens: null,
    cacheIncludedInInput: null, // 不清楚时保留未知，别直接求和
  },
  actualCost: null, // 优先记实际费用，不从 token 降幅推算收益
};

最容易翻车的是 cacheIncludedInInput，没搞清口径就算总量，会把统计差异当成产品优势。

你要是也在做 AI 办公提效，比如查询改写、摘要和资讯分类，我会各挑一批已有结果的输入，先试精简上下文，再试小模型。当天能拿到一组质量、耗时和费用记录，比直接讨论微调更有用。

三、让 Agent 调工具和操作登录账号，权限应该卡在哪？

模型再强，工具入口也不能省校验。

Semantic Kernel 两起漏洞的分析把问题讲得很直接。一条链路把过滤字符串拼进 Python 表达式，再交给 eval()；另一条把允许指定本地目标路径的下载方法暴露给模型，最终出现越界写入风险。

提示注入把危险参数送过来，工具实现给了它执行机会。

文章的小规模对抗样本里，字符串黑名单放过了 14 个表达式中的 11 个。这不能当成所有工具的攻击成功率，但足够说明，搜几个危险词撑不起表达式执行的边界。

路径检查也是同一回事。模型说要写到某个目录，系统仍得判断这个位置是否获准，不能因为参数符合字符串类型就放行。

Kinaya 的登录态浏览器设计则提供了另一个角度。它给每个 MCP 会话独立后台标签页，并允许通过 tab_id 明确操作目标；读取页面与点击、输入、上传、登录，采用不同的权限安排。

这个拆法我认可。Agent 能读取登录后的页面，并不自动获得替用户提交表单或上传文件的授权。

密码不进入模型上下文，也只解决了凭据暴露的一部分。账号已经登录，页面里的恶意文字仍可能诱导 Agent 做错事。作者也承认，把网页视为不可信内容的服务端指令需要配合动作审批，单靠提醒不够。

模型生成参数，系统决定这些参数有没有资格执行。

执行 AI 推荐脚本前核验文件的实验还补上了下载这一环。SHA-256 能发现文件与预期摘要不一致，但摘要和脚本如果都来自攻击者，校验照样通过。从 AI 回答里复制一个哈希值，也不能补出可信来源。

这几条放在一起，我会优先检查工具能造成什么后果。读数据、写文件、执行命令和操作账号，应当有各自的限制。

真要当天动手，不必先做复杂攻防。挑两个带副作用的工具，输入越界路径、缺失参数和未经授权的目标，确认它们在入口被拒绝；再把网页里的诱导文字作为测试数据，观察系统是否仍会拦住敏感操作。两类测试分开做，才能知道是模型没上当，还是系统确实守住了边界。

四、Agent 总是重试和忘事，除了改提示词还能做什么？

大概率你也遇到过，接口已经执行成功，Agent 却因为没收到确认又来了一次。或者它说记住了项目约定，隔几轮又开始自由发挥。

这两类问题都容易被一句「模型不稳定」盖过去。

Agent 故障分类文章把故障拆成工具边界、返回数据、模型决策、副作用和循环控制五类。超时、429、截断的 JSON、重复写入、工具来回调用，处理位置各不相同。

它基于注入故障的玩具 Agent，不能据此认定生产环境的大多数故障都与模型无关。但这个分类很好用，至少能阻止大家每次出错都去追加 system prompt。

拿重试来说，执行成功但响应丢失，与执行前就失败，对业务的影响完全不同。执行框架需要稳定的操作标识，接收端也得按标识去重。

下面这段 JavaScript 在模拟响应丢失后重试，检查同一步操作是否沿用同一个幂等键。

async function retrySameOperation(callTool) {
  const operation = {
    idempotencyKey: "task-42:step-3", // 在重试循环外确定
    args: { orderId: "order-7" },
  };

  for (let attempt = 0; attempt < 2; attempt++) {
    try {
      return await callTool(operation, {
        dropResponseAfterCommit: attempt === 0,
      });
    } catch (error) {
      if (!error.retryable || attempt === 1) throw error;
    }
  }
}

最容易翻车的是 idempotencyKey 的生成位置，放进循环每次换一个值，重试就会变成新的业务请求；接收端没有去重实现时，这段代码同样保不住副作用。

Bareship 的离线写入设计也碰到相同问题。客户端把操作落盘，重连后重放，同一次写入的多次发送携带同一个幂等键。但服务端怎么保存去重记录、多端冲突怎么处理，文章没有展开，不能只靠客户端就承诺业务只执行一次。

长程记忆则可以看 Goink 的设计。它用 SQLite 保存人物关系、伏笔和故事线，模型通过工具查询、更新，再配合本地检索和 Git 管理修改。

虽然应用场景是写小说，我觉得这种显式状态管理很适合拿来思考长任务。已经完成什么、哪些约束仍有效、下次从哪一步恢复，都可以脱离聊天记录保存。

不过，数据库记错了也会持续误导后面的任务，写完注入检查清单也不等于更新正确。

回到业务系统，我会挑一个可恢复的小流程，分别注入超时、损坏返回值和执行后丢响应，再让进程中断一次。当天先看它会不会重复写入、能否准确报告当前状态，再决定提示词究竟该补在哪里。

五、多个编程 Agent 并行工作，为什么还会互相覆盖和越跑越慢？

并行开发有两个很现实的问题，文件会不会互相覆盖，时间到底省在哪里。

Git worktree 的实验让两个模拟 Agent 在独立目录和分支修改同名文件，未提交内容没有互相覆盖。只建两个分支、仍指向同一个工作目录，解决不了这个问题。

独立工作树可以隔离文件状态，但多个工作树仍共享仓库。它也不会替你处理最后的合并冲突，更不是进程或安全沙箱。

我会把它理解成给每个 Agent 一张独立工作台。工作台分开了，审查和合并还得照做。

另一头，session-profiler 作者的会话分析解释了开头那组数字。一次合并任务用了 49 分钟，其中完整测试占了 47 分钟；作者还列出了移动端截图、完整检查拖长任务的例子。

这些来自作者自己的会话观察，公开图也使用了按真实耗时构造的演示数据。它不能代表所有编程助手，却给了一个很实用的排查顺序。

先看时间线。

如果最长的一段是全量测试，换生成速度更快的模型，能省下来的时间就有限。作者后来采用迭代时先跑相关测试、收尾时再跑一次全量的方式，我更愿意从这里试起，同时保留项目要求的必要检查。

出了回归也不必逐个问 Agent「是不是你刚才改坏的」。Git bisect 的示例在构造的 16 次提交历史里，用 4 轮测试定位到缺陷提交。

四轮是该案例的结果。中间版本无法构建、问题修复后又出现，都可能让真实排查更麻烦，关键仍然是先把异常变成可重复判断的测试。

前端交接还有个挺具体的补充。figlens从本地 .fig 打包画框信息、变量、素材与参考图，让云端 Agent 通过文件读取设计依据。字体不在包里，离线也只覆盖设计解析，别把它理解成整个开发过程无需联网。

我的取舍是，先把输入、目录和验收分别固定好，再增加 Agent 数量。当天可以拆两个相对独立的页面任务，分别放到工作树，记录实现、测试和等待耗时，合并后再验一次交互；这一轮足够看出瓶颈究竟在协作还是命令执行。

六、团队接入多个模型之后，怎么把权限和预算一起管住？

模型越多，后台也越多。开发者按任务切工具，负责人却要回答谁能用、费用记在哪、超额之后是否继续跑。

JetBrains Air Governance 的发布说明称，产品已正式可用，支持集中管理 Agent、模型、供应商和用户组，并提供预算与用量管理。

这条适合团队负责人关注，不过要看清功能边界。集中式 BYOK 已经提供，BYOK 模型的额度限制和自定义定价仍在开发中，不能把通用预算能力直接套到所有自带账号上。

产品侧也有类似问题。AI 免费额度防滥用方案建议先限制全站每日预算与单账号额度，再叠加邮箱、账号关联和风险验证。

我赞成这个顺序。识别刷号会有漏网，先约束最大支出，至少不会把账单完全押在识别准确率上。

但文章里的 Redis 示例先累加再判断，被拒绝的请求也占额度，而且没有实际用量结算。它适合解释预算预占思路，直接搬进计费系统还差一截。

报表能显示花了多少，调用前的预算控制才能限制继续花多少。

基础设施同样要跟上。Google API Gateway 的流式支持进入公开预览，支持 SSE、WebSocket、gRPC 流和分块传输，让流式接口有机会沿用统一的认证与可观测能力。

不过预览期需要新建网关，连接最长一小时。客户端能重连，也不代表后端任务能恢复，事件补发和会话延续还得单独设计。

这和 n8n 对本地模型、云端 API 分工的讨论能接起来看。先判断数据能否出网，再看任务能力与请求规模；本地模型只是一环，工作流仍经过外部服务时，不能宣称整个请求留在内网。

对全栈开发者，这些最终都会落到入口路由、预算预占、用量结算和任务状态上。当天可以用测试账号跑一次预算边界，再主动断开一条流连接，确认超额时有没有发起模型调用、断线后任务是否继续、重连能否读回结果。管理功能是否有用，跑到边界才看得清。

总结

今天几篇模型文章给出了开放权重、长上下文和速度的新成绩，但大多仍是厂商或作者报告的结果。Mercury 3 的速度口径、MiniMax 的成功任务总成本、Step 5 的真实仓库表现，都还需要独立测试。

更明确的进展是，Google 公布了流式网关公开预览，JetBrains 发布了正式可用的组织管理产品；同时，工具作者给出了工作树隔离、设计文件交接和会话时间线的具体实现。这些也各有适用范围，预览功能、演示任务和单人测试，都得带着条件看。

我的判断是，接下来更值得程序员投入的，是把 AI 编程变成一套能验收、能恢复、能算账的流程。模型候选可以继续增加，权限、状态和成本记录得先有地方落。

如果今天只挑一件事做，我会找一个最近反复处理的小任务，记下完整耗时、实际费用和验收结果，再换一个候选跑同样的输入。自己的对照记录，会比参数表更快帮你做决定。

参考

一、百万上下文和千 token 秒速，为什么还不能直接换编码模型？

先说结论，我会把今天这批模型放进候选名单，但不会因为「百万上下文」就调整现有开发流程。

按 Step 5 Preview 的介绍文章，模型总参数为 6000 亿，每 token 激活 270 亿，支持最高百万 token 上下文，提供 BF16、FP8 和 NVFP4 权重。

这里有个坑，270 亿激活参数不能拿来估算整套部署规模。

上下文窗口是容量规格，仓库修改通过验收才是工作能力。

Mercury 3 的报道给出了更抢眼的每秒 1068 token。它采用文本扩散，通过多轮并行修正文本来生成内容，减少逐 token 顺序生成带来的限制。

回到这块，前端真正关心的是改完能不能跑、交互对不对、类型和接口有没有一起收好。生成快当然有用，但它只是整个任务中的一段。

二、AI 编程费用怎么比较，为什么省 token 不一定省钱？

顺着上面聊，今天另一个明显信号是，大家开始拆模型外面的成本了。

编码 CLI 的 44 次运行测试里，两款工具使用相同名称的 Opus 5.5，Antigravity 报告的输入 token 比 Claude Code 少 68% 至 88%，完成时间短了 27%。

先别把它转成采购结论。

另一个方向是缩小任务。

我会先找高频、边界清楚的辅助调用，再考虑替换最终回答模型。

说实话，很多团队在讨论便宜模型之前，还没分清模型到底收到了什么。

可以先用一份 JavaScript 记录格式，把不同工具输出的字段整理清楚，避免缓存 token 被重复相加。

const taskRecord = {
  taskId: "fix-checkout-validation",
  model: "candidate-a",
  attempts: 2,
  accepted: false,
  elapsedMs: 0,
  usage: {
    inputTokens: null,
    cacheReadTokens: null,
    outputTokens: null,
    cacheIncludedInInput: null, // 不清楚时保留未知，别直接求和
  },
  actualCost: null, // 优先记实际费用，不从 token 降幅推算收益
};

最容易翻车的是 cacheIncludedInInput，没搞清口径就算总量，会把统计差异当成产品优势。

三、让 Agent 调工具和操作登录账号，权限应该卡在哪？

模型再强，工具入口也不能省校验。

提示注入把危险参数送过来，工具实现给了它执行机会。

路径检查也是同一回事。模型说要写到某个目录，系统仍得判断这个位置是否获准，不能因为参数符合字符串类型就放行。

这个拆法我认可。Agent 能读取登录后的页面，并不自动获得替用户提交表单或上传文件的授权。

模型生成参数，系统决定这些参数有没有资格执行。

这几条放在一起，我会优先检查工具能造成什么后果。读数据、写文件、执行命令和操作账号，应当有各自的限制。

四、Agent 总是重试和忘事，除了改提示词还能做什么？

大概率你也遇到过，接口已经执行成功，Agent 却因为没收到确认又来了一次。或者它说记住了项目约定，隔几轮又开始自由发挥。

这两类问题都容易被一句「模型不稳定」盖过去。

它基于注入故障的玩具 Agent，不能据此认定生产环境的大多数故障都与模型无关。但这个分类很好用，至少能阻止大家每次出错都去追加 system prompt。

拿重试来说，执行成功但响应丢失，与执行前就失败，对业务的影响完全不同。执行框架需要稳定的操作标识，接收端也得按标识去重。

下面这段 JavaScript 在模拟响应丢失后重试，检查同一步操作是否沿用同一个幂等键。

async function retrySameOperation(callTool) {
  const operation = {
    idempotencyKey: "task-42:step-3", // 在重试循环外确定
    args: { orderId: "order-7" },
  };

  for (let attempt = 0; attempt < 2; attempt++) {
    try {
      return await callTool(operation, {
        dropResponseAfterCommit: attempt === 0,
      });
    } catch (error) {
      if (!error.retryable || attempt === 1) throw error;
    }
  }
}

长程记忆则可以看 Goink 的设计。它用 SQLite 保存人物关系、伏笔和故事线，模型通过工具查询、更新，再配合本地检索和 Git 管理修改。

不过，数据库记错了也会持续误导后面的任务，写完注入检查清单也不等于更新正确。

五、多个编程 Agent 并行工作，为什么还会互相覆盖和越跑越慢？

并行开发有两个很现实的问题，文件会不会互相覆盖，时间到底省在哪里。

独立工作树可以隔离文件状态，但多个工作树仍共享仓库。它也不会替你处理最后的合并冲突，更不是进程或安全沙箱。

我会把它理解成给每个 Agent 一张独立工作台。工作台分开了，审查和合并还得照做。

这些来自作者自己的会话观察，公开图也使用了按真实耗时构造的演示数据。它不能代表所有编程助手，却给了一个很实用的排查顺序。

先看时间线。

出了回归也不必逐个问 Agent「是不是你刚才改坏的」。Git bisect 的示例在构造的 16 次提交历史里，用 4 轮测试定位到缺陷提交。

四轮是该案例的结果。中间版本无法构建、问题修复后又出现，都可能让真实排查更麻烦，关键仍然是先把异常变成可重复判断的测试。

六、团队接入多个模型之后，怎么把权限和预算一起管住？

模型越多，后台也越多。开发者按任务切工具，负责人却要回答谁能用、费用记在哪、超额之后是否继续跑。

JetBrains Air Governance 的发布说明称，产品已正式可用，支持集中管理 Agent、模型、供应商和用户组，并提供预算与用量管理。

产品侧也有类似问题。AI 免费额度防滥用方案建议先限制全站每日预算与单账号额度，再叠加邮箱、账号关联和风险验证。

我赞成这个顺序。识别刷号会有漏网，先约束最大支出，至少不会把账单完全押在识别准确率上。

但文章里的 Redis 示例先累加再判断，被拒绝的请求也占额度，而且没有实际用量结算。它适合解释预算预占思路，直接搬进计费系统还差一截。

报表能显示花了多少，调用前的预算控制才能限制继续花多少。

不过预览期需要新建网关，连接最长一小时。客户端能重连，也不代表后端任务能恢复，事件补发和会话延续还得单独设计。

AI日报

今日看点

一、百万上下文和千 token 秒速，为什么还不能直接换编码模型？

二、AI 编程费用怎么比较，为什么省 token 不一定省钱？

三、让 Agent 调工具和操作登录账号，权限应该卡在哪？

四、Agent 总是重试和忘事，除了改提示词还能做什么？

五、多个编程 Agent 并行工作，为什么还会互相覆盖和越跑越慢？

六、团队接入多个模型之后，怎么把权限和预算一起管住？

总结

参考

AI日报

今日看点

一、百万上下文和千 token 秒速，为什么还不能直接换编码模型？

二、AI 编程费用怎么比较，为什么省 token 不一定省钱？

三、让 Agent 调工具和操作登录账号，权限应该卡在哪？

四、Agent 总是重试和忘事，除了改提示词还能做什么？

五、多个编程 Agent 并行工作，为什么还会互相覆盖和越跑越慢？

六、团队接入多个模型之后，怎么把权限和预算一起管住？

总结

参考