7.4
深览指数
科技Bestblogs·阿里云开发者··AI 生成
数据研发 Multi-Agent 架构的 Harness 工程实践
文章提出数据研发场景下 Multi-Agent 工程的核心矛盾：LLM 不擅长保持长程约束，而数仓场景对此依赖极强。作者认为 Agent 能力不仅取决于模型，更取决于围绕模型的工程框架（Harness），并提出六大核心支柱（Identity、Orchestration、Context、Gate、Recovery、Evolution）来系统性解决 Agent 的可控性、可预测性与可信任问题。适合正在落地 AI Agent 的工程团队或技术决策者阅读，尤其对数据研发相关场景有参考价值。原文 ↗
核心观点
- ▍Agent 能力不仅取决于模型，更取决于围绕模型的工程框架（Harness），核心公式为 Agent = Model + Harness。
- ▍LLM 的 context 压缩机制不擅长保持长程约束，而数仓场景对长程约束依赖极强，必须将「抗约束」的责任从模型转移到确定性工程体系。
- 01文章提出 Harness 工程的三层核心分层：身份层（Identity）、执行层（Orchestration/Context/Gate/Recovery）、进化层（Evolution），构成从定义到执行到反馈的闭环。
- 02Identity 支柱包含「角色约束三层金字塔」：超级红线（不可触碰的绝对规则）、错误记录、操作规则，用于限制 Agent 行为的边界。
- 03Orchestration 支柱包含前置自动完成、多路径/多专家并行、修改重量自适应等机制，用于智能调度执行流程。
- 04Context 支柱通过阶段切分、CP 检查点摘要、渐进式加载、Spec 文件驱动等手段，解决长上下文场景下的信息丢失问题。
- 05Gate 支柱实现「生成评估分离」：子专家负责产出，协调者负责验收，避免 Agent 对自身产出的合理化倾向。
- 06Recovery 支柱定义了 12 状态状态机、故障三档分级、断点续接与异常回滚机制，用于处理运行时错误。
- 07Evolution 支柱实现知识沉淀与螺旋上升，将运行中遇到的问题和经验反馈回 Identity 层，不断强化约束。
- 08作者回顾 AI 工程范式演进：从 Prompt Engineering（怎么说）到 Context Engineering（看什么）再到 Harness Engineering（怎么做）。
反方 / 局限
- — 文章未明确讨论 Harness 框架本身的前期构建成本与维护复杂度，对于中小团队是否适用未做评估。
- — 文章对 Identity 层「超级红线」的定义依赖于人工输入，未讨论如何动态更新或自动化发现红线规则。
4 分钟 · 4 卡片 · 8 资料
读原文 →