209 篇博文 含有标签「agents」

你的智能体集群（agent fleet）本周开启了 40 个拉取请求（pull requests）。你审查了其中涉及支付代码的 6 个请求，浏览了几个正好在你打开标签页时提交的请求，然后只要通过了 CI 测试，就将其余的全部合并了。如果有人问你的审查政策是什么，你大概会描述成类似上面的做法——但这根本不是政策。这只是一种“心情”（mood）。

数据表明大多数团队都处于同样的境地。最近一项针对流行开源仓库中智能体生成的拉取请求的大规模研究发现，61% 的请求完全没有任何审查记录；而在确实经过审查的请求中，大多数也仅由其他智能体进行审查。与此同时，产量仍在攀升：智能体现在生成 PR、文档、支持响应和工单的速度，已经超出了任何人类审查流程的设计初衷。审查所有内容是不可能的，而完全不审查则是玩忽职守。因此，团队在两者之间即兴发挥，既没有明确的规则，也没有衡量的覆盖率，更无法判断当前的审查力度是过于偏执还是草率鲁莽。

制造业在一个世纪前就解决了这个问题。20 世纪 20 年代，当西部电气（Western Electric）大量生产电话设备时，对每一个单元进行检查在经济上是不可能的，而运送未检查的批次又是不可接受的——于是贝尔实验室的统计学家们建立了“验收抽样”（acceptance sampling）：这是一门具有数学依据的学科，用于决定一批产品中需要检查多少、何时拒绝整批产品，以及供应商何时赢得了放宽检查的信任。它在二战期间演变为 MIL-STD-105 标准，随后成为 ANSI/ASQ Z1.4 和 ISO 2859-1，至今仍规范着港口如何验收一整箱货物。这与智能体集群的对应关系几乎是直截了当的，但在 AI 工程领域几乎没有人采用它。

每一个工程组织的每一个年度规划周期都运行在同一个隐藏的等式之上：路线图雄心除以工程师产出等于人员需求。这一规律存在了太久，以至于已经没有人再去专门记录它。你评估工作量，除以一个团队一年内能交付的成果，余数就变成了招聘计划。财务部门围绕它制定预算，招聘团队围绕它建立人才库，而经理们则围绕它规划职业生涯。

这个等式悄然失效了。在一个高度依赖 Agent（智能体）的组织中，工程产出的边际单位不再是另一名资深新员工——而是 Token 加上吸收这些 Token 产出内容的审核带宽。NVIDIA 现在给工程师分配的 Token 预算大约相当于其基本工资的一半，而 Jensen Huang 曾表示，如果一名年薪 50 万美元的工程师每年消耗的 Token 少于 25 万美元，他会感到“深感忧虑”。无论你是否认真对待这个具体的比例，结构性的核心点依然成立：公司现在可以通过两扇不同的门将资金转化为可运行的代码，而年度计划却只为其中一扇门保留了填写框。

每个构建 Agent 的团队最终都会遇到同样的瓶颈。系统提示词（System Prompt）起初只有 400 个 token。接着有人添加了数据库迁移检查清单。然后是复盘模板、部署运行手册、客户邮件风格指南。18 个月后，它变成了一个拥有 9,000 个 token 的巨石，没人敢去改动它，因为修改关于回滚流程的一行内容，竟然会降低 Agent 在支持工单中的语气表现。你构建了一个相当于 50,000 行的 main.c 的提示词——而且每个人都在对其进行静态链接。

直觉的反应是使用 RAG：将运行手册切片、嵌入（embed），然后按需检索。但这会以一种更隐蔽的方式失败。RAG 是为检索“事实”而生的，而事实在被碎片化时可以平滑退化——关于你计费模型的五个相关切片中检索到三个，仍然能告诉 Agent 大部分所需信息。但程序（Procedures）无法平滑退化。检索到 60% 的数据库迁移运行手册并不是 60% 有用，而是意味着一场生产事故。有第 1 到 4 步但缺失了第 5 步（“在切换前验证复制延迟”）比完全没有运行手册更糟，因为 Agent 现在的行为带着一种它尚未赢得的自信。

打开你的 Token 仪表板，针对其中的每一个工作负载问一个问题：是否有真人在等待这个响应？对于大多数在生产环境中运行智能体（Agent）的团队来说，诚实的回答是：至少有一半以上的账单并非如此。评估套件（Eval suites）、向量回填（embedding backfills）、每日报告生成、批量分类、隔夜代码迁移、昨日工单总结——这些任务都没有用户在盯着进度条。然而，几乎所有这些任务都流经交互式端点，以全额价格支付，并与那些真正对延迟敏感的请求竞争同样的容量。

每个主流供应商都会以一半的成本运行这些可延迟的工作。OpenAI 的 Batch API、Anthropic 的 Message Batches 以及 Gemini 的 batch 模式都为异步作业提供统一的 50% 折扣，以换取 24 小时的完成窗口。这种折扣不需要谈判，不需要承诺消费，也不需要工程上的壮举。它只要求你在架构中承认，某些工作是可以等待的——而大多数团队从未做出过这种让步，因为没有人将“延迟交付”作为一个设计决策。

我们以前看过这类戏码。多年来，抢占式实例（Spot instances）为云计算提供了 60–90% 的折扣，但大多数团队仍将所有业务保留在“按需（on-demand）”模式下。这并非因为节省的费用不真实，而是因为使用它们被迫面对一个令人不安的问题：我们哪些工作负载可以容忍中断？回答了这一问题的团队构建了检查点（checkpointing），并将计算账单削减了一半以上。没回答的团队则继续支付“凡事皆紧急”税。批处理层级是同样的岔路口，只不过坐标轴从“中断容忍度”变成了“延迟容忍度”——而且智能体工作负载每项任务消耗的 Token 是聊天机器人的 5 到 30 倍，这使得不作选择的代价要昂贵得多。

当依赖项损坏时，你的构建会失败。当临时规避方案变得不再必要时，什么都不会发生。这种不对称性正是为什么每一个运行超过一年的生产级 LLM 系统都带有它不再需要的脚手架——重试编排、输出修复解析器、强制思维链、复杂的任务分解、分块启发式方法——每一个都是为了弥补特定模型的特定弱点而构建的，而且每一个都在无声无息中比它所补偿的弱点活得更久。

令人不安的是，这不仅仅是一个像过期的特性标志（feature flags）那样的卫生问题。过时的脚手架不仅仅是消耗你的延迟和 Token。在最坏的情况下，它会主动将新模型限制在旧模型的上限内：你的分解逻辑将一个任务切分为六个步骤，是因为 2024 年的模型无法处理整个任务，而 2026 年的模型本可以一次性完成，现在却继承了六个在你构建的缝隙中丢失上下文的机会。

统计一下你的堆栈跟踪（stack traces）的阅读者。对于大多数内部工具，过去的答案通常是“偶尔有一位疲惫的工程师”。如今，你的错误输出的最大阅读者几乎肯定是一个处于重试循环中的语言模型。编程智能体（Coding agents）每天成千上万次地阅读你的 linter 警告、CLI 使用说明字符串、API 错误主体以及测试失败信息——频率远高于任何人类。而且与人类不同，智能体会字面理解每一个词。

这改变了错误信息的“本质”。它不再仅仅是失败的文档，而是注入到下一次尝试的上下文窗口中的指令——这是你几个月前编写的提示词，现在正引导着一群你从未见过的智能体集群。一个精确的错误能让循环在一次重试中收敛。而一个模糊或误导性的错误则会让智能体陷入恶性循环：错误的修复、--no-verify 的权宜之计、幻觉出来的参数标识、消耗殆尽的 token。如果你维护着一个工具、一项服务或一个构建系统，你其实已经在进行提示词工程（prompt engineering）了。你只是在错误字符串中进行的，而且很可能是无意为之。

你的团队采用编程 Agent 的那个季度，发生了两件没人会放在同一张幻灯片上的事情。吞吐量上升了 —— 更多的 PR、更多的合并代码、更多的工单被关闭。然而，你最资深的三位工程师却变慢了。这种慢不是因为偷懒，而是因为“溺水”。他们自己的提交量枯竭了，日历被评审任务填满，一对一面谈的主旋律也从“这是我交付的内容”变成了“我花了一整周时间在帮别人排障”。

这就是“资历倒挂”。那些本该通过 AI 获得更多杠杆效应的人，反而被它埋没了。这既不是动力问题，也不是工具差距，而是 Agent 改变工作形态后的结构性后果：它们让生成变得廉价，而让验证变得昂贵。验证正是你无法交给初级人员或其他 Agent 的那一项任务。

有一种 Agent 漏洞，当你孤立地观察任何单个组件时，它都不会出现。模型没问题，工具没问题，重试策略也没问题。纸面上的超时值甚至可以说很慷慨。然而，一个通常在 8 秒内完成的工具，却总是在一个已经在 7.9 秒时将其宣告为失败的 Agent 面前折戟。Agent 围绕一个从未发生过的“错误”重新规划，并启动了第二次调用，而第一次调用的结果即将与其发生碰撞。

漏洞不在任何一个框框里。它存在于两个没人同意应该同步的时钟之间的缝隙中。

用户点击停止。浏览器关闭了 SSE 连接。你的 AI SDK 触发了 onAbort。Agent 运行时检测到信号，停止向模型请求更多 token，并终止其循环。从你的代码库内部来看，这次取消显得非常利索。你所能看到的每个子系统都在执行正确的操作。

与此同时，两秒钟前，模型发出了一个工具调用（tool call）。运行时分发了它。工具的 execute 函数打开了一个连接到第三方 API 的 TCP 连接并发送了 payload。该 HTTP 请求仍在传输中，第三方的服务器仍在处理它，而第三方完全无法得知它所服务的对话已不存在。写入操作成功提交。用户的心智模型认为他们通过点击停止避开了该操作。下游系统的数据库则记录了完全不同的结果。

周一，一位新工程师加入了团队。到周三时，她已经搭建好了本地 Agent 环境：一个桥接到公司部署 API 的 MCP 服务，指向 Staging 环境，并与她的编辑器相连。入职文档引导她完成了 OAuth 流程。她粘贴到服务器环境文件中的令牌是同事发给她的——这与 CI 流水线用于发布到 Staging 环境的是同一个令牌。到周五，她已在共享办公空间与团队一起进行协作开发。

MCP 服务仍在运行。绑定在 127.0.0.1。无需身份验证。令牌已加载到进程中。她没多想，因为她并没在使用它。但那天访问任何网站的任何标签页，都可以通过她自己的浏览器与她的本地服务通信。共享办公空间 Wi-Fi 上的任何其他笔记本电脑也同样可以，因为她没注意到该服务实际上绑定到了 0.0.0.0。你的 CI 流水线用来推送到 Staging 的 OAuth 令牌，现在任何能诱导浏览器向本地 IP 发起请求的人都能触及——在 2026 年，这只需要一个弹窗。

本文讨论的就是这类故障：“我在笔记本上开发”与“我的笔记本是对手可以触及的服务器”之间的鸿沟。MCP 服务在设计上恰好处于这个鸿沟之中。大多数团队尚未察觉。

客户支持团队升级了一个问题：“你的助手以前能正确处理退款资格问题。但上周开始出错了。”值班工程师调取了对话记录，在开发账号中使用相同的模型标识符回放了完全相同的提示词（prompt），得到了正确的回答，于是以“无法复现”为由关闭了工单。两周后，另一名客户提出了同样的投诉。工程师再次在同一个开发账号中进行回放，结果依然正确。团队开始归咎于没人做过的提示词更改。

请求中的模型标识符从未改变。响应字段中的字符串与请求字段中的字符串匹配。评估套件在六周内一直保持绿色。生产流量使用的模型权重与评估套件使用的模型权重是两套不同的集合，而且在该账号的整个生命周期中一直如此——直到过去这六周，它们变成了同一套权重，而团队注意到这一点仅仅是因为客户先发现了。

安全审查称智能体（Agent）“代表”（on behalf of）用户操作。OAuth 令牌却有不同的说法，而审计日志也支持令牌的说法。

语言上的一点微小差别，在架构层面起到了意想不到的作用。“代表”（On behalf of）是安全审查在试图描述一种委派安排时使用的语言，即智能体是一个可识别的委派对象，并受此身份约束。“作为”（Act as）则是运行时的行为，此时智能体持有的令牌与用户本人的令牌完全一致，因此在任何下游系统看来，智能体就是用户。这两个短语描述了完全不同的威胁模型。典型的企业级 OAuth 集成交付的是后者，但宣传的却是前者。