上下文工程的自然演进：从「聊天机器人」到「推理者」再到「Agent」

过去一年，我们见证了 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 工具是显式的。它是一个被定义和调用的工具，专门用于「行动中的思考」：

{
  "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 需要调用很多次，上下文会被中间结果撑爆。好的实践是合并高频工作流：

contacts              替换  list_contacts（不需要读取整个通讯录，太浪费 Token）
schedule_event        替换  list_users + list_events + create_event
get_customer_context  替换  get_customer_by_id + list_transactions + list_notes

关键实践二：用参数来做上下文工程

让 Agent 自己决定这一步需要多少上下文，而不是工具无脑返回所有信息：

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 的系列文章后，发现其中有一句话的思想贯穿始终：做最简单且有效的事情。希望我们都可以在这个世界上保持简单，呵护好自己最初的纯粹。