GLM-5.3安全评估与GPT-6.1 Sol价格解析

410 次尝试，50 个可用的漏洞利用程序。这是今天读到的 GLM-5.3 安全评估里，我最在意的一组数。同一批素材里，GPT-6.1 Sol 的标准输入、输出价格被报为旗舰的五分之一。一边是攻击能力变便宜，一边是干活能力变便宜，程序员要算的账开始变复杂了。这份 2026 年 9 月 30 日的 AI 热点日报，沿着安全、成本、后台任务、验收、接口和长上下文六条线，聊聊哪些值得试，哪些先别急着搬进项目。

一、开源模型能写浏览器漏洞利用，Agent 权限该怎么收？

先说结论，我会把今天的安全新闻放在模型降价前面。

据 The Decoder 转述 Anthropic 的分析，GLM-5.3 在针对 Chrome V8 已知漏洞的 ExploitBench 测试中，410 次尝试生成了 50 个可用利用程序，Claude Mythos Preview 为 56 个。在另一项基于 OSS-Fuzz 项目的内部二进制漏洞利用测试中，两者实现完全控制的任务占比分别为 4% 和 6%。

这两组数字得分开读。它们说明特定测试里的漏洞利用能力接近，不能推导成两个模型整体能力相同，更不能理解为随便找个网站就有对应的攻击成功率。

报道还提到轻量版约 20 美元构建可靠 Chrome 攻击链的结果。但当前摘录没有展开这笔费用怎么算、用了多少人工帮助、对应哪个浏览器版本。我会把它当成攻击成本下降的信号，不会拿来估算公司被攻破要花多少钱。评估出自竞争对手，这层关系也得记着。

不过，工程问题已经很具体了。一个能读仓库、开浏览器、装依赖、调用接口的 Agent，接触到的东西远超聊天窗口。即使它原本只负责改一个组件，也可能拿到构建环境、测试账号和服务凭证。

模型愿不愿意遵守限制，不能代替运行环境真的拦住越权操作。

同一天的 NVIDIA OpenShell 项目说明给出了另一侧的做法。它通过沙箱、内核控制和网络策略限制文件访问、系统调用及出站连接，并把真实凭证加到发往批准端点的请求里，而不是直接交给 Agent。项目还描述了对策略变更进行形式化验证的机制。

这里有个坑。验证策略允许了什么，不等于证明整个 Agent 系统绝对安全。项目仍处于 0.1.x 阶段，部署支持和现有环境是否合拍，也要单独看。它值得借鉴的地方，是把权限执行从模型的回答里拿出来。

回到这块，前端团队不一定当天就换运行时。拿一个隔离测试环境，让 Agent 分别尝试读取仓库外的诱饵文件、访问未批准域名、调用超出任务范围的接口，看看究竟是系统拒绝，还是模型口头表示「我不会这么做」。用假凭证就够了，这一轮能直接暴露权限到底卡在哪层。

二、GPT-6.1 Sol 便宜到五分之一，AI 编程现在就该换模型吗？

我对降价当然有好感，但「便宜五倍」得先问清楚比的是什么。

TechCrunch 报道的口径是，GPT-6.1 Sol 标准输入和输出 token 价格为 GPT-6 Astra 的五分之一；接近旗舰的能力描述，主要落在 Agent 编程、电脑操作和专业工作上。这是 OpenAI 的发布主张，不是所有任务都有五倍成本优势。

AWS ML Blog 则给了另一个口径。它转述 OpenAI 的数据，在 DeepSWE v1.1 上，Sol 的表现可与 Astra 相当，单任务成本约为后者的五分之一。这里谈的是特定评测里的任务成本，和 API 单价不是同一个分母。

实际账单还会被重试、上下文长度、工具等待和人工返工改变。模型每次调用便宜，但如果总在错误文件里打转，你省下的钱可能还不够同事重新读一遍 diff。

我更愿意比较每个验收通过的任务花了多少钱。

GitHub Copilot 更新日志提到，早期测试里，GPT-6.1 Sol 能以更少 token 和步骤完成多步编码任务。它面向指定订阅开放并逐步推送，列出的入口包括编程智能体和移动应用，不能直接扩写成每个人的 IDE 补全都已经升级。

Kimi K3 也适合放进候选，但我对那篇价格文章持保留意见。dev.to 的介绍同时出现了相对 GPT-5.6 Sol 约三分之一和便宜约两倍的说法，还包含网关推广。前端编码第一、百万上下文表现良好，都缺少足够完整的测试条件，不能凭这篇文章就批准全量迁移。

更值得拆出来研究的是缓存。文章描述了重复输入命中缓存后费用下降的情况，但 70% 到 90% 的命中率属于它讨论的工作负载，不是接入后自动到账的折扣。

还有 Ultrafast。The Decoder 的 DevDay 报道提到更高生成速度，以及标准费率六倍的 API 价格。生成快八倍，也不等于整个任务快八倍。安装依赖、等待测试和调用外部服务的时间，未必跟着缩短。

说实话，真要选模型，我会拿仓库最近 20 个能复现的任务，覆盖组件修改、跨文件修复和失败定位，固定权限、推理设置与验收条件，让两个候选跑一轮。记下通过数、账单、总耗时和人工接手次数；样本虽小，至少比照着榜单直接换主力靠谱。

三、后台 Agent 一直运行，任务状态和权限该放在哪？

顺着上面聊，模型便宜之后，产品很自然会让它多干一会儿。Dots 把这件事做成了明确的产品形态。

据 MarkTechPost 报道，Dots 基于 GPT-6 Astra，每个 Agent 有独立云端计算机和浏览器，用户登出后还能继续工作，并通过插件连接应用。它正向符合条件的订阅和市场逐步开放，属于托管产品。

我最在意的细节是，报道把无人交互时的主动后台研究限制为连接应用的只读访问。能持续运行，并不自动获得持续修改账号和内容的权限。

这个区分很实用。读资料、整理候选方案和真的发消息、改记录，风险完全不同。要做 AI 办公提效，允许它夜里整理明天的材料很合理；允许它凭一段模糊目标到处替你做决定，就得另算。

与 Dots 同时出现的，是 Codex 可复用云环境和 Agents API 更新。前者让团队共享环境、批准设置和权限，后者加入 Computer Use。我的读法是，任务上下文、机器环境和工具权限正在一起变成产品的一部分。

但环境能复用，任务状态也得能恢复。

聊天历史里写着「下一步准备提交」，并不能告诉调度器提交到底有没有发生。尤其遇到超时，接口可能已经执行成功，只是响应没回来。盲目重试就可能重复创建 PR、重复写记录。

你要是也在做后台 Agent，我会先明确下面这份任务记录，而不是先写更长的系统提示词。它只是结构示例，实际需要由调度器持久化。

const task = {
  id: "fix-cart-total",
  revision: 3,
  status: "running",
  checkpoint: {
    step: "tests_passed",
    artifactId: "test-run-184"
  },
  nextAction: {
    type: "open_pull_request",
    idempotencyKey: "fix-cart-total:open-pr:v1",
    approval: "required" // 写操作单独授权，不能继承只读许可
  },
  limits: { maxAttempts: 3, maxCostUsd: 5 }
};

最容易翻车的是 idempotencyKey 那一行，只存一个字符串没有任何防重效果，执行端必须实际检查和复用结果。

这也是后台任务和一次性对话在工程上的差别。它需要回答「上次做到哪」「哪些动作已经生效」「剩余预算多少」，不能每次恢复都靠模型猜。

当天就能做一次中断恢复实验。在外部操作成功、状态回写之前主动终止任务，再恢复运行，观察它是否重复操作；同时把预算耗尽、等待审批和用户取消分别走一遍，看看任务能不能真正停下来。

四、Agent 说「修好了」，怎么确认代码和线上问题都好了？

Cloudflare 今天这条，我会放进工程团队的讨论群。

根据 Cloudflare Blog，Workers 的 Issues 已开放公测，可以把重复异常、5xx 和错误日志聚合为一个问题，再将堆栈、日志、链路与 Worker 版本发送给配置好的编码 Agent，触发分类、调查乃至创建 PR 的工作流。

它解决的是一个很具体的麻烦。你让 Agent 修 bug，它得先知道出错的是哪个版本、哪些请求、是否同一个原因。上下文没整理好，后面再强的模型也要先花时间翻日志。

但把故障送给 Agent，只完成了前半程。

一篇关于「描述即执行」的实践文章记录了模型声称文件已保存、实际却没有调用写入工具的情况。作者建议在完成声明前增加证据检查，要求有工具结果和产物。这是个人系统里的观察，不能据此推算所有 Agent 的发生率，但失败方式很容易理解。

我赞成检查产物，不太赞成只检查回答里有没有 URL、commit hash 或 HTTP 状态码。那些东西也能被生成出来。就算工具真的返回 200，也只能说明一次请求成功，不能证明业务目标已经达成。

「完成」应该是执行系统核验后的状态。

下面这段演示最小的验收入口，解决模型自己把任务标成完成的问题。

async function canMarkDone(task, store, verifyArtifact) {
  const receipt = await store.getReceipt(task.id); // 读取执行器记录
  if (!receipt || receipt.status !== "succeeded") return false;
  if (receipt.revision !== task.revision) return false;
  if (!receipt.artifactId) return false;

  const verdict = await verifyArtifact({
    artifactId: receipt.artifactId,
    acceptance: task.acceptance
  });
  return verdict.passed === true; // 验证产物满足当前任务要求
}

最容易翻车的是 verifyArtifact，如果它只是让同一个模型重新读自己的总结，然后回答「通过」，这个检查仍然绕回了原点。

测试这边也有对应争论。另一篇 dev.to 文章指出，自动修复 locator 可能选中错误元素，让测试维持绿色，并提出让 Agent 直接执行自然语言用例。

这个提醒有道理，但我不会因此删掉测试脚本。自然语言执行一样可能找错按钮、漏看状态，也要交证据。页面布局巡检、低频探索任务可以试；金额计算、权限隔离这类验收条件清楚的逻辑，我会保留可重复执行的断言。

把两条新闻接起来看，真正完整的路径是错误上下文进入任务，代码产生变更，独立检查验收，再观察修复是否对应原问题。PR 创建成功，只能停在其中一站。

当天可以故意安排三个失败场景，工具超时、文件未生成、测试返回失败，看看 Agent 是否仍报告完成。再挑一个测试环境里的已知问题，把日志交给它处理，要求报告关联具体版本和验证结果，而不是只给一段流畅总结。

五、分类和检索都交给大模型，Agent 会不会花了冤枉钱？

不少 Agent 流程里，真正需要长篇生成的地方没有想象中多。选工具、分工单、判定是否继续，往往都是有限选项。

MarkTechPost 对 Liquid AI d1 的介绍提到，这个决策模型接受上下文和类型化问题，返回固定结果集合上的概率，usage.output_tokens 为 0。它提供是非判断、选项选择和有序评分三种原语，通过托管 API 使用。

别把零输出 token 看成零计算或零费用。它描述的是不逐 token 生成回答，不代表请求没有其他成本。返回概率也不等于对你的业务天然校准，示例里 0.999 的结果不能当成上线可靠性保证。

OpenAI 的 Decisions API 报道同样指向快速单项决策和分类。这两条放在一起，我更愿意尝试把「选择下一步」和「执行复杂工作」分开计费、分开评估。

不必每一步都请最贵的模型写一段话。

检索也是同样的思路。Perplexity Photon 的报道描述了自研 Rust 检索引擎，涉及自适应倒排表、批量异步读取、缓存设计和索引构建与服务分离。里面的收益不能只归因于换了编程语言。

还有两个数字别混读。标题给出的检索引擎 p99 从 800ms 降到 65ms，与 Fast Search API 的 p50 160ms、p95 230ms，属于不同测量范围。不能拿引擎内部延迟直接承诺用户接口响应时间。

对前端来说，这会影响加载状态、流式输出前的等待以及取消操作的体验。对全栈团队来说，模型之外的接口延迟，可能已经占了工作流的大头。

我的取舍是先拆耗时。拿一批已有分类样本，对比通用模型与决策接口的准确率、费用和低置信度分布；再固定搜索查询，分别记录检索等待、模型首字和完整任务耗时。当天跑完这两组，就知道下一笔优化预算该花在哪。

六、百万上下文模型来了，整个仓库和文档都能直接塞吗？

大概率你也遇到过这种诱惑。上下文一变长，就想把文件树、全部源码、历史讨论一次塞进去，省掉挑选资料的步骤。

今天的长上下文消息，得把「模型上限」和「现在能调用多少」分开看。

IT之家关于 Ling-3.1-flash 的报道写到，模型约 560B 总参数、25B 激活参数，上下文上限为 1M。但两周免费体验期间，服务长度是 256K；1M 和开源属于之后的计划。现在就按百万上下文设计接入，会直接撞上可用范围的差别。

前面提到的 Kimi K3 文章则声称百万上下文可用，并描述了超过 50 万 token 的仓库测试。作者的体验可以作为线索，不过一次长输入表现良好，不能证明模型每次都能找全跨文件约束。

长文档翻译提供了更具体的观察角度。B站 Index-Translate 的报道介绍了基于 Qwen3.5 的模型家族，文本模型覆盖 150 种语言，并支持术语、格式和保留内容等指令；其中 NativeLong 展示了约 32K token 文档中的上下文处理。

这条对做多语言产品的前端，比单看参数规模更有用。翻译界面文案时，产品名能不能始终一致，插值变量会不会被改，富文本结构是否保留，往往比一句译文是否顺口更影响交付。

不过，权重开放不等于所有用途都没有许可限制；支持 150 种语言，也不代表每一种语言质量一致。报道里的社区表达案例很好玩，但我会把业务术语、占位符和长文档前后指代放到更前面。

能装进去，只是开始。

代码仓库也是这样。你真正要的是模型找到相关实现、理解依赖、保留行为约束，而不是它成功接收了几十万 token。长输入可能减少检索遗漏，也可能增加费用和排查难度，得看任务。

要我选，我会用同一个跨文件问题，对比整仓输入与相关文件输入，要求两边指出依据并通过相同测试。做翻译的团队则拿一份含产品名、插值变量和重复术语的真实文档，检查前后译法与结构是否一致；这一轮比继续追问「支持多少万」更接近交付。

总结

今天能从给出的发布记录中确认的，是 Copilot 正在推送 GPT-6.1 Sol，Cloudflare Issues 开放公测，Index-Translate 文本权重已开放，以及 Ling-3.1-flash 免费体验阶段提供 256K 服务长度。它们都有具体入口或适用范围，不能把计划中的能力算进现有能力。

至于 Sol 接近旗舰、GLM-5.3 的漏洞利用表现，以及 Photon 的延迟改善，分别来自厂商评测或报道转述，要连着任务条件和测量范围一起读。Kimi 的成本优势、自然语言测试能否替代脚本、后台 Agent 能省多少人力，这些还没有在我们的业务里得到验证。

我的判断是，AI 编程接下来的差距，会越来越多地出现在模型周围。权限能否收住，任务能否恢复，完成是否有证据，账单能否对应验收结果，这些都会决定团队到底省了多少事。

如果今天只安排一次试验，我会拿一个真实但可回滚的任务，同时记录成本、失败和验收证据。跑完再决定扩大使用，比一次接入五个新名字更有用。

参考

一、开源模型能写浏览器漏洞利用，Agent 权限该怎么收？

先说结论，我会把今天的安全新闻放在模型降价前面。

模型愿不愿意遵守限制，不能代替运行环境真的拦住越权操作。

二、GPT-6.1 Sol 便宜到五分之一，AI 编程现在就该换模型吗？

我对降价当然有好感，但「便宜五倍」得先问清楚比的是什么。

我更愿意比较每个验收通过的任务花了多少钱。

三、后台 Agent 一直运行，任务状态和权限该放在哪？

顺着上面聊，模型便宜之后，产品很自然会让它多干一会儿。Dots 把这件事做成了明确的产品形态。

我最在意的细节是，报道把无人交互时的主动后台研究限制为连接应用的只读访问。能持续运行，并不自动获得持续修改账号和内容的权限。

但环境能复用，任务状态也得能恢复。

你要是也在做后台 Agent，我会先明确下面这份任务记录，而不是先写更长的系统提示词。它只是结构示例，实际需要由调度器持久化。

const task = {
  id: "fix-cart-total",
  revision: 3,
  status: "running",
  checkpoint: {
    step: "tests_passed",
    artifactId: "test-run-184"
  },
  nextAction: {
    type: "open_pull_request",
    idempotencyKey: "fix-cart-total:open-pr:v1",
    approval: "required" // 写操作单独授权，不能继承只读许可
  },
  limits: { maxAttempts: 3, maxCostUsd: 5 }
};

最容易翻车的是 idempotencyKey 那一行，只存一个字符串没有任何防重效果，执行端必须实际检查和复用结果。

这也是后台任务和一次性对话在工程上的差别。它需要回答「上次做到哪」「哪些动作已经生效」「剩余预算多少」，不能每次恢复都靠模型猜。

四、Agent 说「修好了」，怎么确认代码和线上问题都好了？

Cloudflare 今天这条，我会放进工程团队的讨论群。

但把故障送给 Agent，只完成了前半程。

「完成」应该是执行系统核验后的状态。

下面这段演示最小的验收入口，解决模型自己把任务标成完成的问题。

async function canMarkDone(task, store, verifyArtifact) {
  const receipt = await store.getReceipt(task.id); // 读取执行器记录
  if (!receipt || receipt.status !== "succeeded") return false;
  if (receipt.revision !== task.revision) return false;
  if (!receipt.artifactId) return false;

  const verdict = await verifyArtifact({
    artifactId: receipt.artifactId,
    acceptance: task.acceptance
  });
  return verdict.passed === true; // 验证产物满足当前任务要求
}

最容易翻车的是 verifyArtifact，如果它只是让同一个模型重新读自己的总结，然后回答「通过」，这个检查仍然绕回了原点。

测试这边也有对应争论。另一篇 dev.to 文章指出，自动修复 locator 可能选中错误元素，让测试维持绿色，并提出让 Agent 直接执行自然语言用例。

五、分类和检索都交给大模型，Agent 会不会花了冤枉钱？

不少 Agent 流程里，真正需要长篇生成的地方没有想象中多。选工具、分工单、判定是否继续，往往都是有限选项。

OpenAI 的 Decisions API 报道同样指向快速单项决策和分类。这两条放在一起，我更愿意尝试把「选择下一步」和「执行复杂工作」分开计费、分开评估。

不必每一步都请最贵的模型写一段话。

对前端来说，这会影响加载状态、流式输出前的等待以及取消操作的体验。对全栈团队来说，模型之外的接口延迟，可能已经占了工作流的大头。

六、百万上下文模型来了，整个仓库和文档都能直接塞吗？

大概率你也遇到过这种诱惑。上下文一变长，就想把文件树、全部源码、历史讨论一次塞进去，省掉挑选资料的步骤。

今天的长上下文消息，得把「模型上限」和「现在能调用多少」分开看。

能装进去，只是开始。

总结

如果今天只安排一次试验，我会拿一个真实但可回滚的任务，同时记录成本、失败和验收证据。跑完再决定扩大使用，比一次接入五个新名字更有用。

AI雷达日报

今日看点

一、开源模型能写浏览器漏洞利用，Agent 权限该怎么收？

二、GPT-6.1 Sol 便宜到五分之一，AI 编程现在就该换模型吗？

三、后台 Agent 一直运行，任务状态和权限该放在哪？

四、Agent 说「修好了」，怎么确认代码和线上问题都好了？

五、分类和检索都交给大模型，Agent 会不会花了冤枉钱？

六、百万上下文模型来了，整个仓库和文档都能直接塞吗？

总结

参考

AI雷达日报

今日看点

一、开源模型能写浏览器漏洞利用，Agent 权限该怎么收？

二、GPT-6.1 Sol 便宜到五分之一，AI 编程现在就该换模型吗？

三、后台 Agent 一直运行，任务状态和权限该放在哪？

四、Agent 说「修好了」，怎么确认代码和线上问题都好了？

五、分类和检索都交给大模型，Agent 会不会花了冤枉钱？

六、百万上下文模型来了，整个仓库和文档都能直接塞吗？

总结

参考