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

这是2026年的第36篇文章

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

01 项目背景

今年团队在AI Data方向锁定了两个核心命题：一是“数据研发效率提升”，二是“数据价值交付”。项目启动前，我们对集团内外的相关实践做了系统的摸底。发现当前AI在数据领域的应用，大多集中在单点提效的Agent、NL2SQL和ChatBI这几个方向，而且在垂直领域确实跑出了不错的效果，但问题也显而易见——很难作为通用方案向外推广。

调研过程中，两个共性问题浮出水面：

1. 横向拓展能力不足。 现有平台能力在各自业务领域表现优异，但缺少一套标准化的接口供其他业务接入。新业务进来时，由于业务特性不同，能发挥出来的能力往往只有30%左右。

2. 数据资产沉淀不足。 NL2SQL的准确率高度依赖语义层的数据资产质量。但不同团队各有各的语义组织方案，口径不一，标准各异，缺乏统一规范。

问题的本质，归根结底是“数据研发的知识是碎片化的，流程是非标准化的”。每个数研同学脑子里都有一套“这事该怎么做”的经验，但这些经验很难被复用、被传承，更不用说被AI理解了。基于这个认知，我们重新思考了数研工作范式的升级路径，最终聚焦在两大工程方向上：

• 知识工程（Knowledge Engineering）： 解决“AI凭什么能做对”的问题。核心是把数研专家的经验、业务规则、数据资产，转化为LLM能够理解的结构化知识体系，让AI在执行时有据可依，而不是凭空猜测。

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

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

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

这里要特别强调一下语义层的重要性。它是NL2SQL的核心基础设施，解决的是从自然语言到精确数据语义映射这个最关键的问题。为什么“自然语言直接转SQL”的成功率一直上不去？原因很直白：自然语言中缺少太多关键信息。所以，我们选择走“NL2DSL2SQL”的路线——先把自然语言映射到标准化的指标-维度语义，再从这个语义层出发生成SQL。

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

在Agent体系上，我们做了升级，基于智能体实现工程能力的串联，完成生产级数研方案的交付。工作流采用的是“顺序协作模式”和“反馈循环模式”的组合，核心节点保留人工干预。

• 顺序协作： Agent按照预定义的顺序依次执行任务。比如，“老架”启动需求分析后，“小需”完成SPEC，“老架”审核通过后再调度“小语”进行资产盘点，接着由“老架”设计技术方案……形成一条严格的流水线。
• 反馈循环： 当下游Agent发现问题时，可以回滚到上游环节。例如，“小检”发现SQL质量有问题，任务就会返回给“老架”，由他来决策是否需要“小需”重新生成。

这套方案的核心，就在于“知识工程的搭建”和“Harness Engineering的架构设计”。下面，我们就重点展开聊聊这两个部分。

03 知识工程：让AI“有据可依”

在数据研发这个场景里，如果我们自己都讲不清楚需求是什么、能提供哪些数据资产，那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 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自己更新配置文件，下次执行时自动包含这些步骤。通过人对大模型的反馈，实现大模型的“经验升级”。

05 演进方向与展望

近期：Multi-Agent工作流落地

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

• 工作流验证： 在真实需求中验证7 Agent协同的端到端流程，重点关注Gate机制的实际效果和Agent间协作的稳定性。
• Spec规范输出： 输出《Spec研发规范V0.5》，包含Excel需求模板、指标拆分规则、数据建模契约、校验规则。
• 知识库冷启动： 完成各业务域的基础资产沉淀，建立指标命名规范和资产防腐化流程。

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

知识工程方向：

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

Harness Engineering方向：

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

ChatBI建设：

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

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

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

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

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

06 项目总结

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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：电商团队数据研发的Harness Engineering实践：从Coder到Designer要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题