你的智能体有两条发布流水线，而非一条

我合作过的一个团队在周三下午发布了一个“微小的提示词调整”。同一个 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 模板、相同的审查者和相同的合并按钮覆盖了两者，添加工具的工程师会意外地触发提示词工程师的关卡。审查从未提出正确的问题。评估套件衡量的是行为，而不是权限——而根据定义，新工具扩展的是权限。

隔离的实际表现

拆分流水线并不意味着需要两个代码仓库和两套 CI 系统（尽管有些团队最终会演变成那样）。它意味着数据平面 (data-plane) 和控制平面 (control-plane) 的变更即使在同一个 PR 中，也要经过不同的准入关卡 (gates)。

数据平面的变更受控于行为差异 (behavioral diff)。评估集 (eval suite) 的指标变了吗？新的提示词 (prompt) 是否导致了拒绝准确率、延迟或格式化的退化？针对上周流量的离线回放是否产生了不同的输出，这些差异是改进吗？评审人通常是提示词工程师或领域专家。回滚操作是 git revert。由于后果是可恢复的，因此部署时机可以很快。

控制平面的变更则受控于能力范围差异 (capability-scope diff)。Agent 今天能做哪些昨天做不到的事？新工具需要哪些凭据？如果在受操纵的输入下触发，其爆炸半径 (blast radius) 是多大——是无操作 (no-op)、可逆写入、不可逆的副作用，还是特权操作？它是否与现有工具组合，从而创造出原威胁模型未列出的危险路径？评审人是安全工程师或负责权限边界的人员。由于回滚可能无法撤销已发生的行为（例如邮件已发送），因此这是一个前向门控 (forward gate)——在你思考清楚误操作的后果之前不要发布——而不是“有问题再回滚”的关卡。

具体而言，从两者分离中引申出的原则包括：

• 独立的注册表：提示词和工具分别拥有独立的注册表，各自有其所有者、变更日志和评审 CODEOWNERS。同一名工程师可以同时编辑两者，但准入关卡不同。
• 不同的签核标准：提示词在评估差异为绿色时即可发布。工具的发布取决于能力范围的签核，无论评估集是否恰好通过。
• 解耦的部署时机：提示词的修复不应等待同一个迭代中工具变更的安全评审。工具的撤销也不应等待提示词冻结。它们需要能够独立发布。
• 独立的可观测性：一套仪表盘用于监控行为偏移（拒绝率、输出长度、格式合规性、评估集得分）。另一套用于监控权限偏移（过去 24 小时内触发了哪些工具、针对哪些范围、代表谁、输入来源是什么）。事故复盘会同时参考两者，但仪表盘由不同的团队负责和阅读。
• 独立的审计日志：行为日志记录模型说了什么。权限日志记录 Agent 做了什么。合规部门审查后者，产品部门审查前者。将两者混为一谈会使审计变成大海捞针。

这种分离并不是为了增加官僚主义，而是为了将每种变更路由到能够真正发现其问题的关卡。

组织的失效模式

如果组织架构图上写着“提示词工程师也负责工具注册表，因为那都只是配置”，那么世界上最干净的技术隔离也无法幸存。这是我见过的最常见的失效模式：一名工程师同时负责两者，两半部分都没有得到正确的评审，工具注册表在无人审查的情况下悄悄积累了各种能力。半年后，Agent 除了发布时的 12 项功能外，还多出了第 13 项功能——那是某人在 3 月份为了处理客户投诉而悄悄添加的，而工具团队对此一无所知，因为那名工程师将其视为“自己的”技术栈。

解决方法虽然让人不适，但很乏味：控制平面需要与数据平面有不同的所有者，即使是同一名工程师提交的代码。“所有者”在这里指的是对关卡负责，而不是对代码负责。提示词工程师可以编写工具，但在合并之前，必须由安全路线的评审人对能力范围差异进行签核。这会让你在工具变更上损失几小时的延迟，但能避免你在凌晨 3 点发现一个早已被遗忘的工具已被 Agent 悄悄使用了一个月。

2026 年的行业数据在这一点上非常严峻：今年的一份 Agent 安全报告发现，70% 的企业已在生产环境中使用 Agent，但只有 14% 的企业让这些 Agent 获得了完整的安全批准，且超过一半的已部署 Agent 在运行时没有任何权限日志记录。这不是安全团队的失败。这是发布流水线的失败——组织从未构建过控制平面的评审机制，因此权限变更默认通过数据平面关卡路由，而该关卡根本不知道要检查什么。

网络工程的类比具有实际意义

值得说明的是，从网络工程中借用数据平面/控制平面的术语不仅仅是一个时髦的隐喻。在路由器中，这种设计分离之所以存在，是因为失效模式的规模不同：转发 bug 会导致一个数据包停滞，而路由 bug 则会让整个前缀陷入黑洞。两者优化的方向也不同——转发路径追求速度和规律性，控制路径追求可定制性和异常处理——正是因为将它们混为一谈会导致两者都做不好。

Agent 的形态与之相同。行为 bug 会导致一次对话停滞；权限 bug 则会导致一整类副作用停滞。行为平面需要快速迭代、评估关卡、A/B 测试框架和轻量级回滚。权限平面则需要缓慢的变更、明确的范围界定、安全关卡和前向遏制，因为回滚并不总是有效。试图为两者优化同一个流水线，就是路由器在 20 世纪 90 年代就已经停止犯的错误。

对于任何正在构建超越玩具阶段 Agent 的团队来说，这意味着：停止询问“我们的 Agent 部署流程是什么”。转而询问“我们的两个 Agent 部署流程是什么，每种变更分别通过哪个关卡”。如果你无法用两组不同的评审名单、两套不同的签核标准和两套不同的可观测性方案来回答这个问题，那么你的发布流水线就是融合在一起的——而下一次事故将会教会你，你忽略了断裂带的哪一侧。