跳转到主要内容
一个 Workflow 定义允许执行的步骤与转移。一个 Run 保存某次运行的输入、状态、动作、等待和证据。同一工作流可以有多个互相独立的 Run。

核心对象

修改工作流定义时使用新版本,并保留活动 Run 引用的定义。编辑说明文字、改状态 JSON 或填写“完成”不能替代合法转移。

定义你允许执行的路径

entry 是启动时就绪的步骤,steps 的键是图中步骤名称,ref 是执行器处理函数名称。transitions 声明允许的后续路径。多个步骤可以调用同一个处理函数,但各自保留独立的执行记录。 将 workflow 传入 createRuntime,使用固定 id/version 启动 Run。完整可运行示例见 快速接入。

读取推进结果

调用 runUntilBlocked 后,优先读取 reason,再读取对应动作、等待和业务输出。 inspect 读取记录,不调用模型或工具。业务 UI 应同时显示当前 Run、待处理 Action/Wait 和最后一次错误,方便用户选择继续、审批或核对。

定义步骤

从 @rpamis/comet/runtime 导入 defineWorkflow,或像 快速接入 一样使用工作流定义对象。 步骤间的依赖决定什么时候可以派发。并行步骤可以按不同顺序完成;合流条件必须明确。循环和分支沿已声明的转移执行,不能通过处理函数跳到图外。

执行器与结果

createRuntimeExecutor 按步骤 ref 注册具名处理函数。defineRuntimeHandler 先解析输入,再交给业务函数执行,避免在一个大函数中按步骤名分派。 已有平台需要自行领取和回报时,可以使用 Runtime 的 claim、recordOutcome 和 retry 接口。保留当前 Action 的身份、attempt、输入摘要和领取凭据,回报必须属于这一次执行。 成功结果还会经过输出 Schema 和业务验证器检查。已知失败直接记录为失败结果;已经派发、但执行器抛错或结果回传中断时,操作可能已经发生,按未知结果处理。完整恢复规则见 恢复与未知结果。

用户等待

审批决定绑定 Wait ID 和当前提案摘要。提案变化后,需要重新展示并确认。旧批准、另一次激活的批准或执行器伪造的批准,不能授权当前动作。 证据等待由 Agent 平台提交实际证据,Runtime 校验其归属和声明条件。步骤结束、证据通过和外部服务确实完成是不同事实,业务界面应分别显示。

存储与 Agent 平台职责

createMemoryRuntimeStore 适合不需要跨进程恢复的试验。createFileRuntimeStore 将 Run 保存在你指定的目录,新进程注册相同定义和执行器后可以继续运行。 Runtime 不会自动调用模型、配置 MCP、注入插件上下文或替 Agent 平台取得授权。需要固定 Skill、安装入口、业务文件保护和分发时,使用 Workflow Application。 按功能继续学习:执行器、并行与合流、子工作流、业务状态与循环。
最后修改于 2026年10月22日