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

你的安全团队拥有公司信用卡上每一项 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% 的时间都能正常工作”的智能体，实际上在三分之一的真实用户请求中都会失败，因为真实的用户请求绝非只有单个步骤。

当智能体（agent）在同一个 diff 中编写函数和注释时，该注释并不是文档。它是代码在编写时的转述，由同一个模型从同一个上下文中生成。当代码第一次发生变动时，它就会悄然出错。函数被重构，参数类型改变，或者添加了提前返回（early-return），但注释却保持不变。到下个季度，注释所编码的规范已不再与代码匹配，而下一位读者会因为注释更易读而选择相信它。

这是一个古老的失效模式 —— 人类修改代码，注释保持陈旧 —— 但智能体从三个维度同时加速了这一进程。注释量增加了，因为智能体无论是否需要，都会给每个函数添加文档块（doc block）。注释的语法非常完美，所以审阅者不会将其标记为低质量。而且，注释用与代码实际执行不同的术语来转述代码，因此它们看起来像文档，但实际上编码了第二套规范，这套规范独立于第一套规范而漂移。

如果代码审查流水线中的作者和审阅者都是在重叠语料库上训练的语言模型，那么它就不是一个质量关卡，而是一个信心放大器。作者编写的代码在 Transformer 看来是合理的，审阅者以同样的合理性视角阅读代码，双方最终达成“看起来没问题”的共识，于是代码变更带着一个绿色的勾合并了，而这对于变更是否真正正确毫无意义。最近的行业数据清楚地展示了这种不对称性：在同等规模下，与 AI 共同编写的 PR 产生的严重问题（critical issues）比人类编写的高出约 40%，重大问题（major issues）高出约 70%，其中逻辑和正确性错误占了差距的大部分。而为了捕捉这些错误而发布的审阅代理（reviewer agents），从构造上来说，恰恰是最不具备发现这些错误能力的。

那些从 AI 代码审阅中获得真实信号的团队已经不再将“审阅”视为“生成”的某种变体，而是开始将审阅设计为一种本质上不同的认知任务。生成式提示词（Generation prompting）要求模型产生连贯的内容。而审阅式提示词（Review prompting）则必须要求模型发现缺失的东西——去关注 Diff 中的负空间而不是正空间——这种反向思维比一行系统提示词所暗示的要难诱发得多。

一个用户打开聊天窗口，请求退款，得到“抱歉，此次购买不符合退款条件”的回复后，关闭了标签页，再也没有回来。在内部，智能体生成了一条完美的追踪记录：工具调用、中间推理过程、参考的政策包，以及运行的模型版本。每一个 span（追踪跨度）都进入了可观测性平台。但没有任何内容是用户可以触及的。这里没有标为“请求人工再次审核”的按钮，即使有，后面也没有相应的服务。这个决定在默认情况下就是终局，而非设计使然。

这就是“可争议性差距”（contestability gap），它是监管机构、律师和愤怒的用户接下来要撕开的口子。这也是一个最典型的例子：一个从外部看像是政策问题，而从内部看实际上是工程链路（plumbing）的问题。

智能体自信地报告：“我已将会议改至周四下午 3 点。”用户却盯着原本周二上午 10 点的时段发呆，因为在智能体制订计划到提交更改的这段时间内，用户自己编辑了该事件。“最后写入者胜”（Last-write-wins）策略让自动化的操作覆盖了人类的修改，而用户对助手的信任也因这一次事故而崩塌。这就是双写竞争（dual-writer race），也是智能体工具链从未专门设计应对的 bug 类别。

大多数智能体平台都无意中继承了这一问题。工具层将 update_event 视为一个简单的函数调用：获取 ID，获取新字段，返回成功。底层的提供商 API 十多年来一直提供乐观并发原语（optimistic concurrency primitives）——ETags、版本令牌（version tokens）、If-Match 前提条件——但几乎没有人将它们贯通。模型无法知道它一分钟前所推理的世界已不再是现状，因为由于它所获得的抽象层静默地丢弃了这些信息。

凌晨 3 点让财务部门收到告警的成本飙升其实并不是真正的成本飙升。那只是一个 Span 重命名。Agent 平台团队的某个人觉得 llm.completion.synthesis 应该改为 llm.generate.answer，因为这样读起来更自然。他们提交了一个小的 PR，运行了测试，然后发布了。三天后，财务的月度 Token 消耗仪表盘显示下降了 60%。没有人削减支出。聚合规则仍然按旧名称分组，而新的 Span 流向了一个仪表盘甚至没有渲染的 “其他” 桶中。账单没有变。仪表盘变了。

这是我一直看到团队在重复经历的一类事故。Span 名称和属性键并不是为了让人在追踪 UI 中阅读而存在的标签。它们是一个未公开 API 的公开 Schema，其消费者是生产团队从未谋面的——过滤它们的评估流水线、按它们分组的成本仪表盘、根据其持续时间触发的 SLO 告警、汇总其 Token 属性的 FinOps 报告。一个团队内部 “无害的重命名”，对于另外四个从未看过该 PR 的团队来说，就是一个网络协议破坏。

当监管机构第一次要求你证明你的支持代理在 3 月 14 日没有访问某位二级客户的账单记录时，你会发现关于你的鉴权架构的一个令人不悦的事实：系统提示词说“不要访问二级客户的账单”，YAML 工具清单说 tools: [search_orders, refund_order, get_billing]，而在两者之间，模型做出了决定。由于不存在决策点，因此没有决策记录。代理是否做了正确的事是无法审计的，只能从发生的日志中推断。

这是智能体工程中没人画在架构图上的部分。如今的工具权限仍然存在于由创建智能体的人编辑的 YAML 文件中，通过描述意图的系统提示词呈现给模型，并由包裹每个工具调用的应用代码强制执行（如果真的执行了的话），例如 if user.tier == "premium" 检查。随着工具目录超过 50 个条目，且条件在租户、数据类别和用户角色之间成倍增加，这种手动构建的网格便不再具备扩展性，而系统提示词也不再是一个可靠的执行面。模型不是你的鉴权层，即使它的表现看起来像是一个鉴权层。

取而代之的是策略即代码（policy-as-code）：一个专门的策略引擎 —— OPA 配合 Rego、AWS Cedar 或类似的声明式工具 —— 作为策略决策点（Policy Decision Point）位于每个工具调用之前。引擎在每次调用时只回答一个问题：给定这个主体（principal）、这个工具、这些参数和这个上下文，该操作是否被允许？智能体运行时（agent runtime）从未参与投票。这篇文章将探讨这种架构在实践中的样子，以及它所解决的四个即使是提示词工程也无法解决的问题。

Agent 对客户说：“收到——我已经提交了你的退款请求。你应该会在 5–7 个工作日内看到它。”客户关闭了聊天。但退款从未被提交。没有工单，没有 API 调用，退款表中也没有记录。有的只是一段礼貌且自信的英语，以及随后成功的会话终止。

这就是确认与行动的脱节（acknowledgment-action gap），它是生产环境 Agent 系统中代价最高昂的一类 Bug。这种脱节之所以存在，是因为让经过指令微调（instruction-tuned）的模型显得很能干的流利文字，与真正改变世界的结构化工具调用（tool calls）属于不同的输出通道——而大多数团队将业务逻辑挂接到了错误的通道上。

每个发布 Agent 的人最终都会以惨痛的方式意识到这一点。模型生成了一份读起来像承诺的精美确认函，下游系统将其解读为承诺，几周后一份支持工单寄来，询问退款去了哪里。令人尴尬的不是模型撒了谎，而是系统被设计成去信任它所说的话。