📌 一句话摘要

文章提出数据研发场景下的 Multi-Agent Harness 工程范式，通过六大核心支柱解决 Agent 可控性、可预测性与可信任问题，核心观点是 Agent 能力不仅取决于模型，更取决于围绕模型的工程框架。

📝 详细摘要

文章从数据研发 Agent 落地的常见问题切入（Agent「能跑但不值得信」），引出核心矛盾：LLM 的 context 压缩机制不擅长保持长程约束，而数仓场景对长程约束依赖极强。作者回顾 AI 工程范式演进：从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering，提出核心公式 Agent = Model + Harness。随后详细展开 Harness 工程实践，包括三层核心分层（身份层、执行层、进化层）和六大支柱：Identity（角色定义与约束三层金字塔：超级红线、错误记录、操作规则）、Orchestration（流程编排与智能调度，包括前置自动完成、多路径/多专家并行、修改重量自适应）、Context（阶段切分、CP 检查点摘要、渐进式加载、Spec 文件驱动）、Gate（门禁检查点、强制检查项、生成评估分离）、Recovery（12 状态状态机、故障三档分级、断点续接与异常回滚）、Evolution（知识沉淀与螺旋上升）。最后强调 Harness 的核心价值：让 Agent 从「能跑」到「能用到」再到「可信」，可控制、可预测、可信任。

💡 主要观点

1. Agent 能跑不等于能用，能用不等于可信。 从 Demo 到生产环境，需要工程框架来约束和验证，核心差距是工程能力而非模型能力。
2. LLM 天然不擅长保持长程约束，需要确定性工程框架托底。 数仓场景对长程约束依赖极大，模型会因 context 压缩而丢失规约，必须将「抗」的责任从模型转移到工程体系。
3. Harness 工程是 AI 工程第三代范式，核心是让 Agent 可控制、可预测、可信任。 从 Prompt Engineering（怎么说）到 Context Engineering（看什么）到 Harness Engineering（怎么做），后者系统性解决 Agent 的可靠性问题。
4. Identity、Orchestration、Context、Gate、Recovery、Evolution 六大支柱构成闭环。 身份定形→可靠执行→进化增强→身份增强，体现从定义到执行到反馈的螺旋上升结构。
5. 生成评估分离：子专家负责产出，协调者负责验收，不能既当运动员又当裁判。 Agent 对自身产出天然有合理化倾向，独立裁判角色是可信度量建立的关键。

💬 文章金句

• Agent 能跑，不代表能用；能用，不代表可信。
• 模型决定了上限，Harness 决定了下限。
• 一个不可预测的 AI，能力再强也没法用，因为你不敢把任何重要的事情交给它。
• 可控，比聪明更重要。
• Agent 之间不直接对话，而是通过预定义 Schema 的结构化文件交换信息。

📊 文章信息

阅读完整文章