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

每个智能体 (Agent) 架构图中都有一个标记为“上报给人类 (escalate to human)”的方框。它用一条整洁的箭头画出，既能让评审人员满意，又能让系统显得安全。然而，架构图从未展示过箭头另一端的人——他们是否存在、是否醒着，以及是否能在智能体耗尽耐心之前给出答复。

人机回环 (Human-in-the-loop) 被当作一种设计模式来推销。但在生产环境中，它的表现更像是一个人员配置问题。这种模式假设有人在随时待命；而人员配置的现实是，上报请求并不会在人类刚好有空时出现——它们有自己的“时间表”。比如凌晨 2 点，当夜间批处理任务触发护栏 (guardrail) 时出现的爆发式请求。或者是午餐时间，当一半评审员都不在座位上时产生的长尾延迟。又或者是细水长流般的请求量，在不知不觉中超出了那支在演示阶段看起来绰绰有余的双人团队——毕竟在演示阶段，智能体每天只处理 10 个请求，而不是 1 万个。

“我们有上报路径”与“上报得到响应”之间的鸿沟，正是智能体系统发生故障且评估 (eval) 无法捕捉的地方。评估衡量的是智能体是否正确地发起了上报，而从未衡量过是否真的有人在那里。

值班轮换制度是建立在一个承诺之上的：故障是可以复现的。警报触发，你重新运行请求，观察 Bug 发生，找到错误的提交 (commit)，然后回滚部署。这个循环的每一个环节都假设了确定性 (determinism)。同样的输入产生同样的输出，而输出要么是对的，要么是错的，其方式一目了然。

Agent 集群悄无声息地打破了这条链条上的每一个环节。故障发生了一次，其采样温度 (sampling temperature) 你无法重现，所处的上下文窗口 (context window) 也早已被垃圾回收。这里没有“错误的提交”，因为代码从未改变 —— 改变的是模型，或者是检索到的文档，再或者是用户措辞的方式超出了所有人的预料。你回滚了部署，但部署从来都不是问题所在。

于是警报发出了，一名工程师接手了。他们发现了在生产环境中运行 Agent 最令人不安的事实：他们拿到手的是一个无法单步执行 (single-step) 的系统，而摆在他们眼前的运行手册 (runbook) 却是为另一种完全不同的机器编写的。

一个智能体订错了机票。它给错误的客户发送了道歉邮件。它编写了一个数据库迁移脚本，删掉了一个仍有三个服务在读取的列。在每种情况下，模型都生成了一个看起来合理的动作，执行了它，然后继续运行。而在每种情况下，都有人承担了真实的代价——改签费、受损的关系，或是凌晨 2 点的故障排查。

令人不安的地方在于：大多数 AI 产品对于“谁来承担代价”这个问题没有答案。在设计评审中，这个问题从未被提及。它在以后才会显现，以支持工单的形式，一个接一个地出现在支持队列中——因为客户听起来很生气，而客服代表没有可以遵循的政策，只能即兴提供 40 美元的额度。将此乘以每月几千张工单，单位经济效益就会悄然腐烂——不是因为一次戏剧性的失败，而是因为一个无人关注的缓慢漏洞。

“模型犯了错”不只是一个支持升级。它是一个计费事件。而在智能体时代生存下来的产品，将是那些在收到第一张愤怒的工单之前就为这类事件做好了设计的产品，而不是那些靠感觉即兴退款，直到毛利变为负值的产品。

现在每个智能体 (agent) 框架都将“长期记忆”作为核心功能发布，每个团队都将其视为百利而无一害的好事。智能体记住了用户的偏好、之前的决策、项目上下文以及上周收到的修正，因此每次会话的起始状态都比上一次更“热”。演示效果令人难以抗拒：用户说一句“按照我的喜好设置项目”，智能体就照办了。没有人问那个显而易见的问题，因为这一功能的叙事框架在刻意回避它。

问题是：这一切何时会变得不再准确？

记忆存储本质上是一个缓存。它保存着关于一个并非静止不变的世界的事实。智能体在 8 个月前记录了“用户偏好 Postgres”，但团队此后已迁移到了另一个数据库。智能体记得“用户在增长团队”，而用户在 3 月份已经调岗了。智能体存储了一个简洁的对话总结，但该对话的前提在两条消息后就被修正了。记忆层在提取这些信息时，其自信程度和新鲜感与今早刚写下的事实完全一致。我们花了 50 年的时间才意识到，没有失效策略的缓存就是一个正确性漏洞 (correctness bug)。然后我们构建了智能体记忆，并在没有这种策略的情况下将其发布了。

你智能体系统提示词中的工具描述是一个六个月前的评估产物（eval artifact）。它说 search_pricing 返回“带有结构化定价的最新库存数据”，规划器（planner）对此深信不疑，因为自描述调优的那天起，提示词中的任何内容都没有更新过。而实际上，在过去的 40 分钟里，search_pricing 端点的 p95 延迟一直保持在 11 秒，因为上游供应商正在对你的账户进行限流。而那个被提示词描述为“可能略微陈旧”的更便宜的 search_cache 工具，只需 200 毫秒就能返回同样的答案。但规划器还是选择了 search_pricing，因为描述读起来仍和评估时一样，且规划器没有任何关于目前调用这两个工具成本的信号。

这就是静态工具描述的结构性失效。规划器是在根据一个已经发生变化的世界快照做出路由决策。工具选择实际上并不是一个能力问题——大多数生产环境中的智能体都有两三个在回答内容上高度重合的工具——它本质上是一个“等待成本”问题，而等待成本正是你的提示词模板所看不见的东西。

一位资深工程师向 planner 提示词（prompt）提交了一个只有四个单词的修改——“if uncertain, ask first”（如果不确定，先询问）。Planner 自身的评估集（用于评分计划是否合理）提升了 0.5 分。他们合并了代码。两周后，verifier 的评估显示通过率出现了 3 个百分点的回归，且没人能复现。根本原因在于：planner 现在会提出更多澄清性问题，executor 在第二轮收到的任务描述变短了，而 verifier 的评分准则（rubric）是针对之前 executor 较长的输出进行隐式调优的。一个没人标记为高风险的修改，一次性改变了下游的三个分布。

当你把智能体（agent）内部的提示词看作一个扁平的文件文件夹，而不是一个带有“边”（edges）的图（graph）时，就会发生这种情况。提示词有负责人，但它们之间的“边”却无人看管。

当单次尝试（single-pass）的智能体（agent）不再足够好时，默认做法是将其包装在一个自我批评循环（self-critique loop）中。生成、批评、修正、重复。我接触的大多数团队都假设评估（eval）的提升将与修订轮次呈大致线性关系，并止步于此。但数据往往并不如人愿。到第三轮自我批评时，准确率仅提高两三个百分点，而 Token 成本却增加了 3–4 倍，而且第一轮没发现的失败模式（failure modes），在第三轮通常也发现不了——因为产生错误答案的上下文，正是被要求找出错误的那一个。

另一种形式效果更好且成本更低：让第一轮作为“浪费式”的探索，将其丢弃，然后在干净的上下文中基于学到的经验运行第二轮。称之为“二稿模式”（second-draft pattern），或“先探索后提交”（explore-then-commit）。第一稿允许草率、走弯路、堆积草稿产物、追逐最后证明是错误的假设。第二稿是受限的——它获取提炼后的发现（distilled findings），并产出干净的执行。在那些倾向于使用自我批评的任务中（如多步推理、涉及多个文件的代码、研究综述），这种双轮形式在质量和成本上通常都优于 n 选 k 的自我批评。

每个将智能体（agent）投入生产环境的团队，最终都会遇到类似的事故。智能体进入了一个无法退出的状态。它在六个小时内反复调用同一个工具，只是参数在表面上略有不同。它在两个前提条件互斥的计划之间摇摆不定。它每隔两百毫秒重试一次瞬时的 429 错误，一直持续到天亮。它生成了一个包含百万 token 的计划，却从未执行。等到有人察觉时，token 账单已达四位数，下游 API 被限流，客户会话已超时十二次，而值班工程师正被针对同一根因的三个不同告警狂轰滥炸。

每个团队首先想到的解决方法都是步骤计数预算（step-count budget）。将智能体限制在 20 次迭代。限制在 50 次。定个数字，然后上线。步骤预算确实让事故报告消失了，但它并没有消除底层问题 —— 一旦你理解了其中的机制，你就会发现步骤预算相当于智能体世界里的家用保险丝：它是在损害造成之后才熔断的，保险丝盒本身现在成了维护负担，而下次发生故障时，你的本能反应是换一个更大规格的保险丝，而不是去追究到底哪里短路了。

针对你的智能体记忆层的第一次合规升级，几乎从不以监管机构信函的形式出现。它往往是以你企业级销售工程师发来的一张 Jira 工单的形式出现的，上面写着：“客户的隐私团队正在阻碍合同签署——他们想知道在你的系统中‘忘记我的用户’到底是什么意思，并且他们要求在周五前给出书面答复。”这张工单通常在记忆层发布 6 到 12 个月后送达，而构建该功能的工程团队在读完问题的那一刻就会发现，他们不小心构建了一个没有任何记录管理系统（records-management system）应有原语的记录管理系统。

这是智能体产品中长期记忆的结构性问题。构建它的团队通常会针对记忆功能的卖点进行优化——检索质量、延迟、存储成本，以及让助手感觉很懂用户的个性化体验。在设计评审中，没有人会去估算同时被构建出来的那个并行系统的代价：一个按用户、按租户、跨区域的数据存储，它带有保留义务、删除语义、审计导出要求，而且从第一个用户数据进入其中的那一刻起，监管机构的倒计时就开始了。记忆并不是一个功能。它是每个隐私制度、每份企业采购调查问卷以及每个被遗忘权（right-to-erasure）请求最终都会找上的运营界面（operational surface）。

第一代 AI 助手表现得很礼貌。你输入，它们回答。第二代则不再等待。它会观察你的日历、扫描你的收件箱、阅读你的代码库活动，并在你提出任何要求之前就抛出“你应该知道这个”之类的打扰。这种宣传极具吸引力，演示也令人着迷。但一旦这些功能上线，留存曲线却并不理想。

发布会幻灯片上没人会放这样一个数字：用户对来自所有渠道的未经请求的 AI 更新有一个每日上限，总和大约只有三到五个。如果一个主动式智能体在一周内发出了第十条通知，那么用户在周五就会将其静音，并在下个月将其卸载。这不仅是一个 UX 打磨问题，更是整个主动式 AI 领域的架构盲区，它值得拥有一个名字：通知预算（notification budget）。

只要为你的智能体连接一个 GitHub MCP 服务端，在用户输入一个字之前，你可能就已经消耗了 1.2 万到 4 万个 token。连接一个文件系统服务端、一个日历、一个数据库、一个内部 CRM 以及一个第三方工具目录，据测算，一个重型桌面配置的纯工具披露 (tool disclosure) 就会产生 6.6 万个 token —— 这几乎占了 Claude Sonnet 200K 上下文窗口的三分之一，而且在每一个规划轮次 (planning turn) 都要付费。智能体还没开始干活，用户还没开始提问，账单就已经开始计费了。

这就是“披露税” (disclosure tax)，它是目前交付的智能体系统中定价最低估的条目。团队添加 MCP 服务端的方式就像曾经添加微服务一样 —— 每一个集成看起来都像是一个免费的组合原语 (composition primitive)，采购理由也顺理成章（“更多工具 = 更多能力”）。而单位经济效益仪表盘 (unit economics dashboard) 从未反映出每个服务端的成本，因为成本隐藏在 token 桶里，没有人将其归因于连接器。结果是，每当有人添加另一个集成时，智能体就会变得更慢、更笨、更贵，而团队却通过重新调整提示词 (prompt) 和催促模型厂商发布新版本来解释这种退化。

一名产品市场经理 (PMM) 在发布简报中写下了“AI 智能体 (AI agent)”。新闻稿发布后，将其描述为具备自主决策能力。六周后，工程团队正盯着 Jira 看板上满满的“智能体可观测性”工单，而这些是他们从未针对一个本质上只是“单个提示词后接硬编码工具调度”的系统所规划的。没人撒谎。没人犯技术错误。团队只是意识到，“智能体”这个词并非一种描述——它是一个戳记 (stamp)，而这个戳记带有的运维影响，无论实现方式是否合理，工程团队都必须承接。

这就是 Gartner 如今所谓的“智能体洗白 (agent washing)”的内部版本。外部版本——供应商为了追赶炒作周期将聊天机器人重新包装为智能体——往往会获得媒体关注。而内部版本则更加隐蔽且昂贵，因为这笔账落在了那些在术语被批准时无法反驳的人身上。