🚀 从提示到上下文：打造高效可控AI代理的工程化方法论

【摘要】探讨AI代理开发从提示工程到上下文工程的范式转变。文章系统阐述了在LLM有限注意力预算下，通过动态管理上下文、优化工具契约与应用长期记忆技术，构建高效、可控、能够胜任复杂任务的自主智能体的核心方法论与工程实践。

引言

AI代理正在经历一场深刻的变革。它们不再是仅能执行单一指令的简单工具，而是朝着能够自主规划、执行并适应复杂环境的智能体演进。在这股浪潮中，我们过去赖以为生的提示工程（Prompt Engineering）开始显得力不从心。面对需要多轮推理、跨越数小时甚至数天的长时域任务，仅仅优化几句提示词，就像试图用一把小刀雕刻一座大山，捉襟见肘。

于是，一个更系统、更具架构思维的理念浮出水面，那就是上下文工程（Context Engineering）。

这个理念的核心关注点发生了根本性的转移。我们不再仅仅追问“如何措辞才能让模型听懂”，而是开始系统性地思考“在任务的每一步，模型需要看到什么信息、这些信息应该以何种结构呈现、又该在何时被注入”。这本质上是在大语言模型（LLM）固有的、有限的“注意力预算”内，进行一场精密的资源调度。我们的目标是动态地、系统地为模型策划并维护一个最优的信息集合，从而以最大概率引导它产生我们期望的行为。

这场变革的背后，是LLM自身的技术局限。尽管我们看到了128K、200K甚至百万级别的上下文窗口，但这并非一劳永逸的灵丹妙药。研究与实践反复证明，随着上下文窗口中token数量的急剧增加，模型准确回忆和利用关键信息的能力会显著下降。这种现象被称为**“上下文腐烂”（Context Rot）或“上下文衰减”（Context Decay）**。它就像一个记忆力超群的人，当被要求同时记住一整图书馆的书时，他也会开始遗忘、混淆关键细节。

这种“遗忘”并非偶然，它根植于Transformer架构的自注意力机制（其计算复杂度与token数量的平方成正比）、模型训练数据中短序列远多于长序列的分布偏见，以及位置编码在超长序列下的精度损失等多种因素。这些因素共同决定了一个残酷的现实，上下文是一种宝贵且稀缺的资源。因此，我们的工程目标必须转向追求一个“最小但信噪比最高”的token集合，用最精炼的信息，去最大化撬动我们期望的产出。这，就是上下文工程的出发点与归宿。

一、范式之变：从提示到上下文的必然演进

1.1 两种工程范式的核心分野

提示工程是我们与LLM打交道的起点。它更像一门手艺，一种“指令的艺术”，专注于为模型编写和组织单次指令，以期在单轮或少数几轮交互中获得最佳表现。它非常适合那些目标明确、流程固定的静态任务，比如文本分类、内容摘要或简单的问答。

但是，当任务变得复杂，需要代理自主进行多步推理、与外部工具交互、并长期保持目标一致性时，提示工程的局限就暴露无遗。它无法系统性地管理一个动态演变的信息环境。

上下文工程则完全不同。它是一种系统级、动态的架构策略。它将LLM视为一个信息处理核心，而我们的工作就是设计并维护一个高效的信息流管道，确保在任何时刻，流入这个核心的都是最精准、最相关的“世界观”。在这个宏大的视角下，系统提示仅仅是上下文的静态组成部分之一。历史对话、外部数据库的检索结果、工具调用的返回数据、项目规范文件等等，所有这些共同构成了模型的完整上下文。

因此，我们可以清晰地看到，提示工程是上下文工程的一个子集。前者是战术层面的优化，后者则是战略层面的架构设计。

为了更直观地理解两者的区别，我们可以通过一个表格进行对比。

1.2 “上下文腐烂”现象的技术探源

理解上下文工程的必要性，必须深入探究“上下文腐烂”这一核心痛点。为什么更大的上下文窗口不等于更好的性能？

1. 注意力机制的平方灾难
   Transformer架构的核心是自注意力机制，它允许每个token关注到上下文中的所有其他token。这意味着对于一个包含n个token的上下文，模型需要计算n²对关系。当n从几千增长到几十万时，计算量和内存需求呈指数级增长。更重要的是，注意力被极度稀释了。模型需要从海量的信息中分辨出哪些是真正重要的，这本身就是一个巨大的挑战。就像在一场万人喧哗的演唱会上，试图听清一个朋友的耳语。

2. 训练数据的分布偏见
   LLM的训练数据，无论是来自网页、书籍还是代码，其自然分布都倾向于短序列。一篇博客文章、一个函数定义、一次简短的对话，这些常见的文本单元长度都有限。模型在训练过程中见过无数这样的短序列，却很少见到横跨几十万token且内部逻辑高度关联的超长序列。这导致模型内部的参数和注意力模式，天然就更擅長處理短距離依賴關係，而對於長距離的邏輯穿透則顯得“經驗不足”。

3. 位置编码的精度挑战
   为了让模型理解token在序列中的位置，Transformer引入了位置编码。一些技术如位置编码插值（Positional Encoding Interpolation）允许模型处理比其预训练长度更长的序列。但这是一种“适应性”拉伸，而非原生支持。在超长序列的末端，位置信息的区分度可能会下降，导致模型对token位置的感知变得模糊，进而影响其理解长距离依赖的能力。

这些底层因素共同作用，导致了性能的平滑下降而非硬性断崖。模型在长上下文上依然强大，但相比于在短上下文中的表现，其信息检索的精准度和长距离推理的可靠性会打折扣。这迫使我们必须放弃“把所有东西都塞进去”的粗放式做法，转向精耕细作的上下文工程。

二、高效上下文的解剖学：构建坚实的代理基石

一个高效的上下文，就像一个装备精良、指令清晰的特种兵工具包。它包含的每一项内容都经过精心挑选，不多一分冗余，不少一分关键。下面我们来解剖这个“工具包”的几个核心组成部分。

2.1 🎯 系统提示设计：追求“恰当高度”的艺术

系统提示是代理行为的基石，是刻在代理“基因”里的核心指令。设计好系统提示，关键在于找到一个“恰当的高度”（Right Altitude）。这是一个介于两种常见失败模式之间的“黄金地带”。

• 失败模式一：过度硬编码
  工程师试图用复杂的if-else逻辑和脆弱的规则，在提示中预设所有可能性，试图精确控制代理的每一步行为。这种方法初期可能有效，但会造成系统极度脆弱，难以维护和扩展。一旦任务场景稍有变化，整个提示就可能崩溃。

• 失败模式二：过于泛泛
  工程师提供模糊、高层次的指导，比如“请成为一个有用的助手”。这种提示未能给LLM提供任何具体、可操作的行为信号，或者错误地假设了模型与我们共享了大量的隐性知识和背景。结果就是代理的行为难以预测，输出质量飘忽不定。

最佳实践是取得平衡。提示既要足够具体，能够有效指导行为，又要足够灵活，为模型提供强大的启发式方法（Heuristics）而非僵化的规则。

具体落地建议

1. 分区组织
   我们强烈建议将系统提示组织成不同的部分，并使用XML标签或Markdown标题来明确区分。这不仅让人类易于阅读和维护，也为模型提供了清晰的结构化信息，帮助它更好地理解不同指令的范畴。

   xml：

   <role_description>

   你是一个资深的数据分析师，擅长使用Python进行数据处理和可视化。

   </role_description>

   <tool_guidelines>

   ## 工具使用指南

   - 优先使用 search_internal_db 工具查询内部数据。

   - 仅在内部数据不足时，才使用 web_search 工具。

   - 生成图表前，必须先调用 validate_data 工具检查数据质量。

   </tool_guidelines>

   <output_format>

   ## 输出格式要求

   所有分析报告必须包含以下三个部分：

   1. 核心发现: ...

   2. 数据支撑: ...

   3. 后续建议: ...

   </output_format>

2. 迭代式优化
   不要试图一步到位写出完美的提示。更好的方法是，先用当前最强大的模型，测试一个最小可用的提示。观察它在你的核心任务上的表现，然后像调试代码一样，围绕它出现的失败模式，迭代地补充清晰的规则和示例。比如，如果发现代理经常忘记数据校验，就在<tool_guidelines>里增加一条明确的指令。

2.2 🔧 工具集成与契约：最小可行工具集

工具是代理与外部世界交互的触手，它定义了代理的信息获取和行动空间。工具设计的优劣，直接决定了代理的效率和可靠性。

核心设计原则

• 单一职责
  每个工具应该只做一件事，并把它做好。一个既能查天气又能发邮件的工具，会给代理的决策带来困扰。

• 鲁棒与容错
  工具应该能优雅地处理错误输入和异常情况，并返回清晰、有用的错误信息。一个脆弱的工具会频繁中断代理的工作流。

• 清晰的契约
  工具的名称、描述、输入参数都应该极其清晰、无歧义。如果人类工程师都无法根据描述快速判断何时使用哪个工具，就不要指望AI代理能做得更好。

• Token高效
  工具的返回结果应该尽可能简洁、信息密度高。返回一个巨大的JSON对象，会迅速挤占宝贵的上下文空间。可以考虑在工具层面做初步的信息提炼。

我们遇到的最常见的失败模式之一，就是工具集臃肿。团队为代理提供了数十个功能相似、边界模糊的工具，导致代理在决策点上反复纠结，或者频繁用错工具。

因此，我们提倡精选一个“最小可行工具集”（Minimum Viable Toolset）。仔细审视每个工具的必要性，合并功能重叠的工具，确保工具集正交、完备。一个精炼的工具集，不仅能提升代理的决策效率，也为后续在长时交互中进行上下文修剪打下了良好基础。

2.3 ✨ 示例与少样本提示：以少胜多的智慧

提供示例，也就是我们常说的少样本提示（Few-shot Prompting），是一种极其有效的引导技术。但是，这里的关键在于“少”和“精”。

很多团队容易犯的一个错误是，试图在提示中塞入一长串覆盖各种边缘案例的示例，希望以此穷举所有规则。这不仅会迅速消耗上下文预算，还可能因为示例间的细微冲突而干扰模型。

正确的做法是，精心挑选一小组多样化、典型化的示例，它们应该能有效地展示代理在核心场景下的预期行为模式。一个好的示例，对LLM来说真正是“一图胜千言”。它能传递出比冗长规则描述多得多的微妙信息，包括风格、格式、推理链条等。

例如，要教会代理如何写一份代码审查评论，与其写十条规则，不如给它看两份高质量的评论范例。

2.4 📜 项目规则与惯例：隐性知识的显式化

在复杂的软件项目或研究任务中，存在大量不成文的规则、编码风格和工作流程。这些隐性知识对于人类协作者至关重要，对于AI代理同样如此。

一个高效的实践是，通过一个约定的文件（例如CLAUDE.md或PROJECT_CONTEXT.md）将这些项目级的规则、惯例显式化，并让它自动成为代理上下文的一部分。这个文件可以包含：

• 代码风格指南（如PEP8）。

• API使用约定。

• 项目模块的架构概览。

• 通用的调试流程。

这种方法不仅能极大提升代理动作的一致性和效率，还可以支持层级继承。比如，一个子目录可以有自己的README.md来覆盖或补充顶层规则，代理在进入该目录工作时，可以动态地将这个更具体的文件加载到上下文中。

三、动态的艺术：运行时上下文管理策略

如果说静态上下文是代理的“出厂设置”，那么动态上下文管理就是代理在执行任务过程中的“实时战术调整”。随着任务的推进，代理必须能够智能地更新自己的“工作记忆”，丢弃过时信息，引入新的相关数据。

3.1 📥 即时上下文：从“预装”到“按需加载”

传统的做法，尤其是在RAG（检索增强生成）应用中，倾向于在任务开始前，通过一次性检索，将所有可能相关的文档片段“塞满”上下文窗口。这种“预先加载”的模式简单直接，但有几个明显缺点。

• 上下文浪费
  很多预加载的信息在实际推理中可能根本用不上，白白占用了宝贵的空间。

• 信息过时
  如果外部数据源是动态变化的，预加载的信息很快就会过时。

• 缺乏探索性
  代理被动地接受信息，无法根据任务进展自主地去探索和发现新的信息。

因此，一种更先进、更高效的范式正在成为主流，即**“即时上下文”（Just-in-Time Context）**。

在这种模式下，代理不再维护沉重的数据对象，而是只持有轻量级的标识符，比如文件路径、数据库查询语句、API端点或网页链接。当任务进展到某一步，代理判断需要某项信息时，它会通过工具在运行时动态地将数据加载到上下文中。

这种方法非常像人类专家的工作方式。一位医生不会记住所有病人的全部病历，但他知道如何通过病历号快速调取所需信息。一位程序员不会背下整个代码库，但他知道如何使用grep或IDE的搜索功能找到相关的函数定义。

即时上下文的优势

1. 极致的上下文效率
   只有在绝对需要时，信息才会被加载进来，确保了上下文窗口内始终是高价值信息。

2. 支持渐进式披露
   代理可以像人类一样，通过探索逐步发现相关上下文。一次ls -R的文件列表，就能让代理对项目结构有个初步了解。一个文件名test_utils.py本身就传递了比其内容更重要的元信息——这是一个测试辅助模块。

3. 自主探索与信息发现
   代理可以主动地导航其信息环境。它可以先用head命令预览一个大文件的开头，判断其相关性，再决定是否要完整加载。这种自主性是迈向真正智能体的关键一步。

4. 元数据作为行为信号
   文件系统的层级结构、命名约定、修改时间戳等元数据，本身就是强大的行为信号。一个位于src/core_logic/目录下的文件，其重要性显然与docs/examples/下的文件不同。代理可以利用这些信号来指导自己的探索策略。

3.2 🧩 混合策略：速度与灵活性的平衡

当然，即时上下文并非万能。它的缺点是运行时探索可能会比预先计算好的检索要慢。在某些场景下，最有效的代理可能会采用一种混合策略。

例如，在一个处理法律案件的代理中，案件的核心卷宗、关键证人证词等文档，可以作为高优先级信息被预先加载到上下文中。这保证了代理在启动时就具备了核心背景知识，响应速度更快。然后，再赋予代理一系列工具，允许它根据需要即时检索具体的法律条文、过往判例或外部新闻报道。

这种“核心预加载 + 外围即时检索”的混合模式，兼顾了速度与信息的实时性、灵活性，在许多内容相对静态但细节繁复的领域（如金融、法律、学术研究）表现出色。选择哪种策略，或者如何组合它们，最终取决于具体任务的性质和对响应延迟的容忍度。

四、征服长时域：高级上下文治理技术

当任务的复杂度与持续时间，远远超出单个上下文窗口的承载极限时，我们就需要引入更高级的治理技术。这些技术的核心目标，是在漫长的任务周期中，帮助代理对抗“遗忘”，保持连贯性与目标导向。我们可以将其概括为“写、选、压、隔”四大策略。

4.1 ✍️ 写：结构化笔记与代理记忆

这是一种让代理拥有“长期记忆”的关键技术。其核心思想是，让代理定期将关键信息、中间结论、待办事项等，写入到上下文窗口之外的持久化存储中。这个存储可以是简单的Markdown文件（如NOTES.md），也可以是结构化的数据库或向量库。

当代理需要回忆过往信息，或者在一次上下文重置后恢复任务时，它可以主动地从这个“外部大脑”中读取自己的笔记。

一个生动的例子是让Claude玩《宝可梦》。在没有任何特定提示的情况下，模型自发地学会了做笔记。它会记录下“在1号道路训练皮卡丘，目标10级，当前8级，已持续1234步”这样的精确状态。在上下文窗口被压缩重置后，代理会先阅读自己的笔记，然后无缝衔接之前的训练任务。这种跨越上下文周期的连贯性，使得完成需要数小时乃至数天的长远策略成为可能。

为了简化这一过程，一些平台已经推出了记忆工具。例如，Anthropic的Memory Tool允许代理通过类似文件系统的API（create, read, update, delete）来管理其在客户端的记忆。这不仅方便了开发者，也确保了记忆数据的主权和可控性。

4.2 📥 选：动态检索与RAG

“选”就是我们前面提到的动态检索，其最成熟的应用形态就是RAG（Retrieval-Augmented Generation）。它确保了在任何时刻，进入上下文的外部知识都是与当前任务最相关的。这是一种主动的、有选择性的信息注入，是保证上下文“信噪比”的核心手段。

4.3 🗜️ 压：上下文压缩

压缩（Compaction）是一种简单而高效的“续命”手段。当对话历史或工具调用记录逐渐填满上下文窗口时，我们可以触发一个压缩操作。

具体做法是，将当前的完整上下文（除了系统提示等固定部分）交给一个LLM，让它进行一次高保真的摘要。这个摘要应该凝练出到目前为止的关键决策、核心状态和下一步的目标。然后，用这个精炼的摘要替换掉冗长的历史记录，开启一个新的、清爽的上下文窗口。

这种方法在需要大量来回对话的交互式任务中尤其有效。它定期清理掉不重要的对话细节，只保留对话的主干和精华，从而在降低token成本、提升响应速度的同时，维持了任务的长期连贯性。

4.4 🚪 隔：子代理架构

隔离（Isolation），或称为子代理架构，是应对极端复杂任务的终极武器。其思想源于软件工程的“分而治之”。

与其让一个无所不能的“超级代理”维护整个项目的庞大状态，不如将宏大任务分解，交给多个各司其职的专门子代理处理。

在这种架构下，通常会有一个主代理（Orchestrator），它负责高层次的规划、任务分解和结果整合。而**子代理（Specialists）**则专注于执行具体的、边界清晰的任务，比如“代码实现代理”、“文档检索代理”、“测试执行代理”等。

每个子代理都在自己独立的、聚焦的上下文窗口中工作。它可能会为了完成任务而进行广泛的探索，消耗数万甚至更多的token。但任务完成后，它只会向主代理返回一个高度精炼、浓缩的摘要结果（通常在1-2K token以内）。

这种模式的优势是巨大的。

• 关注点分离
  详细的、混乱的探索过程被隔离在子代理内部，主代理的上下文始终保持干净、聚焦于高层战略。

• 并行化收益
  多个子代理可以并行工作，极大地提升了复杂研发和分析任务的效率。

• 鲁棒性增强
  单个子代理的失败不会污染整个任务状态，主代理可以更容易地进行重试或调整策略。

下表总结了这四种高级治理技术的适用场景。

五、从理论到实践：上下文工程的落地清单

将上下文工程的理念转化为实际可运行的AI代理系统，需要一套工程化的落地流程。以下是一个可供参考的实践清单。

5.1 阶段一：定义与搭建基础

1. 明确任务边界与评估指标

   • 首先要清晰地定义代理需要完成的任务类型（是代码生成、研究分析还是客户服务？）。

   • 设定代理的自主级别边界。它应该在多大程度上可以自主决策？

   • 建立可量化的评估指标，例如任务完成准确性、token使用效率、工具调用成功率、长程任务的连贯性得分等。

2. 构建基础上下文框架

   • 系统提示：采用分区结构（角色、指南、格式），编写清晰、直接的指令。包含核心约束和一两个高质量示例。

   • 工具契约：定义一个最小可行的工具集，为每个工具编写清晰的描述和参数说明。可以建立一个工具白名单机制。

   • 项目规则：如果适用，创建一个项目规则文件（如PROJECT_CONTEXT.md），并设计机制让它能自动进入上下文。

5.2 阶段二：实现动态与记忆能力

3. 构建“即时上下文”管道

   • 为代理配备能够探索和读取外部信息环境的工具（如ls, cat, grep, sql_query等）。

   • 如果需要，集成一个RAG系统，用于从非结构化数据中选择最相关的片段。

4. 制定记忆策略

   • 确定需要被“记住”的信息类型（是任务状态、用户偏好还是关键发现？）。

   • 设计记忆的写入和回读策略。何时写入？以何种格式写入？何时以及如何检索回上下文？

   • 建立一套清晰的记忆命名约定，方便代理管理和查找。

5.3 阶段三：治理与监控

5. 配置长时任务治理策略

   • 压缩：设定一个上下文使用率的触发阈值（例如，当token占用达到容量的85%时），自动触发压缩流程。

   • 清理：设计机制自动清理上下文中过时的工具调用结果。

   • 记忆：确保结构化笔记能够在跨会话、跨上下文周期时被正确加载，以保持状态。

   • 隔离：对于真正复杂的任务，设计主-子代理的编排逻辑，明确它们之间的分工和通信协议（即子代理返回的摘要格式）。

6. 运行与监控

   • 日志记录：详细记录每一轮交互的完整上下文构成，包括系统提示、消息历史、工具调用及返回等。这是调试和优化的基础。

   • 性能监控：持续跟踪之前设定的评估指标，监控token占用与任务性能之间的关系。

   • 失败案例复盘：定期回顾失败的交互案例，分析失败的根源是工具设计不佳、检索选择错误，还是提示分区有歧义，然后进行针对性的调整。

六、警惕常见的失败模式

在实践上下文工程时，有一些常见的“坑”需要我们警惕和防范。

1. 工具集臃肿与职责不清
   这是最常见的失败模式。过多的工具、模糊的命名、重叠的功能，都会导致代理在决策时“选择困难”，或者频繁误用工具。

   • 防范：坚守“最小可行工具集”原则。定期审视工具集，毫不犹豫地砍掉或合并那些非核心、低频或可以被其他工具组合替代的工具。为每个工具设定明确的输入输出约束。

2. 上下文污染与冲突
   随着任务的进行，长长的上下文窗口中会累积大量信息，包括旧的、可能已过时的信息、错误的工具调用结果、甚至是相互矛盾的指令或示例。这些“噪音”会稀释模型的注意力，甚至引发逻辑上的矛盾。

   • 防范：这就是高级治理技术发挥作用的地方。定期压缩重启可以清除历史包袱。结构化的边界（如XML标签）可以帮助模型区分不同信息源。渐进式地重建上下文，而不是简单地追加，也是一种有效的策略。

七、面向未来：更大窗口下的思考

即使未来我们拥有了百万甚至千万级别的上下文窗口，上下文工程的理念依然不会过时。物理窗口的扩大，并不意味着注意力瓶颈和信息相关性问题的消失。

• 成本考量：更大的上下文意味着更高的计算成本和更长的响应延迟。在商业应用中，成本效益永远是重要的考量因素。

• 信噪比问题：一个装满了低质量信息的巨大窗口，其效果可能还不如一个经过精心策划的小窗口。垃圾进，垃圾出（Garbage In, Garbage Out）的原则依然适用。

因此，即使物理限制放宽，我们仍然需要通过上下文工程（压缩、检索、隔离等）来确保高信号密度和可控的行为。技术的发展可能会让这些工程实践变得更加自动化和智能，但其核心思想——将上下文作为一种需要精心管理的宝贵资源——将长期存在。

结论

上下文工程代表了AI系统开发范式的一次根本性转变。它要求我们从“提示词工匠”转变为“信息流架构师”。其核心在于，深刻理解并尊重LLM有限的注意力预算，在任务的每一步都精心策划进入模型视野的信息，努力找到那个能够以最高概率触发期望行为的“最小高信号token集”。

无论是系统提示的精雕细琢、工具契约的严谨设计、示例选择的以少胜多，还是动态检索的即时响应、长期记忆的构建，以及多代理架构的协同作战，所有这些技术的指导原则始终如一：信息精炼、结构清晰、动态调度、持续优化。

将这一方法论工程化落地，需要我们关注从基础搭建到动态管理，再到长期治理的全过程，并建立起一套监控与迭代的闭环。未来，随着模型能力的持续提升和上下文窗口的不断扩展，上下文工程将不再是锦上添花的技巧，而是决定AI代理能否从“有趣的玩具”真正走向“可靠的生产力工具”的关键基础设施。

📢💻 【省心锐评】

上下文工程，本质是把AI当成CPU，我们负责设计操作系统。别再迷信“大力出奇迹”了，精细化的信息调度才是构建可靠AI代理的唯一通路。