从埋点需求到规则资产:Hermes Agent 重构得物数仓工作流

数仓埋点需求的承接流程中,最消耗数据承接方的往往是把分散的信息重新拼起来——需求文档里的动作到底要不要采集,历史上有没有类似点位,指标口径有没有被下游使用,新增字段要改哪几层表,发布前又该由谁确认。本文介绍得物数仓团队选型 Hermes Agent(而非 OpenClaw)重构数仓工作流的实战经验,核心:把”判断前的工程化准备”交给 Agent,人聚焦口径裁决 + 生产放行。

一、Hermes Agent 让流程可控

选型理由:Hermes vs OpenClaw

数仓埋点承接场景对 Agent 有 4 项原生能力诉求:

  1. 分层持久记忆:短期会话/中期交互/长期知识/技能库四层结构,本地 SQLite + FTS5 全文检索。”关掉窗口就失忆”,在需要反复回溯历史口径的数仓场景是不可接受的
  2. 技能自动沉淀:任务完成后能把经验提炼成 Markdown 技能文档并持续优化 —— 这正是”专家经验资产化”的框架级支撑,本文反复出现的”规则包”就构建在这套技能机制之上
  3. 多平台统一网关:原生接入飞书、钉钉、企业微信等协作平台,智能体直接嵌进团队已有的沟通现场,不用另建工作台
  4. 工具与扩展生态:终端执行、定时任务、浏览器自动化等内置工具,企业内部系统经 MCP 命令封装稳定接入

核心判断:选 Agent 不只看能力清单,看场景痛点——”反复回溯历史口径”+”让 AI 进入协作沟通现场”+”生产动作可审计”这 3 个是数仓场景刚需。

4 个工程构件

在这套框架之上,把一次埋点需求承接拆成 4 个可追踪的工程构件:

Hermes Agent 的能力边界

关键定位:Hermes Agent 不是”埋点生成器”,是”流程编排者”。

Hermes Agent 的边界是”把问题整理到足够可判断“——让数据承接方从反复翻材料、追状态、补上下文里释放出来,把精力放在真正需要负责的地方:口径能不能成立,风险能不能接受,生产动作能不能放行。

二、用单 Agent 串流程,用能力模块沉淀可复用能力

选型逻辑:为什么是”单 Agent 编排 + 多能力模块”?

如果只靠一段提示词,会遇到两个问题:

所以选择”单 Agent 编排 + 多能力模块 + 看板确认点”:

固化流程契约

能力模块不是”工具清单”,是”流程契约”——固化每个能力模块的:输入、动作边界、输出产物、失败处理、经验回写。只有这些契约稳定,Hermes Agent 才不会因为提示词换一种说法就改变检查重点。

可复用能力模块设计:从埋点链路迁移到更多数据研发场景

能力模块不是只服务一次埋点需求,而是把素材采集、历史检索、变更预演、发布确认、经验沉淀抽成可复用的流程模块。换事实源和工具接口后,同一套机制也能迁移到指标发布、配置变更和数据质量排查——可复用的 SKILL 就是这套机制的核心载体。

三、总体工作流:从一次对话变成一条可回放链路

端到端链路示意

业务 → “昨天各体裁发布量”示例:

  1. 需求入口(飞书群消息)
  2. 工作区(独立空间,集中需求文档/历史讨论/评审结论/交付产物)
  3. 规则包 + 长期记忆(把”老同学才知道”的判断写成可执行检查清单)
  4. 系统预演(用结构化工具接口先在测试环境跑一遍)
  5. 人工确认点(看板状态机:进入→设计→预演→评审→交付,每步责任人)
  6. 交付归档(产物入库 + 经验回写)

关键设计:会议纪要作为协作语境进入需求上下文,补充已确认事实、责任人和待澄清问题。 任务看板承接需求状态、推进和人工介入。 工作区保留的事实源作为最终可追溯依据。

单需求示例

业务希望稳定查看”昨天各体裁发布量”。如果只让模型直接写 SQL,很容易把物理字段、业务发生日期和默认过滤混在一起。Hermes Agent 的做法是:先固化事实,再预演风险,最后把需要人判断的点推到看板确认。

四、能力底座:把规则、上下文和命令资产化

核心命题:埋点自动化真正难的是把历史口径、下游影响、人工确认和生产状态拆成可复用资产——规则包回答”怎么判断”,工作区回答”依据在哪里”,看板回答”卡在哪里”,结构化工具接口回答”系统状态是否验证过”。

1. 规则资产化:先决定什么值得记住

关键不是让 Hermes Agent 记得更多,而是把材料分层:

下一次相似需求到来时,系统先补证据、提醒风险,而不是让数据承接方从头解释。

2. 协作可见:让 AI 不在后台默默跑完

规则资产只有进入协作流程才有价值。三件套:

三者合起来,才能让人知道 AI 做到了哪一步、还缺什么、哪里必须停下来等确认。

3. 上下文与事实源:下一任务读什么,最终相信什么

上下文传递不能靠”多塞材料”解决,而是要把任务背景、阶段结论、人工反馈和运行元数据分开保存:

类型 职责
聊天 补语境
工作区 留证
系统预演 验证
生产系统 最终事实源

4. 结构化工具接口:把生产动作变成可验证接口

当智能体接近生产系统时,最不应该依赖页面识别和临场点击。结构化工具接口的作用:把查询、绑定、发布、验证这些动作包装成 参数明确、返回结构化、过程可审计 的接口。越靠近写入,越要先预演、再确认、最后留痕。

五、风险治理:可验证执行、人工确认点与审计留痕

Hermes Agent 越靠近生产链路,越不能只追求”自动执行”。上线前只看三类硬证据:事实来源是否可信,系统预演是否通过,责任人是否已经确认。

上线前 3 道门

硬约束:任何一道门缺证据,Hermes Agent 都只能停在候选方案或待确认状态,不能继续推进生产写入。

治理的目标不是让数据承接方把系统做过的事再手工复查,而是让系统在关键位置停下来,把证据、预演结果和责任人摆到台面上。人的精力应该留给真正的判断点:口径要不要调整,风险能不能接受,生产动作能不能放行。

六、结论与下一步

已形成的主线

Hermes Agent 值得放大的是 可回放、可确认、可复用的工作流能力。当前链路已经围绕 4 件事形成主线:

  1. 跑通需求流转
  2. 前置风险拦截
  3. 沉淀规则资产
  4. 让数据承接方把精力放到口径裁决和生产边界上

规模化路径

下一步的重点不是继续堆更多自动化动作,而是把证据口径跑实——用连续样本证明:

只有当这些指标和看板、日志、确认记录一一对应时,这条链路才真正具备扩大使用的工程基础。

作者团队往期回顾

  1. 让 Claude Code 拥有自我进化和记忆系统 得物技术
  2. 用 LLM Agent 重构告警排查流程 得物技术
  3. 得物技术在 AICon 关于大模型与 Agent 技术实践分享来袭!
  4. HorizonVault 技术深潜:如何在 HDD 上做出 100GB/s+ 级大吞吐分布式存储 得物技术
  5. Claude Code Harness 工程:数仓侧落地方案 得物技术

备注