上下文工程：AI长任务性能优化的核心策略

Prompts 确立意图。Context 选择事实、历史和工具输出，让 AI 在长任务中保持连贯。

在 AI 应用的早期，我们沉迷于字词的斟酌。微调一个动词，增加一条约束，观察模型是否按预期响应。这些技巧常常奏效，足以让人以为这是一门手艺。直到任务变得更长、更复杂、涉及更多步骤时，一条安静的真相才浮出水面：措辞固然重要，但模型看到什么 更为关键。

Prompt engineering 关注“如何把问题问好”。Context engineering 则关注此刻应该把哪些信息摆上台面 。这包括指令、检索到的事实、工具输出、计划，以及仍然会影响下一步的那部分历史。工作重心从“讨巧的提问”转向“信息的策展”，从机灵的话术转向精挑细选的输入。

别把模型当作精灵，更像是舞台监督。你的职责是决定谁上场，说哪句台词，什么时候退场。

为什么这很关键？因为模型有注意力预算。每个新增的 token 都会加剧对注意力、成本和延迟的竞争。将上下文窗口填得过满，输出质量会下降；提供的信息过少，模型则会凭空编造来填补空白。真正的技艺在于找到平衡点：提供相关、及时、最小化 的信息。

想象一个执行研究任务的智能体。它浏览资料、做笔记、调用工具，持续一小时。如果每一轮交互都重播全部历史，你需要为速度和连贯性付出代价；如果过早压缩历史，又会丢失真正需要的细节。系统的表现取决于你喂给模型的 context，而不是你囤积的 context。

Context engineering 是一门选择、塑形、编排 模型下一步应当关注内容的学科。

这并非否定 prompts 的价值，而是将其置于一个更大的框架中。好的 prompts 仍然锚定意图与语气，但它们坐落在一个动态的 context 里，必须在任务展开时被修剪、总结、刷新。每个强大系统背后的问题都变得既简单又苛刻：为什么是这些信息、在这一步、以这个代价、为了这个结果。

Context vs. Prompt Engineering

有什么区别？

Prompt engineering 调教的是指令 。你打磨措辞、约束、语气，让模型理解意图。它是“局部的”、迭代迅速，适合短小且独立的任务。

Context engineering 塑造的是信息集合 。你决定哪些事实、历史、计划、工具输出应该进入模型的上下文窗口，且是针对当前这一步 。它是“系统性的”，难以通过小技巧优化，当工作跨越多轮交互与多个工具时，其价值会显著放大。

指令再精炼，如果输入信息错误，任务也会失败；反之亦然。提示可能很混乱，但当正确的文档、数据和状态在场时，任务也能跑通。二者的区别不在于“文案”与“数据”的对立，而在于单句指令与信息供应链 的差异。

从职责角度思考：Prompt engineering 锚定声音、目标和安全护栏；Context engineering 策展信息来源、压缩历史、编排工具结果。一个在约束语言，另一个在约束流程。

权衡随之而来。更重的 context 会增加成本、延迟，也扩大了出错面；更轻的 context 则冒着遗漏关键信息、导致重复工作或系统脆弱的的风险。需要根据任务类型校准：短问答偏向 prompt 技巧，长流程的智能体则更依赖 context 的控制。

为什么把 prompt 视为 context 的子集？因为指令本身就在你组装的上下文窗口里“同行”。如果窗口嘈杂或信息单薄，再完美的措辞也救不了场；如果窗口相关且精简，普通的措辞往往就足够了。

实践中的判断标准很简单：如果你的改进计划改变了句子，你在做 prompt 工作；如果它改变了模型读什么 ，你在做 context 工作。最好的系统两者兼顾，且通常按这个顺序来构建。

为何随着 AI 成熟，Context 更重要

短任务会原谅糟糕的输入，长任务不会。一旦智能体开始浏览、调用工具、拟定计划、反复修改文稿，prompt 就不再是性能瓶颈。真正移动的靶子是“状态”：模型该记住什么、忘记什么、重新读取什么。

模型在这点上很像人类。工作记忆稀缺，长期记忆嘈杂。把一切塞进上下文窗口，注意力会涣散；剔除得太狠，又会丢掉主线。手艺不在于“量”，而在于“压力下的取舍”。

用预算思维。每个 token 都在购买注意力、延迟、金钱。要把预算花在能产生复利的地方。

多轮工作会留下轨迹。工具输出、中间计算结果、用户纠正、细小决策的积累速度超出预期。逐字逐句重播这条轨迹，系统会变慢，答案质量会漂移；不加思索地做总结，又可能压掉恰恰支撑下一步的那个关键数据。

这些失败模式与真实团队的通病如出一辙：旧错误残留，污染后续步骤；过时事实与新鲜事实并列，模型把它们混在一起；无关历史干扰下一次选择。另一边，修剪过猛会造成既视感：智能体反复学习它本来就知道的事。

有用的 context 位于相关性、时效性、可靠性 的交集。除此之外的信息，都是负担。更大的窗口容量有帮助，但也容易养懒：人们不再精心策展，因为系统“吃得下”。结果是账单攀升、延迟拉长、质量仍然下降。

设计问题转向务实：跨轮次需要缓存什么？需要重算什么？现在总结什么、以后再总结什么？这些是“策略选择”，不应事后想起，它们决定了你的智能体是保持专注还是走神。

Context Engineering 的构件

Context 不靠一个绝招，而是一套小而严的纪律，彼此配合。Retrieval 拉来候选信息，Processing 进行提炼，Memory 管理时间维度，Orchestration 让整条环路保持清醒。把这些做好，模型读到的是简报，而不是逐字稿。

1/ Context Retrieval 与 Generation

从“可能有用的候选信息”开始，而不是迷信模型“本来就知道”。从文档、代码、日志、工单或向量数据库中检索——带着预算意识去做。检索是工具，不是拐杖。

信息生成也属于这里。计划、假设、工作笔记不会凭空出现。让模型起草一个简短计划，然后把这个计划当作下一步的输入。草稿（scratchpads）让思考过程可见、可验证。

对“新鲜度”要挑剔。过期一周的 FAQ 若与新政策矛盾，比没有更糟。来源不可信，就别检索。你能维护的最简单检索策略，胜过你维护不动的花哨策略。

2/ Context Processing、Summarization 与 Compression

原始输入很少值得直接呈现。为长段落做总结，去掉套话，对敏感字段做脱敏。保留能锚定决策的数字与名字；丢掉只增添情绪、没有信息量的形容词。

压缩往往是团队容易抄近道的地方。克制“全都塞上去以求保险”的冲动。每多一个 token 就意味着延迟与成本。如果确实需要更长的记录，把它写进 memory，按需再取关键片段。

顺序很重要。先给出清晰的指令，再放置高信号的事实，然后是更短的历史。别把请求埋在 context 堆里指望模型自己挖出来。

3/ Context Management 与 Memory

短期 context 是窗口，长期 memory 是存储，要分开使用。窗口留给会直接影响下一步的东西；存储留给你希望跨轮次保留的事实与决策。

写得比你以为的更少。存储用户偏好、已解析的 ID、重新发现代价高的决策，以及紧凑的过去工作摘要。回避八卦与琐碎。按任务与语义双重索引，方便后续选择性检索。

隐私是设计，不是复选框。写入时脱敏、静态加密，明确可被召回的范围。没有什么比模型突然翻出用户没想到会再出现的旧细节更伤信任。

4/ Context Integration 与 Orchestration

真实系统要使用工具。工具输出也是 context，所以同样需要纪律。别整页地粘贴搜索结果或日志。提取相关行，并保留源链接以便审计。

子任务应有独立的 contexts。研究型智能体可广泛阅读，然后给写作型智能体一份两段式的简报。编码型智能体需要的是函数签名与失败的测试，而不是整个代码仓库。分离能降噪，让错误局部化。

编排是写进代码的策略。决定何时检索、何时总结、何时写入 memory、何时丢弃。为整个流水线添加监控，在生产环境观察 token 计数与延迟。目标是稳定的环路，而不是炫技的演示。

编排的检验很简单：拿掉某一步，如果质量可测地下降，那它就值得保留；否则就删。

稳定环路的共性

• 目标与预算先行：先把任务目标与 token 预算说清的团队，选择会更干净。这听起来形式化，但当延迟与成本开始漂移时，它会省大事。
• 检索即假设：检索更像“假设”而非“真相源”。在操作性任务上，新鲜度胜过广度；在开放式研究上，广度有益。不要猜测，值得测试。
• 总结保关键：总结只有在保住数字、名字、决策时才有用。这些一丢，错误率就会上升，哪怕 prompts 看起来更干净。掩盖关键数字的整洁总结，是个 bug。
• 顺序至关重要：耐用的系统常把指令放前、硬事实其次、历史只留薄薄一层：清楚的请求，其次是证据，再有恰到好处的过去以保持自洽。
• 记忆需管理：把耐久事实写入 memory，且控制范围。一个越长却从不提升结果的存储，只是新杂物。决定留弃时，监控数据胜过直觉。

从打磨 Prompts 到工程化 Context

一种新范式

Prompt 小技巧给了我们开门红，它们仍然重要。但如今的工作更像“系统设计”而不是“文字游戏”。我们在选择信息来源、决定什么要持久化、把工具输出当作信号进行路由。

心智转变说起来简单、做起来难。与其问“怎么表述”，不如问“模型必须读什么，按什么顺序，为什么是现在”。这个问题引出的是“策略”，不是一次性的招数；也引出“度量标准”。

团队习惯也会随之改变。内容创作者与产品经理共同定义目标与语气；工程师搭建检索、记忆与过滤管道；数据分析师关注数据漂移与成本。只有这些角色坐在一起，对“什么是好”达成一致，整个环路才能顺畅运转。

失败模式也变了。过去 prompt 不好，答案就不好，你改句子就行。现在 context 不好，答案看起来可能像样却暗中走偏。错误藏在缺失的事实、陈旧的片段、或未经修剪就粘贴的工具结果里。

你不需要宣言来实践它。首先，明确某类任务每一轮都应该“存活”的少量关键事实。决定它们存储在哪里、何时被召回。设定一个硬性的 token 预算并遵守。其他都是在此基础上的打磨。

关于团队文化的最后一笔：Context 工作在“轻意见、重证据”的团队里更茁壮。某一步如果不改变结果，就删掉；更小的窗口表现更好，就保持更小。以“最小化”为傲，胜过以“复杂度”为傲。

结论

The Future is Engineered Context

Prompts 开启对话；Context 让对话保持诚实。耐久的系统把信息当作可塑的材料，而不是用来膜拜的垃圾场。它们选择谁该在场、谁该候场、谁永不入场。

收益是现实可感的。更小的模型在干净的简报下也能显得更锋利；评审更短，因为决策依据存放在该放的地方；团队少争论文案，多争论来源、顺序与成本——这样的争论更健康。

责任同样在这儿。记忆是力量，力量需要边界。写入你能辩护的，检索你能验证的，有意地遗忘。你守住的信任，是你交付的产品的一部分。

如果我们把 context 当成产品表层来对待，配上预算、测试与清晰的意图，会发生什么变化？答案很少是“更多数据”，更常是“更好的时机、更清晰的次序、更少的意外”。

Prompts 是接口。Context 是让这个接口可靠的环境。请慎选你的环境。

难的不是造更大的窗口；难的是决定该留什么在外，并在“再多粘一点更容易”时仍然守住这条线。这就是手艺，这就是工作的所在。

关注“鲸栖”小程序，掌握最新AI资讯