你的智能体有两条发布流水线,而非一条
我合作过的一个团队在周三下午发布了一个“微小的提示词调整”。同一个 PR 还向智能体注册中心添加了一个新工具——一个对内部管理 API 的便利封装,提示词现在偶尔会调用它。评估套件通过了。金丝雀发布看起来也很正常。到周四早上,由于智能体处理了一个包含提示词注入攻击的支持工单,一名客户的计费记录被修改了。审计追踪显示,管理工具完全按照设计运行。值班工程师的第一反应——回滚提示词——毫无用处,因为凭证已经使用,数据行已经写入。
复盘报告将其定性为安全审查失败。其实不是。这是发布流水线的失败。团队通过相同的审查、相同的关卡和相同的回滚逻辑,发布了两个完全不同的资产类别——对模型的行为引导和授予智能体的新权限,就好像它们是同一种变更一样。它们并不是。一旦你将它们视为两个流水线,大多数关于“智能体治理”的争论就会变得清晰得多。
在磁盘上看起来完全相同的两个资产类别
打开任何一个非平凡(non-trivial)智能体的代码仓库,你会看到两个在结构上无法区分的文件夹。两者都是版本化的文本。两者都在拉取请求(PR)中进行审查。两者都使用相同的 CI 任务部署。但它们位于断裂带的两侧,网络架构师在四十年前就识别出了这条断裂带,而我们现在正以糟糕的方式不断重新发现它。
智能体的**数据平面(data plane)**是模型的行为形态:系统提示词、指令、few-shot 示例、输出 schema、角色描述、拒绝指南,以及引导模型倾向于某种输出分布而非另一种输出分布的整个文学语料库。这里的编辑改变了模型说的话。
**控制平面(control plane)**是智能体可触达的动作空间:工具注册中心、工具 schema、能力范围、认证边界、速率限制预算、智能体可以通信的 MCP 服务器列表,以及控制哪些工具在哪些条件下触发的策略。这里的编辑改变了智能体能做的事。
这两者不是同一种事物的两个变体。它们具有不同的爆炸半径、不同的回滚语义、不同的审查者、不同的审计义务和不同的故障模式——将它们视为同一个流水线是导致大多数“智能体在生产环境中失控”事件的根源性架构错误。
故障的不对称性
一个糟糕的数据平面变更会产生质量回归。智能体变得过于啰嗦、拒绝了不该拒绝的请求、幻觉出一个字段名、自我重复、或者在对话中途切换语气。你可以在评估差异、用户投诉、满意度评分中看到它。你将提示词回滚到之前的版本,回归随之消失。爆炸半径受限于你的监控窗口,恢复过程是机械的:回滚后的每一次对话都使用新行为,唯一的残留只是几小时平庸的会话记录。
一个糟糕的控制平面变更会产生权限回归。智能体不是说了你希望它没说的话——而是做了你希望它没做的事。发送了邮件。取消了订阅。写入了数据。授予了访问令牌。发布到了频道。模型可以回滚,但副作用(side-effects)不能。你的“回滚”现在变成了一次事件响应,涉及凭证轮换、向受影响用户发送通知,可能还有监管机构的电话,以及律师针对审计日志实际记录的内容提出的尖锐问题。你无法像从糟糕的提示词中恢复那样,从一个糟糕的工具注册中恢复。你只能遏制它,并接受遗留的影响。
OWASP 的 LLM06 指南将其定义为“过度代理”(excessive agency),并明确称其为根本性的设计冲突,而非一个可配置的旋钮。这种表述很重要。它意味着正确的控制不是仪表板上的一个设置——而是一个架构选择,决定了变更属于数据/控制划分的哪一侧,并相应地接受何种审查。
为什么单个流水线是默认选择
几乎每个团队最初都只有一个流水线,因为在第一天,资产类别还没有分化。这个“智能体”只是一个 Python 文件,顶部是系统提示词,底部附近是一个 TOOLS 列表,还有一个将它们连接在一起的 main() 函数。一个仓库,一个 CI,一个审查者。将它视为两个发布平面会显得为了流程而流程。
问题在于,这两类资产开始以截然不同的速度和形态增长——在第一天正确融合的流水线,在融合已经不再起作用后仍然保持着这种状态。系统提示词从 30 行增加到 300 行,伴随着回归测试、评估套件、行为比对、A/B 测试框架和版本化方案。工具注册中心从三个函数增加到三十个,伴随着认证范围、速率限制预算、爆炸半径分类,以及那种长期的、悄无声息的漂移:“我们为第三季度的那个用例又增加了一个功能,但从未对整个列表重新进行审计。”
一年后,你有一个流水线在拙劣地同时处理两项工作。提示词编辑通过了评估差异审查(很好——这是它们需要的),而工具添加也通过了评估差异审查(很糟——这不是它们需要的;它们需要的是能力范围审查、污点分析、爆炸半径分类和安全签名)。而且因为相同的 PR 模板、相同的审查者和相同的合并按钮覆盖了两者,添加工具的工程师会意外地触发提示词工程师的关卡。审查从未提出正确的问题。评估套件衡量的是行为,而不是权限——而根据定义,新工具扩展的是权限。
- https://www.ibm.com/think/topics/control-plane-vs-data-plane
- https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html
- https://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents/
- https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- https://cloud.google.com/blog/products/ai-machine-learning/new-enhanced-tool-governance-in-vertex-ai-agent-builder
- https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control
- https://langfuse.com/docs/prompt-management/features/prompt-version-control
- https://www.auxiliobits.com/blog/versioning-and-rollbacks-in-agent-deployments/
- https://agentic-software-development.riskfirst.org/risks/deployment-rollback-risks
- https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization
