2025 年确实成了 AI Agent 元年。不只是 Manus 这种通用型 Agent，还有设计领域的 Lovart、编程领域的 Claude Code 和 Cursor 等垂直产品。经常会有人问：这些 Agent 到底是如何工作的？为什么有的 Agent 看着很智能，有的却在掉链子？

大模型大家都可以用，但为啥结果差异比较大呢？

这是由于在大模型能力一致的前提下，决定 Agent 成败的，我们给它提供了多少有用的信息。这就是今天要聊的核心话题——从提示词工程到上下文工程的演进。

1. Agent 的三个核心动作

要理解上下文工程，我们得先从 AI Agent 的基本工作原理说起。简单来说，Agent 就像一个能自主完成任务的助手，它的工作流程可以概括为三个核心动作：感知、计划、行动。

1.1 感知

感知是 Agent 的第一步，也是最容易被忽视的一步。就像开车需要看清路况，Agent 需要准确理解当前的情况。

这里有个关键点：感知包含两个层面。

状态感知是对客观环境的理解。比如你让 Agent 帮你改代码，它需要知道：

• 项目用的是什么语言和框架
• 现有的代码结构是怎样的
• 有哪些依赖和限制

意图感知则是理解你真正想要什么。当你说”优化这段代码”时，Agent 需要判断：

• 是要提升性能还是改善可读性？
• 有没有特定的性能指标要求？
• 是否需要保持向后兼容？

很多 Agent 失败的案例，根源就在于感知出了问题。比如用户说”这个太慢了”，如果 Agent 只是机械地理解为”需要优化”，而没有深入了解具体慢在哪里、期望达到什么速度，那后续的优化很可能南辕北辙。

1.2 计划

有了准确的感知，Agent 需要制定行动计划。这就像做菜，你得先想好步骤：先切菜还是先热油，什么时候放调料。

计划能力很大程度上取决于底层的大语言模型。不同模型有不同的”性格”：

• Claude 喜欢深思熟虑，会考虑多种可能性
• GPT-4 比较均衡，执行标准任务很稳定
• Gemini 更大胆，有时会提出创新方案

从技术架构上来说：

• Gemini 侧重多模态融合和大规模上下文处理
• Claude 专注于精确推理和复杂任务执行

但光有好模型还不够。Agent 的计划质量很大程度上取决于它掌握的信息是否充分。如果缺少关键信息，再聪明的模型也会做出糟糕的计划。

1.3 行动

最后是行动模块，让 Agent 真正能够”做事”。目前主流的实现方式是函数调用（Function Calling）——预先定义一系列工具函数，比如搜索网页、读写文件、发送邮件等，然后让模型根据需要调用这些函数。

这里面临的挑战是工具选择。当可用工具很多时，Agent 可能会困惑。就像给你一个装满各种工具的工具箱，如果不清楚每个工具的用途，很容易选错。

2. Agent 的四大支撑系统

除了核心的感知-计划-行动循环，现代 Agent 还需要四个重要的支撑系统：

2.1 记忆系统

记忆让 Agent 能够积累经验。就像人类一样，Agent 需要不同类型的记忆：

• 工作记忆：处理当前任务的临时信息
• 情景记忆：之前的对话和任务记录
• 语义记忆：领域知识和最佳实践

但这里有个反直觉的发现：好的记忆系统不仅要会记住，更要会遗忘。

为什么？因为不是所有信息都值得保留。过时的信息、错误的尝试、无关的细节，如果都保存下来，反而会干扰 Agent 的判断。这就像你的电脑，定期清理缓存才能保持流畅运行。

2.2 工具系统

工具让 Agent 能够与外部世界交互。早期的 Agent 只能回答问题，现在的 Agent 可以：

• 搜索信息
• 操作文件
• 调用 API
• 甚至控制其他软件

Anthropic 推出的 MCP（Model Context Protocol）协议，试图为工具调用建立统一标准。这就像 USB 接口的标准化，让不同的工具都能方便地接入 Agent 系统。

2.3 安全系统

给 Agent 执行能力就像给孩子一把剪刀，必须要有安全措施。Manus 刚上线时就出现过安全问题，有人通过特殊的提示词，让 Agent 打包了执行环境的所有代码。

现代 Agent 通常采用多层防护：

• 沙箱隔离：所有操作都在受控环境中执行
• 权限管理：根据用户和场景动态分配权限
• 审计日志：记录所有操作便于追溯

2.4 评估系统

如何判断一个 Agent 的表现？这比想象中复杂。不像传统软件有明确的对错，Agent 的输出往往有多种可能的”正确答案”。

评估需要考虑多个维度：

• 任务完成度
• 效率和成本
• 用户满意度
• 安全合规性

3. 从提示词工程到上下文工程

理解了 Agent 的工作原理，我们再来看看工程实践的演进。

3.1 提示词工程的局限

去年大家还在研究怎么写提示词。什么”你是一个专业的XX”、”请一步一步思考”，各种模板层出不穷。但很快我们发现，光靠精心设计的提示词，很难让 Agent 处理复杂任务。

原因很简单：提示词只是静态的指令，而真实任务需要动态的信息。

就像你请人帮忙，光说”帮我订个机票”是不够的，还需要告诉对方：

• 出发地和目的地
• 时间和预算
• 个人偏好
• 可用的支付方式

3.2 上下文工程的兴起

上下文工程是一个更宏大的概念。也有人说又是套壳包装了一下。但是我觉得非包装，而是大家对于如何和大模型交互有了更全面的认知。用 Shopify CEO Tobi Lütke 的话说，上下文工程是「提供所有必要上下文，让任务对 LLM 来说变得可解的艺术」。

上下文不只是提示词，而是 Agent 在生成回复前能看到的所有信息：

1. 指令上下文：系统提示词、任务说明、行为规范
2. 对话上下文：当前和历史对话记录，包含用户意图，如输出的结构
3. 知识上下文：相关文档、数据库信息、搜索结果
4. 工具上下文：可用函数的描述和使用方法
5. 状态上下文：环境变量、用户偏好、系统状态

更重要的是，上下文工程是一个动态系统，不是静态模板：

• 它根据任务类型选择相关信息
• 它随着对话进展更新内容
• 它平衡信息的全面性和简洁性

从终局的逻辑来看，上下文工程的结果还是给到大模型的提示词。

Google DeepMind 的一位工程师写了一篇博客，地址：www.philschmid.de/context-eng… 其中有一张图，如下：

讲了七个部分：

• 指令 / 系统提示词：定义模型在对话过程中行为的初始指令集，可以/应该包含示例、规则等。
• 用户提示词：来自用户的即时任务或问题。
• 状态 / 历史记录（短期记忆）：当前对话，包括导致此刻的用户和模型响应。
• 长期记忆：持久的知识库，从许多先前的对话中收集而来，包含已学习的用户偏好、过去项目的摘要，或被告知要记住以供将来使用的事实。
• 检索信息（RAG）：外部的最新知识，从文档、数据库或API中获取的相关信息，用于回答特定问题。
• 可用工具：它可以调用的所有函数或内置工具的定义（例如：check_inventory（检查库存）、send_email（发送邮件））。
• 结构化输出：关于模型响应格式的定义，例如JSON对象。

这七个部分都包含在上面的 5 个上下文中。

4. 上下文工程的核心挑战

Karpathy 把 LLM 比作新型操作系统，上下文窗口就像 RAM。这个比喻很精确——就像内存管理是操作系统的核心功能，上下文管理是 Agent 工程的核心挑战。

主要挑战包括：

1. 容量限制 即使 Claude 已支持 20 万 token，Gemini 甚至支持 200 万 token，但这些容量在复杂任务面前仍然捉襟见肘。一个长时间运行的 Agent，轻易就能产生海量的交互记录。

2. 注意力分散 研究发现，当上下文过长时，模型会出现”迷失在中间”现象——对开头和结尾的内容记忆较好，但中间部分容易遗漏。这就像看一本太厚的书，中间章节的内容总是记不清。

3. 性能退化 过长的上下文不仅增加成本和延迟，还会降低模型的推理能力。Drew Breunig 总结了几种典型问题：

• 上下文污染：错误信息影响后续判断
• 上下文干扰：无关信息分散注意力
• 上下文冲突：不同部分信息相互矛盾

5. 上下文工程的四种核心策略

面对这些挑战，有四种核心策略：

5.1 有选择的保存

这是把重要信息保存到上下文窗口之外，需要时再取用。

便签本模式：Agent 在执行任务时记笔记，保存中间结果和重要发现。Anthropic 的研究系统会在开始时制定计划并保存，避免因上下文截断而丢失。

长期记忆：跨会话保存的信息，包括用户偏好、领域知识、成功案例等。ChatGPT、Cursor 都实现了这种机制。

关键是要有选择地保存。不是什么都值得记住，需要识别真正有价值的信息。

5.2 选择对的信息

保存了信息，还需要在合适的时候取出来用。

记忆检索：当积累了大量记忆后，如何找到相关的部分？简单的关键词匹配往往不够，需要语义理解。ChatGPT 会根据当前对话内容，自动检索相关的历史记忆。

工具筛选：当可用工具很多时，全部列出会让模型困惑。研究表明，通过语义匹配只提供相关工具，可以将准确率提升 3 倍。

知识召回：这就是 RAG（检索增强生成）的核心。但实现好的 RAG 系统很有挑战。Windsurf 的工程师分享说，他们结合了多种技术：向量检索、关键词搜索、AST 解析、知识图谱，最后还要重排序。

5.3 压缩提炼

当信息太多时，需要压缩和精炼。

轨迹总结：Claude Code 的”自动压缩”功能就是典型例子。当上下文使用超过 95% 时，它会总结整个对话历史，保留关键信息的同时大幅减少 token 使用。

定点压缩：在特定环节进行信息精炼。比如搜索工具返回大量结果后立即总结，或者在不同 Agent 交接时压缩传递的信息。

智能裁剪：根据相关性和时效性，自动删除不必要的信息。可以基于时间（删除过早的对话）、频率（删除很少用到的信息）或相关性（删除与当前任务无关的内容）。

5.4 分而治之

把不同类型的信息分开管理，避免相互干扰。

多智能体架构：让不同的 Agent 处理不同的子任务，每个都有自己的上下文空间。Anthropic 的研究显示，多个专门的 Agent 往往比一个通用 Agent 表现更好。

环境隔离：HuggingFace 的做法很有启发——让 Agent 生成代码，在沙箱中执行，只把必要结果返回。这样可以把大量中间数据隔离在执行环境中。

状态分离：通过精心设计的状态结构，把不同类型的信息存在不同字段，只在需要时才暴露给模型。

6 小结

上下文工程正在成为 AI 工程师的核心技能。随着 Agent 能力的提升，如何管理和优化上下文将变得更加重要。

几个值得关注的发展方向：

1. 自适应上下文：Agent 自己学习什么信息重要，自动调整上下文策略
2. 分布式上下文：跨多个 Agent 和系统共享和同步上下文
3. 个性化上下文：根据用户特点和偏好定制上下文管理策略
4. 实时优化：在运行时动态调整上下文，而不是预先设定

当前不再是简单地“调教”模型说出正确的话，而是构建一个完整的信息系统，让 Agent 真正理解任务、掌握必要信息、做出正确决策。这种转变，预示着 AI Agent 正在从实验室的玩具，变成真正能够解决实际问题的工具。

如 Cognition 所说：”上下文工程实际上是构建 AI Agent 的工程师的头号工作。”。

以上。