从埋点需求到规则资产:Hermes Agent 重构得物数仓工作流(原文摘要)
一句话总结
数仓埋点承接最消耗的不是”生成 SQL”,而是”把分散信息重新拼起来“——需求文档动作→历史点位→指标口径→字段变更→发布确认;得物选 Hermes Agent(而非 OpenClaw)重构数仓工作流,核心把”判断前的工程化准备“交给 Agent,人聚焦口径裁决 + 生产放行;上线前 3 道门(事实源门/预演门/责任门)+ 4 类资产化能力底座(规则/协作可见/上下文与事实源/结构化工具接口)。
8 条核心观点
- 数仓场景的”埋点承接”特殊性:把分散信息重新拼起来(文档→历史点位→指标口径→字段变更→发布确认),分散性高、易错。”关掉窗口就失忆”在数仓场景不可接受。
- Hermes vs OpenClaw 选型逻辑:选 Hermes 因 4 项原生能力(分层持久记忆 + 技能自动沉淀 + 多平台统一网关 + 工具与扩展生态);选 Agent 不只看能力清单,看场景痛点——”反复回溯历史口径 + 让 AI 进入协作沟通现场 + 生产动作可审计”是数仓刚需。
- 4 个工程构件:工作区(独立空间) + 看板(状态机:进入/设计/预演/评审/交付,每步责任人) + 规则+长期记忆(“老同学才知道”沉淀为可执行检查清单) + 结构化工具接口 + 预演 + 人工确认点。
- 能力边界划分:Hermes 是”流程编排者“不是”埋点生成器”;Hermes 负责”判断前工程化准备”(材料/历史/候选方案/系统预演/风险证据),人负责业务语义/指标口径/敏感字段/下游影响/生产放行。
- 单 Agent 编排 + 多能力模块:”单 Agent 保持统一上下文 + 能力模块承接稳定动作(工具调用/输入约束/输出产物/停顿条件)”——固化流程契约,避免提示词换说法检查重点就漂。
- 4 类资产化能力底座:规则包答”怎么判断” + 工作区答”依据在哪里” + 看板答”卡在哪里” + 结构化工具接口答”系统状态是否验证过”;上下文传递不靠”多塞材料”而是分层(临时留本轮/可复用沉规则包/把关进治理记忆)。
- 风险治理 3 道门:事实源门 + 预演门 + 责任门——任何一道门缺证据,Hermes 只能停在候选/待确认状态,不能继续生产写入;越靠近写入越要先预演、再确认、最后留痕。
- 规模化落地路径:用连续样本证明准备时间/交付周期/评审通过率/返工原因的变化,只有指标和看板、日志、确认记录一一对应时,才具备扩大使用的工程基础——”自动化动作堆得越多 ≠ 链路可用”。
关键参数/数字
| 项 |
数字/范围 |
用途 |
| 工程构件数 |
4 个 |
工作区/看板/规则+长期记忆/结构化工具接口+预演+人工确认 |
| 状态机阶段 |
5 步 |
进入→设计→预演→评审→交付,每步责任人 |
| Hermes 原生能力 |
4 项 |
分层持久记忆/技能自动沉淀/多平台统一网关/工具与扩展生态 |
| 持久记忆分层 |
4 层 |
短期会话/中期交互/长期知识/技能库 + SQLite + FTS5 |
| 协作平台接入 |
飞书/钉钉/企微 |
原生网关 |
| 风险治理门数 |
3 道 |
事实源门 + 预演门 + 责任门 |
| 资产化能力底座 |
4 类 |
规则/协作可见/上下文与事实源/结构化工具接口 |
| 能力模块设计原则 |
5 项契约 |
输入/动作边界/输出产物/失败处理/经验回写 |
| 规模化验证指标 |
4 个 |
准备时间/交付周期/评审通过率/返工原因 |
| 上下文分层职责 |
4 类 |
聊天补语境/工作区留证/系统预演验证/生产系统最终事实源 |
| 作者团队往期文章 |
5 篇 |
含 [[让 Claude Code 拥有自我进化和记忆系统]] / [[用 LLM Agent 重构告警排查流程]] / [[Claude Code Harness 工程:数仓侧落地方案]] 等 |
核心金句
- “数仓埋点承接最消耗的不是’生成 SQL’,而是’把分散信息重新拼起来’。”(全文痛点)
- “Hermes Agent 不是’埋点生成器’,是’流程编排者’。”(能力边界)
- “选 Agent 不只看能力清单,看场景痛点。”(选型原则)
- “能力模块不是’工具清单’,是’流程契约’。”(模块设计)
- “规则包回答’怎么判断’,工作区回答’依据在哪里’,看板回答’卡在哪里’,结构化工具接口回答’系统状态是否验证过’。”(4 资产分工)
- “上下文传递不能靠’多塞材料’解决,而是要把任务背景、阶段结论、人工反馈和运行元数据分开保存。”(分层原则)
- “越靠近写入,越要先预演、再确认、最后留痕。”(风险治理)
- “任何一道门缺证据,Hermes Agent 都只能停在候选方案或待确认状态,不能继续推进生产写入。”(3 道门硬约束)
- “只有当这些指标和看板、日志、确认记录一一对应时,这条链路才真正具备扩大使用的工程基础。”(规模化前提)
- “会议纪要作为协作语境进入需求上下文。”(会议纪要定位)
关联图谱
上游(基于 / 来自)
- Hermes Agent 平台:分层持久记忆 + 技能自动沉淀 + 多平台网关 + 工具与扩展生态
- OpenClaw(本文平行对比对象):同赛道 Agent 框架,但在”反复回溯历史口径 + 协作沟通现场嵌入 + 生产动作可审计”上”没有对应的能力定位”
- MCP(Model Context Protocol):企业内部系统通过 MCP 命令封装稳定接入
下游(应用于 / 验证于)
- 得物数仓埋点承接场景:每个需求独立工作区 + 状态机看板 + 规则包 + 结构化接口
- 可迁移场景:指标发布、配置变更、数据质量排查(同套机制 + 换事实源和工具接口)
- 多平台协作:飞书(澄清/驳回/确认语境)+ 钉钉 + 企微(原生网关)
同级(横向 / 并列)
- 阿里淘系 Harness 主题:[阿里云开发者-淘宝主播Agent的Harness工程实战] / [阿里妹-端到端业务需求专家Agent-4层架构8步流程]
- 得物同主线:[[Skill-Self-Evolution]] (Claude Code 自我进化和记忆系统)/ [[用 LLM Agent 重构告警排查流程]] / [[Claude Code Harness 工程:数仓侧落地方案]]
- Skill 主线:[[Agent Skills 系统性综述]] / [[谷歌开源 agent-skills]] / [[Addy-Osmani-agent-skills-设计哲学]] / [[PM-Skills-Marketplace-产品经理必备skill]]
- Loop 主题:[Loop-Engineering-验证才是瓶颈]/ [[Addy-Osmani-Loop-Engineering]]
- 评测主线:[[腾讯-AI-Agent-Skill-测评方案落地]] “测评是 Demo→生产必须跨过的门槛”同主线
- 风险治理:[[阿里云开发者-淘宝主播Agent的Harness工程实战]] 5 层纵深防御 + 记忆对账信任度闭环
备注与限制
- 作者小诘、博温,得物技术团队
- 核心选型立场:选 Hermes Agent 而非 OpenClaw — 原因是 4 项原生能力更贴近数仓场景
- 关键术语:Hermes Agent = 文中特指的智能体平台(非通用概念,与 OpenClaw 平行对比)
- 阶段 5 “规模化落地路径”中 4 个量化指标(准备时间/交付周期/评审通过率/返工原因)具体数字未披露
- Hermes Agent 平台具体技术栈(基于什么框架)未明示
- 规则包的版本管理 / 多人协作冲突解决未展开
- 得物技术团队往期回顾 5 篇未给出完整链接(仅列标题)
- “可迁移到指标发布/配置变更/数据质量排查”的具体落地案例未展开
- “会议纪要进入需求上下文”的自动化机制未给具体方法
- “结构化工具接口”具体接口设计 / 入参出参规范未公开
- 与 OpenClaw 的对比只在”能力定位”层面,无 Benchmark 数据(响应时间/成功率/记忆命中率)