agent-harness-">Agent 系统中的 Harness 到底是什么

在讨论”重型基础设施”还是”轻量外挂层”之前，必须先把 Harness 这个概念讲清楚。Harness 直译为”挽具、线束”，在软件工程语境里指的是包裹并约束某个核心执行单元的外部控制层。放到 Agent 系统中，它就是围绕”大模型推理循环（Agent Loop）”而构建的那一层运行时封装：它本身不负责思考，但负责让思考这件事变得可靠、可持久、可观测、可控并发。

一个行业研究者曾把 Agent 相关技术栈系统性地划分为三个层次，这一划分目前被广泛引用：

• Framework（框架层）：提供构建积木，例如提示词模板、工具调用抽象、记忆接口、消息协议等。它解决的是”如何声明和组装一个 Agent”的问题。
• Runtime（运行时层）：提供执行引擎，例如持久化执行、流式处理、中断恢复、人机协同（Human-in-the-loop）调度等。它解决的是”如何真正跑起来、跑得稳”的问题。
• Harness（封装层）：位于最上层，是一种”有主见（opinionated）”的封装。它预置了提示词、工具集、外部集成、记忆策略与上下文管理机制，把前两层的能力打包成一个开箱即用、面向具体任务的 Agent 形态。

从技术视角看，Harness 是关注点分离的产物：把”模型如何推理”与”如何保障推理过程的工程可靠性”解耦；从业务视角看，它是降低 Agent 落地门槛的封装，让开发者不必每次重复实现重试、状态、日志等基础设施；从使用视角看，它是开发者与裸循环之间的一层缓冲，决定了接入体验的好坏。

为什么会出现 Harness：它解决什么问题

裸的 Agent 循环非常朴素，核心只有三件事——思考、行动、观察：

while not done:
    thought = model.think(context)      # 模型决定下一步做什么
    action  = tool.execute(thought)     # 执行工具调用
    observe = action.result             # 收集结果
    context = update(context, observe)  # 更新上下文

messages = [system_prompt, user_input]
while True:
    resp = llm(messages, tools=toolset)
    if resp.has_tool_call:
        result = dispatch(resp.tool_call)   # 执行工具，可能失败/超时
        messages.append(tool_result(result))
    else:
        return resp.text                    # 结束

这段逻辑看起来简单，但在生产环境中会立刻暴露一系列工程问题：模型调用可能超时或限流，工具可能抛出异常，长任务需要断点续跑，多个请求需要并发与限流控制，线上还需要追踪每一步的输入输出。这些问题与”模型能力”无关，却决定了 Agent 能否稳定运行。 Harness 正是为了统一解决这类”循环外围”的工程问题而出现的一层。

核心组成与关键能力

一个成熟的 Harness 通常围绕 Agent 循环提供以下几类能力：

• 重试与容错：对模型调用、工具调用的超时、限流、瞬时失败进行退避重试与熔断，避免单点抖动导致整个任务失败。
• 状态持久化与断点续跑：把每一步的中间状态写入外部存储，使长时任务在进程崩溃后能从断点恢复，而不是从头再来。
• 事件路由与流式处理：把循环中产生的 token 流、工具事件、状态变更以事件流形式向外分发，支撑实时前端展示与异步处理。
• 并发控制与背压：在多 Agent、多会话场景下做限流、队列与背压，防止把下游模型或工具打垮。
• 上下文与记忆管理：负责裁剪、压缩、检索历史上下文，在有限的上下文窗口内维持有效信息。
• 可观测性：对每一步的输入、输出、耗时、成本、错误进行结构化记录，支撑排障、评估与成本核算。
• 人机协同：在关键节点插入人工审批或干预，实现”可暂停、可接管”的执行流。

工作原理：包裹在循环外的一层运行时

Harness 的工作方式，本质上是把裸循环中的每个环节”加壳”。以重试为例，原始的一次模型调用被包裹成”带退避策略的调用”；以持久化为例，每次状态变更都被同步落到外部存储；以可观测性为例，每个环节的执行都被埋点采集。可以将它理解为在裸循环外再套一层”控制平面”：

┌─────────────────── Harness（控制层）───────────────────┐
│  重试策略 │ 状态持久化 │ 并发限流 │ 可观测埋点 │ 人机协同 │
│  ┌──────────── Agent Loop（执行层）────────────┐        │
│  │  think → act → observe → update context      │        │
│  └──────────────────────────────────────────────┘        │
└──────────────────────────────────────────────────────────┘
                         │
              模型服务 / 工具 / 外部存储 / 事件总线

有的团队曾用纯 TypeScript 实现了一个极简 Harness 来验证这一思路：核心就是一个 think → act → observe 的 while 循环，没有任何框架依赖，只在循环外围补上重试、状态、事件与并发能力。这说明 Harness 的”必要内核”其实很轻——真正决定重量的是外围能力的厚度与集成度。

核心争议：重型基础设施，还是轻量外挂层

回到标题提出的分歧，两种设计哲学各有其内在逻辑。

倾向重型基础设施的观点认为：Agent 正从演示走向生产，可靠性、可观测性、合规与运维需求会持续加码。与其让每个团队各自造轮子，不如把持久化执行、事件路由、并发调度、身份认证、日志监控等能力沉淀为一套统一的运行时基础设施。这样 Agent 才能像传统后端服务一样被严肃地部署、扩容和治理。重型路线的优势在于开箱即用的完备性与一致性，代价是耦合较深、迁移成本高、灵活性受限。

倾向轻量外挂层的观点认为：Agent 的核心价值在模型与工具编排，外围能力应当保持”可插拔、无侵入”。用一个不依赖任何框架的薄循环，按需挂载重试、状态、日志等能力，既保留了模型与工具快速迭代的自由，也避免了被某套重型运行时锁定。轻量路线的优势在于灵活、易替换、心智负担低，代价是需要团队自行补齐大量工程能力，落地一致性较差。

我的判断是：二者并非二选一，而是分层共存、按场景收敛。对于追求快速验证、原型迭代、单一任务的场景，轻量外挂层更合适；对于多 Agent 协作、长时任务、强合规、大规模生产的场景，重型基础设施的价值会显著放大。更现实的趋势是：内核保持轻量（一个清晰的循环抽象），能力按需组合（可插拔的可靠性、持久化、可观测模块），从而在两者之间取得平衡。

典型适用场景

• 客服与工单自动化：需要人机协同、状态持久化与全链路追踪，适合较完备的 Harness。
• 代码助手与研发 Agent：需要流式输出、工具编排与快速迭代，适合轻量可插拔的封装。
• 长时数据处理与批处理 Agent：强调断点续跑与并发控制，重持久化能力。
• 多 Agent 协作系统：强调事件路由、并发调度与可观测性，偏向基础设施化。
• 原型验证与教学演示：强调简单与无依赖，适合极简外挂层。

与相关概念的区别

• 与 Framework 的区别：Framework 提供”声明和组装 Agent 的积木”，Harness 提供”让 Agent 稳定运行的外壳”。前者面向构建，后者面向运行与治理。
• 与 Runtime 的区别：Runtime 强调执行引擎本身（如持久化执行、流式），Harness 往往是在 Runtime 之上再做一层”有主见”的任务化封装。二者边界会随产品定位浮动。
• 与 Agent Loop 的区别：Agent Loop 是最内核的思考—行动—观察循环；Harness 是包裹它的外围控制层，二者是”内核与外壳”的关系。

选型与使用注意事项

• 明确重量级需求：先判断是否需要断点续跑、多 Agent、强合规，再决定重型还是轻量，避免过度设计。
• 关注可迁移性：优先选择内核清晰、能力可插拔的方案，避免外围能力与被封装的模型、工具强绑定。
• 重视可观测性：无论轻重，结构化的日志、追踪与成本核算都应尽早纳入，否则线上排障代价极高。
• 并发与成本护栏：为模型与工具调用设置限流、超时、预算上限，防止失控调用造成资源与费用浪费。
• 安全与人机协同边界：对涉及写操作、外部副作用的工具调用设置审批与权限控制，遵循最小权限原则。
• 云上能力解耦：重试、持久化、事件、日志、监控等能力可对接通用的对象存储、消息队列、日志服务、监控告警、身份认证等云产品类目，但应保持接口抽象，避免与某一具体实现死绑。

总结

Harness 是 Agent 系统中包裹推理循环、保障其可靠运行的一层运行时封装，其价值在于把”循环外围的工程问题”从”模型能力问题”中剥离出来统一解决。关于它未来的形态，更合理的结论不是”重型 vs 轻量”的二元对立，而是”内核轻量、能力可插拔、按场景收敛”的分层演进：原型阶段用轻量外挂层快速验证，生产阶段以可组合的基础设施能力补齐可靠性、持久化与可观测性。理解 Harness 的定义与边界，是做好 Agent 系统架构选型的第一步。