跳转至

阿里数据研发 Harness Engineering：NL2SQL × Multi-Agent × 知识工程

Ch04.823 阿里数据研发 Harness Engineering：NL2SQL × Multi-Agent × 知识工程

📊 Level ⭐⭐⭐ | 10.3KB | entities/alibaba-data-rd-harness-engineering-nl2sql.md

阿里数据研发 Harness Engineering 实践

阿里技术团队在数据研发领域通过知识工程 + Harness Engineering 实现 NL2SQL 多 Agent 工作流，涵盖 7 Agent 协同、幻觉防控、心跳自迭代等完整工程化方案。

摘要

阿里技术团队在数据研发领域的 AI 化实践中，构建了一套从「自然语言 → DSL → SQL」的全链路多 Agent 工作流。核心思路是将数据研发专家的碎片化知识转化为结构化知识体系（知识工程），再通过 Harness Engineering 的工作流编排、Gate 审批、幻觉防控和心跳自迭代机制，让 AI 稳定可靠地完成数据研发任务。最终愿景是从「只做选择，不做配置」——数研同学从写代码的人转变为做设计的人。

核心要点

  • NL2DSL2SQL 路线：自然语言 → 标准化的指标-维度语义（DSL）→ SQL。语义层解决自然语言中缺少关键信息的问题，是准确度的核心保障。
  • 7 Agent 多 Agent 工作流：顺序协作 + 反馈循环组合。Agent 设计包括老架（需求分析）→ 小需（SPEC）→ 老架审核 → 小语（资产盘点）→ 老架（技术方案）→ ... 关键节点设人工 Gate 审批，「AI 做执行，人做决策」。
  • 三层知识架构：方法论层（Spec/Plan/Task）→ 协作机制（文档状态机 + 人工校验飞轮）→ 执行原则（经验初始化，持续优化）。核心原则是「文档即接口」，研发即沉淀。
  • 幻觉防控三策略：技能幻觉检测 Hook（执行后对比声称结果与实际状态）、执行结果强制校验（可验证产物）、日志必看原则（每个操作检查是否真正更新）。
  • 心跳机制（三层自迭代）：执行监控 → 模式识别（反复问题）→ 自动优化（Prompt/知识库/参数调整）。核心闭环：人对 Agent 行为的修正自动写回知识库和配置，实现「以 Agent 养 Agent」。

深度分析

数据研发领域特有的挑战

与传统软件工程不同，数据研发的知识高度碎片化——每个业务域都有自己的指标定义、维度体系和计算逻辑。阿里团队调研发现，各业务垂直方案虽然效果出色但缺少标准化接口，其他业务接入只能发挥约 30% 能力。这意味着 NL2SQL 的准确度强依赖语义层质量，而不同团队的语义组织方案各异。Harness Engineering 在这里的作用不仅是「让 AI 运行」，更是「让知识可复用」。

DSL 作为语义约束层

NL2DSL2SQL 路线的关键洞察是：自然语言到 SQL 的直接映射缺少关键信息（如指标的业务含义、维度的取值范围）。插入 DSL 层作为标准化的语义桥梁，让自然语言先被翻译为结构化的指标-维度语义，再据此生成 SQL。这与 Beautiful Article 的 Reacticle 协议有异曲同工之妙——都通过在输入和输出之间插入一个受约束的中间表示层，来提升 AI 输出的可控性和准确性。

Harness vs CI/CD Pipeline 的核心区别

团队明确指出与传统 CI/CD Pipeline 的核心区别：Harness 需处理 AI 的不确定性——AI 的每个步骤都可能产生意料之外的输出。CI/CD Pipeline 的每一步是确定性的（编译要么成功要么失败），而 Harness 的每一步都需要应对 AI 的幻觉、理解偏差和创造力溢出。因此 Gate 机制、反馈循环和人工审批点成为必要组件。

以 Agent 养 Agent 的自我迭代闭环

心跳机制是这套系统中最具前瞻性的设计。它不只是监控 Agent 的健康状态，更重要的是将「人对 Agent 行为的修正」自动写回知识库和配置——这意味着系统越用越聪明。当人工修正了一个 SQL 生成错误，修正方案自动沉淀为知识条目，后续的 Agent 自动受益。这是「以 Agent 养 Agent」的具体实现，也是知识工程从「一次性建设」走向「持续进化」的关键机制。

工作空间隔离与配置治理

团队实践了独立 Workspace（~/.openclaw/workspace/{project_name}/）、命名规范（{domain}_{date}_{seq}）和 MCP/Skill 加载路径优先级控制（子 Agent workspace → 全局 fallback）。这些工程细节虽不引人注目，却是多 Agent 系统稳定运行的基石——没有空间隔离，Agent 之间的文件冲突和配置污染会快速压垮系统。

实践启示

  1. DSL 中间层是 NL2SQL 准确度的关键：不要试图让 AI 直接从自然语言生成 SQL。插入一个结构化的 DSL 语义层（指标-维度模型），让 AI 先做「理解翻译」，再做「代码生成」，准确率显著提升。
  2. 文档状态机是协作的基石：「文档即接口」——让 Agent 之间的协作通过结构化文档传递，而不是通过共享内存或轮询。每份文档有明确的 owner、状态和验收标准，这降低了多 Agent 系统的耦合度。
  3. 幻觉检测需要分层策略：单靠 prompt 约束不足以防止幻觉。阿里实践的三层策略（技能检测 Hook → 执行结果校验 → 日志审计）是可复用的参考模式，尤其「对比声称结果与实际状态」是性价比最高的检测手段。
  4. 人以 Agent 养 Agent 是长期竞争力的来源：投入建设知识库和配置的自动沉淀机制，让每次人工修正都变成系统的「训练数据」，这是 AI 系统性能持续提升的飞轮。
  5. 空间隔离不是可选项而是必需品：在多人多 Agent 协作环境中，工作空间隔离和命名规范是防止「Agent 间串扰」的最基本工程手段。在项目启动时就建立，比事后修复代价小得多。

相关实体

第 2 来源 — 1688数据中心 Multi-Agent 研发小队实录

来自 1688 数据中心的实践报告延续了阿里数据研发 Harness Engineering 框架，提供了 KST 三层分治架构的具体实现、语义资产冷启动的量化数据，以及研发飞轮的组织化协作方案。

核心增量

  1. KST 三层架构的完整定义（K 层领域知识 → S 层行为规范 → T 层工作流配置）：K 层涵盖业务规则库、元数据知识库、SQL 规范库、Multi-Agent 配置、Skill 原子能力、经验沉淀库六大资产类型，其中经验沉淀库的 24 条 SQL CR 记录是从真实代码审查中自动沉淀的 Bad Case。S 层定义 NL2SQL 流水线中每个节点的输入/输出/验收标准，以 Spec 契约替代"跑一次看运气"。T 层定义"顺序协作 + 反馈循环"组合，最多循环 3 次。

  2. 语义资产冷启动方案：以 Agent 扫描 SQL 脚本、DataWorks 节点、报表、钉钉文档自动抽取知识草稿 → 语义资产审核 Agent review → 审核通过注册到 K 层知识库 → 消费过程复盘提高质量。200+ 指标从手工数周缩短至 Agent 数小时。基于分销域知识库的实际结果：13 个规则文件、40+ 表描述文件、1 本 SQL 编码规范手册，Agent 扫描约 2 小时产出初稿。但承认 20% 的"潜规则"仍需依赖人工发现沉淀。

  3. Manifest 核心五问：团队用 5 个根问题直接定义研发飞轮——协作入口在哪、人机验收标准怎么定、各阶段产物进哪、Agent 行为怎么约定、Team Skill 怎么持续迭代。这五个问题的答案直接驱动 KST 三层和 Harness 工作流的形式化设计。

  4. Agent 组织化协作平台：研发小队 Fork 模式 + 使用过程数据自动回流。每个人从超级个体的本地 Agent 走向超级组织——知识在团队内复用，使用中产生的新知识自动写回知识库。愿景是"只做选择，不做配置"。

  5. 人机工程 Gate 设计哲学：坚持人工审批卡点是因为"Multi-Agent 工作流很难一步到位，关键节点让人来兜底"，随着知识库变厚逐步减少人工介入。这比全自动化多 Agent 方案更务实。

→ 第 2 来源原文存档

→ 原文存档