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

两个小时的课后作业和 45 分钟的算法面试从来都不是重点。它们只是代标（proxies）。课后作业代表的是“这个人能否交付功能”，而白板面试代表的是“这个人能否在压力下分解问题”。二十年来，这些代标运作得相当不错，以至于大多数团队都停止了对它们的质疑。它们的管理成本低、易于评分，并且与你真正关心的能力大致正相关。

编程 Agent 破坏了这种相关性，但没有破坏形式。面试照常进行。它仍然会产生一个分数。这个分数看起来仍然像是有意义的信号。但面试所衡量的东西与工作所需的能力之间的差距已经拉大到如此地步，以至于一个合格（green）的结果几乎证明不了任何东西——而大多数招聘流程还没有意识到这一点，因为表面上没有任何失败的迹象。

这是一种悄无声息的失效。不是过程崩盘了，而是一个过程在它的假设前提不再成立后仍在继续运行。

打开一个生产环境中的智能体，在用户输入第一个字符之前，数一数上下文窗口里已经有了什么。有一段由平台团队负责的系统提示词（system prompt）。有工具定义——可能有 40 个甚至更多——每一个都包含名称、描述、JSON schema、字段级文档以及一些枚举值。有一段检索到的示例，是搜索团队为了提升某个评测指标而加入的少样本（few-shot）示例。有来自信任与安全团队的 6 行安全指令，来自设计团队的 4 行格式规则，还有一段某人在处理故障时添加但没人删除的领域术语表。

加在一起，智能体启动时就有 30,000 个 token 的开销。在连接了三个 MCP 服务器的配置下，这个数字通常会更糟糕——一个被广泛引用的测量结果显示，三个服务器占用了 200,000 token 预算中的 143,000 个，在对话开始前就消耗了 72% 的窗口。这一切都没有错。每一行都是由为了解决实际问题的人添加的。而这恰恰就是上下文窗口正在被摧毁的原因。

演示很顺利。智能体（Agent）回答了那个难题，流畅地串联了四个工具调用，生成的一段文字让全场安静了片刻，直到有人喊出“发布吧”。没人问成本是多少。没人问它运行在哪个模型上，你在成功之前尝试了多少次输入，也没人问当一千个人同时使用它，而不是你周二独自坐在办公桌前时会发生什么。

那场演示刚刚变成了一份契约。不是书面的——而是更糟。它成为了一个隐形的基准线，领导层、销售和客户都会据此来衡量最终发布的产物。而这份契约的条款是由一个你根本负担不起的系统设定的。

演示经济学与生产经济学之间的差距是真实且巨大的，而且在做出承诺之前几乎从未被定价。Gartner 预计到 2027 年，超过 40% 的智能体 AI 项目会因为成本超支而被取消。2026 年 3 月的一项调查发现，78% 的企业已经启动了智能体试点项目，但只有 14% 将其扩展到了全公司范围。试点失败并不是因为技术行不通，而是因为那个行得通的版本从来就不是任何人能够部署的版本。

有一种特定的会议，通常发生在令人印象深刻的智能体（Agent）演示大约六周后。原型演示了订机票、重构模块、核对发票——现场演示，一次成功，就在利益相关者面前。大家都认为它可以上线了。接着有人调取了生产数据，发现那个“好用”的智能体每完成 40 个任务就会产生一张工单，每几百次就会产生一笔退款，还留下了一堆没人能解释的半成品状态。项目没被砍掉，但它卡住了。而且到现在还卡在那儿。

这就是从演示到生产的悬崖，也是智能体项目失败最常见的方式。悬崖并非由糟糕的模型或懈怠的团队造成的。它源于一个度量错误：将 90% 的成功率视为完成了 90% 的上线工作。事实并非如此。一个 90% 准确率的智能体是一场成功的演示，但对于大多数真实工作流来说，它是一个无法上线的产品。2025 年登上头条的 MIT NANDA 报告指出，95% 的企业生成式 AI 试点项目没有产生可衡量的损益（P&L）影响——这就是在大规模范围内统计出的悬崖现状。

看看大多数智能体（Agent）评测集是从哪里来的。有人构建了智能体，向团队演示，演示成功了，于是演示脚本就变成了评测套件。那些通过评审的案例，正是有人已经亲眼看到它们运行成功的案例。评测集在构建之初，几乎就是“快乐路径”（Happy path）的录音——即在截屏当天成功运行的那一段工具调用序列。

所以，当仪表盘显示智能体得分为 94% 时，它实际上是在说：它通过了我们能想象到的案例。它完全没有提及搜索 API 在多步计划中途返回 429 错误的情况，或者用户推翻了两轮前设定的约束的情况，亦或是检索结果为空，智能体必须在胡乱猜测和承认不知道之间做出选择的情况。这些情况并非没有通过你的评测。它们压根就没在评测里。

这就是黄金路径偏见（Golden-path bias），除非你刻意对抗，否则它就是智能体评测套件的默认形态。解决方法不是增加案例数量，而是增加不同种类的案例——这些案例应根据失败模式（Failure mode）来选择，从生产环境中收集，并针对刻意引入的故障进行压力测试。

一位客户曾因一次退货收到了三次退款。这不是因为模型幻觉出了某种政策，也不是因为人类填错了表单——而是因为退款工具超时了两次，智能体随之重试了两次，而每次重试都发起了一个全新的请求，导致支付处理器根本无法识别这其实是它处理过的工作。三个干净的 HTTP 200。三次真实的资金转移。智能体完全按照指令行事：当调用失败时，重试。

这个 Bug 不在模型中。Bug 出在一个从未发送的 Header（标头）中。

重试是智能体最自然不过的本能。工具调用返回错误，或者更糟，什么都不返回，而循环系统的直觉——无论是编码在框架、提示词还是模型自身的训练中——就是重新尝试该动作。这种直觉对于“读”操作是正确的，而对于“写”操作则是灾难性的。一个韧性十足的智能体与一个会向客户重复收费的智能体之间的区别，不在于智力高低，而在于每一次改变状态的工具调用是否携带了幂等键（Idempotency Key），以及另一端的系统是否真正履行了它。

这张故障工单具有只有真实事故才具备的典型特征。在 02:14，支持代理关闭了一个本应进入 30 天宽限期的客户账户。客户发现了。工单落到你的桌面上，“复现步骤”一栏下面只有一行字：未知。

你打开追踪记录。你看到代理调用了 close_account 而不是 set_grace_period。你看到工具执行成功了。你看不出的是模型为什么选择了那个分支 —— 而且当你通过同一个代理重新运行同一条客户消息时，它做出了正确的选择。做了两次。现在的事故复盘报告中，原本该写根本原因的地方出现了一个段落大小的空洞，而你唯一能诚实写下的只有“无法复现”。

内部 API 依赖于一种默契而存在：没人会写下契约，因为每个人都已经心知肚明。那些碰巧存在的字段、调用者在暗地里解析的报错、返回空列表而非 404 的 200 响应 —— 这些都是关键的承重行为。而维系这些行为的基础是，你可以叫出每个调用者的名字，并在做出任何更改之前通过 Slack 联系他们。这种安排一直有效，直到它失效的那天。

当你将一个智能体（Agent）连接到该 API 的那天起，这种默契就失效了。这并非因为智能体怀有恶意或粗心大意，而是因为智能体是一个你无法触及的调用者。它没有 Slack 账号。它没有阅读你的迁移说明。它依赖于从示例载荷或 Schema 快照中吸收的响应形态，并且在你早已更新版本后，它仍会长期依赖这些形态。

一个令人不安的事实是，“内部”从未是 API 本身的属性。它其实是调用者列表的属性。将列表缩减到你认识的人，API 就是内部的；一旦增加一个你无法协调的参与者，API 就是公共的 —— 这意味着你需要承担“公共”一词所暗示的所有严谨规范，尽管你并没有构建任何本应具备的基础设施。

追踪单个质量信号在现代 AI 流水线中的路径。一个智能体（Agent）起草回复。第二个模型对其进行评审，打出 9 分（满分 10 分）。该评分被记录下来。在季度末，这些记录的评分成为新的评估集（eval set），而下一个模型则针对该评估集进行微调以获得高分。现在问一个显而易见的问题：在这一闭环中，人类在哪一个环节审视过实际输出？

在许多流水线中，诚实的回答是：无处寻觅。执行工作的智能体由另一个智能体评审，而该评审者的结论又会作为下一轮评估的输入。这个回路是封闭的。它持续运行，生成仪表盘，而仪表盘显示一片绿色（一切正常）。然而，它在任何阶段都不包含对现实情况的衡量。

当一个智能体（agent）加入你的团队时，每个工程经理脑海中最接近的类比就是新员工。因此，应对策略显而易见：给它一个沙盒和只读日志，将最初的任务范围缩小，与其结对编程，预留一段磨合期，并随着信任的累积让它承担更重的工作。这听起来很负责任。这感觉就像是你把上一个初级工程师培养成高级工程师时那种耐心的管理方式。

这也是一个范畴错误（category error）——它不只是一个略显不完美的类比，而是一个错误的类比。初级工程师是一个还不太了解你系统的人。而智能体是一个无状态的函数，无论接触系统多少次，它永远都不会真正“了解”你的系统。这是两种完全不同的事物，适用于前者的管理直觉会在无形中让你错配注意力。

这之所以重要，是因为这个隐喻不仅会产生误导，还会让你把精力投在错误的地方。“培养智能体”并不是一种策略。智能体是固定的，你真正能改变的一切都存在于它之外。

观察一名开发者使用 Agentic 编程工具一小时，你会看到同一个动作重复四十次：弹窗出现，“允许 Agent 运行 git status 吗？”，手在眼睛读完之前就移到了批准按钮上。到第四十次提示时，提示内容根本没被阅读。它变成了一个用户学会全速通过的减速带。

这是“人机回环”（human-in-the-loop）的一种无声失败。架构图上仍然显示人类在把控每一个危险动作。审计日志仍然记录着对每个命令的明确批准。但人类已经停止了评估。他们变成了一个接入控制流的生物版 “yes” 函数 —— 虽然身在回路中，却不贡献任何判断。权限提示本应是一项安全控制，它却退化成了附带确认对话框的系统延迟。

Prompt 缓存被宣传为一种稳赚不赔的方案。缓存长期的共享前缀——你的系统提示词、工具定义、检索到的上下文——只需为变化的短尾部分支付全额费用，然后看着账单下降。数字是真实的：缓存读取的成本大约是新鲜输入 Token 的十分之一，因此具有大量稳定前缀的工作负载，其输入成本可以降低 80% 或更多。团队因此采用它，因此调整它，并用单一指标来汇报：缓存命中率，且趋势向好。

这种表述掩盖了一个事实：你刚刚划定的边界——缓存前缀与非缓存尾部之间的界线——并不是一个计费旋钮。它是一个正确性边界。缓存断点之上的所有内容都是系统认为可以在请求之间互换的内容。如果你为了最大化命中率而划定这条线，你就是在让财务指标来决定你的 Prompt 中哪些事实可以在用户之间、租户之间以及跨时间共享。这是一个隔离决策，理应有目的地做出。

这种失效模式是隐蔽的，因为它永远不会报错。如果缓存命中提供了一个由另一个用户概况塑造的上下文，它会返回一个格式完全正确的响应。如果缓存命中提供了一个在缓存预热时为真、但在重用时已失效的个性化信息，它会返回一个自信、连贯但错误的答案。你的延迟图表或错误率不会有任何波动。唯一的信号是看起来 非常棒 的命中率——因为 Key 太粗颗粒度了。