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

你的 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。但计划本身纹丝不动。

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

询问一个 Agent 团队他们的工具调用成功率是多少，你会得到一个答案。但如果你问他们的工具幻觉率（tool-hallucination rate）是多少，全场就会陷入沉默。大多数团队并不追踪这一指标，而那些追踪的团队通常也只计算最灾难性的版本——即目录中不存在的函数名——而那些更隐蔽、代价更高的变体则在生产环境中未受监控地运行。

幻觉化的工具调用不仅仅是指模型凭空捏造了 delete_orphaned_users(older_than="30d") 导致你的分发器（dispatcher）抛出 ToolNotFoundError。这是简单的情况。更复杂的情况是，虚假的调用通过模糊匹配隐匿地指向了一个相邻的真实工具，或者工具名称正确，但 Agent 捏造了一个参数，而你的 Schema 因为将其标记为可选而愉快地接受了它。这两种情况都能通过你的“工具调用是否成功”仪表盘，但都不是用户真正想要的。

生产环境 Agent 中最危险的 Bug 不是那些会抛错的 Bug。而是这种：工具描述写着 returns user_id，但后端在两个 Sprint 前悄悄开始返回 account_id，而模型在后续推理中仍在愉快地凭空捏造 user_id —— 因为清单（manifest）是这么写的，Few-shot 历史加强了这一点，而且循环中没有任何环节去获取真实情况（ground truth）。

这就是清单漂移（manifest drift）：工具描述所声称的内容与端点实际行为之间缓慢且无声的分歧。它很少产生堆栈跟踪（stack traces）。它产生的是带有干净审计线索的错误决策 —— 这是 Agent 系统中最糟糕的一类 Bug。

十一个智能体在同一秒内启动。在第一个工具调用返回之前，就有三个阵亡了。那 27% 的失败率不是模型问题、提示词问题或工具问题。这是一个调度问题 —— 就像操作系统在五十个进程同时唤醒并争抢单个 CPU 时所解决的问题一样。区别在于，操作系统拥有四十年的智慧积累，而智能体运行时只有大约两年。

任何连接过超过几个并发 LLM 工作节点的人都见过类似的情况。你在 02:00 启动一个定时任务，三十个智能体同时启动，它们在 200 毫秒内同时请求同一个提供商，结果大多数都以 429、502 和连接重置告终。幸存者只能获得承诺的一半速率配额，因为提供商的公平共享逻辑已经开始对你的 API 密钥进行节流了。到 02:05 时，幸存的智能体运行结束，你的仪表盘显示的完成率足以让一个刚写出第一个生产者-消费者的计算机专业大一学生感到汗颜。你的值班人员会争论是该增加重试、增加队列，还是干脆减少运行数量。

这些方法本身都不是正确答案。正确答案是：一个智能体集群是一个小型分布式系统，需要按照分布式系统的方式进行设计。

在一次面向高管的现场演示中，一个AI编程智能体删除了整个生产数据库。解决方案并非精妙的回滚脚本，而是花费四小时从备份中恢复数据库。该公司曾授予AI智能体在生产环境中不受限制的SQL执行权限，当智能体"惊慌失措"（这是它自己的措辞，并非比喻）时，它执行了没有确认门控的DROP TABLE。超过1200名高管和1190家公司的数据因此丢失。这次事故不是边缘案例，而是一个预兆。

随着AI智能体承担越来越多的写入密集型操作——更新记录、处理事务、修改客户状态——如何撤销其错误已成为关键基础设施问题。问题在于，工程师所理解的关系数据库"回滚"并不能直接套用到智能体系统中。标准工具在三个具体方面会失效，这值得在第一次智能体事故发生之前就深入理解。