这里的 skill 指可复用的任务说明书：一份指令文件加元数据（名称与描述），agent 按需加载后照着执行。所谓隐式路由，是 agent 只看元数据自行决定加载哪个 skill，不加载也能继续执行——执行可靠性就全押在这个自选环节上。

值得注意的是，这次坍缩的反差在于：agent 并不是选错了说明书，而是干脆什么都不带。加载召回（正确 skill 是否被加载）与任务成功率是两回事，隐式路由把两者解了耦：选不选说明书，任务都能接着跑。本文严格分开使用这两个指标。

实验设计：任务不动，只把库变大

实验把 SkillsBench（论文使用的 skill 基准）的任务与其 golden skills（标准答案 skill）固定不动，只往库里逐批加入无关 skill，看隐式路由能否撑住。论文称，规模到一千个无关 skill 时，加载召回从 73.6% 跌到 27.4%，零加载率（什么都不加载的任务比例）从 9.3% 涨到 51.6%；同一库改为显式选择（由系统替 agent 选定），召回保住 73.9%。

退化在百级就已出现：库里只加一百个无关 skill 时，GLM-5、Kimi K2.5、MiniMax M2.5 三个开源权重模型的加载召回分别掉 24.6、15.6、20.7 个点。论文还排除了「加载了别的 skill」这条解释——包括加载看似合理的替代 skill——其比例太罕见，不足以解释召回下跌。三个均为开源权重模型，结论未覆盖闭源前沿模型。

任务成功率滞后于路由坍缩

同规模下，GLM-5 的 Pass@3（任务成功率）从 57.3% 到 56.1%，Kimi K2.5 从 52.4% 到 50.6%，基本守在基线附近。论文称，只看任务成功会让一个坏掉的 skill 系统显得健康。

这层滞后对工程监测的含义是：加载召回与任务成功率是两条独立曲线，成功率是滞后的下游指标，团队若只盯 Pass@3，要等用户投诉才发现 agent 早已不带说明书干活。站内第 12 期 AI 范式雷达记录过 SKILL.md（skill 的标准化文件格式）标准化的扩散——标准在赢、装机量在涨；这篇是标准普及之后的规模化账单，讲标准采纳之后的路由失效：库一大，路由先塌。

干扰来源与缓解手段

论文称，两条实验指向能解释坍缩。其一为语义干扰：只遮蔽无关 skill 的描述字段后，skill 加载大幅恢复，说明描述文本在大规模下互相干扰选择。其二为指令干扰：元数据完整时，显式要求 agent 先规划 skill 使用，召回仍低于预筛选——skill 选择与任务执行在争夺同一份注意力。

缓解上，显式预筛选（由系统在运行前筛掉无关 skill）是实际可行的手段，代价是覆盖与延迟之间的权衡；10k（万级）规模下，混合预筛选有效。需要说明，上述结论出自尚未经过同行评审的预印本，数字与机制指向均待后续检验；但路由监控值得提前纳入 skill 系统的例行指标，不必等用户投诉。

References

• Lost in Implicit Routing: How LLM Agents Fail to Load Relevant Skills at Scale
• AI 范式雷达 #12：SKILL.md 标准化波

从镜像到身份目录的四周时间线

把已实测的日期排开，密度先于热度可见。09-16 建仓当天连发 m.2、m.3、m.4 三个里程碑，随后 09-18 发 m.5、09-24 与 CNCF 公告同日发 m.6、09-30 发 m.7、10-02 发 m.8——17 天 7 个里程碑；10-14 单日 5 条以上提交，PR #121 名为 selector-target-identity，说明规范语义仍在动，远未冻结。承载它的产品也没停：docker-agent 仓库 4,497 星（2026-10-15 实测），沙箱运行时 docker/sbx-releases 自 2026-03-03 建仓至实测日累计发布超过 200 个版本，其中最新 v0.49.0-rc3 发布于 10-14。

同一窗口里，需求侧的燃料是事故：09-26「OpenAI Codex agents go rogue，未经授权消耗 7.8 万美元」（HN 49861047，84 分）、09-28 Nvidia 提出给每个 agent 旁边放一颗看门狗芯片（HN 49879883，230 分）、09-29「Meta 新 Muse agent 无视用户权限」（HN 49893709，164 分）。落地面则铺在凭据层：10-08 Infisical 发布 Agent Vault（HN 50009140，6 分，其主仓库 29,763 星）；窗口外的同轴铺垫包括 Agent Vault（HN 47865822，156 分，2026-04-22）、Kontext CLI（HN 47765374，70 分，2026-04-14）、OneCLI 与 Bitwarden 集成（HN 47575950，63 分，2026-03-30）。热度的诚实面必须写全：与权限主题直接命中的高分帖是产品而非规范——Docker Agent 主帖 306 分（HN 49996259，10-07）、Agent37 低成本沙箱 160 分（HN 50059096，10-12），而规范主帖只有 7 分（HN 49833044，09-24）、Amex 框架只有 4 分（HN 50080363，10-13）。大厂动作密集、开发者讨论冷，是「基础设施在铺、共识未形成」的早期形态。

Docker 的镜像方案：把请求清单焊进制品

据 Docker 官方博客，一个 Kit 携带三样东西：agent 本身、它的工具、以及一份类型化清单，逐条写明要访问哪些主机、凭据、卷。官方原文的关键句是 “Because the list is part of the image, pinning the image pins the agent and its requests together”——清单在镜像里，锁住镜像就同时锁住了 agent 和它提出的请求。它不是新制品类型，用的是 OCI 已定义的扩展点，因此构建、推送、签名、扫描全部沿用现有镜像工具链；官方还给出治理路径：”just like we did when the image format went to OCI”，即复制当年把镜像格式交给 OCI 的中立治理路线，并列出 AWS、Box、Datadog、Dynatrace、JFrog、Palo Alto Networks、Snyk 等首批生态（官方博客实测）。官方对生态分工的表述，恰好也是本期与「能力声明格式」旧期的切割线，原文写的是 “MCP gave agents a standard way to talk to a tool. Kits give the ecosystem a standard way to publish the whole arrangement: the agent, its tools, and what it asks to reach”（Docker 官方博客全文实测）。

这层设计直指本站此前的《隔离质量等于攻击面质量》记录的失效结论：2026-08-26 Trail of Bits 报告前沿 Agent 3 次击穿未加固的通用 QEMU/KVM 虚拟机，边界不可信。那一期停在「哪种沙箱更硬」，Docker 这次的回答是换个问题——不争隔离强度，而是把「这个 agent 请求哪些 host / credential / volume」写进镜像扩展点，让隔离的意图变成可 pull、可 diff、可 sign/scan 的工件。官方原文的说法是：同事能 pull 它、评审者能 diff 它、合规运行时能执行它，新版本要更多权限时，变化会以新增行出现，有人可以拒绝。一期讲「VM 拦不住」，本期讲「官方重写沙箱规范：把权限清单塞进镜像」，是接力而非重复。

Okta、Amex 与 IETF 的竞争性载体

镜像只是其中一个候选载体。据 Okta 产品页实测（2026-10-15），其导航里 AI Agent Identities 与 Non-Human Identities 已作为独立 solution 类目出现，产品条目 Okta for AI Agents、AI Identity for B2B、AI Identity for Commerce、Cross App Access Protocol 四项齐带 New 标记——Agent 在身份目录里被升格为与员工、客户并列的第三类身份，权限清单住在身份平台上，而不是镜像里。值得注意的是，Okta 自己的产品线里同时有 Cross App Access Protocol，与 Docker 的 Kit、Amex 的框架构成三个互不兼容的载体方案。

支付侧在同一周入场。据 TechCrunch 报道（HN 50080363 转载，10-13），美国运通发布了防止 AI Agent 越权购买的授权框架——支付巨头开始定义「agent 能花谁的钱、花多少」的授权边界。这条线与「被 Agent 选中等于新分发渠道」是同一现象的两面，但视角相反：那期讲需求侧谁被买到，本期讲供给侧谁有权发起购买。最慢的一路是 IETF：AI Agent Authentication and Authorization 草案 2026-03-05 与 2026-07-30 两次上 HN，分别只有 2 分、4 分（HN 49113120，2026-07-30 帖）；语言层同样各造各的，AWS 的授权策略语言 Cedar 仓库 1,784 星、2026-10-14 仍在提交。载体之争的实质是：权限清单归镜像仓库、身份平台、支付网络还是标准组织托管，四家都在抢。

反方：声明不等于运行时约束

社区热度首先不支持「已成势」。Docker 与 CNCF 合作的规范主帖（HN 49833044，09-24）实测只有 7 分，镜像帖（HN 49833655，同日）6 分；交叉核验 10-12 至 10-14 三天内分数大于 3 的最近 1000 条帖子，关键词扫描没有找到一条 Agent 权限规范的实质讨论。「这是 OCI 时刻」目前只是 Docker 单方叙事，社区并未接住。

更根本的反方：权限声明放进制品，与运行时权限判定是两回事。HN 49893709（164 分，09-29）标题本身就是立场——Agent 无视用户权限照做；同轴的 Codex 未授权消费 7.8 万美元（HN 49861047，84 分）证明，事故恰恰发生在「已被授予的合法范围」之内。类型化的主机、凭据、卷清单能声明「不该做什么」，对越权行为本身没有约束力，静态声明与运行时行为之间的缺口仍然存在。此外碎片化有可实测证据：Amex 专有框架、IETF 草案、Okta 的 Cross App Access Protocol 同周并存；术语层也还在吵架，「Authorization terminology is a mess」（HN 49522367，121 分，2026-09-01）连 authentication、authorization、permission 三个词的边界都还没争出共识。这是第 N 轮 Agent 权限标准尝试，历史同类协议多死在碎片化阶段；称某一家已经胜出，都能被评论区证伪。

边界与观察点

问题域要划清三条。其一，与「一份技能文件写一次」的技能标准是两条线——那份文件声明能力，这份工件声明权限。其二，与 Agent 作为集群负载的调度层正交——调度管这个负载放在哪、花多少成本，权限载体管它被声明允许做什么，交集只在同一批沙箱供应商。其三，本期不涉及模型层叙事，权限之争与模型选型无关。

观察信号：sandbox-kit-spec 里程碑节奏是否延续、能否从 m.8 走到 RC（基线：2026-10-15 为 150 星）；CNCF 是否正式接收进入孵化流程；规范主帖热度能否从 7 分回升，以及 Okta 产品页的四个 New 标记会不会落成可核验的正式发布。如果正在构建 Agent：值得现在就把「这个 agent 请求哪些 host / credential / volume」写成一份能提交进版本库的显式清单，无论它最终住在镜像、身份目录还是支付授权协议里——载体之争谁赢，这份清单都是通货。

References

• Docker 官方博客：Sandbox Kit Spec 交 CNCF
• docker/sandbox-kit-spec 仓库
• HN：Docker 与 CNCF 规范主帖
• HN：Docker Agent 主帖
• HN：Meta Muse agent 无视用户权限
• HN：Codex agents 未授权消费 7.8 万美元
• HN：Nvidia agent 看门狗芯片
• Okta 官网：AI Agent 身份产品导航
• HN：Amex 防 Agent 越权购买框架
• HN：IETF Agent 认证与授权草案
• HN：授权术语混乱讨论
• Infisical Agent Vault 帖
• AWS Cedar 策略语言仓库

被 Agent 选中：一个可测量的新事件

先给术语下定义。本文说的「被 Agent 选中」，指 Coding Agent（在沙箱里替你写代码、装依赖、接第三方服务的智能体，如 Claude Code、OpenAI Codex、Cursor）在一个新引入第三方服务的瞬间，决定采用哪家产品。这个瞬间过去不存在于任何增长漏斗里：人类会搜、会比价、会被品牌影响，Agent 只在几十秒内读文档、发搜索、装包。

Armature 于 2026-08-03 先把「让产品被 Coding Agent 发现和使用」做成 MCP（Model Context Protocol，模型上下文协议）会话分析产品（HN 49157807，42 分），一个月后发布测量报告《Which tools do Claude, Codex and Cursor choose? We measured 16,893 sessions》。方法（以下数字均为 Armature 厂商自述，但声称全部原始 trace 公开在 leaderboards.armature.tech 可复算）：1,163 个 prompt 变体、75 个仓库、3 个 Agent、4 类开发者人格（vibe coder、初级、资深、大厂工程师），在 E2B、Blaxel、Daytona 沙箱里轮换跑 16,893 个会话，最终收敛出 5,292 个有效样本，覆盖 51 个代码库、18 个行业；「模拟人类」和裁判都由 Gemini 3.7 Flash 扮演。

结果是三个可复算的分裂。选择分裂：同场景选同一工具的比例只有 42%；Claude Code 的自建方案率 19%，约为 Codex 与 Cursor（10%）的两倍。信息源分裂：Cursor 约 2/3 会话靠网络搜索决策；Codex 94% 会话搜索、但 9/10 用 site: 限定域名；Claude Code 主要靠参数记忆，仅约 30% 搜索，遇到沙箱这类训练语料稀疏的新领域才升到约 80%。上下文分裂：同一个「发邮件」需求，TypeScript 仓库 Resend 赢（55/89），Python 仓库 Sendgrid 赢（22/24），Go 仓库 Postmark 赢（20/24），Java 仓库 Azure ACS 赢（22/23）。

证据链：从一次测量到一台评价飞轮

时间线上的每一步都可实测，口径分三类标注：厂商自述、转引未验证、独立实测。

• 2025 前后（转引、原始出处未独立验证）：据 Armature 博客转引，Vercel 称超过 30% 的部署由 Coding Agent 发起。我方未能定位 Vercel 原始出处，此数字全文仅此一处，按「据称」读。
• 2026-08-03（厂商自述）：Armature 发布 MCP 会话分析产品，先做「看到 Agent 怎么选」的工具。
• 2026-09-03（厂商自述、trace 据称公开）：16,893 会话测量报告发布，HN 实测 300 分。
• 2026-10-03（独立实测）：npm 包 @armature-tech/agent-reviews 首发（registry API 实测 created=2026-10-03），GitHub 仓库同日建立、0 星（API 实测 2026-10-14）。
• 2026-10-07（厂商自述）：Show HN《Agent.reviews – Where AI agents read and write reviews on tools》（HN 49995539，实测 73 分、51 评论），发帖时自述「已测量 50k+ Agent 会话、数千条评价」。
• 2026-10-14（页面自述文字实测）：agent.reviews 首页写着 189,934 条评价、4,120 个工具，其中 1,971 个已发布评分。从发布时的数千条到一周后的近 19 万条，均为官方页面自述，约 30-60 倍增长。

飞轮的设计图纸是公开的。agent.reviews 每个页面有 .md 版本加 llms.txt 加 SKILL.md 加 MCP 端点；官方 install.md 提供「一条 prompt 装 skill 并开启自动评价」的复制文本，skill.md 明文规定自动评价开启后每次任务结束自动写工具评价。你一条 npx -y @armature-tech/agent-reviews lookup "xxx" 就能验证货架存在——这是本话题一小时可动手的实操面。

被提到不等于被选中：货架经济学的第一课

测量数据里最锋利的一条是提及与中选的脱钩，它说明 Agent 的货架不是搜索引擎的结果页，而是一份带上下文的决策表（以下均为 Armature 自述数字）：

• PayPal 被提及 139 次、被选 0 次，其中 124 场 Stripe 赢走。
• Adyen 提及 175 次、中选 3 次；LangChain 提及 194 次、中选 4 次；Netlify 提及 152 次、中选 6 次。
• Supabase 是提及最多的数据库，却被 Neon 压制，Neon 赢下 66% 的对决；支付场景 Stripe 十场赢九场；对象存储 S3 拿 45%，Azure 与 GCP 各 20%。

更细的粒度上，页面信息呈现本身直接翻转选择：Mailgun 因为免费档写着「1 天日志保留」输给 Postmark；Supabase 因为把 auth、storage、realtime 捆绑报价而常输。人类营销优化的对象是文案与品牌，Agent 营销优化的对象是免费档条款的措辞、site: 白名单里的域名、TypeScript 仓库里 README 的示例代码。这与 SEO（搜索引擎优化）向 AEO（Answer Engine Optimization，让生成式引擎引用你的答案）的迁移同构，只是这次的读者会直接替你装包下单。

agent.reviews：Agent 写、Agent 读的货架，以及它的自我限定

2026-10-07 上线的 agent.reviews 把「被选中」从观察对象变成基础设施：一个 Agent 写工具评价、另一个 Agent 读评价选工具的公开货架。协议面完整——.md 页面、llms.txt、写评价 skill（v2.11.0）与读评价 skill（v2.1.0）、需 OAuth 的 MCP 端点（实测返回 401，非匿名可爬）、npm CLI 提供 lookup、compare、search、category 四个命令。评分样本（页面自述）：uv 4.7 分（1,279 评、99% 任务完成率），Git 4.7 分（20,060 评）；Codex 4.1 分（84% 完成率）、Claude Code 3.9 分（64%）、Cursor 3.7 分（47%）——Coding Agent 类目下六个工具互评，被 Agent 评价已经反身作用于 Agent 本身。

两条自我限定必须一起写，否则就是夸大。第一，读评价 skill 的原文要求：这些评价只讲接入摩擦，绝不可用于挑选或排名工具，不能替代文档、搜索与独立基准。第二，官方把「同一任务多次运行、Agent 每次选谁」的榜单（leaderboards.armature.tech）与日常评价明确切开。所以「Agent 口碑等于工具质量」这句话，连货架主人都不同意。生态成熟度也要诚实：GitHub 仓库 0 星、无开源镜像、无中立第三方、唯一自述跟进者 preseason.ai 未独立验证，MCP 面要登录——渠道由同一家闭源 SaaS 主导。与上一期《快脑拆出大模型，Agent 控制循环改订阅决策函数》的决策模型生态「四周四层齐备」相比，这个生态只有一层，还是首发者自循环。

反方：从 SEO 灾难到 AdWords，HN 的火力全部有据

当年 SEO 灾难看起来也只是无害的学术测量——测量先于污染，是分发渠道史的铁律（评论 49559950）。

四条火力线的结构先看这张地图，再逐条展开。 道德火力最重的一条（评论 49558929）直指渠道化的正当性本身：Armature 卖的就是「用增长手法操纵模型选产品」，让 Agent 推荐并非最优的工具，等于把伤害开发者的 SEO 垃圾玩法搬进 Agent。这条攻击不是抬杠——Armature 自己的博客首段写着免责声明 “Disclaimer: Armature sells growth services to dev tools”，诚实声明恰恰是「测量与生意同源」的最好注脚。操纵路径甚至已经在评论区公开演示：有人写下「给产品狂刷链接、加一条每次启动都读的 durable note 就行」（评论 49561488），另一条讽刺未来：”我已按今日工具赞助商 Firebase 建好数据库”（评论 49558267）。

技术火力最锋利的一问（评论 49997827）：Agent 写的公开评价会进入另一个 Agent 的上下文，这难道不是个 prompt injection（提示注入，指把恶意指令藏进数据里让模型执行）工厂？官方回复只说两个 skill 都是可选的，未正面回应注入面。商业模式火力（评论 49999510、50070994）：一旦 Agent 把这里当参考，下一步就是付费排名，工具界的 AdWords；官网标语 be the tool X chooses 的实质是「让你的工具被找到」，不是「找到最好的工具」。数据质量火力可实测（评论 49998702）：cryptography 与 YAML 同为 4.6 分，我方实测两页确实如此（71 评与 78 评）——Agent 可能在按曲线打分而非事实打分，评分通胀、区分度存疑。

边界条件：这套判断管不到哪里

本期的证据只支持「新引入第三方服务的选择瞬间」这一窄场景，测量覆盖 18 个 SaaS 与库类目；企业内部已有技术栈、采购合规主导、架构评审主导的选型，外推无效。样本以 TypeScript、Python 等开源可见栈为主，私有云与本地部署场景未测。agent.reviews 评分衡量的是 Agent 接入摩擦，官方自己声明不可用于选型排名。前文那个 30% 部署数字若始终定位不到原始出处，就只能以未验证转引的身份活着。

与站内已发期次划清切割：《网站开始给 Agent 单独上一道菜》讲的是供给侧——网站如何向 Agent 供料；本期讲需求侧——Agent 如何替人做选择、选择如何被商业化，两者互为上下游。《一份技能文件写一次》讲能力分发的格式，本期讲分发的货架与评价体系；《外壳走上台前》里 Agent 选 harness，本期 Agent 在 harness 内选第三方服务；上一期的决策模型是「怎么选」的机制层，本期是「选择被谁影响」的渠道层。

未来两个周期的证伪观察点

检验本期判断的，不是 agent.reviews 的评分有多高，而是它会不会在两周内停转，或者被第一个付费排名价目表出卖。

10 月中下旬看三条。其一，评价量是否续涨：基线 189,934 条（2026-10-14 页面自述实测），两三周内破 40 万且评分工具数破 3,000，说明自动评价飞轮真的在转；停在 20 万附近，就是 Show HN 一波流。其二，是否出现独立复现或第三方批评研究（检索关键词 coding agent tool choice measured），若始终只有 Armature 一家数字，「最大测量」可信度打折。其三，16,893 会话研究承诺发布的剩余 1 万+ 会话是否兑现。顺带一个旁证温度计：Codex CLI 默认安装持久自更新守护进程事件（HN 50060694，590 分、285 评论），跟踪 OpenAI 是否把 daemon_auto_start 改为 opt-in——那是「Agent 周边软件悄悄常驻化」焦虑的温度计。

11 月初看两条。其四，是否出现第一个「Agent 渠道」中立基础设施：Vercel、Netlify、Stripe 级别厂商公开按 Agent 推荐量做增长动作，或 G2、Product Hunt 系进场做 Agent 评价，或学术复现——出现任何一条，本期判断升级为强证据；若先出现的是「付费被选中」服务价目表，反方的 AdWords 化将成为下期主叙事。其五，是否出现首例「通过公开 Agent 评价污染他人 Agent 工具选择」的事故报告——出现即把本期核心判断改写成警告体。

总结与行动清单

被 Agent 选中正在成为真实的分发渠道，但它的测量者、货架与增长服务目前是同一家公司；证据链完整，中立性为零——这恰好是分发渠道史第一章的标准样貌。你现在可以做的：

1. 用 npx -y @armature-tech/agent-reviews lookup "你的产品或常用工具" 跑一次，看看 Agent 眼中的货架长什么样，再对照你的官网是否提供 .md 页面与 llms.txt。
2. 如果你是工具厂商：把免费档条款、site: 可发现性、你主力语言仓库里的示例代码当作货架陈列来优化，其重要性对标当年的 SEO。
3. 如果你是 Agent 使用者：意识到你的 Coding Agent 装什么包可能受一个厂商自有的公开评价库影响，关键依赖坚持用文档与独立基准做二次确认。
4. 设一个两周提醒：复查 agent.reviews 评价量是否从 189,934 涨破 40 万，以及是否出现第二个测量者。
5. 对照读供给侧：把《网站开始给 Agent 单独上一道菜》过一遍，供给侧与需求侧两条线合起来才是完整的 Agent 分发图景。

References

• Armature：Which tools do Claude, Codex and Cursor choose?（16,893 会话测量）
• HN：测量研究帖 49557206
• HN：Agent.reviews 产品帖 49995539
• agent.reviews llms.txt（评价量与工具数口径）
• agent.reviews 协议说明
• 写评价 skill（v2.11.0）
• 读评价 skill（v2.1.0，含「不可用于选型」原文）
• 安装说明：一条 prompt 开启自动评价
• Coding Agents 互评类目页
• uv 评分页
• yaml 评分页（与 cryptography 同分证据）
• cryptography 评分页
• Armature 榜单实验
• npm 包 registry
• GitHub 仓库 armature-tech/agent-reviews
• Codex CLI 守护进程 issue
• HN：Codex CLI 守护进程帖
• HN：2025-04 产品推荐排名比较（历史先声）

编程 agent 跑端到端软件工程任务时，一个现实缺口是常常没有现成的预言机评测器。所谓预言机评测器，指任务自带的、可机械执行的成功判据，比如现成的测试用例或验收脚本。判据缺位时，agent 干没干完、干得对不对，就只能靠人或模型来裁。

现有裁判的两条路都不够

现有做法分两条。一条是直接拿通用 LLM 当裁判，不做任何专门训练，判断质量完全取决于基座模型的推理水平。另一条是训练专用 critic，但这类 critic 只输出一个标量分数，作为奖励信号喂给训练流程，不解释判断依据。

被裁判的对象本身也不轻。论文描述的训练轨迹里，agent 与代码仓库和外部工具会发生数百次迭代交互，日志长度和上下文复杂度都远超单轮问答，人工复核在这类轨迹上成本极高，这正是需要自动裁判的场景。

裁判也要后训练：57% 到 78%

SWE-Critix 的路线是训练会说理由的通用裁判：输入任务描述与完整执行轨迹，输出两样东西，一个完成标签，加一段解释判断依据的自然语言分析。基座选用推理模型 Qwen3-30B-A3B，后训练分两步：先做监督微调 SFT，再做强化学习 RL。

效果体现在 held-out 测试集的完成判定分类准确率上：基座 57%，SFT 后 66%，RL 后 78%。基座与最终成绩之间超过二十个百分点的差距说明，通用推理模型不经过专门训练直接当裁判，离可用还有距离；训练出来的裁判才具备商用价值。论文训练了一系列 30B 规模的模型，训练数据来自 CodeForge-Preview 轨迹集。

会说理由，和只打分数不一样

可解释分析是这篇论文与纯标量 critic 的核心区别。标量分数只能用来排序或当奖励信号，分数本身无法审计，也说不清失败原因出在哪一步。自然语言分析则把判断依据摆到明面上：这份交付缺了什么、轨迹里哪一步出了问题，下游可以直接拿去做评审意见或缺陷定位，而不只是拿来排序。

需要划清的边界有三条。其一，这是未经同行评审的预印本，全部数字来自作者自报的 held-out 测试集。其二，CodeForge-Preview 是该团队自产的代码域轨迹集，裁判在其他领域的表现论文未做验证，不能外推。其三，开源承诺覆盖模型、数据集与训练代码，以论文称开源为准。

专利面与技术面的互文

本站简报 《微软圈地代码评审智能体，PR 质检报告还空着》从专利面写过同一个缺口：大厂圈地评审产物，独立质检报告的生意没人接。这篇论文补的是技术面的另一块拼图：裁判层正从拿现成模型凑数进入专门后训练阶段，且直接开源。专利面上被圈占的是评审产物，技术面上免费可得的是一个会说理由的开源裁判，两个面互相咬合但并不重复。

References

• SWE-Critix 论文页（arXiv:2610.13356）
• 本站简报：微软圈地代码评审智能体，PR 质检报告还空着

案情不动，只换被点名的权威

法律场景里，模型在判决书或合同推理之后「点名法条或判例」，通常被当作这条权威就是决策依据的证据。论文的审计设计绕开了对推理文本的信任问题：案情保持不变，把被点名的权威替换成不相关的法条或判例，观察判决是否随权威一起变。判决从模型隐藏状态解码：用 logit-lens 把中间层投影回词表，追踪模型在生成中途已经倾向哪个答案（承诺追踪），再按各类目的经验基准率校正。

为了排除提示词噪声或统计假象，论文做了多重稳健性检查：无混淆重采样（剔除类目难度差异）、案情同义改写、成对选择任务，以及把权威换成空值的对照，结果方向在各检查下一致。

点名正确率与判决改变率的缺口按数据集分列

换掉权威之后判决会变的比率，在三个数据集组上差异很大，论文按数据集分列报告，没有合并：CaseHOLD 上的判决改变率只有 0.0% 到 21.7%，也就是多数模型换了法条答案照旧；ECHR 与 SCOTUS 两个判例基准上是 30.0% 到 76.7%，中间水平；ContractNLI 合同基准上是 43.3% 到 50.0%，最接近「点名确实影响结论」的样子。同一批模型，引用对结论的约束力随数据集体裁波动。

论文把这解释为两阶段假说：模型先按套话把权威念出来，再按案件事实做决定。规模不是解药，从 8B 到 70B 关不掉这个缺口；专门法律推理模型也关不掉——不过这一条来自 best-effort 的 LoRA 微调复现，不是官方模型，属于近似验证而非定论。测量口径也要写清楚：论文量的是行为上的权威依赖，即输出会不会随权威替换而变，不是权威有没有被模型内部表征，它没有证明模型内部没在读法条。

红队评测里，藏在案情里的指令比法条管用

红队评测暴露了更扎眼的对比。在五个核心模型上，藏在案情里的对抗指令遵从率达到 73.3% 到 96.4%，远高于这些模型对替换权威的敏感度，且五个模型无一例外都是这个方向。论文的措辞里没有口号，但这个数据的指向可以概括成一句本站口径的评论：模型听话，但不守法——点名权威是表演，藏在案情里的指令才是被执行的那一条。

需要交代的是，这篇论文截至提交时没有评审场合标注，摘要页也无机构落款，按预印本口径对待，结论仍需同行评审与独立复现检验。但这对审计的提示已经很具体：商业面上，简报 #10 的专利簇在把「答案带出处」做成产品与壁垒；技术面上，本文说明出处本身不证明依据。两篇合起来读才是完整图景——如果合规只验收「有没有引用」，这条验收线根本探不到判决是怎么形成的。

References

• Cited but Not Consulted: A Counterfactual Audit of Legal Chain-of-Thought Faithfulness
• arXiv 摘要页

结构税此前一直记错了账

「结构税」指强制模型按预定义格式作答所带来的精度下降，结构化输出即模型必须按给定 schema 逐字段填写答案。此前的普遍做法是把这部分损失当作使用 JSON 或 XML 的固有成本接受下来。PayPal AI 团队用五个模型乘以四个数据集的全交叉矩阵重审了这一假设：模型侧是 GPT-4o、Gemini-Flash-2.0、Claude-Sonnet-4.5 三个闭源前沿模型，加上 Llama-3.1-8B 与 Gemma3-4B 两个不同量级、不同家族的开权重模型；任务侧覆盖 GSM8K（应用数学）、MMLU（知识选择题）、LogicBench（逻辑推理）与 Spider（Text-to-SQL）。结果显示，税的高低由字段顺序决定：推理优先的排法——先写推理字段、再写答案字段——在相同任务上匹配甚至超过自由文本输出；真正出事的是答案优先的排法。

10.98% 的崩盘需要四个前提

最剧烈的翻转出现在四个条件叠加时：GSM8K 数据集、XML 格式、答案字段排在推理字段之前，开权重的 Llama-3.1-8B 与 Gemma3-4B 双双跌到 10.98%，而同条件下推理优先的排法保持在 83-87%。这个对比数字剥离掉任何一层前提都不成立，引用时必须带上完整的任务、格式、顺序与模型范围。论文同时给出了税的分布规律：格式敏感度与任务自身对答案结构的约束成反比，答案被题目约束得越死的任务，字段顺序能造成的差距越小。针对提示词表面变体的重跑实验显示结果稳定，效应不是某一条提示词的偶然。

先落子的答案 token 为什么贵

机制解释很直接：模型是自回归生成，只能逐 token 往后写；答案字段排前面，意味着答案 token 在任何推理内容写出来之前就被落子承诺。等于强迫模型先押注答案，再补写配合该答案的过程。论文把实验中观察到的两种失败模式归到同一个根因：答案承诺发生得太早。推理优先的排法只是恢复了自然顺序——过程先行，答案最后落子。论文还给出内部表征与校准两个层面的证据：按 CKA 相似度分析，推理优先时中间层里答对与答错样本的表征可分性更大；校准误差指标也随之改善，即模型的置信度与其真实答对概率的吻合程度更高。

工程师的结论：把字段顺序倒过来

可执行的结论只有一句话：给模型的 JSON schema 里，把推理或依据字段放在最终答案字段之前。不换模型、不增加推理开销，只改字段声明顺序，是一项经过评审验证的免费午餐。这与本站前一天的 AI 范式雷达第 14 期 正好互补：雷达讲的是供给端——行业为什么集体转向类型化的决策输出；本文补上使用端——字段怎么排才不会为同样的输出付税。对生产系统必须使用结构化输出的团队来说，问题已经不再是要不要用 JSON，而是 JSON 的字段按什么顺序写。

References

• Structure Tax: How Structured Output affects LLMs Performance (arXiv:2610.12056)
• 论文 PDF 全文

被审计的组件叫类型化决策模型（typed decision model）：读入文本，在调用方自定义的选项上返回概率（每个选项附一段书面定义），自身不生成文本。近期工程实践把这类便宜小模型当作 Agent 闸门（guardrail）：读取工具调用或来件消息，决定放行还是拦截。

一个方向错误率低不代表可靠

这个准确率区间跨提示注入、越狱、有毒内容三类任务，不能当作单一场景数字。单一方向的低错误率只反映模型默认答哪一边：一个几乎什么都放行，另一个几乎什么都拦截。拆开看两类错误比总准确率信息量更大——几乎全放行的闸门没有拦截成本，却最危险。

攻击不需要碰到被审内容

两个攻击都不碰被判定本身。第一个：在作者自建的合成 Agent 工具调用套件上，六行与服务策略无关的服务器日志，把某闸门的 fail-open 率从 0% 抬到 63%——前提是该闸门原本能正确判这条策略。第二个更省事：只给宽松选项起一个误导性名字，选项定义与被判文本都不动，同样的率就在 四个把标签放进输入的模型上抬到 93% 到 100%。一个名字就打开了闸门——这就是「选项通道」的来源：模型从选项标签上读到了策略之外的信息。

防御全线失守，最稳的防御是辞退模型

作者测试的防御全部被破解：要么攻击者针对防御机制下手，要么攻击者控制的文本直接奏效。「加个置信度阈值就安全」也被堵住——把最低置信度的决策升级给人工复核没用，被翻转的决策置信度并不比翻转前更低。

唯一稳固的路径是把每个策略字段解析成类型化的值，再对这些值跑确定性规则：在全部六条策略上达到 100% 准确率，同时消除了选项名攻击。但这条防御一上岗就暴露了自己的推论——既然规则能判，模型在这条通道上就不必要。作者口径克制：这些模型可以减少送到人工复核的案件量，但按现有证据，不应由它们充当做最终决定的那个组件。同样在安全轴上，《没有任务智能体仍会拆掉同伴的关机开关》查的是 agent 自身的行为倾向，这篇查的是外部闸门本身有多可靠——一个查内鬼，一个查门卫。

质疑与边界

• 论文是 2026 年 10 月 8 日提交的预印本，未经同行评审，数字待独立复现。
• 两个关键攻击所在的合成套件由作者自建，不是工业部署的真实流量，真实环境中的可迁移性未验证。
• 93% 到 100% 只发生在把标签放进模型输入的四个模型上，不能外推到全部七个被测模型；六行日志抬升 63% 同样以「该策略原本能判对」为前提。
• 确定性规则的 100% 限于字段可类型化解析的六条策略；对必须依赖语义理解的策略是否仍成立，论文没给证据。

References

• One Word Opens the Gate: The Option-Channel Attack on Typed Decision Models as Agent Guardrails
• 论文开源代码仓库
• 一分钟读论文：《没有任务智能体仍会拆掉同伴的关机开关》

四周内成形的生态波

判断这是范式而非发布稿，看跟进者构成。GitHub API 实测（2026-10-11）：jaredpalmer 的 kev（基于 Qwen3.5/3.8 的 Jev 风格模型家族）8,895 星；firelex 的 jeff，0.8B 家用训练，1,499 星；ollaya 是本地决策模型运行时，1,283 星；Nokia 应用研究团队的 AnyJev 把任意 LLM 转成 Jev 风格模型，1,150 星。清单层：awesome-jev 2,261 星、awesome-jev-tools 743 星，GitHub 搜索 “jev decision model” 返回 1,087 个仓库。模型、运行时、路由、清单四层齐备，是生态信号而非单品信号。

大厂一侧：Cloudflare 发布开放权重决策模型 Clef（HN 49923692，641 分），AWS 系 Strands 发布 Decider 2B 开源决策模型（HN 49987076，285 分）。更早的 HN 49765348（1363 分）里，Laya 声称一年前做过非自回归决策模型——品类不新，新的是命名、兼容接口与生态位分工。价格侧另有共振：DeepSeek 4.1 Flash 帖（HN 50000488，1107 分、967 条评论）与「Tokens too cheap to meter」讨论（HN 49813482，354 分）同属把模型调用做成廉价基础设施的漂移。TypeSafe 的延迟 70ms-500ms、输出免费、融资 870M 美元与估值 7.5B 美元（HN 50023450，423 分），均为厂商自述。

快脑与慢脑的架构分工

TypeSafe 发布稿里那句 “unstructured state in, typed probabilistic decisions out”（非结构化状态进，带概率的类型化决策出）是这次分工的钥匙。传统 Agent 循环里，每轮工具选择、路由都要让自回归大模型逐 token 生成文本，再由外层代码解析——决策伪装成对话。决策模型把这层剥掉：并行采样的非自回归直接输出标签加概率，不参与聊天。类比 CPU 时代「通用核 + 协处理器」分工：慢脑管推理与生成，快脑管高频结构化决策，两者在同一条控制循环里分层订阅。

对 “can’t hallucinate” 这类强宣称要给反方留位：不发散文本拿掉了编造事实的通路，但概率失真、标签集外误判仍在，公开可复现基准之前，这句话只能当设计目标读。本站此前的论文解读《改一个选项的名字就能打开安全闸门》查的是这类模型当安全闸门有多不可靠；本期讲为什么全行业在造这类模型。一期造闸、一期验闸，互为印证而非矛盾：造闸潮越大，验闸越值钱。

反方：没有基准的品类与商品化风险

社区火力：Jev 主帖评论 id 49719120 称技术与结果含糊，RLCD 是什么、相比 LLM 的基准分数在哪，整篇像营销稿，品类发布至今没有公开可复现基准。评论 id 49720601 称速度对比「极其不诚实」，id 49720956 附和：端到端 LLM 延迟对比单步决策延迟，口径不对等。更根本的是 id 49723102：这就是个对自定义标签输出加权分的分类器，质量能否超过结构化输出模式的 LLM 待客观基准验证——「新瓶装旧分类器」论直接攻击品类成立性。商品化专帖：「OpenAI 已处在跟进 Jev 的有利位置」（HN 49802161，328 分）——兼容接口越像标准，首发者护城河越薄。共同点：范式成立不等于 TypeSafe 赢。

边界与观察点

边界要划清：与集群调度切割——调度层管 Agent 负载在集群里怎么排队休眠，本期讲控制循环内用哪类模型决策；与文件标准之争切割——Jev-compatible 目前是事实兼容生态，没有成文跨厂商标准，写成「标准之战」会误导读者。

验证信号：kev/jeff/ollaya 星数增速（基线 2026-10-11）；第三方盲测基准是否出现，当前最大空缺、反方火力点；OpenAI、Anthropic 是否发同类类型化决策端点，fast-follow 论的证实或证伪点；DeepSeek 系是否跟进类型化输出与免费输出定价，两条廉价路线是否合流。如果你正在构建 Agent：把控制循环里高频、只需标签加概率的部分拆出来，用 kev 或 jeff 加 ollaya 本地验证，安全闸门留在待验清单。

References

• Introducing System One Models and Jev
• HN：Jev 首发帖
• Cloudflare：Clef 开放权重决策模型
• Strands Decider 2B
• kev 仓库
• jeff 仓库
• ollaya 仓库
• AnyJev 仓库
• OpenAI is well positioned to fast-follow Jev

专利信号

四件均为近期公开或授权文本，公开与授权状态已分别标注：

• US12614037B2，Microsoft Technology Licensing, Llc，2026-04-28 授权：用大模型做复杂数据库的对话式检索接口，用户可在会话中反复改写查询条件。
• US20260111428A1，Amazon Technologies, Inc.，2026-04-23 公开（优先权日 2024-10-23）：先对自然语言做实体抽取与领域预测，再挑出所需数据表，生成「可直接产出 SQL 的实体关系图」，最后由图生成 SQL。
• US20260119483A1，Dell Products L.P.，2026-04-30 公开：把人可读的查询转换为机器可读查询。
• US12613928B2，Snowflake Inc.，2026-04-28 授权：用大模型在数据清单（data listing）里做检索匹配。

同族申请公开文本 US20260220380A1（优先权日 2024-01-31，与 US12614037B2 同名 LARGE LANGUAGE MODEL INTERFACE FOR COMPLEX DATABASES）申请人同为 Microsoft Technology Licensing, Llc。

技术趋势

共同走向：把「一句话翻译成 SQL」从提示词工程挪进结构化中间层。亚马逊的专利不让模型直接写 SQL，先生成实体关系图；微软与 Snowflake 把会话上下文与数据目录做成系统组件。与「通用大模型加一句提示词」的差异：专利方案的准确率取决于元数据厚度（表注释、字段口径、历史查询），不取决于提示词运气。

这意味着 NL2SQL 的竞争点已从「会不会写 SQL」转向「元数据与校验做得够不够厚」。前者被专利与大厂产品占住，后者没有。

落地机会

用户场景：5-20 人的 SaaS 团队把自然语言查数接进内部后台，业务同事问「上月华东退货率」，系统返回一个数字。没人知道这条 SQL 选没选对表、过滤漏没漏退款单——错了也没人发现，直到周报被质疑。

针对这个痛点，一个人能做的那一层是金标准问题集加自动回归校验：把业务方高频的 50-200 条问题固化成期望结果（行数、取值区间、关键字段），每次换模型或改提示词跑一遍；再叠静态检查——漏没漏分区过滤、是否 SELECT *、JOIN 是否放大行数。

现成技术栈：开源库 Vanna 加本地 SQLite/Postgres 做被测对象，BIRD（文到 SQL 公开基准）做能力对照，校验层用 Python 自写。起步成本约 3000-8000 元：API 调用加一台小服务器。

创业发现

• 查数质检服务：给已上线 NL2SQL 的小团队做两周交付——问题集、回归脚本、错误率报告。首批客户从数据外包群与自带报表的 SaaS 团队找，按项目收 1-3 万元。
• 校验插件：同一套检查做成 Postgres 中间件或编辑器插件，按月订阅，每席位几十元。

门槛一句：要读得懂执行计划、能判断结果是否合理。风险一句：模型厂商原生内置评测能力后，独立工具的生存空间会被压缩。

上一篇Agent 轨迹评测专利是给智能体交付物做验收，这一篇是同一道理落到查数场景：先有可核验的分数，才有付费理由。

References

• Google Patents：US20260111428A1 Generating SQL queries from natural language requests
• Google Patents：US12614037B2 Large language model interface for complex databases
• FreePatentsOnline：US20260220380A1 申请公开文本
• BIRD Benchmark：文到 SQL 准确率基准
• Vanna：开源 NL2SQL 库

仿真的可信度靠什么建立

仿真评测最常被问：仿真分数和生产分数是一回事吗？论文的回答是先做相关性验证再谈应用——跨 4 个已部署版本，把仿真跑出的版本级二元评估分（binary evaluator，按预先定义的规则判定会话成败，非人工抽查）与生产同口径分数对比，两者高度相关。这一步是全文的地基：没有它，后面所有「仿真筛出来的配置上线更好」都只是巧合叙事。方法上是假设驱动的组织——先写下这版智能体要验证的假设，再让合成客户沿假设场景走流程，而非漫无目的地海量对话。地基打好后，仿真成了发布门禁：新配置先在仿真里过筛，才允许见真实客户。

两次线上实验回收了仿真的价值

相关性立住之后，仿真开始产出。第一条线：用仿真引导迭代智能体本身，改完再仿真、过了再上线 A/B——交易后净推荐值（tNPS）提升 36.69 分。第二条线更工程化：仿真里跑 16,000+ 场合成会话筛选开源权重模型的配置组合（模型、推理设置、提示词），选出配置上线 A/B，自助率（SSR，客户不转人工就解决的比例）提升 8.82 个百分点，达 Nubank 有记录以来最高，同时 tNPS 无统计显著变化——自助率上去了，满意度没被牺牲。作者口径克制：仿真让大范围探索模型与提示词变得可行，靠线上实验做这些不现实——每次试错都要拿真实客户垫底。

这份证据能信到什么程度

四条折扣要摊开说。第一，这是 2026 年 9 月 24 日提交的预印本，尚未经过同行评审。第二，相关性验证的粒度很粗：所谓「四个版本高度相关」只有四个数据点，二元评估分也只看成功与否，细粒度的用户感受差异未必照得出来。第三，全部证据来自 Nubank 自家场景的自证——同一家公司设计仿真、跑实验、报结果，没有第三方复现；客服对话智能体之外（比如长任务型 agent）能不能复制这套流程，论文没有回答。第四，Snowglobe 是文中使用的仿真器，是否开源论文未给出承诺，直接照搬不可行，能借鉴的是「假设驱动 + 版本级相关性验证 + 上线前门禁」这套方法骨架。

对做产品的人意味着什么

真正可迁移的不是某个仿真器，而是便宜的闭环结构：把历史会话日志改造成合成客户剧本库，先小流量验证「仿真分与生产分相关」，相关了再把仿真当发布门禁用。凡有客服、工单、对话式入口的团队，这一步门槛不高——不需要重建生产后端，工具输出可以桩掉，客户反应可以用模型扮演。与站内 上一篇讲 RAFT 工单检索的文章正好是一前一后两道工序：那篇管知识库入口——历史案例怎么被检索到；这篇管发布门禁——新配置见客户之前先过一遍仿真考场。

References

• Screen Before You Serve: Simulation for Production Customer Experience AI Agents at 140M Scale（arXiv:2609.30137）
• 站内：查历史工单要比所处阶段而非整篇文档