Harness工程：从上下文管理到Agent系统构建

版权信息

书名：Harness工程 : 从上下文管理到Agent系统构建

ISBN：978-7-115-69795-0

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版  权

著    邢云阳

责任编辑 贾 静

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

内容提要

本书系统阐述从上下文工程到Harness工程（Harness Engineering）的技术演进路径，揭示AI Agent从工具调用到自主思考与协作的核心原理及工程落地方法。全书共7章，以通过Agent工程化的构建方式落地上下文与Harness相关技术为主线，帮助读者系统掌握构建具备理解、计划、反思与行动能力的Agent系统的完整方法论。

第1章、第2章系统介绍上下文工程的理论基础，涵盖意图识别、计划模式、反思模式、CodeAct行动及人机协作五大核心能力的工程化实战；第3章、第4章以DeepResearch 和记忆工程为典型案例，提供从搜索到研究的完整代码实现及分布式记忆系统部署方案；第5章阐述Skills上下文卸载艺术，并给出使用扣子编程开发“运维巡检Skill”及基于OpenClaw测试“运维巡检Skill”两个实战案例；第6章、第7章走向Harness工程，通过两个实践案例介绍如何复现Claude Code核心特性，以及如何构建OpenClaw类产品，实现技术整合与工程落地。每章均配有可落地的代码示例与真实场景案例。

本书既适合具备开发背景的工程师、架构师阅读，也适合希望提升AI Agent实战能力的技术人员参考。

前  言

当前，大语言模型（Large Language Model，LLM）的能力日益强大，不仅能够进行复杂的逻辑推理，甚至能写出超越大多数程序员水平的代码。然而，LLM本质上是一个“思考者”，而非“行动者”——它可以告诉你如何修改代码，却无法真正操作你的工程文件。

我们可以通过提示词让LLM生成一段代码，但如果希望它基于已有的工程进行代码阅读、搜索，或者将生成的代码真正写入文件，而不仅仅停留在对话框中，就必须为其配置工具，并赋予它调用工具的能力。此时，LLM便从单纯的模型进化为一套精心设计的工程系统，这便是AI Agent（智能体）。

但是，仅赋予模型调用工具的能力显然不够。代码编写并非一蹴而就，而是一个循环往复的过程：LLM需要阅读部分代码，思考编写逻辑，搜索相关上下文，再编辑代码。针对这一持续思考与调用工具的过程所进行精心的工程化设计，这便是Agent Loop（智能体循环）。

此外，LLM的上下文窗口是有限的。阅读十几个文件、进行数十次代码搜索，很快就会消耗数十万Token（词元）。即便是号称国产最强编程模型的GLM-5，其上下文长度也不过200k Token。因此，如何组织上下文，将最有价值的信息精准填入LLM的“工作记忆”中，便成为关键，这就是2025年业界广泛讨论的Context Engineering（上下文工程）。

进入2026年，Claude Code、OpenClaw等Agent产品的能力不断刷新认知，并带来实际的生产效率提高。这些产品中所用到的除上下文工程技术外的Sub Agent、任务管理、Agent Teams（智能体团队）等概念，本质上都是通过“模型之外”的工程手段，将LLM转换为能够处理复杂业务逻辑的AI Agent（以下简称Agent）。无论是模型上下文协议（Model Context Protocol，MCP）、上下文工程，还是任务管理、Agent Loop、Agent Teams、Skills（技能），这些工程手段都在做着“模型之外”的事情。它们的集合，被归纳为Harness Engineering（还未有公认的中文翻译，本书使用“Harness工程”）。正如第6章提出的：Agent = Model + Harness。

由此归纳，AI开发的路径便变得脉络清晰：要么深入研究LLM本身，设法提升其推理能力，或在同等能力下降低训练与部署成本；要么专注于Harness，让LLM能够在真实世界中完成更多有价值的任务。

业界正呈现出一个显著趋势：LLM之间的能力差距正在逐渐缩小。我们已经告别了2023年那种“同一句提示词在GPT上效果惊艳，换到其他模型上却差强人意”的时代。然而，面对同一个模型，为其配套不同的Harness，其表现却天差地别。这也解释了为什么在AI编程领域，越来越多的程序员开始告别自己更习惯使用的IDE类编程软件，转而拥抱Claude Code这类看似不太习惯的命令行工具。

本书正是在这一背景下诞生的。在写作过程中，经历了上下文工程、Coding Agent、Skills、OpenClaw、Harness等概念的相继兴起，每一次新概念的出现，都促使我重新审视并调整内容结构，力求将前沿、实用的技术体系，结合工程实践，清晰、毫无保留地呈现给读者。

主要内容

本书系统阐述从上下文工程到Harness工程的技术演进路径，揭示Agent从工具调用到自主思考与协作的核心原理及工程落地方法。全书共 7 章，涵盖从上下文构建与管理到 Harness工程实践的完整学习路径。

第1章　从提示词工程到上下文工程

本章从上下文工程与提示词工程的理论出发，系统阐述二者的区别与联系、上下文工程与Agent的关系，并梳理从简单工具调用型Agent到复杂深度思考型Agent的技术演进路线。

第2章　上下文的“元驱动”：意图识别、规划等模块的工程化实战

本章围绕意图识别、计划、反思、CodeAct、Human-in-the-loop五大设计模式，提供完整的代码实践，构建上下文管理的核心能力。

第3章　DeepResearch：基于深度思考Agent构建上下文的典型案例

作为2025年上半年备受瞩目的Agent工程化产品，DeepResearch融合了第2章介绍的设计模式，构建了深度思考型Agent范式，使得Agent产品从聊天机器人进化为能够运行数十分钟的深度研究助手。本章深度拆解DeepResearch这一代表性Agent产品，从原理到实现，带领读者从零构建DeepSearch与DeepResearch产品。

第4章　记忆工程：Agent系统的长短期上下文管理

记忆工程又称为记忆体，旨在应对LLM上下文长度有限等问题，帮助Agent系统更高效地进行上下文管理。本章介绍短期记忆与长期记忆的实现方案，围绕GitHub上获得近5万Star的项目Mem0展开深度讲解与实践，并涵盖基于容器的分布式部署实战。

第5章　Skills：上下文卸载的艺术

Skills是一项为Agent制作专家经验包的技术。其构建方式简单（多为提示词）、学习门槛低，但实战效果突出，深受AI开发者青睐。其采用的三级渐进式加载策略，完美实现了上下文卸载。本章详细讲解Skills的原理、机制、格式与构建技巧，并通过零代码开发运维巡检Skills，基于OpenClaw测试运维巡检Skills。

第6章　Harness工程实践：复现Claude Code核心设计模式

Claude Code虽为闭源的Code Agent产品，其代码泄露后有众多开发者通过逆向工程研究其原理。本章通过代码实践复现Claude Code中的Agent Loop、Bash、上下文压缩、SubAgent、任务管理等核心特性，帮助读者深入理解Harness工程的设计理念。

第7章　Harness工程实践：Claw类产品的设计模式解析与实践

OpenClaw（中文社区昵称“龙虾”）在Code Agent之上构建了Claw外壳，涵盖IM通信、调度编排、定时任务等特性，也是Harness工程的典型代表。本章基于轻量级项目NanoClaw，剖析OpenClaw类产品的核心原理与机制，并通过二次开发与部署实践，帮助读者掌握IM通信、调度编排等Harness工程能力。

配套资源

为方便读者学习，本书提供以下配套资源。

• 　配套源代码：可访问https://github.com/xingyunyang01/harness获取，也可在“异步社区”网站本书对应页面下载。

• 　配套视频：可在“异步社区”网站本书对应页面免费兑换观看。

• 　配套图片文件：本书的思维导图及书中插图，可在“异步社区”网站本书对应页面下载。

致谢

本书的写作历时4个月，其间AI领域风云变幻，新概念层出不穷。但我始终坚信，无论模型如何迭代，Harness工程作为连接模型与真实世界的桥梁，都将是未来AI应用工程师的核心竞争力。

希望本书能帮助读者在这一变革中，建立起清晰的技术视野与扎实的工程能力，从容应对Agent开发中的真实挑战。

邢云阳

2026年3月

第1章　从提示词工程到上下文工程

人工智能的发展正经历一场深刻的范式演进——从单纯的语言理解迈向系统化的语境构建。

在2025年之前，大语言模型（Large Language Model，LLM）凭借简单的提示词（Prompt）即可生成流畅且具有逻辑性的文本，这引发了技术社区的广泛关注。彼时，开发的核心范式主要聚焦于提示词工程（Prompt Engineering），即通过人工设计输入模板来引导模型输出。在这种模式下，人机交互的边界清晰，且呈现出明显的单向线性特征。

然而，随着应用场景的深入，传统的“提示-响应”模式逐渐暴露出其局限性。

• 意图偏移：模型难以通过单一指令准确捕捉复杂业务背后的真实意图。

• 长程记忆缺失：在长对话或多轮交互中，模型容易丢失初始任务目标。

• 逻辑断层：面对多步骤、跨领域的复杂任务时，模型往往因缺乏结构化引导而导致输出失控。

在此背景下，上下文工程（Context Engineering）应运而生。它不再仅仅关注单次提示词的优化，而是转向一个更本质的问题：如何系统化地构建、管理并动态演化LLM的输入语境？

上下文工程通过整合业务意图、任务需求、工具回调及历史记忆等多维信息，确保进入模型上下文窗口（Context Window）的数据具备精准性与结构化特征。这种范式确保了模型在处理复杂任务时，能够保持目标的一致性并实现高效协同。

基于从提示词工程到上下文工程的这一技术演进脉络，本章将系统引导读者深入理解以下3项内容。

• 上下文工程的本质内涵与核心原则。

• Agent在上下文工程中所扮演的关键角色。

• Agent自身的技术演进路径。

1.1 上下文工程的核心思想

本节将介绍上下文工程的核心思想。

1.1.1　从购车决策看上下文的构建

在深入分析技术细节之前，我们先看一个典型的生活决策场景：购买新能源汽车。

一位拥有10年燃油车驾龄的朋友计划换购一辆国产新能源汽车。由于对该领域缺乏了解，他尝试通过向通义千问（Qwen）模型提问获取建议，输入提问“理想L6怎么样？”通义千问随即生成了一段看似详尽的回答，如图1-1所示。

图1-1　通义千问模型的输出结果

由于朋友对“增程”“激光雷达”“智驾”等技术词汇缺乏背景认知，模型给出的回答虽然详尽，但多为通用型参数堆砌，因缺乏针对性而难以辅助朋友作出决策。针对这种因背景知识缺失导致提示词质量低下的问题，通过单纯修改提问的措辞收效甚微，真正的解决方案在于构建更完整的上下文。

我建议朋友在再次提问前，先完成以下信息补全工作。

• 明确边界条件：梳理通勤里程（如30千米）、乘员构成（如5人家庭）、预算范围（如20万～25万元）及持有周期（如8年）。

• 引入外部知识：通过专业汽车平台了解底盘调校、电池供应商（宁德时代/欣旺达）等核心信息。

• 实地反馈闭环：通过线下试驾获取直观感受，并将销售人员提供的具体信息整合进认知体系。

这些步骤本质上是外部信息的检索与整合过程。当车主基于上述信息构建了如下的进阶版提示词后，模型的输出结果发生了质的变化。

我是一个10年燃油车驾龄的老司机，平时用车主要是往返30千米的通勤。周末节假日偶尔会带老婆孩子和父母，共5口人自驾短途旅游。我的预算是20万～25万元。我对于智驾的要求不高，能实现自动泊车即可。我比较看中的是车企对于底盘的调教，驾驶操控性以及安全性。由于我买车会开8年左右，因此我对于电池的续航也比较看中。我已经在4S店完成了试驾，销售人员给我讲理想L6的电池是宁德时代和欣旺达两家供应商混发的。基于我的需求，你认为理想L6怎么样？

通义千问基于这段内容丰富的上下文，给出了更具参考价值的回答，如图1-2所示。

（a）

（b）

图1-2　修改提示词后的回答展示

通过这个购车案例，可以透视上下文工程的本质：它并非单纯的提示词润色，而是一套对信息进行系统化采集、过滤与组合的技术范式。购车思路总结，如图1-3所示。

图1-3　购车思路总结

首先，描述清楚真实的购车意图，将原本模糊的提问“××车怎么样”转换为对其具体用车场景的深入挖掘，如通勤距离、乘员构成、使用年限等核心需求。

其次，基于这些拆解出的需求维度，通过多源渠道主动获取信息。例如，在专业汽车平台观看直观的车型测评，查阅真实车主的使用反馈，并对关键参数与技术概念进行归纳整理。

最后，调用现实世界的工具（前往4S店试驾），通过亲身体验验证前期形成的认知，从而获得一手感知数据。

这一系列动作最终构建出一组高度结构化且与个人需求对齐的上下文信息。这组上下文不仅支撑了更精准的提示词生成，也形成了可复用的记忆单元。当积累多组这样的记忆后，LLM便能基于它们进行横向对比与推理，辅助用户高效筛选出最匹配的车型。

因此，上下文工程的核心理念在于：通过工程化手段，将用户模糊、简略的原始提示（如“×××怎么样？”）转换为富含精准上下文的高质量输入。通俗地讲，就是如何将一句话提示词转换成一篇包含需求、知识背景、思考等内容的几百字到上千字的“小作文”。这一过程通常包括意图识别、需求分解、多源知识检索、外部工具调用以及结构化记忆构建等关键步骤。最终生成的上下文增强型提示词，能够引导LLM输出更贴合用户真实需求、更具实用价值的回答。

1.1.2　上下文工程与Agent的关系

通过前文对购车案例的剖析，我们可以对“上下文工程”给出一个工程化的定义：“上下文”是输入模型的核心语义载体，而“工程”则是通过程序化、系统化的手段对这些载体进行动态构建与持续优化。

在当前的技术范式下，承担这一工程化任务的核心载体正是Agent。

具备AI开发经验的读者，对于ReAct（Reasoning and Acting，推理与行动）范式并不陌生。其核心逻辑如图1-4所示，当LLM接收到原始输入后，通过推理将其拆解为一系列子任务；随后模型选择合适的工具执行操作并获取反馈。

图1-4　ReAct的核心逻辑

这一过程的本质，其实就是一个动态构建与丰富对话上下文的过程。LLM 的每一次决策都极度依赖当前步产生的观察（Observation）并将其整合进上下文，从而驱动下一轮的推理。

尽管ReAct思想早在2023年（提示词工程盛行的时代）就已被提出，但不难发现，其本质正是一个动态构建和丰富对话上下文的过程：LLM始终基于不断演进的上下文进行推理，最终得出解决方案。

然而，在当时，单 Agent 系统大多停留在演示（Demo）或实验阶段，尚未大规模应用于复杂真实场景。因此，诸如上下文窗口溢出、推理路径偏离主题、记忆碎片化等因长程复杂交互引发的问题并未充分暴露，也未催生出对上下文进行系统性设计与管理的迫切需求——上下文工程这一概念自然也就尚未形成。

由此可见，工程方法的出现，往往源于实际应用落地过程中暴露出的真实痛点。

正因如此，我们可以将上下文工程进一步凝练为：Agent驱动的智能上下文构建。它不仅关注说什么，更强调如何系统地准备和演化说的内容，从而让LLM在复杂、开放的任务中真正发挥价值。

1.2 上下文工程的系统结构

在理解了核心思想后，开发者面临的现实问题是：一个成熟的上下文工程系统究竟由哪些组件构成？如果将提示词工程比作侧重表达技巧的“单兵作战”，那么上下文工程则是一场“多兵种联合作战”。它不再是单一的文本编写过程，而是一套集成了多种方法论的Agent协同系统。

1.2.1　上下文构建的四大模块

尽管Agent技术日新月异（如Manus、OpenClaw等工具层出不穷），但从上下文工程的视角来看，其核心逻辑始终围绕感知、规划、执行、反思这四大模块展开。

1．感知模块，精准锚定意图

感知模块是系统的入口，其核心任务是将非结构化的自然语言提问转换为结构化的任务描述，并理解其核心意图，从而路由到合适的处理模块。在工程化的层面，这个过程叫作意图识别。

例如，Agent系统可能接入了多种AI大模型：擅长多模态识别的Doubao-Seed-2.0-Pro、逻辑推理见长的Qwen3-Max或代码能力突出的GLM-4.7等。通过感知模块，系统能根据用户意图匹配最合适的模型，避免因模型选型错误导致的响应质量下降或不必要的Token开销。

2．规划模块，串联上下文执行逻辑

规划模块负责生成解决问题的思维链。由于一个问题解决过程通常要经过多轮规划和思考，因此该模块实际上是串起整个上下文构建的逻辑骨架。它决定了如何通过合理的步骤设计来完成用户的任务。目前业界有很多成熟的方法论支撑思考模块的工程化，比较常用的有如下几个。

• ReAct模式：通过“推理-行动-观察”的闭环，实现上下文的动态演进。

• PlanAct模式：预先生成完整计划或由人工注入标准作业程序（Standard Operating Procedure，SOP），驱动LLM按序执行。

• Sequential Thinking：这是一个开源的MCP（Model Context Protocol，模型上下文协议）Server，可以帮助LLM实现多轮自主规划与反思，显著提升复杂任务的处理成功率。目前，扣子（原扣子空间，扣子升级2.0版本后改名为扣子）等产品便是基于MCP Server进行思维链的构建。

3．执行模块，提供实时上下文

执行模块通过调用外部API或运行代码Agent（如Code Agent），获取物理世界的实时数据（如最新的行业参数、价格动态）。这是上下文工程中最具动态性的部分，每一次工具调用的返回结果都会被加工成新的上下文片段，实时推送到模型输入端，驱动下一轮推理。

4．反思模块，确保上下文信息不遗漏

“吾日三省吾身”，就是要通过对自己进行反思，从而思考自己做事是否有所纰漏，进而改正。反思模块要解决的也是类似问题，它会对规划和执行模块的结果进行反思，检查是否存在错误或者不完善的地方，进而提出改正意见并重新引导规划模块进行新一轮的规划。

在工程化层面，既可以自行通过反思提示词的设计为Agent提供反思能力，也可以借助Sequential Thinking工具完成从规划到反思的全部过程。

1.2.2　上下文管理的核心策略

由于LLM的上下文窗口有限，因此不能仅停留在上下文构建层面，还需要对上下文进行管理，从而使上下文窗口可以被高效利用。下面将从记忆管理和上下文卸载（Context Offloading）两个方面，介绍上下文的管理。

1．记忆管理

记忆管理解决的是LLM的上下文窗口有限，无法在长对话或多轮交互中持续保留信息的问题。记忆模块可以通过短期记忆和长期记忆相结合，确保在对话或任务中能记住之前的交互内容，避免重复提问或上下文断裂，提供连贯的用户体验。此外，记忆模块还可以维护用户的长期偏好、历史行为，以及从外部检索到的专业知识等信息。

在工程化层面，根据场景的需要，记忆（长期记忆或短期记忆）模块的构建可以有多种实现方法。例如，要实现短期记忆，可以将对话历史存储在内存中，供Agent系统临时使用。而实现长期记忆，则可以将历史对话存储在文件或者向量数据库中，然后基于RAG技术进行历史对话等信息的存取，例如，Mem0就是基于Agentic RAG进行的设计。

2．上下文卸载

在工程实践中，上下文并非越多越好。过剩的信息会造成噪声干扰，导致模型性能下降。因此，上下文卸载成为管理核心——即仅保留当前任务最相关的关键信息。

如图1-5所示，AI编程工具Cursor在进行复杂项目分析时，倾向于将详尽的分析结果写入独立的Markdown文件，而在当前对话窗口中仅保留文件路径和摘要。这种引用而非堆砌的方式有效抑制了上下文膨胀。

图1-5　使用Cursor进行复杂项目分析

其实，Skills（技能）也是上下文卸载的典范。Agent系统初始状态下仅加载Skills的元数据（包括名称、描述）；当确认需要调用该Skills时，才加载详细的说明书（SKILL.md文件）；若涉及更深层的操作，则进一步读取关联的资源文档。这种按需加载的方式避免了将太多暂时用不到的工具描述等信息加载到模型上下文中，从而有效减少对模型判断的干扰。

1.3 简单工具调用到复杂Agent：Agent技术发展路线图

本节将进一步梳理Agent技术自2023年以来的发展脉络，回顾其在架构、能力与应用场景上的关键演进，从而帮助读者进一步理解上下文工程是如何伴随着Agent技术的发展而不断演进的。

1.3.1　简单工具调用Agent的原理与特点

Agent的概念于2023年开始受到业界广泛关注。这一思路的提出，源于一个观察：尽管大语言模型（LLM）具备丰富的通用知识，但在处理垂直领域专业问题，或需要依赖实时信息的场景（如“今日北京天气状况如何？”）时，往往无法给出准确答案，甚至会生成看似合理、实则与事实相悖的模型幻觉内容。

为突破这一局限，研究者开始探索如何赋予LLM与外部环境交互的能力，即让模型不仅具备思考能力，还能主动发起行动。具体而言，就是通过调用外部工具（如数据库、API、搜索引擎等）获取最新、最具相关性的外部信息，并将这些信息融入模型的推理过程，进而显著提升回答的准确性、时效性与实用性。

1．Function Calling

在这一背景下，2023年6月，模型厂商OpenAI正式推出Function Calling（函数调用）技术，并在其GPT系列模型中提供原生支持。Function Calling的核心思想是在模型预训练或微调阶段，引入结构化的工具交互数据，使模型学会在适当情境下触发工具调用。典型训练样本如下。

1． [
2．  {"role": "user", "content": "查询北京明天天气"},
3．  {"role": "assistant", "tool_calls": [{"name": "get_weather", "arguments": {"location": "北京"}}]},
4．  {"role": "tool", "name": "get_weather", "content": "{\"temperature\": 22}"},
5．  {"role": "assistant", "content": "北京明天气温22℃"}
6．]

通过此类训练，模型逐步掌握了工具调用的能力——即在推理过程中识别用户意图、选择合适的工具、构造规范参数并发起调用。这标志着LLM从纯文本生成器向可行动的Agent迈出了关键一步，也为后续Agent架构的发展奠定了技术基础。

由于Function Calling通常依赖于在预训练或微调阶段对模型进行专门的结构化训练（如前述的工具交互数据格式），其技术门槛较高，涉及模型架构、训练数据和推理引擎的深度协同。因此，并非所有LLM都原生支持Function Calling，在相当长一段时间内，只有少数头部厂商提供了成熟的Function Calling支持。

此外，即使在原生支持Function Calling的LLM中，LLM的对话输出内容也仅限于工具调用指令（包括工具名称与结构化参数）和最终回答文本这两类。

而LLM在决策过程中的内部推理逻辑，如“为何选择此工具而非彼工具”等关键思考步骤，对开发者而言仍然是一个黑盒。这种不可见性不仅限制了系统的可解释性，也增加了调试、优化和安全审计的难度。

2．ReAct

为了解决Function Calling的这两个问题，从而构建实用的Agent，研究者将目光投向了无须修改模型结构或重新训练的方案。其中，2023年发表的论文ReAct: Synergizing Reasoning and Acting in Language Models提出的ReAct设计思想迅速在AI开发圈内实现了工程化，时至今日仍是Claude Code等强大的Agent系统的核心底层范式。

ReAct的核心优势在于其零训练依赖。它不需要对模型进行任何预训练或微调，仅通过精心设计的提示词即可引导LLM在推理过程中交替执行思考（Reasoning）与行动（Acting），且LLM在推理阶段的思考内容，会在对话返回中与工具调用指令一起输出。具体而言，开发者只需构造一段包含任务目标、可用工具列表及交互格式的上下文模板，模型便能在运行时自主完成以下5个步骤的循环，流程示意如图1-6所示。

• 理解用户问题并进行推理。

• 决定是否需要调用外部工具。

• 选择合适的工具并生成调用参数。

• 接收工具执行后的结果反馈。

• 基于新信息更新上下文，继续推理或输出最终答案。

图1-6　ReAct流程示意

通过这一机制，即使是不具备内建工具调用能力的开源模型，也能在应用层实现动态感知与外部交互，从而构建出结构简单、部署灵活且效果可靠的轻量级Agent。

ReAct的出现，不仅降低了Agent开发的门槛，也为上下文工程提供了早期但极具启发性的实践范式——它证明了：高质量的上下文设计本身，就是一种强大的工程化智能。

1.3.2　深度思考型Agent的原理与特点

随着Agent在实际生产环境中的广泛应用，开发者逐渐意识到仅依赖ReAct模式构建Agent已无法满足日益复杂的业务需求。ReAct范式虽然在初期展示了其灵活性和易用性，但也暴露出若干局限性。

• 对LLM自身能力的高度依赖：ReAct流程的成功与否，高度依赖底层LLM的综合能力。若LLM的逻辑推理能力、指令遵循能力或格式化输出能力不足，则可能在推理环节生成错误规划，或在工具选择环节生成不符合格式的指令，导致整个流程中断。

• 执行效率问题：由于ReAct的循序渐进特性，完成一个任务通常需要多次调用LLM。每一次调用都伴随着网络延迟和计算成本，尤其对于复杂任务，这种串行的“思考-行动”循环可能导致较高的总耗时和费用。

• 提示词的脆弱性：整个机制的稳定运行建立在一个精心设计的提示词模板之上。模板中的任何微小变动，甚至是用词的差异，都可能影响LLM的行为。此外，并非所有模型都能持续稳定地遵循预设格式，这增加了在实际应用中的不确定性。

• Agent可能陷入局部最优：步进式的决策模式意味着Agent缺乏全局视角和长远规划。它可能会因为眼前的工具调用结果而选择看似正确但长远来看并非最优的路径，甚至在某些情况下陷入“原地打转”的循环中，无法有效推进任务进展。

鉴于上述挑战，开发者们开始探索新的Agent设计模式（也称为构建范式），以适应不同业务场景的需求。

1．Agent设计模式

常见的Agent设计模式包括以下几种。

（1）CodeAct模式。CodeAct是ReAct的一种重要衍生形式。其核心思想是将工具抽象为Python代码执行器，而非预定义的业务API（如高德地图、天气服务等）。在此模式下，LLM不再直接调用特定工具，而是根据任务需求生成可执行的代码片段（如Python脚本或Shell命令），作为参数传递给代码执行器运行。该模式特别适用于运维自动化、数据处理、系统诊断等场景。例如，一个运维Agent可以根据用户指令生成grep、awk或systemctl等Linux命令，交由执行器运行并返回结果，从而实现高度灵活的任务处理能力。

（2）计划-执行（Plan-Act）模式。为应对复杂任务中推理深度不足的问题，计划-执行模式引入了分阶段决策机制。系统首先由规划Agent对用户问题进行全局拆解，生成结构化的多步执行计划；随后，该计划被传递给执行 Agent，后者严格按照步骤调用工具、收集反馈并推进任务。这种先谋后动的策略显著提升了 Agent在长程、多跳任务中的逻辑一致性与完成率，同时减少了因局部决策失误导致的整体失败风险。

（3）反思（Reflection）模式。反思模式是一种事后校验与自我修正机制。在工具调用Agent完成初步执行后，一个独立的反思Agent会对其输出结果进行评估：检查是否存在逻辑漏洞、信息遗漏、工具误用或格式错误等问题。若发现问题，系统可触发重试、补充查询或调整策略，从而形成闭环优化。该模式有效提升了Agent的准确性与鲁棒性，尤其适用于对结果可靠性要求较高的专业领域（如金融分析、医疗辅助等）。

（4）人机协作（Human-In-the-Loop）模式。在关键决策节点或高风险操作中，完全依赖自动推理仍存在不确定性。人机协作模式通过在流程中嵌入人工干预点，允许人类在必要时审核、修正或确认Agent的行为。例如，在执行资金转账、发布生产环境变更等敏感操作前，系统可暂停并请求用户授权。这种“人在环路”的设计不仅降低了错误成本，也增强了用户对智能系统的信任感与可控性。

2．深度思考型Agent的出现

随着多种设计模式的出现，开发者开始不满足于Agent仅仅是耗时几分钟的短短数轮工具调用形式的对话，而是希望Agent能够自主进行长达几十分钟甚至几小时的任务执行，从而深入地完成一项任务。

基于这样的背景，深度思考型Agent（Deep- Thinking Agent）在2025年上半年成为各家研究的对象。例如，OpenAI的DeepResearch、智谱的沉思、扣子系列产品中的扣子等。这类Agent不再满足于对用户问题进行单轮工具调用或线性推理，而是通过融合Agent设计模式，构建一个持续迭代、自我修正的认知闭环，从而实现对复杂问题的系统性拆解与深度研究。

以Google Gemini团队发布的DeepResearch（架构见图 1-7）为例，其工作流程充分体现了深度思考型Agent的核心理念。

图1-7　DeepResearch架构

该系统首先通过多样性规划模块生成多个潜在的研究路径（例如，从不同角度定义问题、提出假设或选择关键词）；其次，利用联网搜索工具并行获取外部信息；再次，通过反思模块评估各路径的信息质量与相关性，淘汰低效分支，保留或合并高价值线索；最后，在多轮“思考–执行–反思”循环后，将碎片化信息合成结构清晰、逻辑严谨的最终报告。

这种深度思考机制使得Agent处理任务的能力远超传统问答类Agent系统，已达到企业级深度研究助手的水平——能够处理如“分析某新兴技术的市场前景与竞争格局”或“综述近 3年来某疾病治疗方案的临床进展”等高度开放、信息密集型任务。

1.3.3　以代码执行为主的Agent：Code Agent的原理与特点

2025年下半年以来，随着以通义千问的Coder模型、智谱的GLM-4.7模型为代表的模型代码生成能力的跨越式提升，一种以代码执行为主的新型Agent范式——Code Agent逐渐成为行业关注的焦点。许多开发者认为，这是当前阶段Agent的最优范式。

需要明确的是，Code Agent并不是Cursor或Claude Code等AI辅助编程工具（Coding Agent），而是一种以生成并执行代码为核心决策手段的Agent范式。它与传统的ReAct Agent（通过解析JSON触发工具）有着本质的区别。

下面通过一个简单的案例来对比两者的差异：假设为Agent配置一个加法工具函数calc()，并要求其计算从1加到100的结果。

如果是ReAct Agent，会进入漫长的对话循环处理流程，每一轮仅执行一次calc()函数，并将结果存入上下文，如图1-8（a）所示。计算1到100的累加需要进行99轮对话交互，这不仅极其低效，且极易因长程推理疲劳导致计数错误。

如果是Code Agent，则会由LLM直接构建一段包含循环逻辑的Python代码，如图1-8（b）所示。

1． result = 0
2． for i in range(1, 101):
3．    result = calc(result, i)
4． print(f"1加到100的和是: {result}")

随后，系统在受控的代码执行器中运行该段程序，一次性输出最终结果。

（a）

（b）

图1-8　ReAct Agent与Code Agent的对比

从两个Agent的表现来看，Code Agent的效率明显要比ReAct Agent高很多倍，这是Code Agent备受追捧的重要原因。

1.3.4　多Agent的原理与特点

近期有一个非常热门的技术叫作SubAgent。在中文语境中，它也常被称为子Agent或专家Agent，意指在 AI 系统中专门负责某一特定子任务或领域知识的专项 Agent，如天气查询Agent、地图助手Agent等。

典型的多Agent系统（Multi-Agent System，MAS）通常由多个SubAgent与一个协调者Agent（Manager Agent）构成。后者负责任务分解、调度分发、冲突仲裁与结果整合，而前者则专注于各自领域的高效执行。这种分而治之、协同作战的架构，已成为构建高阶智能系统的重要范式，尤其适用于需要跨领域知识融合与复杂流程编排的企业级应用场景。

在互联网上，许多资料将MAS的出现归因于单Agent在面对大量工具时难以准确选择合适工具，从而导致推理失败。这一观点不无道理——就像一位厨师面前摆着上百把功能各异的刀具，即便技艺高超，也可能因选择困难而效率低下。

然而，若从上下文工程的视角重新审视，MAS的本质在于解决上下文污染问题。上下文污染（Context Pollution），是指在单Agent架构中，随着任务复杂度的提升，该架构上下文会不可避免地混杂多种异构信息，包括问题的推理轨迹、可用工具的描述、工具调用的中间结果、多轮历史交互记录以及用户的原始意图等。这些信息虽各有用途，但若无结构化组织，便会相互交织、彼此干扰。

这种混杂不仅引入了大量认知噪声，削弱模型对核心任务的理解能力与聚焦能力，还极易导致上下文窗口迅速耗尽。尤其在处理多步骤、长周期任务时，Agent往往尚未完成问题求解，就因达到Token上限而被迫截断上下文，造成任务中断或输出不完整。

一个生活化的例子可以清晰地说明这一点。过去我们找财务同事小赵报销时，总会看到他的办公桌上堆满了差旅费、招待费、办公采购等各类票据，所有类型的报销单都涌向他一人，处理起来既繁重又容易出错。

但某天再去报销时，我们发现小赵升职了。他不再亲自处理每一张票据，而是将任务分派给两位下属：员工个人支付类票据交给小张，业务招待费交给小李。小张和小李各自专注于自己擅长的领域，高效完成初审；而小赵只需在两人审核完成后，点击确认流程即可。他的桌面从此整洁有序。在这个类比中：

• 小张和小李是两个专业化SubAgent，各自拥有干净、聚焦的上下文（仅包含与其任务相关的工具、规则与记忆）。

• 小赵则是协调者Agent，负责任务路由与结果整合，其上下文仅包含任务分配和任务执行结果。

• 整个系统通过上下文隔离，避免了不同类型任务之间的信息干扰，从根本上降低了认知噪声。

整个系统由一个Agent扩展为3个Agent，整体上下文长度扩展了3倍。因此，MAS不仅是分工协作的工程实践，更是上下文工程在复杂任务场景下的自然延伸。它通过构建多个语义边界清晰、上下文纯净的Agent单元，让LLM能在更可控、更专注的环境中发挥最大效能。

至此，本章已系统介绍了上下文工程的核心概念，厘清了其与Agent的内在关联，并梳理了Agent从早期简单工具调用（如ReAct）到现代复杂架构（如MAS、深度思考型Agent）的技术演进路径。