引言：为什么模型越来越强，但Agent还是不够好用？
2026年，当你打开各家厂商的大模型产品时，会发现一个有趣的现象：模型的benchmark分数越来越接近，但Agent产品的体验却天差地别。
同样是接入GPT-4或通义千问，为什么Claude Code能连续工作数小时完成复杂编程任务，而你自己搭的Agent用不了几分钟就"失忆"了？为什么OpenClaw可以7×24小时自动处理邮件、监控股票，而大多数聊天机器人只能完成简单问答？
答案就藏在《Harness工程：从上下文管理到Agent系统构建》这本书的核心公式里：
Agent = Model + Harness
Harness（马具），指的是模型之外的一切工程能力：上下文管理、工具调度、任务编排、记忆系统、安全控制……这才是决定Agent能否真正落地的关键。作者邢云阳用175,000字的篇幅，系统性地回答了一个问题：如何为大模型构建一个理想的工作环境？
一、核心洞察：上下文工程才是Agent的灵魂
从一个购车案例说起
书中第1章用了一个非常生动的例子。一位朋友想买新能源车，直接问通义千问："理想L6怎么样？"，得到的回复充满了"增程""激光雷达"这些术语，完全没法帮助决策。
但当他补充了完整的上下文后：
- 通勤距离：30公里
- 家庭人数：5人（需要带老人小孩）
- 预算范围：20-25万元
- 持有周期：8年左右
- 核心诉求：底盘调校、安全性、电池续航
- 已完成试驾，知道电池是宁德时代/欣旺达混发
这一次，模型给出了精准且实用的建议。
这个案例揭示了一个本质：LLM本身是无状态的，它需要足够丰富且精准的上下文才能给出有价值的回答。而上下文工程要解决的，就是如何系统化地构建、管理和动态演化这些上下文。
上下文工程的四大模块
作者在第1.2节提炼出了上下文构建的标准流程：
1. 感知模块（意图识别）
- 将模糊的自然语言转换为结构化任务描述
- 根据意图匹配最合适的模型（如豆包做多模态、GLM做代码）
- 实战方案：Arch-Router轻量级路由模型 + 业务小模型微调（第2.1节）
2. 规划模块（计划模式）
- 生成解决问题的思维链
- 方法论：ReAct（推理-行动）、PlanAct（预生成完整计划）、Sequential Thinking（多轮自主规划）
- 完整代码：基于LangGraph的旅游攻略生成器（第2.2节）
3. 执行模块（CodeAct模式）
- 调用外部API或运行代码获取实时数据
- 核心思想：把整个编程语言视为一个通用工具，让LLM直接生成代码而非调用预定义函数
- 典型场景：运维脚本生成、数据分析、图表绘制（第2.4节）
4. 反思模块
- 对规划和执行结果进行自我检查
- 发现错误或不完善的地方，触发重新规划
- 案例：运维命令生成+合理性审查（第2.3节）
这四个模块构成了Agent的"元驱动"。书中第2章用了整整900行代码，把每个模式都实现了一遍，包括Human-in-the-loop（人机回环）这种在生产环境必不可少的机制。
二、从搜索到研究：DeepResearch的技术跨越
RAG的局限性
在2025年之前，提升LLM准确性的主流方案是RAG（检索增强生成）。它的核心流程是：
- 把文档切分、向量化，存入向量数据库
- 用户提问时，用问题向量搜索相似文档
- 把检索结果和问题一起发给LLM
但RAG有个致命问题：召回率低。即便数据库里有相关信息，也可能因为用户表达模糊或向量偏移而检索失败。更关键的是，RAG是被动检索，无法像人类研究员那样主动追问、交叉验证、深挖细节。
技术演进路径
DeepResearch：模拟人类研究员的工作模式
第3章是全书最精彩的部分之一。作者用3000多行代码，从零构建了一个完整的DeepResearch系统，核心架构包括三个模块：
思考与决策模块
- 任务拆解、逻辑推理、结果反思
- 技术支撑：Sequential Thinking（顺序思维MCP Server）
信息搜索模块
- 联网检索：博查（Bocha）AI搜索引擎
- 备选方案：SearXNG开源聚合搜索引擎（支持私有化部署）
报告输出模块
- 将多轮搜集的信息整合为结构化文档
- Streamlit前端实时展示推理过程
工作流程完整展示了"研究"的闭环：
初始探索 → 评估信息完整性 → 识别矛盾点/缺口
→ 生成针对性搜索指令 → 再探索 → 再评估
→ 循环直至信息充分 → 整合生成报告
真实案例测试：
用户提问："即梦Seedance2.0最近为什么火？其相关的概念股有哪些？走势怎么样？"
系统连续触发了9次工具调用，严格遵循"先思考→后搜索"的范式：
- Sequential Thinking分析问题维度
- 搜索Seedance 2.0技术特性
- 反思：信息不足，需要了解市场反应
- 搜索相关新闻报道
- 反思：需要明确概念股范围
- 搜索A股AI概念股
- 交叉验证哪些公司与Seedance有业务关联
- 搜索这些股票的走势数据
- 最终生成包含技术解析+市场表现的完整报告
这个过程耗时数分钟，但生成的报告具备了实时性（最新数据）、深度性（多维分析）和准确性（交叉验证）。
三、记忆工程：让Agent拥有"长期记忆"
为什么Agent需要记忆？
LLM本质上是无状态的：每次API调用都是独立计算，模型不会自动保留历史对话。这导致了四大问题：
- 上下文丢失：长对话中早期信息被截断
- 个性化缺失：无法持续捕捉用户偏好
- 学习能力受限：难以从过往交互中提取反馈
- 逻辑一致性难维持：多轮对话容易前后矛盾
书中用一个简单的代码实验验证了这一点：
- 第一次对话："大明的儿子叫小明"
- 第二次对话："小明的爸爸是谁？"
- LLM回答："我不知道"
因为两次调用相互独立，第二次调用的上下文里根本没有第一次对话的信息。
短期记忆：上下文注入
解决方案是把历史对话重新封装进新请求：
messages = [
{"role": "user", "content": "大明的儿子叫小明"},
{"role": "assistant", "content": "好的，我了解了"},
{"role": "user", "content": "小明的爸爸是谁？"}
]
这次LLM能正确回答了。但这种方式有致命缺陷：上下文窗口有限。随着对话增多，全量携带历史记录会导致：
- Token成本激增
- 最终触及窗口上限（如Qwen3-Max为256KB）
因此需要优化策略：
- 滑动窗口：只保留最近N轮对话，或通过算法剔除无关片段
- 上下文压缩：利用LLM对历史记录进行摘要（Claude Code的/compact命令就是这个原理）
长期记忆：基于Mem0的混合存储
第4章花了近6000字详细讲解Mem0这个GitHub上近5万Star的开源记忆框架。它的核心设计非常巧妙：
多层级架构：
- 对话层：单轮对话的临时上下文
- 会话层：一次会话的任务连续性
- 用户层：永久存储的用户画像
记忆生命周期：
阶段1：语义提取
- 内部提取Agent过滤无关闲聊
- 捕捉7类结构化事实：个人偏好、重要信息、计划意图、服务偏好、健康信息、专业信息、杂项
阶段2：冲突仲裁
- 将新事实与既有记忆比对
- 执行ADD（新增）、UPDATE（更新）、DELETE（删除）、NONE（跳过）四种操作
- 例如："喜欢黑咖啡" → "只喝冰美式"（UPDATE）
阶段3：混合存储
- Qdrant向量数据库：基于语义相似度检索（擅长模糊匹配）
- Neo4j图数据库：基于关系推理（擅长逻辑链追踪）
为什么需要图数据库？作者举了个例子：查询"用户喜欢的饮品类别"时，图存储能通过"咖啡→饮品"的关系链实现精准推理，而单纯的向量检索可能漏掉这种逻辑关联。
实战验证：
书中提供了完整的分布式部署方案：
- Qdrant 3节点集群（满足多数派共识）
- Redis缓存层（读缓存+写失效策略）
- Docker Compose一键部署
- 完整的Python客户端代码
测试场景：构建一个记住用户信息的聊天助手
- 第一次会话：用户告诉AI自己的家庭信息、工作情况
- 第二次会话（使用相同user_id）：AI能主动调用记忆，准确回答"我儿子喜欢喝什么？"
四、Skills：上下文卸载的艺术
67,000 Token的困境
第5章开篇就抛出一个真实案例：某开发者配置了7个MCP Server，共接入100多个工具。结果在用户还没输入任何问题之前，仅工具描述信息就占用了67,000+ Token，相当于上下文窗口总长度的33%。
这意味着，即便是最简单的对话——用户问"1+1=？"Agent回答"2"（共5个Token），其上下文开销也高达13,400倍。
Skills的三级渐进式加载
Skills本质上是为Agent制作的专家经验包，类似于企业的标准作业程序（SOP）文档。它的结构非常简单：
skill-name/
├── SKILL.md # 必选：技能说明书
├── scripts/ # 可选：可执行代码
├── references/ # 可选：参考资料
└── assets/ # 可选：模板文件
关键创新在于加载机制：
L1级：仅加载标签
- 时机：Agent初始化时
- 内容：name、description、tags
- 占用：每个Skills约50-100 Token
L2级：读取说明书
- 时机：判断Skills可能适用时
- 内容：SKILL.md完整正文（使用说明、执行步骤）
- 占用：几百到上千Token
L3级：按需加载资源
- 时机：实际执行过程中
- 内容：scripts/代码、references/文档、assets/模板
- 特别注意：代码不会进入LLM上下文，而是由Agent的Bash工具直接执行，仅将运行结果返回LLM
这种设计的精妙之处在于：即便一个Skills打包了数百个工具定义、完整的数据字典或上百页的参考手册，只要当前任务不需要，这些内容就不会进入LLM上下文。
零代码开发运维巡检Skills
第5.2节展示了如何使用"扣子编程"（字节跳动的AI开发平台）通过自然语言对话生成一个完整的Skills。
输入提示词：
帮我编写一个"运维巡检Skill"，可以自动进行服务器的巡检
（检查CPU、内存、磁盘、Docker容器状态），并输出一份巡检报告。
要求包含SKILL.md的五个关键部分：
1. 定时机（什么场景下激活）
2. 立目标（核心问题）
3. 理规则（执行逻辑）
4. 给示例（输入-输出对）
5. 划边界（能力边界与限制）
AI自动生成：
- 完整的SKILL.md（含元数据、使用说明）
- scripts/collect_system_info.py（使用psutil库采集系统指标）
- references/inspection-standards.md（健康阈值标准）
实际测试（在OpenClaw上运行）：
- 部署：将Skills文件夹放入
/usr/lib/node_modules/openclaw-cn/skill - 验证：发送"你是否存在ops-inspection这个Skill" → 确认已加载
- 执行：发送"使用该Skill执行一次巡检" → 生成详细报告
整个过程没有编写任何运维脚本，没有配置告警推送，也没有手动调度任务——仅通过自然语言对话，就完成了传统运维中需要数小时编码的工作。
五、复现Claude Code：Harness工程的典型范例
核心哲学：为模型构建理想环境
第6章是全书的高潮。作者通过逆向工程，复现了Claude Code的核心特性，揭示了Anthropic的设计哲学：
"不再通过堆砌大量工具或构建复杂工作流来硬性引导模型，而是根据模型的需求来封装环境能力。"
具体体现在四个维度：
1. Agent Loop：一个Agent = 一个Loop + 一个Bash工具
核心观点：随着LLM编程能力的提升，最高效的交互方式不是为其配置大量工具，而是让LLM直接生成代码并通过Bash执行。
Bash工具实现的关键设计：
- 安全防线：黑名单拦截
rm -rf /、sudo等危险命令 - 超时控制：120秒timeout，防止死循环卡死
- 输出截断：限制50,000字符，避免撑爆上下文
- 错误捕获：合并stdout和stderr，返回统一格式
while True循环：
def agent_loop(messages):
while True:
response = send_messages(messages)
if response.tool_calls != None:
# 调用工具（如run_bash）
messages.append(工具调用结果)
else:
break # LLM认为任务完成，退出循环
这就是Agent能"持续工作"的秘密：不是一问一答，而是一个自动化的推理-行动-观察闭环。
扩展工具集：
在Bash基础上，Claude Code还提供了Read、Write、Edit这3个核心文件操作工具。作者提供了完整实现，包括：
- 路径安全检查：防止
../../etc/passwd这类路径穿越攻击 - 自动创建目录：Write工具会自动创建不存在的父目录
- 精确替换：Edit工具仅替换第一个匹配项，防止误改
测试结果：仅凭这4个工具，Agent就能完成文件创建、内容编辑、代码执行等复杂操作。
2. SubAgent：分离上下文窗口
核心问题：在单Agent架构中，随着任务复杂度提升，上下文会被大量的中间推理过程、工具调用日志填满，构成"上下文噪声"。
解决方案：
将Agent本身视为一种特殊工具。主Agent遇到复杂任务时：
- 调用
run_subagent(prompt)工具 - 系统动态生成一个临时SubAgent
- SubAgent在独立上下文中完成任务
- 任务完成后，仅向主Agent汇报摘要
- SubAgent销毁，内部细节不回流污染主Agent
代码实现的关键设计：
- 独立的消息历史：
sub_messages - 最大轮次限制：
max_rounds = 30（防止死循环） - 相同的工具集：Bash、Read、Write、Edit
- 返回最终结果：
return sub_messages[-1]["content"]
实测效果：
用户："使用SubAgent创建一个test.py，并写入hello world代码"
- 主Agent识别任务，调用Agent工具
- SubAgent接管：Write创建文件 → Bash执行测试 → 验证通过
- 主Agent收到摘要："已成功创建'test.py'文件并写入打印'hello world'的代码"
主Agent的上下文中只有这一句话，而SubAgent内部可能进行了多轮操作。
3. Compact：三级上下文压缩
压缩策略：
L1：微缩旧工具调用
- 保留最近N个工具调用的完整返回
- 旧调用替换为占位符：
{"role": "tool", "content": "[Previous: used get_weather]"}
L2：自动摘要压缩
- 触发条件：Token数超过阈值
- 操作：完整对话存盘 → LLM生成摘要 → 用摘要替换历史
L3：Agent主动压缩
- 提供Compact工具
- LLM判断需要压缩时主动调用
这三级策略确保了即便在数小时的长任务中，上下文也不会溢出。
4. Skills：渐进式加载
第6.2.2节演示了如何在Agent中集成Skills机制：
SkillLoader类：
_load_all()：递归扫描skills目录，解析SKILL.md的YAML Frontmatterget_descriptions()：返回所有Skills的简短描述（一级加载）get_content(name)：返回指定Skills的完整内容（二级加载）
系统提示词集成：
你是在 {WORKDIR} 目录下的编程代理。
在处理不熟悉的话题之前，先使用load_skills获取相关的专业知识。
可用Skills：
- keyword-research: 发现高价值关键词 [SEO, 营销]
- competitor-analysis: 竞争对手分析 [市场研究]
...
测试验证：
用户："我要写一篇关于2025年AI在医疗行业的落地情况的报告，请帮我进行关键词的搜索"
- 一级加载：Agent看到4个SEO相关Skills
- 二级加载：调用
load_skills("keyword-research")，获取详细说明 - 按照Skills指引，输出高质量的关键词研究报告
六、关键洞察与实践建议
为什么Harness比模型更重要？
作者在全书中反复强调一个观点：
"主流厂商在演示Agent产品时，不再仅仅展示单轮问答的能力，而是反复强调其能够连续运行数小时、整夜执行任务、实现无人值守。"
这种能力的跃升，不是因为模型变聪明了，而是因为Harness变强了：
- DeepResearch能运行数十分钟 → Sequential Thinking提供了深度思考能力
- Claude Code能连续编码数小时 → Agent Loop + Compact保证了上下文不溢出
- OpenClaw能24小时自动化 → 任务管理 + 持久化 + 定时调度
模型的作用是"大脑"，但Harness提供了"身体"（工具执行）、"记忆"（长短期存储）、"耐力"（上下文管理）和"安全保障"（权限控制）。
从堆砌工具到构建环境
传统Agent开发的误区是：给模型配置100个工具，希望它能自动选对。但这会导致：
- 工具描述占用大量上下文
- LLM选择困难，经常调错工具
- 维护成本极高，每个工具都要精心设计描述
Claude Code的做法是：只给9个基础工具（Bash、Read、Write、Edit、Glob、Grep、WebSearch、WebFetch、AskUserQuestion），但这9个工具组合起来，能完成几乎所有文件操作、系统调用和信息检索任务。
关键在于：不是工具越多越好，而是工具的"通用性"和"组合能力"越强越好。
三个实践建议
1. 从简单开始，按需迭代
不要一上来就搭建完整的分布式记忆系统+多Agent编排。先实现：
Agent Loop + Bash + Read/Write + 系统提示词
这就够跑通大部分任务了。然后根据实际需求逐步添加：
- 任务经常失败？→ 加入反思模式
- 上下文溢出？→ 加入压缩机制
- 需要领域知识？→ 加入Skills
2. 监控比优化更重要
书中虽然提供了完整代码，但在生产环境中，你还需要记录：
- Token消耗：每次对话用了多少Token？趋势如何？
- 成功率：多少任务一次完成？多少需要重试？
- 工具调用分布：哪些工具用得最多？是否需要优化？
Claude Code内部肯定有完善的监控体系，书中没讲这块，但这是工程化的必备环节。
3. 安全是生命线
赋予Agent Bash权限是一把双刃剑。书中的安全机制（黑名单、超时）只是最基础的防护。在真实生产环境中，还需要：
- 沙箱隔离：Docker容器 + 资源限制
- 权限最小化：只给必要的文件系统访问权限
- 审计日志：记录所有命令执行，方便追溯
- 人工审核：高危操作（如删除、网络请求）强制Human-in-the-loop
七、这本书适合谁？
强烈推荐
场景1：你在构建企业级Agent产品
- 需要处理复杂的多步骤任务
- 需要长时间运行（数小时甚至24小时）
- 对稳定性、可控性要求高
本书提供的架构设计（SubAgent、Compact、Skills）都是经过Claude Code验证的成熟方案。
场景2：你在做AI编程工具
- 需要读写文件、执行代码
- 需要理解大型代码库
- 需要持续交互而非一次性生成
第6章基本就是一个mini版Claude Code的实现教程。
场景3：你在做深度研究/数据分析类Agent
- 需要联网搜索
- 需要多轮信息整合
- 需要生成结构化报告
第3章的DeepResearch系统可以直接拿来改。
谨慎选择
场景1：简单的聊天机器人
- 只需要问答，不需要执行任务
- 对话轮次少（<10轮）
- 不需要记忆历史对话
这种场景直接调用LLM API就够了，Harness工程是过度设计。
场景2：对延迟极度敏感
- 需要秒级响应
- 不能接受多轮工具调用的耗时
Agent的多轮推理天生比单次调用慢，这是架构决定的。
场景3：资源受限环境
- 没有服务器部署Qdrant/Neo4j
- Token预算紧张
- 没有开发资源维护复杂系统
书中的方案都是面向"不差钱"的企业场景，个人项目可能承受不起成本。
结语：AI工程的下半场
2023年是"提示词工程"年，大家比拼的是谁能写出更巧妙的Prompt。2024年是"模型能力"年，各家厂商卷benchmark分数。而2026年，战场已经转移到了Harness工程。
模型之间的差距在缩小（Claude 3.7 vs GPT-4.5 vs 通义千问Max在大多数任务上表现接近），但Agent产品的体验差距在拉大。原因很简单：模型是商品化的（买个API就行），但Harness是需要自己构建的。
《Harness工程》这本书最大的价值，不在于它教了你多少具体技术（LangGraph、Mem0这些工具都会更新换代），而在于它建立了一套系统性的思维框架：
- 上下文工程：如何为模型准备高质量输入
- 设计模式：意图识别、计划、反思、CodeAct、Human-in-the-loop的组合运用
- 资源管理：上下文压缩、记忆分层、Skills按需加载
- 安全与稳定：Agent Loop容错、工具权限控制、人机协作
当你掌握了这套框架，即便具体工具变了（比如从LangGraph迁移到其他框架），你依然知道该如何构建一个真正可用的Agent系统。
这才是"工程"的意义：不是教你使用某个工具，而是教你如何系统性地解决一类问题。
原书信息
- 书名：《Harness工程：从上下文管理到Agent系统构建》
- 作者：邢云阳
- 出版社：人民邮电出版社
- 出版时间：2026年3月
- 字数：175,073字
- 配套代码：https://github.com/xingyunyang01/harness
声明：本文所有论点均基于原书内容，代码示例均来自书中实际案例，案例描述与作者阐述保持一致。
评论区