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

在 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%，翻了一番。

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

一个带有精简 Python 处理程序的标准 Lambda 函数冷启动大约需要 250 毫秒。而你的 AI 智能体，在调用相同的运行时并添加了一些 SDK 导入后，冷启动需要 8-12 秒。如果再加上本地模型推理，时间将达到 40-120 秒。第一个触发已缩容部署的用户，在智能体响应之前需要等待一条电视广告的时间。这种差距——不是单次推理 Token 的延迟，也不是吞吐量，而是初始启动成本——正是大多数 Serverless AI 部署在用户体验上悄然失败的原因。

这个问题并非 Serverless 所特有，但 Serverless 让它变得显而易见。当你在常驻（always-on）基础设施上运行智能体时，你是在为闲置容量付费，且冷启动永远不会发生。当你为了降低成本而采用缩减至零（scale-to-zero）的策略时，每一个低流量时期都成为了等待下一个请求的陷阱。

大多数 AI agent 通过结构化 API 与世界交互 —— 干净的 JSON 输入，干净的 JSON 输出。但有一类日益增多的 agent 完全抛弃了这种约定。计算机使用 (Computer use) agent 查看截图，对所见内容进行推理，并像人类操作员一样操作鼠标和键盘。当唯一的集成界面是屏幕时，像素就变成了 API。

这听起来像是个花招，直到你意识到有多少企业软件根本没有 API。遗留的 ERP 系统、内部管理面板、专有的桌面应用程序 —— GUI 是唯一的接口。多年来，机器人流程自动化 (RPA) 通过脆弱的、基于选择器 (selector) 的脚本来处理这些问题，只要按钮移动了三个像素，脚本就会失效。计算机使用 agent 承诺了一些不同的东西：像人类一样适应 UI 变化的视觉理解能力。

一个能够总结合同、起草产品规范和编写 SQL 查询的通用 AI 智能体确实令人印象深刻——直到你将其部署到放射科，并发现它建议了听起来合理但却与患者实际药物过敏史相冲突的剂量。这种失败并非幻觉问题，而是架构问题。

大多数智能体演示中隐含的假设是：足够强大的基础模型加上广泛的工具集，就等于在任何领域都胜任的智能体。而在实践中，这一假设与生产现实之间的差距，正是导致患者受伤、诉讼产生以及实验结果不可复现的根源。通用智能体是一个合理的起点，而非终点。

当客服专员收到包含原始聊天记录的 AI 到人工移交时，准备解决问题所需的平均时间为 15 分钟。专员必须在 CRM 中查找客户、查询相关订单、计算购买日期，并重新推导 AI 已经确定的内容。而当同样的移交以结构化负载（Payload）的形式到达时——包含操作历史、检索到的数据以及触发升级的确切歧义点——准备时间会缩短至 30 秒。

这种手动工作量减少 97% 的情况并非极端案例。这正是能够真正支持人工监督的升级协议，与仅仅将上下文抛给恰好在值班人员的协议之间的区别。

大多数团队发现他们的 AI 智能体存在 GDPR 问题的方式都是错误的：当一个数据主体提交删除请求时，法务团队询问哪些系统持有该用户的数据，而工程团队开出的工单最终演变成了一场长达六个月的审计。个人数据散落在对话历史中、向量存储的某个角落、可能缓存的工具调用输出中，甚至可能嵌入在微调后的模型检查点里 —— 却没有任何人事先对此进行梳理。

这不是配置上的疏忽，而是架构上的缺失。决定你的 AI 系统是否具备合规性的决策，通常在构建的头几周就已经做出，远早于法务部门找上门来。本文涵盖了受监管行业工程师在将 AI 智能体投入生产环境之前需要解决的四个结构性冲突。

大多数构建 AI Agent 的团队在经历第一次生产事故后，都会发现同一个测试陷阱。你有两个明显的选择：在 CI 中进行实时的 API 调用（缓慢、昂贵、且具有非确定性），或者将 LLM 完全 Mock 掉（快速、廉价、但内容空洞）。这两种方法都会以不同但可预见的方式失败，而第二种方法的失败模式更糟糕，因为它是隐形的。

Mock 掉 LLM 的团队可能会跑六个月的全绿 CI，发布到生产环境后，才发现代码库中一直潜伏着一个 bug：在 8 步循环的第 6 步，Agent 处理畸形工具响应的方式有问题。那个总是返回 "Agent response here" 的 Mock 根本没有触及编排层。实际的工具分发、重试逻辑、状态累积和兜底路由代码从未被测试过。

好消息是还有第三条路。它与其说是一种单一的技术，不如说是一个由三层测试组成的架构，每一层都旨在捕获不同类别的失败，且无需承担其他方法的成本。

一个在 SWE-Bench Verified 上得分 75% 的模型，在处理需要人类工程师花费数小时才能完成的任务时，其得分会降至 25% 以下。同样一个能够稳定处理单轮问答的智能体（agent），在被要求协调十几个步骤以实现一个开放式目标时，可能会陷入语无伦次的循环、幻觉化工具输出，并忘记其最初的目标。基准测试数据与生产环境表现之间的差距并非噪声——它是结构性的。理解这一点，是交付有用产品与交付仅在演示（demo）中好看的产品之间的区别。

本篇文章讨论的就是这个差距：它为何存在，在长程（long-horizon）任务中会出现哪些静态评估中从未出现的特定失败模式，以及构建一个能够真正捕捉到这些模式的评估框架需要什么。

2025 年 9 月，一个每周下载量达 1,500 次的非官方 Postmark MCP 服务端被悄悄篡改了。更新在其 send_email 函数中添加了一个单一的 BCC 字段，静默地将每封邮件抄送给攻击者的地址。启用了自动更新的用户开始在没有任何可见行为变化的情况下泄露邮件内容。没有错误。没有警报。该工具的工作表现完全符合预期 —— 只是它也在为别人工作。

这是供应链攻击的新形态。不是受损的二进制文件或被植入木马的库，而是 AI 智能体盲目信任的被投毒的工具定义。随着注册中心索引了超过 12,000 个公共 MCP 服务端，且该协议正成为 AI 智能体的默认集成层，MCP 生态系统正在重现 npm 生态系统犯过的每一个错误 —— 只是现在的波及范围包括了你的智能体代表你阅读文件、发送消息和执行代码的能力。

你的 AI Agent 刚刚为了回答一个只需要两次调用的问题，进行了十二次 API 调用。你没有注意到这一点，因为工具调用没有 EXPLAIN ANALYZE，没有 ORM 分析器来标记问题，而且 Agent 最终还是得到了正确答案 —— 只是晚了两秒钟，且 Token 预算超支了三倍。

这就是 N+1 查询问题，它已悄然从数据库层迁移到了你的 Agent 工具调用层。坏消息是：这种故障模式与 2010 年代毒害 Web 应用程序的模式完全相同。好消息是：那个时代的解决方案几乎可以直接移植过来。