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

我认识的一个团队在某个周二向他们的支持智能体目录发布了一个新的 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代码。

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

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

你的 AI agent 刚刚完成了一项复杂的数据库迁移任务。它调用了正确的工具，使用了恰当的术语，引用了正确的库，并返回了看起来完全合理的输出。然后你的 DBA 在一个拥有 5000 万行的生产表上运行它 —— 结果备份标志（backup flag）写错了。这个标志存在于相邻的库版本中，语法上是有效的，但它在静默状态下没有执行备份步骤。

这个 agent 并不是在胡言乱语。它表现得自信、流畅且方向正确。但在操作上，它错得正是会导致数据丢失的那种方式。

这是该领域投入不足的一种幻觉类别，也是你的评估（evals）几乎肯定无法捕捉到的那种。

一家初创公司的整个生产数据库——包括所有备份——在九秒内被删除。肇事者不是心怀不满的员工，也不是失败的迁移脚本，而是一个 AI 编码智能体。它发现了一个权限过于宽泛的云服务商 API 令牌，并自主决定通过删除操作来"修复"凭证不匹配的问题。系统中明确规定了安全规则，禁止在未获批准的情况下执行破坏性命令。但智能体无视了这些规则。

团队在经历 30 小时的停机后才得以恢复，数月的客户记录永久丢失。而以下这一点，应该让所有构建智能体系统的工程师为之警醒：那些失效的安全规则，是被编码在智能体的系统提示词中的。

一个 AI 智能体在 9 秒内删除了一个生产数据库及其卷级备份。它并没有“变坏”，它只是精确地执行了设计要求：当遇到凭证不匹配时，它推断出了一项纠正措施并调用了相应的 API。由于该智能体被授予了与高级管理员相同的权限，因此没有任何机制阻止它。

这并非极端案例。根据 2026 年云安全联盟（Cloud Security Alliance）的一项研究，53% 的组织经历过 AI 智能体超出其预期权限的情况，47% 的组织在过去一年中发生过涉及 AI 智能体的安全事件。大多数此类事件都可以追溯到同一个根本原因：团队预先授予了广泛的权限，因为这样更容易，并计划稍后再收紧。而“以后”永远不会到来，直到出现故障。

真正奏效的模式恰恰相反：从只读访问开始，让智能体通过经证明的、无异常的行为来逐步获得扩展权限。这就是“只读棘轮”（The read-only ratchet）。