Agent Workflow 的流程图展示，核心不是简单画节点和连线，而是把 Agent 的“编排结构”和“运行轨迹”抽象成一个可解释、可交互、可实时更新的有向图。

比较合理的实现方式是先定义一套统一的数据模型。Workflow 本身可以抽象成 nodes 和 edges，节点表示一个执行单元，比如 LLM 调用、Tool 调用、Retriever、Router、Condition、Human Approval、Sub Agent、Start/End 等；边表示执行顺序、数据依赖或条件分支。节点还要包含运行态字段，比如 status、input、output、error、duration、tokenUsage、retryCount 等。

复制
1type WorkflowNode = {
2  id: string;
3  type: 'llm' | 'tool' | 'router' | 'condition' | 'human' | 'start' | 'end';
4  label: string;
5  status?: 'idle' | 'running' | 'success' | 'failed' | 'skipped';
6  input?: unknown;
7  output?: unknown;
8  error?: string;
9  position?: { x: number; y: number };
10};
11
12type WorkflowEdge = {
13  id: string;
14  source: string;
15  target: string;
16  label?: string;
17  condition?: string;
18};

前端展示层可以直接使用成熟的图编辑或图展示库，比如 React Flow、AntV X6、G6。如果偏业务流程编排和交互编辑，React Flow 会比较顺手；如果图关系复杂、节点数量大、需要复杂布局，G6 或 X6 更合适。常见做法是用自定义节点组件来渲染不同 Agent Step，例如 LLM 节点展示模型名和 token 消耗，Tool 节点展示工具名和调用结果，Condition 节点展示分支条件。

布局上需要区分“静态编排”和“运行时轨迹”。静态编排可以保存节点坐标，支持拖拽、缩放、对齐、自动排布；运行时轨迹更适合用 DAG 布局，借助 dagre 或 elkjs 自动计算节点位置，避免流程变复杂后连线交叉严重。对于子流程或多 Agent 协作，还可以把节点分组成 group，支持折叠和展开。

运行态展示是 Agent Workflow 的重点。Agent 执行通常是异步和流式的，所以前端应该通过 SSE 或 WebSocket 接收后端事件，例如 node_started、node_completed、node_failed、edge_activated、workflow_completed。前端收到事件后，只做增量更新：更新节点状态、点亮当前边、追加日志、刷新耗时和输出结果。这样用户能看到流程从哪个节点开始、当前执行到哪里、失败在哪一步，以及每一步的输入输出。

交互上，流程图不应该只停留在“看图”。点击节点后，右侧可以展示详情面板，包括 prompt、tool arguments、tool response、模型输出、错误堆栈、重试记录、耗时和 token 成本。对于失败节点，可以提供重试、跳过、从该节点重新运行等操作；对于 Human Approval 节点，可以直接在节点或侧栏里完成审批。

性能上需要注意大图场景。节点数量较多时，应避免把完整日志直接塞进节点 DOM，节点只展示摘要，详情按需加载；图画布需要控制渲染范围，减少不必要的状态刷新。实时事件更新时也要做批处理，避免高频 token 流导致整个画布频繁重渲染。

整体来看，一个成熟的 Agent Workflow 流程图展示应该同时覆盖三件事：第一是结构可视化，让用户知道这个 Agent 是怎么编排的；第二是运行可观测，让用户知道执行到了哪里、为什么失败；第三是可操作，让用户能调试、重跑、审批或定位问题。