578 篇博文 含有标签「insider」

read_file 是安全的。send_email 是安全的。你的安全审计对照各自的威胁模型分别批准了它们：对已知目录的只读访问，以及通过带有速率限制和收件人日志记录的已认证中继发送的出站邮件。每一个都通过了，两者都已注册。随后智能体将它们组合在一起，而客服工单中的一行注入文本就将这对组合变成了外泄工具，原有的审计对此根本没有描述这种风险的术语。

危险并不存在于工具图谱的任何节点中，而是在于边。你运行的每次针对单个工具的安全审计都是对顶点的判定；而智能体实际的权限表面是目录中的路径集合，这个集合呈二次方增长，而你的审计流程却只能线性扩展。当你的智能体拥有 15 个注册工具时，你审计了 15 个项，却发布了大约 200 个可达的两步组合，其中没有一个经过人工审核。

大多数生产环境中的 AI 功能在发布时只带有一个置信度阈值。在阈值之上，模型给出回答；在阈值之下，用户会得到一句生硬的“我不确定”。这个单一的数值同时承担着两个完全不同的任务，这就是为什么即便你对已回答查询的准确率看起来不错，但信任度指标却已经连续两个季度下滑的原因。

正确的设计至少应该有两个切分点。一个“弃权”（abstain）阈值设在低位：低于该值时，模型拒绝回答，因为此时保持沉默比给出任何答案都更有价值。一个“升级”（escalate）阈值设在中间：在两个切分点之间，系统将案例交给人工审核员，而不是直接将其丢弃。将它们合并成一个刻度盘，你发布的产品在出错时和不确定时会让人感到同样无用——在用户只需打开另一个标签页就能找到免费替代品的市场中，这是最糟糕的处境。

这并不是什么新鲜想法。拒绝选项分类器（reject-option classifier）的文献自 20 世纪 70 年代以来就一直在主张拆分阈值，将“歧义”拒绝（输入介于已知类别之间）与“距离”拒绝（输入远离任何训练数据）区分开来。生产环境中的 AI 团队总是在以惨痛的方式重新学习这一教训，通常是在首次发布大约六个月后，当支持队列中挤满了询问“这玩意儿是坏了还是怎么了”的人时。

一个模型提供商发布了 99.9% 的可用性 SLA。采购团队将其理解为“三个九，每年四个小时的停机时间，对于非 0 级（非核心）工作负载是可以接受的”。六个月后，智能体（Agent）功能上线，值班仪表板显示用户感知的任务成功率约为 98% —— 这个数字没有写进任何合同，在提供商的状态页面上也找不到，而且没有人为此负责。提供商满足了他们的 SLA，而产品却没达到其 SLO。两者同时成立，而这种差距并不是一个 bug —— 这是一个算术问题。

大多数团队都忽略了算术这部分。提供商的 99.9% 是针对同步请求工作负载进行衡量的 —— 一个用户，一个提示词，一个响应，一个计费事件。而智能体并不会产生这种工作负载。一个用户感知的任务会扇出（fan out）为 8 到 20 次推理调用，它会对瞬时错误进行重试，对慢速调用进行对冲（hedge），并聚合部分输出。每一次调用都是对提供商故障分布的一次独立抽样，如果任何关键调用失败，任务就会失败。SLA 覆盖的边界和用户感受到的边界并不是同一个边界。

当这种情况第一次发生时，值班工程师正盯着已经全红的 Gmail Postmaster 仪表盘，支持信箱因为客户重置密码邮件落入垃圾邮件箱而告急，而导致这一切的智能体（Agent）仍在运行。在当地时间凌晨 4 点到上午 9 点之间，它从公司的主要发送域名发送了 8 万封“个性化跟进邮件”，且全部使用了计费系统所用的同一个 DKIM 密钥签名。等有人注意到时，花费三年建立的域名声誉已毁于一旦，接下来六周内，公司所依赖的每一条事务性消息的收件箱投递率也将随之化为乌有。

从智能体发送邮件看起来就像是一个单行的工具调用。send_email(to, subject, body) 是最经典的演示，每个框架都将其作为入门集成提供。但邮件不同于其他工具。错误的数据库查询可以回滚，错误的 API 调用会返回错误。而一批糟糕的邮件会降低你公司发送的每一封其他邮件的送达率，且持续数周之久。这里没有可以回滚的事务，因为邮件已经发送到了接收方的邮件服务器，而这些服务器正在记录你域名的声誉历史。

当智能体（agent）在同一个 diff 中编写函数和注释时，该注释并不是文档。它是代码在编写时的转述，由同一个模型从同一个上下文中生成。当代码第一次发生变动时，它就会悄然出错。函数被重构，参数类型改变，或者添加了提前返回（early-return），但注释却保持不变。到下个季度，注释所编码的规范已不再与代码匹配，而下一位读者会因为注释更易读而选择相信它。

这是一个古老的失效模式 —— 人类修改代码，注释保持陈旧 —— 但智能体从三个维度同时加速了这一进程。注释量增加了，因为智能体无论是否需要，都会给每个函数添加文档块（doc block）。注释的语法非常完美，所以审阅者不会将其标记为低质量。而且，注释用与代码实际执行不同的术语来转述代码，因此它们看起来像文档，但实际上编码了第二套规范，这套规范独立于第一套规范而漂移。

如果代码审查流水线中的作者和审阅者都是在重叠语料库上训练的语言模型，那么它就不是一个质量关卡，而是一个信心放大器。作者编写的代码在 Transformer 看来是合理的，审阅者以同样的合理性视角阅读代码，双方最终达成“看起来没问题”的共识，于是代码变更带着一个绿色的勾合并了，而这对于变更是否真正正确毫无意义。最近的行业数据清楚地展示了这种不对称性：在同等规模下，与 AI 共同编写的 PR 产生的严重问题（critical issues）比人类编写的高出约 40%，重大问题（major issues）高出约 70%，其中逻辑和正确性错误占了差距的大部分。而为了捕捉这些错误而发布的审阅代理（reviewer agents），从构造上来说，恰恰是最不具备发现这些错误能力的。

那些从 AI 代码审阅中获得真实信号的团队已经不再将“审阅”视为“生成”的某种变体，而是开始将审阅设计为一种本质上不同的认知任务。生成式提示词（Generation prompting）要求模型产生连贯的内容。而审阅式提示词（Review prompting）则必须要求模型发现缺失的东西——去关注 Diff 中的负空间而不是正空间——这种反向思维比一行系统提示词所暗示的要难诱发得多。

我认识的一位后端工程师在一个周二的下午盯着一个从未有过波动的 Datadog 图表：其内部日历服务的单用户 429 计数器。投诉的客户并没有改变他们的行为。他们只是开启了助手功能，现在每当用户说“帮我找下周的时间”时，该功能就会针对同一个日历 API 并行启动八个规划线程。速率限制器（Rate Limiter）——每用户每分钟 60 次请求，这个设置非常合理，是多年前针对一个在物理上无法点击得那么快的 UI 编写的——在每次请求的前三秒内就会触发，并悄无声息地破坏了助手一半的响应。

速率限制不是 Bug。契约才是 Bug。那个后端，就像大多数在 2024 年之前编写的内部服务一样，在每一层都植入了一个悄然执行的假设：一个用户意味着一条活动流，其节奏受限于人类的反应时间，拥有一个 cookie 罐、一个 CSRF 令牌和一套在出现问题时可以重新提示的凭据。Agent 一次性粉碎了所有这五个假设，故障表现为一系列看似无关的事件——429 风暴、“最后写入者胜”（last-write-wins）导致的数据损坏、无法取证的审计日志、挂起无头工作线程的重新认证循环——在模式被命名之前，没有人会将它们联系起来。

我一直与平台团队沟通的一个简短总结是：你拥有的每一个后端都与它的调用者有一个未记录的契约，而那个契约是与人类协商达成的。现在 Agent 出现了，要求重新协商。你可以选择在代码审查中主动进行协商，也可以选择在下一次事故期间被动进行。

你的推理火焰图（inference flame graph）有一个成本轴，但没有能源轴。这种差距在某天早上之前都没问题，直到客户的采购团队给你发来一份包含 23 列供应商可持续性披露信息的电子表格，其中一列是 每 1,000 次推理的 kgCO2e。你没办法填那一格，你的供应商给出的答案是一篇方法论论文，而交易将在 9 天内关闭。你的平台团队磨练了两年的 token 成本仪表盘突然看起来像是解决了一个错误的问题。

这里的转变并非抽象的。可持续性披露正在从公司层面的汇总转向产品层面的颗粒度。第一波浪潮于 2025 年进入了 CSRD 和 ESRS，而第二波浪潮现在正冲击着 B2B 采购合同。构建了成本可观测性的工程组织即将发现，他们需要针对碳排放的可观测性，而这两者在同一个 span 上并非同一列。

一个用户打开聊天窗口，请求退款，得到“抱歉，此次购买不符合退款条件”的回复后，关闭了标签页，再也没有回来。在内部，智能体生成了一条完美的追踪记录：工具调用、中间推理过程、参考的政策包，以及运行的模型版本。每一个 span（追踪跨度）都进入了可观测性平台。但没有任何内容是用户可以触及的。这里没有标为“请求人工再次审核”的按钮，即使有，后面也没有相应的服务。这个决定在默认情况下就是终局，而非设计使然。

这就是“可争议性差距”（contestability gap），它是监管机构、律师和愤怒的用户接下来要撕开的口子。这也是一个最典型的例子：一个从外部看像是政策问题，而从内部看实际上是工程链路（plumbing）的问题。

架构图上写着“三个前沿模型集成、辩论与对齐、多数投票”。追踪记录显示，所有三个智能体在第一轮就达成了一致，并又花了两个回合礼貌地互相转述。评估结果显示比单次调用高出 0.4 分。账单显示成本是 4.2 倍。在这其中的某个环节，有人判定这个委员会运作良好。

多智能体辩论被宣传为一种获取分歧驱动推理的方法：三个大脑相互争论，以获得比其中任何一个单独达到的更好的答案。但这取决于智能体是否真的存在分歧。在重叠的网络语料库上训练、针对重叠的偏好数据集进行指令微调、并针对重叠的安全分类法进行对齐的前沿 LLM，其共享的先验知识远比架构图所承认的要多。在经过一轮“让我们达成一致”之后，你观察到的并不是三种观点向真理汇聚——而是来自同一个分布的三个样本向它们原本就相距不远的众数汇聚。

这种模式在最近的文献中有一个名字：当一个集成的投票分歧率趋于零且与问题难度无关时，你就遇到了辩论多样性崩塌（debate diversity collapse）。委员会仍在投票。但投票已不再携带任何信息。

第一个内部 LLM 网关的构建通常是出于那些枯燥的原因：成本归因，以便财务可以回答“哪个团队花了推理预算”；速率限制，防止某个失控的脚本烧掉月度配额；以及供应商故障转移，确保 OpenAI 的小故障不会导致助手挂掉。数据泄露防护 (DLP) 虽然出现在幻灯片上，但交付时却变成了“每个应用团队在调用模型前应自行脱敏敏感字段”。六个月后，生产环境中有九个应用，三个维护得半吊子的脱敏库（带有微妙差异的正则表达式集），两个完全绕过网关“仅用于测试”的原型，以及一起 Prompt 中包含客户数据的事故——而这本该是由每个人的中间件来防止的，因为并没有人的中间件是规范的出站口。

这不是工具问题，而是架构错误。DLP 是一种出站控制，而出站控制只有在路径强制执行时才有效。当你让应用团队负责脱敏时，你就放弃了让 DLP 发挥作用的特性——即敏感数据只能从一个地方流出，且你可以证明流出了什么。2025 年的 LayerX 安全报告用大多数团队尚未意识到的数据说明了问题的规模：2025 年初，与生成式 AI (GenAI) 相关的 DLP 事故增加了一倍多，目前占 SaaS 流量中所有数据安全事故的 14%，员工平均每天向 GenAI 工具粘贴 6.8 次内容，其中超过一半包含公司信息。影子路径默认在胜出。

智能体自信地报告：“我已将会议改至周四下午 3 点。”用户却盯着原本周二上午 10 点的时段发呆，因为在智能体制订计划到提交更改的这段时间内，用户自己编辑了该事件。“最后写入者胜”（Last-write-wins）策略让自动化的操作覆盖了人类的修改，而用户对助手的信任也因这一次事故而崩塌。这就是双写竞争（dual-writer race），也是智能体工具链从未专门设计应对的 bug 类别。

大多数智能体平台都无意中继承了这一问题。工具层将 update_event 视为一个简单的函数调用：获取 ID，获取新字段，返回成功。底层的提供商 API 十多年来一直提供乐观并发原语（optimistic concurrency primitives）——ETags、版本令牌（version tokens）、If-Match 前提条件——但几乎没有人将它们贯通。模型无法知道它一分钟前所推理的世界已不再是现状，因为由于它所获得的抽象层静默地丢弃了这些信息。