从 Coder 到 Designer：电商团队如何通过知识工程与 AI 管控框架，解决数据研发的碎片化难题，实现效率跃迁。
核心内容：
1. 数据研发面临的核心痛点：知识碎片化与流程非标准化
2. 解决方案的双引擎：知识工程与 Harness Engineering 架构
3. NL2SQL提效实践中的语义层建设与挑战应对

这是2026年的第 36 篇文章

（ 本文阅读时间：约 20 分钟 ）

01

项目背景

我们团队今年在 AI Data 方向共有两个命题，一个是「数据研发效率提升」，另一个是「数据价值交付」，在项目启动之初，我们面向集团内外都做了深刻的调研，公司内 AI Data 方向的建设主要是在单点提效 Agent、NL2SQL、ChatBI 数据分析这几个方向，而且大多都是在垂直领域取得了不错的效果，但是难以推广为通用方案进行应用。在这个过程中，我们发现两个共性问题：

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

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

问题的本质在于“数据研发的知识是碎片化的，流程是非标准化的”。 每个数研同学脑中都有一套「怎么做」的经验，但这些经验难以被复用、被传承、被 AI 理解。基于这些认知，我们深刻思考了数研工作范式升级需要通过 「 知识工程的构建」和「Harness Engineering」架构设计来实现。

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

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

02

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

语义层是 NL2SQL 的核心基础设施。它解决的是 NL2SQL 中最关键的一步：从自然语言到精确的数据语义的映射。「自然语言直接转 SQL」的成功率很难高，原因很直白：自然语言里缺少太多关键信息。因此我们引入「语义层」，走 NL2DSL2SQL 的路线：先将自然语言映射到标准化的指标-维度语义，再从语义生成 SQL。

语义层建设面临两大核心挑战：指标命名混乱影响AI效能、数据资产在使用过程中会持续劣化。针对此前存在的指标歧义问题，我们目前采用的是先治理再录入的原则，由核心的数研专家同学负责核心指标资产的数据建模和注册，后续注册指标中心的语义资产都需要经过他们的确认才能录入，后续我们计划通过「标准名称+别名映射+语义边界」规范体系，系统性解决「成交金额/GMV/交易额」等同义词混用、「活跃商家/有效商家」等近义词混淆导致的RAG召回偏差和AI出码错误。同时构建资产防腐双循环机制——上线前由数仓小组拦截语义重复资产，上线后通过定期资产健康度评估，动态清理冗余资产等动作来保证语义资产层的质量。

我们将 multi-agent 体系进行了升级，基于智能体实现工程能力串联，完成生产级数研方案交付，工作流采用顺序协作模式和反馈循环模式的组合（核心节点人工干预）完成整体的需求交付工程串联：

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

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

这套方案的核心在于「知识工程的搭建」和「Harness Engineering」的架构方案，下面针对这两个部分的实现进行重点介绍说明。

03

在数据研发场景下，如果我们都讲不清楚需求是什么、能提供的数据资产有哪些，AI 肯定无法完成我们的诉求。知识工程的核心是将数研专家的「数据研发思路和经验」转化为 LLM 易于理解的结构化知识。这需要建设一套完整的知识体系，让 AI 在执行每一步时都能准确地检索和引用正确的知识；要求构建包含专业术语（语义层）、方法论（Spec/Plan/Task知识结构）及协作规范的三层架构：

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

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

3. 执行原则：基于数研经验初始化知识体系，并通过需求调试持续优化。NL2SQL能力栈遵循"文档驱动研发+持续自迭代"原则，计划于4月底接入生产环境。

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

需求如何交付 

我们设计了一个三层的质量保障架构，让复杂的数据研发流程更靠谱、更高效。这三层体系就像三道安全网，既保证了研发质量稳定，又能让团队越干越熟练，效率自然就提上来了。

第一层流程标准化：有点像搭积木。通过配置文件和技能清单把常用流程固定下来，这样大家做事有章可循，效率自然就上去了。

第二层质量把关：我们用详细的技术规范+人工复核，就像给AI加上双重保险，既能规范输入输出，又能及时发现那些容易出错的地方，最大限度避免AI「脑补」出问题。

第三层是知识管理：平时工作中积累的业务经验和调优方案都会被系统化沉淀下来，慢慢就形成了一套可复用的知识库，相当于给团队打造了一个「经验宝库」。

经验如何消费

知识工程最重要的是「知识是否在持续生长」。我们设计的闭环机制确保每一次研发过程本身就是一次知识生产过程。

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

2.  从「人可用」到「AI可食」的转型。 传统的数据资产是为人设计的 —— 人能看懂就行。但 AI 需要的是严格结构化、语义明确、可机器检索的资产格式。这要求我们在资产维护时，不仅定义「这个指标是什么」，还要定义「这个指标的 DWD 表达式是什么」「它依赖哪些上游表」「它的计算结果取值范围是什么」。

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

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

04

什么是 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 自己更新配置文件，下次执行时自动包含这些步骤。通过人对大模型的反馈，实现大模型的「经验升级」。

05

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

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

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

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

知识工程方向：

• 业务语义的持续补充，边做需求边沉淀，实现"研发即沉淀"的常态化

• 指标智能推荐和口径冲突预警功能上线，提升资产准确度

• SQL 研发规范的精细化，包含字段命名、表命名等团队定制规范

• DSL 协议升级，灵活支撑更复杂的需求场景

Harness Engineering 方向：

• 幻觉防控自动化：从"人工看日志"升级为自动化的技能幻觉检测 Hook

• 可观测性提升：全链路执行指标埋点上线，支持 ELK/Grafana 分析

• 心跳机制的初步实现：Agent 基于执行历史自动识别问题模式并生成优化建议

• 配置治理标准化：自动化 Git 备份和 agents.md 同步机制落地

ChatBI 建设：

• 知数平台集成 NL2SQL 工作台

• 在 R2C 基础上叠加 BI 可视化能力，支持基础的数据分析问答

• 利用 NL2SQL 沉淀的 SQL 模板作为 ChatBI 的 Few-shot 素材

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

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

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

06

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

登录查看剩余 70% 内容