907 篇博文 含有标签「insider」

你做了负责任的事。你检查了你的 agent，识别了那些可能造成真正损失的操作——发放退款、删除记录、发送外部邮件、部署配置更改——并将它们路由给人工审批。风险分级门控（Risk-tiered gating）。教科书级的做法。评审委员会也签署通过了。

然后，三周后收到了一个客户投诉：一个 agent 任务自上周二以来一直处于“进行中”。没有失败。没有报错。只是停留在一个人工审批队列中，而事实证明，根本没人在关注那个队列。Agent 完成了它的工作，将危险操作挡在门后并等待。而这扇门没有负责人。任务在没有仪表盘指向、没有警报触发的地方默默地老化。

两个小时的课后作业和 45 分钟的算法面试从来都不是重点。它们只是代标（proxies）。课后作业代表的是“这个人能否交付功能”，而白板面试代表的是“这个人能否在压力下分解问题”。二十年来，这些代标运作得相当不错，以至于大多数团队都停止了对它们的质疑。它们的管理成本低、易于评分，并且与你真正关心的能力大致正相关。

编程 Agent 破坏了这种相关性，但没有破坏形式。面试照常进行。它仍然会产生一个分数。这个分数看起来仍然像是有意义的信号。但面试所衡量的东西与工作所需的能力之间的差距已经拉大到如此地步，以至于一个合格（green）的结果几乎证明不了任何东西——而大多数招聘流程还没有意识到这一点，因为表面上没有任何失败的迹象。

这是一种悄无声息的失效。不是过程崩盘了，而是一个过程在它的假设前提不再成立后仍在继续运行。

编程面试的设计初衷是为了隔离单一变量。把一个人关在房间里，给他们一个问题，拿走他们的参考资料，观察他们是否能独立将问题转化为可运行的代码。这种形式的一切——白板、空白编辑器、禁止查阅资料——都是为了剥离协作者和工具，从而衡量一种被隔离的技能：这个人能否在压力下独自编写出正确的代码。

这项技能已不再是工作中需要锻炼的技能了。2026 年的日常工程工作是工程师与智能体（Agent）之间的协作。工程师决定构建什么，智能体起草大部分代码，而工程师真正的任务是审查、纠正，并判断智能体何时在“自信地犯错”。面试衡量的是独立产出代码的能力。而工作奖励的是指导一个不知疲倦、快速、偶尔产生幻觉的协作者。代理指标与目标已经脱节，而大多数招聘流程尚未察觉到这一点。

这并不是在抱怨作弊，尽管作弊是每个人都关注的症状。这是一个测量问题。当你无法再观察到测试旨在隔离的变量时，测试就不再产生信号——而一个在所有人仍然信任它的同时却不产生信号的测试，比根本没有测试更糟糕。

大多数团队将上下文窗口视为一种预算。你有一百万个 token；明智地使用它们；更长的对话成本更高，运行速度也更慢。这种框架是正确的，但并不完整。上下文窗口也是一个攻击面，它的尺寸就像一个旋钮，随着数值的调大，会悄无声息地削弱你的安全控制。

这是没人会放在威胁模型中的失效模式。你的系统提示词（System Prompt）——包含护栏、工具使用规则和“绝不要做某事”条款的那些——位于上下文的最顶端。它的权威在那里是最强的。随着对话的进行，成千上万个 token 的用户轮次、工具输出和检索到的文档会堆叠在它之上。模型的注意力机制并不会平等地衡量所有这些 token。最接近生成点的指令在权重竞争中胜出。到了第四十轮，你的护栏并没有消失，但它们被埋没了。一个耐心的对手不需要聪明的越狱手段就能绕过它们，他们只需要一个足够长的对话。

这不是假设。这是 Transformer 处理长上下文时一种可衡量的属性，在研究文献中它有专门的名称，即使你的事故审查模板中还没有。

每个构建 AI 产品的团队都会得出同样安逸的结论：“我们每天都在用它，效果非常好。”这句话听起来像是证据。但它不是。它是房间里最具误导性的信号，而且你的团队越优秀，这个信号就越强烈——更具说服力，也更错误。

“吃狗粮”（Dogfooding）只能告诉你产品在运行。它不能告诉你产品是否奏效。这是两个不同的命题，而它们之间的差距正是你产品发布出问题的地方。从统计学上讲，构建系统的人是所有可能用户中最糟糕的样本。他们共享系统的心理模型，知道它的薄弱环节，并且已经花了几个月时间训练自己，用模型喜欢的方式来组织请求。这根本不是测试人群。这是你从未开展过的一项研究的对照组。

你发布了一个模型升级。评估套件的分数从 87% 提升到了 91%。更新日志信手拈来，领导层纷纷鼓掌，然而那些真正重要的仪表盘——用户满意度、工单升级率、点踩率——却毫无动静。毫无起色。甚至可能略微变差了。

这是 AI 工程中最令人迷惑的失败模式之一，因为表面上没有任何东西坏掉。评估运行正常。数字是真实的。在你测试的 600 个示例中，模型确实有所改进。问题在于，这 600 个示例是你构建套件那一周的流量快照，而在那之后的几个月里，你的用户已经走出了画面。

每一个具有韧性的 LLM 设计在配置中都有一行代码指定了一个备选模型。它之所以存在，是因为有人在设计评审中提出了正确的问题——“如果主模型宕机了怎么办？”——而另一个人用一个 fallback: 键回答了这个问题。大家都点头表示赞同。架构图上多了一个带有虚线箭头的第二个框。合规文档中也增加了一句关于优雅降级的描述。

然后，再也没有人碰过它。

备选模型是大多数生产环境 AI 系统中被断言得最自信、但演练最少的组件。它被命名、被记录、被画在图中——而在它真正承载流量的那一天，也是它第一次遇到真实请求的一天。你并没有建立安全网。你只是构建了第二个断裂强度未知的模型，而你将在最糟糕的时刻发现那个极限。

每个成熟的 AI 系统都会配备回退方案（fallback）。当主模型被限流时，路由到更廉价的模型。当服务商返回 5xx 错误时，提供缓存的答案。当置信度低于阈值时，回退到手写的启发式规则（heuristic）。架构图中有一个清晰的小分支，标注为“降级模式”（degraded mode），每个人都因此感到更安全。

令人不安的部分在于：那个分支是系统中几乎从未运行过的唯一代码。主路径每天执行数百万次，并经过大量流量的调试、性能分析和实战测试。回退路径几乎从不执行——直到某天，它在负载下、在事故期间、在三名工程师看着仪表盘变红时，突然为所有人同时执行。

一个你不练习的回退方案并不是冗余。它是一个不受监控的第二系统，其“首秀”在统计学上注定会发生在最糟糕的时刻。

看看大多数智能体（Agent）评测集是从哪里来的。有人构建了智能体，向团队演示，演示成功了，于是演示脚本就变成了评测套件。那些通过评审的案例，正是有人已经亲眼看到它们运行成功的案例。评测集在构建之初，几乎就是“快乐路径”（Happy path）的录音——即在截屏当天成功运行的那一段工具调用序列。

所以，当仪表盘显示智能体得分为 94% 时，它实际上是在说：它通过了我们能想象到的案例。它完全没有提及搜索 API 在多步计划中途返回 429 错误的情况，或者用户推翻了两轮前设定的约束的情况，亦或是检索结果为空，智能体必须在胡乱猜测和承认不知道之间做出选择的情况。这些情况并非没有通过你的评测。它们压根就没在评测里。

这就是黄金路径偏见（Golden-path bias），除非你刻意对抗，否则它就是智能体评测套件的默认形态。解决方法不是增加案例数量，而是增加不同种类的案例——这些案例应根据失败模式（Failure mode）来选择，从生产环境中收集，并针对刻意引入的故障进行压力测试。

内部 API 依赖于一种默契而存在：没人会写下契约，因为每个人都已经心知肚明。那些碰巧存在的字段、调用者在暗地里解析的报错、返回空列表而非 404 的 200 响应 —— 这些都是关键的承重行为。而维系这些行为的基础是，你可以叫出每个调用者的名字，并在做出任何更改之前通过 Slack 联系他们。这种安排一直有效，直到它失效的那天。

当你将一个智能体（Agent）连接到该 API 的那天起，这种默契就失效了。这并非因为智能体怀有恶意或粗心大意，而是因为智能体是一个你无法触及的调用者。它没有 Slack 账号。它没有阅读你的迁移说明。它依赖于从示例载荷或 Schema 快照中吸收的响应形态，并且在你早已更新版本后，它仍会长期依赖这些形态。

一个令人不安的事实是，“内部”从未是 API 本身的属性。它其实是调用者列表的属性。将列表缩减到你认识的人，API 就是内部的；一旦增加一个你无法协调的参与者，API 就是公共的 —— 这意味着你需要承担“公共”一词所暗示的所有严谨规范，尽管你并没有构建任何本应具备的基础设施。

观察某人第一次使用聊天产品时，你会发现他们在模型完成输出之前就开始阅读了。这种“边出边读”的行为正是流式传输（streaming）存在的全部意义：它将数秒的等待转变为一种对话般的感觉。然而，这也是你的输出防护栏（guardrails）悄然失效的原因。

这是一个令人尴尬的过程。模型生成了第 1 个 Token、第 2 个 Token、直到第 150 个。每一个 Token 在到达时都会立即渲染。到第 200 个 Token 时，模型产生了一个虚假的用药剂量、泄露了一个电子邮件地址，或者生成了一句违反内容政策的话。你的输出侧防护栏正确且立即触发了。但“立即”已经太晚了——用户已经阅读了前 200 个 Token。你无法撤销渲染。防护栏履行了职责，但违规内容仍然传达给了人类。

你的团队启用模式约束解码（schema-constrained decoding）的那一天感觉像是一个里程碑。解析错误停止了。JSONDecodeError 警报消失了。从文本中抓取字段的脆弱正则表达式也被删除了。有人在站会上说“模型现在返回有效的 JSON 了”，结构化输出的任务单随之关闭。

那句话正是麻烦的开始。“模型现在返回有效的 JSON 了”是正确性工作的开始，而不是结束。JSON 模式和约束解码保证了响应的形状（shape）——即 quantity 是一个整数，status 是三个枚举值之一，对象包含你要求的键。它们完全无法保证 quantity 是否是正确的数字，status 是否反映了真实发生的情况，或者 sku 字段是否指向了目录中存在的商品。