因素03：掌控上下文窗口

来源：12-Factor Agents / Factor 3（Own your context window）

一句话先懂

模型是“无状态函数”，它只会基于你给的上下文做判断。上下文质量，直接决定输出质量。

奶奶版理解

看病时如果只说“我不舒服”，医生只能猜。
如果你给出病历、检查单、过敏史，诊断就会更准。

上下文窗口就是给模型的“病历袋”。

原文最关键的 3 个观点

1. 上下文不止是聊天记录，还包括：提示词、RAG 文档、工具结果、历史事件。
2. 不必死守标准 chat message 格式，可设计更高密度的自定义格式。
3. 目标是“对模型更友好”：高信息密度、低噪声、可控安全。

标准格式 vs 自定义格式

标准 chat 很通用，但在复杂 agent 中往往冗长。

可改成事件流：

<slack_message>部署后端到生产</slack_message>
<list_git_tags_result>[v1.2.3, v1.2.2]</list_git_tags_result>
<approval_required>true</approval_required>
<question>请选择版本</question>

这种格式更适合“下一步决策”任务。

落地建议（能直接用）

1. 建立统一 Event 类型，沉淀成 thread。
2. 构建 thread -> prompt 转换器，可替换策略。
3. 做上下文压缩：保留关键事实，合并冗余历史。
4. 敏感信息默认脱敏，只给最小必要字段。

真实场景：部署失败恢复

部署报错后，不要把 500 行日志全塞给模型，建议只给：

• 错误类型：连接超时
• 目标服务：deploy-api
• 重试次数：2/3
• 建议动作：检查服务状态或请求人工

模型更容易做出正确下一步。

常见误区

• 认为上下文越多越好。
• 错误历史不压缩，导致注意力稀释。
• 把密钥、隐私信息直接塞入上下文。

我的思考

这条是 12 因素里最“值钱”的一条之一。

很多人把注意力放在模型参数调优，但在生产里，提升最大的通常是：

• 上下文组织
• 信息密度
• 噪声控制

也就是说：先做上下文工程，再谈模型玄学。

小结

• 上下文就是模型的世界。
• 结构化上下文通常优于原始聊天堆叠。
• 谁掌控上下文，谁掌控智能体效果上限。