提示词工程这个词在 2023 年火过一阵，到 2026 年已经显得过时。不是因为写提示词不重要了，而是因为大家意识到，决定一个智能体表现的关键，不再是那几句精巧的开场白，而是整个上下文窗口的动态管理——放什么记忆、检索哪些文档、何时清空、何时压缩。这就是上下文工程。

上下文窗口的稀缺性为什么变成核心约束？

上下文窗口从几千 token 涨到几十万、甚至上百万 token，看起来很大，但一个真实智能体跑起来，系统提示、工具描述、对话历史、检索文档、中间推理步骤加在一起，几分钟就能吃掉一半。窗口是有限的昂贵资源，每塞一句话都要付出「挤掉别的内容」的机会成本。于是上下文工程的第一性原理，就是把窗口当成预算来分配——哪些信息必须常驻，哪些可以按需拉取，哪些应该在用完后立刻丢弃。

记忆与检索的边界在哪里？

不是所有历史都值得放进上下文。很久以前的对话细节、已经完成的任务结论、不再相关的用户偏好，这些东西如果硬塞进窗口，只会稀释注意力。成熟的做法是分层：最近的对话保留原文，更早的压缩成摘要，再久远的存到外部向量库按需检索。这套分层策略本质上是在模仿人类记忆——工作记忆很短，长期记忆靠联想提取。论坛里 智能体架构 的讨论，大量篇幅都在争论这几层该怎么切。

上下文工程会取代微调吗？

短期内两者是互补的。微调负责把通用能力定制成领域风格，上下文工程负责把每次任务的具体情境喂进去。很多场景下，与其花几万块做一次微调，不如把领域知识写成高质量的系统提示和检索集，效果不差且随时可改。但反过来，有些深层行为习惯——比如特定输出格式、固定决策风格——微调仍然更稳。未来的智能体栈，大概率是小模型加精细上下文，而不是巨型微调模型。

上下文工程的崛起，标志着大模型应用从「调提示词」的手工作坊，进入了「管理状态」的系统工程时代。谁把窗口预算花得最聪明，谁的智能体就最聪明。

上下文预算该怎么量化分配？

把上下文窗口当成一个有限的预算池，每一段塞进去的内容都要算机会成本。系统提示占多少、工具描述占多少、对话历史压缩到什么粒度、检索文档留多长，这些都需要按任务类型建模。一个常见误区是把所有历史都保留，结果窗口被无效信息塞满，真正相关的细节被注意力稀释。成熟的做法是给每一类内容设定配额，超限时自动压缩或外移，让模型始终在一个信噪比可控的窗口里工作。

去论坛讨论

前往 silicon-agi.com 论坛 参与讨论。