数据研发Multi-Agent架构的Harness工程实践

当团队兴奋地向管理层演示数据研发Agent时，流畅的五分钟让人信心满满。然而真正投入使用后，各种问题接踵而至：Agent跳过关键确认步骤、字段命名混乱、甚至擅自重构整个数据表。这种从"演示可用"到"生产可信"的鸿沟，正是当前AI Agent落地面临的核心挑战。问题的本质并非模型能力不足，而是工程化体系的缺失——这就是Harness架构需要解决的根本问题。

Harness架构的整体设计

理解Harness的定位，需要回顾AI工程范式的演进历程。第一代Prompt Engineering解决的是"如何把话说清楚"；第二代Context Engineering解决的是"给Agent看什么资料"；而第三代Harness Engineering要回答的则是更根本的问题：Agent到底应该怎么工作。Harness这个源自马具的比喻，形象地说明了一个道理——让烈马拉车，光有马是不够的，还需要缰绳、笼头和车辕把力量约束在正确的方向上。核心公式非常简单：Agent = Model + Harness。模型决定上限，Harness决定下限。

身份层与角色定义

基于Multi-Agent执行生命周期，Harness工程可拆解为三大分层和六大支柱。三大分层包括：身份层（Agent执行前的静态身份与约束定义）、执行层（动态决策的执行路径、上下文加载、门禁检查、状态追踪、故障恢复等）和进化层（执行后的经验沉淀与能力演进）。六大支柱则是Identity（角色定义与约束体系）、Orchestration（流程编排与智能调度）、Context（上下文工程）、Gate（门禁检查与质量评估）、Recovery（状态追踪与故障恢复）、Evolution（经验沉淀与进化学习）。这三层六支柱形成闭环反馈：身份定形→可靠执行→进化增强→身份增强，螺旋上升。

执行层核心支柱

Identity支柱解决的是"谁有什么能力、什么绝对不能做"的问题。约束越清晰，模型在概率空间中的采样越聚焦，输出方差越小。采用Orchestrator+Specialist架构：协调者Agent不写代码、不出方案，只负责调度、把关、评审；各专家Agent（需求拆解、方案设计、SQL开发、测试验证）有明确边界，只暴露领域内能力。行为约束采用三层金字塔结构：顶层是绝对不可违反的"超级红线"（如Human in the loop、禁止编造数据），中间层是历史教训的错误记录，底层是操作规则。Orchestration支柱则实现"链路模式"与"单点模式"并存，既支持完整流程质量保障，也支持高效单点调用。

质量保障与持续进化

Gate支柱引入"两层防御"机制：Identity作为前置约束管准入，Gate作为事后验证管验收。Generator+Evaluator必须分离——子Agent负责埋头干活，协调者Agent负责拿着checklist逐项验收，确保裁判独立于生成过程。Recovery支柱通过12个明确的状态枚举值实现断点续接，配合三档故障分级（可重试→需回退→必须中止），确保长任务执行的韧性。Evolution支柱则将"每犯一个错，就工程化一个解"作为核心理念，通过结构化违规记录、自动加载历史教训、约束迭代升级，让错误成为系统进化的燃料。

如有侵权，请联系删除。