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

一个智能体用简洁明了的文字告诉你，它检查了用户权限，查阅了策略，确认请求在范围内，并执行了操作。法务阅读追踪记录（trace）。审计人员阅读追踪记录。你的事故复盘也在阅读追踪记录。每个人都阅读同一段话，并且每个人都感到满意。

他们中没有人知道权限检查是否真的运行了。这段文字是叙事的证据，而不是执行的证据——而这两者之所以会被混淆，正是因为叙事足够流畅，让人感觉像是证明。Anthropic 自身关于推理模型忠实度的研究发现，当 Claude 3.7 Sonnet 收到关于正确答案的提示时，平均只有约 25% 的时间承认使用了该提示，而在有问题的类别（如针对评分者的 trick、不道德的提示）中，这一比例低至 19%–41%。模型的陈述推理与其真实行为在大约一半或更多的时间里是不一致的，即使是那些被明确训练以展示思考过程的模型也是如此。

一个规划器智能体输出了七个步骤。每一个看起来都很合理。编排器分发了这些步骤，前三个返回了值，第四个在等待第五个，第五个在等待第七个，而第七个——埋藏在规划器散文般描述的第三行里——正静静地等待着第四个。没有任何东西被锁定。没有触发过任何 EDEADLK。智能体消耗了 40,000 个 token 来推理为什么第四步“花费的时间比预期长”，最终以一个温和、合理的道歉向用户宣告放弃。

这就是你的智能体无法察觉的死锁。它不是操作系统课程中的那种经典死锁——这里没有互斥锁（mutex），没有内核可以内省的资源图，也没有你的技术栈中任何人能识别的持有者或等待者。依赖关系存在于规划器生成的英语句子中，循环形成于潜在语义而非任何数据结构中，而故障模式看起来与“模型正在努力思考”无异。经典的死锁检测在这里毫无用处，但代价是相同的：工作流停滞，token 蒸发，而你的 trace 什么也不会告诉你。

一个调度代理将客户的入职电话订在了周二，而不是周三。调查花费了两天时间。Prompt 没问题。模型没问题。日历工具也没问题。错误在于系统 Prompt 携带了一个早一小时的 current_time 字段，当时请求正通过一个在 UTC 午夜前刚刚构建的缓存前缀（cached prefix）进行路由。当代理解析出“明天上午 10 点”并调用预订工具时，“明天”所指的日期对于东京的用户来说已经是“今天”了。

代理根本无法察觉。它没有任何感知手段。LLM 没有时钟。它们只有你在 Prompt 中提供给它们的字符串，并且它们会像对待用户问题一样权威地对待这个字符串——也就是说，完全信任，不加怀疑，也没有第二个来源可以进行交叉比对。

大多数团队在抽象层面都知道这一点，但仍然将注入的时间戳视为日志字段：某种有则更好、渲染到系统 Prompt 中提供上下文、不属于任何人的明确责任、不属于任何人的正确性边界的内容。这种构想是错误的。时间戳是一个正确性边界。每一个依赖于“现在”的代理行为——调度、过期、重试窗口、“最近”、“明天”、“五分钟内”、检索文档的新鲜度检查——都运行在你生成的时间管道之上，并继承了该管道所拥有的每一个 Bug。

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 中，比如规划、拒绝，或是关于变通方案的“热心”建议。