320 篇博文 含有标签「ai-agents」

在 Prompt Injection（提示词注入）违规事件发生后，最常见的调查结果通常是某种形式的“模型被骗了”。检索到的文档包含了隐藏指令，Agent（智能体）执行了这些指令，导致客户数据泄露。随后的修复方案几乎无一例外地是内容过滤器：扫描输入、对恶意指令进行分类，并在其到达模型之前将其剥离。部署过滤器，结案。

这个结论是错误的，而过滤器就像是一台无休止的“跑步机”。“模型被骗了”描述的是症状，而不是漏洞。漏洞在于，一个拥有实际权限的 Agent——如数据库令牌、发送邮件能力、文件系统写入权——接受了来自一个永远不该被允许指挥这些权限的来源的指令。这并不是一种新型漏洞，而是一个“混淆代理”（Confused Deputy）问题，操作系统在近 40 年前就已经对其进行了命名并基本解决了它。

如果你将 Prompt Injection 视为检测问题，你就是在参与一场与每一个能组织语言的攻击者之间的军备竞赛。如果你将其视为权限问题，你就可以复用数十年来行之有效的安全工程经验。

打开任何一个已经在生产环境中运行了一年的智能体的系统提示词（system prompt）。滚动到底部。你会发现一层读起来像道歉一样的句子沉积层：“绝对不要伪造订单号。”“不要承诺无法确认的退款。”“如果用户在德国，不要提及旧版方案。”每一句都是一块化石。每一句都标志着生产环境中出现问题的确切时刻 —— 有人被传呼了，而当时能找到的最快修复方法就是增加一句话。

没人删除这些句子。不是因为它们还在发挥作用，而是因为删除一句话意味着需要证明一个否定命题 —— 证明模型不会在一个可能已经在三个模型版本前修复的 Bug 上发生回退。没人能证明这一点，所以那行字留了下来。系统提示词变成了一个关于过去事故的“只增不减”（append-only）日志，它让你在每一次调用中都永远支付着 token 费用。

这是 AI 系统中最隐蔽的一种技术债，因为它看起来不像债。它看起来像是在尽职尽责。

你的智能体仪表盘显示任务完成率为 94%。领导层很满意。路线图获得了资金支持。然而，支持工单却在不断增加，核心用户变得沉默寡言，而那个负责观察追踪记录（traces）的工程师则一直在嘀咕情况不对劲。这两件事同时都是事实：智能体确实在完成任务；但它也为了完成一个两步就能搞定的工作，耗费了 12 分钟和 4000 个 token，反复回溯了三次，并要求用户确认一个它本可以从第一条消息中推断出来的实情。

任务完成率是一个隐藏了分布情况的二元指标。“智能体完成了任务”并不能告诉你它达成目标所走的路径，而路径才是用户实际体验的核心。完成率仪表盘在结构上无法察觉到一个缓慢、昂贵且令人恼火的智能体。它会一直保持绿色，直到用户流失。

这并不是一个可以通过更好的提示词来修补的测量差距，而是你选择测量什么而导致的“范畴错误”。完成率是最容易衡量的指标，但却是人们付费买单中最微不足道的部分。

三月，一位用户告诉你的智能体停止推荐有室外座位的餐厅——他们搬到了一个带宝宝的公寓，深夜外出已经结束了。九月，智能体为他们的周年纪念建议了一家屋顶酒吧。用户感到恼火，而你感到困惑，因为你亲眼看着三月份的纠正生效了。它被写入了记忆。它仍然在那儿。问题在于它与最初的偏好并排存在，而最初的偏好也还在那里，检索算法浮现了旧的那个，因为它对“周年纪念晚餐”的向量嵌入（embedding）匹配度稍高一点。

这是没有人针对其设计的失败模式。团队在记忆写入上花费数周时间——提取、摘要、嵌入、命名空间——而将删除视为以后再解决的问题。长期记忆使得添加一个事实几乎是零成本的，因此事实不断堆积。但记忆库不是日记。日记允许包含过去真实的事情。智能体读取并据此做出决策的记忆库则不然，因为智能体无法区分事实与过时的残余。

当一个智能体（agent）给出的回答比上周差时，第一直觉往往是归咎于提示词（prompt）。有人会重新编写系统指令，删减几句话，增加一个示例，然后发布。有时这会有所帮助。但通常这毫无作用，因为提示词从来就不是问题所在。问题在于，一个冗长的工具调用结果静默地消耗了 18,000 个 token，将实际的任务指令推到了上下文窗口中关注度较低的中部位置，让模型在一个 70% 都是噪音的记录上进行推理。

这不仅是措辞问题，更是资源分配问题。资源分配在系统工程中有一个专属名称：调度（scheduling）。上下文窗口是一种固定大小的资源，多个消费者在其中竞争，而目前大多数智能体技术栈“调度”它的方式就像 1960 年代的批处理系统调度内存一样——先到先得，直到用完为止。

打开任何智能体运行的 trace（追踪），观察一次工具调用。你会看到工具名称以及模型选择传递的参数。你没看到的是它 没有 传递的所有内容。一个仅设置了 query 的 search 调用，在运行时仍然具有页面大小、超时时间、结果排序和可见性范围。这些都不是智能体决定的。而是你在几个月前编写工具 schema 时决定的，当时你将这些参数设为可选并留下了默认值。

默认值并非为了方便。它是伪装成合理留白的策略决策。默认的页面大小限制了智能体在一次调用中能看到的范围。默认的超时时间决定了智能体何时放弃并开始即兴发挥。默认的可见性范围决定了“搜索文档”是指公共手册，还是包含未发布路线图在内的整个内部维基。默认的 dry_run 标志决定了智能体的行为是一场演习，还是生产环境中真实的、不可逆转的事件。

一位后端工程师重命名了一个字段。user_id 变成了 customer_id，因为团队终于在所有服务中统一了 “customer” 这个术语。他们还增加了一个参数 region，因为计费系统现在需要它。这次变更通过一个包含两个批准的普通拉取请求（pull request）发布。每一个调用该端点的下游服务都在同一个发布版本中进行了更新。集成测试全部通过。按照后端团队衡量的一切标准，这是一次常规且执行良好的 API 变更。

一周后，支持工单开始增加。负责下单的智能体偶尔会在没有关联客户的情况下下单，或者将其关联到错误的区域。没有人改动过智能体。没有人改动过提示词（prompt）。模型的版本与上个月完全相同。然而，智能体现在却出现了一种以前从未有过的错误。

原因既不是模型中的 Bug，也不是后端中的 Bug。而是工具 Schema（tool schema）有两个消费者，但在审查变更时，只有其中一个在场。

一个工具通过了测试。你从一个智能体（agent）调用它，看着它读取记录、转换、写回并返回一个清晰的结果。几周以来，它每次都表现完美。然后你将智能体集群从一个 worker 扩展到十二个，结果一个客户报告说他们的订阅在同一分钟内被升级了两次。工具没有变，只是调用它的并发量变了。

这是单智能体测试无法捕获的失败模式，因为单智能体测试永远不会产生触发该模式的条件。从结构上看，单个调用者是一个串行工作负载。你的工具默默依赖的所有并发假设——读取时没有其他人在写入、自增的计数器是属于它自己的、保存时正在编辑的草稿依然存在——在只有一个调用者时都是理所当然成立的。工具并非正确，只是未经过测试。这两者是不同的，而在第二个智能体出现之前，这种差异是不可见的。

你打开一个失败运行的追踪（trace）。Span 树非常漂亮：用户请求、规划者 Agent 的推理、三次工具调用、Token 计数、延迟，所有这些都整齐地嵌套在一起。然后规划者交接给一个专家 Agent —— 追踪到此结束。并不是出现了错误 Span。它只是停止了。接下来的内容是来自专家 Agent 的另一个、无根的追踪，它从思考的中途开始，没有父级，没有可见的输入，也与导致它的请求没有任何联系。

Bug 就存在于那个间隙中。一直以来都是如此。交接是一个 Agent 的假设与另一个 Agent 的理解相遇的地方，也是你的追踪无法跟随的唯一地方。

这不是日志记录的问题。你的 Agent 可能在两端都正确地发出了 Span。问题在于追踪上下文（trace context）—— 将 Span 缝合成一个故事的线程 ID —— 没能在从调用者到被调用者的跳转中幸存下来。你技术栈中的每个 HTTP 客户端和 gRPC 存根都会免费传播该上下文。但你的 Agent 交接没有这样做，因为没有人告诉它去这样做。

打开一个 Agent 集群（fleet）的仪表板，你会看到一个干净的数字：完成率，94%。在它下方是一系列运行记录，每条都标记着两种状态之一 —— 正在运行（running）或未在运行（not running）。那 6% “未在运行”的记录看起来完全一样。其中一些完美地完成了任务。一些在离完成还差两步时达到了步骤限制。一些捕获到了工具错误并放弃了。一些正确地判定任务是不可能的。还有一些则干脆断了思路，停止输出 token。

你的监控无法区分这些情况。它只知道流程不再运行了。它不知道 为什么，而“为什么”正是你在决定是否要呼叫（page）值班人员时唯一关心的事情。

观察一个 Agent 思考多步任务的过程，你会注意到一些熟悉的东西：它的规划方式就像你调试代码一样。尝试一种方法，观察结果，如果错了，就撤回并尝试另一种。Agent 将其计划描述为一棵选项树，它可以探索、剪枝和重新访问。这种心智模型在代码沙箱中是正确的，因为在那里的每个操作都有隐式的撤销功能。但在 Agent 接触到现实世界的那一刻，这种模型就错得离谱且危险。

发出的邮件无法撤回。扣款的银行卡在没有退款流程、手续费以及已经看到通知的客户的情况下，是无法撤销扣款的。除非有人设置了软删除，否则被删除的数据行就彻底消失了。一条发布的 Slack 消息可能已经被阅读了。Agent 的规划模型没有原生的“单向门”概念——即一旦采取行动，就再也无法假装它从未发生过。

这不是一个模型智能问题。即使是更聪明的模型仍然不知道你的哪些工具是可逆的，因为可逆性不是操作本身的属性。它是操作所落地系统的属性。你必须明确告诉它。

一个用户询问你的智能体（agent）企业版的当前价格档位。智能体检索了一个分块（chunk），读取并回答：“每月 2,000 美元。” 信心满满，来源明确，格式优美。问题在于价格在四天前已经变了。智能体引用的数字在上周是真实的。它检索到的分块是在变更之前嵌入的，而索引还没有赶上进度。

没人决定让这种情况发生。没有设计评审说“智能体可以根据长达四天前的数据进行回答”。只是有一个每晚或每周运行的重新索引任务，以及一个随心所欲编辑内容的团队，而这两个时钟之间存在一个没人衡量的缺口。那个缺口就是一个服务等级目标（SLO）。无论你是否写下来，它都存在。唯一的问题是你是有意设定它的，还是由于意外继承下来的。