如何设计和构建基于你自己业务的自定义Agent Harness?

从业务所需的上下文、潜在故障、强制策略和运行环境出发,借助 create_agent 与 middleware,把八类能力组合成真正适配任务的 Agent Harness。

作者:Sydney Runkle09-14 · 约 8 分钟

在构建面向具体业务的 AI Agent 时,开发者真正要决定的关键问题,往往并不是“选哪个最强模型”,而是厘清当前任务的具体运行诉求:它究竟需要哪些上下文(context it needs)、会遇到哪些潜在失败(failures it'll encounter)、必须执行哪些策略(policies it must enforce),以及运行在怎样的真实环境(environment it operates in)之中。这四个维度,正是原文在定义 Task-Harness Fit(任务与底座适配度) 时明确指出的核心衡量标准。

构建真正实用的智能体,本质上是关于定制化(Customization)——如何让智能体在特定任务中连接到所需的上下文、数据与运行环境。包裹在模型外部的 Agent Harness(智能体运行底座/脚手架),正是实现这种连接的工程实体。需要交代的是,原文并未给出开箱即用的完整业务实施教程,而是系统阐明了如何以极简原语为核心、利用中间件为业务量身设计和定制 Harness 的架构路径。

生产级 Agent 的工程核心:自定义 Harness

概念解耦:什么是 Harness?为什么说 Agent = Model + Harness?

在最本质的层面上,智能体就是一个模型在循环中不断调用外部工具,直到任务完成并返回结果:

Agent 的基础工具调用循环

这一运行机制可以用一个核心公式清晰表达:

Agent = Model + Harness

这里的 Harness,就是包裹在大模型外部、负责将其与真实世界连接起来的整套脚手架工程。

Agent 等于模型与 Harness 的组合架构

这一架构认知建立在两项前提之上:

  1. 智能体的实际表现,取决于提供给模型的上下文质量(An agent is only as good as the context provided to the model);
  2. Harness 的核心职责,就是在循环的每一步为模型精准提供所需的上下文(The job of a harness is to provide context to the model at every step)。

因此,要构建出真正可用的智能体,就必须打造一套善于为特定任务按时、按需向模型输送正确上下文的 Harness。


极简原语与预组装底座的分水岭:为什么选择 create_agent?

在 LangChain 体系中,构建自定义 Harness 的基础原语正是 create_agent。只需传入模型、工具集和系统提示词,就能得到一个正常运转的智能体:

from langchain.agents import create_agent

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=tools,
    system_prompt="you are a helpful assistant..."
)

在工程选型中,市面上存在两种截然不同的底座构建思路:

  • 预组装 Harness(Pre-assembled Harnesses):如 Deep Agents 或 Claude Agent SDK。它们出厂即带有一套有明确取向的中间件技术栈,包含记忆、上下文管理、沙箱等组件。这类底座旨在帮助团队快速得到生产可用的 Agent,适用于大多数场景。然而,许多 Agent 仍需要比预装底座更细粒度的定制控制,例如专属提示词、业务逻辑以及护栏。
  • 极简原语路线(Purposefully Minimalistic Primitive):create_agent 采取了不同的方式,这一理念类似于高可配置的代码智能体 Harness Pi。create_agent 只实现最核心的智能体循环,并把中间件(Middleware)暴露为定制原语。

中间件机制:如何通过四类杠杆精细定制 Harness?

中间件是深度定制 Harness 的核心手段。中间件能够直接挂载到 Agent 运行循环的各个阶段:模型调用前后、工具调用前后,以及智能体启动和终止时。每个中间件独立处理单一关注点,并能与其他中间件自由组合拼装:

Harness 内部中间件的拦截机制

通过中间件,开发者可以借助以下四类常常协同起效的“工程杠杆”按业务需求精细定制底座:

  1. 确定性逻辑(Deterministic Logic):
    • 解决的设计问题:业务规则、策略强制执行以及动态运行时控制,需要在运行循环的特定节点触发,不适合完全塞进提示词(Prompt)中。
    • 机制与原文示例:用于在循环特定节点触发的确定性代码。原文明确指出的关键场景是对智能体运行时的动态控制:根据任务复杂度动态切换模型(swapping the model based on task complexity)、动态调整提示词(adjusting the prompt),以及在上下文压缩时更新消息历史(updating the agent's message history, during compaction, for example)。凡是不能或不应写在提示词里的逻辑,都属于此类。
  2. 工具生命周期治理(Tools):
    • 解决的设计问题:当工具带有外部依赖、需要初始化或结束时清理,仅仅把工具直接注册到 Agent 上,会让配置与治理逻辑分散。
    • 机制与原文示例:不再将工具生硬地直接注册在智能体上,而是由中间件全权接管工具的完整生命周期——初始化设置(setup)、运行结束清理与卸载(teardown)以及动态注册(registration),并妥善管理工具依赖,最终交付给智能体一套干净规整的可用工具集。这保证了工具配置与其背后的控制逻辑紧密内聚,避免配置散落。
  3. 自定义状态(Custom State):
    • 解决的设计问题:中间件需要在不同生命周期钩子之间持续记录并共享业务状态。
    • 机制与原文示例:通过自定义属性扩展智能体的状态对象(extend the agent's state with custom properties)。原文明确指出,这使得中间件能够在整个执行周期内维护计数器(counters)、状态标志(flags)或其他持久值,并在不同的钩子之间无缝共享数据。
  4. 流处理器(Stream Handlers):
    • 解决的设计问题:智能体输出流中的不同事件,需要交给界面、审计和监控等不同消费者处理。
    • 机制与原文示例:中间件可以拦截并重塑输出流——过滤事件(filtering events)、注入元数据(injecting metadata),并将不同类型的事件路由给不同的消费者。原文给出的典型业务场景包括:前端 UI 消费 Token 增量(token deltas)实现实时打字渲染、审计日志系统捕获工具调用(tool calls)完成合规留痕、监控系统追踪延迟(latency)保障服务稳定性。

中间件机制的核心工程价值在于:

  1. 允许在智能体生命周期的任意拦截点进行无缝定制;
  2. 将关联工程逻辑封装为独立解耦、可自由组装并在多项目间复用的代码单元。

LangChain 提供了覆盖常见模式的预置中间件(Prebuilt Middleware);若存在专有需求,也可以编写自定义中间件(Custom Middleware)。由于每个中间件彼此隔离,同一个中间件可以在组织内复用,使新 Agent 继承已经验证过的行为。


从业务任务倒推 Harness:八大能力需求与中间件映射

Harness 的终极使命,是在循环的每一步为模型递送精准匹配当前任务的上下文。

构建 Harness 不是把所有中间件全量装上。原文明确指出,智能体最终采用哪些中间件组合,取决于具体任务的核心需求:是否需要长周期运行(is it long running?)、任务本身有多复杂(how complex are the tasks?),以及智能体执行动作的敏感程度如何(how sensitive are the agent's actions?)。一个客服 Agent 与一个长运行编程 Agent 所需的 Harness 会明显不同,但原文没有替这两类业务规定固定组合。

业务设计方法:从任务需求倒推 Harness 装配

围绕“如何设计和构建基于你自己业务的自定义 Harness”,把原文关于 Task-Harness Fit 的四个维度与官方能力映射表结合起来,可以提炼出一套面向业务开发者的倒推设计方法(注:这是把原文的 Task-Harness Fit 考量与能力表合并后的读者用法,而非 LangChain 官方给出的固定四步规范):

  1. 写清任务使命(Mission):先明确智能体要完成的核心业务目标、执行边界与期望交付物。
  2. 按四大维度盘点特征(Context / Failures / Policies / Environment):
    • 上下文(Context):会话是多轮长交互还是一次性问答?需不需要记忆模块在启动时加载外部知识、在结束时沉淀经验?
    • 潜在故障(Failures):模型或工具会遇到哪些不可预测的瞬态失败?
    • 策略红线(Policies):是否存在用户隐私脱敏(PII)、合规检查,或者哪些高敏感操作必须获得人工审批批准?
    • 运行环境(Environment):智能体是在受限数据环境还是需要获得文件系统、命令行或代码解释器等更广阔的执行环境?
  3. 从八项核心能力中按需筛选:根据盘点出的特征,在下方八项能力中挑出当前业务真正需要的项,避免无谓堆砌。
  4. 映射到具体中间件组合:将选定的能力直接对应到 LangChain 预置中间件或编写自定义中间件,组合挂载到 create_agent 的循环中。

TASK → CAPABILITY → MIDDLEWARE

用业务条件拼出你的 Harness

勾选当前业务真实存在的条件,右侧会把对应 middleware 自动去重组合。未选择时,下方八项能力仍完整可读。

你的业务需要什么?
01防止上下文溢出Summarization · ContextEditing
02访问与更新记忆Filesystem · Memory · Skills
03在环境中执行动作ShellTool · Filesystem · CodeInterpreter
04委派复杂任务SubAgent · AsyncSubAgent · TodoList
05处理瞬态故障ToolRetry · ModelRetry · ModelFallback
06强制执行策略PII · HumanInTheLoop
07引导与控制 AgentHumanInTheLoop
08控制运行成本ModelCallLimit · ToolCallLimit · PromptCaching

下表展示了原文梳理的八项核心生产能力需求、其背后的关键价值,以及官方对应的预置中间件映射关系:

能力维度(Capability) 为什么重要(Why it Matters) 对应中间件(Middleware)
防止上下文溢出(Prevent context overflow) 长时间运行的会话会迅速积累消息历史。若不加干预,将导致上下文窗口溢出。 SummarizationMiddleware、ContextEditingMiddleware
访问与更新记忆(Access and update memory) 在启动时加载相关知识,在运行结束时写回更新。使智能体能够从真实使用中随时间持续进化。 FilesystemMiddleware、MemoryMiddleware、SkillsMiddleware
在环境中执行动作(Take actions in an environment) 固定的工具集限制了智能体的能力边界。获得文件系统和执行环境的访问权限,能解锁更具创造性的解决方案,且往往具备更高的 Token 效率。 ShellToolMiddleware、FilesystemMiddleware、CodeInterpreterMiddleware
委托任务(Delegate tasks) 子智能体(Subagents)使用独立的干净上下文窗口处理复杂子任务。待办清单(Todo list)则用于追踪长运行周期中的整体任务进度。 SubAgentMiddleware、AsyncSubAgentMiddleware、TodoListMiddleware
处理瞬态故障(Handle transient failures) 模型与工具的调用故障具有不可预测性。生产级智能体需要具备退避重试逻辑,并在主模型不可用时自动启用回退方案。 ToolRetryMiddleware、ModelRetryMiddleware、ModelFallbackMiddleware
执行策略与合规(Enforce policies) PII(个人身份信息)脱敏、合规检查、审批关卡——无论模型输出什么内容,这些检查都必须在每次调用时强制触发,它们绝不能只写在提示词里。 PIIMiddleware、HumanInTheLoopMiddleware
引导与控制智能体(Steer the agent) 完全自主并不总是合适。在执行具有重大影响的动作前暂停执行,等待人类审核批准、拒绝或重定向指令。 HumanInTheLoopMiddleware
控制运行成本(Control costs) 提示词缓存(Prompt caching)能降低长运行任务的 Token 开销。调用上限控制则能防止成本无节制累积。 ModelCallLimitMiddleware、ToolCallLimitMiddleware、PromptCachingMiddleware

完整的预置中间件定义与说明可查阅官方的 Prebuilt Middleware 参考文档。


任务与底座适配(Task-Harness Fit):检验你的自定义 Harness

Task-harness fit(任务与底座适配度),衡量的是 Harness 对业务任务真实需求的匹配程度:它需要的具体上下文(the context it needs)、可能遭遇的故障类型(the failures it'll encounter)、必须强制执行的安全合规策略(the policies it must enforce),以及它赖以运转的宿主环境(the environment it operates in)。正如前文所述,一个客服 Agent 与一个长周期运行的编程 Agent,其 Harness 构造截然不同。

LangChain 在文章中列举的三个自建 Agent,都基于 create_agent 并为各自任务装配中间件栈:

  • GTM agent;
  • Open-SWE,异步代码智能体(Asynchronous coding agent);
  • Fleet,无代码智能体构建器(No-code agent builder)。

好的智能体不只依赖能力强大的模型,也依赖与具体任务高度契合的 Harness。LangChain 给出的直接做法,是使用 create_agent 配合中间件打造这种自定义底座。

自定义 Harness 最小设计自查清单

在将这些原理带回你的业务场景时,可以通过以下源自原文四个维度与能力图谱的问题进行快速自查:

  1. 上下文与记忆(Context & Memory):
    • 任务是否涉及长运行会话?是否需要配置上下文总结或编辑中间件防止窗口溢出?
    • 智能体是否需要在启动时加载外部知识/技能,并在运行结束时将新经验写回记忆?
  2. 故障容错与成本(Failures & Costs):
    • 当外部模型或工具发生不可预测的瞬态故障时,是否配有退避重试与回退模型中间件?
    • 是否配置了提示词缓存以降低长任务 Token 成本?是否设置了模型与工具的调用次数限制,避免成本持续累积?
  3. 策略约束与人工控制(Policies & Steering):
    • 业务中是否有 PII 脱敏或合规审查等规则?它们是否已通过中间件在每次调用中强制执行?
    • 面对高影响或敏感动作,是否配置了暂停并等待人类批准、拒绝或重定向的人在回路机制?
  4. 运行环境与任务协同(Environment & Delegation):
    • 智能体是否需要突破固定工具集,接入文件系统、命令行或代码解释器环境以提高行动与 Token 效率?
    • 面对复杂的长任务,是否需要将其拆解并委托给具备独立干净上下文的子智能体或由待办列表跟踪?
    • 工具的依赖、初始化设置(setup)与结束清理(teardown)是否已交由中间件治理?
    • 输出流是否需要分别处理:让前端消费 Token 增量、审计留存工具调用、监控追踪耗时延迟?

拓展资源与参考链接

官方指南与文档

来源
How to Build a Custom Agent HarnessSydney Runkle·2026-06-03·查看主材料
↑ 正文结束
✓ 本篇全文免费开放

会员可复制、下载全文 Markdown,还能让你的 AI 订阅和提问。

阅读原文 ↗
📮 新解读第一时间进邮箱

读完觉得有用?留个邮箱,每篇新解读发布就送达,随时退订。