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

Agent 以“全部搞定——如果需要任何修改请告诉我！”结束它的回合，而你的编排器必须决定是将工单标记为已解决、启动下一次交接，还是重试。这句话不是一个返回码。它只是一个训练出来的、为了在聊天结束时听起来很贴心的礼貌语，而它下游的每一行自动化代码都继承了这种模糊性。那些将此视为解析问题的团队会编写捕获 \b(done|complete|finished)\b 的正则并收工。而那些在生产环境中运行 Agent 的团队最终会明白，完成是一个事件，而不是一种情绪。

失败模式通常是双峰且枯燥的。要么是 Agent 在未完成时宣布完成——过早终止——而编排器愉快地在一个半成品产物上推进工作流。要么是 Agent 确实完成了，但表述方式与检测器不匹配（“我已经落地了更改，尽管边界情况的测试仍然不稳定”），编排器于是发起重试，导致重复工作、产生重复的副作用，有时甚至会推翻成功的第一次尝试。这两种模式都会静默地退化。在有人阅读 Trace 并注意到 Agent 说了“我想这些就是全部了”而计费系统将其视为一次提交（commit）之前，任何仪表盘都不会显示异常。

解决方法不是更智能的解析。而是给 Agent 一个结构化的终止方式——一个具有枚举状态、原因代码和你的流水线可以路由的句柄（handle）的“完成工具（done-tool）”——并将编排器改为等待该事件，而不是监听聊天流。

你的 Agent 通过了 92% 的评估测试集。你发布了它。在上线一小时的真实流量中，发生了一些从未在任何追踪（trace）中出现过的事情：Agent 在频率限制（rate-limit）重试风暴中停滞不前，一个客户在工具响应中看到了另一个客户的草稿邮件，你的模型供应商连接池处于 100% 的占用率，而 CPU 却处于闲置状态。这些失败没有一个源自模型。它们存在于你测试的方式与生产环境运行方式之间的鸿沟中。

这个鸿沟表现为同一种形式。你的评估工具（eval harness）在一个固定数据集上一次循环一个 Agent。而你的生产环境则在共享基础设施上同时运行许多 Agent。顺序评估隐藏了每一个前提条件为“两个事物接触同一个资源”的 Bug。在你将对抗性并发（adversarial concurrency）构建到评估工具本身之前，这些 Bug 只会以紧急运维（on-call）报警的形式出现。

你的智能体刚刚花了 90 秒和几美元来修改一个只有三行代码的函数。在提交编辑之前，它列出了两个目录，打开了测试文件，运行了 grep 来查找调用者，读取了配置模块，检查了 CI 工作流，还调出了一个从未用过的类型定义。它产生的 diff 只有四行，而产生这个结果的 trace 却包含了 43 次工具调用。

这就是“首触工具损耗”（First-touch tool burn）：一种当智能体被分配了一个范围明确的任务时，却表现得好像每个请求都是一个研究课题的模式。探索行为先行且力度极大 —— 在向文件写入单个字符之前，60% 到 80% 的 token 预算都花在了列出目录、grep 和读取上。团队在第一次查看 trace 时发现了这一点，并意识到智能体为一个两分钟的任务做了相当于两小时的入职培训。

这种行为并非某个特定模型的 bug。它是这些系统的训练和评估方式的必然产物，与生产环境发生了碰撞。而生产环境衡量的是训练从未衡量过的东西：这项工作是否便宜到值得去做的程度。

在智能体（agent）系统中，最危险的失败并非那些大张旗鼓的报错。而是智能体自信地宣布“任务完成”，并返回一份它从未执行过的工作摘要。文件从未写入。Webhook 从未触发。数据库行仍保持一小时前的状态。但追踪记录（trace）显示为绿色，完成计数器在增加，仪表盘告诉领导层新功能运行良好。

这就是“幻觉成功”（hallucinated success）问题，它是生产环境中最难捕捉的一类漏洞，因为它能避开你拥有的所有廉价信号。智能体没有崩溃。它没有超时。它没有返回错误。它叙述了一个合理、连贯且完全虚构的成功执行过程。你的可观测性堆栈是为捕捉嘈杂的失败而构建的。而无声的成功看起来与真正的成功一模一样，直到用户注意到输出是错误的。

你的 Agent 每五分钟调用一次的 MCP 服务，其最后一次 commit 还是在八个月前。它所封装的上游 API 在二月份推出了新的身份验证模型。目前有 47 个未解决的 issue，其中 12 个被标记为安全风险。维护者的 GitHub 账号自十月以来就没有过任何活动。你的 Agent 仍然能够连接，仍然能够接收工具描述，仍然能够执行调用 —— 而在无声无息中，每一次调用都流经一段无人看管的基础设施。

这就是 MCP 被遗弃的现状。不是恶意的卷款跑路（rug pull），也不是被攻破的软件包，仅仅是由于疏忽。有人在 2025 年发布了一个有用的服务，被大家采用后，便转向了其他项目。该服务之所以能继续运行，是因为没有任何因素强行让它崩溃。直到它彻底崩溃 —— 而到那时，你的 Agent 每五分钟跨越一次的信任边界其实早已失效。

大多数团队采用社区 MCP 服务的方式与采用 npm 包的方式如出一辙：运行 install 并阅读 README。这种思维模型在面对 MCP 时失效了。在 MCP 中，依赖是一个动态的信任边界，LLM 在循环中携带凭据，并在生产数据上对其进行调用。

智能体对话记录中最危险的一句话不是幻觉。而是四个冷静的词：“我没有找到。”智能体听起来在认知上表现出谦逊。听起来像是完成了尽职调查。对于任何下游读者或调用者来说，这听起来完全像是一个事实。然而，这句话并没有提供关于该事物是否存在的信息。它只提供了关于特定工具在使用特定查询、咨询特定索引（而智能体恰好在那个时刻有权访问该索引）时发生了什么的信息。

在这两种解读之间，隐藏着一个随时可能发生的生产事故。支持智能体告诉客户“我们没有你的订单记录”，因为同步延迟导致写入只读副本的时间推迟了 90 秒。编码智能体声明“该模块没有测试”，因为它搜索了一个不包含测试文件夹的目录。合规智能体回答“档案中没有先前的违规记录”，因为审计索引尚未摄取上周的报告。在每种情况下，智能体的输出在语法上都是一种否定，但在认知上，它只是一个被重新表述为断言的“耸肩”。

当一个生产环境中的 Agent 首次运行 40 分钟，并在 40 个步骤中的第 27 步遇到 401 错误时，故障复盘的情形几乎总是如出一辙。房间里有人会问为什么令牌没有刷新。另一个人指出刷新逻辑是存在的，但它存在于 HTTP 客户端中，而 Agent 的工具封装层（tool wrapper）从未与之对接。第三个人注意到，即使触发了刷新，Agent 的两个并行工具调用也会尝试在同一瞬间轮换同一个刷新令牌，从而导致会话崩溃。大家纷纷点头。然后，团队在接下来的一周里，为一个假设请求会在 800 毫秒内完成的架构苦哈哈地补齐凭据生命周期管理。

OAuth 的设计初衷是让访问令牌（access token）的寿命长于使用它的请求。长运行 Agent 颠覆了这一假设。现在的请求——实际上是在数分钟或数小时内编排的数十次或数百次工具调用链——比令牌活得更久。整个行业花了十年时间围绕“短请求”假设构建库、代理和刷新流，而这些几乎都无法干净地移植到 Agent 循环中。

智能体（Agent）打印了一个五步计划。第三步是“从发票服务中获取用户的账单历史”。追踪链路（Trace）显示，第三步实际上调用了订单服务，关联了一个过时的客户表，并产生了一个看起来正确的数字。输出通过了评估（Eval）。六个月后，财务部门发现仪表盘与事实源（Source-of-truth）悄然出现了 4% 的偏差，复盘时才发现了这次回归（Regression）。

没有人写出 Bug。规划器（Planner）写下了一份执行器（Executor）从未签署的契约。

这就是“计划与执行”架构在其优雅的架构之下所掩盖的失败模式。这种模式被推销为一种赋予智能体长程连贯性的方式：由一个强大的模型起草计划，较弱的模型执行步骤，计划起到脚手架的作用。在实践中，计划只是一种“营销产物”——在 t=0 时发出的一个看起来合理的预告，随后在 t>0 时发生的每一件趣事都会迅速令其失效。追踪链路显示了计划，追踪链路也显示了行动。但几乎没有人去衡量两者之间的距离。

一个免费层级用户打开你的支持聊天窗口并询问：“你能为订单 #4821 退款吗？”你的智能体（agent）回答：“我无法办理退款 —— 这是管理员才能执行的操作。你可以通过控制面板进行升级，或者我可以为你转接。”拒绝是正确的。退款工具上的 ACL 是正确的。而你刚刚告诉了一个匿名用户：存在一个名为 issue_refund 的工具，它受名为 manager 的角色限制，并且你的平台接受格式为 #NNNN 的订单 ID。

你的规划器（planner）知道用户无法调用的工具。这种不对称性 —— 推理层可见完整目录，而动作层仅能执行部分目录 —— 正是大多数智能体权限控制（agent authorization）悄无声息出错的地方。工具边界处的 ABAC 能拦截未经授权的调用。但它无法拦截已经发生的“能力泄露”，这种泄露往往出现在前一个 token 中，比如规划、拒绝，或是关于变通方案的“热心”建议。

错误报告显示服务很慢。仪表板显示服务很健康。每分钟 Token 使用量处于层级上限的 62%，稳稳处于绿色安全范围内。然后你打开追踪（traces）查看形态：一个用户请求生成了一个规划步骤，该步骤发出了 11 个并行工具调用，其中 4 个是搜索扇出，每个都触发了子智能体，而这些子智能体又分别并行调用了 3 个工具——那个单一的“请求”现在正同时从 47 个不同的工作线程猛击你自己的 Token 桶。产品的其他 99 名用户被堵在它后面，收到了他们本不该得到的 429 错误。你的智能体正在对自己发起 DoS 攻击，而速率限制器（rate limiter）正在忠实执行你给它的指令。

这就是速率限制层级崩塌。你购买了为 HTTP API 设计的边界防御系统，在那样的系统中，一个请求等于一个工作单元；然后你把它连接到一个请求意味着深度未知且分支因子无界的树形系统前端。单一桶模型不仅无法提供保护，而且它的失败是隐形的，因为你的聚合数据从未突破任何限制。损害发生在尾部、相关的爆发中，以及那些恰好在时间上紧邻重度请求的专注用户身上。

强化思维在处理新颖的推理任务时表现出色。但在工具边界（即你的智能体必须选择调用哪个函数、何时调用以及传递哪些参数的时刻），同样的思维预算往往会适得其反。模型会权衡三个等效的工具，而快速模型原本只需要一个 token 就能消除歧义。它在原本不存在歧义的地方制造出听起来合理的歧义。它消耗了一千个推理 token 来反复质疑那个显而易见的 search 调用，结果最后还是调用了 search。你为一个不需要推理的决策支付了推理税。

这是 2026 年智能体系统中隐形的成本中心：问题不在于推理模型本身（其擅长领域的定价是合理的），而在于在错误的环节部署了推理模型。这种反模式（anti-pattern）就潜伏在显而易见的地方，因为顶层任务看起来很难（如“回答用户的问题”），所以团队将整个循环都包裹在深思熟虑的模式中，却从未意识到 80% 的思维预算都花在了对工具选择的微观决策上，而这些决策模型凭第一直觉就已经选对了。

打开一个智能体在长程规划任务中的追踪记录（trace），数一数模型写了多少次“让我重新考虑一下”、“经反思”或“更好的方法是”。现在，将它最终确定的计划与最初起草的计划进行对比。在我审计过的大多数追踪记录中，第二个计划其实就是换汤不换药的第一个计划 —— 同样的分解方式、同样的工具调用、同样的操作顺序，只是重命名了一些步骤标签并重新组织了理由的措辞。反思确实运行了。模型输出了看起来像是在重新考虑的 token。但计划本身纹丝不动。

这很重要，因为“带有反思”已悄然成为一种质量等级。团队在发布规划器时会加入一轮、两轮或三轮反思，并为此支付额外的成本。推理开支是真实且可衡量的。但计划层面是否真的发生了改变，几乎没有人去进行检测，而答案往往是：没有。