构建订单与退款交付验收助手
本实战将在智能体开发服务平台(AgentWorks)中构建一个面向电商数据接收方的交付验收助手。合作方每天交付订单或退款批次后,使用者只需说明交付 ID;助手会按约定生成本次报告的名称,先从已批准的校验器清单中准备一份可核对的计划,再在人工允许后运行按固定规则编写的校验程序,解释 PASS 或 FAIL 结果,并把 JSON 报告写入对象存储。
准备条件已经满足时,完成本实战通常需要 75–120 分钟。首次配置对象存储挂载或沙箱时可能需要更长时间。
重要
本实战依赖外部对象存储
本实战不能只在 AgentWorks 内完成。开始前,需要准备由组织批准的阿里云 OSS 或火山引擎 TOS 非生产测试存储桶、最小权限访问凭证,以及能够从存储端下载并核对报告的方式。
AgentWorks 通过沙箱挂载访问这些目录;对象存储账号、服务可用性、费用、数据保留和访问审计仍由相应服务及你的组织管理。没有获批测试范围时,请勿继续。AccessKey 和 Secret Access Key 只填写到 AgentWorks 的凭证管理中,不要写入文件、命令、提示词、截图或验收记录。
本实战将帮助你理解
- 如何把一句验收请求转换成可核对的执行计划,并从已批准的校验器清单中精确选择订单或退款校验规则。
- 为什么计划和实际校验都要经过人工审批,以及校验程序、助手和审批者分别决定什么。
- 如何区分数据校验的 PASS 或 FAIL 与工具执行失败,并从对象存储端确认报告已经持久写入。
理解 AgentWorks 如何完成数据交付验收
可以把“数据交付验收”理解为数据进入业务系统前的收货检验。合作方交付每日订单或退款文件,接收方用自己批准的规则检查文件是否齐全、格式是否正确、内容是否与 manifest(批次清单)一致,再决定是否导入、退回或等待重新提交。
本实战让同一个助手处理两类交付。使用者不需要记住校验脚本和策略文件的位置;助手先调用只读的 plan 命令,由确定性脚本根据 manifest 中的交付类型和版本精确匹配已批准的校验器清单,再把准备使用的校验器、策略、哈希和报告路径展示出来。使用者确认后,助手才请求实际运行。
validator-catalog.json 和 accept_delivery.py 是本实战提供的接收方工件,不是 AgentWorks 的内置校验器管理能力。用于实际业务时,它们应由数据接收方维护和审核;AgentWorks 在这里提供沙箱挂载、工具调用审批、执行记录和结果解释。
只运行一个固定校验脚本当然更简单。本实战使用小型合成数据,是为了展示交付类型和规则逐渐增多后仍然适用的处理方式:使用者通过同一个入口发起验收,执行前可以看到匹配结果,程序只接受已经登记并固定哈希的校验器,最后留下便于复核的结构化报告。增加这些步骤不是为了让模型判断数据,而是为了约束它可以运行什么,并让人员看清实际运行内容。
下图展示一次验收中的职责和数据流。两个黄色审批节点分别表示计划命令和实际运行命令都要经过人工审批;右侧的导入、退回或重新提交决定发生在 AgentWorks 之外。
图中有四条需要保持的边界:
- 计划只说明准备怎样验收。
plan读取 manifest 和已批准的校验器清单,但不运行校验器,也不生成 PASS 或 FAIL 报告。 - 提示词和校验器清单本身不是执行约束。 实际运行时,
accept_delivery.py会重新核对清单匹配、文件路径、哈希、validator_id和plan_sha256;不一致时安全停止。 - 确定性校验器决定 PASS 或 FAIL。 这里的校验器是按固定规则运行的 Python 程序;助手解释结构化结果,但不会代替订单或退款规则判断数据是否合格。
- 后续业务动作仍在 AgentWorks 之外。 本实战不会自动导入数据、退回批次或通知交付方。
准备样例和存储
本阶段先确认 AgentWorks 和外部对象存储满足测试条件,再上传固定的订单和退款样例。
确认准备条件
开始前确认:
- 模型凭证和模型能够正常回复。尚未验证时,先完成创建第一个智能体并完成基础验证。
- 已获得创建对象存储凭证、沙箱实例、智能体模板和智能体实例,以及查看 Trace 和 沙箱运行记录的权限。
- 租户已有包含 Python 3 和命令工具的沙箱规格与环境。
- 存储所有者已经批准一个不含生产数据、个人信息、密钥或客户资料的阿里云 OSS 或火山引擎 TOS 测试范围。
- 平台管理员已经说明测试沙箱的运行超时、空闲回收和计费方式,并确认完成后由谁处理沙箱、凭证和外部测试对象。
本实战包含四种操作角色:存储所有者批准对象存储范围和凭证范围,AgentWorks 构建者创建沙箱与智能体,测试人员发起验收并核对结果,审批者在每次工具运行前核对命令。可以由同一人承担多个角色,但不能省略相应检查。
准备对象存储目录和样例
本阶段由存储所有者或获准操作测试存储的人员完成。AgentWorks 构建者记录获批的存储桶、子目录和凭证范围,供下一阶段配置挂载。
在测试存储桶(Bucket)中准备三个互不重叠的子目录:
| 用途 | Bucket 子目录示例 | 沙箱目录 | 权限 |
|---|---|---|---|
| 已批准的校验器清单、策略和程序 | agentworks-recipes/data-delivery/team-a/rules | /delivery-rules | 只读 |
| 合作方交付的 manifest 和数据文件 | agentworks-recipes/data-delivery/team-a/input | /delivery-input | 只读 |
| 验收报告 | agentworks-recipes/data-delivery/team-a/reports | /delivery-reports | 读写 |
将 team-a 换成本次测试专用的短名称。对象存储凭证应允许三个目录均可列出和读取,只允许在报告目录创建测试对象,不授予删除权限。由于同一沙箱表单中的挂载共用一个凭证,请通过对象存储权限限制各子目录的写入范围,并为每次运行使用新的报告对象名。
下载订单与退款交付验收样例包和样例清单。
计算 ZIP 的 SHA-256,与样例清单中的
bundle.sha256比较;一致后再解压。保持相对目录不变,把以下内容上传到对应的对象存储子目录:
rules/accept_delivery.pyrules/validator-catalog.jsonrules/validators/validate_csv.pyrules/policies/retail-orders-v1.jsonrules/policies/retail-refunds-v1.jsoninput/RETAIL-ORDERS-PASS-001/input/RETAIL-REFUNDS-FAIL-001/input/RETAIL-INVENTORY-UNSUPPORTED-001/(仅用于可选验证)
在对象存储端确认上述对象存在。后面的
plan命令会读取 manifest,并核对清单匹配、相关文件路径和 SHA-256;任一检查失败时,请修正上传或挂载,不要改用未经批准的文件。确认报告目录中没有
RETAIL-ORDERS-PASS-001-run-001.json和RETAIL-REFUNDS-FAIL-001-run-001.json。已有同名对象时,请为本次运行使用新的后缀。
注意
本实战中的验收规则
订单和退款批次使用同一个确定性 CSV 校验程序,但分别匹配 retail-orders-v1 和 retail-refunds-v1,并加载各自的策略文件。真实流程还需要验证交付方身份和业务数据真实性:请从受信系统取得预期值,或者使用经过认证或签名的 manifest。
创建专用沙箱
本阶段由 AgentWorks 构建者在 AgentWorks 管理控制台完成。以下入口仅在租户已启用沙箱能力时可用。按钮会在新标签页打开控制台。若先进入登录页,控制台目前不会在登录后自动返回目标页面;请登录后返回本文,再次选择按钮。
本实战直接创建一个专用沙箱实例,以便先确认 Python 环境、三个挂载和最小权限凭证,再把同一个沙箱关联到测试智能体。只有需要让多个智能体实例根据相同配置分别创建沙箱时,才需要改用沙箱模板。
按准备对象存储挂载创建名为
recipe-data-delivery-storage-v2的对象存储凭证。按创建沙箱实例确认配置要求,再打开新建沙箱实例页面,创建名为
recipe-data-delivery-sandbox-v2的沙箱实例。选择管理员提供的测试规格和包含 Python 3 的环境。在 存储挂载 中开启挂载,选择
recipe-data-delivery-storage-v2,再选择 新增挂载点 两次。配置三个挂载点:
- 将规则目录挂载到
/delivery-rules,选择 只读。 - 将输入目录挂载到
/delivery-input,选择 只读。 - 将报告目录挂载到
/delivery-reports,选择 读写。
- 将规则目录挂载到
确认三个 本地目录互不重叠,再选择 创建沙箱实例。校验失败时,修正凭证、Bucket、子目录或本地目录后重新提交,不要扩大凭证权限。
不要把这个测试沙箱关联到其他智能体。对象存储挂载是否正确,将由后面的只读计划和存储端报告核验共同确认。
创建订单与退款交付验收助手
本阶段由 AgentWorks 构建者在 AgentWorks 管理控制台完成。先创建关联专用沙箱的智能体模板,再从该模板创建一个测试智能体实例。
创建智能体模板
打开创建智能体模板页面。
也可以打开 智能体模板,再选择 创建智能体模板。
将 模板名称设为
recipe-data-delivery-assistant-v2,并选择已经验证的 模型凭证和模型。在 系统提示词 中输入:
language-text你是订单与退款交付验收助手。 用户提供 delivery-id 后,将本次教程的 report-key 设为 <delivery-id>-run-001。若用户明确给出另一个唯一 report-key,则使用该值。 然后先且只运行: python3 /delivery-rules/accept_delivery.py plan \ --delivery-id <delivery-id> \ --report-key <report-key> 概括 phase、status、delivery_id、delivery_type、schema_version、selected_validator_id、 dispatcher_sha256、provenance 中的文件路径和 SHA-256、plan_basis、proposed_run、proposed_run_argv、 report_object_name、mount_output_path 和 plan_sha256,然后等待用户明确要求继续。 计划失败或没有精确匹配时, 停止并说明原因,不要猜测校验器或策略。 用户确认后,只运行: python3 /delivery-rules/accept_delivery.py run \ --delivery-id <delivery-id> \ --report-key <report-key> \ --validator-id <plan 的 proposed_run.validator_id> \ --plan-sha256 <plan 返回的 plan_sha256> 不直接运行其他脚本,不改写目录、路径、哈希或 validator_id,不执行交付目录中的文件, 不删除或覆盖对象,不访问网络,也不执行导入、退回、通知或其他下游操作。 运行完成后,概括结构化结果中的 delivery_id、status、failed_checks、 failed_check_count、validator_id、delivery_type、schema_version、dispatcher_sha256、 plan_sha256、provenance_sha256、 report_object_name、mount_output_path 和 next_action。只有确定性校验器的结构化结果可以表示 PASS 或 FAIL; 工具、挂载或报告写入失败时,说明无法确认验收结果。 请在当前调用中完成,不要委派其他任务。关闭默认开启的 启用文件系统。本实战只使用专用沙箱,关闭另一个文件工作区可以避免混淆输入和报告位置。
在 插件配置 中添加 沙箱 - 实例,选择
recipe-data-delivery-sandbox-v2。在 工具权限 中,明确选择并保存 默认行为为 审批。不要添加自动允许规则。
重要
本实战保留两次可见审批
plan是只读操作,但仍会调用命令工具,因此第一次审批用于确认它只读取固定目录并生成计划。第二次审批用于确认实际运行仍使用计划中的delivery_id、report_key、validator_id和plan_sha256。任一次工具、命令、参数或路径不符合本实战时,请选择拒绝。工具审批不会扩大对象存储凭证的权限,参见工具审批规则能代替工具服务的访问授权吗?。
选择 创建智能体模板,确认模板已经保存。
创建智能体实例
打开创建智能体实例页面。
选择刚创建的智能体模板,将智能体实例命名为
recipe-data-delivery-assistant-test-v2,再完成创建。打开测试实例的 Playground,等待连接状态显示 已连接。
为订单批次生成只读验收计划
测试人员在刚创建的智能体实例中打开 Playground 新会话,发送:
请验收批次 RETAIL-ORDERS-PASS-001。命令工具暂停后,审批者确认实际调用为:
python3 /delivery-rules/accept_delivery.py plan \
--delivery-id RETAIL-ORDERS-PASS-001 \
--report-key RETAIL-ORDERS-PASS-001-run-001确认没有其他命令、重定向、网络访问或后台执行,再选择允许。计划结果应表明已经找到精确匹配,并列出以下结构化信息:
phase=plan、status=READY、delivery_id、delivery_type和schema_versionselected_validator_id=retail-orders-v1provenance中的accept_delivery.py、manifest、数据文件、校验器清单、校验器和策略路径及其 SHA-256plan_basis、proposed_run、proposed_run_argv、报告对象名、挂载内报告路径和plan_sha256
plan 会读取 manifest,并核对已批准校验器清单中的匹配、路径和文件哈希。它不会运行 CSV 校验器或写入报告。计划失败、没有精确匹配或任一字段与本实战不一致时,请停止并修正上传或挂载;不要让助手改用其他路径。
plan_sha256 代表这次计划所依据的 accept_delivery.py、manifest、数据文件、校验器清单、校验器、策略和输出参数。实际运行时,accept_delivery.py 会重新计算它;两次审批之间任一相关内容发生变化时,运行会安全停止。
运行订单 PASS 和退款 FAIL 验收
测试人员在 Playground 中发起验收,审批者核对并处理实际运行命令,存储所有者或获准操作人员从对象存储端下载报告。每次验收都使用新的报告键。
危险
从对象存储下载并核对报告
报告写入后,请在对象存储控制台或组织批准的客户端中按完整对象路径下载,并核对内容和 SHA-256。同一沙箱中的读取结果、Trace 或沙箱运行记录可以定位调用,但不能代替存储端核验。
找不到报告、无法读取或哈希不一致时,请把本次写入视为失败,保留沙箱、Trace、运行记录和现有测试对象。修正问题后使用替代测试沙箱或新的报告键重试,不要覆盖已有对象。
使用本页列出的报告键时,可以对照订单和退款报告的固定字段核对交付类型、校验器、状态、失败项、报告对象名和下一步代码。模型生成的解释可以改变措辞,这些结构化字段不应改变。如果为避免重名而更换报告键,报告对象名、挂载内路径和 plan_sha256 也会随之改变。
验收合格的订单批次
在已经显示订单计划的会话中发送:
language-text按刚才的计划继续验收。命令工具暂停后,审批者确认实际调用为:
language-bashpython3 /delivery-rules/accept_delivery.py run \ --delivery-id RETAIL-ORDERS-PASS-001 \ --report-key RETAIL-ORDERS-PASS-001-run-001 \ --validator-id retail-orders-v1 \ --plan-sha256 9c7156c6e7a79697dcd16da649453954ad6854934014d45589243fd79967dbf8validator_id和plan_sha256必须与计划完整一致。若实际调用仍有占位符、字段不同,或者包含其他命令、参数或路径,请拒绝,不要在审批窗口中代为修补。accept_delivery.py会重新计算计划哈希,并核对校验器清单、文件路径、文件哈希和校验器 ID,然后才调用确定性 CSV 校验器。确认结构化结果中的
status=PASS、failed_check_count=0,并包含delivery_id、delivery_type、schema_version、validator_id、dispatcher_sha256、plan_sha256、provenance_sha256、报告对象名、挂载内报告路径和next_action。provenance_sha256应分别列出accept_delivery.py、manifest、数据文件、校验器清单、校验器和策略的 SHA-256。按结果中的报告对象名从对象存储端下载 JSON 报告,记录 SHA-256,并确认报告内容与助手解释一致。输入目录中的 manifest 和订单文件不应发生变化。
在 Trace 和 沙箱运行记录中确认计划和实际运行是两次独立、经过审批的命令调用。
识别不合格的退款批次
打开另一个 Playground 新会话,发送:
language-text请验收批次 RETAIL-REFUNDS-FAIL-001。审批者确认
plan命令只包含该交付 ID 和报告键,再选择允许。计划应精确匹配selected_validator_id=retail-refunds-v1,并列出退款策略、共享 CSV 校验器及其 SHA-256。测试人员发送:
language-text按刚才的计划继续验收。命令工具暂停后,审批者确认实际调用为:
language-bashpython3 /delivery-rules/accept_delivery.py run \ --delivery-id RETAIL-REFUNDS-FAIL-001 \ --report-key RETAIL-REFUNDS-FAIL-001-run-001 \ --validator-id retail-refunds-v1 \ --plan-sha256 52eba8fede82b2e7767c9a232ae1d44b278995b7d2bd216e2ef1ccf6f237e6f3确认
validator_id和plan_sha256与退款计划完整一致。仍有占位符或任一字段不一致时,请拒绝,不要在审批窗口中代为修补。确认结构化结果中的
status=FAIL,failed_checks指出不受支持的reason_code,failed_check_count与失败项一致,报告保留计划中的plan_sha256,next_action建议修正后重新提交。助手可以解释失败原因,但不能把 FAIL 改成 PASS,也不能自行退回或修改批次。从对象存储端下载退款 FAIL 报告并记录 SHA-256。确认它没有覆盖订单 PASS 报告,输入文件也没有变化;Trace 和沙箱运行记录应指向本次计划和实际运行。
命令工具、Python、挂载、清单匹配或报告写入失败时,请先恢复运行环境,再使用新的报告键重新验收。只有确定性校验器返回的不合格结果才记为数据验收 FAIL。
完成结果:同一个助手调用接收方维护的计划脚本,由脚本从已批准的校验器清单中分别匹配订单和退款校验配置;对合格订单生成 PASS 报告,对包含不受支持 reason_code 的退款批次生成 FAIL 报告。两份报告使用不同对象名,并且都已从对象存储端下载、核对内容和 SHA-256。
完成可选验证
前面的订单 PASS 和退款 FAIL 已经构成完整教程。以下检查用于进一步理解安全停止和持久化边界,不影响本实战的完成结果。
验证没有清单匹配时安全停止
固定验收用例还包含清单中没有匹配项的 RETAIL-INVENTORY-UNSUPPORTED-001。在 Playground 新会话中发送:
请验收批次 RETAIL-INVENTORY-UNSUPPORTED-001。审批者确认调用的仍然只是固定 plan 命令,再选择允许。由于 manifest 中的交付类型和版本在已批准的校验器清单中没有精确匹配项,命令应返回 status=NOT_READY 和 reason_code=NO_APPROVED_VALIDATOR,proposed_run 应为空。助手不应提出其他校验器,报告目录中也不应出现对应对象。
这个结果不是数据验收 FAIL,因为确定性校验器尚未运行。它证明 accept_delivery.py 在无法选择已批准校验器时停止,而不是由模型猜测一个路径。
从新沙箱读回报告
主流程已经要求从对象存储端直接核对报告,不需要再创建沙箱。组织还要求独立验证新挂载时,请按验证对象存储挂载另建只读验证路径,读取一个已确认的 PASS 报告和一个 FAIL 报告,再把读取内容的 SHA-256 与存储端记录比较。不要放宽本实战助手只运行 plan 和 run 的限制。
需要更换仍然有效的凭证时,参见轮换对象存储凭证。
排查验收失败
从最早失败的步骤开始检查。挂载配置或运行环境状态仍不明确时,请新建替代测试沙箱并重新配置;可能已经写入报告时,请使用新的报告键。
| 现象 | 检查和恢复 |
|---|---|
| 沙箱创建或 Bucket 预检失败 | 核对存储类型、区域、Endpoint、Bucket、子目录、本地目录和凭证范围。修正配置后重新提交,不要扩大到 Bucket 全局权限。 |
plan 无法读取 manifest、目录或规则文件 | 保持规则和输入挂载只读,核对上传对象、相对目录、挂载路径和凭证读取范围。不要让助手寻找其他文件。 |
plan 返回 status=NOT_READY 和 reason_code=NO_APPROVED_VALIDATOR | 核对 manifest 中的交付类型和版本,以及已批准校验器清单中的对应项。不要通过修改 validator_id 绕过停止结果。 |
run 拒绝目录、路径、哈希或 validator_id | 返回最近一次计划重新核对字段。修正被更改的对象或重新生成计划,不要直接调用校验器。 |
| 命令工具或 Python 3 不可用 | 选择管理员已经准备并允许使用的环境,不要让模型安装未审核依赖或猜测其他工具名称。 |
| 报告目录不能写入,或者无法直接下载报告 | 把写入视为执行失败,保留现有测试资源和运行记录。修正配置后使用替代测试沙箱和新的报告键重试。 |
| 助手回答、报告、Trace 或运行记录不一致 | 以校验器结构化结果和对象存储端报告为准,先确认原调用是否已经写入报告,再决定是否重试。不要补写 PASS。 |
| 新沙箱读取的报告缺失或哈希不同 | 停止使用该挂载,记录完整对象路径并联系管理员。不要删除原沙箱或报告来重新测试。 |
调整为自己的交付规则
本实战用小型合成订单和退款 CSV 讲清完整流程。迁移到其他交付类型时,由数据接收方维护 manifest 约定、已批准的校验器清单、策略和确定性校验程序;交付方只提交 manifest 和数据文件。
至少明确:
- 用哪两个 manifest 字段选择规则,以及没有精确匹配时怎样停止。
- 必需文件、格式、字符编码、列名、数据类型、行数和校验和规则。
- 校验器和策略如何发布版本、固定 SHA-256,并加入已批准的校验器清单。
- 哪些 FAIL 可以修复后重新提交,哪些需要人工复核。
- 报告键的唯一性、报告保留、读取、审计、备份和恢复要求。
- 并发交付、覆盖、删除和对象版本由哪个外部系统控制。
样例校验器面向小型 CSV。真实校验器应流式处理数据,并限制文件大小、行数、执行时间、内存和输出大小。交付 ID 和报告键应作为经过校验的结构化参数传入;不要把未经校验的值拼接到 Shell 命令中,也不要自动批准任意 Shell 命令。
将这一模式用于其他业务场景
同样的计划、审批、确定性校验和报告边界可以用于其他文件交付,但每个场景都需要接收方自己的 manifest 约定、已批准的校验器清单、策略和校验器:
| 行业场景 | 一批待验收的数据 | 可以写入接收方规则的检查 | 通过后通常交给的系统 |
|---|---|---|---|
| 电商与零售 | 每日订单、退款或库存文件 | 文件名、列结构、金额格式、数据行数和校验和 | 数仓、结算或库存系统 |
| 制造与供应链 | 发货清单、批次和质检数据 | 必需文件、批次号、字段格式、记录数量和校验和 | WMS、MES 或质量系统 |
| 金融与支付 | 对账或清算批次 | 币种、笔数、总金额,以及与受信控制数的一致性 | 对账或清算系统 |
| AI 与数据工程 | 训练数据分片或评测集 | 文件清单、格式、分片数量、元数据列和校验和 | 训练、评测或数据处理流程 |
PASS 只表示本批文件通过已经配置的检查,不自动证明交付方身份或业务数据真实,也不表示 AgentWorks 已经完成导入、结算或放行。
上线前完成验证
本页提供的是合成数据教程,不是已经针对你的生产规则完成的验证。上线前,请在非生产范围使用最终的最小权限凭证和正式批准的校验器清单,重新运行一个 PASS 和一个 FAIL 用例,并从对象存储端确认两份报告。
同时确认生产发布检查中的权限、恢复、观测和回退要求。还应明确校验规则的负责人、目录变更审批、凭证轮换、报告保留、对象清理、费用管理,以及下游系统如何消费或拒绝报告。
完成后处理测试资源
本实战不包含删除凭证、资源或对象的步骤。完成验证并保留所需报告后,请记录本实战创建的对象存储凭证、沙箱实例、智能体模板、智能体实例和测试对象,并移交给准备条件中确认的资源负责人。
负责人应先确认这些资源没有被其他任务引用,再按组织流程保留或清理。对象存储中的报告和样例由存储所有者按照既定的数据保留策略处理;不要为了清理测试对象而扩大本实战凭证的删除权限。沙箱的回收和费用边界参见说明沙箱如何启动、回收和计费。