把这一周排在一起看

10 月下旬这一周,智能体赛道出现了几件彼此不相关、方向却一致的事。

10 月 22 日,Replit 上线监控智能体,把修复与重新发布拆成两个独立开关,后者挂着实验标签。10 月 25 日,一篇论文给出多智能体拆解的闭式成本模型。10 月 26 日,另一篇论文量出编码智能体的整单完成率只有 26.4%。10 月 28 日,思科开源 Project Quarry,想把检测智能体有害行为的规则写成公共语言。10 月 29 日,OpenAI 公开了四层失准监测体系,并坦白监测本身可能教模型学会掩饰。同一周,评测框架开始跑进托管沙箱,协议层的审批门继续往下落。

这几件事看似散在检测、评测、成本、产品四个方向,合起来指向同一个结构:围绕智能体运行时,正在长出一层独立于框架的中间件。框架管的是「智能体做什么」,这一层管的是「允许它做什么、出了事怎么查、能不能退回来」。

10 月下旬的一周里发生了什么按公开日期排列,均为厂商或官方渠道口径10 月 22 日Replit 上线监控智能体,把修复与重新发布拆成两个开关10 月 25 日协调税论文给出多智能体拆解的闭式成本模型10 月 28 日思科开源 Project Quarry,把检测规则写成公共语言10 月 29 日OpenAI 公开四层失准监测,并交代它可能教模型掩饰同一周评测框架进入托管沙箱;协议层的审批门继续落地同一周的反面证据:编码任务整单完成率只有 26.4%意味着大量改动在到达生产之前就已经是半成品
图|把四件事排在一起看,共同点是都在「发现」这一侧加码。

三层里,前两层各挪了一格

把这层中间件拆成三层,进展就很清楚了。

看得见这一层,本周的进展最实。检测规则有了公共语言的候选——思科的 Quarry 明着对标 Snort、YARA 与 Sigma,主张一处写规则、各处都能读。监测体系有了公开的模板——OpenAI 把四层漏斗、覆盖范围与两组计时都摊了出来。评测也开始有了托管去处,沙箱厂商承接第三方评测框架,让被测的智能体与其余环境隔开。

拦得住这一层继续加厚。协议层长出了审批门,服务器可以在执行中途暂停、等客户端补信息或等人类拍板,这道门从提示词里搬进了协议。网关继续做身份与访问范围,工具允许清单与沙箱隔离已经成了默认配置。

回得去这一层,几乎没有对等的东西。

同一周里,前两层各往前挪了一格第三层几乎没有对等的产品化动作看得见思科开源 Quarry 检测语言OpenAI 公开四层监测评测托管进入沙箱记录标准在起草拦得住协议层长出审批门网关做身份与范围工具允许清单沙箱隔离执行回得去回滚未见产品化金丝雀比例未公开错误预算闸门缺位重复修复无自动叫停Quarry 自己写明:命中返回证据,告警或拦截由接入产品决定Replit 的自动重新发布挂实验标签,也没配自动回滚发现能力越强的副作用:命中之后要有人做决定,而决定要有退路没有退路的拦截,最终会变成「干脆不拦」
图|三层里两层的进展是可查的,第三层的进展要靠厂商自己交代。

不是做不到,是没人认领

这个缺口的性质要说清楚:它不是技术难题,是责任难题。

回滚要有人定义「回到哪里」——回到上一个版本,还是回到上一个已知健康的状态,还是回到一次业务上正确的状态?金丝雀要有人定义「多少算安全」——1% 的请求还是 1% 的用户,观察多久算通过?错误预算要有人定义「烧掉多少就停」——这些全是组织决策,写不进任何一份开源文档。

证据就在本周的材料里。思科在介绍 Quarry 时反复强调:它求值和返回发现,告警、拦截、脱敏还是隔离,由接入它的产品决定。这是设计上的诚实,也把最难的一问留给了采购方——买的是发现能力,不是兜底能力。Replit 那一边同样:自动重新发布挂着实验标签,配套的金丝雀比例、自动叫停与自动回滚都没有公开。

还有一个更硬的佐证,来自本周那份编码基准。逐条要求平均通过 69.9%,整单完成只有 26.4%——意味着大量改动在到达生产之前就已经是半成品。把半成品自动发出去的风险不在于它错了,而在于它看起来没错:界面改好了,逻辑也动了,只有一条边界条件没接上,而这类问题往往要等到有人投诉才现形。

三盆冷水

这个判断要配三条保留。其一,本周这几件事里有三件是厂商自述,重放与效果数字都没有独立审计,OpenAI 自己那两个计时里,30 多小时那个出自事后模拟,15 分钟那个才是真实运行的观测。

其二,「回得去这层是空的」基于公开材料的缺失。缺失不等于不存在——厂商内部可能已有成熟做法,只是没有对外交代。这个判断因此只能在公开可见的层面成立,不能推成「行业都没有」。

其三,三层这个切法是观察者为了看清结构画的,厂商未必这么组织自己的产品。真实的产品边界往往横跨其中两层,比如网关既做拦截也做记录,硬套会失真。

三层缺口会不会被填上,看这三处都是可公开验证的信号,不依赖厂商自述检测规则有没有基准是否出现公开评测集误报率与延迟能不能比规则在不同产品间能不能原样复用回滚有没有变成默认值自动发布是否配回滚金丝雀比例是否公开修复失败能否自动停错误预算是否被引用记录标准何时定稿持久身份是否入规批准记录是否可导出权限变更是否留痕跨产品能否互认判断口径:不看出席了哪些发布会,看这三项有没有可核对的公开材料若三项长期停在「已在路线图上」,说明缺口是结构性的对使用方的实操建议:先开记录与告警,把发布权留在自己手里把「发现之后怎么办」写成自己的流程,再谈要不要自动发布
图|三个观察哨都指向同一件事:能力能不能被第三方核对。

三个观察哨

接下来值得盯的,是三件可公开验证的事。

其一,检测规则有没有基准。思科开源了语言与引擎,但没有公开准确率、误报率与延迟。什么时候出现一份公开的评测集,让不同产品的规则能被放在同一把尺子上量,这一层才算真正立住。

其二,回滚有没有变成默认值。看四件事:自动发布是否配回滚、金丝雀比例是否公开、反复修复能否自动叫停、错误预算有没有被写进产品语义。这四项里出现两项,方向就变了。

其三,记录标准何时定稿。持久智能体身份、可导出的批准记录、权限变更留痕,这三样在标准草案里都还在动。它们决定了审计能不能跨产品互认——本站此前记录过主流框架连这些记录都不写的缺口,那一层的进展会直接决定这一层能不能落地。

对正在部署的使用方,建议相对朴素:先开记录与告警,把发布权留在自己手里;把「发现之后怎么办」写成自己的流程,再谈要不要让智能体自动发布。检测能力会越来越便宜,判断题永远贵。