从 Coder 到 Designer：电商团队数据研发的 Harness Engineering 实践

从 Coder 到 Designer：电商团队如何通过知识工程与 AI 管控框架，解决数据研发的碎片化难题，实现效率跃迁

在数据研发领域，知识碎片化与流程非标准化一直是团队效率提升的核心障碍。每个数研同学脑中都有独特的“怎么做”经验，但这些经验难以被复用、被传承，更难以被 AI 理解。本文基于一个电商团队的实践，深入解析如何通过知识工程与Harness Engineering（AI 管控框架）双引擎，构建 NL2SQL 提效方案，实现从“代码编写者”到“设计决策者”的角色转变。

一、数据研发的核心痛点：知识碎片化与流程非标准化

团队在项目启动前进行了深入调研，发现集团内 AI Data 方向的建设集中在单点提效 Agent、NL2SQL、ChatBI 数据分析等方向，虽然垂直领域效果不错，但难以推广为通用方案。两个共性问题尤为突出：

• 横向拓展能力不足
  ：已有平台能力针对各自业务效果出色，但缺少其他业务接入的标准化接口。其他业务接入时，由于业务特性不同，只能发挥约 30% 的能力。

• 数据资产沉淀不足
  ：NL2SQL 的准确度强依赖于语义层的数据资产质量，而不同团队有着各自不同的语义组织方案，缺乏统一标准。

问题的本质在于“数据研发的知识是碎片化的，流程是非标准化的”。每个数研同学脑中都有一套「怎么做」的经验，但这些经验难以被复用、被传承、被 AI 理解。

二、解决方案的双引擎：知识工程与 Harness Engineering

基于上述认知，团队提出数据研发工作范式升级的两大支柱：

• 知识工程（Knowledge Engineering）
  ：解决「AI 凭什么能做对」的问题。将数研专家的经验、业务规则、数据资产转化为 LLM 可理解的结构化知识体系，让 AI「有据可依」。

• Harness Engineering（AI Agent 管控框架）
  ：解决「AI 如何稳定运行」的问题。为 AI 智能体构建系统化的管控框架，通过分离关注点、施加约束、管理上下文与熵值，确保 AI 在长程复杂任务中稳定、安全、可回溯地运行。

这两个引擎如同汽车的“导航系统”与“控制系统”，缺一不可。

三、项目全景：Multi-Agent 驱动的 NL2SQL 提效实践

团队复用兄弟团队 NL2SQL 约 60% 的已有能力，自建部分聚焦在业务域特有的：数据资产（表资产、指标资产、业务维度）、预定义 SQL 模板、业务语义知识库，以及对接业务 AI-Infra 基础能力。该方案已在大促场景完成落地，除资产维护成本外，整体 NL2SQL 研发效率大幅提升。

语义层：NL2SQL 的核心基础设施

语义层解决的是 NL2SQL 中最关键的一步：从自然语言到精确的数据语义的映射。“自然语言直接转 SQL”的成功率很难高，因为自然语言里缺少太多关键信息。因此团队引入“NL2DSL2SQL”路线：先将自然语言映射到标准化的指标-维度语义，再从语义生成 SQL。

语义层建设的两大核心挑战

• 指标命名混乱影响 AI 效能
  ：例如“成交金额/GMV/交易额”等同义词混用、“活跃商家/有效商家”等近义词混淆，导致 RAG 召回偏差和 AI 出码错误。

• 数据资产在使用过程中持续劣化
  ：新增指标重复、口径变化不及时更新等问题。

应对策略：采用“先治理再录入”原则，由核心数研专家负责指标资产的数据建模和注册，后续注册指标中心的语义资产需经其确认才能录入。同时构建资产防腐双循环机制——上线前由数仓小组拦截语义重复资产，上线后通过定期资产健康度评估动态清理冗余资产。

Multi-Agent 工作流：顺序协作与反馈循环

团队将 multi-agent 体系升级为 7 Agent 协同工作流，采用顺序协作模式和反馈循环模式的组合，并在核心节点设置人工干预 Gate：

• 顺序协作
  ：Agent 按照预定义顺序依次执行任务。例如“老架”启动需求分析后，“小需”完成 SPEC，“老架”审核后调度“小语”进行资产盘点，再由“老架”设计技术方案，形成严格的流水线。

• 反馈循环
  ：当下游 Agent 发现问题时，可回滚到上游环节。例如“小检”发现 SQL 质量问题，任务返回给“老架”决策是否需要“小需”重新生成。

这套方案的核心在于“知识工程的搭建”和“Harness Engineering”的架构方案，下面重点介绍这两个部分。

四、知识工程：让 AI「有据可依」

在数据研发场景下，如果连需求都讲不清楚、数据资产也无法提供，AI 必然无法完成任务。知识工程的核心是将数研专家的“数据研发思路和经验”转化为 LLM 易于理解的结构化知识。团队建设了一套包含三层架构的知识体系：

1. 方法论层
   ：通过 Spec 指导需求分析、Plan 规范技术方案、Task 定义执行标准，形成“文档即接口”的多 Agent 协同机制。各阶段文档既是输出成果，又是下一阶段输入，实现 SPEC→PLAN→SQL 的链式生成。

2. 协作机制
   ：采用文档状态机驱动 8 阶段研发流程，结合人工校验形成“需求经验沉淀-能力提升-效率提升”的飞轮效应。关键技术组件包括：AGENTS.md（记录协作规范）、Skills 引擎（执行核心操作）、Knowledge 库（沉淀研发经验）。

3. 执行原则
   ：基于数研经验初始化知识体系，并通过需求调试持续优化。NL2SQL 能力栈遵循“文档驱动研发+持续自迭代”原则。

该架构通过结构化知识沉淀（三层体系）、流程化协作约束（状态机）、经验化能力进化（飞轮效应），实现 AI 在数据研发场景中的可控执行与持续进化。

需求如何交付：三层质量保障架构

团队设计了一个三层质量保障架构，让复杂的数据研发流程更靠谱、更高效：

• 第一层：流程标准化
  ——通过配置文件和技能清单固定常用流程，让大家做事有章可循。

• 第二层：质量把关
  ——详细的技术规范+人工复核，给 AI 加上双重保险，避免 AI“脑补”出问题。

• 第三层：知识管理
  ——日常工作中积累的业务经验和调优方案被系统化沉淀，形成可复用的知识库。

经验如何消费：研发即沉淀

知识工程最重要的是“知识是否在持续生长”。团队设计的闭环机制确保每一次研发过程本身就是一次知识生产过程：

1. 研发即沉淀
   ：每完成一个数据需求，过程中产出的 SPEC、PLAN、SQL、验证报告都自动归档到 Archival Memory。新增的指标定义自动进入语义资产库，踩过的坑记录到 anti-patterns.md。

2. 从“人可用”到“AI 可食”的转型
   ：传统数据资产为人设计，而 AI 需要严格结构化、语义明确、可机器检索的资产格式。例如不仅定义“这个指标是什么”，还要定义“这个指标的 DWD 表达式是什么”“它依赖哪些上游表”“它的计算结果取值范围是什么”。

3. 长期收益曲线
   ：资产维护初期投入较大，但这是一次性建设成本。随着资产持续积累，后续研发效率持续提升，线上运维越来越轻松。更重要的是，当团队人员离职或跨业务 backup 时，沉淀的知识资产不会随人离开。

目前这套方案通过定时任务调度需求过程澄清日志和复盘，将每个需求研发的过程经验进行沉淀。通用经验被沉淀到 Agent 的核心配置文件中，不同业务域的经验则沉淀在不同业务域的目录下，按照后续的需求类型动态渐进式加载业务域知识。

五、Harness Engineering：让 AI「稳定可控」

什么是 Harness Design

当模型能力不再是瓶颈，决定 AI 智能体性能上限的，是围绕模型构建的整套外部系统。Harness Design（管控框架设计）的核心目标不是让模型变得更聪明，而是确保 AI 在复杂任务中稳定、安全、可回溯地运行，并持续产出高质量结果。通过结构化控制而非算法优化，保障智能体在动态环境中的可靠性与结果可解释性。

Harness Engineering 通过以下手段实现管控：

• 分离关注点
  ：将“决策”与“执行”分离，将“知识检索”与“代码生成”分离，每个 Agent 只负责自己擅长的事。

• 施加约束
  ：通过 Gate 机制、规范校验、强制审批等手段，限制 AI 的自由度。

• 管理上下文
  ：控制每个 Agent 的信息输入量，避免上下文过载导致的质量下降。

• 管理熵值
  ：在长程任务中，AI 的行为不确定性会随时间累积（熵增）。Harness 的作用就是持续“整理”和“矫正”，防止行为漂移。

与传统 CI/CD Pipeline 相比，Harness Engineering 需要额外处理的核心挑战是AI 的不确定性。传统 Pipeline 中的每个步骤是确定性的，而 AI Agent 的每个步骤都可能产生意料之外的输出。Harness 的设计就是为了在这种不确定性中建立秩序。

Multi-Agent 编排架构

团队构建了一个 7 Agent 协同的工作流，采用顺序协作模式和反馈循环模式的组合，关键节点的人工 Gate 审批。AI 做执行，人做决策。在数据研发这种对准确性要求极高的场景中，完全自动化是不现实的，也是不负责任的。Gate 机制确保了关键决策点始终有人类参与。

• 顺序协作
  ：Agent 按照预定义的顺序依次执行任务。例如“老架”启动需求分析后，“小需”完成 SPEC，“老架”审核后调度“小语”进行资产盘点，再由“老架”设计技术方案，形成严格的流水线。

• 反馈循环
  ：当下游 Agent 发现问题时，可以回滚到上游环节。例如“小检”发现 SQL 质量问题，任务返回给“老架”决策是否需要“小需”重新生成。

稳定性工程（应对策略、空间隔离、配置治理）

稳定性是 Harness Engineering 最核心的设计目标。幻觉是 AI Agent 最危险的问题。实践中遇到的典型案例：子 Agent 使用 qwen 作为底层模型时，被要求查看官方文档核对配置方案。官方文档读取失败，但 Agent 报告“检查通过”，这就是模型幻觉——Agent 声称完成了任务，但实际上什么都没做。

应对策略

1. 技能幻觉检测 Hook
   ：在每次技能执行后，自动对比 Agent 声称的执行结果与实际的系统状态。如果 Agent 说“文件已创建”，就去检查文件是否真的存在；如果说“API 调用成功”，就校验返回值是否合理。

2. 执行结果强制校验
   ：所有子 Agent 的关键操作必须产出可验证的产物（文件、数据、状态变更）。仅凭 Agent 的文本回复不能作为任务完成的依据。

3. 日志必看原则
   ：养虾技巧中最重要的一条：一定要看日志。Agent 的每个操作都需要去检查配置或改动是否真正更新。调试完的工作流换模型或业务类型都要经过重新测评。

空间隔离

工作空间管理混乱是导致脏数据和重复需求失效的常见原因。团队建立了严格的隔离机制：

• 独立 Workspace
  ：每个子 Agent 项目的根目录必须为 ~/.openclaw/workspace/{project_name}/。主 Agent 启动时校验路径合法性，拒绝非法 project。

• 命名规范
  ：项目强制使用 {domain}_{date}_{seq} 格式命名（例：finance_20240520_01），创建前检查同名冲突。

• MCP/Skill 加载路径优先级
  ：子 Agent workspace/skills/ -> 子 Agent workspace/mcp/ -> 全局 fallback。禁用跨 workspace 加载，避免环境污染。

• 按需开放技能
  ：在子 Agent 目录下只开放必要的技能和服务，避免全量加载，节省 Token 消耗。

配置治理

配置文件是 Agent 系统的“生命线”。~/.openclaw/workspace 配置丢失可能导致整个工作流失效。

• 自动化 Git 备份
  ：每日定时执行配置备份（cd ~/.openclaw/workspace && git add . && git commit && git push），配置仓库托管在内部代码仓库。

• agents.md 同步机制
  ：配置变更后自动同步到 agents.md，确保定时任务和能力注册始终有效。按官方模板生成标准化配置文件，包含 project name、workspace path、skills list、timeout 等关键字段。

• 模板化重新配置
  ：当配置损坏时，可基于 Git 仓库中的备份和标准模板快速恢复，而不是从零重新配置。

自动化自我迭代：心跳机制

自动化自我迭代是 Harness Engineering 的高级目标。其核心思想是：Agent 不仅执行任务，还能从执行结果中学习，自动优化自身的行为。心跳机制包含三个层次：

1. 第一层：执行监控
   ——Agent 在运行过程中定期（心跳周期）回顾近期的执行历史，包括成功率、失败原因、用户修正记录等。这是最基础的健康检查。

2. 第二层：模式识别
   ——基于执行历史数据，识别反复出现的问题模式。例如：某类指标的 RAG 召回准确率持续偏低，某个 SQL 模板的校验通过率不高，某个业务域的需求澄清环节返工率高。这些模式揭示了知识库或规则配置的薄弱环节。

3. 第三层：自动优化
   ——根据识别出的模式自动调整 Agent 行为：
   • 优化 Prompt 模板：如果某类任务成功率低，分析失败 case 并改进 Prompt 中的指导语。
   • 补充知识条目：如果 RAG 召回频繁 miss，自动生成知识条目建议，经人工确认后写入知识库。
   • 调整工作流参数：如果某个环节的超时率高，动态调整超时阈值和重试策略。

最关键的一点是：人工修正 Agent 行为时产生的反馈，会被自动捕获并写回到知识库和规则配置中。这实现了“以 Agent 养 Agent”：在执行过程中告诉 Agent 少了哪些步骤，Agent 自己更新配置文件，下次执行时自动包含这些步骤。通过人对大模型的反馈，实现大模型的“经验升级”。

六、演进方向与展望

近期：Multi-Agent 工作流落地

• 4 月 2 日开始 OpenClaw Multi-Agent 工作流联调，计划 4 月底开放给团队数研同学使用。

• 工作流验证
  ：在真实需求中验证 7 Agent 协同的端到端流程，重点关注 Gate 机制的实际效果和 Agent 间协作的稳定性。

• Spec 规范输出
  ：输出《Spec 研发规范 V0.5》，包含 Excel 需求模板、指标拆分规则、数据建模契约、校验规则。

• 知识库冷启动
  ：完成各业务域的基础资产沉淀，建立指标命名规范和资产防腐化流程。

中期：知识工程与 Harness 成熟化

• 业务语义的持续补充，边做需求边沉淀，实现“研发即沉淀”的常态化。
• 指标智能推荐和口径冲突预警功能上线，提升资产准确度。
• SQL 研发规范的精细化，包含字段命名、表命名等团队定制规范。
• DSL 协议升级，灵活支撑更复杂的需求场景。

• 幻觉防控自动化：从“人工看日志”升级为自动化的技能幻觉检测 Hook。
• 可观测性提升：全链路执行指标埋点上线，支持 ELK/Grafana 分析。
• 心跳机制的初步实现：Agent 基于执行历史自动识别问题模式并生成优化建议。
• 配置治理标准化：自动化 Git 备份和 agents.md 同步机制落地。

• 知数平台集成 NL2SQL 工作台。
• 在 R2C 基础上叠加 BI 可视化能力，支持基础的数据分析问答。
• 利用 NL2SQL 沉淀的 SQL 模板作为 ChatBI 的 Few-shot 素材。

长期愿景：AI 的经验升级与知识复用

• 经验升级的闭环
  ：通过 Harness Engineering 的心跳机制和知识工程的沉淀机制，构建“执行 -> 评估 -> 优化 -> 再执行”的持续进化循环。每一次人对大模型行为的修正，都不应该是“一次性的纠偏”，而应该自动转化为知识库中的永久条目或规则配置中的约束更新。AI 的能力随使用而增长，而不是停留在初始状态。

• 从单团队到跨团队的知识复用
  ：数据团队沉淀的知识体系和 Harness 框架，其设计本身就是面向可复用的。语义层的分层设计（业务规则库、元数据知识库、SQL 规范库）可以在保留核心架构的同时，替换业务域特有的知识内容。其他团队接入时，只需要完成自身业务域的资产建设，就能复用整套工作流和管控框架。

• 研发范式的根本转变
  ：最终的愿景是实现“只做选择，不做配置”的理想画面。数研同学的角色从“写代码的人”转变为“做设计的人”：人专注于需求理解、方案选型、质量决策，AI 负责资产检索、代码生成、环境部署、数据验证等一切可自动化的执行工作。知识工程确保 AI“做对事”，Harness Engineering 确保 AI“稳定做事”，两者协同构成数据研发 AI 化的完整技术底座。

七、项目总结

AI 在数据研发领域的落地，不是一个模型能力问题，而是一个工程化问题。知识工程解决「AI 凭什么能做对」，Harness Engineering 解决「AI 如何稳定运行」，两者缺一不可。从 NL2SQL 到 ChatBI 的延伸，则将这套能力从“服务数研同学”拓展到“服务业务用户”，实现数据价值的全链路交付。在这个过程中，知识不断沉淀、Agent 持续进化、工程框架日趋稳健——这才是 AI + 数据研发的可持续发展路径。

欢迎留言一起参与讨论~