从工作流图到执行链：观察 Agent 如何运行
工作流图展示 Workflow 注册了哪些节点、路由和错误恢复关系。执行链展示一次运行实际经过哪些节点、选择了哪些分支、留下了哪些子流程记录。前者帮助阅读程序定义，后者帮助核对运行事实。
这两个接口属于开发辅助。调用它们不会增加模型、工具、角色或业务权限，也不会参与下一步决策、改变调度或推进任务。应用正常运行不需要先导图；演示程序如何运行，也不能作为 Agent 会完成相应业务的证明。
精确字段、数据源和异常合同见工作流图与执行链 API。本文讨论如何使用这些数据，以及如何判断展示结果能说明什么。
先区分定义、记录和视图
| 数据 | 回答的问题 | 不能据此认定 |
|---|---|---|
| 工作流图 | 定义允许从哪里走到哪里，错误后交给哪个节点 | 运行一定选择哪条路，模型为什么作出某项判断 |
| 执行链 | 本次经过哪些节点、重复了几轮、在哪里失败或恢复 | 当前定义包含本次所有历史节点，缺失事件一定没有发生 |
| 原始日志与回执 | 某个事件、调用、结果和关联身份的具体事实 | 一次工具成功就等于整个业务完成 |
| 渲染视图 | 按选定的分组、过滤和布局呈现上述数据 | 图中没显示的事实不存在，布局顺序就是执行依赖 |
执行链来自采集记录，是按主节点执行聚合的只读投影。它不创建第二套运行记录，也不是新的调度协议、可执行脚本或恢复检查点。重新渲染执行链不会重放工具，更不会恢复已结束的任务。
用工作流图审查程序结构
const graph = workflow.toGraph();导图读取注册快照，不执行节点、路由条件或完成函数。因此可以在没有任何运行记录时展示基础图，也可以把 JSON 放进设计审查、代码评审和内部开发工具。
审查时可以沿着入口检查阶段职责、分支、恢复出口与结束条件。多条 route 可能指向同一条拓扑边，展示端应保留它们的顺序和条件身份；入口需要读取 entryNodeId，不能根据入边数量猜测。
图很简单时，先看职责是否完整表达。一个“分发”节点可能只是简单协议选择，也可能在内部串起工具、恢复、校验和交付。只有后者存在独立阶段与失败去向时，才值得把编排提升到 Workflow。增加节点数量本身不会改善分工，也不会增加 Agent 能力。
静态图不会分析函数体，无法自动展开节点内部的工具或自定义子节点。多 Agent 应分别导出各自 Workflow 的定义，角色职责、可用工具、资源范围和交付合同仍由应用自己的声明表达。共用相同的工作流骨架，可以拥有不同的角色约束；图的形状不足以证明它们具有相同权限或专业能力。
用执行链核对一次真实运行
// App 已在创建 Workflow 时绑定授权的 chainSource。
const chain = await workflow.toChain(runId);也可以按调用传入授权读取源。日志路径、账户隔离、保留期、分页与读取范围由 App 负责；导出功能不会自动授予访问其他用户记录的权限。
开发时可以核对：工具失败后是否进入声明的恢复节点、交付被拒绝后是否保留回执、重复访问是否来自新的决策、取消前已经记录了哪些事实。比较多次运行，还可以在应用侧统计路径覆盖、重试次数或阶段耗时；这些分析由应用或开发工具实现，不是导出接口内置的评估能力。
同一 nodeId 可能执行多次，节点执行的身份是 spanId。即使两个节点在数组中相邻，也要使用真实 transition 连接，不能直接把相邻顺序画成依赖。错误事件声明的恢复目标同样是实际跳转证据。
先阅读 coverage，再解释图。事件覆盖不明或缺失时，不能把未显示的节点理解成“没有执行”。content 说明正文是否采集，与事件覆盖分开；完整采集也只说明观察记录完整，不代表用户的业务需求已经完成。
历史记录可能包含当前定义没有的节点。使用历史名称、版本和原始身份呈现，不从当前图补出一条看似完整的历史路线。
给观测界面留下展示选择
Core 聚合主节点的每次执行，节点内部保留按 sequence 排列的扁平 subflow。GUI、终端或开发面板可以建立自己的 DataModel：
- 折叠时，按原始顺序展示该节点的内部过程摘要。
- 展开时，按 subnodeId 分组，并保留跨组的原始顺序号。
- 没有 subnodeId 的记录作为主节点自己的过程呈现。
- 每次 fix 保留独立记录，通过 targetStepId 更新视图，并允许查看原始修订过程。
同组记录可能交叉、并行，也可能只是同一逻辑阶段的分类；分组不产生子节点之间的串行关系。子 Agent 有自己的工作流执行，观测工具可以通过真实调用身份与父节点关联，不应把整个子工作流误画成父节点的一组平行步骤。
toChain 返回读取时的数据快照。需要实时界面时，由 App 接收原有事件观察流，再按自己的规则更新视图；导出接口本身不是订阅通道。布局、展开、筛选、状态投影和渲染都由消费端拥有。
演示能说明什么
演示适合解释应用如何组织职责、请求在哪一步、子 Agent 怎样接收任务，以及失败如何被处理。展示时明确区分静态定义图、某次运行记录，以及使用离线模型脚本的测试运行。
离线脚本配合真实工具，可以验证指定路径的编排与调用合同；它没有验证真实模型会不会作出同样选择。静态图不能证明运行已经发生；一条成功执行链也不能证明所有业务输入、外部依赖和失败场景都有效。业务验收仍需相应输入、实际调用与真实结果的证据。
与日志复盘的关系
App 可以把授权范围内的日志交给 Agent 的复盘流程，提取问题、假设和改进建议。是否把建议写入记忆、转成规则或发布为程序变更，由 App 另外组织；记录本身不自动形成学习闭环。
工作流图与执行链目前提供开发侧的结构与运行投影，没有自动接入决策、学习或规则修改。若应用需要把这些投影作为复盘输入，应明确选取字段、保留覆盖缺口，并沿用原有授权和内容策略。导出并不赋予这类业务能力。
查看底层记录与关联方式，可继续阅读请求、调用链与 Journal；组织复盘、分支和建议处理时，参阅复盘、分支和资料发布。