上下文组装

上下文工程和提示工程差在哪？

提示工程关心这一段指令怎么写。上下文工程关心一次采样时，模型看见的全部 token 怎么配：系统指令、工具、检索结果、记忆、历史和输出格式。

智能体一轮轮跑，候选信息会膨胀。组装要回答的是：有限窗口里，这一步放进哪些 token，才最可能得到期望行为。

什么是上下文腐蚀，窗口里该怎么取舍？

上下文变长后，模型从里面准确找回信息的能力会下降。注意力要在 token 之间建立关系，长度上去就被摊薄。所以上下文是有边际收益的预算，不是越大越好。

高信号的部分是：写清边界的系统提示、职责不重叠的工具、少量典型例子、当前目标和最近观察。完整历史、原始工具输出和文档库留在外面。

GSSC 流水线是什么？

把组装收成四步，避免每个智能体各写一套：

1. Gather：把候选收成统一的信息包，带上内容、时间、token 数和相关性。
2. Select：按相关性和新近性挑选，不为每种来源再发明一套优先级。
3. Structure：装进固定骨架，例如角色与规则、任务、状态、证据、历史、输出要求。骨架固定，调试和对比才有可能。
4. Compress：超预算时压缩，但给系统规则留出比例，不能被证据挤掉。

长任务超出窗口怎么办？

三招，按任务选，不要默认全上。

• 压缩：接近上限时做高保真摘要，用摘要加最近的少量材料重开一窗。先保证关键决定还在，再删重复的工具输出。
• 结构化笔记：把进度、阻塞和结论写到上下文外，之后按需拉回。适合有里程碑的任务。
• 子代理：子任务在干净窗口里做，只把短摘要交回主代理。适合并行探索，不适合必须共享每一步细节的流程。

文件和代码不要事先全索引进提示。留下路径和搜索工具，用到再读。这比一份过期的全量索引更不容易把窗口撑满。代码库维护这类完整项目先不写，机制记到这里即可。