Workflow
Workflow 是 Jarvis 的多 worker 生产线。它把一个任务拆成多个节点，让不同编码会话按依赖关系串行或并行工作，并在每个节点完成时用结构化 handoff 交接给下游。
在实现里，这套能力也叫 Pipeline。面向用户的文档统一称为 Workflow 或生产线。
一个 Workflow 包含两部分：
- 定义：生产线名称、节点列表、依赖关系、失败策略和自动监督设置。
- 运行：某次输入任务后的执行实例。运行开始后会冻结当时的定义快照，后续编辑不会改变已经启动的运行。
节点本质上是一个可启动的 worker 会话。它可以指定 Agent Profile、运行时、模型、工作目录、权限模式、skills、交接 schema 和是否需要人工批准。
为什么需要它
标题为“为什么需要它”的章节单个 worker 适合线性任务。Workflow 适合这些情况：
- 同一问题需要多个 worker 独立探索，然后汇总；
- 先做调研、再做实现、再做审查，阶段之间必须有明确交接；
- 某些节点有危险动作，需要在启动前停下来等人工批准；
- 主聊天只需要看关键状态，不希望被完整终端输出淹没；
- 想把一条成功的工作方法保存下来，反复用于类似任务。
Workflow 的目标不是替代主脑判断，而是把可重复的编排步骤固化成确定性状态机。
核心词汇
标题为“核心词汇”的章节| 词汇 | 含义 |
|---|---|
| Definition | Workflow 的可编辑定义。草稿不可运行，发布后才能启动。 |
| Run | 一次具体运行，包含输入任务、节点状态和冻结后的定义快照。 |
| Node | 一个 worker 会话启动规格，包含 prompt、运行时、权限、Profile 等。 |
| Stage | Studio UI 中的阶段。后一阶段默认依赖前一阶段所有节点，适合表达串行/并行拓扑。 |
| Dependency | depends_on 声明的节点依赖。上游成功后，下游才会进入可启动状态。 |
| Handoff | 上游节点完成时交给下游的结构化 JSON 结果。 |
| Output Schema | 节点 handoff 的 JSON Schema 子集。为空时使用默认 summary/artifacts/notes 结构。 |
| Failure Policy | 节点失败后整条运行如何处理：暂停、快速失败或继续独立分支。 |
| Approval Gate | requires_approval 启动门。节点到达后等待人工批准再启动 worker。 |
工作方式
标题为“工作方式”的章节- 你在 Studio 或主聊天里创建 Workflow 定义。
- 你发布定义并输入一次
task_input启动运行。 - 引擎根据依赖关系找到可运行节点，并启动对应 worker 会话。
- worker 完成后必须调用 Jarvis MCP
report_progress，用 JSON handoff 汇报结果。 - 下游节点的 prompt 使用
{{task}}和{{upstream...}}变量读取输入与直接上游 handoff。 - 如果节点失败，Workflow 按
failure_policy暂停、失败或继续其它独立分支。 - 所有节点成功后，运行收敛为成功；终态后可以一键退出这次运行创建的 worker 会话。
主脑在这个过程中负责观察和干预。它不会手动启动下游节点；下游推进由 Workflow 引擎确定性完成。auto_supervise 开启时，Workflow 会使用自主监督让主脑在阻塞、待授权和收尾时自动回来跟场。
- Studio 主要用 Stage 表达串行和并行，不是任意 DAG 画布。需要精细 DAG 时可通过 JSON/API 定义
depends_on。 - 模板变量只渲染直接依赖的上游节点。引用非直接依赖会保留为原始文本。
output_schema是 JSON Schema 子集，只支持type、properties、required、items、enum等常用字段。additionalProperties目前更接近注释，不应当作严格额外字段拦截。- Extension 提供的 Workflow 通常是 locked；需要复制后再编辑。
- Workflow 不会绕过运行时权限。节点权限、Profile 权限、运行时本地权限仍共同生效。