# 上下文工程的自然演进：从「聊天机器人」到「推理者」再到「Agent」 > 作者：晨旭｜发布：2025-10-18｜系列：AI技术理解 > 来源：https://chenxu.xin/writing/context-engineering-evolution 沿着 Chatbot 到 Reasoner 到 Agent 这条主线，拆解上下文工程的三大模块（Think 工具、RAG 演进、工具调用）与上下文窗口管理的四象限、三范式。 --- 过去一年，我们见证了 AI 智能体的爆发。但这条进化之路并非一蹴而就，它遵循着一条清晰的主线：从「聊天机器人」到「推理者」，再到「Agent」。 更有趣的是，在这条演进路径上，作为 AI 工程师和 PM 所面临的核心瓶颈，也发生了根本性的迁移： - 在聊天机器人时代，我们的挑战是「怎么把话说清楚」，这催生了提示工程。 - 在 Agent 时代，我们的挑战是「每一步该往上下文里放什么」，这催生了上下文工程。 今天就沿着这条主线，深度拆解这场演进背后的关键模块和工程范式。 ## 一、为什么：演进的主线 ### Level 1：聊天机器人（Chatbot） 这是我们最熟悉的起点。Chatbot 的核心是单轮或短多轮对话，它的表现好坏，强依赖于提示工程。我们所有的努力，无论是写清晰的指令、给 Few-shot 示例，还是优化输出格式，都是为了让模型能听懂，并给出稳定、可预期的输出。 ### Level 2：推理者（Reasoner） 当任务变得复杂，需要多步逻辑时，Chatbot 就不够用了。 我们不再满足于模型「直接给答案」，而是要求它「先想清楚」。于是，一系列引导显式推理的技术诞生了，如思维链（CoT）、自我一致性、后退提示和思维树（ToT）。这些方法的本质，都是在模型的上下文窗口中，为其强行开辟出一个「思考区」，让它在给出最终答案前，先进行逻辑推演。 ### Level 3：智能体（Agent） 这是当前的最前沿：Agent 不再是被动应答，它是在一个循环中自主使用工具、读写外部状态、长时程执行任务。 此时，核心瓶颈彻底从「怎么写提示」转向了「怎么管上下文」。因为 Agent 运行得越久、调用工具越多，其上下文窗口就越容易被海量的中间结果、对话历史、工具日志所淹没，导致上下文污染。 正如 Anthropic 和行业实战圈的共识：上下文工程的核心，就是在模型有限的注意力预算下，以最小的高信号信息集合，驱动模型产生期望的行为。 ## 二、是什么：上下文工程的三大模块 要实现从 L2（会思考）到 L3（会做事）的飞跃，Agent 必须解决三个核心的工程难题。 但在此之前，必须明确一个关键点：我们在 L1 阶段修炼的提示工程去哪了？ 答案是：它进化了。它不再是那个「直接写给模型看」的单一系统提示，而是渗透到了 L3 Agent 架构的每一个组件中，成为解决所有新难题的元技能。 ### 1、Think 工具：把思考产品化 L2 的思维链是隐式的，而 L3 的 Think 工具是显式的。它是一个被定义和调用的工具，专门用于「行动中的思考」： ```json { "name": "think", "description": "当需要复杂的推理时……使用该工具来思考某事。" } ``` 这和「延展思考」有什么区别？延展思考发生在 Agent 响应之前，用于制定顶层规划；Think 工具是在执行过程中的在途反思，是在 Agent 已经启动、并在与工具交互时，用来处理新发现的信息。 **提示工程在此处的进化**：Think 工具的成功，100% 依赖于提示工程。必须在系统提示中教会 Agent 何时以及如何使用它。 - 坏的提示：「你可以思考。」（Agent 不知道什么时候用） - 好的提示：「在调用任何会改变数据库的工具（如 `cancel_flight`）之前，你必须先调用 `think` 工具，在 `thought` 字段中列出你已核实的所有合规性规则（如：1. 24 小时内可退；2. 非促销票），确认无误后再执行。」 提示工程从「让模型好好说话」进化为了「为模型的思考过程制定 SOP」。 ### 2、RAG 的演进：从「优化内存」到「主动探索」 **（1）更好的 RAG：上下文检索** Agent 的决策依赖外部知识。传统 RAG 因「上下文丢失」（即 chunk 脱离了原文语境）而变得不可靠。 例如，一个 chunk 写着「该公司收入增长 3%」，但 Agent 根本不知道这是哪家公司、哪个季度。此时上下文检索（Contextual Retrieval）的作用，就是在预处理阶段用 LLM 为每一个这样的模糊 chunk 生成一段「微语境」： > 这是一段 chunk……请提供一个简短而精确的上下文语境，以便在整个文档中定位这个片段，从而改进 RAG 搜索检索效果。 我们通过这个提示，让 LLM 自己去修复 RAG 的上下文丢失问题。这个「一次性预处理提示」的质量，直接决定了整个 RAG 系统的上限。 但这个阶段的 RAG 还是被动的。我们只是在预处理阶段把「内存」做得更好了，Agent 还是在拉取我们喂给它的东西。 **（2）主动的 RAG：智能体搜索** 智能体搜索（Agentic Search）的核心转变是从「预先检索」进化到「即时搜索」。 Agent 不再依赖我们预先切好的、带语境的 chunks。相反，Agent 获得的是轻量级标识符（如文件名、API、数据库查询）和工具（如 `grep`、`glob`、`head`、`tail`），它在运行时自主决定要「看」什么。它不是在检索，它是在探索。 关键优势有两点： - **渐进式披露**：Agent 通过探索逐步发现上下文。它先用 `ls` 看看有哪些文件，通过文件名（如 `test_utils.py`）和路径（如 `/src/logic/`）来推理文件的用途，然后再决定是否用 `cat` 或 `head` 读取它。 - **类人认知**：这更像人——我们不会背下整个图书馆（传统 RAG），我们只会记住索引和书架（文件系统、书签），然后按需取用。 **提示工程在此处的进化**：此时提示不再是告诉模型「知识在这里」，而是教会模型「如何自主去寻找知识」。 **（3）混合策略才是王道** 智能体搜索虽然更智能，但代价是慢（运行时探索）；上下文检索虽然被动，但快（预计算）。最佳实践是结合两者： - 对高频、关键的指南（如 Claude Code 的 `CLAUDE.md` 文件），使用上下文检索直接塞给模型。 - 对庞大、动态的代码库或数据库，则赋予 Agent 智能体搜索的工具，让它自己去 `grep` 和 `glob`。 ### 3、Tool Use 工具调用：Agent 的四肢 这是 L3 Agent 最具标志性的进化：Agent-Computer Interface（ACI），Agent 如何与外部世界成千上万的 API 和工具交互？ **（1）函数调用** 工具调用是为非确定性的 Agent 设计的，是「确定性系统」和「非确定性 Agent」之间的契约。我们不能像设计传统 API 那样设计工具，必须对 Agent 的「人机工学」友好。 一个重要判断：优化工具描述带来的性能提升，远大于修改总系统提示。 **提示工程在此处的进化**：核心战场从「系统提示」转移到了「工具描述」。工具的 `description` 和 `parameters` 描述就是一种微提示，Agent 能否正确选用工具，九成取决于这个 ACI 提示写得是否清晰、无歧义、无重叠。 **关键实践一：合并工作流** 坏的实践是简单包装 API，比如 `list_contacts`、`get_contact_details`，Agent 需要调用很多次，上下文会被中间结果撑爆。好的实践是合并高频工作流： ```text contacts 替换 list_contacts（不需要读取整个通讯录，太浪费 Token） schedule_event 替换 list_users + list_events + create_event get_customer_context 替换 get_customer_by_id + list_transactions + list_notes ``` **关键实践二：用参数来做上下文工程** 让 Agent 自己决定这一步需要多少上下文，而不是工具无脑返回所有信息： ```text response_format: "concise" | "detailed" ``` 我们开始将「Agentic 的思考」固化到工具内部，以节省上下文。 **关键实践三：评估驱动开发** 工具不是写出来的，是评测出来的。你需要用 Agent 来帮你优化工具，通过分析评测日志（比如 Agent 为什么会用错），来反向迭代你的工具描述。Claude 之前总给搜索词加上「2025」，就是通过评测发现并通过优化描述来修复的。 **（2）MCP（模型上下文协议）** 它是一个标准化的工具驱动协议，将 Agent 与工具解耦。Agent 不再需要把所有工具定义都「背」在 Prompt 里，它可以在运行时动态发现 MCP 服务器，并向它们查询「你能做什么？」 **提示工程在此处的进化**：提示工程变成了协议工程。Agent 和工具之间的交互被标准化了，工具描述可以按需加载，而不是全部塞入上下文。 **关键实践：命名空间**。当 Agent 通过 MCP 发现数百个工具时，它会懵。使用 `asana_search` 对比 `jira_search`，或者 `asana_projects_search` 对比 `asana_users_search` 这样的命名空间，可以帮助 Agent 在动态发现时进行剪枝，极大提升选择正确工具的概率。 提示工程从「写好一个描述」进化到了「设计一套清晰的工具命名和信息架构」。 **（3）Agent Skills（技能包）** 这是最新的进化。如果说 MCP 是驱动程序，那么 Skills 就是应用程序包。一个 Skill = 指令文档（.md）+ 流程脚本（.py）。 `SKILL.md` 文件本身就是一种极其复杂、结构化的流程提示，它通过渐进式披露机制被动态加载到上下文中： - **L1（启动时加载）**：只加载 `SKILL.md` 的元数据（`name` 和 `description`），消耗的 Token 极少。 - **L2（Agent 触发时）**：Agent 觉得这个 Skill 有用，于是主动读取 `SKILL.md` 的正文。 - **L3（Agent 需要时）**：Agent 在阅读时发现它引用了 `forms.md` 或 `utils.py`，于是再次主动去读这些更深层的文件。 而且 Skill 不只是一个「超级提示」，它是一个混合体：`SKILL.md` 是给 Agent 的程序性知识，告诉它如何思考；`.py` 脚本是给 Agent 的确定性工具，让它高效执行（比如用代码排序，而不是让 LLM 自己在上下文中排序）。 提示工程至此进化成了「知识库和代码库的架构师」：我们不再是喂给模型上下文，而是设计一个信息迷宫，并相信 Agent 能看到地图、选择进入哪个区域、按需索取房间钥匙。 ## 三、怎么做：上下文窗口管理 Agent 的上下文窗口就像人类的工作记忆，它有一个注意力预算。上下文不是越多越好——Token 越多，模型的注意力就越稀释，回忆精准度就越低。 ### 1、四象限 - **Write（写到窗外）**：把中间思考、工具结果等产物，写入到外部存储（如 Scratchpad、Memory、文件系统），而不是无脑塞回上下文。 - **Select（按需取回）**：基于检索或索引，只拉取当前步骤最需要的片段。上一节的上下文检索和智能体搜索就是实现高质量 Select 的关键。 - **Compress（压缩裁剪）**：对长对话轨迹和重型工具输出，主动进行摘要、裁剪或清理（如 Claude Code 的 auto-compact 会自动清理陈旧的工具结果）。 - **Isolate（隔离）**：利用多代理或环境隔离，让重对象、长轨迹在子代理或沙箱环境中展开，只把最终的摘要和关键信号回传给主上下文。 ### 2、Manus 实战：三大范式 如果说四象限是理论，那么 Manus 的实战范式就是将其落地的优秀工程案例。 **（1）Reduce（压缩）** 第一阶段是轻量压缩（compaction）：工具返回结果分为 full 和 compact 两个版本，full 版本（如网页全文）被卸载到文件系统，compact 版本（如文件路径和一句话摘要）留在上下文中。 关键点在于：只对较旧的工具结果进行压缩，保留最新的工具结果，因为 Agent 的下一步决策最依赖它。这比「自动清理工具结果」更精细。 第二阶段是重量压缩（summarization）：当轻量压缩达到极限时才启动，调用 LLM 把 full 版本的结果按固定模式生成结构化摘要，替换掉上下文中的 compact 引用。 **（2）Offload（卸载）** Manus 把大量结果卸载到沙箱的文件系统，Agent 不直接看这些数据，而是通过 `shell`、`grep`、`glob` 这类通用原语按需取回。 核心洞察是**分层行动空间**： - 错误的做法：把 100 个 MCP 工具的描述都塞进 System Prompt。这会撑爆上下文，并让 LLM 选择困难。 - Manus 的操作：函数调用层只保留不到 20 个原子工具（如 `shell`、`text_editor`），这层非常薄，占用 Token 极少；沙箱层则把 100 个 MCP 工具全部做成命令行工具，安装在沙箱环境中。 Agent 不需要认识 100 个工具，它只需要认识一个 `shell`。当它需要用 MCP 时，会调用 `shell` 去执行 `mcp_tool_cli --help`。 这是一种极致的上下文卸载：「工具描述本身」都被卸载了，从「提示」变成了「环境」的一部分。Agent 的认知负荷从「N 选 1」降低到了「1」，然后它可以在沙箱环境中自主发现工具的用法。 **（3）Isolate（隔离）** Manus 使用了少量实用型子代理。子代理在自己隔离的上下文中完成任务，然后以标准化的输出模式回传给主代理，极大地降低了跨代理对话的噪音和 Token 成本。 核心洞察是：**子代理是「工具」，不是「团队」**。Manus 反对把子代理拟人化（如 PM 代理、程序员代理），它的子代理是实用主义的：Planner（规划者）、Knowledge Manager（知识管理者）、Executor（执行者）。原因是拟人化的跨代理沟通成本极高，而且 LLM 并不受人类「认知分工」的限制。 隔离有两种模式，都确保子代理的噪声不会污染主代理的上下文： - **简单任务**：Planner 只给 Executor 发送指令，Executor 在一个干净的上下文中完成工作，只返回结果。 - **复杂任务**（如需要读写共同文件）：Planner 把自己的完整上下文复制一份，连同指令一起发给 Executor，Executor 在继承的上下文中工作，然后返回结果。 ## 最后 要让一个 Agent 真正能做事，且保证成本、稳定性和合规可控，需要一个完整的技术栈： - **推理（Think 工具）**：把思考从隐式的 CoT 变为显式的 SOP，实现行动中反思。 - **RAG（上下文检索 + 智能体搜索）**：把记忆从被动灌输升级为主动按需探索。 - **工具（MCP + Skills）**：把四肢从扁平 API 升级为可动态加载的、分层的行动空间。 - **框架（四象限 / 三范式）**：把上下文管理从随心所欲变为制度化的内存调度。 这一切合在一起，才让 Agent 真正完成了从「会聊天」到「会思考」，再到「会做事」的飞跃。 最后，在看完 Anthropic 的系列文章后，发现其中有一句话的思想贯穿始终：做最简单且有效的事情。希望我们都可以在这个世界上保持简单，呵护好自己最初的纯粹。 ## 核心结论 - 从 Chatbot 到 Agent，核心瓶颈从「怎么写提示」彻底转向了「怎么管上下文」。提示工程没有消失，它渗透进了 Agent 架构的每一个组件。（判断 · 把握较大） 永久链接：https://chenxu.xin/writing/context-engineering-evolution#bottleneck-shifted-to-context - 上下文工程的黄金法则是：在模型有限的注意力预算下，用信噪比最高的最小 Token 集合，驱动模型产生期望的行为。上下文不是越多越好。（判断 · 把握较大） 永久链接：https://chenxu.xin/writing/context-engineering-evolution#context-engineering-golden-rule - 优化工具描述带来的性能提升，远大于修改总系统提示。Agent 能否正确选用工具，九成取决于这个描述写得是否清晰、无歧义、无重叠。（判断） 永久链接：https://chenxu.xin/writing/context-engineering-evolution#tool-description-beats-system-prompt - 智能体搜索不是「检索」，是「探索」。Agent 拿到的是文件名和 grep 这类轻量标识符与工具，在运行时自主决定要看什么——更像人只记住索引和书架，而不是背下整个图书馆。（判断） 永久链接：https://chenxu.xin/writing/context-engineering-evolution#agentic-search-is-exploration - 子代理是「工具」而不是「团队」。拟人化的分工（PM 代理、程序员代理）跨代理沟通成本极高，而 LLM 并不受人类认知分工的限制。（判断） 永久链接：https://chenxu.xin/writing/context-engineering-evolution#subagents-are-tools-not-teams --- 本文出自晨光里的AI（https://chenxu.xin），作者晨旭。 引用时请保留来源链接。文中标注「判断」「假设」的部分是作者的个人看法，不是事实。