这是 2026 年的第 36 篇文章（本文阅读时间：约 20 分钟）
01 项目背景
团队今年在 AI Data 方向聚焦两大命题：“数据研发效率提升”与“数据价值交付”。调研显示，集团内现有建设多集中于单点提效 Agent、NL2SQL 及 ChatBI 等垂直领域，虽效果显著但难以推广为通用方案。主要存在两大共性问题：
- 横向拓展能力不足：已有平台缺乏标准化接口，其他业务接入时因特性差异，仅能发挥约 30% 的能力。
- 数据资产沉淀不足：NL2SQL 准确度强依赖语义层质量，而各团队语义组织方案不一，缺乏统一标准。
问题本质在于“数据研发知识碎片化、流程非标准化”。专家经验难以被复用、传承或被 AI 理解。为此，我们提出通过「知识工程构建」和「Harness Engineering 架构设计」实现数研工作范式升级：
- 知识工程（Knowledge Engineering）：解决"AI 凭什么能做对”。将专家经验、业务规则及数据资产转化为 LLM 可理解的结构化知识体系。
- Harness Engineering（AI Agent 管控框架）：解决"AI 如何稳定运行”。构建系统化管控框架，通过分离关注点、施加约束及管理上下文，确保 AI 在长程复杂任务中稳定、安全、可回溯地运行。
02 项目全景：Multi-Agent 驱动的 NL2SQL 提效实践
基于调研结论，我们复用兄弟团队约 60% 的 NL2SQL 能力，自建部分聚焦于业务域特有的数据资产（表、指标、维度）、预定义 SQL 模板及业务语义知识库，并对接业务 AI-Infra 基础能力。该方案已在大促场景落地，显著提升了 NL2SQL 研发效率。
语义层是 NL2SQL 的核心基础设施，旨在解决从自然语言到精确数据语义的映射难题。鉴于“自然语言直接转 SQL"成功率低，我们引入语义层，采用NL2DSL2SQL路线：先将自然语言映射到标准化的指标 - 维度语义，再生成 SQL。
针对指标命名混乱及资产劣化两大挑战，我们采取“先治理再录入”原则，由核心专家负责建模注册，并计划通过“标准名称 + 别名映射 + 语义边界”规范体系，系统性解决同义词混用导致的 RAG 召回偏差。同时构建资产防腐双循环机制：上线前拦截重复资产，上线后定期评估清理，确保持续高质量。
我们将 Multi-Agent 体系升级，基于智能体串联工程能力，采用顺序协作与反馈循环组合模式（核心节点人工干预）完成交付：
- 顺序协作：Agent 按预定义顺序执行。如：老架启动分析→小需完成 SPEC→老架审核→小语盘点资产→老架设计方案，形成严格流水线。
- 反馈循环：下游发现问题可回滚上游。如：小检发现 SQL 质量问题，任务返回老架决策是否重生成。
以下将重点介绍“知识工程搭建”与"Harness Engineering 架构”的具体实现。
03 知识工程：让 AI「有据可依」
知识工程的核心是将数研专家的“思路和经验”转化为 LLM 易于理解的结构化知识，构建包含专业术语、方法论及协作规范的三层架构：
- 方法论层：通过 Spec 指导需求、Plan 规范方案、Task 定义执行，形成“文档即接口”的多 Agent 协同机制，实现 SPEC→PLAN→SQL 链式生成。
- 协作机制：采用文档状态机驱动 8 阶段研发流程，结合人工校验形成飞轮效应。关键组件包括 AGENTS.md（协作规范）、Skills 引擎（核心操作）及 Knowledge 库（经验沉淀）。
- 执行原则：基于经验初始化知识体系，并通过需求调试持续优化，遵循“文档驱动研发 + 持续自迭代”原则。
该架构通过结构化沉淀、流程化约束及经验化进化，实现 AI 在数据研发中的可控执行与持续迭代。
需求交付保障
我们设计了三层质量保障架构，如同三道安全网：
- 第一层流程标准化：通过配置文件和技能清单固化常用流程，确保做事有章可循。
- 第二层质量把关：采用“技术规范 + 人工复核”双重保险，规范输入输出，避免 AI“脑补”出错。
- 第三层知识管理：系统化沉淀业务经验与调优方案，打造可复用的“经验宝库”。
经验消费与生长
知识工程的关键在于“知识是否持续生长”。我们设计的闭环机制确保每一次研发都是一次知识生产过程：
- 研发即沉淀：需求产出的 SPEC、PLAN、SQL 及验证报告自动归档；新增指标进入语义库；踩坑记录存入 anti-patterns.md。
- 从“人可用”到"AI 可食”：资产维护不仅定义“是什么”，还需明确"DWD 表达式”、“依赖关系”及“取值范围”，满足 AI 对严格结构化数据的需求。
- 长期收益曲线：初期投入较大，但随着资产积累，研发效率持续提升，且知识资产不随人员流动而流失。
目前方案通过定时任务调度澄清日志和复盘，将通用经验沉淀至核心配置，业务域经验动态加载，实现知识的渐进式积累。
04 Harness Engineering：让 AI「稳定可控」
什么是 Harness Design
当模型能力不再是瓶颈，决定 AI 性能上限的是外部系统。Harness Design 的核心不是让模型更聪明，而是通过结构化控制而非算法优化，确保 AI 在复杂任务中稳定、安全、可回溯地运行。其本质是一种工程架构设计，手段包括：
- 分离关注点：将决策与执行、检索与生成分离，各司其职。
- 施加约束：通过 Gate 机制、规范校验等手段限制 AI 自由度。
- 管理上下文：控制信息输入量，避免过载。
- 管理熵值：在长程任务中持续“整理”和“矫正”，防止行为漂移。
与传统 CI/CD 不同，Harness Engineering 需额外应对 AI 的不确定性，旨在不确定性中建立秩序。
Multi-Agent 编排架构
我们构建了 7 Agent 协同工作流，采用顺序协作与反馈循环组合，并在关键节点设置人工 Gate 审批，坚持"AI 做执行，人做决策”。
- 顺序协作：形成严格流水线，如老架启动→小需 SPEC→老架审核→小语盘点→老架设计。
- 反馈循环：下游发现问题可回滚上游，如小检发现 SQL 问题返回老架决策。
稳定性工程策略
幻觉是 AI Agent 最危险的问题。为应对模型声称完成任务实则未做的情况，我们采取以下策略：
- 技能幻觉检测 Hook：执行后自动对比声称结果与实际系统状态（如文件是否存在、API 返回值）。
- 执行结果强制校验：关键操作必须产出可验证产物，仅凭文本回复无效。
- 日志必看原则：检查每个操作的配置或改动是否真正更新，更换模型或业务类型需重新测评。
空间隔离：建立严格隔离机制，每个子 Agent 项目根目录独立，强制使用"{domain}_{date}_{seq}"命名格式，禁用跨 workspace 加载，按需开放技能以节省 Token。
配置治理：配置文件是系统生命线。实施自动化 Git 备份每日定时执行；配置变更自动同步至 agents.md；支持基于模板快速恢复损坏配置。
自动化自我迭代：心跳机制
Agent 不仅能执行任务，还能从结果中学习并自我优化。心跳机制包含三个层次：
- 执行监控：定期回顾执行历史、成功率及失败原因。
- 模式识别：识别反复出现的问题模式（如某类指标召回率低、某环节返工率高）。
- 自动优化：根据模式调整行为，包括优化 Prompt 模板、补充知识条目、调整工作流参数等。
最关键的是，人工修正行为的反馈会被自动捕获并写回知识库，实现“以 Agent 养 Agent”，推动大模型经验升级。
05 演进方向与展望
近期：Multi-Agent 工作流落地
4 月 2 日开启联调，计划 4 月底开放使用。重点包括：
- 工作流验证：在真实需求中验证 7 Agent 协同及 Gate 机制效果。
- Spec 规范输出：发布《Spec 研发规范 V0.5》，涵盖需求模板、拆分规则及校验规则。
- 知识库冷启动：完成基础资产沉淀，建立命名规范及防腐流程。
中期：知识工程与 Harness 成熟化
知识工程方向：常态化“研发即沉淀”；上线指标智能推荐与冲突预警；精细化 SQL 研发规范；升级 DSL 协议支撑复杂场景。
Harness Engineering 方向：升级为自动化技能幻觉检测；全链路埋点提升可观测性；初步实现心跳机制自动优化；落地配置治理标准化。
ChatBI 建设：集成 NL2SQL 工作台；叠加 BI 可视化能力；利用沉淀的 SQL 模板作为 Few-shot 素材。
长期愿景：AI 的经验升级与知识复用
构建“执行 - 评估 - 优化 - 再执行”的闭环，让人工修正转化为永久规则，使 AI 能力随使用增长。同时，推动从单团队到跨团队的知识复用，其他团队只需建设自身业务资产即可复用整套框架。最终实现研发范式转变：数研同学从“写代码”转变为“做设计”，专注于需求理解与质量决策，由 AI 负责自动化执行，共同构成数据研发 AI 化的完整技术底座。
06 项目总结
AI 在数据研发领域的落地本质是工程化问题。知识工程解决“做对事”，Harness Engineering 解决“稳定做事”，两者缺一不可。从 NL2SQL 延伸至 ChatBI，实现了从服务数研到服务业务用户的全链路价值交付。在此过程中，知识不断沉淀、Agent 持续进化、工程框架日趋稳健，这才是 AI+ 数据研发的可持续发展路径。
