创建 Workflow

这份指南用一条两节点生产线说明 Workflow 的基本路径：第一个 worker 做代码审查，第二个 worker 读取上游 handoff 并输出面向人的摘要。

前置条件

Jarvis 已经运行。
至少一个编码运行时 CLI 可用并已登录。
你能打开 Jarvis UI 的 Studio 页面。
目标仓库或目录已经准备好，worker 有权限读取。

适用场景

这类 Workflow 适合把一个任务拆成固定步骤：

先并行调研，再汇总；
先做只读审查，再由另一个节点写报告；
先让低权限节点分析，再让需要权限的节点执行。

如果只是给现有会话补一句后续指令，优先使用派发任务。

用 Studio 创建

打开 Jarvis UI，进入 Studio。
选择 Workflows · 生产线。
点击新建 Workflow，填写名称和描述。
保持 failure_policy 为 pause，保持 运行时自动开启主脑监督（异常时主脑介入处置） 勾选。
在第一个 Stage 创建节点 review，让它只读检查目标。
新增第二个 Stage，创建节点 summarize，在 prompt 中读取 {{upstream.review.summary}}。
保存并发布 Workflow。
点击运行，输入这次任务的目标。

Stage 的含义很直接：同一个 Stage 内的节点可以并行；下一 Stage 默认依赖上一 Stage 的所有节点。

auto_supervise 对应这个 UI 选项。它会在 Workflow run 期间使用同一套自主监督机制，让主脑在异常、阻塞和收尾时跟场；下游节点仍由 Workflow 引擎按依赖关系启动。

完整导入示例

也可以把下面的 JSON 保存成文件，然后在 Workflow 列表页点击 导入。导入后可直接运行。

{
  "name": "两步代码审查摘要",
  "description": "先只读审查变更，再汇总成面向人的结论。",
  "failure_policy": "pause",
  "auto_supervise": true,
  "nodes": [
    {
      "id": "review",
      "name": "只读审查",
      "profile_id": null,
      "prompt_template": "请只读检查这次任务相关的代码和文档，找出行为风险、文档缺口和需要验证的点。任务：{{task}}",
      "runtime": "auto",
      "cwd": null,
      "model": null,
      "effort": "medium",
      "permission_mode": null,
      "skip_permissions": null,
      "isolate": null,
      "depends_on": [],
      "output_schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "findings": {
            "type": "array",
            "items": { "type": "string" }
          },
          "verification": {
            "type": "array",
            "items": { "type": "string" }
          }
        },
        "required": ["summary", "findings"]
      },
      "skills": [],
      "requires_approval": false,
      "reuse_session_of": null
    },
    {
      "id": "summarize",
      "name": "汇总结论",
      "profile_id": null,
      "prompt_template": "请根据上游审查结果写一份简短结论，先列必须处理的问题，再列建议验证。任务：{{task}}\n\n上游摘要：{{upstream.review.summary}}\n\n完整上游 JSON：{{upstream.review.json}}",
      "runtime": "auto",
      "cwd": null,
      "model": null,
      "effort": "medium",
      "permission_mode": null,
      "skip_permissions": null,
      "isolate": null,
      "depends_on": ["review"],
      "output_schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "decision": {
            "type": "string",
            "enum": ["pass", "needs_changes", "blocked"]
          },
          "next_steps": {
            "type": "array",
            "items": { "type": "string" }
          }
        },
        "required": ["summary", "decision"]
      },
      "skills": [],
      "requires_approval": false,
      "reuse_session_of": null
    }
  ]
}

permission_mode: null 表示节点继承本次启动时的 worker gear。只有 workflow 作者明确要覆盖用户启动选择时，才写 bounded 或 yolo。

运行时的输入可以写成：

检查当前分支相对 main 的文档改动，只报告用户可见风险和需要补充验证的点，不修改文件。

看运行结果

运行启动后，Workflow 面板会显示 run 和每个节点状态。健康的运行通常会出现这些信号：

review 节点进入运行状态，并打开一个托管 worker 会话；
review 完成后产生结构化 handoff；
summarize 自动启动，不需要你手动派发；
所有节点成功后 run 进入 succeeded；
终态后可以用 stop_sessions 或 UI 的退出入口关闭本次 run 创建的 worker 会话。

加一个并行分支

需要并行审查时，在第一个 Stage 再加一个节点，例如 security_review。第二个 Stage 的汇总节点会依赖第一 Stage 的所有节点，可以使用：

请合并所有直接上游的发现：

{{upstream_summaries}}

{{upstream_summaries}} 会把直接上游摘要合并成适合人读的文本。需要读取某个节点的结构化字段时，使用 {{upstream.<node_id>.<field>}}。

添加人工批准

如果某个节点会执行部署、删除、发布、外部通知等不可逆动作，把它的 requires_approval 打开。运行到这个节点时，状态会停在 waiting_approval，直到你在 UI 或通过 pipeline_control 批准。

常见问题

下游没有拿到上游字段

确认下游节点的 depends_on 直接包含该上游节点。Workflow 只渲染直接依赖的上游变量。

节点完成后被要求重试 handoff

说明 worker 汇报的 JSON 不符合 output_schema。让节点返回一个根对象，并补齐 required 字段。

草稿不能运行

草稿用于编辑和主脑协作。发布后才会出现在可运行路径中。

Extension Workflow 不能直接改

扩展包贡献的 Workflow 通常是 locked。先复制一份用户副本，再编辑。