907 篇博文 含有标签「insider」

模型正在逐个 Token 地输出 JSON。你的 UI 希望在字段出现的那一刻就进行渲染 —— 在冗长的回答正文之前显示置信度得分，或者在模型填充工具调用参数时实时显示它们。接着，有人尝试在每个数据块（chunk）上调用 JSON.parse，结果整个系统就崩溃了，因为 JSON.parse 是“全或无”的。它需要一个结构完整的文档才能返回任何结果。在模型输出闭合括号之前，你什么也显示不出来。

这不是一个可以通过 try/catch 解决的解析器问题。标准 JSON 解析器是针对内容长度已知的 HTTP 响应设计的。部分输入并不是它所建模的状态 —— 而是被视为“输入错误”。当你将 Token 流视为 HTTP 正文处理时，你继承了三十年来“文档要么完整，要么无效”的传统，而你的 UI 则为此付出了代价。

当你的智能体（Agent）扇出五个并行工具调用——跨三个索引进行搜索、查询两个数据库、调用一个外部 API——的那一刻，你已经跨越了一道无形的界限。你不再是在编写“提示-响应”（prompt-and-response）代码，而是在编写一个并发程序。大多数智能体框架都假装你没有在这样做，而账单会在凌晨 2 点准时送达。

这种假象是令人愉悦的。规划器（Planner）发出一个工具调用列表，运行时环境（Runtime）启动它们，收集返回的任何结果，最后由规划器消费这些汇总数据。从万英尺的高空俯瞰，这就像一个扇出 / 扇入（fan-out / fan-in）流水线，大多数团队在生产环境给他们上课之前，也确实是这样对待它的。问题在于，二十年的并发编程研究——部分失败语义（partial-failure semantics）、结构化取消（structured cancellation）、背压（backpressure）、确定性错误归因（deterministic error attribution）——已经解决了你即将重新发现的那些失败模式。而你的智能体框架在默认情况下，没有引入其中的任何一项。

用户提交了一个 $0.01 的请求。你的智能体读取了一个网页。40 秒后，该次对话的推理账单变成了$42。该查询在技术上是成功的——智能体返回了一个合理的答案。只是为了得到这个答案，它经历了三个嵌套的子智能体、一次 200K token 的文档获取，以及一个递归的计划优化循环。这些扇出（fanout）操作并非用户的本意，而是隐藏在智能体所读取页面中的一句话。

这就是代币放大（token amplification）：一种提示词注入攻击，它不窃取数据，不调用未授权工具，也不会留下明显的安全特征。它只是烧光你的账单。云账单是攻击载荷，而用户的请求则是载体。

供应商声称这次升级是无缝替换。API 契约保持不变。配置中的模型名称几乎没变。一周后，你的上下文窗口防御机制（context-window guard）开始在以前从未触发过的提示词（prompts）上报警，你的停止序列（stop-sequence）正则匹配在了错误的位置，而你的少量样本（few-shot）示例之一开始产生一个极其自信的错误答案，而你的评估套件恰好没有覆盖到这一点。没有人动过提示词。没有人动过温度参数（temperature）。有人悄悄重新训练了分词器（tokenizer）。

分词器更改是供应商不会称之为“破坏性”（breaking）的破坏性更改。API 层面保持了字节级稳定，SDK 没有升级主版本，发布说明中提到了“改进的指令遵循能力”——但从你的输入字符串到模型实际看到的整数序列的映射函数已经被替换了。你的代码关于文本如何转换为标记（token）的每一个假设现在都出现了微妙的偏差。这种隐形代价是，在有人重新通过 count_tokens 运行标准提示词并发现答案之前，你会经历两周“感觉模型不太一样”的困惑期。

调取任何生产环境智能体（agent）的一周工具调用追踪（tool-call traces），你会发现其规律如出一辙：三四个工具处理了 90% 的调用，其余数十个工具则瓜分了剩下的 10%。工具目录呈现幂律分布（power law），但框架却将其视为均匀列表。每个工具描述都会出现在每个系统提示词（system prompt）中，每个选择准则都对工具一视同仁，每个评估（eval）在对目录进行采样时，都仿佛 search-files 调用和 refund-issue 调用来自同一分布。事实并非如此。

这种“扁平化”处理的代价在爆发前往往是隐形的。团队增加第 18 个工具，规划器（planner）对最初三个工具的准确率下降了两个百分点，却没人能将这种退化归因于特定变更，因为所有指标都同时发生了偏移。而评估套件本身在目录中也是均匀分布的，它将这些下滑平均成一个看起来依然正常的数字。与此同时，本轮对话中模型不会调用的工具描述所消耗的 token，已经超过了用户实际提示词的 token。

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 出现了，要求重新协商。你可以选择在代码审查中主动进行协商，也可以选择在下一次事故期间被动进行。