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

一名监管人员给你发了一封邮件，只问了一个问题：该用户是否授权了这笔交易？六小时后，三名工程师正在聊天频道里，试图将聊天界面的对话日志、规划代理（planner agent）的推理追踪以及工具的 API 记录关联起来。聊天日志记录了轮次 ID（turn ID）和用户可见的消息，但没有工具调用的细节。规划器追踪记录了工具调用的记录，其时间戳与聊天日志相差几百毫秒。工具日志记录了 API 调用及其自身的关联 ID（correlation ID），而该 ID 在代理的记录中无处寻觅。下游服务的日志则有另一个 ID，且没有回溯链接。团队最终通过关联用户 ID 和大致的时间戳重建了答案，祈祷没有什么关键信息因错过一个轮次而产生偏差，最后向法务部门提交了一份 PDF 文件。

这就是审计追踪不匹配（audit trail mismatch）。每一层的负责人（owner）都认为自己的日志没问题——而且从单体来看，它们确实没问题。缺失的产物是那个本应存在的“关联视图（joined view）”，并且没人为它的缺失负责。团队只有在发生事故、客户升级投诉或监管机构强制要求关联数据时，才会发现它并不存在。

一个长时间运行的智能体（agent）会话最初以 2K 上下文开启，现在却在为 40K token 的“死状态”买单。第三轮的检索结果、智能体早已跳过的目录列表、工具调用返回的 JSON 转储（即便其答案只是一个整数）—— 所有这些都在随后的每一次推理调用中如影随形，全额计费，并拖累注意力。这种模式在结构上与内存泄漏完全一致：无引用的数据无限制增长。但没有剖析器（profiler）能发现它，因为泄漏并不存在于进程内存中。它存在于对话历史里，而大多数智能体框架在发布时都没有配备回收机制。

成本同时体现在两个地方。token 账单呈二次方增长 —— 一个 20 步的循环，每一步贡献 1,000 个 token，累计产生约 210,000 个输入 token，而不是 20,000 个，因为之前的每一轮对话都会在后续的每一次调用中重新计费。而且模型本身也开始退化：当积累了 50K token 的噪声时，即使是拥有 1M token 窗口的模型，在实际任务上的准确度也会出现两位数的下降。你在花更多的钱，让模型更差地去思考它在三轮前就已经解决的问题。

周一，一位客户在 Slack 上询问你的助手如何启用某项功能，得到了清晰的回答，然后继续工作。到了周五，他们发邮件要求确认之前的决定，而运行在不同会话存储上的助手——完全不知道周一的聊天发生过——给出了截然相反的建议。客户不会针对两个产品提交两张工单，他们会针对你的 AI 提交一张工单，而且他们是对的。对他们来说，只有一个助手。你写了三个助手并将它们粘在三个特定渠道的会话存储上，这本该是你不该泄露的实现细节。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E8%B7%A8%E6%B8%A0%E9%81%93%E8%AE%B0%E5%BF%86%EF%BC%9A%E5%BD%93%E4%BD%A0%E7%9A%84%E6%99%BA%E8%83%BD%E4%BD%93%E5%BF%98%E8%AE%B0%E9%82%AE%E4%BB%B6%E5%BE%80%E6%9D%A5%E6%97%B6"]

这就是跨渠道记忆问题，它处于两个被团队低估的因素的交汇点：用户对连续性的假设有多强烈，以及渠道团队为了快速交付而编写各自会话存储的行为有多普遍。最近的行业数据清晰地揭示了这一差距——只有 13% 的组织成功实现了全渠道的完整对话上下文衔接。碎片化多渠道支持的 CSAT（客户满意度）仅为 28%，而真正的全渠道支持则为 67%。这 39 个百分点的差距并不是模型质量的差距，而是记忆架构的差距。

我认识的一个团队在某个周二向他们的支持智能体目录发布了一个新的 lookup_customer_v2 工具。这个工具的作用范围很窄，经过了充分的隔离测试，并通过了评审。到了周四，一个毫不相关的流程——退款处理——在之前一直运行良好的案例中出现了约 4% 的失败。退款工具没有变。退款提示词没有变。模型也没有变。改变的是规划器（planner）现在在处理退款资格查询时选择了 lookup_customer_v2，而以前这些查询都会清晰地路由到 get_account_status。原因是新工具的描述中恰好包含 "eligibility"（资格）这个词，并在模型内部使用的某种相似性启发式算法下获得了更高的排名。

这就是依赖炸弹。团队通常将工具注册表视为增量式的——“我们只是增加了一个东西，能出什么问题”——但规划器并不将你的注册表视为独立能力的列表。它看到的是各种选择上的概率分布，而每一个条目都会重新分配权重。增加一个工具可能会悄悄地削弱其他地方的行为，而你的评估套件（eval suite）可能会漏掉这一点，因为没有人写过回归测试来规定“在这种情况下，智能体应该仍然选择 旧 工具”。

行动前先询问的 AI 系统显然更可靠。它们能避免不可逆的错误，在误解扩散前将其暴露出来，并在第一次真正的尝试中生成更高质量的输出。

问题在于，这一原则的大多数实现都是 UX（用户体验）的灾难。它们不是问一个好问题，而是问三个平庸的问题。那些本只需要澄清十个词指令的用户，最终陷入了五轮审讯式的对话，这比直接做错任务然后再修正还要耗时。可靠性带来的优势消失殆尽，取而代之的是用户的放弃。

这是一个设计问题，而不是模型能力问题。模型完全有能力提出精准、高价值的问题。缺失的是一种强制收敛的架构约束：一种将多轮澄清视为需要通过工程手段解决的故障模式（Failure Mode），而不是一种可以依赖的特性的规则。

2025 年，自动化互联网流量同比增长了 23.5%，是人类流量增速的八倍。其中，agent 驱动的交互增长了 7851%。如果你的产品处理了相当体量的 API 流量，那你的最重度"用户"很可能根本不是人类。而令人不安的事实是：你的产品分析系统对此几乎一无所知。

这不是一个机器人检测问题，而是一个埋点架构问题。当 AI agent 预订差旅、提交费用报告、查询数据库或调用你的支付 API 时，它留下的行为特征与人类完全不同——而你的会话漏斗、NPS 问卷和队列留存图，正在悄悄对你撒谎。

大多数工程团队在推出第一个AI智能体六个月后，会发现自己已经拥有了15个。这并非出于规划——而是因为每个团队都解决了真实问题并付诸实施。客服团队构建了分类智能体，数据团队构建了报告生成智能体，平台工程团队构建了运行手册智能体，基础设施团队又构建了三个。这些智能体之间没有共享的认证、日志、工具或评估方法。Token费用从十几个供应商账户持续流失，而没有人能告诉你哪个智能体负责哪些开销。

这一时刻，正是能够规模化AI的工程组织与不能的工程组织之间的分水岭。答案不是放慢智能体的开发——而是在熵使整合变得不可能之前，先进行一次组合审计。

你的智能体在最初三个月表现良好。它拥有 CRM 的读取权限、工单系统的写入权限，以及代表用户发送电子邮件的许可。你在部署时仔细划定了它的权限范围（Scope），然后便开始处理其他事务。六个月后，它开始针对用户从未预料到的情况提交支持工单，发送引用了用户本想保密的内部上下文的邮件，并以技术上符合授权范围、但完全背离用户授权初衷的方式跨系统提取数据。

这就是授权衰减（Consent Decay）。授权并没有改变，改变的是智能体的行为——而你在设置时授予的静态权限也随之而动，支持了智能体随后决定做的任何事情。

一个正在构建多智能体研究工具的团队在一次失控任务运行到第 11 天时发现，他们的两个智能体在整个过程中一直在循环交叉引用彼此的输出。账单金额：47,000 美元。没有人类看到过结果。没有触发任何警报。系统只是在持续运行，并确信自己正在取得进展，因为架构中没有任何环节提出这样一个问题：当一个任务确实无法完成时会发生什么？

消息队列在几十年前就通过死信队列 (DLQ) 解决了这个问题。一条超过投递重试限制的消息会被路由到一个暂存区，操作员可以在那里检查它、修复根本原因，并在系统准备就绪时重新播放。这种模式简单、经过实战检验，但在当今的生产级智能体系统中几乎完全缺失。

大多数构建多智能体系统的团队，把大量时间花在授权信任上：智能体 B 被允许执行哪些操作、可以调用哪些工具、能访问哪些数据。这是一个重要的问题。但还有第二个信任问题同样关键，却鲜少得到足够重视——而正是它在实际生产系统中造成严重故障。

这个问题是认知层面的：当智能体 A 将任务委托给智能体 B 并收到答案时，A 应该在多大程度上相信 B 返回的内容？

这不是 B 是否被授权回答的问题，而是 B 是否真的有能力回答的问题。

一个在生产环境中运行的智能体曾经收到指令"清理测试数据"，然后对生产数据库执行了 DROP TABLE 命令。工具调用成功执行了。审计日志显示了一个结构完美的 JSON 载荷。智能体做的恰恰就是被要求做的——只是不是任何人所期望的那样。这不是一个提示注入的故事，而是一个架构选择的故事：团队赋予了智能体生成和执行任意代码的能力，却低估了这在运行时真正意味着什么。

将函数调用与代码生成作为 AI 智能体动作层之间的选择，是智能体架构中最关键的决策之一，却几乎没有人对其进行直接基准测试。论文衡量任务完成的准确性；它们很少衡量在生产中真正重要的失败模式——静默语义错误、不可逆副作用、安全暴露面，以及出错时的调试成本。

你的智能体已经与同一个用户对话了400次。六个月前她说她更喜欢Python。三个月前她的团队迁移到了Go。上周她提到了一个新的TypeScript项目。这三个事实现在都存储在你的向量数据库中——语义相似、时间顺序混乱、权重相同。下次她请求代码帮助时，你的智能体会同时检索到这三条信息，将这团矛盾的内容递给模型，然后自信地为TypeScript场景生成带有Go风格的Python代码。

这就是幽灵上下文：那些永不消亡的过时信念，与其替代版本一同被检索，悄然腐蚀智能体的推理。

这个问题之所以被低估，是因为它不会产生可见错误。智能体不会崩溃，不会拒绝响应，而是生成流畅自信的输出——只是微妙地、代价高昂地出错了。