控制平面：规模化治理智能体AI

这份指南最初是为一家加拿大主要银行的工程负责人撰写的白皮书。他们并非从零开始。他们已经在预生产环境中使用 LangGraph 代理：检查点存入 Postgres，子图用于专业角色，interrupt() 连接起来供人工审查。他们阅读了文档并构建了实际系统。所以当我进去谈论编排时，一位首席工程师提出了唯一值得问的问题：“我们已经有了 LangGraph。它有持久性，有 人在回路，有状态。我们为什么还要在中间加入其他东西？”

回答这个问题有一种错误的方式，大多数供应商都采取这种方式。错误的答案是部落式的：我的运行时对抗你的运行时，我的标志出现在架构图上。这种答案理应得到白眼。在深入探讨之前，我应该披露我的立场：我在 Camunda 工作，而本指南中可能的答案之一就是我雇主销售的产品类别。请相应地对我的观点进行打折。我会努力通过具体说明权衡、诚实地列出替代方案，并告诉你何时你根本不需要这些来重新赢得信任。

正确的答案是关注点分离。代理框架非常擅长内循环：将目标转化为行动的推理、工具选择和记忆循环。它们在结构上不适合拥有外循环：无论是否涉及 LLM，机构都必须承担的一系列义务。银行需要的答案不是推倒重来。它是一个 控制平面，可以编排基于任何框架构建的代理，并明确哪个循环拥有什么。这份指南就是那份白皮书的通用版本。

内循环和外循环

内循环是框架在接收任务和产生结果之间运行的过程。组装提示，推理目标，选择工具，调用工具，读取输出，更新记忆，决定是否再次循环。LangGraph、CrewAI 和 OpenAI Agents SDK 在这方面确实表现出色，并且它们正在快速改进。我无意取代它们，你也不应该。如果你的团队在使用 LangGraph 方面效率很高，那是一项资产。

外循环是机构必须围绕该循环进行的所有操作。它不是智能。它是责任。这两个循环有不同的所有者、不同的生命周期和不同的受众。

内循环（由代理框架拥有）	外循环（由 控制平面 拥有）
推理和规划	无需自定义日志记录即可存在的 审计追踪
工具选择和调用	带有身份和授权的 人在回路 审批
提示组装和上下文管理	SLA、升级和持久计时器
短期和情景记忆	数据化策略，由合规部门拥有
自我纠正和错误输出重试	长期运行工作的版本控制和迁移
结构化输出和工件生产	一站式事件调查
模型选择和令牌经济学	原子取消和补偿

重要的主张不是说框架今天缺乏这些功能。而是说它们在结构上不适合承载这些功能。框架运行在你的应用程序进程内部。它的状态存储是为了图可以恢复，而不是为了审计员可以证明。它的授权上下文是你的应用程序传入的任何内容。它的生命周期是部署的生命周期。外循环的要求是机构性的：它们必须超越进程、部署、团队重组，有时甚至超越框架本身。LangGraph 的检查点机制是用于恢复的优秀工程。它从未被设计为证据。OpenAI Agents SDK 中的防护措施与它们所保护的代理运行在同一个进程中，而这正是控制不应该存在的地方。公平地说，围绕这些框架的托管平台（LangSmith、LangGraph Platform 及其等效产品）确实增加了可观察性和运维工具。但它们增加的是面向开发人员且受框架限制的功能。外循环的受众包括那些永远不会打开追踪查看器的人：合规官、内部审计、运营人员，以及最终的监管机构。

外循环的五项义务

当我撰写最初的白皮书时，我不断删减列表，直到只剩下那些经受住实际审查的义务。有五项保留了下来。

1. 无需自定义日志记录即可存在的审计追踪

测试很简单：你能在没有任何开发人员记住记录日志的情况下，重构发生的一切吗？如果答案取决于散布在代理代码中的 logger.info() 调用，那么你没有 审计追踪。你只有一本由志愿者保管的日记。

审计员的问题是具体的。谁发起了这个案例？系统在每个步骤中知道什么？哪个版本的哪个策略被评估了，输入是什么？谁批准了该行动，依据什么权限？应用程序日志无法可靠地回答这些问题。它们被采样，按以天为单位的保留计划轮换，被管道配置修改，并由开发人员在周四下午 4 点认为有趣的内容塑造。从中重构一个案例是考古学，而考古学是当文明未能保存记录时你所做的事情。

控制平面 颠覆了这一点。当过程的每一步都是引擎中的状态转换时，历史就是执行的副产品。追踪记录不会偏离现实，因为追踪记录就是现实的执行方式。这是该模式最强有力的论据，并且在开发时无需额外成本。你通过将工作放入记录器中来实现这一点，而不是要求工作器也记住写入。

2. 带有身份和授权的 人在回路

每个框架现在都提供了一个暂停原语。LangGraph 有 interrupt()。其他框架也有等效功能。暂停不是审批。审批是暂停加上授权模型，而授权模型才是难点。

真正的机构审批意味着：一组明确的人员可以批准此特定操作，这些人员从目录中解析，而不是硬编码。四眼原则（制作者-检查者），即发起案例的人不能是批准案例的人。基于金额的路由，2,000 美元的异常发送给团队负责人，200,000 美元的异常发送给指定官员。审批人休假时的委托，以及无人处理时的升级。以及谁在何时、在哪个版本的案例数据上点击的不可变记录。

这些都不是框架的工作，框架也正确地不尝试这样做。但这必须是某人的工作。危险的中间状态是将暂停原语连接到任何方便的通道，这就是审批最终变成 Slack 消息的方式。我将在下面回到这个失败，因为我亲眼目睹了它的发生。

3. 时间作为一流公民

代理框架以“回合”为单位思考。机构以“天”为单位思考。一个争议案例等待商家回复十一天。一个贷款异常在漫长的周末期间由承销商处理。KYC 更新附带监管时钟。在这些案例的生命周期中，上下文窗口早已消失，Pod 已经重启两次，代理背后的模型已经升级，应用程序也部署了四次。外循环必须在无人察觉的情况下经受住所有这些。

这意味着持久计时器，而不是 setTimeout()，也不是你在周五编写的读取表的 cron 作业。这意味着将 SLA 建模为带有升级链的数据：如果 48 小时内未获得批准，通知经理；72 小时后，重新路由。这意味着一个案例可以休眠三周而无需任何成本，并在原处醒来。持久执行引擎和 BPMN 引擎都原生支持这一点，因为它们都是由那些在自制版本崩溃时被呼叫的人构建的。框架在持久性方面越来越好，但用于恢复的持久性比作为具有升级语义的建模原语的时间承诺要小。

4. 数据化策略，由合规部门拥有

这是我在会议中重复次数最多的一句话：预算检查不应存在于模型内部。

如果你的支出限额是系统提示中的一句话（“绝不批准超过 500 美元的退款”），那么你没有控制。你只是向一个随机系统，在一个对抗性输入也能写入的通道中，礼貌地提出了一个请求。提示注入是戏剧性的失败，但平庸的失败更糟：即使模型每次都遵守，你也无法证明。 “我们告诉了模型”这句话你绝不想对内部审计说。

评审意见：一个你无法展示其评估过程的策略，与你根本没有策略是无法区分的。审计师在 LLM 出现之前很久就明白了这一点。

模式是数据化策略，在模型外部进行评估，在代理行动之前或之后，但绝不在其内部。决策表（如果你在 BPMN 世界中，就是 DMN，但规则服务甚至经过充分测试的策略模块也符合条件），合规部门可以读取、版本化和更改，而无需代码部署。代理提议：“退款 650 美元，这是我的理由。”策略处理：金额超过阈值，路由到人工审批。分工明确。模型提供判断。表格提供限制。当限制改变时，合规部门编辑一行，更改被版本化，并且不涉及提示工程师。

5. 可操作性

最不吸引人的义务，也是决定系统能否存活到第二年的义务。四项能力，都枯燥无味，但都至关重要。

暂停和恢复而不丢失上下文：不仅仅是代理的记忆，而是整个案例，包括其计时器和待处理的审批。运行中实例的迁移：你部署了流程版本 3，但仍有 4,000 个案例在版本 1 上运行中，其中一些将运行数周；你需要工具将旧状态映射到新定义，或者有意让不同版本并行运行并逐渐耗尽。原子取消：当一个案例必须终止时，所有相关的一切都随之终止，已提交的步骤会触发补偿操作，并且没有孤立的代理会继续向虚空调用工具。以及一个调查地点：当运营部门询问“案例 8842 在哪里，为什么卡住了”时，答案应该在一个屏幕上显示，而不是在四个服务和一个 Slack 线程中进行 grep 搜索。

框架对这些几乎没有任何说明，这没关系。这不是它们关注的问题。这必须是你的问题。

控制平面 是一个角色，而不是一个产品

以上所有内容都描述了一个角色。至少有三类技术可以胜任，我见过所有这三种都有效。诚实的比较比我雇主所属的类别更重要。

选项 A: BPMN 引擎

Camunda、Flowable 及其相关产品。它们的优势几乎与这五项义务一一对应，因为工作流引擎早在代理出现二十年前就是为解决这类问题而构建的。执行历史是原生的且完整的。带有身份、候选组和四眼原则的 人在回路 任务是内置的。计时器和升级是你可以指向的模型元素。策略外部化在决策表中有一个一流的解决方案。实例迁移工具之所以存在，是因为长期运行的流程使其成为必要。并且流程模型可供非工程师阅读，这听起来很“软”，直到合规部门签署实际可执行工件而不是一份与其脱节的 Confluence 页面时，你才会明白它的重要性。

在机构规模下，还有两个特性很重要，它们是这类产品在我参与的受监管行业评估中屡获成功的原因。首先，这里的规模是经过验证而非预测的：这类引擎已经在全球一些最大的银行、保险公司和零售商运行核心流程，并且当前一代经过重新架构，正是为了水平扩展、高吞吐量的工作负载，这意味着你计划的代理流量小于这些引擎已经承载的支付流量。其次，治理界面是一个产品，而不是一个项目：用于调查卡住的实例、重放事件或迁移一万个运行中案例的运营工具是现成的，并且有供应商对此负责。当代理在凌晨 2 点出现异常时，“打开操作控制台”和“grep 事件存储”之间的区别就是事件和中断之间的区别。

成本是真实的。你运行一个引擎，而引擎具有操作负担。BPMN 有学习曲线，一些开发人员对任何看起来像“代码即图表”的东西都有过敏反应。需要建模纪律；一个草率的 BPMN 模型会像草率的代码一样腐烂，只是更明显。

选项 B: 持久执行运行时

Temporal、Restate 和云原生等效产品。这些是卓越的工程产品，具有业界最强的持久性语义：事件溯源历史、确定性重放、作为一流原语的计时器和多周休眠，以及用于演进工作流的版本控制 API。如果你的组织是代码优先且对可视化模型过敏，这是一种合法的角色填充方式，我尊重的团队也曾这样做过。

差距是机构性的而非技术性的。事件历史是为了使重放正确而存在，而不是为了让审计员的生活轻松；它是面向开发人员的，合规官无法阅读 Go 工作流。带有目录解析身份、四眼原则和委托的 人在回路 任务管理需要你自己构建。策略外部化需要你自己构建（大多数团队会附加 OPA 或规则服务，这可行但增加了你现在也需要治理的集成）。你绝对可以在 Temporal 上构建外循环。只是要预算到你是在构建它，而不是配置它。

选项 C: 有纪律的自研状态机

Postgres，一个 state 列，工作器，一个发件箱表。不要让任何人告诉你这总是错误的。对于一个流量适中且团队稳定的流程，这通常是正确的第一个步骤，我见过它做得很好。没有新基础设施，完全控制，每一行都理解。

权衡是纪律是承重的，而纪律会衰退。你将重新实现持久计时器、升级和版本控制，每个大约 80% 正确。 审计追踪 的质量只取决于你最弱的代码审查员。而杀手是运行中迁移：失败模式不是第一天，而是第十八个月，当流程版本 3 遇到 4,000 个仍在运行版本 1 的实例时，没有工具，只有一个非常长的事件通道。

义务	BPMN 引擎	持久执行	自研
无需自定义日志记录的 审计追踪	原生	部分（重放历史，面向开发人员）	自行构建
带有身份、四眼原则的 人在回路 任务	原生	自行构建	自行构建
持久计时器、SLA、升级	原生	原生（升级：自行构建）	自行构建
数据化策略，非开发人员可编辑	原生（决策表）	附加（OPA、规则服务）	自行构建
运行中实例迁移	工具已存在	API 已存在，需要投入精力	第 18 个月的事件
合规部门可读	是	否	否
运营和学习成本	引擎 + BPMN 曲线	集群 + 确定性规则	启动成本最低，但会累积

根据你的组织特点来选择，而不仅仅是这张表。但要慎重选择，因为默认选项（外循环无处不在，散布在应用程序代码中）是唯一总是失败的选项。

集成模式：编排，而非替换

银行的担忧，表面上是合理的，即增加一个 控制平面 意味着重写他们的代理。事实并非如此，任何需要这样做的架构都是错误的。有效的模式是将每个代理保留在其原生框架中，并将流程模型置于其之上。

流程就是代理，而不是对某个代理的附带调用。

这句话就是整个设计。从机构的角度来看，重要的单位是端到端流程：解决争议、开立账户、审查信用证。这个流程是接受审计的，是承载 SLA 的，是监管机构询问的。LLM 循环是其中的一项活动，而不是围绕它的容器。如果颠倒过来（以代理为中心的应用程序代码，偶尔调用工作流），那么每个外循环义务都会回到应用程序代码中，而这正是本指南的起点。

具体来说，对于一个争议案例：

1. 控制平面 使用业务键和关联 ID 启动一个案例实例。从这一刻起，就有了历史记录。
2. 一个确定性步骤收集账户数据。没有代理。它是一个查询。
3. 控制平面 将分流代理作为任务调用。代理运行在自己的运行时中（LangGraph、CrewAI，无论团队选择什么），并通过 A2A 作为对等代理访问，或者其能力通过 MCP 作为工具暴露。内循环完全在框架内部运行：推理、工具调用、记忆。 控制平面 看到一个正在进行的任务，然后一个工件返回。
4. 代理的提议进入流程变量。决策表对其进行评估：金额、客户等级、欺诈分数。低于阈值，自动进行。高于阈值，为正确的审批组创建一个 人在回路 任务，强制执行四眼原则，并启动一个 48 小时升级计时器。
5. 批准后，执行步骤运行。每个转换，包括代理的任务和审批人的身份，都已在历史记录中。没有人记录任何东西。

协议边界是使其与框架无关的原因。A2A 为 控制平面 提供了一种标准方式，将任务交给它不托管的代理并接收工件，同时代理团队保留对其堆栈的完全所有权；我在 A2A 现场指南 中详细介绍了其机制、卡片发现和故障模式。MCP 涵盖了工具型案例。团队保留他们的框架、评估和部署管道。机构获得一个主干。

这种模式也是代理发挥价值的地方。在一个贸易金融概念验证中，将文件审查移至代理步骤，使信用证审查从数小时缩短到数秒。代理产生了那个数字。 控制平面 使这个数字在生产中可用：每个被审查的文件都留下了审计事件，每个异常都被路由给有权限的人，并且为期两周的案例在每次部署之间都得以存活。

何时你不需要 控制平面

这一节是你应该信任其余内容的原因。 控制平面 并非免费。你正在增加一个需要操作的引擎，一个需要版本控制的模型或工作流工件，每个边界处的延迟，以及你的值班轮换人员必须理解的第二个系统。不要为聊天机器人支付这些。

当人类在任何事情发生之前 100% 审查所有输出时（起草助手不是自主系统，无论演示文稿怎么说），你不需要 控制平面。你不需要它用于内部开发工具、原型，或任何最坏失败只是一个糟糕段落的东西。你不需要它用于没有副作用的单次生成。在所有这些情况下，仅使用框架，或者根本不使用框架，都是恰当的架构。

更早一步，问问你是否首先需要一个代理。我的启发式方法，来自我写的一篇关于开放银行的文章，是计算工具数量和路径中的偏差：“当你遇到那种偏差程度，你可以使用三个工具而不是十个工具时，那就是代理式 AI 更适合的地方。”三个工具和一条可预测的路径就是一个程序。编写代码，或建模一个确定性工作流，免费获得确定性。十个工具，每个案例所需的高度可变性，判断使用哪个以及按什么顺序使用：这就是内循环赚取其令牌的地方。我曾看到团队在一个流程上部署代理，承担所有评估负担，而那个流程不过是三条 if 语句披着一件风衣。

当外循环义务不再是理论时，控制平面 就变得必要。金钱或承诺在没有人接触每个环节的情况下流动。工作超越了上下文窗口和部署。监管机构或你自己的审计职能部门可以问“系统为什么这样做”，并期望得到答案。多个团队的代理必须组合成一个流程。如果满足其中两项或更多，问题就不再是你是否有外循环，而只是它是故意的还是偶然的。

当外循环存在于框架内部时会发生什么

三个失败案例，从我审查过的真实系统中概括而来。细节已更改，结构保持不变。

随 Pod 消失的审计追踪

一个团队构建了一个代理管道，它在内存中组装完整的推理追踪，并在每次运行结束时写入一条合并记录。设计简洁，易于阅读，直到一个 Pod 在操作已经执行后，在运行中因内存不足被杀死。结果：一个已执行的操作，但没有记录其原因。检查点存储有恢复所需的图状态，但恢复状态不是证明，而且该存储的保留策略是由一个没有人阅读过的基础设施默认设置的。解决方案不是更好的日志记录。而是将每个步骤的完成移到一个记录不是可选的引擎中，这样崩溃可能会丢失未来，但绝不会丢失过去。

变成 Slack 表情符号的审批

人在回路，实现为向通道发送消息；通道中任何人的点赞都会恢复图的运行。演示效果很棒。然后问题来了：到底是谁批准了案例 4417？那个人是否有权批准那个金额？消息在点赞后是否被编辑过？当审批人离职且其账户被停用时会发生什么？还有一个问题终结了设计评审：工作区保留策略在 90 天后删除消息，这意味着审批证据的生命周期比它批准的贷款还要短。审批是一个附带身份的授权事件。表情符号都不是。

存在于系统提示中的预算检查

一个退款代理，其限额以系统提示指令的形式表达。一次红队演练在一天内通过一次不起眼的注入绕过了它。但重要的发现是反事实：即使模型每次都坚守底线，机构也无法证明其执行情况。没有可展示的工件，没有评估日志，没有版本化的策略。将限额移入在代理提议后评估的决策表，将一个无法证明的行为变成了有证据的控制。提示仍然提及限额，作为对模型的礼貌。表格才是强制执行者。

评审意见：所有这些系统在演示中都运行良好。外循环在演示中是不可见的，因为演示不会崩溃，不会被审计，也不会运行三周。

监管机构实际要求什么

这里重要的文件都没有提到“代理”。它们不需要。将它们解读为对外循环的要求，映射关系是直接的。这是一种审慎的解读，而非恐吓；这些期望中的大多数都是一个运行良好的系统无论如何都想要的。

OSFI 更新的《模型风险管理指南 E-23》（2025 年 9 月定稿，2027 年 5 月 1 日起对加拿大所有联邦监管金融机构生效）明确将 AI 和机器学习纳入范围，并要求生命周期治理：清单、设计、审查、部署、监控和明确的问责制，与风险成比例。一个完全存在于应用程序代码内部的代理系统，几乎将所有这些期望都变成了手动文档项目。 控制平面 使其中大部分成为副产品：清单是已部署的流程和决策定义集，生命周期是版本化工件历史，监控是引擎自身的运营数据。

欧盟 AI 法案将自然人信用评估列入附件 III，这使得信用决策代理成为高风险系统；这些义务将于 2026 年 8 月 2 日起强制执行。第 12 条要求自动生成事件日志，这正是本指南中义务一的监管语言（“自动”是关键词；志愿者日志不符合要求）。第 14 条要求有效的人工监督，这正是义务二，包括监督意味着一个有权限和干预能力的人，而不是一个在通道中被抄送的人。

SR 11-7，美联储的模型风险指南，自 2011 年以来一直是美国银行的基准，其对模型的定义（一种将输入处理成估计值并应用于决策的定量方法）轻松涵盖了 LLM 驱动的代理。其核心要求是有效挑战：独立验证、文档和清单。你无法有效挑战一个其决策路径仅存在于应用程序日志和提示文件中的系统。你可以挑战流程模型、决策表和执行历史，因为它们是可检查的、带有版本的对象。

这三者共同的模式是：监管机构正在趋向于生命周期治理、自动记录和负责任的人工监督。这些正是内循环无法提供而外循环旨在提供的东西。分离循环的机构会发现合规性大多是架构的自然结果。不分离循环的机构将运行一个平行的文书工作流程，描述一个它实际上无法看到的系统。

一段话总结

代理框架（LangGraph、CrewAI、OpenAI Agents SDK）非常擅长内循环：推理、工具选择、提示组装、记忆。它们在结构上不适合拥有外循环：无需自定义日志记录即可存在的 审计追踪、带有身份和四眼原则的 人在回路 审批、作为一流公民的时间、由合规部门拥有的数据化策略，以及长期运行工作的可操作性。答案不是推倒重来；它是一个 控制平面，可以编排任何框架中构建的代理，通过 A2A 或 MCP 访问，并将流程模型作为受治理的工件。流程就是代理，而不是对某个代理的附带调用。使用 BPMN 引擎、持久执行运行时或有纪律的自研状态机来扮演这个角色，并清楚地了解每种方案的哪些功能是原生的，哪些会成为你的问题。对于原型和 人在回路 审查的工具，可以跳过所有这些；当三个工具和一条可预测的路径意味着你只需编写代码时，则完全跳过代理。在审计员、监管机构或你自己的事件审查第一次提出你的日志无法回答的问题之前采用它。

参考资料

• OSFI，指南 E-23：模型风险管理 (2027)，2025 年 9 月定稿，2027 年 5 月 1 日生效。
• 欧盟 AI 法案，附件 III：高风险 AI 系统 和 第 12 条：记录保存；附件 III 义务自 2026 年 8 月 2 日起强制执行。
• 美联储，SR 11-7：模型风险管理指南 (2011)。
• Camunda 博客，代理式 AI 助力开放银行，上文引用的三工具与十工具启发式方法的来源。
• Camunda 博客，使用 A2A 实现您的业务目标，第 1 部分 和 第 2 部分，我合著的代理间集成模式文章。
• A2A 协议规范 和 模型上下文协议，集成模式中引用的两个互操作层。
• LangGraph 文档（持久性和 interrupt()）、OpenAI Agents SDK 和 Temporal 文档，用于讨论的内循环和持久执行能力。
• 本站相关内容：A2A 现场指南。