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 在生成回复前能看到的所有信息：
- 指令上下文：系统提示词、任务说明、行为规范
- 对话上下文：当前和历史对话记录，包含用户意图，如输出的结构
- 知识上下文：相关文档、数据库信息、搜索结果
- 工具上下文：可用函数的描述和使用方法
- 状态上下文：环境变量、用户偏好、系统状态
更重要的是，上下文工程是一个动态系统，不是静态模板：
- 它根据任务类型选择相关信息
- 它随着对话进展更新内容
- 它平衡信息的全面性和简洁性
从终局的逻辑来看，上下文工程的结果还是给到大模型的提示词。
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 能力的提升，如何管理和优化上下文将变得更加重要。
几个值得关注的发展方向：
- 自适应上下文：Agent 自己学习什么信息重要，自动调整上下文策略
- 分布式上下文：跨多个 Agent 和系统共享和同步上下文
- 个性化上下文：根据用户特点和偏好定制上下文管理策略
- 实时优化：在运行时动态调整上下文，而不是预先设定
当前不再是简单地"调教"模型说出正确的话，而是构建一个完整的信息系统，让 Agent 真正理解任务、掌握必要信息、做出正确决策。这种转变，预示着 AI Agent 正在从实验室的玩具，变成真正能够解决实际问题的工具。
如 Cognition 所说："上下文工程实际上是构建 AI Agent 的工程师的头号工作。"。
以上。