Workflow zh

工作流

未实现——依赖子代理和后台任务能力。

上游参考：Workflow

上游提供了什么

工作流子系统让模型编写并执行可并行生成子代理的编排脚本。由三个组件组成：

• WorkflowEngine（ctx.workflowEngine）— 在 Node.js worker thread 中执行脚本，每次运行一个 worker。提供 agent()、parallel()、pipeline() 和 phase() 原语。
• WorkflowWorkerThread（dsh-workflow-worker-thread）— Node.js worker_threads 执行后端。
• ToolWorkflow（dsh-tool-workflow）— 模型工具，接受脚本并管理运行生命周期。

脚本返回结构化结果。致命错误（schema 违规、限制超出）立即抛出；非致命失败（子代理错误）在组合器中映射为 null。持久化 tool-workflow/run-start 和 tool-workflow/run-end 事件写入父 session 日志。

当前 Edge 状态

未实现 三个工作流包均不在 Edge 的依赖中。未安装工作流引擎、工具或执行后端。

尚未满足的依赖

依赖	Edge 状态	影响
SubagentRuntime	未实现	工作流脚本通过 agent() 生成子代理
JobRegistry	未实现	工作流运行作为后台任务追踪
worker_threads	不可用	上游执行后端使用 Node.js workers

Edge 已有的基础

Edge 有多轮代理协调的先例：GoalRoundDriver 已经在单个代理内编排跨 turn 的自主续跑。这是同一模式的简化形式——无并行扇出的顺序步骤。工作流增加了并行子代理生成，需要完整的 SubagentRuntime。

Cloudflare 可用产品

Cloudflare 产品	可启用	Plan
DO 进程内执行	DO isolate 内的单线程脚本执行（无 worker_threads）	免费
Cloudflare Containers	完整 Node.js worker thread 环境，用于重型编排	付费 / 企业
Dynamic Worker dispatch	将子代理作为独立 Worker 调用生成，由 DO 协调	付费

免费用户最可行的路径是 DO 内的单线程执行引擎，同步运行工作流脚本（无真正并行，但顺序 agent() 调用可工作）。真正的并行扇出需要付费 plan 的 Containers 或 Dynamic Worker dispatch。

架构总结

组件	分类	状态
WorkflowEngine	缺失	未安装——需要执行后端
ToolWorkflow	缺失	未安装——需要引擎
执行后端	缺失	worker_threads 不可用；需要 DO 或 Container 替代

关键观察：工作流被两个缺失能力（子代理、后台任务）和一个平台差距（worker_threads）阻塞。这是复合依赖——实现它需要先解决底层组件。但简化版的单代理顺序工作流可以在 Edge 现有的 GoalRoundDriver 模式内工作，无需任何这些依赖。

TODO

**评估简化版 DO 内工作流引擎。**一个在 DO isolate 内运行的单线程执行后端（无 worker_threads）可以支持顺序工作流脚本。上游 WorkflowEngine 服务接口可能接受替代后端。评估 DO 内部后端能否在不支持并行子代理的情况下满足接口。

**先解决上游依赖。**完整的工作流支持需要子代理和后台任务。这些应独立评估后再尝试工作流集成。