161 篇博文 含有标签「agents」

当 AI 智能体预订日历事件、发送电子邮件或提交表单时，它并非以自己的身份行事——而是在某个说"去做这件事"的人类的委托授权下行事。这一区别听起来很哲学，直到某个智能体泄露了敏感数据、执行了用户并不打算执行的不可逆操作，或者遭到入侵。到那时，问题不再是发生了什么，而是谁授权的、何时授权的，以及能否撤销。

权限范围设置不当的智能体凭证所带来的波及范围，远超大多数团队的预期。拥有广泛 API 访问权限的智能体不是单一故障点——而是一个长期开放的后门。2025 年，智能体 AI 的 CVE 数量同比增长了 255%，大多数事件都可以追溯到权限过宽、有效期过长或无法彻底撤销的凭证。正确构建智能体，意味着在投入生产之前就设计好授权层。

你有一个批量任务，一夜之间可以对 1,000 万张客户支持工单进行分类。你将正则分类器换成了大语言模型（LLM），准确率从 61% 飙升至 89%。然后你上线了它，却发现：这项任务现在的成本增加了 40 倍，运行速度慢了 12 倍，当模型返回无法解析的输出时会静默跳过 3% 的记录，而且由于标签架构（label schema）在无人察觉的情况下发生了偏移，你的下游分析团队正在不断提交 Bug。

Agentic 数据管道的损坏方式是 ETL 工程师以前从未见过的，修复它们需要一套不同于传统批处理或实时 LLM 服务的思维模型。

这个 Demo 只需 20 分钟就能构建完成。你粘贴一个 URL，大语言模型（LLM）读取 HTML，结构化数据就从另一端输出了。这感觉就像网页数据提取的未来已经到来。

然后，你以每小时 1,000 页的速度运行它。成本飙升，屏蔽不断积累，提取出的字段开始以一种看起来不像错误的方式发生偏移——它们看起来像正常数据，直到你的下游流水线已经默默地摄取了三周的垃圾。“LLM 读取页面”的模式并没有错，只是它的定价更适合原型的吞吐量。

智能体（Agentic）网页提取确实解决了传统爬虫无法解决的问题。但要将其扩展到概念验证（PoC）阶段之后，需要理解一组与大多数团队预期不同的故障模式。

大多数构建多步 agent 管道的工程师会在第一次生产故障后约两周发现同一个问题：他们在 API 网关设置了 5 秒超时，但 agent 管道有四跳，而整个系统的行为就好像根本没有超时一样。第三跳的 agent 不知道上游调用方三秒前就已放弃等待，它继续运行、继续调用工具、继续生成 token——而用户早已离开。

这不是配置错误，而是结构性问题。延迟约束默认不会跨 agent 边界传播，主流编排框架也没有任何一个让截止时间传播变得容易。结果是一类看起来像延迟问题、实则是上下文传播问题的故障。

你的 Datadog 仪表盘一片绿色。Jaeger 链路看起来干净整洁。P99 延迟符合 SLA。而你的 Agent 流水线正在悄无声息地因重试死循环每天烧掉 4000 美元，却没有触发任何一条报错。

传统 APM 工具是为微服务设计的——确定性路径、有界载荷、可预测的扇出。Agent 流水线打破了所有这些假设。执行路径在运行时才能确定。工具调用深度变化剧烈。一次"请求"可能跨数分钟产生数十次 LLM 调用。而当出了问题，失败模式通常不是异常——而是一个悄然膨胀成本和延迟、却返回看似正常输出的静默重试级联。

结果是一代工程师在盲目飞行，信任着那些衡量错误事物的仪表盘。

大多数团队能把单智能体的可观测性做得足够好——加上链路追踪、统计 Token 用量、设置错误率告警。然后他们把并发智能体扩展到一百个，才发现整个监控体系一直在盯错方向。

摧毁集群的问题，并不是摧毁单个智能体的那些问题。一个陷入递归推理循环的智能体可以在一小时内烧光一个月的 API 预算。模型服务商悄无声息的质量降级，会让集群里的每一个智能体同时以满满的自信给出错误答案——而你的基础设施仪表盘依然一片绿灯。这些故障不会出现在延迟图表或 HTTP 错误率中，因为它们根本不是基础设施故障，而是语义层面的失效。

大多数团队将人机协作审核作为事后补充：智能体完成其工作链，结果落入审核队列，然后人工点击批准或拒绝。这看起来像是安全保障，但实际上大多只是一种表演。

当一个多步骤智能体到达链尾审核时，它已经发送了 API 请求、修改了数据库行、起草了客户邮件并安排了后续跟进。所谓的"审核"不过是在批准一件已经完成的事。拒绝它意味着向智能体——通常也向用户——解释为什么过去 10 分钟发生的一切都不作数。

错误放置审批关卡造成的危害并不总是戏剧性的。更多时候，危害更加隐蔽：审核者批准一切，因为真正的决策已经做出；工程师在事故发生后增加更多检查点，却眼睁睁看着产品信任度崩溃；组织在"太多摩擦"和"监督不足"之间摇摆，却从未解决根本的放置问题。

你的客服智能体稳定运行了三个月。一次例行模型更新在周二悄然上线。到周三下午，三个下游服务已在静默地解析智能体响应中的错误字段——JSON 键值发生了微妙变化，但没有任何报错。到周四，你追溯到订单完成率下降，原因是某个 JSON 字段从 "status" 被重命名为 "current_state"。模型更新了，智能体版本号仍是 v2.1.0，没有人收到告警。

这正是传统 API 设计从未需要解决的版本管理空白。语义化版本控制（Semver）在能够从规范中确定性地复现输出时才有效。AI 智能体无法做出这种承诺。然而下游服务对其行为的依赖程度，与对任何微服务 API 的依赖一样关键。"我们打了一个发布标签"与"下游消费者受到了保护"之间的鸿沟，从未如此之大。

前沿模型如今宣传的上下文窗口动辄 200K、1M 乃至 2M token。工程团队将其视为已解决的问题而继续前行。数字如此之大，我们应该永远不会触及上限。

然而，在一个自主研究任务执行六小时后，agent 开始产生幻觉，对它三小时前编辑过的文件路径一无所知。一个代码 agent 自信地打开了它在第四轮已删除的函数。文档分析流水线开始与它之前从同一文档得出的结论相矛盾。这些不是模型失败——它们是上下文预算失败：可预测、可测量，而且只要将上下文窗口视为它实际所是的稀缺计算资源，几乎完全可以预防。

在生产环境中运行一百个 agent 感觉还可以管理。你有追踪数据，有仪表盘，知道什么时候出问题。但运行一千个并发 agent 完全是另一个问题——不是因为 agent 更复杂，而是因为你为十个 agent 建立的监控模型在你注意到之前就已经悄然失效了。

失败模式很微妙。一切看起来都很正常。你的 span 树都在。错误率很低。然后，一个导致 40% 会话输出质量下降长达六小时的提示词回归，只因为客户投诉才浮出水面——而不是被你的可观测性系统捕获。

这就是仪表盘盲区问题：单 agent 追踪在小规模下运行良好，在集群规模下则会悄然失效。以下是它发生的原因及应对之道。

你的链路追踪仪表盘显示 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 也应该遵循同样的纪律，而大多数组织仍然像处理团队间传递的贴纸一样对待它们。