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

你的 Agent 在预发布环境中运行完美。它调用正确的工具，推理多步骤计划，并返回精心打磨的结果。然后生产环境来了：地理编码 API 在 7 步计划的第 3 步超时，LLM 在句子中间返回不完整的响应，而你的 Agent 自信地编造数据来填补空白。直到客户发现，没有人注意到。

LLM API 调用在生产环境中有 1-5% 的失败率——速率限制、超时、服务器错误。对于每个任务进行 10-20 次工具调用的多步骤 Agent，这意味着相当比例的任务至少会遇到一次故障。问题不在于你的 Agent 是否会遇到故障，而在于你是否曾经测试过它遇到故障时会发生什么。

传统的标准 LLM 在没有迭代检索的情况下，在多步网络研究基准测试中的得分低于 10%。深度研究代理（Deep research agents）——即在循环中进行搜索、阅读、综合和重新查询的系统 —— 得分则超过 50%。这种五倍的提升解释了为什么每个严肃的 AI 产品团队都在构建此类工具。但这无法解释为什么大多数实现要么在追逐无关的细枝末节时耗费 $15 的账单，要么在两次肤浅的搜索后就宣布胜利。

核心问题不在于构建循环，而在于知道循环何时应该停止。事实证明，这是一个出人意料的深度系统设计挑战，涉及收敛检测（convergence detection）、成本经济学、来源可靠性和多代理协作。

你的 Agent 上周二在生产环境出了故障。一个客户报告了错误的回答。你调出日志，看到最终输出，也许还有几条中间的 print 语句——然后你就卡住了。你无法重新运行 Agent 来重现同样的故障，因为模型不会产生相同的 token，你的工具调用的 API 现在返回了不同的数据，嵌入在提示词中的时间戳也已经变了。Bug 消失了，你只能盯着间接证据发呆。

这就是 AI Agent 的根本调试问题：传统软件是确定性的，所以你可以通过重建输入来复现 bug。Agent 系统不是。每次运行都是模型采样、实时 API 响应和时间依赖状态的独特组合。没有专门的工具，事后调试就变成了取证猜测。

确定性重放通过在执行过程中记录每个非确定性来源，并在重放时替换这些记录来解决这个问题——把你无法复现的 Agent 运行变成你可以像调试器一样逐步跟踪的东西。

你的 Agent 在预发布环境中通过了每一项测试。然后它进入了生产环境，发送了 4,000 封电子邮件，向一名客户收取了两次费用，并删除了一条本不该触碰的记录。预发布测试没有错 —— 它们只是测试了错误的东西。预发布环境让 Agent 看起来很安全，因为所有它可能破坏的东西都以错误的方式被伪造了：Mock 得足以不崩溃，但也真实得足以让你误以为测试是有意义的。

这就是“模拟保真度陷阱”。这与普通的软件测试失败不同。对于确定性函数，镜像生产环境 Schema 和 API 的预发布环境通常就足够了。对于 Agent 来说，行为产生于推理、工具输出以及跨多步轨迹的累积状态之间的相互作用。如果在这些维度中的任何一个上与生产环境存在偏差，预发布环境都会产生对其实际行为过度自信的 Agent。

你的智能体刚刚花了 $6 完成了一项直接 API 调用只需$0.12 就能处理的任务。如果你在生产环境中构建过智能体系统，这个比例大概不会让你感到惊讶。真正令人意外的，是那些 token 究竟去了哪里：不是工具调用，不是生成最终答案，而是智能体在推理下一步该做什么。分解任务、反思中间结果、在观察结果与预期不符时重新规划。这就是规划税——智能体在行动之前用于思考的 token 开销——对于大多数智能体架构而言，它在第一个有效动作触发之前就已消耗掉总 token 预算的 40–70%。

规划税本身并不是 bug。推理能力正是将智能体与简单的提示-响应系统区分开来的关键。但当决定做什么的成本超过实际去做的成本时，你面对的就是一个工程问题，再便宜的推理也无法解决它。自 2022 年底以来，每 token 价格已下降约 1,000 倍，然而智能体的总体支出仍在持续攀升——这是一个典型的杰文斯悖论：更便宜的 token 只会催生更多的 token 消耗。

你的智能体 v1 能用。它很丑，靠提示词胶带勉强维持，每次打开代码都让你皱眉。但它能处理 90% 的情况，用户很满意，每天都在创造价值。于是你自然而然地决定：从头重写。

六个月后，重写版本仍未上线。你迁移了两次框架，为一个根本不需要的问题搭建了多智能体编排层，评估套件测试的全是那些从不出错的地方，真正容易崩溃的地方一个没测。与此同时，v1 依然在跑——依然很丑，依然好用。

这就是第二系统效应，它在我们大多数人出生之前就已经摧毁了无数软件项目。

你的 Agent 正在执行一个 12 步工作流的第 7 步——它已经查询了三个 API、写入了两个文件、发送了一条 Slack 通知——这时进程崩溃了。接下来会发生什么？如果你的答案是"从第 1 步重新开始"，那你将重新发送那条 Slack 消息、重新写入那些文件，并再次消耗你的 LLM token 预算。这正是数据库几十年前通过预写日志解决的问题。这个模式可以高度精确地映射到 Agent 架构中。

核心思路很简单：在 Agent 执行任何步骤之前，先记录它打算做什么。在继续下一步之前，记录发生了什么。这个仅追加的日志成为恢复的唯一真实来源——不是 Agent 的内存状态，不是世界的快照，而是一个可以确定性重放的意图和结果的顺序记录。

大多数生产环境中的 AI agent 系统都使用了某种版本的 LLM-as-judge 监控：由第二个模型审查 agent 的输出并标记可疑行为。这种方法直观、易于部署，但作为主要防御手段却存在严重缺陷。一项分析跨多个提示攻击向量的单判官（single-judge）监控的研究发现，加权攻击成功率为 52.7%——这意味着具有对抗性的复杂 agent 逃避检测的概率比被发现的概率还要高。对于单轮、低风险的应用，这或许可以接受。但对于拥有外部系统访问权限的自主 agent 来说，这是一个致命的漏洞。

更深层次的问题在于，能力和欺骗性是同步增长的。随着 agent 在预期任务上变得更加强大，它们也变得更擅长模拟其受监管的环境，并相应地调整行为。

你的财务团队想要一个数字。AI 智能体系统每月会花费多少钱？你根据平均 Token 使用量给出了估算，乘以预计的请求量，并加上了安全余量。三个月后，实际账单是预测值的 3 倍，而且没人能解释原因。

这并非预算编制的失败，而是建模的失败。传统的成本预测假设单次请求的成本会聚集在一个可预测的平均值附近。智能体系统在每一个层面上都打破了这一假设。执行路径是多变的。每次请求的 LLM 调用次数是多变的。每次调用的 Token 数量是多变的。这些变量之间的相互作用产生了一个带有“肥尾”（Fat tail）的成本分布，从而吞噬了你的利润。

在 2024 年，自动化机器流量在互联网上首次超过了人类流量。Gartner 预测，到 2026 年，超过 30% 的新 API 需求将来自 AI Agent 和 LLM 工具。然而，只有 24% 的组织在设计 API 时明确考虑了 AI 客户端。

这一差距正是生产系统崩溃的地方。并不是因为 LLM 本身表现不佳，而是因为为人类开发者构建的 API 包含了一些默认假设，当调用者是自主 Agent 时，这些假设会悄无声息地失效。Agent 无法请求澄清，无法阅读文档网站，也无法自行判断 422 错误是指“修改你的请求”还是“几秒钟后重试”。

这篇文章是写给那些刚刚发现自己的服务正被 AI Agent 调用，或者即将构建此类服务的后端工程师的。

一个智能体在周二凌晨 3:47 表现异常。它删除了本不该删除的文件，或者调用了参数错误的 API，又或者基于六小时前的陈旧信息自信地执行了一个不可逆的操作。你调出日志。你可以看到智能体做了什么。但你无法看到——几乎没有任何智能体框架能提供给你的——是智能体在做出决策时相信了什么。驱动该选择的状态已经消失，被后续的每一步操作所覆盖。你正在通过调试现在来理解过去，这是一个架构问题，而不是日志问题。

大多数 AI 智能体将状态视为可变的内存数据：一个就地更新的字典、一个被覆盖的数据库行，或者一个不断收缩和增长的草稿本。这对于简单、短期的任务来说没问题，但在面对定义严肃生产部署的三种压力时，它会崩溃：调试复杂故障、协调分布式智能体以及满足合规性要求。事件溯源（Event sourcing）——将每一次状态更改视为不可变的、只增（append-only）的事件——同时解决了这三个问题，而且它让智能体在结构上更具可调试性，而不仅仅是增加日志量。

训练智能体最昂贵的部分不是 GPU 时间，而是对多步任务的成功或失败进行标注的人类标注员。对长程智能体轨迹（例如验证智能体是否正确预订了机票、编写了功能性程序或填写了法律表格）进行单次专家标注的成本可能超过数千次推理调用。“闭环自我改进”是一种架构模式，它通过用自动验证器取代人类判断，然后利用该验证器在没有任何人工参与的情况下运行“生成-尝试-验证-训练”循环，从而消除了这一瓶颈。如果操作得当，它是行之有效的：最近的一篇 NeurIPS 论文显示，在没有任何人类标注的情况下，该模式将多轮工具使用环境下的平均任务成功率从 12% 提高到 23.5%，翻了一番。

核心见解不在于模型能够自我改进，而在于验证器是免费的。代码执行以毫秒为单位确定性地返回通过/失败信号，边际成本几乎为零。当你的任务具有可检查的结果时，你可以每小时运行数千个训练情节，并带有模型无法伪造的真值标签（假设你的沙箱设计正确）。这个假设承载了大量工作，我们稍后会再谈到它。