写在前面

适合谁看： 测试开发、后端开发、网站工程师、正在做 AI Agent 工具工程化的人。

主要问题： 复杂测试造数流程，如何从脚本自动化升级成配置驱动的编排程序？

主要 YAML 不是简单参数表，而是一个小型流程 DSL；不过，Action 数量要少，但表达力要够。主要种 Action 加 种 Action，已经能覆盖大多数公司造数链路。

一句话答案： 把稳定能力抽成 Action。把业务差异放进 YAML，把复杂请求体交给模板，把执行通道留给 Dify。

系列定位： 这是执行骨架篇。第 篇讲多模态如何把截图变成参数；本篇讲这些参数进入引擎后如何被 YAML 和 Action 稳定编排。

关键边界： 多模态不是第 种 Action，它发生在 Action 之前；Action 只消费已经结构化、已校验的参数。

一、为什么需要一个编排引擎

在做造数 Skill 之前，最直接的方案是写脚本。

再看痛点1，脚本复制成本高。一旦业务细节变更，所有脚本都需要手动维护，导致维护成本暴增。

痛点2的观点是。每条脚本都包含相同的 HTTP/SQL/等待/重试逻辑，只是少量业务差异，使得错误难以定位和统一管理。

案例拆解

• check_materialcreate_requestquery_request_noapprove_requestquery_contractcreate_orderapprove_orderquery_final_no
• 从痛点3来看。同一套动作重复出现，多次复制粘贴导致代码膨胀且易错。

二、整体设计：YAML 是流程 DSL。不是参数表

痛点4这方面，传统配置文件只能存储参数，却无法描述多步骤、多分支的业务流程，导致“流水线”与“业务逻辑”混杂。

YAML 示例

name: sample-order-flow
再看inputs，orderType:
required: true
supplierCode:
required: true
materials:
required: true
type这方面，list
说到steps，- id: build_request
action的观点是，template
template: templates/order-request.json.j2
context:
orderType: "{{ inputs.orderType }}"
supplierCode: "{{ inputs.supplierCode }}"
materials: "{{ inputs.materials }}"
- id: create_request
说到action。http_call
再看params，url: "{{ config.api_base }}/purchase/request"
说到method，POST
从body来看，"{{ steps.build_request.output }}"
extract:
至于code，"$.body.code"
request_no: "$.body.data.requestNo"
- id: check_result
action的观点是，condition
if的观点是，"{{ steps.create_request.extracted.code }} == ''"
n: query_request
再看else，END_CREATE_FAIL

说到痛点5，缺乏统一的数据提取与跳转机制，导致不同步骤间耦合度高，调试时需频繁查看代码逻辑。

三、种 Action：主要种，种

说到痛点6。过多自定义 Action 会让配置学习曲线陡峭，同时降低复用性与可维护性。

四、Action 逐个拆开看

. http_call: 业务接口统一入口

• 关心 URL / Method / Header / Body / 提取规则，只聚焦网络层面不涉及业务细节。

. sql_query: 查询中间态和结果

• 保证查询条件绑定当前上下文，并使用 LIMIT 防止误检；结合 wait/retry 判断同步/异步状态。

. template : 把复杂 JSON 请求体治理出来

• 使用 Jinja 模板实现多物料循环及空字段裁剪，让请求体不再硬编码到 Python 或低代码节点中。