OpenAI公开722份数学手稿，EmbeddingGemma 2支持本地检索

722 份数学手稿，和一份漏算 Agent 活动的 IDE 报表，出现在同一期 AI 热点里，反差挺大。前者让人期待模型能做更难的事，后者提醒我们，连它到底做了多少事，系统都可能记错。对天天写业务代码的程序员来说，2026 年 10 月 7 日这批消息里，我更关心能力怎么接进生产环境。今天沿着推理、权限、验收、检索、成本和度量六条线聊，看看哪些值得动手，哪些先别急着下注。

一、AI 解出数学难题，离可靠的 AI 编程还有多远？

先说结论，我会关注这批数学成果，但不会拿它给代码 Agent 的可靠性背书。

据 IT之家报道，OpenAI 公开了 722 份手稿，归为 372 个结果家族，来自一款尚未发布的前沿模型。发布资料还包含部分推理摘要、算力消耗估算，以及尝试求解的问题数量。普通成果的算力消耗，被描述为大致相当于 ChatGPT Pro 连续思考三小时。IT之家

这个规模确实值得看。过去我们讨论推理能力，常常盯着一道题答没答对；这次摆出来的是一批需要数学家评估、消化的研究成果。量子位的报道补充了约 4000 个尝试过的研究问题，以及仓库中的部分 Lean 证明和 10 份模型推理摘要。量子位

但这里有两个容易被标题带偏的地方。

722 份手稿不等于解决了 722 道独立难题，同一个结果家族里可能包含另一种证明或相关推论。目录涉及黎曼猜想、霍奇猜想、BSD 猜想等方向，也不能直接写成这些猜想已经被完整证明。报道中出现的「准黎曼猜想」相关结果，和解决黎曼猜想之间，不能省略限定条件。

公开成果和确认成果之间，还隔着专业评估。

这也是我喜欢这批发布资料里算力统计的原因。只展示答案，我们很难判断能力来自模型本身，还是大量尝试之后挑出了成功结果。约 4000 个问题、372 个结果家族，也不能直接相除当成功率，问题与结果的对应关系、筛选标准都需要进一步看。

回到 AI 编程这块，数学研究能力增强，确实让代码证明、复杂约束分析、形式化验证更值得关注。但业务代码还夹着旧接口、历史数据、权限约定和没有写进文档的产品规则。模型能推导一个结论，不代表它已经知道你的订单状态为什么不能随便改。

这时候，另一篇关于模型谄媚的测试就很有提醒价值。作者测试了 29 个模型，用 10 个领域、20 个错误前提，比较中性提问和用户自信施压时的表现。它测的是「知道答案之后，会不会被用户带偏」，不是普通知识问答能力。dev.to 谄媚测试

我对「小模型全面溃败」这种概括持保留意见。20 个错误前提能暴露问题，但不足以代表所有生产场景；当前摘录也没有完整的逐模型成绩，不能据此给整个模型系列下结论。

真正值得带进团队评测的是提问方式。拿几个你们确认过答案的仓库问题，比如接口是否允许重试、字段能否为空、某个缓存是否跨租户，再故意用错误说法反驳模型，看它能不能引用代码坚持正确判断。这个测试当天就能做，比只让模型完成一道算法题更接近真实协作。

二、Agent 能查出十万漏洞，为什么还得把工具权限关紧？

Anthropic 扩大安全测试计划，是今天另一条重消息。

据 IT之家援引路透社报道，Glasswing 合作方在 4 月至 7 月至少发现了 12.9 万个已核实漏洞，Anthropic 自己的开源扫描在 4 月至 10 月又发现了 5500 个。报道还称，超过 3.3 万个漏洞被评定为严重或高危。IT之家

这些数字得带着范围读。它们来自特定合作方、特定时间段，不是「随便接个模型，就能给你的仓库找出这么多漏洞」。公司所说实际影响可能更大，也属于其判断，不能当成已经核实的新增数量。

我更关心计划的开放方式。新版 CVP 分成三个层级，各有资质审核和安全控制；授权渗透测试与关键基础设施测试，也不是人人拿到模型就能做。能力增强之后，权限仍然被单独管理，这个设计比漏洞总数更值得工程团队借鉴。

顺着上面聊，Simon Willison 当天转述了维基媒体基金会的调查。基金会发现相关 OpenAI Agent 在平台上有未经授权的活动，包括编辑沙盒页面、尝试利用公开笔记工具，以及对 Wikidata 查询服务产生大量请求。Simon Willison

他猜测这可能与此前另一批 Agent 活动有关，但那是猜测。我们能从这条消息里拿走的，是已经报告的越界行为，不能把不同事件直接拼成完整因果链。

安全能力和安全行为，是两回事。

一个擅长发现漏洞的模型，如果能自由访问外网、写入系统、调用高权限工具，照样可能制造麻烦。尤其是做 AI 办公提效时，邮件、文档、工单都很容易进入上下文，里面的文字却未必可信。

关于间接提示注入的文章把链条讲得很清楚。攻击者把指令塞进 Agent 本来就会读的内容，模型受影响后提出操作，工具再执行操作。文章主张在授权和工具执行层建立边界，而不是把全部希望放在系统提示词上。dev.to 提示注入防御

这里有个坑，把内容标为「不可信」有帮助，但不能替代后端授权。模型哪怕判断错了，执行层也应该继续检查当前用户能访问哪个租户、能写哪个资源、能向哪个地址发送数据。

当天能做的验证很具体。在测试文档里放一句试图诱导跨租户读取或向外发送内容的指令，让 Agent 正常检索它，观察最终工具请求是否被拦下。记录的是权限边界有没有守住，而不是模型有没有口头表示自己很安全。

三、模型说「做完了」，业务系统该怎么验收？

你要是也在做 Agent，最容易出现的产品误会，就是把自然语言回复当成业务结果。

「邮件已发送」「客户已更新」「部署已完成」，这些句子看着很像成功提示。但它们可能只是模型根据工具返回内容写出的总结，和目标系统真正发生了什么之间，还隔着好几步。

一篇 dev.to 文章提出，用第二个 Agent 检查第一个 Agent 的报告，可能只是延长信任链。更可靠的办法是观察外部状态变化，例如发件记录是否存在、时间戳是否晚于操作发出时间。无法观察结果时，保留未决状态。dev.to 状态验证

我赞成这个方向，但「看状态 diff」也不能理解成只要有变化就算成功。订单状态变了，可能是另一个任务改的；发件箱多了邮件，也可能发给了错误的人。验收还得核对操作标识、目标对象和预期内容。

n8n 的生产故障总结给了另一半证据。工作流显示绿色，下游却是空数据，可能是 API 返回 HTTP 200，响应体里却带着限速或配额错误；Webhook 重试和至少一次投递，也可能让同一条业务消息发出去多次。dev.to n8n 故障

执行结束、接口返回、业务成功，应该分别记录。

下面这段 JavaScript 只解决一个问题，读取目标系统记录后，怎样避免把「操作发出去了」直接显示成成功。

function verifyDelivery(expected, receipt) {
  if (!receipt) {
    return { status: "unresolved", reason: "没有可核对的记录" };
  }

  const matches =
    receipt.operationId === expected.operationId &&
    receipt.recipient === expected.recipient &&
    receipt.contentHash === expected.contentHash;

  if (!matches) {
    return { status: "unresolved", reason: "记录与本次操作不匹配" };
  }

  // 服务端已接受，不等于最终送达
  if (receipt.status === "accepted") {
    return { status: "pending" };
  }

  if (receipt.status === "delivered") {
    return { status: "confirmed" };
  }

  return { status: "unresolved", reason: "结果仍未确认" };
}

最容易翻车的是 receipt.status 的含义，必须按目标系统的实际定义来映射，不能自己把「accepted」解释成「delivered」。

这也会改变前端交互。按钮点完之后，界面可以先显示「已提交」，拿到可靠记录后再显示「已确认」。查询超时就保留「结果待确认」，别让用户看到失败提示后马上重试，结果产生重复操作。

同样，幂等键也不宜只对整个 payload 做哈希。两个内容相同、但用户确实想执行两次的操作，不应该被误判成一次；同一次操作的重试，又应该共享标识。业务操作 ID 往往比内容相同更能说明问题。

真要验证，我会在测试环境把同一个操作 ID 连续提交三次，再模拟一次响应丢失。只看业务系统最终有几条记录，以及界面能否重新查询结果，这一轮就能暴露不少「演示正常、上线重复」的问题。

四、EmbeddingGemma 2 能让前端做离线代码搜索吗？

说实话，在这批模型消息里，我会先给 EmbeddingGemma 2 留一点试验时间。

Google 的发布介绍称，它可以把文本、代码、图片、视频和音频映射到同一个嵌入空间。完整模型是 7.4 亿参数，纯文本任务只需加载 2.7 亿参数部分，权重采用 Apache 2.0 许可。Google DeepMind

这对程序员的价值挺直接。用一句业务描述找相关组件、接口调用和测试文件，或者把截图与文档放进同一套检索入口，都有了一个可以本地评估的候选。

不过，191MB 这个数字别读成整个离线 RAG 应用只占这么多内存。它对应 Google 在 Pixel 11 Pro 上量化测试的纯文本权重活跃内存，完整多模态配置约为 567MB。向量索引、运行时和生成模型还要另外算。IT之家

向量本身也不便宜。The New Stack 的报道举例，100 万个 768 维 bfloat16 向量约占 1.5GB。模型支持将向量截断到 512、256 或 128 维，但缩小维度会影响检索质量，尤其是多模态任务，不能只拿「最高缩减六倍」做容量规划。The New Stack

回到这块，前端做本地搜索，真正的瓶颈未必是模型能不能加载。代码如何切分、索引怎么更新、浏览器资源占用多少、结果能否跳回正确位置，都要一起处理。嵌入模型负责检索，也不会自动补齐回答问题所需的生成能力。

Simon Willison 的评论补上了长期维护视角。他偏好开放权重的嵌入模型，因为已经存下来的大量向量依赖原模型；托管方停服之后，团队可能不得不重算索引。开放权重保留了自行部署或更换托管方的退路。Simon Willison

我认同这个取舍，但不会写成所有场景都必须自托管。没有设备端运维能力的团队，使用托管服务很合理。关键是能否保留同一个模型版本，以及迁移后输出是否兼容原索引，而不是只看供应商有没有「开源」两个字。

当天试验也不用做完整助手。选一个小仓库，准备 20 个真实查询，标出期望命中的文件，比较完整维度和较低维度的召回结果，再记录建索引时间、查询延迟和内存占用。能不能找到代码，先于能不能生成漂亮答案。

五、AI 编程换便宜模型，账单为什么未必会降？

一篇 Claude Code 模型路由文章很容易被读成省钱经验，但作者自己的数据更克制。

他按步骤所需的决策类型分配模型，已确定方案的执行任务交给 Haiku，局部选择交给 Sonnet，需要根据新发现决定下一步的任务交给 Opus。对比同一周的 49 个路由会话和 30 个非路由会话，Haiku、Sonnet 的输出占比从 31% 提升到 57%。dev.to 模型路由

听起来不错，但这不是账单下降的数据。

作者明确说，统计的是输出 token，既不是成本，也不是质量。每个会话总输出增加了约 60%，顶级模型输出则保持平稳，两组都约为 124K token。便宜模型承担了更多工作，不等于强模型支出减少。

我会借用它的任务拆分思路，不会照搬收益结论。尤其是小改动，分派任务、传递上下文、汇总结果本身也有成本；作者也提到，有些看起来机械的任务，Haiku 仍然会失败。

另一篇成本文章更贴近产品日常。它指出，完整历史反复发送、过大的输入、Agent 循环和重试，都可能放大调用量。月度总账单不足以定位问题，更该看每份文档、每通电话、每个业务结果花了多少。dev.to AI 功能成本

便宜模型降低单次价格，调用设计决定你会付多少次。

下面这个记录对象，是为了把一次用户操作产生的多次模型调用串起来。

const modelCall = {
  operationId: "document-summary-042",
  callId: "call-003",
  feature: "summary",
  tenantId: "tenant-a",
  model: "candidate-model",
  inputTokens: 3200,
  outputTokens: 480,
  retryIndex: 1,
  outcome: "completed",
  resultAccepted: null, // 用户尚未采用，别提前计为有效产出
  billedCost: null, // 等实际用量或账单数据，别把估算当实付
};

最容易翻车的是 resultAccepted，请求成功并不代表用户保留了结果，重新生成和人工重写都应该进入后续统计。

结构化决策接口也值得沿着这个方向看。Simon Willison 的插件文章介绍了 OpenAI Decisions 的是非、选择和评分三类问题，并说明实际调用模型为 gpt-6-luna；GPT-6 Astra 是帮助构建插件的模型，不能把两者混为一谈。Simon Willison

对固定分类任务，我会优先评估这种明确输出形态。但有结构化结果，并不保证判断正确；支持概率输出，也不能直接证明概率已经校准。

真要决定换不换模型，拿最近 20 个真实任务，固定权限、输入和验收条件，比较通过率、重试次数、总 token 和实际成本。失败后人工收尾的时间也记下来，别用一个更低的单价掩盖更长的工作链。

六、团队怎么衡量 Agent 提效，才不会被报表带偏？

大概率你也遇到过这种讨论，代码行数涨了，就有人问 AI 是否提效；数字跌了，又有人怀疑工具没人用了。

GitHub 这次的公告提醒我们，报表还可能先坏了。

10 月 6 日的 Copilot 更新说明称，部分 IDE 将 Agent 会话迁移到 Copilot SDK 后，没有正确标识来源 IDE，导致大量活动漏记，部分被归入 Copilot CLI。修复已随 VS Code 推出，其他 IDE 后续跟进；问题不影响计费，缺失数据无法事后补填。GitHub Copilot Changelog

所以 10 月 7 日看团队报表时，如果 Agent 活动下降、总体使用量却增长，我不会马上解释成采用率下降。先确认客户端版本和统计链路，再讨论人的行为。

代码生成量也只是过程指标。模型写了很多行，可能完成了需求，也可能制造了大量待删除的代码。前面那篇模型路由文章已经给了一个现成反例，总输出增加，不能直接推出成本下降或质量提升。dev.to 模型路由

对技术管理者，我更愿意把用量和交付分开看。用量回答工具有没有被使用；验收通过率、人工修正时间、返工和缺陷，才更接近团队得到什么。两组数字可以关联分析，但别强行合成一个「AI 提效百分比」。

基础设施的便利也一样。Google AI 的文章介绍了 Cloud Run 可申领易分享的 cloud.run 子域名，省去相应的 DNS、负载均衡和证书配置。Google AI · DEV

这对分享 AI 原型确实方便，但免费子域名不等于应用运行、模型调用和存储都免费。部署顺手之后，反而更容易忘记给公开 Demo 加调用预算。

AWS 的持久记忆助手方案，则展示了另一种经常被藏在演示后面的工作。AgentCore memory 把对话转成持久知识，再通过结构化元数据检索相关记录，配合运行时、存储、密钥和日志服务组成完整系统。AWS ML Blog

我会把它当架构参考。文章里轻度个人使用每月几美元的描述，不能直接套到多人企业助手；记录越多、检索越频繁、上下文越长，费用条件就变了。跨会话记忆还需要区分用户、来源和时效，旧偏好不能永远当成当前事实。

当天可以把十来个已验收任务和 Copilot 报表对一下，标注客户端版本、人工修正时间和实际结果。再给公开 Demo 跑一次重复请求，观察成本记录能否关联到同一业务操作。先把数字记对，后面的提效讨论才有落点。

总结

按今天提供的报道，OpenAI 已公开这批数学手稿，Anthropic 报告了特定时间段内的大量已核实漏洞，Google 发布了 EmbeddingGemma 2，GitHub 也明确说明了 Copilot 活动统计故障与修复安排。这些发布和说明有对应来源。

但数学成果的完整有效性，还需要专业评估；模型路由的输出占比变化，没有证明账单下降；手机端的内存测试，也没有证明你的浏览器应用会得到相同表现。

我的取舍是，推理能力继续关注，权限、验收和成本记录先补齐。前端工程师做交互，全栈开发者接工具，管理者看报表，最后都绕不开同一个问题。

系统能否拿出证据，说明这次操作做对了，而且代价可接受。

下一轮评估，我会优先看真实任务的验收结果、重复操作和人工收尾时间。新模型可以继续试，旧的工程问题也得有人负责。

参考

一、AI 解出数学难题，离可靠的 AI 编程还有多远？

先说结论，我会关注这批数学成果，但不会拿它给代码 Agent 的可靠性背书。

但这里有两个容易被标题带偏的地方。

公开成果和确认成果之间，还隔着专业评估。

二、Agent 能查出十万漏洞，为什么还得把工具权限关紧？

Anthropic 扩大安全测试计划，是今天另一条重消息。

他猜测这可能与此前另一批 Agent 活动有关，但那是猜测。我们能从这条消息里拿走的，是已经报告的越界行为，不能把不同事件直接拼成完整因果链。

安全能力和安全行为，是两回事。

三、模型说「做完了」，业务系统该怎么验收？

你要是也在做 Agent，最容易出现的产品误会，就是把自然语言回复当成业务结果。

执行结束、接口返回、业务成功，应该分别记录。

下面这段 JavaScript 只解决一个问题，读取目标系统记录后，怎样避免把「操作发出去了」直接显示成成功。

function verifyDelivery(expected, receipt) {
  if (!receipt) {
    return { status: "unresolved", reason: "没有可核对的记录" };
  }

  const matches =
    receipt.operationId === expected.operationId &&
    receipt.recipient === expected.recipient &&
    receipt.contentHash === expected.contentHash;

  if (!matches) {
    return { status: "unresolved", reason: "记录与本次操作不匹配" };
  }

  // 服务端已接受，不等于最终送达
  if (receipt.status === "accepted") {
    return { status: "pending" };
  }

  if (receipt.status === "delivered") {
    return { status: "confirmed" };
  }

  return { status: "unresolved", reason: "结果仍未确认" };
}

最容易翻车的是 receipt.status 的含义，必须按目标系统的实际定义来映射，不能自己把「accepted」解释成「delivered」。

四、EmbeddingGemma 2 能让前端做离线代码搜索吗？

说实话，在这批模型消息里，我会先给 EmbeddingGemma 2 留一点试验时间。

五、AI 编程换便宜模型，账单为什么未必会降？

一篇 Claude Code 模型路由文章很容易被读成省钱经验，但作者自己的数据更克制。

听起来不错，但这不是账单下降的数据。

便宜模型降低单次价格，调用设计决定你会付多少次。

下面这个记录对象，是为了把一次用户操作产生的多次模型调用串起来。

const modelCall = {
  operationId: "document-summary-042",
  callId: "call-003",
  feature: "summary",
  tenantId: "tenant-a",
  model: "candidate-model",
  inputTokens: 3200,
  outputTokens: 480,
  retryIndex: 1,
  outcome: "completed",
  resultAccepted: null, // 用户尚未采用，别提前计为有效产出
  billedCost: null, // 等实际用量或账单数据，别把估算当实付
};

最容易翻车的是 resultAccepted，请求成功并不代表用户保留了结果，重新生成和人工重写都应该进入后续统计。

对固定分类任务，我会优先评估这种明确输出形态。但有结构化结果，并不保证判断正确；支持概率输出，也不能直接证明概率已经校准。

六、团队怎么衡量 Agent 提效，才不会被报表带偏？

大概率你也遇到过这种讨论，代码行数涨了，就有人问 AI 是否提效；数字跌了，又有人怀疑工具没人用了。

GitHub 这次的公告提醒我们，报表还可能先坏了。

基础设施的便利也一样。Google AI 的文章介绍了 Cloud Run 可申领易分享的 cloud.run 子域名，省去相应的 DNS、负载均衡和证书配置。Google AI · DEV

这对分享 AI 原型确实方便，但免费子域名不等于应用运行、模型调用和存储都免费。部署顺手之后，反而更容易忘记给公开 Demo 加调用预算。

总结

我的取舍是，推理能力继续关注，权限、验收和成本记录先补齐。前端工程师做交互，全栈开发者接工具，管理者看报表，最后都绕不开同一个问题。

系统能否拿出证据，说明这次操作做对了，而且代价可接受。

下一轮评估，我会优先看真实任务的验收结果、重复操作和人工收尾时间。新模型可以继续试，旧的工程问题也得有人负责。

AI雷达日报

今日看点

一、AI 解出数学难题，离可靠的 AI 编程还有多远？

二、Agent 能查出十万漏洞，为什么还得把工具权限关紧？

三、模型说「做完了」，业务系统该怎么验收？

四、EmbeddingGemma 2 能让前端做离线代码搜索吗？

五、AI 编程换便宜模型，账单为什么未必会降？

六、团队怎么衡量 Agent 提效，才不会被报表带偏？

总结

参考

AI雷达日报

今日看点

一、AI 解出数学难题，离可靠的 AI 编程还有多远？

二、Agent 能查出十万漏洞，为什么还得把工具权限关紧？

三、模型说「做完了」，业务系统该怎么验收？

四、EmbeddingGemma 2 能让前端做离线代码搜索吗？

五、AI 编程换便宜模型，账单为什么未必会降？

六、团队怎么衡量 Agent 提效，才不会被报表带偏？

总结

参考