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

用户点击了智能体操作的“撤销”按钮，而该操作之前已经分发（fan out）到了十二个工具调用中。智能体发送了两封电子邮件，创建了一个日历邀请，更新了一条 CRM 记录，扣除了信用卡费用，并在 Slack 频道中发布了消息。其中三个操作通过 API 是不可逆的。两个操作只能通过触发自身下游通知的反向操作来撤销。剩下的七个操作各自都有自己的幂等性（idempotency）定义，而规划器从未协调过这些定义。你发布的撤销按钮看起来令人安心，它大约 60 % 的时间静默成功，其余时间则静默失败。

这不是一个 UX（用户体验）漏洞。这是一个 Saga 模式问题，分布式系统工程师已经研究了三十年，而忽略这段历史是发现它最昂贵的方式。

无状态的聊天补全（Stateless chat completion）耗电量极低。一次中等规模的 Gemini 文本提示耗电约为 0.24 Wh；一次简短的 GPT-4o 查询约为 0.3–0.4 Wh。这些数字微乎其微，甚至没人会把它们放进董事会演示文稿里。

智能体任务（Agent task）并非普通的聊天补全。一个典型的“研究该客户并起草回复”的工作流可以扇出（Fan out）到 30 多个工具调用、10–15 次模型调用，且上下文窗口随着每一步不断增长。能源成本随调用图（Call graph）呈复合增长。当智能体返回结果时，你消耗的不是一个推理单元，而是五十到两百个。突然之间，每个任务的碳足迹便与视频流达到了同一数量级。

这种算术题很快就会在工程部门之外产生影响。欧盟的 CSRD 使范围 3（Scope 3）排放披露成为受规制公司的强制要求，并要求从 2026 年起提交机器可读的 iXBRL 报告。尽管 SEC 在其最终规则中删除了范围 3，但任何在欧盟有业务的跨国公司仍然必须回答这个问题。采购团队已经开始在供应商调查问卷中加入“你的 AI 功能每个用户任务的碳足迹是多少？”这类问题。大多数工程团队无法回答，因为从来没有人测量（Instrumented）过它。

当 CFO 第一次问“这个助手每月花掉我们多少钱”时，工程团队会给出一个数字。第二次问时，另一个团队会给出不同的数字。第三次问时，财务部门会给出第三个数字，然后有人会打开一个电子表格，尝试从 Span（跨度）中重新推算账单，因为没有人再相信之前的任何答案。就在这一刻，复合 AI 系统（Compound AI System）不再仅仅是一个架构问题，而变成了一个会计问题。

这种故障的形式是结构性的。一个简单的用户请求“总结我上季度的客户反馈”会触发由团队 A 拥有的智能体，它调用由团队 B 维护的检索工具，接着调用由供应商 X 托管的模型，然后通过团队 C 的重排序工具回传结果，而重排序工具又调用了由供应商 Y 提供的另一个模型。一次点击；五个所有者；两张相隔一个月到达的账单。标准的 FinOps 原语——成本中心、分配标签、账号级汇总——是为了切割那些已经拥有稳定所有者的基础设施而设计的。它们无法清晰地组合在一个每次请求都会跨越团队边界的内部调用图中。

《2026 年 FinOps 现状报告》指出，98% 的 FinOps 团队需要对 AI 支出负责，而同一份调查将“对 AI 成本的实时可见性”列为最大的工具缺口。这个缺口并不是“我们看不见账单”，而是“我们无法足够快地看清是账单的哪一部分是由谁产生的，以至于无法在账单寄到之前让任何人改变其行为”。

我合作过的一个团队在周三下午发布了一个“微小的提示词调整”。同一个 PR 还向智能体注册中心添加了一个新工具——一个对内部管理 API 的便利封装，提示词现在偶尔会调用它。评估套件通过了。金丝雀发布看起来也很正常。到周四早上，由于智能体处理了一个包含提示词注入攻击的支持工单，一名客户的计费记录被修改了。审计追踪显示，管理工具完全按照设计运行。值班工程师的第一反应——回滚提示词——毫无用处，因为凭证已经使用，数据行已经写入。

复盘报告将其定性为安全审查失败。其实不是。这是发布流水线的失败。团队通过相同的审查、相同的关卡和相同的回滚逻辑，发布了两个完全不同的资产类别——对模型的行为引导和授予智能体的新权限，就好像它们是同一种变更一样。它们并不是。一旦你将它们视为两个流水线，大多数关于“智能体治理”的争论就会变得清晰得多。

调出你今天早上的 SSO 日志。每一条 Slack 消息、每一个 GitHub PR、每一项日历邀请、每一次 CI 运行、每一条 Jira 评论——它们都显示着与人类手动输入完全相同的信息：一个人的名字、一个会话令牌（session token）、一行绿色的“身份验证成功”。从审计的角度来看，你根本无法分辨哪些行为来自人类，哪些来自人类启动后便置之不理的智能体。这就是“幽灵员工”问题，而且过去 12 个月里上线了智能体的团队几乎都面临这个问题。

导致这一问题的捷径是结构性的，而非疏忽大意。当你将智能体接入工具时，最简单的凭证就是工程师环境中现有的那个——他们的个人访问令牌（personal access token）、OAuth 会话或绑定设备的 SSO Cookie。替代方案则是一项平台级工程：配置一级身份（first-class identity）、在每个下游服务中进行联邦认证、将其接入审计流水线、构建针对每个实例的撤销机制。这些工作无法在一个 Sprint 内完成，也不会出现在功能路线图中。因此，智能体选择了“借用”。

我本季度交流过的一个平台团队发布了一个封装了 kubectl 并支持英语指令的 Slack 机器人。一名工程师输入了 “清理 staging 中未使用的分支”。这个机器人非常“热心地”删除了 12 个命名空间——其中一个的名字匹配到了子字符串 “branch”，但它恰好托管了移动团队已经使用了一周的长期集成环境。没有任何异常被抛出。机器人发起的每一次调用都是它合法持有的权限。复盘报告无法指出任何违背的访问规则，因为确实没有规则被打破。该机器人完全按照其 IAM 策略允许的操作执行。

Unix 哲学是一种隐藏在审美偏好下的隔离策略。具有窄接口的小型工具意味着任何单个命令的爆炸半径都受到它所接受的谓词和标志 (flags) 的限制。rm -rf 极其危险，因为这是大家的共识；kubectl delete namespace 要求操作者完整输入命名空间名称，而这种手动输入就是一道关卡。最小特权原则之所以容易执行，是因为权限是词法化的：命令的形式告诉了你行动的形式。

随后，封装层开始接受英语。现在，“命令的形式”变成了 LLM 认为它是什么，它就是什么。

一位资深工程师打开了一个由 Agent 编写的 PR。Diff 非常整洁。测试通过了。命名规范一致。他们大致扫了一眼，点了个赞，然后合并。两个月后，另一位资深工程师正在重写那个模块，因为该模块引入的抽象在三个调用点悄悄泄露了状态，而测试套件从未发现这一点，因为它只断言了代码在做什么，而不是规范（Spec）的要求。

这种模式是 2026 年代码审查（Code Review）中占主导地位的失败模式。那些适用于人类编写 PR 的审查直觉——探究作者的意图、寻找他们没想到的 Bug、检查测试是否反映了设计——在 Agent PR 上失效了，因为 Bug 聚集在不同的地方，且审查者看到的产物不再是真正重要的产物。

数据支持这一直觉。CodeRabbit 在 2025 年 12 月对 470 个 GitHub PR 的分析发现，AI 协作编写的代码产生的问题大约是人类编写代码的 1.7 倍，其中逻辑和正确性错误是 1.75 倍，安全发现是 1.57 倍，算法和业务逻辑错误是人类的 2.25 倍。严重问题增加了 1.4 倍，重大问题增加了 1.7 倍。Diff 读起来很流畅，而这种流畅性恰恰就是问题所在。

你的安全团队拥有公司信用卡上每一项 SaaS 订阅的完整清单、每一个获得管理员授权的 OAuth 应用，以及连接到公司 Wi-Fi 的每一台设备。然而，对于你的高级工程师笔记本电脑上当前绑定到 127.0.0.1 的七个进程，他们却完全视而不见——一个带有长期 Staging API 令牌的“部署助手”，一个订阅了包含客户数据的 Slack 频道的“工单分类器”，以及一个拥有生产分析数据仓库读取权限的“发布说明生成器”。这些都不在供应商名单上。它们不会出现在 SSO 日志中。所有这些都在利用工程师现有的凭据运行，执行着从未经过审批的操作。

这就是影子 MCP（Shadow MCP），它是企业中增长最快的未管理授权面。模型上下文协议（Model Context Protocol）使得将任何工具接入任何 LLM 的成本变得极低，而工程师们——天性使然——首先接入了那些最显而易见的工具。Saviynt 的 CISO AI 风险报告指出，75% 的 CISO 已经发现其生产环境中运行着未经授权的 AI 工具。GitHub MCP 服务器在 2026 年初的周安装量突破了 200 万次。Postgres MCP 服务器允许 LLM 对开发者能接触到的任何数据库执行 SQL 提示词，其周安装量已超过 80 万次。这些数字中没有一个代表企业的 IT 决策。

“发送邮件”工具和“删除账号”工具被放在了同一个确认弹窗后面。你的用户今天已经点击了 40 次“批准”（Approve），没有一次点击涉及阅读 Diff，而下一次点击——即向生产数据库提交一个不可逆变更的操作——看起来和之前的 40 次完全一样。这就是二元工具审批的失效模式，也是当今几乎所有发布的 Agent 框架的默认设置。

问题的核心框架在于，“需要人工审批”被视为附加在工具上的单个布尔值，而实际上它是一个包含五到六个类别的分类法，取决于工具可能造成的破坏类型以及这种破坏的可恢复程度。那些能够交付安全 Agent 的团队不再询问“这个工具是否需要确认对话框”，而是开始询问“这个工具属于哪种风险类别，以及哪个门槛（gate）对应于该类别”。审批门槛的正确数量既不是一个，也不是很多。它是每个风险类别对应一个，你必须在构建门槛之前先列举这些类别。

调取任何生产环境智能体（agent）的一周工具调用追踪（tool-call traces），你会发现其规律如出一辙：三四个工具处理了 90% 的调用，其余数十个工具则瓜分了剩下的 10%。工具目录呈现幂律分布（power law），但框架却将其视为均匀列表。每个工具描述都会出现在每个系统提示词（system prompt）中，每个选择准则都对工具一视同仁，每个评估（eval）在对目录进行采样时，都仿佛 search-files 调用和 refund-issue 调用来自同一分布。事实并非如此。

这种“扁平化”处理的代价在爆发前往往是隐形的。团队增加第 18 个工具，规划器（planner）对最初三个工具的准确率下降了两个百分点，却没人能将这种退化归因于特定变更，因为所有指标都同时发生了偏移。而评估套件本身在目录中也是均匀分布的，它将这些下滑平均成一个看起来依然正常的数字。与此同时，本轮对话中模型不会调用的工具描述所消耗的 token，已经超过了用户实际提示词的 token。

read_file 是安全的。send_email 是安全的。你的安全审计对照各自的威胁模型分别批准了它们：对已知目录的只读访问，以及通过带有速率限制和收件人日志记录的已认证中继发送的出站邮件。每一个都通过了，两者都已注册。随后智能体将它们组合在一起，而客服工单中的一行注入文本就将这对组合变成了外泄工具，原有的审计对此根本没有描述这种风险的术语。

危险并不存在于工具图谱的任何节点中，而是在于边。你运行的每次针对单个工具的安全审计都是对顶点的判定；而智能体实际的权限表面是目录中的路径集合，这个集合呈二次方增长，而你的审计流程却只能线性扩展。当你的智能体拥有 15 个注册工具时，你审计了 15 个项，却发布了大约 200 个可达的两步组合，其中没有一个经过人工审核。

在几乎每一个智能体（agent）项目评审中，都有一个会让谈话戛然而止的时刻。有人画了一张小图表：y 轴是端到端任务成功率，x 轴是工具使用的步骤数。曲线急剧下降。全场陷入沉默，因为屋子里的每个人之前都在争论提示词（prompt）、模型和检索策略——而这张图表在告诉大家，所有的这些争论，都抵不过一个简单的事实：这条链条上的环节太多了。

这一数学原理是可靠性工程中最古老的结论之一，如今被移植到了一个自以为是的新领域。如果流水线中的每一步都以概率 p 独立成功，那么 n 个串联步骤的成功概率就是 p 的 n 次方。代入一些在进度报告中听起来还不错的数字：单步可靠性 95%，十个步骤，端到端成功率就只有 60%。二十步降至 36%。三十步则降至 21%。那个“95% 的时间都能正常工作”的智能体，实际上在三分之一的真实用户请求中都会失败，因为真实的用户请求绝非只有单个步骤。