货拉拉 DataAgent 实践：策略复盘的智能化探索

DID（双重差分）是策略复盘中常用的因果推断方法。它通过比较策略影响组与对照组在策略实施前后的变化差异，在满足平行趋势等识别条件的前提下，尽可能排除同期市场波动和其他共同因素的干扰，从而估计策略带来的增量效果。

策略复盘为何需要智能化

货运市场的供需关系具有明显的时空波动。为及时响应市场变化，运营团队需要动态调整供需策略，在改善供需匹配效率和用户体验的同时，推动经营收益增长。

策略调整后，仅通过观察订单量、成交率或收入等指标的前后变化，并不能准确判断策略是否有效，因为这些指标还可能受到季节性、市场趋势及同期其他活动等因素影响。因此，需要通过科学的复盘方法评估策略的实际效果，为策略的继续实施、优化调整或扩大覆盖提供依据。

实际人工策略复盘过程中逐渐沉淀了以下 SOP：首先根据策略类型和实施方式判断 DID 是否适用，并确定处理组、对照组及分析周期；随后完成数据获取与质量校验；在此基础上估算策略效果，并通过平行趋势、安慰剂等检验评估结论的稳健性；最后结合分组和指标拆解开展归因分析，形成复盘报告与策略建议。

这套 SOP 需要复盘人员在多个数据与分析工具之间切换，整个过程周期较长、重复工作多、对个人经验依赖强、且难以跨场景复用，这些问题都在限制着策略复盘的效率。

因此，我们开始探索一套由 Agent 驱动的 DID 策略复盘线上化方案，预期由 Agent 理解策略背景自动编排各分析环节，辅助高效完成数据获取、代码生成、统计检验、结果解释和报告输出，形成可跨场景复用的能力。

从单 Agent 硬扛到多 Agent 编排

HClaw 是货拉拉内部打造的企业级通用智能体平台，基于 Claude Agent SDK 构建，面向复杂业务场景提供 Agent 调用编排、状态管理和过程追踪等能力。

初期，基于 HClaw 单 Agent 模式尝试落地 DID 策略复盘时，效果并不理想。我们逐渐认识到 DID 策略复盘是一个典型的 Agent 长程任务，具有以下几个痛点：

所以，我们面对的挑战也从“Agent 能否完成一次 DID 分析任务”，转变为“Agent 能否稳定、可追溯地完成长链条复盘任务”。

Agent 方案选型对比

Hclaw 已覆盖业界常见的 Agent 能力，包括 Skills、SubAgents、Agent teams 和 Dynamic workflows（以下简称 Workflow）。它们都可以扩展 Agent 的执行能力，但解决的问题并不相同：有的侧重任务拆分，有的侧重经验复用，有的侧重多角色协作，有的则侧重流程编排。

简单来看，四种方式分别对应四种不同的组织逻辑。

• Skills更像一套可以反复调用的工作规范。它能够将复盘步骤、输出格式和注意事项沉淀下来，减少重复描述，但本身不负责任务调度，也不会自动建立节点之间的依赖关系。对于标准化程度较高的单项任务，Skills 更适合发挥作用。

• SubAgents适合将一个大任务拆成几个相对独立的局部任务，例如单独负责取数、资料整理或结果解释。它能够隔离部分上下文，但主 Agent 需要自行接收、理解和整合返回结果。如果缺少统一的输入输出规范，不同 SubAgent 之间仍可能出现方法、样本或时间口径不一致。

• Agent teams强调多个 Agent 之间的持续协作。不同成员可以分别承担任务，并通过共享任务列表或相互通信协作机制推进工作。这种方式适合开放性较强、需要反复讨论和动态分工的项目，但协作过程仍依赖主导 Agent 的判断，任务边界和结果口径需要额外管理。

• Dynamic workflows则将重点从“如何派发任务”转向“如何执行流程”。它可以预先定义节点关系、执行顺序、并行分支、状态传递和结果校验，使复杂任务按照确定的结构推进。主对话不必承载全部中间过程，后续节点也可以直接读取前序节点产生的结构化结果。

方案之间的差异不能只停留在能力描述上。本着实践出真知的原则，我们先后迭代了多个版本，分别尝试了 Skills、SubAgent、Workflow 等方案。

最终发现 Workflow 相对其他方案，能更稳定应对 DID 策略复盘这种步骤相对固定、过程需要追踪、结果需要复核的长程任务。

迭代中踩过的三类典型坑

在介绍 Workflow 方案前，可以先回看下我们在未引入 Workflow 前遇到了哪些 badcase ，踩过哪些坑。历史方案执行时在复盘各阶段的衔接环节表现不稳定，经过我们整理，过程中经常出现以下三类问题：

A. 目标与规划类：Agent 自行缩小了任务范围

任务要求判断是否需要读取候选城市数据，并进行换对照检验。但 Agent 看到候选数据量较大后，自行判断“没有必要”，直接进入下一步。这个判断没有触发异常，流程也继续运行，原本要求完成的检查环节却被悄然跳过。

问题在于，一个需要被记录和复核的判断，被转化成了 Agent 的临场决定。长任务中，如果步骤和停止条件只存在于提示或上下文里，任务范围就可能在执行过程中发生变化。

B. 记忆与经验类：关键约束在上下文传递中丢失

长任务运行过程中，取数结果、分析过程和中间结论不断进入上下文，早期提出的目标与约束容易被弱化。任务拆分后，如果节点只接收局部信息，也可能无法感知前序步骤已经作出的判断。

实际运行中，前序步骤明确要求完成稳健性检验、归因分析并保留 warnings，但后续生成报告时，这些要求没有被完整带入。最终报告并非完全错误，而是遗漏了部分必要环节。

这类问题的核心不是某个节点算错，而是任务要求没有被稳定地记住和传递。

C. 执行与工具类：有返回结果，不代表执行正确

信息成功传递到节点，并不意味着执行结果一定正确。不同节点可能基于各自的理解选择方法、处理日期或解读数据，最终产生互相矛盾的局部结论。

实际运行中，方法选择节点判断应采用合成对照，效果估算节点却直接执行 DID；另一个节点还将 pre 期和 post 期标签混淆。每个节点都返回了结果，但这些结果对应的并不是同一套方法、同一批样本和同一段时间。

这类问题的核心不是信息丢失，而是信息在执行过程中发生了偏差，且缺少统一的结果校验。

这三类问题分别出现在规划、记忆和执行环节，底层原因却相近：计划、中间状态和校验责任都依赖主 Agent 在上下文中自行维护。不同的子任务结果不断追加到主 Agent 上下文中持续增长，早期目标和约束容易弱化，进而出现步骤遗漏、口径变化或结果难以复核的问题。

因此，解决问题的关键不是继续增加 Agent 数量，而是将复盘方法转化为一套有明确依赖关系、能够传递状态并支持结果校验的方案。

最终方案：让 Workflow 承载复盘 SOP

我们最终方案是将已经沉淀复盘 SOP 环节改写成 Workflow。

Workflow 的核心不是替代 Agent 或某个专业工具，而是将复杂任务拆解为可调度、可传递、可复核的执行过程。每个节点负责一个相对独立的分析任务，前序结果通过内存变量实现可靠状态传递，最终由独立的校验节点检查报告是否符合要求。

先固化方法，再划分节点

Workflow 本身是 JavaScript 脚本，但该脚本仅能负责编排 Agent 和 基于基础语法进行基础的变量处理、判断、循环等工作。比如该脚本本身没有直接的文件系统或 Shell 访问权限，同时也不支持模块加载：如果包含 import() 的脚本会在运行开始前失败。所以，以上具体工作都需要放入 Agent 节点的任务中。

在 Hclaw 中，我们可以通过自然语言自动生成 Workflow，只需要描述任务目标、执行步骤和输出要求，系统即可形成初始版本。随后，再根据实际运行结果调整节点边界和执行条件，例如明确“归因分析必须执行”“稳健性检验不通过时需要重新判断对照组”等规则，Workflow 的伪代码如下：

// 固定结构元数据
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 能力：上线前辅助效果预估与方案推演，上线中持续监测指标变化并识别异常，上线后完成效果评估与归因复盘，最终形成从策略设计、执行监控到复盘优化的闭环。