跳转至

Harness 范式：Agent 的工程基座

Ch04.831 Harness 范式：Agent 的工程基座

📊 Level ⭐⭐⭐ | 8.2KB | entities/harness-paradigm.md

Harness 范式：Agent 的工程基座

摘要

Harness 范式将 Agent 从"单次对话"提升为"可持续运行的工程系统"，主张决定 Agent 上限的不只是模型能力，更是承载它的工程基座。上下文管理、工具编排、循环控制、安全边界、人机协作五大支柱构成其方法论骨架，状态外化则是从对话走向系统的关键一跃。

核心要点

  • Harness ≠ 框架：Harness 是 Agent 运行所依托的工程基座；LangGraph、Claude Code 等只是具体实现载体。
  • 五大支柱分层：上下文管理（感知）、工具编排（行动）、循环控制（流程）、安全边界（约束）、人机协作（交互），下层赋能上层、上层约束下层。
  • 状态外化是范式转换核心：LLM 只是状态转换引擎而非仓库——状态持久化于文件系统、数据库、队列，窗口只保留工作集。
  • 每个支柱都是显式权衡：完整上下文 vs 检索增强、顺序 vs 并行扇出、固定轮次 vs 自适应终止，没有银弹，只有显式取舍。
  • Harness 本身需要可观测与可评估：trace、eval 与可复现的循环控制，决定其能否持续迭代进化。

深度分析

五大支柱的层次关系

五大支柱并非平级并列，而是存在结构性层次。上下文管理是底层基础——决定 Agent 能感知的信息范围与质量，一旦溢出或被裁剪，上层就在错误信息上运行。工具编排是执行层——将感知转化为行动，决定调什么工具、按何顺序、如何合并结果。循环控制是流程层——确保长任务收敛，决定何时继续、停止、重试。安全边界是约束层——划定行动的不可逾越范围（权限、配额、白名单），是生产环境接纳 Agent 的前提。人机协作是交互层——决定人类介入的时机与粒度，即对自动化程度的分级授权。

五层双向作用：下层提供能力基础，上层提出约束要求——安全边界要求最小权限调用，人机协作要求可中断点，每层都要为上层预留"接口"。

从单次对话到持续运行系统的范式转换

本质是状态管理位置的变化。单次对话模式中，状态完全存在于上下文窗口内：对话结束即消失，系统无记忆、无恢复、无并发。持续运行模式下，状态被外化到 Harness 层面——文件系统保存任务产物，数据库保存结构化状态，队列保存待处理工作项——LLM 退化为"状态转换引擎"：读状态、决策、写回状态。这与 Harness 即后端：当 Agent 基础设施消解于统一原语 的趋势一致：Harness 把状态、调度、持久化沉淀为统一原语。

状态外化带来三个连锁需求。其一，持久化与恢复：任务中断后从最近 checkpoint 继续，状态转换要么幂等、要么可回滚。其二，错误处理：从"重试一次"升级为退避重试、死信队列、人工兜底等多级策略。其三，并发与一致性：多实例共享状态需要锁、事务或事件溯源——这三者都是后端经典问题，"Harness 即后端"的含义正在于此。

五大支柱的工程实现权衡

每个支柱都是"能力-成本-风险"的三方权衡。

上下文管理：完整保留（简单但窗口迅速耗尽）vs 滑动窗口（有界但丢失早期信息）vs 检索增强（可扩展但引入噪声）vs 分层记忆；实践中组合使用，难点在"何时触发压缩/检索"。参见 Agent 编排层：长任务中的上下文管理架构。

工具编排：顺序执行（确定但慢）vs 并行扇出（吞吐高但需聚合）vs 条件分支/DAG（灵活但需显式依赖建模）vs 模型自由调用（弹性但不可预测）。核心权衡：编排逻辑写死在代码里还是交给模型决策——前者可控但僵化，后者弹性但需护栏。

循环控制：固定轮次（预算可控但可能过早截断）vs 自适应终止（省 token 但可能误判）vs 外部信号终止（测试通过等客观条件，最可靠）vs 人类中断。生产系统通常组合：外部信号为主、自适应为辅、固定上限兜底。

安全边界：软约束（提示词层面，零成本但可绕过）vs 硬约束（sandbox、权限模型、白名单，可靠但需基础设施投入）vs 审计追踪（不阻止但记录）。成熟 Harness 三者叠加，遵循最小权限。

人机协作：审批门禁（关键动作前强制确认，安全但打断流畅性）vs 异常上报（仅低置信时升级，体验好但依赖置信度判断）vs 全程监督（最安全但无自动化收益）。介入粒度应与任务风险挂钩。

Harness 生命周期：构建、部署、监控与迭代

Harness 本身是需要被工程化管理的系统，生命周期分四阶段。构建（Build）：选型五大支柱实现（自研内核 vs 基于 LangGraph 组装），先跑通最小闭环再补全安全与可观测。部署（Deploy）：作为长期服务而非一次性脚本交付，涉及进程生命周期、配置外部化与版本化，与业务代码一样需要 CI/CD。监控（Monitor）：输出结构化 trace——LLM 调用、工具执行、状态转换、循环迭代均可回放，并采集成本、延迟、失败率指标，使行为可审计。迭代（Iterate）：基于 trace 与 eval set 识别循环失控、工具误用、上下文污染等问题，形成"观测→诊断→修改→再评估"闭环。

可观测与评估是这一闭环的地基：没有 trace 无法定位根因，没有 eval 无法判断改动优劣。这与 Agent 友好的可观测：阿里云观测与智能运维 Skills 代表的趋势一致——可观测正在成为 Agent 基础设施的标配层。

实践启示

  1. 从上下文管理起步：它是底层基础，先解决"Agent 能看到什么"再谈"Agent 能做什么"，再做上下文审计与压缩检索策略。
  2. 状态外化优先于模型升级：把状态外化到持久化存储、为关键路径设计 checkpoint 与恢复，对可靠性的提升通常大于换更强模型。
  3. 每个支柱都做显式权衡并记录：写下设计决策与权衡理由，避免隐形假设引发重构。
  4. 以外部信号作为循环终止主判据：优先用可判定的客观条件（测试通过、目标达成）终止循环，模型自评辅助、固定轮次兜底。
  5. 把安全与协作做成默认而非插件：从第一个生产用例起就引入 sandbox、最小权限与审批门禁，事后补远比事前设计昂贵。
  6. Harness 也要持续迭代：建立 trace 与 eval 基线，把每次"Agent 翻车"沉淀为回归测试用例。

相关实体