209 篇博文 含有标签「agents」

凌晨 3 点 17 分,一个不稳定测试被隔离了。On-call 轮值没有被叫醒,因为根本没东西失败——Agent 判定这次失败是噪声,自动开了一个标题为 chore: quarantine flaky test 的小 PR,用 ci-bot 这个 service account 把它 self-merge 了,然后继续盯着队列。六天之后,一个用户来反馈说某个功能从周二开始就坏了。那个测试不是 flaky,它是把一个真实回归挡在生产之外的唯一防线,而 Agent 那个 confidence threshold 设得刚好高到敢做决定,又刚好低到会判断错。

这是 agentic CI 中市场材料从不提及的那部分。在 2026 年,把 Agent 接进 pipeline 让它分流失败、对安全告警做依赖降级、提出依赖升级,在工程上其实很简单——工具齐了、集成只差一个 config 文件、生产力故事也是真的。没人写 runbook 的部分,是你刚刚引入的那一类新的操作主体:一个在凌晨 3 点没有任何人类同步在环、却拥有合并权限的角色,而你的 SRE 手册当初就是默认人类才是意图的来源。

用户正在阅读 Agent 流式输出的推理过程。在 token 1200 附近,模型决定调用 send_email,然后 create_ticket,再 kick_off_deploy。用户看到部分输出并意识到 Agent 误解了请求,在停止按钮上慢了半秒。邮件已经发出,工单已经创建,部署已经在跑。停止按钮取消的是下一个 token,而非上一个 token 的后果。

Bug 不在取消处理程序里。Bug 是那个假设——从团队路线图上所有其他流式 UI 借来的假设——即"逐步渲染的输出"就是"逐步可逆的输出"。工具调用并不遵守这个契约。它们是时间点上的提交,流式层一边欢快地触发它们,响应的其余部分还在生成中,而取消按钮无法沿着线路追赶它们。

这是那种没人认领的失败模式,因为它存在于两个团队各自干净交付的接缝处。UX 团队上线了流式,因为用户研究中表现更好;平台团队上线了工具调用,因为框架支持。两个团队都没有开过会问:当响应已经离开大楼时,"停止"应该是什么意思?

合规部门给你转发了一张工单。三周前，一名客户的退款请求被你的支持代理拒绝了，他们发起了申诉，现在需要有人解释这一决定。你对此感到很淡定，因为你记录了一切。每一次提示词、每一次工具调用、每一段检索到的内容、每一个 Token 计数、每一项延迟数据——所有这些都在追踪记录（trace）中，你可以在几秒钟内调出它们。

你调出了记录。你可以看到代理收到了退款请求。你可以看到它调用了 get_order_history，接着是 check_return_window，然后是 lookup_policy。你可以看到它检索到的确切政策文本。你可以看到它发送的最后一条消息：拒绝退款。追踪记录是完整的。每一个 span 都是绿色的。但你仍然无法回答那个问题，因为追踪记录显示代理拒绝了退款，并向你展示了它查看过的所有内容，但它没有向你展示为什么这些输入叠加在一起的结果是“不”。原因存在于模型如何权衡上下文，而这种权衡从未成为一种产物（artifact）。它从未在任何地方被记录下来。

这就是追踪记录与解释（explanation）之间的差距，几乎所有声称“我们拥有完全可观测性”的团队都还没有意识到，他们只构建了前半部分。

模型已经向用户屏幕推送了 70% 听起来很自信的回答。接着，它即将进行的工具调用返回了错误、无结果或 429 错误。现在你必须在两种损失之间做出选择：让模型通过编造剩余部分来优雅地结束，或者在句子中间戛然而止，且没有体面的方式撤回。这两种都不是修复 —— 它们都是损害。

这是流式传输 UX 中没人考虑过成本的部分。流式传输被描绘成一种感知延迟的胜利：首个 Token 时间 (TTFT) 是核心指标，用户更早开始阅读，应用显得充满活力。但这种描绘忽略了你推送的每一个 Token 都是一种承诺。你发布了一个你还不知道是否正确的答案草稿，而你系统的后半部分还没有运行完毕。当它运行结束并产生分歧时，你的 UI 没有原生方法来撤回已经显示的内容。

你的运营 Agent 通过引用一条内容为 “我们明天发版” 的 Slack 消息，回答了一个关于即将到来的发布会的问题。Agent 将其视为当前的计划，并开始撰写沟通稿。然而，这条消息是六周前发布的。发版早就完成了。检索流水线（retrieval pipeline）根据你衡量的每一项指标——与 “发布日期” 的语义相似度、高于阈值的 top-1 置信度、与项目匹配的来源频道——抓取到了正确的文本块（chunk），而 Agent 基于一句仅在编写时的会议语境下才有意义的话制定了计划。

这里的 Bug 不在模型本身。Bug 在于，“明天” 并不是一个日期。它是一个指向时钟的指针，而该消息编写时的时钟并不是 Agent 阅读时的时钟。你的检索流水线索引了消息的正文，却丢弃了其框架（frame）。

你让智能体修复一个不稳定的测试。第三分钟，测试通过了。第四分钟，智能体正在读取相邻文件。第九分钟，它“改进”了一个测试从未触及的辅助函数，为了清晰起见重命名了一个无关的参数，并开始对 fixture 构建器进行重构。最终提交的 diff 涉及 12 个文件和 400 行代码。原始 Bug 修复了，一些原本没坏的代码也顺便被“修复”了。

这不是模型感到困惑，而是模型完全按照指令留下的空间在行事。任务要求“修复 Bug”，但并没说“修复后就停止”。大多数智能体循环都有明确的起点和成功标准，但对第三个问题却含糊其辞：你什么时候结束？在聊天会话中，“结束”是由用户决定的。在自主循环中，“结束”是由停止条件决定的，如果你没写停止条件，那停止条件就是“模型失去了兴趣”。这不属于你可以调试的故障模式，而是一种你必须通过设计来消除的故障模式。

每天，你的智能体（Agent）都会把失败案例打包成“礼物”发还给你。一名用户点击了“踩”。另一名用户读完答案后一言不发，直接关掉了标签页。第三名用户将同一个问题改写了三次，直到智能体终于答对。每一个都是带标签的失败案例 —— 真实的输入、真实的上下文、系统失误的真实时刻 —— 由那些最希望系统运行正常的人免费提供给你。

大多数团队都会把这些信息全部丢掉。并非故意为之。点击“踩”只是增加了仪表盘上的一个计数；放弃使用表现为留存图表中的一次下滑；改写问题看起来就像普通的日常使用。没有任何东西能将信号及其产生的上下文一并捕捉，因此也就无法进行回放、分选（Triage）或转化为测试用例。你所拥有的最丰富的评估数据源正擦肩而过，而团队却还在继续手动编写合成的评估（Eval）案例。

这就是你从未构建的智能体反馈循环。它不是你忘记购买的某种工具，而是一条流水线 —— 从用户信号，到分选后的失败案例，再到新的评估案例 —— 它之所以未能建立，与技术本身关系不大。

财务部门对你发布的每个功能都会问一个问题：“每个用户的成本是多少？”对于传统功能，答案是一个数字。页面渲染、数据库查询、推送通知 —— 每一个的边际成本在不同请求之间几乎没有波动。你测量一次，乘以用户数量，预测就能成立。

AI 功能打破了这种契约。问一下“这个智能体（agent）每次请求的成本是多少”，坦诚的回答不是一个数字，而是一张直方图。同一个智能体，处理上一个工单可能只花 2 美分，但在处理下一个工单时可能会烧掉 4 美元。因为用户问了一个模糊的问题，智能体循环调用了 11 次工具，而每次调用都将不断增长的对话全文重新输入模型。这两次请求的平均值 —— 2 美元 —— 既无法描述其中任何一次请求，更无法真实反映最终账单。

这就是陷阱。当你向财务提交一个单一的平均成本时，你并不是在简化混乱的现实。你是在报告一个在特定的、昂贵的方向上完全错误的数字。

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

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

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

频率限制（Rate limit）过去曾是一个基础设施细节。当你遇到 429 错误，你会使用退避算法（backoff）重试，将溢出的请求排队，而 On-call 频道之外的人甚至根本不知道这回事。用户看到的响应只是比平时慢了几百毫秒。这就是故事的全部。

对于智能体（agentic）功能，这个故事不再适用。当一个智能体在执行多步计划的过程中，中途触及了供应商的每分钟 Token 数（TPM）上限时，失败并不会停留在基础设施层。它会表现为一个半成品的答案、一个在最后一次调用前卡住的工具循环，或者让用户盯着一个永远无法解决的加载动画。配额不再仅仅是后端容量数字，而变成了一个产品必须围绕其进行设计的约束条件 —— 就像产品围绕结账流程或空状态进行设计一样。

当安全团队审查一个新的工具集成时，他们会阅读代码。他们会检查函数的功能、它触及的内容、它需要的权限范围（scopes），以及它是否记录了敏感秘密。但他们几乎从不阅读那句决定模型是否调用该工具的句子——工具描述。那句话不仅仅是文档。它是模型视为权威的指令，而在大多数智能体堆栈中，没有人会去审计它。

工具描述是写给模型看的。模型利用它来决定工具何时相关、应该传递哪些参数，以及如何解释返回的结果。这使得描述成为了进入模型行为的一个控制通道。而当一个工具来自第三方注册表、一个你不运行的模型上下文协议（MCP）服务端，或者一个同事上周安装的插件时，这个控制通道的作者就是你从未同意信任的人。

这就是差距所在。输入净化（Input sanitization）检查用户输入的内容。代码审计（Code review）检查函数执行的内容。工具描述介于两者之间——它是表现得像输入的配置——它从这两个防护网中漏掉了。

一个工程师花了一个下午钻研一个问题：智能体 (agent) 能否根据合同条款核对客户的发票？他们编写了一个简单的提示词，在五份真实发票上运行，结果三份是正确的。另外两份的错误方式他们还没完全搞清楚——于是他们关上电脑，继续做别的事。在第二天早上的站会上，他们说：“是的，发票核对基本上能用了。”房间里的 PM 记下了这一点。两周后，它成了 Q3 路线图上的一个项目。一个月后，一位销售代表在续约电话中向一家大客户承诺了这项功能。

没有人撒谎。没有人孤立地做出错误决定。但团队现在已经在合同上承诺了一种行为，而这种行为的评估集 (eval set) 并不存在，其失败模式从未被记录，其可靠性预算是由一位看了演示并将其解读为正式合同的总监设定的。这是 AI 功能获取范围 (scope) 最常见的方式：不是通过规划会议，而是通过一个从未被明确提升地位的能力探索 (capability probe)。

行业对这种下游症状有一个称呼——“POC 炼狱” (POC purgatory)，即 70% 到 80% 的 AI 项目在可运行的沙盒和可交付的产品之间停滞不前的状态。但“炼狱”是一个错误的比喻，因为它暗示项目被困住了。它们并没有被困住。它们在移动——在有人检查它们是否准备好之前，它们就被承诺了，现在团队正试图将可靠性强行填补到一个承诺中。