← 全部文章

上下文工程:让模型像同事一样工作

2026-05-10#上下文477 字 · 约 1 分钟Read in English ↗

结论先行

真正决定输出质量的不是单次提示,而是每一步给模型看什么、隐藏什么。

已实测可复现上下文工程Prompt 设计

决策卡

把对话状态拆成可选择、可压缩、可回放的三层,而不是把所有历史都硬塞给模型。

为什么
上下文越长,噪声越多;把信息分层管理,才能让模型持续保持稳定输出,而不是前几轮还行、后几轮开始漂。
代价
需要额外维护摘要和检索逻辑,流程比单轮 Prompt 更复杂。
风险
摘要失真、历史遗漏、错误上下文混入,都会直接把后续输出带偏。
结果
这套方式在长对话和多步骤任务里更稳,尤其适合需要持续迭代的工作流。

Prompt vs Context

Prompt 是一次性指令,Context 是持续被加工的状态

写一个好 Prompt 让模型理解任务,但要让模型连续多轮还能保持表现,靠的是上下文工程。

上下文工程的三个动作

1. 选择(Select)

每轮对话开始前,决定:

  • 系统提示词的哪些部分要保留?
  • 历史消息里哪些可以折叠成摘要?
  • 工具调用结果哪些可以丢弃?

不是越多越好。窗口里塞进 50K 噪声 token,关键信息会被稀释。

2. 注入(Inject)

把"模型当前需要的事实"主动放进窗口:

  • 当前时间
  • 用户的偏好/会话历史摘要
  • 相关工具的可用状态
  • 已经做过的尝试

这些信息模型本来不知道,必须由你显式注入。

3. 隔离(Isolate)

子任务用子上下文。一个长任务拆成"调研 → 草稿 → 校对"三步时,校对那一步不需要看到调研的全部原始素材,只需要看到草稿。

一个简单的规则

上下文窗口是模型的"工作内存",不是它的"长期记忆"。

把会议要点、用户偏好、过期信息搬出工作内存,只留下当前这一步真正需要的东西——这就是上下文工程的全部秘密。

这篇对你有用吗?

如果这篇文章对你有帮助,可以请博主喝杯咖啡 ☕