LLM Wiki

外观

Harness Engineering 与知识工程：数据研发企业落地实践（模式） ​

摘要：电商团队在 NL2SQL 数据研发场景落地的双支柱方法论：知识工程（解决"AI 凭什么能做对"）让 AI "有据可依"，Harness Engineering（解决"AI 如何稳定运行"）让 AI "稳定可控"。通过 7 Agent 协同（顺序协作 + 反馈循环 + 人工 Gate）、幻觉检测 Hook、空间隔离、配置治理与心跳机制，实现"只做选择，不做配置"的研发范式转变（stated）。

定义 ​

核心命题：AI 在数据研发领域的落地，不是模型能力问题，而是工程化问题（stated）。

支柱解决的问题手段
知识工程（Knowledge Engineering）AI 凭什么能做对数研专家经验 → LLM 可理解的结构化知识体系
Harness Engineering（AI Agent 管控框架）AI 如何稳定运行分离关注点、施加约束、管理上下文与熵值

适用场景 ​

  • 业务 Agent 迭代快、对准确性要求极高的生产场景（数据研发、金融、审核等）
  • 多 Agent 协作系统需要分模块管控
  • 需要把专家经验沉淀为 AI 可复用资产的团队

关键前提：AI 的不确定性 —— 传统 CI/CD Pipeline 步骤是确定性的，而 AI 每步都可能产生意料之外的输出，Harness 的设计就是在这种不确定性中建立秩序（stated）。

知识工程：让 AI "有据可依" ​

三层知识体系 ​

  1. 方法论层：Spec 指导需求分析、Plan 规范技术方案、Task 定义执行标准，形成"文档即接口"的多 Agent 协同机制（SPEC→PLAN→SQL 链式生成）
  2. 协作机制：文档状态机驱动 8 阶段研发流程 + 人工校验，形成"需求经验沉淀-能力提升-效率提升"飞轮；组件包括 AGENTS.md（协作规范）、Skills 引擎、Knowledge 库
  3. 执行原则：基于数研经验初始化知识体系，通过需求调试持续优化

研发即沉淀（知识复利） ​

  • 每完成一个需求，产出（SPEC/PLAN/SQL/验证报告）自动归档到 Archival Memory；新增指标定义进语义资产库；踩过的坑记录到 anti-patterns.md（stated）
  • 从"人可用"到"AI 可食"：传统数据资产为人设计；AI 需要严格结构化、语义明确、可机器检索的格式（不仅定义"指标是什么"，还要定义 DWD 表达式、依赖上游表、取值范围）
  • 长期收益曲线：资产维护是初期一次性成本，随积累研发效率持续提升，且知识资产不随人员离职流失（high）

语义层（NL2SQL 核心） ​

  • 走 NL2DSL2SQL 路线：自然语言 → 标准化指标-维度语义（DSL）→ SQL（语义映射是关键一步）
  • 指标治理：先治理再录入，核心指标由专家建模注册；"标准名称+别名映射+语义边界"规范体系解决同义词/近义词混淆
  • 资产防腐双循环：上线前数仓小组拦截语义重复资产；上线后定期资产健康度评估动态清理冗余

Harness Engineering：让 AI "稳定可控" ​

四大管控手段 ​

  1. 分离关注点：决策与执行分离、知识检索与代码生成分离，每个 Agent 只负责擅长的事
  2. 施加约束：Gate 机制、规范校验、强制审批，限制 AI 自由度
  3. 管理上下文：控制每个 Agent 信息输入量，避免上下文过载导致质量下降
  4. 管理熵值：长程任务中 AI 行为不确定性随时间累积（熵增），Harness 持续"整理"和"矫正"，防止行为漂移

7 Agent 协同编排 ​

AI 做执行，人做决策 —— 顺序协作 + 反馈循环 + 关键节点人工 Gate：

  • 顺序协作：Agent 按预定义顺序执行（老架启动需求分析 → 小需完成 SPEC → 老架审核 → 小语资产盘点 → 老架设计技术方案…），形成严格流水线
  • 反馈循环：下游 Agent 发现问题可回滚上游（小检发现 SQL 质量问题 → 返回老架决策是否重新生成）

稳定性工程 ​

幻觉是 AI Agent 最危险的问题。典型案例：子 Agent 被要求核对官方文档，文档读取失败但报告"检查通过" —— 声称完成但实际什么都没做（stated）。

应对策略：

  • 技能幻觉检测 Hook：每次技能执行后对比"声称结果"与"实际系统状态"（说文件已创建 → 检查文件是否存在；说 API 成功 → 校验返回值）
  • 执行结果强制校验：关键操作必须产出可验证产物（文件/数据/状态变更），仅凭文本回复不算完成
  • 日志必看原则：每个操作都要检查配置/改动是否真正更新；调试完的工作流换模型或业务类型必须重新测评

空间隔离：独立 Workspace（~/.openclaw/workspace/{project_name}/）、{domain}_{date}_{seq} 命名规范、MCP/Skill 加载路径优先级（子 workspace → 全局 fallback，禁用跨 workspace）、按需开放技能省 Token。

配置治理：配置是 Agent 系统"生命线" —— 每日自动 Git 备份、agents.md 同步机制、模板化快速恢复。

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

三层：执行监控（定期回顾执行历史：成功率/失败原因/修正记录）→ 模式识别（识别反复问题模式：RAG 召回偏低、模板校验不过、返工率高）→ 自动优化（优化 Prompt 模板、补充知识条目、调整工作流参数）。

最关键：人工修正 Agent 行为时的反馈被自动捕获写回知识库和规则配置 —— "以 Agent 养 Agent"：告诉 Agent 少了哪些步骤，Agent 自己更新配置，下次执行自动包含（stated）。

演进路径 ​

  • 近期：Multi-Agent 工作流落地、Spec 研发规范输出、知识库冷启动
  • 中期：幻觉防控自动化（人工看日志 → 自动 Hook）、可观测性埋点（ELK/Grafana）、心跳机制实现、ChatBI 建设（NL2SQL SQL 模板做 Few-shot 素材）
  • 长期：经验升级闭环（执行→评估→优化→再执行）、跨团队知识复用、"只做选择，不做配置"（人做设计决策，AI 做执行）

核心启示 ​

知识工程确保 AI "做对事"，Harness Engineering 确保 AI "稳定做事"，两者协同构成 AI 落地的完整技术底座（stated）。

关联词条 ​