1. 项目缘起当埋点需求成为数仓团队的“阿喀琉斯之踵”在数据仓库团队工作过的人大概都对“埋点需求”这四个字有着复杂的情感。它既是数据生产的源头活水又是流程中最容易“堵车”和“漏水”的环节。在我过去几年的数仓开发生涯里最头疼的场景莫过于此业务产品经理拿着一份新鲜出炉的PRD产品需求文档过来说下个版本要上线一个新功能需要配套二十几个新的埋点事件。接下来就是一场漫长的“翻译”与“接力”赛。数据开发工程师需要从PRD里像考古一样挖掘出每个事件的业务含义、触发时机、上报参数然后将其“翻译”成一份技术侧的埋点采集方案文档。这份文档会流转给客户端或服务端的开发同学去实现代码埋点。等版本上线后数仓团队再根据这份采集方案去编写数据清洗ETL任务将原始的、杂乱的埋点日志处理成结构化的、可供分析的数据表。整个流程冗长、沟通成本极高任何一个环节的理解偏差或延迟都会导致数据链路断裂或数据质量低下。更糟糕的是这些散落在各处、格式不一的文档PRD、采集方案、ETL脚本注释最终都变成了难以追溯和复用的“沉默资产”。直到我们团队遇到了Hermes Agent并决定以其为核心对我们那套陈旧的工作流进行一场彻底的重构。这次重构的目标非常明确将非结构化的、依赖人工传递的“埋点需求”转变为可管理、可执行、可溯源的“规则资产”从而打通从需求提出到数据产出的全链路自动化。这不仅仅是一个工具的更替更是一次数据生产理念的升级。2. 解构旧流程埋点数据生产的四大核心痛点在引入新方案之前我们必须先清晰地诊断旧有工作流的病症。传统的“埋点需求-数仓ETL”流程通常存在以下几个难以根治的痛点### 2.1 需求与实现的“语义鸿沟”业务方口中的“用户点击了加入购物车按钮”在数据世界里需要被精确地定义为事件名event_name、事件属性properties如商品ID、SKU、来源页面等、用户属性user_properties、以及触发时机是点击即上报还是页面离开时上报。这个“翻译”过程极度依赖数据开发人员的经验和对业务的理解没有标准化的模板极易产生歧义。今天A同学定义的“cart_add”事件明天B同学可能就写成了“add_to_cart”下游的ETL任务就必须跟着改否则数据就无法关联。### 2.2 流程割裂与状态黑盒需求文档在Confluence采集方案在飞书文档ETL代码在GitLab任务调度在DolphinScheduler。一个埋点从需求到上线其状态分散在四五个不同的系统中。数据产品经理想了解“XX功能的埋点开发到哪一步了”需要挨个去问、去查。测试同学想验证上报的数据是否符合预期往往要等到版本上线后从线上日志里捞取样本反馈链路极其漫长。### 3.3 资产沉淀与复用困难一个成熟的电商App其埋点事件可能多达上万个。哪些事件已经废弃哪些事件属性含义发生过变更某个核心转化漏斗由哪几个事件构成这些问题在文档堆里很难快速找到答案。每次类似的新功能上线开发人员都需要从头开始设计埋点无法有效复用历史经验造成了大量重复劳动。### 3.4 变更的蝴蝶效应这是最令人恐惧的一点。业务方提出“我们想把‘收藏’按钮的颜色从灰色改成红色顺便改个交互动效。” 这看似只是一个前端改动。但如果这个改动影响了按钮的点击上报逻辑比如从onClick改为了onTouchEnd而前端同学修改时没有同步更新埋点方案或者数仓同学没有及时获知这一变更那么接下来的一整天你可能会看到“收藏率”这个核心指标断崖式下跌然后整个团队开始焦头烂额地排查问题。正是这些痛点促使我们去寻找一个能将“需求”、“规则”、“执行”三者统一起来的解决方案。而Hermes Agent一个设计精巧的、面向流程自动化的智能体框架进入了我们的视野。它的“智能体”Agent、“工具”Tool、“工作流”Workflow核心概念与我们想要构建的“规则驱动”的数据生产流在理念上不谋而合。3. Hermes Agent 核心架构与数据工作流的契合点在决定采用 Hermes Agent 之前我们对其架构进行了深入的评估。它不是一个大而全的数据平台而是一个高度灵活、可编排的“智能体”执行框架。这正是我们需要的——一个轻量的、可嵌入现有数据技术栈的“流程引擎”。### 3.1 智能体Agent作为“需求解析器”与“任务执行器”在Hermes的语境下一个Agent是一个具备特定能力的执行单元。在我们的新工作流设计中我们创建了多个专职Agent需求解析Agent它的任务是读取自然语言或半结构化的埋点需求文档例如一份Markdown格式的PRD片段利用其内置的或我们微调的大语言模型LLM能力将其解析并结构化为一套预定义的“埋点事件规则”对象。这个对象包含了事件名、属性列表名称、类型、示例值、业务描述、触发条件等所有关键信息。规则校验Agent它接收解析后的规则对象与历史规则库进行比对检查事件名是否冲突、属性定义是否与已有标准一致、必填项是否缺失等确保规则的规范性和一致性。ETL代码生成Agent这是核心的生产力工具。它根据校验通过的规则对象结合我们预先定义的Flink SQL或Spark SQL模板自动生成数据清洗任务的SQL代码。例如一条“页面浏览”事件的规则可以自动生成从Kafka原始日志主题中过滤、解析、字段标准化并写入ODS层操作数据层Hive表的完整SQL。### 3.2 工具Tool作为连接现有系统的“适配器”Agent的能力通过Tool来扩展。我们为数据开发生态中的各个系统开发了对应的ToolGitLab ToolAgent可以调用此工具将生成的ETL代码提交到指定的Git仓库并创建Merge Request。调度系统Tool如DolphinScheduler/Airflow自动在调度平台上创建或更新对应的作业Job并配置好依赖关系、调度周期和告警策略。消息通知Tool如钉钉/企微在关键节点如规则解析完成、代码已提交、任务上线成功自动发送通知到相关协作群。元数据管理Tool将新生成的埋点规则作为资产注册到公司的数据地图或元数据中心自动打上标签、建立血缘。### 3.3 工作流Workflow串联全链路单个Agent能力有限但通过Workflow将它们像乐高积木一样串联起来就形成了强大的自动化流水线。我们设计了一个名为DataPoint_Onboarding的主工作流其执行步骤清晰如下触发业务人员在特定的需求管理界面我们简单封装了一个Webhook提交或更新一份埋点需求文档。解析需求解析Agent启动解析文档输出结构化的规则草案。校验与确认规则校验Agent对草案进行合规性检查并将结果含差异对比通过消息通知Tool发送给负责的数据开发人员进行人工确认或修正。确认后的规则成为“已审核规则资产”。代码生成与提交ETL代码生成Agent根据“已审核规则资产”生成SQL代码随后通过GitLab Tool提交至代码库。任务部署调度系统Tool根据代码库中的新文件在调度平台创建任务。资产注册元数据管理Tool将最终的规则、生成的表、任务ID等信息全部关联注册到元数据中心。闭环通知工作流结束时向需求提出者和数据团队发送完成通知并附上所有相关链接Git MR、调度任务链接、元数据页面。这个工作流一旦配置完成就可以7x24小时无人值守地运行。它将原本需要多人日协作的流程压缩到了分钟级并且每一步都有迹可循。注意这里的工作流Workflow指的是Hermes Agent框架内定义的、由多个步骤Step组成的自动化流程与“工作流引擎”如Flowable、Camunda或“低代码工作流平台”如n8n、Dify是不同层次的概念。我们利用的是Hermes Agent的流程编排能力来定制我们的业务流水线。4. 从零到一基于Hermes Agent重构数仓工作流的实操指南理论很美好但落地过程充满了细节。下面我将分享我们团队从零开始搭建这套系统的关键步骤和踩过的坑。### 4.1 环境准备与Hermes Agent部署首先你需要一个可以运行Hermes Agent的环境。官方提供了多种部署方式对于企业级应用我们推荐使用Docker-Compose或Kubernetes部署。# 假设使用docker-compose部署 git clone hermes-agent-git-repo cd hermes-agent/deploy/docker-compose # 仔细修改 docker-compose.yml 中的配置特别是数据库连接、API密钥管理等 vim docker-compose.yml docker-compose up -d部署完成后你会获得一个Hermes Agent的服务端通常包含API Server和前端界面以及一个或多个工作节点Worker。工作节点是实际执行Agent和Tool的地方。### 4.2 定义核心数据模型“埋点规则资产”这是整个系统的基石。你必须设计一个清晰、可扩展的规则数据模型。我们使用的是JSON Schema来定义它既能被程序解析也具备良好的可读性。{ $schema: http://json-schema.org/draft-07/schema#, title: TrackingEventRule, type: object, properties: { event_id: { type: string, description: 事件唯一标识如 product_view }, event_name: { type: string, description: 事件显示名称如 商品详情页浏览 }, description: { type: string, description: 业务描述 }, platform: { type: array, items: { type: string, enum: [iOS, Android, Web, Server] } }, trigger_scene: { type: string, description: 触发场景描述 }, properties: { type: array, items: { type: object, properties: { key: { type: string }, type: { type: string, enum: [string, int, float, bool, array, object] }, required: { type: boolean }, sample_value: { type: string }, biz_desc: { type: string } }, required: [key, type] } }, status: { type: string, enum: [draft, reviewed, implemented, deprecated] }, creator: { type: string }, create_time: { type: string, format: date-time } }, required: [event_id, event_name, platform] }这个模型文件会被需求解析Agent作为输出目标也被规则校验Agent作为校验依据。### 4.3 开发自定义Tool以GitLab Tool为例Hermes Agent支持Python开发自定义Tool。一个Tool本质上是一个类需要实现execute方法。以下是连接GitLab提交代码的Tool简化示例from hermes.agent.tool import BaseTool from gitlab import Gitlab import os class GitLabCommitTool(BaseTool): name “gitlab_commit” description “Commit generated SQL files to a specified GitLab repository and create a Merge Request.” def __init__(self): # 从环境变量或配置中心读取敏感信息 self.gitlab_url os.getenv(‘GITLAB_URL’) self.private_token os.getenv(‘GITLAB_PRIVATE_TOKEN’) self.client Gitlab(self.gitlab_url, private_tokenself.private_token) async def execute(self, project_id: int, branch_name: str, commit_message: str, files: dict, target_branch: str “main”): “”” :param project_id: GitLab项目ID :param branch_name: 要创建和提交的分支名 :param commit_message: 提交信息 :param files: 字典key为文件路径value为文件内容 :param target_branch: 目标合并分支默认为main “”” try: project self.client.projects.get(project_id) # 1. 创建新分支如果不存在 try: branch project.branches.get(branch_name) except: branch project.branches.create({‘branch’: branch_name, ‘ref’: target_branch}) # 2. 逐个创建或更新文件 for file_path, content in files.items(): # 这里需要处理文件可能已存在的情况使用update或create try: f project.files.get(file_path, refbranch_name) # 更新文件 f.content content f.save(branchbranch_name, commit_messagecommit_message) except: # 创建新文件 project.files.create({ ‘file_path’: file_path, ‘branch’: branch_name, ‘content’: content, ‘commit_message’: commit_message }) # 3. 创建合并请求MR mr project.mergerequests.create({ ‘source_branch’: branch_name, ‘target_branch’: target_branch, ‘title’: f’[Auto] Add ETL for tracking event: {commit_message}’, ‘description’: ‘This MR is automatically created by Hermes Agent Data Pipeline.’ }) return {“status”: “success”, “mr_url”: mr.web_url, “branch”: branch_name} except Exception as e: return {“status”: “error”, “message”: str(e)}开发完成后需要将这个Tool注册到Hermes Agent的服务端这样Agent在编排时就能调用它了。### 4.4 编排核心工作流Workflow这是最体现业务逻辑的部分。在Hermes Agent的前端或通过API你可以可视化地拖拽编排Workflow。我们的DataPoint_Onboarding工作流的核心节点包括HTTP Trigger Node接收Webhook请求提取需求文档内容。Python Agent Node (需求解析)配置为调用需求解析Agent输入是文档内容输出是规则JSON。Condition Node判断解析是否成功失败则跳转到错误处理节点发送告警。Python Agent Node (规则校验)调用规则校验Agent并与规则库交互。Human Approval Node可选但推荐插入一个人工确认环节将校验后的规则发送给指定的数据负责人审批。Hermes支持通过邮件或集成的IM工具发送审批任务。Python Agent Node (代码生成)调用ETL代码生成Agent输入是审批后的规则输出是SQL文件内容字典。Custom Tool Node (GitLab提交)调用我们开发的GitLabCommitTool传入上一步生成的文件。Custom Tool Node (调度任务创建)调用调度系统Tool。Custom Tool Node (元数据注册)调用元数据管理Tool。Notification Node调用消息通知Tool发送成功报告。每个节点之间的数据通过上下文Context传递。你需要仔细设计每个节点的输入输出数据结构确保上下游能无缝对接。5. 重构后的价值与未来展望规则资产驱动的数据治理这套系统上线运行半年后带来的变化是实实在在的效率提升埋点数据接入的平均周期从3-5个工作日缩短到2小时内其中大部分时间是留给业务方确认规则的人工等待时间。质量保障规则冲突、字段不一致等问题在流程早期解析和校验环节就被拦截线上数据故障率下降了约70%。资产沉淀所有历史埋点规则都被结构化地存储在数据库中并附带完整的变更历史和血缘关系。新同学 onboarding 时可以快速查询和理解现有数据体系。流程透明每个埋点需求的状态待解析、待确认、代码已生成、已上线在Hermes的仪表盘上一目了然再也不用在多个系统间反复横跳。当然这套系统并非银弹它也有其适用边界和维护成本。例如对于极其复杂、非标准的埋点逻辑如涉及多个页面状态判断的自动化生成的代码可能仍需人工微调。此外维护一套稳定的Agent和Tool对团队的工程能力有一定要求。我个人在实际操作中的体会是这套系统的最大价值不在于“替代人”而在于“规范事”。它强制所有参与者在一个标准化、结构化的框架内协作将模糊的自然语言需求转化为精确的、机器可读的规则。这本身就是一次深刻的数据治理实践。未来我们计划将这套“规则资产”的理念扩展到更广的数据领域比如数据质量规则将数据稽核规则如字段非空、值域检查、波动率监控也定义为可管理的资产并由Hermes Agent驱动其自动生成监控任务和告警。指标定义与管理将业务指标如GMV、DAU的计算逻辑也进行规则化、资产化实现指标口径的统一定义和自动化衍生。与LLM更深度结合让需求解析Agent能够直接与业务产品经理对话通过多轮问答澄清模糊需求甚至主动提出埋点方案建议进一步降低沟通成本。从“埋点需求”到“规则资产”的转变是一个典型的用工程化思维解决数据生产瓶颈的案例。Hermes Agent作为一个灵活的自动化框架为我们提供了实现这一愿景的优秀“脚手架”。如果你也在为混乱的埋点流程和低效的数仓协作而苦恼不妨从设计一个最小的、核心的“埋点规则模型”开始尝试用自动化的方式连接起需求与实现的断点你会发现数据生产的流水线原来也可以如此顺畅。