Agent Harness 解析：一个 Agent 到底由什么构成？

原文：The Anatomy of an Agent Harness
作者：Vivek Trivedy（LangChain）
整理日期：2026-04-19

核心公式

Agent = Model + Harness

模型是大脑，Harness 是让大脑能干活的一切基础设施。

你说”我做了一个 Agent”，其实是说”我做了一个 Harness，然后把模型接进去了”。

“If you’re not the model, you’re the harness.” —— Vivek Trivedy, LangChain

为什么需要 Harness？

裸模型只能做一件事：吃文本，吐文本。它天生不能：

跨会话保持状态
执行代码
访问实时信息
自己安装依赖、配置环境

这些全是 Harness 的活。

一个精准的类比

计算机组件	Agent 对应物
CPU	模型（LLM）
RAM	上下文窗口
磁盘	外部数据库
设备驱动	工具（Tools）
操作系统	Harness

Harness 不是 prompt 的包装，是让自主 Agent 行为成为可能的完整系统。

三层工程的层级关系

┌─────────────────────────────────────────┐
│           Harness Engineering           │
│  ┌───────────────────────────────────┐  │
│  │       Context Engineering        │  │
│  │  ┌─────────────────────────────┐ │  │
│  │  │     Prompt Engineering      │ │  │
│  │  └─────────────────────────────┘ │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

Prompt Engineering — 写给模型看的指令
Context Engineering — 管理模型在什么时候看到什么
Harness Engineering — 包含以上两层，再加上工具编排、状态持久化、错误恢复、安全执行、生命周期管理

生产级 Harness 的 11 个核心组件

1. 编排循环（Orchestration Loop）

Harness 的心跳。实现 Thought-Action-Observation（TAO）循环，也叫 ReAct 循环：

组装 prompt → 调模型 → 解析输出 → 执行工具 → 把结果喂回去 → 重复

Anthropic 把自己的 runtime 叫”dumb loop”——智能在模型里，Harness 只管轮转。

2. 工具（Tools）

模型的”手”。以 schema 形式（名称、描述、参数类型）注入上下文，让模型知道有哪些能力可用。

Harness 负责：注册、参数校验、沙箱执行、把结果格式化回 LLM 可读的 observation。

Claude Code 的工具分六类：文件操作、搜索、执行、Web 访问、代码智能、子 Agent 派生。

3. 记忆（Memory）

分两个时间尺度：

短期记忆：当前会话的对话历史
长期记忆：跨会话持久化

各家实现：
– Anthropic：CLAUDE.md / MEMORY.md 项目文件
– LangGraph：namespace 组织的 JSON Store
– OpenAI：SQLite 或 Redis 支持的 Sessions

Claude Code 的三层记忆架构：轻量索引（每条约 150 字符，始终加载）→ 按需拉取的详细主题文件 → 仅通过搜索访问的原始对话记录。

4. 上下文管理（Context Management）

很多 Agent 悄悄挂掉的地方。

核心问题：Context Rot（上下文腐烂）——关键内容落在窗口中间位置时，模型性能下降 30%+。即使是百万 token 窗口也不免疫。

生产级策略包括：压缩、摘要、选择性保留、滑动窗口等。

5. 文件系统（Filesystem）

最基础的 Harness 原语，解锁了：

Agent 有工作区可以读写数据、代码、文档
跨会话保存中间结果，不用把所有东西塞进上下文
多 Agent 协作的天然共享面

Git 在文件系统上加版本控制，让 Agent 能追踪工作、回滚错误、分支实验。

6. Bash + 代码执行（Code as General-Purpose Tool）

与其为每种操作预先设计工具，不如给 Agent 一个通用工具：bash。

模型可以即兴编写代码来解决问题，而不受预配置工具集的限制。代码执行已成为自主问题解决的默认通用策略。

7. 沙箱执行环境（Sandbox）

Agent 生成的代码不能直接跑在本机。沙箱提供：

安全隔离的执行环境
按需创建、扇出多任务、完成后销毁
预装语言运行时、包管理器、CLI 工具、浏览器等

8. 记忆与搜索（Memory & Search）

Agent 需要访问训练截止日期之后的信息，以及超出上下文窗口的历史知识。

解决方案：向量数据库 + 语义检索，在需要时把相关知识注入上下文。

9. 错误处理与护栏（Error Handling & Guardrails）

工具调用失败、输出格式不对、任务跑偏——这些都要 Harness 兜底。

包括：重试逻辑、格式校验、命令白名单、网络隔离、安全边界强制执行。

10. 多 Agent 编排（Multi-Agent Orchestration）

单个 Agent 处理不了的复杂任务，需要子 Agent 派生、任务分发、结果汇总。

Harness 负责：子 Agent 生命周期管理、任务路由、模型选择、结果聚合。

11. 生命周期管理（Lifecycle Management）

Agent 运行的完整生命周期：启动、暂停、恢复、超时、清理。

包括会话持久化、断点续跑、资源回收等。

关键结论

Harness 工程才是 Agent 能力的真正决定因素。LangChain 仅改变基础设施（同一模型、同一权重），在 TerminalBench 2.0 上从 30 名开外跳到第 5 名。
“我做了一个 Agent”= “我做了一个 Harness”。Agent 是涌现出来的行为，Harness 是产生这种行为的机器。
上下文管理是最容易被忽视的短板。很多 Agent 在 demo 时表现良好，任务超过 10 步就开始悄悄失败，根源往往在上下文管理，不在模型本身。

整理自 LangChain Blog & Daily Dose of Data Science，2026-04-19

The Anatomy of an Agent Harness解析