Agent Harness 到底是什么？从 Claude Code 源码拆解三层架构

2601_96073073

671人浏览 · 2026-05-21 16:07:41

2601_96073073 · 2026-05-21 16:07:41 发布

摘要： 本文基于播客《探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐》的深度转录笔记，系统梳理 Agent Harness 的核心概念、三层架构、Memory 方案演进，以及从 Claude Code 源码泄露中提炼的关键工程实践。

关键词： Agent Harness、Claude Code、Agent Native-Driven、上下文管理、Memory、智能体架构

1. 什么是 Agent Harness？

当我们在讨论 Agent 的时候，经常会听到一个词：Harness。

来新璐（Thinking Machines Lab 创始人）给出了一个极其简洁的定义：

“模型以外，都是 Harness。”

如果把大语言模型（LLM）比作一个聪明的大脑，那 Harness 就是它的身体、手脚和工具——没有 Harness，模型只能思考，无法行动。

概念	类比	说明
模型（LLM）	大脑	负责推理、决策、生成
Harness	身体 + 手脚 + 工具	让模型具备行动能力
Agent	大脑 + 身体的完整体	能思考、能行动的智能体

关于"Agent 的能力上限由谁决定"，来新璐的观点是"赞成一半"：

模型的智力是基础上限——模型越聪明，Agent 天花板越高
Harness 是能力放大器——同样的模型，好的 Harness 可以成倍放大能力

他的比喻很生动：“我们的智商在 120 到 170 之间，但可以通过健身、学武术，或者穿上机甲让自己更强大。Harness 就是那个机甲。”

2. 三层架构：执行层、上下文层、治理层

来新璐将 Harness 拆解为三个层次：

第一层：执行能力层（Action Layer）

为模型提供"行动"的能力：

工具类别	具体能力
文件系统操作	增、删、读、写、搜索
操作系统访问	执行系统命令、进程管理
语言解释器	Python、Node.js 等代码执行

⚠️ 常见陷阱： 工具配置需要与 Agent 角色绑定。比如"代码审查 Agent"应只配置只读工具，不能拥有删除或修改权限。

第二层：上下文环境层（Context Layer）

管理模型工作时的上下文、状态和记忆：

核心概念	说明
KV Cache	模型推理的缓存状态，影响速度和成本
Memory	长期存储用户偏好、历史经验、任务总结
上下文卸载	窗口满时，写入文档供下一个 Agent 加载

第三层：治理编排层（Orchestration Layer）

多 Agent 协同工作时的组织问题：

问题维度	具体问题
任务分配	编写代码的 Agent 和测试 Agent 如何协作？
并行化	哪些模块可以同时由多个 Agent 并行完成？
权限治理	测试 Agent 能否直接修改代码？

实际案例： 用两周时间协调大量 Agent 从 0 到 1 构建浏览器——执行层提供文件操作工具；上下文层通过文档记录传递子任务进展；治理层协调编写与测试 Agent 的分工。

3. Memory 方案演进与 Claude Code 的设计

Memory 是 Harness 第二层中最关键的子系统，目前分为三个阶段：

方案类型	实现方式	优缺点
完全规则式	知识图谱 + 向量搜索	结构化高，但不够灵活
半规则式	Unix 文件系统 + Markdown，Agent 增量更新	兼顾结构与灵活，Claude Code 采用此方案
完全模型驱动式	模型自主决定记忆的存取	理想方向，尚在探索

Claude Code 的 Memory 有两个核心机制：

实时交互更新（Stop Hook）： 每次 Agent 完成工作后，触发"影子 Agent"判断需要保存的信息，增量更新到 Markdown 文件
Auto-Dream（自动做梦）： 每天触发一次深层记忆整理——回顾对话、提取关键信息、纠正错误、合并重复，类似人类做梦时大脑的信息整理

4. Claude Code 源码泄露的三大关键发现

发现一：上下文压缩远比想象中复杂

策略	说明
清理垃圾信息	踢掉不必要的工具输出，腾出空间继续工作
预留上限	使用 80% 窗口容量，保留 20% 余量
文档交接	总结进展和目标，写入文档供下一个 Agent 加载

核心 trade-off：哪些信息保留、哪些丢弃、下一个 Agent 需要加载什么，这些设计都非常精妙。

发现二："模型即 Agent"贯穿始终

Claude Code 完全放弃了传统的"提示词流链条"做法：

传统做法	Claude Code 做法
程序员预先设想 Agent 每一步行为	给模型充分自由，让它自主决策
构建大的状态图	更多 text + action，更少控制
每一步指定模型该做什么	最多限制某些工具的调用权限

发现三：Skill 与 Memory 的边界模糊

Claude Code 中的"经验提取"机制和 Memory 更新机制遵循同一套哲学，两者交集空间很大，但总体都属于上下文层面的工程实践。

5. Agent Native-Driven vs Prompt Flow-Driven

这是当前 Agent 开发领域最核心的范式分歧：

维度	Prompt Flow-Driven	Agent Native-Driven
核心理念	用 Prompt 节点构建状态图，控制每一步流转	模型即 Agent，给工具和自由，让它自主完成
代表框架	LangGraph	Claude Code
开发方式	链式调用、条件路由、状态机	配置工具 + 上下文 + 权限，然后放手
控制程度	高度可控	更多信任模型
未来趋势	逐渐过时	成为主流

来新璐的判断非常明确：

“Prompt Flow-Driven 在未来会越来越不适用。Agent Native-Driven——即 Agent 即模型，模型即 Agent——会越来越清晰。”

6. 如何判断 Harness 的好坏？

判断标准	好的 Harness	不好的 Harness
自洽性	符合模型自回归的推理方式	随意裁剪上下文，导致 prompt caching 失效
正交性	不限制模型未来的能力提升	每一步指定模型该做什么，模型进步后反被束缚
上下文管理	最好的管理是"不做多余管理"	过度压缩、随意丢弃历史轮次

💡 核心原则：好的 Harness 应同时满足——① 与模型当前运行逻辑自洽；② 与模型未来能力进步方向兼容。

7. 总结

从 Claude Code 源码泄露到 Agent Harness 三层架构的提出，趋势非常清晰：

Agent 开发正从"编排控制"走向"信任模型"——更少控制，更多工具和上下文
Memory 是 Harness 最前沿的战场——从规则式到半规则式，最终走向模型驱动
上下文管理的核心是"不做多余管理"——与模型运行逻辑自洽比什么都重要
当前仍处于 Agent 模型的"婴儿期"——很多东西还没收敛，现在是技术红利期

本文内容来源： 小宇宙播客《探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐》

📝 关于本文的笔记整理：

这期播客 47 分钟，信息密度极高，涉及 Harness、Memory、上下文压缩等多个技术概念。我是用 Ai好记 把播客自动转录成了结构化笔记，再按概念维度重新组织，才写出这篇文章的。

Ai好记能做的事：把播客、视频、文章等非结构化内容，自动转录并生成可检索、可引用的结构化笔记。写技术博客时不用边听边记，直接在笔记里搜索关键词就能定位素材。亲测好用！