如何在 Archon 工作流中用 $nodeId.output 引用上游节点的输出【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon当你用 Archon 编写多节点 YAML 工作流时最常见的诉求是让下游节点直接使用上游节点跑出来的结果而不是靠人或文件在中转。Archon 的 DAG 工作流提供两种引用形式——$nodeId.output上游节点的完整输出字符串和$nodeId.output.field从结构化 JSON 输出中取某个字段在节点 prompt、bash:脚本、when:条件等位置都会在执行前被替换成真实值。本文给出编写、验证和排错的完整路径先声明节点依赖再在下游引用输出用archon validate和--dry-run --stubs在不消耗 AI 调用的前提下确认替换确实生效最后才真实运行。两种引用形式与生效条件节点输出引用只在DAG 工作流中可用nodes:格式旧的顺序steps:格式已被移除且有一个硬性前提被引用的节点必须出现在消费节点的depends_on中。两种形式的语义来源variables.md模式解析为限制$nodeId.output被引用节点的完整输出字符串该节点必须是depends_on声明的依赖$nodeId.output.field节点输出 JSON 对象中的某个字段要求输出是 JSON 对象上游声明output_format时字段名校验更严格.field引用的失败规则要记住上游输出不是JSON 对象时.field引用直接使消费节点失败与上游是否声明output_format无关声明了output_format后引用未声明的字段会以命名错误使消费节点失败拼写错误不再静默变成空串声明了但模型省略的可选字段解析为对无 schema 的bash:/script:节点.field引用要求 stdout 是包含该 key 的 JSON否则消费节点失败——要么输出所有你引用的 key要么用整文本$node.output。替换顺序是固定的先替换工作流变量$WORKFLOW_ID、$ARGUMENTS、$ARTIFACTS_DIR等再替换上下文变量$CONTEXT及其别名最后才是节点输出引用。所以引用名本身不会被上游输出里的$文本二次污染。引用可用的位置工作流节点含prompt:、systemPrompt:、agents.*.prompt/description和when:条件中都可以用$nodeId.output直接调用单个 command 文件时不可用command 文件是执行体没有 DAG 上下文。编写一个引用上游输出的工作流工作流文件放在工作目录下的.archon/workflows/详见 Authoring Workflows。下面这个例子覆盖三个要点上游用output_format声明结构化输出、下游在 prompt 中引用字段与整文本、用when:做分支。id是引用的钥匙——它同时用于depends_on、when:和$id.output替换name: classify-and-fix description: Classify issue type, then run the appropriate fix path nodes: - id: classify command: classify-issue output_format: type: object properties: type: type: string enum: [BUG, FEATURE] required: [type] - id: investigate command: investigate-bug depends_on: [classify] when: $classify.output.type BUG prompt_extra: The issue was classified as: $classify.output.type Full classification: $classify.output Users original request: $USER_MESSAGE - id: plan command: plan-feature depends_on: [classify] when: $classify.output.type FEATURE - id: implement command: implement-changes depends_on: [investigate, plan] trigger_rule: none_failed_min_one_success要点说明output_format不是分支的辅助而是任何上游节点声明交给下游的值长什么样的方式。声明了 schema 却返回不合法输出的节点会失败而不是带着 prose 继续跑。when:中可以做字符串比较/!、数值比较///两侧都必须能解析为数字否则 fail-closed 跳过节点以及/||组合。不支持括号。注意一条文档明确列为陷阱的规则不能把没有output_format的 AI 节点prompt:/command:的完整输出与字面量做when:比较——模型输出This is a BUG.逐字节比较必为 false节点被静默跳过。要分支就给上游声明output_format并引用标量字段如$classify.output.type。bash:/script:节点的 stdout 是作者可控的整文本比较when: $check.output true仍然合法。在bash:与script:中引用引号规则这是引用最容易翻车的地方来源variables.md 与 authoring-workflows.mdbash:脚本中的$nodeId.output会被 Archon自动加 shell 引号小输出单引号内联超过 32 KB 时写入引擎管理的$ARTIFACTS_DIR/.archon/node-output-spills/node[.field].nodeoutput文件并替换为$(cat path)。因此规则是无条件不写双引号# WRONG — 小输出时注入的是单引号值status 变成 ok status$emit.output.status [ $status ok ] # → 恒为 false # CORRECT — 不加引号让 Archon 的引号就是引号 status$emit.output.status [ $status ok ] # → true数值和布尔字段是裸注入无引号双引号对它们碰巧能用这会让 bug 时好时坏、很难排查。统一写成var$node.output.field。script:节点不做shell 引号——原始值按原样嵌入。把替换值当不可信输入用语言特性解析如JSON.parse不要拼进 shell 语法。用户可控变量$ARGUMENTS、$USER_MESSAGE、$CONTEXT等与$nodeId.output走不同通道它们以环境变量ARGUMENTS、CONTEXT…投递给bash:/script:子进程绝不作为文本拼接进可执行代码。bash:里读$ARGUMENTSscript:里读process.env.ARGUMENTSbun或os.environ[ARGUMENTS]uv/python。具名 command / script 文件不被内联替换command:文件和具名script:文件对引擎是不透明的写在其内部的$producer.output.x会保持字面文本。给这类节点传上游值要用with:按名字绑定——command 文件通过$INPUTS.name读script 通过INPUTS_UPPER_SNAKE环境变量读nodes: - id: validate prompt: Run validation and report the verdict. output_format: type: object properties: green: { type: boolean } required: [green] - id: record script: record-verdict # 具名脚本 — 内部读 process.env.INPUTS_GREEN runtime: bun depends_on: [validate] with: green: $validate.output.green绑定值的解析规则整个$node.output[.field]引用传递逻辑值布尔保持布尔、对象保持对象非字符串字面量按原样传递其他字符串按input:的方式做文本模板替换。loader 保证被绑定的 producer 必须可达于depends_on绑定永远不会和 producer 竞态。互斥分支用trigger_rule: all_done汇合后producer 可能整体被跳过此时when:和内联$node.output引用都会让节点失败唯一出路是在with:中声明{ from, if_skipped }跳过时取if_skipped数据值没有if_skipped的跳过 producer 会以指明绑定、producer 和修法的方式使节点失败。验证先校验、再 dry-run最后真实运行真实运行前有两层无需 AI 调用即可执行的检查来源cli.md。1. 静态校验——在引用有拼写错误、依赖缺失等结构性问题时提前暴露archon validate workflows my-workflow # 校验单个工作流 archon validate workflows my-workflow --json # 机器可读输出2. 确定性 dry-run——用 stub 值模拟 DAG 路由、when:、严格字段和变量替换不创建 run、worktree、session 或 provider 请求。为工作流里会产出的节点写好 stub对象 stub 会作为结构化输出保留下游$classify.output.severity之类的引用表现得像真实 producercat stubs.yaml YAML classify: issue_type: bug severity: high investigate: Root cause: stale cache YAML # 在目标仓库目录下执行--stubs 的相对路径从 --cwd 解析 archon workflow run my-workflow \ --dry-run --stubs stubs.yaml Issue #2100 # 输出单个完整 JSON 文档可在 CI 中管道处理 archon workflow run my-workflow \ --dry-run --stubs stubs.yaml --json | jq .trace, .outcome判断标准看 trace有序 trace 会把每个节点记为completed/stubbed/skipped/failed/paused并带原因、resolved text替换后的实际文本和安全输出。确认下游节点的 resolved text 中出现了上游 stub 值、分支走向与when:预期一致替换链路即验证通过。dry-run 中无效的严格$node.output.field引用会使消费节点失败行为与真实运行完全一致——这正是它作为引用检查手段的价值。补充边界默认情况下 dry-run不执行任何bash:/script:节点可达而未 stub 的节点会失败并出现在missingStubs--exec-code才允许本地执行受信脚本是唯一可能有代码级副作用的 dry-run 模式执行的节点拿到~/.archon/temp/下的临时$ARTIFACTS_DIR/$STATE_DIR仓库内不写入任何内容。节点多时可先用--stubs-init fixtures/xxx.yaml生成脚手架再编辑关键值。3. 真实运行后核对——前台启动并留 run id随后archon workflow run my-workflow your trigger message archon workflow logs run-id # 打印该 run 的 transcript archon workflow get run-id --verbose # 每节点摘要transcript~/.archon/workspaces/project/logs/run-id.jsonl中每个子进程一条exec_output记录stdout_tail/stderr_tail保留各流最后 2000 字符用于核对 bash/script 节点实际打印了什么。失败语义与限制以下行为文档均有明确定义排错时对照引用一个失败 producer 的输出字段或整文本会使消费节点失败而不是拼入残留输出——即使你用trigger_rule: all_done让它跑到了失败点之后。prompt /systemPrompt:/agents.*.prompt中残留的未解析$nodeId.outputdangling reference是load error。运行期间下游插值和when:看到的是完整输出但成功的 bash 事件只保留 32 KiB UTF-8 的审计预览跨进程边界的 resume 重建的是该预览而非全量。需要大结果跨越重启时写入$ARTIFACTS_DIR下并在结果里返回指针{ type: archon_artifact, run_id: $WORKFLOW_ID, path: ... }run_id必须是本 runpath相对本 run 的 artifacts 目录而不是依赖事件预览。include:组合块只能读$includeId.output块的 primary sink /returns:节点读不到块内单个节点的输出include 内部的$id.output引用在加载期自动重写为带命名空间的 id。loop_group体内引用上一轮输出用$LOOP_PREV.nodeId.output[.field]第 1 轮为空串when:中是类型化条件引用而非文本替换。完成上面的编写—校验—dry-run—真实运行链路后如果你的引用替换在 trace 的 resolved text 中与预期不符优先检查三件事producer 是否在消费节点的depends_on里、.field是否声明在上游output_format的 schema 中、bash:节点里是否误加了两处双引号。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何在 Archon 工作流中用 $nodeId.output 引用上游节点的输出？
如何在 Archon 工作流中用 $nodeId.output 引用上游节点的输出【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon当你用 Archon 编写多节点 YAML 工作流时最常见的诉求是让下游节点直接使用上游节点跑出来的结果而不是靠人或文件在中转。Archon 的 DAG 工作流提供两种引用形式——$nodeId.output上游节点的完整输出字符串和$nodeId.output.field从结构化 JSON 输出中取某个字段在节点 prompt、bash:脚本、when:条件等位置都会在执行前被替换成真实值。本文给出编写、验证和排错的完整路径先声明节点依赖再在下游引用输出用archon validate和--dry-run --stubs在不消耗 AI 调用的前提下确认替换确实生效最后才真实运行。两种引用形式与生效条件节点输出引用只在DAG 工作流中可用nodes:格式旧的顺序steps:格式已被移除且有一个硬性前提被引用的节点必须出现在消费节点的depends_on中。两种形式的语义来源variables.md模式解析为限制$nodeId.output被引用节点的完整输出字符串该节点必须是depends_on声明的依赖$nodeId.output.field节点输出 JSON 对象中的某个字段要求输出是 JSON 对象上游声明output_format时字段名校验更严格.field引用的失败规则要记住上游输出不是JSON 对象时.field引用直接使消费节点失败与上游是否声明output_format无关声明了output_format后引用未声明的字段会以命名错误使消费节点失败拼写错误不再静默变成空串声明了但模型省略的可选字段解析为对无 schema 的bash:/script:节点.field引用要求 stdout 是包含该 key 的 JSON否则消费节点失败——要么输出所有你引用的 key要么用整文本$node.output。替换顺序是固定的先替换工作流变量$WORKFLOW_ID、$ARGUMENTS、$ARTIFACTS_DIR等再替换上下文变量$CONTEXT及其别名最后才是节点输出引用。所以引用名本身不会被上游输出里的$文本二次污染。引用可用的位置工作流节点含prompt:、systemPrompt:、agents.*.prompt/description和when:条件中都可以用$nodeId.output直接调用单个 command 文件时不可用command 文件是执行体没有 DAG 上下文。编写一个引用上游输出的工作流工作流文件放在工作目录下的.archon/workflows/详见 Authoring Workflows。下面这个例子覆盖三个要点上游用output_format声明结构化输出、下游在 prompt 中引用字段与整文本、用when:做分支。id是引用的钥匙——它同时用于depends_on、when:和$id.output替换name: classify-and-fix description: Classify issue type, then run the appropriate fix path nodes: - id: classify command: classify-issue output_format: type: object properties: type: type: string enum: [BUG, FEATURE] required: [type] - id: investigate command: investigate-bug depends_on: [classify] when: $classify.output.type BUG prompt_extra: The issue was classified as: $classify.output.type Full classification: $classify.output Users original request: $USER_MESSAGE - id: plan command: plan-feature depends_on: [classify] when: $classify.output.type FEATURE - id: implement command: implement-changes depends_on: [investigate, plan] trigger_rule: none_failed_min_one_success要点说明output_format不是分支的辅助而是任何上游节点声明交给下游的值长什么样的方式。声明了 schema 却返回不合法输出的节点会失败而不是带着 prose 继续跑。when:中可以做字符串比较/!、数值比较///两侧都必须能解析为数字否则 fail-closed 跳过节点以及/||组合。不支持括号。注意一条文档明确列为陷阱的规则不能把没有output_format的 AI 节点prompt:/command:的完整输出与字面量做when:比较——模型输出This is a BUG.逐字节比较必为 false节点被静默跳过。要分支就给上游声明output_format并引用标量字段如$classify.output.type。bash:/script:节点的 stdout 是作者可控的整文本比较when: $check.output true仍然合法。在bash:与script:中引用引号规则这是引用最容易翻车的地方来源variables.md 与 authoring-workflows.mdbash:脚本中的$nodeId.output会被 Archon自动加 shell 引号小输出单引号内联超过 32 KB 时写入引擎管理的$ARTIFACTS_DIR/.archon/node-output-spills/node[.field].nodeoutput文件并替换为$(cat path)。因此规则是无条件不写双引号# WRONG — 小输出时注入的是单引号值status 变成 ok status$emit.output.status [ $status ok ] # → 恒为 false # CORRECT — 不加引号让 Archon 的引号就是引号 status$emit.output.status [ $status ok ] # → true数值和布尔字段是裸注入无引号双引号对它们碰巧能用这会让 bug 时好时坏、很难排查。统一写成var$node.output.field。script:节点不做shell 引号——原始值按原样嵌入。把替换值当不可信输入用语言特性解析如JSON.parse不要拼进 shell 语法。用户可控变量$ARGUMENTS、$USER_MESSAGE、$CONTEXT等与$nodeId.output走不同通道它们以环境变量ARGUMENTS、CONTEXT…投递给bash:/script:子进程绝不作为文本拼接进可执行代码。bash:里读$ARGUMENTSscript:里读process.env.ARGUMENTSbun或os.environ[ARGUMENTS]uv/python。具名 command / script 文件不被内联替换command:文件和具名script:文件对引擎是不透明的写在其内部的$producer.output.x会保持字面文本。给这类节点传上游值要用with:按名字绑定——command 文件通过$INPUTS.name读script 通过INPUTS_UPPER_SNAKE环境变量读nodes: - id: validate prompt: Run validation and report the verdict. output_format: type: object properties: green: { type: boolean } required: [green] - id: record script: record-verdict # 具名脚本 — 内部读 process.env.INPUTS_GREEN runtime: bun depends_on: [validate] with: green: $validate.output.green绑定值的解析规则整个$node.output[.field]引用传递逻辑值布尔保持布尔、对象保持对象非字符串字面量按原样传递其他字符串按input:的方式做文本模板替换。loader 保证被绑定的 producer 必须可达于depends_on绑定永远不会和 producer 竞态。互斥分支用trigger_rule: all_done汇合后producer 可能整体被跳过此时when:和内联$node.output引用都会让节点失败唯一出路是在with:中声明{ from, if_skipped }跳过时取if_skipped数据值没有if_skipped的跳过 producer 会以指明绑定、producer 和修法的方式使节点失败。验证先校验、再 dry-run最后真实运行真实运行前有两层无需 AI 调用即可执行的检查来源cli.md。1. 静态校验——在引用有拼写错误、依赖缺失等结构性问题时提前暴露archon validate workflows my-workflow # 校验单个工作流 archon validate workflows my-workflow --json # 机器可读输出2. 确定性 dry-run——用 stub 值模拟 DAG 路由、when:、严格字段和变量替换不创建 run、worktree、session 或 provider 请求。为工作流里会产出的节点写好 stub对象 stub 会作为结构化输出保留下游$classify.output.severity之类的引用表现得像真实 producercat stubs.yaml YAML classify: issue_type: bug severity: high investigate: Root cause: stale cache YAML # 在目标仓库目录下执行--stubs 的相对路径从 --cwd 解析 archon workflow run my-workflow \ --dry-run --stubs stubs.yaml Issue #2100 # 输出单个完整 JSON 文档可在 CI 中管道处理 archon workflow run my-workflow \ --dry-run --stubs stubs.yaml --json | jq .trace, .outcome判断标准看 trace有序 trace 会把每个节点记为completed/stubbed/skipped/failed/paused并带原因、resolved text替换后的实际文本和安全输出。确认下游节点的 resolved text 中出现了上游 stub 值、分支走向与when:预期一致替换链路即验证通过。dry-run 中无效的严格$node.output.field引用会使消费节点失败行为与真实运行完全一致——这正是它作为引用检查手段的价值。补充边界默认情况下 dry-run不执行任何bash:/script:节点可达而未 stub 的节点会失败并出现在missingStubs--exec-code才允许本地执行受信脚本是唯一可能有代码级副作用的 dry-run 模式执行的节点拿到~/.archon/temp/下的临时$ARTIFACTS_DIR/$STATE_DIR仓库内不写入任何内容。节点多时可先用--stubs-init fixtures/xxx.yaml生成脚手架再编辑关键值。3. 真实运行后核对——前台启动并留 run id随后archon workflow run my-workflow your trigger message archon workflow logs run-id # 打印该 run 的 transcript archon workflow get run-id --verbose # 每节点摘要transcript~/.archon/workspaces/project/logs/run-id.jsonl中每个子进程一条exec_output记录stdout_tail/stderr_tail保留各流最后 2000 字符用于核对 bash/script 节点实际打印了什么。失败语义与限制以下行为文档均有明确定义排错时对照引用一个失败 producer 的输出字段或整文本会使消费节点失败而不是拼入残留输出——即使你用trigger_rule: all_done让它跑到了失败点之后。prompt /systemPrompt:/agents.*.prompt中残留的未解析$nodeId.outputdangling reference是load error。运行期间下游插值和when:看到的是完整输出但成功的 bash 事件只保留 32 KiB UTF-8 的审计预览跨进程边界的 resume 重建的是该预览而非全量。需要大结果跨越重启时写入$ARTIFACTS_DIR下并在结果里返回指针{ type: archon_artifact, run_id: $WORKFLOW_ID, path: ... }run_id必须是本 runpath相对本 run 的 artifacts 目录而不是依赖事件预览。include:组合块只能读$includeId.output块的 primary sink /returns:节点读不到块内单个节点的输出include 内部的$id.output引用在加载期自动重写为带命名空间的 id。loop_group体内引用上一轮输出用$LOOP_PREV.nodeId.output[.field]第 1 轮为空串when:中是类型化条件引用而非文本替换。完成上面的编写—校验—dry-run—真实运行链路后如果你的引用替换在 trace 的 resolved text 中与预期不符优先检查三件事producer 是否在消费节点的depends_on里、.field是否声明在上游output_format的 schema 中、bash:节点里是否误加了两处双引号。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
