从一次模型调用说起

开发 AI 应用时，我们通常先写提示词：说明角色、任务和回答格式。但真正发送给模型的内容，还可能包含历史对话、检索资料、工具说明和执行结果。上下文工程（Context Engineering）关注的，就是如何在每次调用时选择、组织和维护这些信息。提示词设计是其中的一部分。(anthropic.com)

可以把它理解为给同事准备一份工作材料：任务是什么，哪些事实已经确认，有什么约束，还缺少哪些信息。材料不必包含整个项目的历史，但应足以支持下一步判断。

入门时，建议先问一句：为了完成下一步，模型需要看见什么？

为什么不能把所有材料都塞进去

上下文窗口有容量限制，而能够容纳长文本，也不代表模型总能准确利用其中的信息。无关内容、重复记录和相互矛盾的描述，都可能影响判断。扩大窗口无法代替信息筛选。(anthropic.com)

Agent 会进一步放大这个问题。它可能连续搜索、读取文件、调用工具，每次执行都会产生新的观察结果。这些结果进入后续调用，形成不断增长的上下文。(manus.im)

例如，用户已经把目标从“部署到测试环境”改为“只检查本地配置”，上下文里却仍保留大量部署指令。此时应明确记录最新目标，并标记旧计划已经失效。

所以，开发者需要管理的不只是信息数量，还有信息的适用范围和当前状态。

把每轮输入当成一次组装

可以先设计一个简单的组装流程：明确任务、收集材料、筛选整理、调用模型、更新状态。

建议把输入分成四部分：

  • 稳定规则：助手的职责、回答要求和操作边界。
  • 当前任务：用户最新的目标，以及必须遵守的约束。
  • 任务证据：相关文档片段、工具结果，以及它们的来源。
  • 进度记录：已经确认的事实、尝试过的操作和待解决的问题。

这里的分类是一种实现建议，不要求使用特定框架。即使只是几个函数，也可以先把流程跑通。

检索阶段，建议先按项目、环境等条件缩小范围，再查找相关内容；整理阶段，删除重复片段，保留版本、适用条件和出处；调用前，检查输入长度，并为输出预留空间。

工具接口也需要配合。工具名称、参数和返回内容应清晰明确，返回值应突出对任务有用的信息，避免让模型在大量内部字段中寻找答案。(anthropic.com)

一轮结束后，再更新进度。原始文档可以留在外部存储中，当前上下文保留摘要和可重新读取的位置。这样既能缩小输入，也给后续核查留下路径；压缩时应避免把原始信息永久丢掉。(manus.im)

小例子：帮助用户排查启动错误

假设我们要做一个项目知识库助手。用户问：

本地启动项目时提示缺少 APP_MODE，应该怎么处理？

下面的项目规则和检索结果均为教学假设。

知识库包含项目 A、项目 B 的文档，还有已经停用的旧说明。助手应先确定用户使用哪个项目。假设前文已经确认是项目 A，就可以按“项目 A、本地开发、当前有效”筛选资料。

找到的文档说明：

项目 A 本地启动需要设置 APP_MODE=local。该值仅用于本地开发。

这轮输入可以整理为：

规则：依据资料回答；资料不足时说明缺口。

任务：帮助用户解决本地启动缺少 APP_MODE 的问题。

已确认：
- 项目：A
- 环境：本地开发

证据：
- 来源：项目 A 开发指南，“环境变量”小节
- 内容：本地启动需要设置 APP_MODE=local
- 限制：仅用于本地开发

如果资料没有说明配置文件的位置，回答就应停在已知范围内，并继续查找配置加载方式，避免自行补出一个文件名。

用户随后说“设置后仍然失败”，下一轮应保留“已尝试设置变量、错误仍存在”，再补充新的报错和相关文档。这样，每次输入都围绕当前问题推进。

常见坑：材料看似齐全，实际无法判断

只看检索相似度。 在这个例子中，项目 B 的说明也可能包含同一个变量名。建议把项目和环境作为筛选条件，并让返回片段携带这些信息。

摘要只留下结论。 如果把“仅用于本地开发”删掉，原本有限定条件的建议就变成了通用指令。建议摘要同时保留结论、条件和未确认事项。

错误记录全部清空。 建议留下简短的尝试记录，例如“修改变量后仍报相同错误”。后续排查可以据此选择新的方向。

只凭一次演示判断效果。 可以准备一组固定用例，覆盖信息缺失、资料冲突和用户改口等情况。评估时同时检查任务结果、工具错误、耗时和 token 消耗，才能判断上下文调整是否有效。(anthropic.com)

小结

开始实践时，可以先实现一个明确的上下文组装函数：接收当前任务、历史状态和检索结果，输出本轮模型输入。

随后围绕失败案例调整：缺了什么就补充，哪些材料造成混淆就重新筛选，哪些进度容易遗失就结构化保存。把“模型每轮看见什么”变成可检查、可修改、可测试的流程，就是上下文工程的起点。

参考来源