核心对象
修改工作流定义时使用新版本,并保留活动 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。
按功能继续学习:执行器、并行与合流、子工作流、业务状态与循环。
