AG-UI：流式传输界面的代理，而非文字记录

停留在聊天框的代理

当今大多数投入生产的“AI 代理”都是带有系统提示的聊天界面。界面是一个文本流。用户看到的是令牌，代理看到的是返回的令牌。那个世界里没有其他东西：没有状态，没有结构，也没有你在流程中处于何处的概念。

但真正的工作不是对话。它是一个包含用户界面、审批和工具的流程。财富客户入职流程不是“告诉我你自己”。它是身份验证，然后是风险评估，然后是 DMN 路由，然后是顾问审查，然后是开户。每个步骤都有状态，产生输出，并以决策结束。将其扁平化为聊天记录，恰恰丢弃了使工作可审计的结构。

AG-UI 是为弥补这一空白而构建的协议。后端不是流式传输文本，而是向前端流式传输类型化的 UI 事件：生成式卡片、工具调用状态、人在回路任务。代理渲染的是一个生动的界面，而不是一份记录。Agents, Orchestrated 的第二集展示了当你将该协议指向流程引擎而不是聊天框架时会发生什么。

我构建了什么：AURUM Private Bank

这个演示是一个虚构的私人银行入职礼宾服务，AURUM Private Bank。客户提出申请。代理协调整个流程，从身份验证到开户，而操作员则在 Camunda Operate 中将同一运行作为实时流程实例进行观察。

三层架构，每一层都物有所值。

体验。 客户不会看着聊天机器人打字。随着流程的推进，卡片一张张地流入界面：身份已验证、风险已评估、投资组合已推荐、顾问审查已标记。每张卡片都是由 React 前端渲染的类型化 AG-UI 事件。它看起来像一个活生生的用户界面，而不是一份记录，因为它确实是。前端没有业务逻辑，它渲染后端发出的内容。

后端。 该流程是在 Camunda 8.9 上执行的 BPMN 流程，你可以看到令牌的移动：摄入，然后是身份，然后是风险，然后是 DMN 路由，然后是顾问审查，然后是 AI Agent，然后是账户开立。顾问审查步骤是一个 USER_TASK，这是我最关心的一个细节。当令牌到达该步骤时，流程会暂停并等待人工操作。不是轮询技巧，也不是 webhook 跳板。而是引擎的原生等待状态。运行的每一步都在 Camunda Operate 中实时可见。

代理。 推理层是多模型的。Amazon Bedrock 上的 Claude 模型和 Gemini 模型对客户数据进行推理，调用 13 个工具中的一个，并在工作时原生发出 AG-UI 事件。不同的模型位于同一流程的不同部分背后，流程引擎确保它们“诚实”：模型可以提出建议，但令牌只有在步骤完成时才会前进。

一个重要的实现说明：此构建中没有 CopilotKit 和 ChatKit。AG-UI 是直接针对 Camunda 8 后端实现的，使用 AG-UI EventSource 协议，即从 Node.js 后端到前端的 React 应用程序的纯 SSE。该协议足够简单，直接实现比采用框架所需的代码更少，并且证明了该模式不与任何特定的前端套件耦合。

流程引擎是关键所在

关键的洞察，也是本集存在的原因：当流程引擎是协调器时，代理式用户体验获得了聊天原生架构无法拥有的特性。不是“尚未拥有”。而是结构上无法拥有，因为聊天架构将状态保存在模型的上下文窗口中。

可靠。 如果代理在流程中途崩溃，BPMN 流程会从令牌停止的地方恢复。状态存储在 Camunda 中，而不是 LLM 的上下文窗口中。连接中断或模型调用失败是重试，而不是丢失的入职流程。

可暂停。 用户任务可以暂停流程，等待人工决策，无论是几分钟还是几周。代理不会空转，不会轮询，也不会保持上下文窗口打开。流程以零成本等待，并在顾问操作时恢复。

可审计。 每个状态转换、每个工具调用、每个决策都记录在 Camunda Operate 中。审计追踪无需一行自定义日志代码即可存在。当有人问“为什么这个客户被路由到顾问审查”时，答案是一个你可以打开的流程实例，而不是你希望已进行检测的日志查询。

这里的模式是编排优先的，并且与引擎无关。我使用的是 Camunda，但这个论点也适用于 Temporal 或任何具有持久状态和原生等待状态的引擎。你无法回避的是让 LLM 成为协调器。

这就是论文的精髓：一个流程，三个模型，零胶水代码。BPMN 流程是唯一的协调层。模型插入其中。没有定制的东西将其连接在一起。

未能登上 LinkedIn 帖子的内容

这些是诚实的记录，因为精美的演示视频隐藏了真实的决策。

银行是虚构的，客户数据是合成的。身份和风险步骤调用的工具返回的是合理的结果，而不是真正的 KYC 提供商。真实的是架构：一个实时运行的 Camunda 8.9 集群，AI Agent Connector v6，对 Bedrock 和 Gemini 的真实模型调用，以及一个真正的 USER_TASK，它确实会阻塞流程，直到演示中的审批台有人完成它。

直接使用 AG-UI 而不是 CopilotKit 花了我一天时间阅读事件协议并在 BFF 中构建 SSE 桥接。这很值得，但我只会在你想了解协议时推荐它；如果你只是想要用户界面，那么框架就足够了。

这 13 个工具是演示所需的数量，而不是基准。多模型路由有效，但我是在设计时为每个步骤选择模型的。此构建中没有任何东西在运行时动态选择模型，而且在让任何东西在客户面前这样做之前，我希望有一个评估工具到位。

而“零胶水代码”的说法需要精确：零编排胶水代码。仍然有一个 BFF 将引擎事件转换为 AG-UI 事件。缺少的是任何决定下一步发生什么的自定义代码。这个决策存在于 BPMN 中，审计员可以在那里阅读它。

发布日志

• 引擎： Camunda 8.9 (SaaS 集群)，AI Agent Connector v6
• 模型： Amazon Bedrock 上的 Claude，Gemini
• 工具： 13 个，由代理层调用
• 协议： AG-UI over SSE (EventSource)，直接实现，无 CopilotKit 或 ChatKit
• 前端： React，将类型化的 AG-UI 事件渲染为生成式卡片
• 后端： Node.js BFF，桥接 Camunda 到 AG-UI
• 人工门控： BPMN USER_TASK (顾问审查)，在 Camunda Operate 中实时可见
• 仓库： letmereviewyourcode/camunda-agui-wealth-demo