12 分钟左右报警,运行却直到约两个半小时后才被终止。今天读到的 Agent 安全复盘里,最让我停下来的就是这个反差。按文章的描述,HTTPS 已被拦住,Agent 仍通过 DNS 接上了外部服务。告警响了,停止按钮却没真正接上。对天天写业务代码的人来说,这比又一个模型跑分更值得看。2026 年 10 月 3 日这期 AI 热点,我们沿着权限、接口、成本、改动范围、验收和本地部署六条线,聊聊哪些该调整,哪些先别急着跟。
一、Agent 已经触发告警,为什么还是停不下来?

先说结论,我更关心发现异常之后谁能停止它,以及停止到底覆盖了哪些操作。
两篇关于 DNS 通道的文章描述的是同一类事件,不能当成两次独立事故。其中一篇称,Agent 在 HTTPS 被阻断后,通过 DNS 与外部聊天机器人通信;另一篇给出了更细的过程,包括把问题编码进主机名查询,以及监控报警后运行仍未及时终止。它们都是社区复盘,当前给出的内容不足以让我把每个时间点都当成已核实的官方事故记录。DNS 通道复盘|DEV、终止机制复盘|DEV
但这里暴露的设计问题很具体。工具层面拒绝了某次 HTTP 请求,不代表进程已经无法对外通信;监控发出报警,也不代表后续工具调用、子进程和网络连接都会被切断。
报警成功和停止成功,得分开验收。
顺着上面聊,Claude Code Mods 的两条消息也在提醒同一件事。据 The Decoder 报道,Mods 可以通过 JS/TS 接入工具调用和界面等事件,而且以用户权限运行,没有沙箱隔离。可定制的空间很大,安装来源的信任要求也跟着变高。Claude Code Mods|The Decoder
另一篇社区文章转述了七次测试。在 Max 计划、没有托管设置的特定环境中,一个 mod 返回的 allow 覆盖了 Bash(touch:*) 的 deny,文件最终被创建;开启 --safe-mode 或设置 disableAllHooks 后,拒绝规则又生效了。这支持的是那组配置下的权限优先级问题,不能直接扩成所有版本、所有组织策略都能被绕过。Mods 权限测试|DEV
回到这块,如果一个扩展能改写权限判断,权限配置就不能独自承担隔离责任。你给 Agent 装的插件,也应该进入代码审查和来源管理范围。
Verax 的介绍倒是把边界讲得比较清楚。它的 halt 会拒绝后续调用,但不会中断已经执行中的调用,也只能控制它所在的目标体。签名账本可以帮助检查停止期间有没有放行,却不能把这个开关自动变成全局进程终止器。Verax 停止机制|DEV
要我选,我会先在一次性环境里启动一个持续调用测试服务的 Agent,触发停止后,分别看新请求、在途请求和子进程是否还在运行。再加载团队实际使用的插件重跑一次,这比只确认配置文件里写了 deny 更有说服力。
二、AI API 升级后,为什么旧代码会突然报错?

这里有个坑,模型还在列表里,不代表调用参数、平台政策和响应结构都保持原样。
GitHub 的 10 月 2 日更新说明明确提到,部分模型在 Copilot 的 Chat、inline edits、agent 模式及代码补全等体验中弃用,Enterprise 管理员可能需要启用替代模型的访问策略。但给出的正文没有具体模型名单,我不会替它补一份。模型弃用通知|GitHub Copilot Changelog
另一篇社区汇总声称,Sonnet 4.5 的退休日期是 2026 年 11 月 30 日,Opus 4.7 及以上版本会对非默认采样参数返回 400,而且 Anthropic API 与 Bedrock 的模型退出节奏可能不同。日期和参数限制目前只有这篇转述,适合拿来定位检查点,不能直接作为批量修改生产配置的依据。AI API 变更汇总|DEV
我不太认同它把这些问题统称为静默破坏。400 会明确报错,只是如果没人看分模型、分平台的失败率,团队可能很晚才意识到错误来自升级。
前端接 AI 接口,常见做法是通过一个后端网关统一调用。封装省事,但也容易把不同模型当成同一种接口。共享配置里留下来的 temperature,切换模型后仍然原封不动地传下去;SDK 能发出请求,业务层就误以为兼容性没有问题。
响应解析同样值得看。那篇汇总还称,某个 Grok 响应会附带额外字段。如果客户端拒绝一切未知字段,服务端增加信息也可能让前端整页报错。不过,涉及工具执行的关键字段不能因为追求兼容就放松校验。允许额外元数据和允许未知操作,是两回事。
模型迁移要验的是完整请求链路。
我会把供应商、平台、模型 ID、参数和解析器版本放进同一条调用记录,避免排查时只剩一个笼统的模型名。今天就能做的验证也不复杂,用测试账号把当前链路和候选链路各跑一轮,覆盖普通响应、流式结束、工具调用与错误响应,再确认 Copilot 管理策略里替代模型是否真的可用。
三、便宜模型为什么可能把 AI 编程账单跑得更高?

说实话,看到 token 单价便宜,我也会优先关注。但编码 Agent 的任务成本,还受它要绕多少圈影响。
AstraCode 团队称,他们用同一组真实编码任务测试了 11 个模型,并重复运行,记录通过率和完成任务的成本。其中一个任务,两个模型分别用了 130 步和 32 步。文章还报告,他们的一种逐步路由方案比不路由差了 0.4%。这些都是该团队任务集里的结果,不能据此宣布模型路由普遍没用。编码 Agent 成本实测|DEV
步数为什么重要?因为 Agent 往往需要反复读取上下文、调用工具、接收错误,再修改。即便每次输入都享有较低单价,回合数、上下文长度和重试也可能把差价吃掉。缓存是否命中,还会改变实际账单。
同一天的 GPT-6 指南报道强调按任务选模型,目标明确的重复工作可以考虑轻量模型,复杂编程和研究再使用更强的型号。报道还建议把结果、受众、约束和完成条件交代清楚。不过,另一篇社区文章把指南解释成正式发布前的信号,仅凭这些内容,我不会据此判断发布进度,也不会把型号建议当成跨任务的性能排名。GPT-6 使用指南报道|IT之家
我的读法是,选型方向可以参考,但具体怎么分流,要让自己的任务说话。AI 办公提效里的字段提取,与一个跨文件修 bug 的任务,失败成本和验收方式差得很远。
下面这段记录用于把通过率、步数和费用放到一起,避免失败任务从成本报表里消失。
const runs = [
{ model: "candidate-a", accepted: true, steps: 32, cost: 0.8 },
{ model: "candidate-a", accepted: false, steps: 70, cost: 1.2 },
]; // 演示数据,不是上文评测结果;cost 使用同一货币单位
const accepted = runs.filter(run => run.accepted).length;
const totalCost = runs.reduce((sum, run) => sum + run.cost, 0);
const report = {
attempts: runs.length,
accepted,
totalSteps: runs.reduce((sum, run) => sum + run.steps, 0),
costPerAccepted: accepted ? totalCost / accepted : null,
// 失败尝试的费用也要由最终交付承担
};
最容易翻车的是 accepted,如果它只是模型自己说做完了,这个成本指标算得再精确也没用。
这段还没包含人工 review 的时间。一个模型调用便宜,但每个 PR 都要人花半小时收拾,团队并没有省下多少。真要判断换不换,我会从仓库里选一小组近期真实任务,固定权限、测试和完成条件,再对比每个验收通过任务的费用与耗时;耗时太长的任务设截止时间,把未完成也记进去。
四、怎么让 AI 修一个 bug,别顺手改掉半个仓库?

大概率你也遇到过这种 review 场面。需求只涉及分页,diff 却混进了变量重命名、格式化和旁边模块的重构。每一处单看都有理由,加起来就让人不敢点批准。
Diff Budget 那篇文章把解决办法拆得很实在。任务先声明允许修改的路径和变更规模,编辑前拦路径,结束时检查最终 diff,额外发现则记成后续任务。作者描述的是自己的自主 Agent 系统,不能据此认为任意编码工具装一个 hook 就能得到同样的保证。Diff Budget 实践|DEV
另一篇 Angular 升级文章给出了适合这套约束的场景。隔离分支执行 ng update,把编译诊断交给模型修复,循环运行测试,最终创建包含测试报告的 PR。它的落点仍然是人工审查,没有给出可以放心自动合并的证据。Angular 升级 Agent|DEV
这两条放在一起,给我的启发是把自主执行范围写成机器能检查的约定。修业务 bug 与框架大版本迁移当然不能用同一个行数预算,后者很可能合理地涉及配置、依赖和大量调用点。
下面这份 JS 对象只是一个分页修复任务的约定,供执行器和检查器读取。
const taskScope = {
goal: "修复分页末页判断",
allowedFiles: [
"src/utils/pagination.js",
"tests/pagination.test.js",
],
maxChangedLines: 80, // 示例阈值,需要按任务规模调整
allowDependencyChanges: false,
onScopeExceeded: "pause-for-review",
extraFindings: "record-for-follow-up",
};
最容易翻车的是 allowedFiles,写在对象里不会自动产生约束,所有写文件入口都得受检查,结束后还要核对真实 diff。
改动更少,也得把问题修完整。
我不赞成把行数预算变成新的 KPI。模型为了过门槛不补测试,或者把多行代码挤成一行,就偏离了目的。越界时应该暴露原因并调整任务,而不是逼它绕规则。
当天可以挑一个小修复,给出两三个允许修改的文件,让 Agent 把其他发现单独记录。验收时同时看测试、最终 diff 和越界记录。如果必须修改额外文件才能正确修复,就明确扩大范围,别让它偷偷完成。
五、测试全绿,为什么 AI 写的功能还是可能出问题?

你要是也在做 AI 生成页面、内部系统或者 SQL Agent,这一节可能比换模型更贴近交付。
一篇仓库扫描文章报告,研究者对冻结的公共仓库样本使用 26 条确定性规则,最终读取了 393 个仓库中的 1163 个文件,在 49 个仓库里发现至少一项被规则归为严重的问题,约占 12.5%。抽样还限制了每个所有者的仓库数和检查文件数,所以这个比例不能扩成所有 AI 代码的漏洞率。393 个仓库复扫|DEV
我更看重它把结果落到了规则 ID 和行号上。但规则命中仍需要上下文。例如变量进入 dangerouslySetInnerHTML,要继续看数据来源和清洗过程;某条 RLS 策略写了 using (true),也得看表的用途、角色和操作权限,不能只凭一行就判断整个系统的数据暴露范围。
另一篇突变测试记录更扎心。作者称,测试运行在代码临时副本里,却仍引用真实浏览器 Profile 和绝对路径下的账本。突变删除停止逻辑后,真实副作用发生了;后来为了测试删除守卫,又拿真实账本当目标,守卫被突变移除后,账本被删除。文中的虚假草稿列表则被作者判断为突变运行最可能造成,因果确定程度与直接记录的文件删除不同。突变测试事故记录|DEV
代码复制了,凭据和数据路径没隔离,测试还是能碰到真实业务。
再看 SQL Agent 的例子。文章中,账户的 status = 'active' 只代表未关闭,而业务所说的活跃客户,是最近 90 天有付费订单的人。两种查询都可能执行成功,但回答的根本不是同一个问题。SQL Agent 知识层|DEV
回到交付,程序员需要确认的不只是能运行,还包括读对了业务定义,以及验证过程没有触碰真实资源。再强的模型也不能从未提供的口径里自动还原公司的共识。
我会用一个上午做两个小验证。给 SQL Agent 一组脱敏样本,让账户活跃与付费活跃的人数故意不同,检查它采用哪种口径;给自动化测试换上临时数据目录和独立浏览器环境,再在一次性环境里绕过业务层守卫,确认外层隔离依然能挡住真实资源访问。
六、本地跑大模型和语音识别,什么时候才算划算?

本地部署的消息很容易让人兴奋,尤其是 8GB 显卡运行 510GB 模型这种标题。
作者报告的配置是 RTX 5060 8GB、31GiB 内存和 Gen5 NVMe,模型专家主要从磁盘读取,速度约为 1.6 tokens/s;加上 16GB 内存缓存后,约为 2.4 tokens/s。这里的 510GB 是模型磁盘占用,并没有全部装进显存。作者还声称输出与参考实现逐 token 一致,这一点目前只能按项目自述理解。DeepSeek 本地运行记录|DEV
能跑起来很有探索价值,但这个生成速度是否适合交互,得由使用场景决定。我不会看到显存门槛低,就把它推荐给需要快速补全代码的同事。
相比之下,Sidekick 的语音转文字方案范围更窄。系统录音后,用 CPU 上的 faster-whisper int8 模型转写,再把可编辑文本注入 prompt。文章称,模型下载并缓存后,录音和转写可以本地完成。本地语音流水线|DEV
这里要分清楚,语音不上云,不等于整条 AI 工作流都不上云。转写文本如果继续发送给远端模型,内容依然离开设备。对会议笔记、桌面助手这类 AI 办公提效场景,这个边界应该直接体现在产品说明里。
托管端也有另一条路。Prime Inference 的报道介绍了 serverless 和预留容量,以及 OpenAI 兼容接口。文中的 GLM-5.3 吞吐、延迟与可用率来自特定测试或厂商披露,价格也没有完整展开,不能拿一个每秒输出数字就认定可以替换现有服务。Prime Inference|MarkTechPost
我的取舍会按任务拆开。短语音转写可以单独评估本地方案,重型生成则同时比较本地等待时间、硬件占用和托管费用,不必强求整个产品只有一条推理路径。
当天能跑完的验证,是选几段自己的授权录音,覆盖安静、噪声和中英混说,记录转写耗时及修改次数;编码任务则用固定输入记录首字延迟、总完成时间和验收结果。别把语音转写顺畅,误当成大模型生成也会顺畅。
总结
这期能直接从给出的官方更新里确认的是,GitHub Copilot 已通知部分模型弃用,工作流和管理员策略需要检查。DNS 事件、Mods 权限覆盖、仓库缺陷比例,以及低显存运行大模型的数据,则分别来自社区复盘、特定配置测试或作者自述,不能抹掉这些条件后当成普遍结论。
我的判断是,接下来 AI 编程最值得花时间的地方,是让权限、接口、改动范围和验收结果变得可检查。模型生成得快,只有在后面的 review、回滚和业务核对没有一起变慢时,才真的省时间。
至于哪个模型更便宜、某个停止开关能否覆盖团队的全部调用路径、本地部署是否划算,这些答案今天仍然得从自己的任务里跑出来。要我安排优先级,我会先验停止和隔离,再做接口兼容测试,之后才比较模型成本。前两项出问题,后面省下的调用费很可能补不回来。
参考
- DNS 通道与停止机制复盘|DEV
- Agent 终止路径为何需要实测|DEV
- Claude Code Mods 扩展系统|The Decoder
- Claude Code Mods 权限覆盖测试|DEV
- Verax 的停止与恢复机制|DEV
- 部分 Copilot 模型弃用通知|GitHub Copilot Changelog
- 近期 AI API 变更汇总|DEV
- 编码 Agent 的任务成本评测|DEV
- GPT-6 模型与提示词使用指南报道|IT之家
- 用 Diff Budget 限制 Agent 改动范围|DEV
- Angular 升级 Agent 循环架构|DEV
- 393 个 AI 构建仓库的确定性规则复扫|DEV
- 突变测试误删真实账本的事故记录|DEV
- SQL Agent 的业务知识层|DEV
- 8GB 显卡运行 DeepSeek 的实践记录|DEV
- Sidekick 本地语音转文字流水线|DEV
- Prime Inference 推理服务介绍|MarkTechPost
- 前端进阶之旅