861 篇博文 含有标签「insider」

你的智能体平台连续一年每季度都达到了 99.9% 的“响应成功率”SLO。但工单量增加了 40%。受智能体引导的用户群体的留存率却在下降。轮值运维感到无聊，产品经理在恐慌，而管理层评审一直在问，为什么仪表盘显示一切正常，而支持队列却显示情况一团糟。仪表盘没有撒谎。它只是衡量了错误的东西 —— 因为编写 SLO 的 SRE 将成功定义为“模型 API 返回了 200”，而这正是遥测系统最初唯一能表达的成功定义。

这是智能体可靠性工程的核心问题：成功的信号不是状态码。它是一种关于智能体是否针对特定任务做了正确事情的判断，而这种判断在请求时是无法获得的，通常在会话时也无法获得，有时只有在几天后，当用户提交工单、修改输出或悄无声息地流失时，才能揭晓。你无法在一个尚不存在的列上标记“200 对比 500”的布尔值。

常见的反应是等待获得基准真相（ground truth）后再宣布 SLO。这是错误的。可靠性工作不会在你构建标注流水线时暂停。正确的做法是针对你明知不完美的代理指标（proxies）编写错误预算，将它们命名为代理指标，设定团队在指标触发时的响应策略，并在产生基准真相后将其回填到计算中。这篇文章将探讨如何在不自欺欺人的情况下做到这一点。

仪表盘显示 p95 的 agent.run = 28s。用户反馈该功能感觉已经挂了。值班工程师打开 Trace（追踪），看到一个没有任何值得调查的子节点的“肥大”长条，然后开始盲猜。当有人重建出足够的心理模型，搞清楚瓶颈到底是模型、检索器，还是某个没人添加 Span 的工具调用时，故障已经变成了积压的任务单，而用户早已放弃了。

这就是 2026 年 Agent 运营核心的失败模式：传统的 APM 将 Agent 步骤视为一个黑盒，而“Agent 延迟”并不是一个单一指标——它是七个指标的总和，这些指标根据 Agent 在该轮次中的决策，以不同的方式分解实际用时 (Wall-clock time)。如果一个团队不暴露这七个数字，他们交付的功能虽然大家都能感觉到慢，但谁也无法修复。

用户点击了智能体操作的“撤销”按钮，而该操作之前已经分发（fan out）到了十二个工具调用中。智能体发送了两封电子邮件，创建了一个日历邀请，更新了一条 CRM 记录，扣除了信用卡费用，并在 Slack 频道中发布了消息。其中三个操作通过 API 是不可逆的。两个操作只能通过触发自身下游通知的反向操作来撤销。剩下的七个操作各自都有自己的幂等性（idempotency）定义，而规划器从未协调过这些定义。你发布的撤销按钮看起来令人安心，它大约 60 % 的时间静默成功，其余时间则静默失败。

这不是一个 UX（用户体验）漏洞。这是一个 Saga 模式问题，分布式系统工程师已经研究了三十年，而忽略这段历史是发现它最昂贵的方式。

无状态的聊天补全（Stateless chat completion）耗电量极低。一次中等规模的 Gemini 文本提示耗电约为 0.24 Wh；一次简短的 GPT-4o 查询约为 0.3–0.4 Wh。这些数字微乎其微，甚至没人会把它们放进董事会演示文稿里。

智能体任务（Agent task）并非普通的聊天补全。一个典型的“研究该客户并起草回复”的工作流可以扇出（Fan out）到 30 多个工具调用、10–15 次模型调用，且上下文窗口随着每一步不断增长。能源成本随调用图（Call graph）呈复合增长。当智能体返回结果时，你消耗的不是一个推理单元，而是五十到两百个。突然之间，每个任务的碳足迹便与视频流达到了同一数量级。

这种算术题很快就会在工程部门之外产生影响。欧盟的 CSRD 使范围 3（Scope 3）排放披露成为受规制公司的强制要求，并要求从 2026 年起提交机器可读的 iXBRL 报告。尽管 SEC 在其最终规则中删除了范围 3，但任何在欧盟有业务的跨国公司仍然必须回答这个问题。采购团队已经开始在供应商调查问卷中加入“你的 AI 功能每个用户任务的碳足迹是多少？”这类问题。大多数工程团队无法回答，因为从来没有人测量（Instrumented）过它。

一个编程智能体在凌晨 2 点合并了一项变更，导致客户的生产数据库下线了 90 分钟。一个客户服务智能体在循环被终止前，向外发送了 1.4 万封措辞错误的退款拒绝邮件。一个自主对账工作流对 2800 张卡进行了重复扣款。损失是真实的，审计追踪指向了你的公司，你的财务团队针对六周前续签的网络保险保单提出了理赔。保险公司的回复是一封礼貌的信函，解释说该保单涵盖的是“恶意第三方的未经授权访问”和“对员工的社交工程攻击”——而该智能体是经过身份验证的，其行为是经过授权的，且没有员工被欺骗。理赔被拒。损失只能由你的资产负债表承担。

这并非假设性的极端案例。它是未来 18 个月内最典型的理赔画像，保险业深知这一点。网络保险（Cyber）、职业责任险（E&O）和董事高管责任险（D&O）的保单条款是根据一种威胁模型校准的，在该模型中，泄露的严重程度取决于记录外泄的数量，而事故响应则取决于计费的取证小时数。智能体 AI（Agentic AI）产生的事故并非这种形态。它产生的是一种精算师没有任何基准数据可参考的形态，而保险公司在缺乏精算基准时的第一反应，就是将这种风险敞口完全排除在保单之外。

2025 年 8 月，当 OpenAI 试图从 ChatGPT 中移除 GPT-4o 时，遭遇了强烈的抵制——有组织的标签、付费用户威胁取消订阅、几天内的公开反转——最终迫使公司将其恢复为默认选项，并承诺在未来任何移除之前提供“实质性通知”。替换它的模型在团队关注的每一项基准测试中都表现得更好。但这并不重要。用户已经花了几个月的时间来了解该模型的怪癖，根据其失效模式校准自己的判断，并将它的特定措辞整合进团队从未检测过的工作流中。用“更好的版本”替换它，会让这种校准归零。

这种失效模式是标准的弃用策略手册所未涵盖的。下线一个常规的 SaaS 功能——宣布、迁移、灰度发布移除、退役——假设用户契约是 API 接口。而对于 AI 功能，契约是模型的观察行为：措辞、倾向、失效模式，以及它处理歧义的特定方式。用户在这些行为之上构建了“脚手架”，而这些脚手架大多存在于他们的头脑中、笔记本电脑上以及你的团队从未触及的下游系统中。

我认识的一个团队花了六个月的时间，在他们标准的资深工程师面试流程中额外增加了一个“AI 环节”。他们面试了 70 名候选人，录用了 3 名。但这三个人中，没有一个交付的 Agent 能在生产环境平稳度过一个周末。团队将此归咎于人才市场。但人才市场没问题，问题出在面试流程。

标准的工程面试是为这样一套技术栈校准的：正确性可验证，性能可通过基准测试衡量，优秀的工程师是那些能将问题分解为确定性组件，并根据已知规范推导边缘情况的人。那套技术栈依然存在，那些技能依然重要，但预测交付 LLM 产品能力的技能群与此基本是正交的。你的流程是在为错误的职位询问正确的问题。

这是一个结构性问题，而非校准上的微调。在为确定性系统设计的流程中加入 45 分钟的“AI 环节”，并不能筛出 AI 开发者——它筛出的是既擅长经典系统又精通 LLM 的候选人交集，这是一个极其微小的群体。这导致了长达六个月的失败招聘，而大家还在纳闷 AI 工程师都去哪儿了。

你账单中最便宜的推理费用，是那些你付了两次的钱。几乎所有主流模型提供商现在都提供批处理层（batch tier），价格大约只有同步推理的一半，代价是接受以小时而非毫秒计的完成窗口。大多数工程团队要么完全忽视这一选项，要么只是随手扔进一个深夜定时任务（cron），然后宣称省下了钱。这两种做法都白白浪费了 30%–50% 的推理总支出——并非因为折扣不够大，而是因为批处理并不是一种代金券。它是一个全新的产品层面，拥有自己的 SLA、重试语义和失败模式。那些仅将其视为计费优化的团队，最终要么使用率低下，要么上线了需要数周才能排查出来的细微回归问题。

技术核心不在于“我们是否应该使用批处理？”，而在于：你系统中的哪些动作在用户感知层面确实是同步的，哪些是工程团队为了开发体验方便而“误当成”同步的，以及哪些可以在下游消费者不预设结果实时性的前提下重新塑造为任务（jobs）。回答这个问题需要进行工作负载审计、从“请求型（request-shaped）”到“任务型（job-shaped）”契约的架构转变，以及根据用户预期而非开发便利性，对每个智能体动作进行延迟层级的诚实映射。

用户点击“停止”，因为智能体（agent）误解了请求。UI 界面闪烁着“已停止”。在加载图标消失时，智能体已经发送了两封邮件，在你的日历上安排了周二的会议，针对错误的分支开启了一个草稿拉取请求（pull request），并排队发送了一条正在通过工具层追赶取消信号的 Slack 消息。模型已经听话地停止了生成 token。但外部世界并未停止对它三十秒前生成的 token 做出反应。

这是智能体演示中没人提及的失败模式。同步代码中的取消操作本身就是一个难题，背后有一整代协作式取消理论的支持：Go contexts、Python 的 asyncio.cancel、带有任务组的结构化并发，以及“礼貌请求、谨慎升级、不留资源”的整套语法。智能体在这个本就困难的问题上又增加了一层复杂性：规划器不知道用户在第 4 步和第 5 步之间撤回了授权，而它在第 4 步启动的工具在第 5 步被取消时也不会收到通知。“停止”只是一个 UI 交互功能。其背后的系统必须经过专门设计。

针对 Agent 类产品，生产环境下最常见的投诉通常是某种形式的“它忘记了我们刚才说的话”。这种投诉往往出现在第 8 轮、第 15 轮或第 30 轮——绝不会在第 2 轮出现。团队的第一反应往往如出一辙：扩大上下文窗口。但这其实是错误的直觉，因为 Bug 不在模型本身，而在于团队将对话历史视为了终端的滚动回放（scrollback）——追加一行、渲染尾部、满了就截断。实际上，他们不知不觉中构建的是一个读多写少的数据库，具有仅追加写入、热工作集、隐藏在截断规则中的淘汰策略，以及取决于所提问题类型的查询模式。一旦你接受了这一点，整个问题的本质就改变了。

滚动回放模式之所以如此诱人，是因为聊天界面看起来就像一份对话记录。消息向下流动，用户自上而下阅读，而喂给模型的自然方式就是将最新的 N 轮对话拼接到提示词中。这种数据结构感觉是“免费”的：没有 Schema，没有索引，没有查询——只需追加、渲染、重复。在最初的几轮对话中，任何架构都表现良好。模型拥有完整的上下文，费用低廉，演示效果极佳。

关于编程智能体（coding agents）的讨论总是陷入二元对立：自主还是受监督，YOLO 模式还是手握方向盘，--dangerously-skip-permissions 还是“批准每一次按键”。这种构想框架本身就是一个范畴错误。编程智能体执行的并非“一个动作”，而是一系列动作，其成本跨越了至少七个数量级 —— 从读取文件（免费、可撤销、无副作用）到合并至主分支（不通过 revert PR 则不可逆），再到向集群发布二进制文件（六位数成本级别的事故）。用一个自主性开关来处理如此广泛的范围，就像是为停车场和高速公路设置统一的限速一样。

如果团队在发布“无所不能的智能体”时，没有将每个动作映射到其爆炸半径（blast radius），那么只需一个带有提示词注入风险的 GitHub 评论，就足以引发一场事后复盘 —— 事实上，我们已经有了这种失败模式的公开案例。Anthropic 的 Claude Code 安全审查、Google 的 Gemini CLI Action 以及 GitHub Copilot Agent 在 2026 年都被证实可以通过精心设计的 PR 标题和 issue 正文被劫持，研究人员将这种攻击模式命名为“评论并控制”（Comment and Control）。这些智能体并非在抽象意义上损坏了，而是因为自主性层级悄无声息地将低信任输入抹平为“一视同仁”，从而基于这些输入执行了高阶动作（如推送代码、开启 PR）。

接下来需要建立的规范是：针对每个动作的曲线、随层级扩展的闸门、与爆炸等级匹配的回滚速度，以及一个测试工具组合升级而非单一动作失败的评估程序。

每个 LLM 团队最终都会收到主管发来的同一封邮件：“Anthropic 发布了新的 Sonnet。用我们的流量跑一下测试，周五前告诉我是否应该切换。”团队打开生产环境的追踪（trace）存储，调取上个月的请求，并针对新模型排队运行——但在运行三小时后，有人发现工具调用环节的差异评分看起来非常离谱。答案是：没有人以原始形式捕捉工具的响应。追踪记录忠实地记录了模型的“回复”，并存储了每个工具返回内容的一行摘要。回放这些请求并不能回放旧模型实际看到的内容；它回放的是一段被严重压缩的投射。迁移评估并不是在衡量新模型，而是在衡量新模型如何与一个不同的现实对话。

这就是我想讨论的失败模式。大多数生产环境的 LLM 日志都是“以输出为导向”的：它们能很好地回答“模型说了什么？”，但只能模糊地回答“模型看到了什么？”。这种不对称性在你需要针对新模型回放历史数据之前是隐形的——到那时，它就成了整个问题的关键，因为日志记录与实际发送内容之间的差距，正是真实评估与虚假评估之间的差距。

称之为反事实日志（counterfactual logging）：今天就捕捉那些你明天询问“如果用另一个模型处理这个完全相同的请求，它会做什么？”时所需的输入。标准不是“我们记录了请求”，而是“我们可以针对不同的模型重新执行该请求，并确信结果是有意义的”。