实战·Agentic 上下文工程（上）：无需微调，让智能体自我学习与进化

实战·Agentic 上下文工程（上）：无需微调，让智能体自我学习与进化

在提示工程的年代，我们教AI“怎么回答”；而在Agent（智能体）的时代，我们要教它“怎么思考”。于是，提示工程进化成了一个新形态 — **上下文工程（Context Engineering） —**它不再是微调一行提示，而是构建一个能让AI感知世界、自主决策与行动的舞台。【AI大模型教程】

最近，斯坦福大学等团队联合提出了一种上下文工程方法：Agentic Context Engineering（ACE）。让智能体无需微调，也能通过上下文的不断演化实现自我学习与进化。

这是《实战·Agentic 上下文工程》的上篇。你将看到：

• 为什么上下文需要“工程”
• 什么是上下文工程
• 上下文工程的常见策略
• Agentic上下文工程是什么
• Agentic上下文工程原理与架构

在下篇中，我们将基于ACE构建一个能够“自己复盘与改进”的Agent原型系统。

为什么上下文需要“工程”？

现在的上下文窗口已经普遍达到128K以上甚至1M，这给了智能体勃勃生机的无线可能：你可以把大量智能体需要的东西（指令、知识、工具等）都丢进一次Prompt中，让LLM自由的推理、规划、行动。

但为什么智能体的表现仍然不尽如人意？问题的原因不在于上下文能“装”多少，而在于最终LLM“消化”的是什么。LLM的输出永远存在不确定性——这是架构层面注定的事实。在模型尚未发生质变之前，我们能控制的唯一变量，就是它的输入：上下文（Context）。

而控制上下文，更大的“胃口”（窗口大小）固然重要；但更重要的是“营养”（质量）。大量的测试表明，更长的上下文并不确定会带来更好的结果：其中可能的冗余、冲突、错误（幻觉）信息都会让LLM迷失方向。

即使上下文内容完全正确，当输入规模过大时，LLM的“注意力”也可能会被分散，关键指令或语义线索被淹没，导致模型理解出现偏移与错位，甚至在推理中“跑题”。

更重要的是，在智能体的多轮推理中，微小的偏差会不断“叠加”，最终Agent任务可能完全“南辕北辙”。

这就是为什么需要上下文工程（Context Engineering）：

当LLM可以“吞”下更多内容时，你需要确保“营养搭配”：有结构、有逻辑、有重点，而不仅仅是“堆料”。

什么是上下文工程？

Shopify的CEO Tobi Lutke这样形容上下文工程：

为LLM提供所有用于合理解决任务的上下文信息的艺术。

如果说上下文是LLM的RAM（来自OpenAI 前研究科学家 Karpathy的比喻），那么上下文工程（Context Engineering） 就是 — 设计并实施这块有限 RAM 的管理机制，让信息的组织、输入、更新、淘汰都更有秩序与目的性。

上下文工程不是简单的提示模板设计与堆叠（尽管提示模板是它的一角）。它需要关注到更深层次的一系列结构性问题与工程方法：

• 包含哪些信息，如何组织，什么格式？

  行业知识或工具指南，或者更多，如何分类排序？

  普通文本还是半结构化的JSON、Markdown？

• 信息从哪里，又在什么时候获取？

  是来自企业内部数据库还是互联网、或Agent产生？

  是原始输入还是通过中间步骤动态注入？

• 信息如何产生，如何存储，又是如何检索？

  静态信息、缓存信息、动态生成与检索？

  传统索引、向量数据库，还是实时 Web 搜索？

• 信息是否需要清洗、标注、压缩？

  是否需要去除冗余、噪音、重复，并标注出重点？

  上下文是否需要压缩（如长期记忆）？

• 信息是否需要有生命周期管理？

  哪些内容持久存在，哪些随时间与任务衰减？

  信息过期机制，滑动窗口、基于使用次数还是LLM判断？

总之，上下文工程更像是为LLM建立一套语义的“供应链”，让LLM得以正确理解和推理 — 从而让Agent做出正确的决策。

上下文工程的常见策略

上下文工程涵盖很多不同的方法与技术。在实践中，有一些经过验证、可复用的策略，能帮助我们更好地实施上下文工程，这里为大家总结：

1）上下文分区与隔离

为了让“RAM”中的信息不打架、逻辑不混乱，可以对上下文进行分区：

• 将上下文划分为指令层、目标层、记忆层、知识层、工具层等
• 为每一层分配独立的 Token 预算与出现顺序，确保关键信息始终可见
• 给不同的角色（如规划器、执行器、反思器）分配不同的上下文切片，避免信息冗余与推理“漂移”

2）用RAG装备知识

• 通过检索召回相关的知识，动态注入上下文。
• 不要迷信超大上下文窗口 -- “把所有东西都塞进窗口”。太多的垃圾信息，只会让LLM又傻又慢。上下文不是简单的“堆料”，而是“选料”。

3）合理组装工具（Tools）

工具（Tools）是Agent的手脚，上下文工程要教他如何用手脚：

• 给每个工具以清晰、没有歧义的“说明书”（如函数Docstring）
• 仅装载最相关的工具，比如用RAG来筛选工具描述
• 让工具的异常返回具有清晰的“引导性”，而不是简单的“Tool Error”

4）多智能体协作

在大型的Agent任务中，多Agent是一种常见的架构模式：

• 每个子Agent拥有各自独立的上下文窗口与任务焦点，本身就是一种上下文隔离，减少干扰的手段
• 让单Agent推理100个工具，不如让五个Agent各推理20个，再加一个协调者
• 多Agent设计可以遵循模块设计经典原则“高内聚、低耦合”

5）修剪、卸载、压缩

在长程推理任务的Agent中，你需要考虑应对上下文的“滚雪球”式的膨胀：

• 修剪：适时删除不相关的信息。可借助LLM或者规则引擎来判断
• 卸载：让Agent在上下文之外”记笔记”，比如把阶段性结果写入外部存储，必要时再引用（如工具输出、动态规则等）
• 压缩：通过摘要或语义聚合让上下文更紧凑，提高信息密度而不过度冗长。

当然，除了这些重要的上下文策略，传统提示工程中的技巧仍然奏效：比如指令既不能太死板，也不能太空洞；提供少量但多样化的few-shot等。

Agentic上下文工程（ACE）是什么？

Agentic上下文工程（Agentic Context Engineering）是由斯坦福大学、SambaNova、UC 伯克利团队提出的一种上下文工程框架，，其核心理念是：

不用微调，不改变模型参数，让智能体自己成长。

换句话说，ACE 的目标不是“训练一个更聪明的LLM”来让Agent更聪明，而是让Agent学会“训练自己” — 通过不断调整和丰富它的上下文，实现一种类似“自我学习”“自我成长”的能力。

ACE采取了怎样的方法呢？

ACE 给上下文带入一份可以不断演化的**“策略手册（Playbook）”**。每次任务执行，Agent会从自己的表现中总结经验并修正，并带着改进后的“宝典”进入下一轮。如此循环往复，Agent的能力也随之积累与升级。

假设有一个客服智能体，负责回答用户的退换货问题。

• 第一次任务中，它在处理“退款到账时间”的问题时，给出了笼统的回答：“一般需要1–7个工作日。”

• 但用户追问后发现该回答并不准确，因为不同支付方式的退款周期不同。

• 任务结束后，反思器（Reflector）开始分析了这次对话的轨迹与失败原因：

“我没有区分支付渠道（支付宝、微信、信用卡），

导致回答模糊，用户体验不佳。”

• 接着，策划器（Curator） 会把这条经验转化为Playbook中的“经验”。这条经验会被注入到下一次任务的智能体上下文

“当回答退款周期问题时，需根据支付方式提供具体时间范围。”

• 第二次任务，当智能体再次遇到类似问题时，参考这条经验，回答变成：

“若您通过支付宝付款，退款通常在 1–2 个工作日内到账；

若使用信用卡，银行处理可能需要 3–7 个工作日。”

这就是一次完整的“ACE 循环”：

生成 → 反思 → 策划 → 再执行。

智能体没有改模型参数，却通过上下文的演化，

学会了更精准、更符合场景的回答。

Agentic上下文工程（ACE）原理与架构

ACE通过四个核心组件的协同工作，实现了 Agent 的持续学习和自我进化。这四个组件形成了一个完整的学习循环，让 Agent 能够从每次执行中积累经验，并将这些经验转化为可复用的策略：

• 策略知识库（Playbook）-- "记忆体"

ACE系统的"记忆中枢"，负责存储和管理 Agent 在实践中学到的所有策略。它不是一个简单的数据存储，而是一个智能化的知识管理系统，承担必要的策略维护与生命周期管理等。

• 生成器（Generator）-- "行动者"

承担常规任务执行的角色，基于当前上下文执行任务，产生一系列动作、推理轨迹和结果（如对话和工具使用序列）。在此过程中会暴露出问题：哪些策略是有效的，哪些出现偏差。

• 反思器（Reflector）-- "复盘者"

每轮任务后，对生成器的行为轨迹进行反思 ，提炼出具体的经验教训，如：哪些提示奏效了？哪些推理路径出现失误？哪类信息确实导致错误？你可以理解为一种“工作复盘：这一步我为什么错了？下次我应该注意什么？。

• 策划器（Curator）-- "策略管家"

将反思器给出的教训转化为可以附加在上下文中的可复用的策略，并维护更新Playbook。这里的关键在于：不是简单地插入或覆盖，而需要实现严格的质量控制（去重、修剪、评分等)、优先级决策、生命周期管理等能力。

我们用伪代码来认识工作原理：

# === 一次完整的 ACE 循环 ===def ace_round(task, playbook):    # 1) 取策略手册生成上下文（可含 RAG/工具说明/约束）    strategies = playbook.query(task)    context = build_context(task, strategies)    # 2) 行动者执行任务，产生轨迹    generator = Generator()    trace = generator.run(task, context)    # 3) 反思器复盘轨迹，产出“经验教训”    reflector = Reflector()    lessons = reflector.analyze(task, trace)    # 4) 策划器做质量控制，增量写回 Playbook    curator = Curator()    updates = curator.curate(lessons)    playbook.update(updates)    return trace, updates# === 主流程（持续的在任务过程中学习） ===playbook = Playbook()for task in task_stream():     # 连续的真实任务流    trace, updates = ace_round(task, playbook)

ACE 的创新在于，它建立了一个真正的智能体学习闭环：

生成→反思→策略->再生成

智能体不只是执行任务，而是在不断****学习如何执行得更好 - 每一次任务都在丰富它的上下文，完善它的策略。

这正是“Agentic上下文工程”的真正含义——

让上下文智能进化，进而让Agent自我成长，不断变聪明。

我们将在下篇中介绍一个ACE系统的原型设计与实现，欢迎继续关注。