你不知道自己在运行什么代码:AI代理供应链的隐秘风险

AI代理不只是模型,而是由多组件构成的「星座」,其供应链可见性远比选模型复杂。
文章指出,把AI供应链等同于「用哪个模型」是一种普遍的认知偏差。一个AI代理实际由基础模型、MCP服务器、A2A通信层、插件和技能等组件共同构成,作者称之为「代理星座」。每个组件都有自己的版本、来源和更新节奏,星座越大,对系统真实状态的无知程度越高。传统依赖管理依靠锁文件、语义化版本和哈希校验来获得确定性,但在AI代理场景下,版本锁定可能失效——插件会拉取远程配置、MCP指向可变端点、模型行为因服务端更新而漂移。这种组件级可见性的缺失会放大为三类风险:安全边界失效、行为漂移难以归因、合规与审计出现缺口。应对方向是让复杂度可见:记录来源与版本、做完整性校验、保留运行时组件清单。
当你问开发者「你在用哪个AI模型」时,答案通常是ChatGPT、Claude或某个新出的名字。但这个问题本身就把AI系统想得太简单了。一个AI代理真正运行的东西,远不止那个模型。
模型只是冰山一角

人们习惯性地把「AI供应链」等同于「模型选择」——你用ChatGPT还是用Mythos?你用Astra还是别的?这种问法只触及了整个系统中最显眼的一小块。
真实情况是,一个AI代理是由大量组件拼装而成的星座。模型只是其中最亮的那颗星,围绕它的还有MCP服务器、A2A(agent-to-agent)通信层、插件、技能(skills)等等。每一个组件都有自己的版本、自己的来源、自己的更新节奏。
当你只盯着模型看的时候,其余这些组件正在你看不见的地方运行。
代理星座:一个更准确的隐喻

「代理星座」(agent constellation)这个说法抓住了AI系统的结构性特征:它不是单一制品,而是一组相互依赖的部件构成的整体。

这个星座至少包括:
- 基础模型——你选定的那个LLM
- MCP服务器——连接外部工具和数据的接口层
- A2A协议——代理与代理之间的通信机制
- 插件——扩展能力的第三方模块
- 技能——预打包的行为单元
每增加一个组件,你就多了一个需要追踪的版本号,多了一个可能悄悄变化的依赖项。星座越大,你对自己系统实际状态的无知程度就越高。
MCP(Model Context Protocol) 是由 Anthropic 提出并逐步被多家厂商采纳的开放协议,用于让模型以标准化方式连接外部工具、数据源和服务。在 MCP 之前,每个应用都要为接入某个数据库或 API 写一套专用适配代码;MCP 把这些连接抽象成统一的"服务器"角色,模型侧作为客户端按协议发起调用。一个 MCP 服务器可以暴露工具调用、资源读取、提示模板等能力,并可独立发布、独立更新。这带来了便利,也带来了本文关注的问题:一个代理可能同时挂载多个来源各异的 MCP 服务器,每个服务器背后又是一段你未必审计过的代码和一个可能变动的远程端点。
A2A(Agent-to-Agent)协议 指代理之间互相发现、委派任务和交换消息的通信层。单个代理能力有限,复杂任务常被拆给多个专职代理协作完成,例如一个代理负责检索、另一个负责执行代码、再由一个做汇总。A2A 协议规定了这些代理如何描述自身能力(通常通过某种能力卡片或清单)、如何鉴权、如何传递上下文。与 MCP 的"模型连工具"不同,A2A 是"代理连代理",调用链可能跨越多个组织边界。这意味着你的代理实际依赖的组件,可能包括你从未直接配置过的第三方代理,其版本和行为完全不在你的控制范围内。
版本锁定失效的地方

传统软件工程有成熟的依赖管理手段:锁文件、语义化版本、哈希校验。你可以精确地知道构建时用的是哪个版本的哪个包。
AI代理的供应链打破了这套确定性。即使你在配置里固定了某个插件的版本,实际加载的代码仍可能与你的预期不一致——插件本身可能拉取远程配置,MCP服务器可能指向一个会变动的端点,模型的行为可能因为服务端更新而漂移。
「如果我因为锁定了版本,就以为自己拿到了预期的代码,但实际上运行的是另一份代码——那问题就大了。」这不是理论上的担忧。当你无法确认每个组件的确切身份时,你也就无法判断:哪一个变了、哪一个更新了、哪一个已经不是你以为了。
锁文件与完整性校验的差别值得区分。锁文件(如 package-lock.json、poetry.lock)固定的是依赖解析结果,即"装哪个版本";而哈希校验固定的是"内容是什么",即使版本号相同,内容被替换也会被检出。AI 代理场景的麻烦在于,许多组件在运行时会动态获取内容:插件可能远程加载配置或脚本,MCP 服务器可能把请求转发到可变的云端端点,模型本身则完全由服务方控制。对这些环节,版本号几乎不提供任何保证,必须依赖运行时清单、内容哈希或签名验证,才能回答"此刻实际执行的是什么"。
为什么这件事比听起来更严重
不知道自己在运行什么代码,在AI代理场景下会放大成三类风险。
安全边界失效。 供应链安全的前提是你能枚举出所有组件并验证其完整性。星座模型让枚举本身变得困难——你的代理可能通过MCP调用了你根本没审计过的第三方服务。
行为漂移不可归因。 代理输出变差或出现异常行为时,你需要定位是模型更新、插件变更还是A2A协议层的问题。没有组件级可见性,排查就变成猜测。
合规与审计缺口。 当监管要求说明「系统使用了哪些软件」时,「我们用的是某模型」这种回答远远不够。
把星座画出来
应对思路不是拒绝复杂度,而是让复杂度可见。至少需要做到:对每个组件记录来源与版本;对关键依赖做完整性校验而非仅靠版本号;在运行时保留组件清单,使「实际加载了什么」可以被查询。
AI代理的能力来自星座的协同,风险同样来自星座的协同。认清这一点,是管理它的前提。
相关推荐

Cognition SWE-2 实战:一个提示词搞定产品发布全流程
解析 YouTube 创作者用 Cognition SWE-2 发布产品的完整提示词:落地页、七封邮件序列与未购买用户跟进工具三段式结构,以及"测试并汇报"这一约束如何改变 AI 的交付质量。
AWS AgentCore Gateway:用MCP打通AI Agent与企…
AWS AgentCore Gateway:用MCP打通AI Agent与企业后端
AWS AgentCore Gateway如何作为主MCP服务器聚合REST API、Lambda与已有MCP服务?解析其AST实时映射、零冷启动、语义搜索治工具过载、会话隔离与密钥注入安全设计,以及企业AI Agent解耦后端的架构思路。

一个链接给Figma AI装上新技能:MCP连接器实战
通过粘贴一个MCP服务器链接,Figma中的AI Agent就能获得新工具能力。本文拆解配置流程、超过20个一键接入应用、读写权限与执行策略设置,以及公开HTTPS链接这一关键限制。