本文以货拉拉内部策略复盘场景为例，分享如何借助 Dynamic Workflows，将复杂的 DID 因果分析 SOP 转化为可执行、可追踪、可复核的多 Agent 工作流。文章内容涵盖方案选型、Dynamic Workflows 实践、真实踩坑等经验。
引言：策略上线后，怎么验证效果？
货运市场的供需关系具有明显的时空波动 。为及时响应市场变化，运营团队需要动态调整供需策略，在改善供需匹配效率和用户体验的同时，推动经营收益增长。
策略调整后，仅通过观察订单量、成交率或收入等指标的前后变化，并不能准确判断策略是否有效，因为这些指标还可能受到季节性、市场趋势及同期其他活动等因素影响。因此，需要通过科学的复盘方法评估策略的实际效果，为策略的继续实施、优化调整或扩大覆盖提供依据。
DID（双重差分）是策略复盘中常用的因果推断方法。它通过比较策略影响组与对照组在策略实施前后的变化差异，在满足平行趋势等识别条件的前提下，尽可能排除同期市场波动和其他共同因素的干扰，从而估计策略带来的增量效果。
实际人工策略复盘过程中逐渐沉淀了以下 SOP：
- 首先根据策略类型和实施方式判断 DID 是否适用，并确定处理组、对照组及分析周期；
- 随后完成数据获取与质量校验；在此基础上估算策略效果，并通过平行趋势、安慰剂等检验评估结论的稳健性；
- 最后结合分组和指标拆解开展归因分析，形成复盘报告与策略建议。
这套 SOP 需要复盘人员在多个数据与分析工具之间切换，整个过程周期较长、重复工作多、对个人经验依赖强、且难以跨场景复用，这些问题都在限制着策略复盘的效率。
因此，我们开始探索一套由 Agent 驱动的 DID 策略复盘线上化方案，预期由 Agent 理解策略背景自动编排各分析环节，辅助高效完成数据获取、代码生成、统计检验、结果解释和报告输出，形成可跨场景复用的能力。
01：技术背景：从单 Agent "硬扛" 到多 Agent 编排
HClaw 是货拉拉内部打造的企业级通用智能体平台，基于 Claude Agent SDK 构建，面向复杂 业务 场景提供 Agent 调用编排、状态管理和过程追踪等能力。
初期，基于 HClaw 单 Agent 模式尝试落地 DID 策略复盘时，效果并不理想。我们逐渐认识到 DID 策略复盘是一个典型的 Agent 长程 任务，具有以下几个痛点：
| 痛点 | 解释 |
|---|---|
| 环节之间存在明确依赖 | 例如数据校验完成后才能进行效果估算 |
| 各环节需要共享状态 | 策略口径、样本范围、时间窗口及中间结果 |
| 部分任务可以并行执行 | 如不同稳健性检验和异质性分析 |
| 错误会累积放大 | 任一环节的口径偏移，都可能沿任务链传递并影响最终结论 |
| 需要判断与复核 | 方法选择、异常数据处理和结论输出等关键节点 |
所以，我们面对的挑战也从 "Agent 能否完成一次 DID 分析 任务 " ，转变为 "Agent 能否稳定、可追溯地完成长链条复盘任务" 。
02：Agent 方案选型对比
Hclaw 已覆盖业界常见的 Agent 能力，包括 Skills、Sub Agent s 、Agent teams 和 Dynamic workflows（以下简称Workflow） 。它们都可以扩展 Agent 的执行能力，但解决的问题并不相同：有的侧重任务拆分，有的侧重经验复用，有的侧重多角色协作，有的则侧重流程编排。
| 维度 | Skills | SubAgents | Agent teams | Dynamic workflows |
|---|---|---|---|---|
| 它是什么 | Agent 遵循的提示词 | 主 Agent 生成的独立工人 | 多 Agent 实例相互协作 | 可编排、扩展与运行 Agent 的 js 脚本 |
| 谁决定下一步 | 主 Agent 和 提示词 | 主 Agent，逐轮思考 | 主 Agent ，逐轮思考 | Workflow 脚本代码 |
| 中间结果 存 哪 | 上下文窗口 | 上下文窗口 | 共享任务列表 | 代码 内存变量 |
| 可复用性 | Skill 提示词本身 | SubAgent 的定义 | Team 的定义 | Workflow 本身 |
| 规模 | 每轮少量任务 | 每轮少量专用 Agent | 几个长期对等体 | 数十到数百 Agent |
简单来看，四种方式分别对应四种不同的组织逻辑。
- Skills 更像一套可以反复调用的工作规范。它能够将复盘步骤、输出格式和注意事项沉淀下来，减少重复描述，但本身不负责任务调度，也不会自动建立节点之间的依赖关系。对于标准化程度较高的单项任务，Skills 更适合发挥作用。
- Sub Agent s 适合将一个大任务拆成几个相对独立的局部任务，例如单独负责取数、资料整理或结果解释。它能够隔离部分上下文，但主 Agent 需要自行接收、理解和整合返回结果。如果缺少统一的输入输出规范，不同SubAgent 之间仍可能出现方法、样本或时间口径不一致。
- Agent teams 强调多个 Agent 之间的持续协作。不同成员可以分别承担任务，并通过共享任务列表或相互通信协作机制推进工作。这种方式适合开放性较强、需要反复讨论和动态分工的项目，但协作过程仍依赖主导 Agent 的判断，任务边界和结果口径需要额外管理。
- Dynamic workflows 则将重点从 "如何派发任务"转向"如何执行流程" 。它可以预先定义节点关系、执行顺序、并行分支、状态传递和结果校验，使复杂任务按照确定的结构推进。主对话不必承载全部中间过程，后续节点也可以直接读取前序节点产生的结构化结果。
方案之间的差异不能只停留在能力描述上。本着实践出真知的原则，我们先后迭代了多个版本，分别尝试了Skills、SubAgent、Workflow等方案。
最终发现 Workflow 相对其他方案，能更稳定应对 DID 策略复盘这种步骤相对固定、过程需要追踪、结果需要复核的长程任务。
03：迭代中踩过的坑
在介绍 Workflow 方案前，可以先回看下我们在未引入 Workflow 前遇到了哪些 badcase ，踩过哪些坑。历史方案执行时在复盘各阶段的衔接环节表现不稳定，经过我们整理，过程中经常出现以下三类问题：
A. 目标与规划类：Agent 自行缩小了任务范围
任务要求判断是否需要读取候选城市数据，并进行换对照检验。但 Agent 看到候选数据量较大后，自行判断"没有必要"，直接进入下一步。这个判断没有触发异常，流程也继续运行，原本要求完成的检查环节却被悄然跳过。
问题在于，一个需要被记录和复核的判断，被转化成了 Agent 的临场决定。长任务中，如果步骤和停止条件只存在于提示或上下文里，任务范围就可能在执行过程中发生变化。
B. 记忆与经验类：关键约束在上下文传递中丢失
长任务运行过程中，取数结果、分析过程和中间结论不断进入上下文，早期提出的目标与约束容易被弱化。任务拆分后，如果节点只接收局部信息，也可能无法感知前序步骤已经作出的判断。
实际运行中，前序步骤明确要求完成稳健性检验、归因分析并保留 warnings，但后续生成报告时，这些要求没有被完整带入。最终报告并非完全错误，而是遗漏了部分必要环节。
这类问题的核心不是某个节点算错，而是任务要求没有被稳定地记住和传递。
C. 执行与工具类：有返回结果，不代表执行正确
信息成功传递到节点，并不意味着执行结果一定正确。不同节点可能基于各自的理解选择方法、处理日期或解读数据，最终产生互相矛盾的局部结论。
实际运行中，方法选择节点判断应采用合成对照，效果估算节点却直接执行 DID；另一个节点还将 pre 期和 post 期标签混淆。每个节点都返回了结果，但这些结果对应的并不是同一套方法、同一批样本和同一段时间。
这类问题的核心不是信息丢失，而是信息在执行过程中发生了偏差，且缺少统一的结果校验。
这三类问题分别出现在规划、记忆和执行环节，底层原因却相近：计划、中间状态和校验责任都依赖主 Agent 在上下文中自行维护。不同的子任务结果不断追加到主 Agent 上下文中持续增长，早期目标和约束容易弱化，进而出现步骤遗漏、口径变化或结果难以复核的问题。
因此，解决问题的关键不是继续增加 Agent 数量，而是将复盘方法转化为一套有明确依赖关系、能够传递状态并支持结果校验的 方案。
04：最终方案：让 Workflow 承载复盘 SOP
我们最终方案是将已经沉淀复盘 SOP 环节改写成 Workflow。
Workflow 的核心不是替代 Agent 或某个专业工具，而是将复杂任务拆解为可调度、可传递、可复核的执行过程。每个节点负责一个相对独立的分析任务，前序结果通过内存变量实现可靠状态传递，最终由独立的校验节点检查报告是否符合要求。
先固化方法，再划分节点
Workflow 本身是 JavaScript 脚本，但该脚本仅能负责编排 Agent 和 基于基础语法进行基础的变量处理、判断、循环等工作。比如该脚本本身没有直接的文件系统或 Shell 访问权限，同时也不支持模块加载：如果包含 import() 的脚本会在运行开始前失败。所以，以上具体工作都需要放入 Agent 节点的任务中。
在 Hclaw 中，我们可以通过自然语言自动生成 Workflow，只需要描述任务目标、执行步骤和输出要求，系统即可形成初始版本。随后，再根据实际运行结果调整节点边界和执行条件，例如明确"归因分析必须执行""稳健性检验不通过时需要重新判断对照组"等规则，Workflow 的伪代码如下：
javascript
// 固定结构元数据
export const meta = {
name: '',
description: '',
phases: [],
}
// ── 策略复盘 workflow 思路示意 ──
const state = {}
phase('方法选择 + 数据准备')
// 1. 方法选择 + 取数 → 存进 state.prep
state.prep = await agent('选方法 + 最佳对照城，取数', { label: '方法选择 + 取数' })
phase('并行分析')
// 2. 3 路并行（效果 / 稳健性 / 归因互不依赖）→ 各自结果存进 state
const [did, robust, attr] = await parallel([
() => agent('解读 DID 结果，评 evidence_level', { label: 'DID估算' }),
() => agent('平行趋势是否成立', { label: '稳健性' }),
() => agent('多维度归因下钻', { label: '归因' }),
])
Object.assign(state, { did, robust, attr })
phase('出报告')
// 3. 汇总出报告：把 state 里的中间结果通过变量传给 agent
state.report = await agent(
`基于以下结果构造报告：\n` +
`DID: ${JSON.stringify(state.did)}\n` +
`稳健性: ${JSON.stringify(state.robust)}\n` +
`归因: ${JSON.stringify(state.attr)}\n` +
`按 9 条规则（CI / evidence_level / 归因区块 / 禁业务建议 / 追问结尾 ...）输出`,
{ label: '出报告' }
)
phase('对抗验证')
// 4. 对抗验证：独立 agent 逐条找茬（验证者与执行者分离）
state.check = await agent(
`审查这份报告是否违反 9 条规则：\n${JSON.stringify(state.report)}`,
{ label: '对抗验证' }
)
return state.check.ok ? state.report : fix(state) // 违规则修复后重查Workflow 将复杂目标拆分为多个任务单元，通过状态传递和协同执行连接各个环节，最终汇总为可追踪、可复核的结果。对于任务依赖较多、需要精细控制的场景，还可以进一步调整 Workflow 的源码，对节点关系、状态传递和异常处理进行更细致的编排。
运行过程：每一步都有迹可循
运行过程中，可以看到方法选择和数据准备已经完成，效果估算、稳健性检验和归因分析正在并行推进。节点状态、执行耗时和当前进度均可单独查看。
这意味着复盘过程不再依赖 Agent 自行记忆和推进，关键步骤有明确位置，中间结果也有固定的传递路径。
最终结果：从效果数字到业务依据
任务完成后，Workflow 输出一份结构完整的策略复盘报告，涵盖效果估计、置信区间、证据等级、稳健性检验、归因分析和风险提示。
报告不会只给出"策略有效"或"策略无效"的单一结论。对于数据缺失、检验未通过或结论可信度不足的情况，系统会在结果中明确标注，并给出补充数据、重新分析或调整策略的建议。
这使报告能够同时服务于两类判断：一方面回答策略是否带来收益、效果来自哪些维度；另一方面说明当前结论是否足以支持继续实施、扩大覆盖或调整方案。
总结与展望
这次实践说明，Dynamic workflows 的价值不只是拆分 Agent，而是将业务方法沉淀为可执行、可追踪、可复核的任务结构。对于策略复盘这类步骤明确、依赖较多且需要质量检查的任务，Workflow 能够让模型能力更稳定地嵌入业务流程。
后续我们规划，继续迭代完善任务状态、节点输入输出规范和结果校验流程，结合运行日志建立更系统的监控、评测和异常修复机制，优化人工介入场景的产品逻辑。
此外，我们还计划将 Dynamic Workflows 的实践经验迁移至策略模拟仿真 、业务异动归因 等场景，逐步构建覆盖策略全生命周期的数据驱动 Agent 能力 ：上线前辅助效果预估与方案推演，上线中持续监测指标变化并识别异常，上线后完成效果评估与归因复盘，最终形成从策略设计、执行监控到复盘优化的闭环。
产研团队：大数据技术与产品部-数据应用组-业务应用组
笔者介绍：
夏徐松 ｜ 实习生。负责 DataAgent 产品功能开发。
包恒彬 ｜ 资深大数据工程师。负责罗盘归因系统、AI运营提效、异动监测系统等项目。目前专注于 DataAgent 产品在运营全场景赋能落地。