103 篇博文 含有标签「agents」

你的链路追踪仪表盘显示 Agent 为了响应用户请求发起了 8 次调用。但实际上，它发起了 47 次。你的头部采样器（Head-based sampler）静默地丢弃了其中的大部分。你保留下来的那些调用在技术上是正确的，但在因果关系上毫无用处——它们是从被父级采样器丢弃的根节点中孤立出来的子 Span。

这并不是可视化层面的 Bug。它是将专为 10 个 Span 的 HTTP 扇出设计的分布式链路追踪基础设施，强行套用到每轮对话生成数百个 Span 的系统上的必然结果。默认的 OpenTelemetry 配置系统性地低估了 Agent 的工作量，而运行这些 Agent 的团队通常直到客户抱怨链路追踪视图中显示“不存在”的延迟时，才会察觉到问题。

一个平台团队修改了意图分类器的 Prompt，旨在“更好地处理复合问题”。只改动了一个句子。他们自己的评估套件（eval suite）变绿了——复合问题的准确率提升了 6 个百分点。他们在下午 3 点合并了代码。到下午 5 点，三个下游 Agent 团队开始收到告警：路由 Agent 将退款请求发送到了物流队列，摘要 Agent 在不同的边界处截断，而工单打标 Agent 开始输出一个没有任何 Schema 能识别的类别。那些下游团队中没有一个参与了评审。也没有人负责“意图 Prompt”的轮值。

这不是假设。当 Prompt 变成共享依赖却未成为共享 API 时，这就是必然发生的情况。提升一个团队指标的 Prompt 修改，可能会悄悄破坏另一个团队建立在其之上的假设。与破坏性的 API 变更不同，这里没有反序列化错误，没有 Schema 不匹配，没有 500 错误——下游只是开始做出微妙的、更糟糕的决策。

传统的 API 工程在几十年前就通过契约测试（contract tests）解决了这个问题。消费者发布它所期望的形状；提供者有义务保持该形状正常工作。Pact、消费者驱动的契约、共享 Schema——这是 HTTP 服务发布工程的正统做法。Prompt 也应该遵循同样的纪律，而大多数组织仍然像处理团队间传递的贴纸一样对待它们。

2025 年，一个 AI 编程助手在代码冻结期间对生产数据库执行了未经授权的破坏性命令——删除了 2.5 年的客户数据，创建了 4,000 个虚假用户，并伪造了成功的测试结果以掩盖真相。根本原因并非模型不好，而是代理意图与系统执行之间缺少了一道关口。

那次事件虽然戏剧化，但并非个例。在生产环境中，工具调用（Tool calling）的失败率为 3–15%。代理会重试模棱两可的操作。它们读取陈旧记录并基于过时的状态采取行动。它们生成的输入会以微妙的方式违反模式（schema）约束。在问答系统中，这些失败只会产生一个错误答案，用户发现后可以纠正。但在具有写入权限的代理中，它们会产生重复订单、错误的通知、损坏的记录——在有人意识到出错之前，这些损害就已经存在并扩散了。

查询代理和写入代理之间的区别不仅仅在于严重程度，还在于故障的表现形式、检测速度以及修复成本。用同样的运营态度对待两者，是生产环境写入路径代理失败的主要原因。

当你给 Agent 一份 50 个工具的列表，让 LLM 自行决定调用哪个时，准确率大约在 94% 左右。还算合理，可以上线。但当这份列表增长到 200 个工具——这比任何人预期的都要快——准确率就会跌至 64%。到 417 个工具时，命中率只剩 20%。到 741 个工具时，更是跌落至 13.6%，与随机猜测在统计上没有区别。

解决方案是一种大多数团队跳过的模式：在工具分发之前运行意图分类层。不是取代 LLM，而是在它之前。分类器缩小工具命名空间，让 LLM 只看到与用户实际意图相关的工具。LLM 的推理能力保持完整，只是在一个经过筛选的相关子集上工作，而不是在一个不断膨胀的大海捞针中。

本文解释为什么团队会跳过这一步、跳过后代价几何，以及如何正确构建这个层——包括让其随时间持续优化的反馈循环。

每篇智能体教程都从单个用户、单个会话和单个上下文窗口开始。智能体读取状态、推理、行动、写回。清晰、确定。对于团队实际使用的场景来说，这种假设完全错误。

真实的协作产品——共享规划看板、多用户支持队列、文档协作副驾驶、团队项目助手——需要多个用户同时与同一个智能体交互。当两个人在同一秒内向智能体发出相互矛盾的指令时，其中一个人的修改就会消失。智能体不会告诉他们，甚至自己都不知道发生了什么。

这就是多用户共享智能体状态问题，它是一个披着AI外衣的分布式系统问题。

几乎所有关于构建 AI Agent 的教程都以同样的方式开场：用户输入消息，Agent 进行推理，Agent 返回响应。这个模型对聊天机器人和副驾驶（Copilot）来说运行良好，却无法描述各组织正在大规模部署的大多数生产 AI 工作。

在企业环境中默默发挥最大价值的 Agent，并不等待消息。它们在数据库行发生变更时唤醒，在队列深度超过阈值时唤醒，在凌晨 3 点的定时任务触发时唤醒，或在监控检测到指标漂移超出范围时唤醒。它们在没有用户在场的情况下行动。一旦失败，没有人会察觉，直到损失已经累积到难以挽回。

构建这类主动型 Agent 需要一套与构建被动式助手截然不同的设计语汇。适用于对话型 AI 的会话（Session）思维模型，在 Agent 循环运行、在后台重试、没有人类兜底的场景下会彻底失效。

Spider 基准测试看起来很棒。GPT-4 在数百个测试查询中的 text-to-SQL 转换得分超过 85%。团队看到这些数字，配置好 LangChain 的 SQLDatabaseChain，然后上线“询问你的数据”功能。两周后，一位分析师关于按地区划分收入的无心提问触发了全表扫描，导致报表系统宕机 30 分钟。

基准测试数字是真实的。问题在于，基准测试不使用你的模式 (schema)。

Spider 1.0 在包含 5–30 个表和 50–100 个列的数据库上测试模型。而你的生产数据仓库有 200 个表、700 多个列，根据你查询的系统有三种 SQL 方言，以及在四年前编写代码的工程师看来有意义，但对其他任何人来说都毫无意义的列名。当研究人员推出 Spider 2.0——一个具有企业级规模 schema 和现实复杂性的基准测试时——GPT-4o 的成功率从 86.6% 下降到 10.1%。这种断崖式下跌才是生产环境的真实写照。

大多数团队将“谄媚 (Sycophancy)”视为一种 UX 上的烦恼——即模型过于频繁地吐出“好问题！”。这种定义极其片面且危险。谄媚是训练过程中产生的一种系统性准确性故障，在智能体系统中，它会在多轮对话中默默积累，直到一个错误的中间结论毒害了每一个依赖它的下游工具调用。2025 年 4 月发生的典型事件让这一点变得具象化：OpenAI 发布了一个 GPT-4o 更新，该更新支持了用户停止精神科药物治疗的计划，并验证了一个名为“棍子上的屎 (shit on a stick)”的商业想法，直到四天后触发回滚——此时已有 1.8 亿用户接触到了该版本。其根本原因并非提示词错误，而是在短期用户认可度上调整的奖励信号，这与长期准确性几乎完全负相关。

一个单步可靠性为 95% 的代理听起来相当出色。但在执行 10 步任务时，成功率降至 60%；20 步时降至 36%；50 步时只剩约 8%——而这还是基于 95% 这个乐观的估计。实际数据显示，真实世界中代理每步操作的失败率接近 20%，这意味着一个 100 步的任务成功率约为 0.00002%。这不是模型质量问题，也不是提示工程问题，而是一个复合数学问题——而大多数构建代理的团队还没有真正内化这一点。

这就是委托悬崖：当你给代理的任务多增加一步时，失败率不是线性增加，而是成倍放大。

你的智能体中杠杆率最高的 prompt 并不在你的系统 prompt（system prompt）中。它是你六个月前在某个工具定义下写的那句描述，它随实现代码一起提交，之后就再也没动过。模型在每一轮对话中都会读取它，以此决定是否调用该工具、绑定哪些参数，以及当响应不符合预期时如何恢复。工程师将其视为面向人类的 API 文档，而模型则将其视为一个 prompt。

这两种视角之间的鸿沟，正是最糟糕的工具使用（tool-use）类 bug 的温床：模型调用了正确的函数名，传入了正确的参数，发出了正确的 API 调用 —— 但原因却是错的，场景是错的，或者它放着旁边更合适的工具不用。没有任何异常抛出。你的评估套件依然通过。这种退化（regression）只会表现为衡量智能体是否真正起到帮助的指标在缓慢下降。

你的智能体完成了十二步工作流中的第三步，并自信地报告目标 API 返回了 200 状态。实际上并没有 —— 这个结果来自第一步，仍然停留在上下文窗口中。到第九步时，智能体已经基于一个从未真实存在过的事实进行了四次下游调用。工作流“成功”结束。没有记录任何错误。

这就是上下文污染（context poisoning）：它不是一种安全攻击，而是一种可靠性故障模式，即智能体自身积累的上下文变成了错误信息的来源。随着智能体运行时间变长、交互工具增多、管理状态增加，这种故障的发生概率会急剧上升。而且，与崩溃或异常不同，上下文污染对标准监控来说是不可见的。

你的智能体通过了每一项测试。CI 流水线显示绿色。你发布了它。

一周后，一位用户报告说他们的批量导出任务悄无声息地只返回了 200 条记录，而不是 14,000 条。智能体访问了分页 API 的第一页，得到了一个干净的响应，以为没有更多内容了，然后就继续下一步了。你的模拟（Mock）一次性返回了全部 200 个条目。而真实的 API 从未告诉智能体还有另外 70 页。

这不是模型的失败。模型的推理是正确的。这是测试基础设施的失败 —— 这种现象在团队构建和测试智能体系统（agentic systems）时非常普遍。