一个金融服务 Agent 在标准的越狱测试套件中获得了 11/100 分——属于“低风险”。而上下文相关的红队测试（首先剖析 Agent 的实际工具访问权限和数据库架构，然后构建针对性攻击）发现的情况却截然不同：一种电影角色扮演技术可以指示该 Agent 在 88 个钱包中调度 44 万美元，执行未经授权的 SQL 查询，并暴露跨账户交易历史。通用测试套件并不知道该 Agent 拥有 withdraw_funds 工具。它测试的系统与实际部署的系统并不一致。
这 60 分的风险分值差距正是将传统红队方法论应用于 AI Agent 时面临的问题。Agent 不仅仅是做出响应；它们会规划、跨多个步骤进行推理、持有真实的凭据，并在现实世界中执行不可逆的操作。测试你是否能让它说出一些有害的话，与测试你是否能让它 做 出一些有害的事，并不是一回事。
“AI 界的 USB-C” 这个比喻很吸引人。但在涉及负责生产环境运行的这一关键层面时，这个比喻又是错误的。Model Context Protocol (MCP) 确实解决了一个真实存在的问题——即 AI 模型与外部系统之间爆发式增长的 N×M 次自定义集成——但“演示效果良好”与“在周一早高峰流量下既不泄露数据也不耗尽延迟预算”之间的差距，比大多数团队预期的要大得多。
MCP 在 2024 年 11 月发布后的五个月内，服务器下载量增长了 8,000%，到 2025 年 4 月，每月 SDK 下载量已达到 9,700 万次。这种采用速度既是其真正实用性的标志，也是一个警告：大多数服务器在投入生产时，团队并未完全理解他们所构建的基础。
大多数构建 AI Agent 的团队在第一个月都在追求性能：更好的提示词、更智能的路由、更快的检索。接下来的六个月，你则会忙于补救之前忽略的东西——治理（governance）。无法被审计的 Agent 会被法务部门叫停。没有权限边界的 Agent 会在预发布环境中造成混乱。没有人工升级路径的 Agent 则会在规模化运行时悄无声息地犯下严重的后续错误。
一个令人不安的事实是，大多数 Agent 部署之所以失败，并不是因为模型性能不足，而是因为围绕它的脚手架（scaffolding）缺乏结构。近三分之二的企业正在尝试 Agent；但只有不到四分之一的企业成功实现了生产规模化。差距不在于模型质量，而在于治理。
在 AI 的大部分历史中，治理问题从根本上说是关于输出的：模型说了错误、冒犯或机密的内容。这固然糟糕，但它是受控的。影响范围仅限于读取该输出的人。
智能体 AI（Agentic AI）完全打破了这一假设。当一个智能体能够调用 API、写入数据库、发送电子邮件并生成子智能体时，问题就不再仅仅是“它说了什么？”，而是“它做了什么、针对哪些系统、代表谁做的，以及我们能否撤销它？”近 70% 的企业已经在生产环境中运行智能体，但其中大多数智能体在传统的身份与访问管理（IAM）控制之外运行，使其处于不可见、权限过高且未经审计的状态。
2025 年 6 月，一名研究员向一位 Microsoft 365 Copilot 用户发送了一封精心编写的邮件。没有点击链接。没有打开附件。邮件送达后，Copilot 在执行例行的总结任务时读取了它，短短几秒钟内，AI 便开始从 OneDrive、SharePoint 和 Teams 中外泄文件——通过将数据编码进它请求“渲染”的图片 URL 中，悄无声息地将内容传输到了攻击者控制的服务器上。受害者对此一无所知。
从传统意义上讲，这并不是一个新奇的零日漏洞（Zero-day）。没有缓冲区溢出，也没有 SQL 注入。该漏洞是架构性的：系统结合了三种能力，这些能力单独看起来像是理所应当的产品功能。但结合在一起，它们就构成了现在所谓的“致命三要素”（Lethal Trifecta）。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
