上下文工程
一、为什么上下文工程这么重要
很多人理解 Agent 时，会把“上下文”简单理解成聊天历史。但在制造场景里，这个理解远远不够。
因为一次真实分析往往还涉及：
- 当前问题属于什么场景
- 对象、时间、粒度和口径是否已经确认
- 上一轮哪些结论值得被延续
- 哪些知识、术语、案例或偏好应该参与本轮
- 本轮允许使用哪些工具、哪些能力需要被限制
所以，对产线军师来说，上下文工程不是“多带点历史”，而是“决定 本轮到底该看什么”。
二、上下文不等于聊天历史
从产品视角看，产线军师一次分析里可能进入上下文的信息至少包括六类：
| 类型 | 作用 |
|---|---|
| 当前用户问题 | 明确本轮分析主题和目标 |
| 会话历史 | 衔接上一轮已确认的对象、时间和追问关系 |
| 记忆 | 延续当前任务状态、近期线索和长期偏好 |
| 知识 | 提供术语、规则、案例和经验依据 |
| 时间与作用域 | 明确本轮的时间窗、项目范围和部署边界 |
| 工具与 Skill 边界 | 决定哪些能力可用、哪些能力不应进入本轮 |
这意味着产线军师不是把全部历史原样丢给模型，而是会先做筛选、投影和约束。
三、产线军师如何做“先判再给”
上下文工程最核心的 原则不是“给得越多越好”，而是：
先判断本轮是什么问题，再决定应该给模型什么。
通常会先做几件事：
- 判断这是查询、对比、诊断、建议还是知识类问题
- 补足对象、时间、粒度和口径
- 判断本轮应该开放哪些工具、哪些能力不该调用
- 再决定是否需要带入记忆、知识和术语信息
也正因为这样，系统有时会先澄清，而不是立即回答。
四、为什么系统不会把所有历史都带进来
如果把所有聊天历史、工具结果、表格和图表原样带入模型，通常会带来三个问题：
- 噪声变多：大量无关信息会干扰本轮判断
- 成本变高：上下文越长，计算成本和响应时延越高
- 结果变散：模型更容易抓错重点或沿用过期信息
因此，产线军师更强调：
- 只延续真正相关的历史
- 把工具痕迹转成更适合模型理解的轻量事实
- 在预算内优先保留“对本轮最有帮助的信息”
五、上下文工程和记忆、知识的关系
上下文工程本身不是记忆，也不是知识库， 但它负责决定二者如何进入本轮分析。
| 机制 | 更关注什么 |
|---|---|
| 记忆机制 | 哪些事实值得被延续 |
| 知识闭环 | 哪些规则、案例、经验值得被复用 |
| 上下文工程 | 这一轮到底带哪些内容进模型、带多少、按什么顺序带 |
简单理解：
- 记忆回答“要不要记住”
- 知识回答“有没有依据可查”
- 上下文工程回答“这一轮到底给模型什么”
六、为什么澄清问题是上下文工程的一部分
在制造分析里，同一句话往往可能对应多种口径。比如：
- “昨天”是自然日还是班次归属日
- “产量”是上线数、下线数，还是合格产出
- “这条线”是整线，还是某个工序段
如果系统在上下文不充分时强行回答，就很容易得出“数字看似对，口径其实错”的结论。
因此，必要时先澄清，并不是交互变慢，而是上下文工程在主动保证结果可信。
七、上下文工程对业务的直接意义
从用户视角看，上下文工程带来的直接体验是：
- 追问更连续，不必每轮都重说背景
- 澄清更聚焦，不会反复问无关问题
- 输出更贴近本轮真正想解决的问题
- 结果更容易保持口径一致
这也是为什么产线军师的对话体验更接近“懂业务的分析同事”，而不是单纯的聊天窗口。
八、进一步阅读
如果你想继续理解：