一个被标记为“无状态”的工具是运行时无法兑现的承诺。在函数签名的背后，坐落着 Redis 缓存、向量索引、嵌入存储、限流表、记忆层、热路径上的 LRU——其中任何一个都是共享的基底层，一个用户的数据可能会落在另一个用户的响应中。函数是无状态的。系统则不然。在 2026 年，这是我在 Agent 系统中看到的最常见的隐私漏洞，因为几乎没有人对此进行测试。
对于任何开发过经典 Web 应用的人来说，这种漏洞的形式都熟悉得令人沮丧。不安全的直接对象引用（IDOR）曾是 Bug 赏金猎人们十年来的家常便饭：一个请求处理程序接收记录 ID 并返回记录，却不检查调用者是否有权查看。AI 时代的版本是同样的漏洞，但影响范围更广：一个工具调用接收查询并返回数据，却不检查调用者的租户是否拥有该数据。查询是用自然语言表达的。缓存键是一个哈希值。检索是近似的。这些都不能免除你的授权责任，但其中的每一项都让漏洞在代码审查中更难被发现。
上周二，某供应商在工具响应中将 "items" 更改为了 "results"。智能体没有崩溃。它围绕新结构重新进行了规划，返回了一个看起来很自信但丢失了三分之二行数据的答案，而轮值工程师在 3 天后因为客户询问导出数据为何缺失才发现。没有抛出异常。没有触发报警。运行在供应商变更前冻结的固定集（fixture）上的评测套件（eval suite）一直保持绿灯。
这种失败模式是十年前微服务中发明契约测试（contract testing）要捕捉的，而如今几乎没有智能体技术栈具备相应的对策。HTTP 服务有 Pact、schemathesis 和 oasdiff 位于消费者和提供者之间，拒绝让破坏性变更上线。你提供给智能体的工具——REST 端点、内部 RPC、供应商 SDK、MCP 服务器——都没有类似的保障。模型吸收了变化，优雅地进行了适应，并生成了一个看似正确但质量下降的答案。
单轮评估擅长一件事：在用户输入一次后便离开的任务中对模型进行排名。但对于你实际发布时会遇到的故障模式，它们毫无用处。比如在第三轮对话时就忘记用户目标的 Agent；在礼貌的重复询问下（“你确定吗？能再检查一下吗？”）就屈服并推翻正确答案的 Agent；或者在第四轮对话时还在问第二轮已经问过的澄清问题的 Agent，因为它读不懂自己的历史记录。这些问题都不会出现在对话仅进行一次交互就结束的基准测试中。
你可以进行真实用户评估，但每次发布都需要耗费数百小时的人工审查，而且问题往往在发布三周后才浮出水面。或者，你可以构建由 LLM 驱动的合成用户——具有人物角色 (Persona)、目标、耐心和放弃阈值的机器人——每晚针对待选 Agent 运行数千次对话。这是 τ-bench、AgentChangeBench 以及 2025–2026 年大多数生产级对话评估方案背后的方法。这种方法行之有效，直到它失效为止，而它失效的方式往往能让你更深刻地了解你的评估流水线，而不是合成用户本身。
2025 年 5 月 13 日，纽约南区的一位联邦地方法官签署了一项保护令，用一个词取代了一家消费级 AI 公司的保留政策：永远。OpenAI 被指示保留并隔离其 Free、Plus、Pro 和 Team 等所有层级的每一份输出日志——包括用户已明确删除的对话，以及隐私法原本要求删除的对话。到 11 月，同一法院下令将其中 2000 万份去标识化的转录文本作为抽样取证（sampled discovery）提供给《纽约时报》及其共同原告。这一无限期保留义务一直持续到当年的 9 月 26 日。在这五个月里，“删除”的实际含义是“保存在隔离的保险库中，供对方当事人日后查阅”。
该命令是对每一个基于 LLM 构建产品的团队发出的警告信号。如果你的产品存储了聊天记录，你的保留政策距离被法院认为合理的任何规定所取代，仅隔着一场潜在的诉讼。工程上的问题不在于这是否会发生在你身上，而在于你的存储架构是否能够承受这种变化，而不至于让你的产品变成法务部门的责任引擎。
电子邮件的保留手册无法直接套用。AI 对话包含的内容远多于用户输入的内容，而这“多出的部分”正是取证争端的开始。
大多数团队在发布智能体时，其威胁模型中都潜伏着一个沉默的假设：当模型调用工具时，返回的任何内容都是可以安全读取的。在这个剧本里，用户提示词是唯一的对手，而工具输出则被视为“仅仅是数据”——搜索结果、收件箱摘要、数据库行、RAG 分块、文件内容、网页抓取。正是这种观念导致提示词注入（prompt injection）不断出现在生产环境中。工具输出并不是数据。它们是进入规划器（planner）的另一个输入通道，拥有与用户提示词相同的权限，却完全没有被怀疑。
如果这种说法听起来有些抽象，请考虑 2025 年 6 月 Microsoft 365 Copilot 内部发生的事情。一名研究人员发送了一封带有隐藏指令的电子邮件；受害者从未点击过链接，从未打开过附件，甚至从未亲自阅读过该邮件。一个常规的“总结我的收件箱”查询请求 Copilot 读取该邮件。智能体忠实地执行了在正文中发现的指令，访问了 OneDrive、SharePoint 和 Teams，并在任何人察觉之前通过受信任的 Microsoft 域名外泄了组织数据。该 CVE（2025-32711，“EchoLeak”）获得了 9.3 的 CVSS 评分和服务器端修补，但这类漏洞并未消失。它不可能消失，因为生产环境中智能体上的每一个读取工具都是那个电子邮件收件箱的变体。
这篇文章讨论的是能让你摆脱困境的思维转变：停止将“提示词注入”视为用户输入问题，并开始将每一个工具输出视为一个恰好与你的系统提示词共享 Token 流的不可信渠道。
你的智能体调用了一个数据库工具。查询返回了8000个Token的原始JSON——嵌套对象、null字段、分页元数据，以及每一行都带有时间戳。智能体只需要其中三个字段。你刚刚为7900个噪音Token付了费，并把它们全部注入上下文，让它们与真正的任务争夺注意力。
这就是工具输出注入问题，也是智能体设计中最被低估的架构决策。大多数团队都是在付出代价后才意识到这一点：演示运行顺畅，生产逐渐退化，却没人能解释为什么模型开始对之前能自信回答的问题开始含糊其辞。
大多数团队只有在账单出现时才会发现重试问题。智能体（Agent）“运行正常”；延迟仪表盘保持绿色；错误率看起来也没问题。然后财务部门询问为什么本月的推理支出翻了一番，这时才有人终于去翻看日志。结果发现，一个 3 步操作的智能体中，20% 的工具调用在静默重试，每次重试都重放了完整的提示词（prompt）历史记录，而账单已经连续几周在攀升。
这背后的数学逻辑并不神秘，但极其反直觉。20% 的单步重试率听起来还可以接受 —— 大多数工程师看一眼就会忽略它。但一旦考虑到现代智能体框架的重试方式，实际的 Token 成本会更接近 2 倍而非 1.2 倍。而且，这种失败模式对于团队通常关注的每一项指标都是不可见的。
重试预算（Retry budgets）—— 这是一个源自 Google SRE 工作的旧概念 —— 是最简洁的解决方案。但该模式的 LLM 版本需要调整，因为 Token 的行为方式与 RPC 不同。
每个生产环境的智能体团队最终都会构建同一个东西：一个无限增长的记忆存储、悄然退化的检索性能，以及在用户报告智能体引用了他们的旧工作、已弃用的 API 或三个月前取消的项目后，一场疯狂的冲刺来添加遗忘功能。业界已经在赋予智能体记忆上投入了巨大的努力。更困难的工程问题——对记忆进行垃圾回收——才是真正的生产可靠性所在。
与软件垃圾回收的类比不仅仅是隐喻。智能体记忆系统面临着同样的根本张力：你需要回收资源（上下文预算、检索相关性），同时不能销毁仍然可达（语义上与未来查询相关）的数据。解决这个问题的算法与你的运行时已经使用的算法惊人地相似。
你的 agent 在开发环境中运行完美。它能推理多步任务，自信地调用工具，生成精美的输出。然后你设置了每次请求 $0.50 的成本上限，它就崩溃了。不是优雅地降级——而是灾难性的崩溃。它在推理过程中截断自己的思考，忘记三步前的工具结果，并基于被静默丢失的上下文自信地给出错误答案。
这就是丰裕设计的 agent 和生产受限 agent 之间的差距。大多数 agent 架构都是在无限 token 预算下原型化的——长系统提示词、冗长的工具 schema、完整的文档检索、未压缩的对话历史。当你引入硬上限（成本上限、上下文限制、延迟要求）时，这些 agent 不会优雅地降级。它们以难以检测且调试成本高昂的方式崩溃。
一个记住所有事情的 agent，最终什么有用的都记不住。这听起来像是悖论，却是每个在没有遗忘策略的情况下上线长期运行 AI agent 的团队的亲身体会。记忆存储不断膨胀，检索质量持续下降，某一天你的 agent 开始自信地引用用户的前雇主、一个已废弃的 API 端点，或者一个六个月前就已放弃的项目需求。
行业在赋予 agent 记忆能力上投入了大量精力，却很少关注那个更难的问题：教会 agent 如何遗忘。
一个客户服务智能体知道用户偏好在早晨送货。它还知道用户的主要地址在西雅图。但它无法理解的是，西雅图的地址是一个仅在工作日使用的办公地址，而且由于用户三个月前提到的一项大楼限制，早晨送货窗口期在周一并不适用。每个事实都可以被单独检索，但它们之间的关系却不能。
这就是在基于扁平向量库（flat vector stores）运行的生产级智能体中常见的故障模式。每一条信息都像是一个漂浮在高维空间中的嵌入（embedding）。相似性搜索检索与查询匹配的事实，但它无法恢复事实之间的结构化连接——即在组合中赋予它们意义的“边”（edges）。
大多数智能体记忆架构是围绕向量数据库构建的，因为它们速度快、设置简单，且适用于大多数检索任务。这些失败案例非常微妙，以至于在有人注意到这种模式之前，它们往往已经出现在生产环境中了。
大多数工程师之所以选择并行工具调用，是因为他们希望自己的 Agent 运行得更快。工具执行占 Agent 总延迟的 35–60%，具体取决于工作负载——编码任务处于高端，深度研究任务则处于中端。同时运行独立的调用是显而易见的优化方案。但接下来的情况却让大多数团队感到意外。
一旦你启用了并行执行，工具设计中隐藏的每一个假设都会变得显而易见。在顺序执行时可靠工作的工具，在并发运行时可能会悄无声息地失效。原本稳定的行为变得不可预测，而且失败往往不会产生错误——只是在充满自信地返回一个错误的答案。
并行工具调用主要不是一项性能特性。它是一次非自愿的架构审计。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
