上下文的构成与消融

从 API 视角看，上下文由哪五部分组成？

• 系统提示词（System Prompt）: 由开发者编写，整个对话中保持不变，相当于“岗位说明书”；内含身份、权限、行为准则，以及跨会话保存的用户记忆和动态注入的环境状态;
• 工具定义（Tool Definitions）: 声明可用工具的名称、功能描述与参数格式；与系统提示词一起构成保持不变的静态前缀;
• 用户消息（User Messages）: 用户输入；可包含通过 RAG 动态检索引入的外部知识;
• 模型回复（Assistant Messages）: 最多含三部分——思考过程（reasoning）、文本内容（content）、工具调用请求（tool_calls）；三者不一定同时出现;
• 工具执行结果（Tool Results）: 框架执行工具后返回的结果，是下一步思考的直接依据;
• 结构: 上下文 = 静态前缀（系统提示词 + 工具定义）+ 动态轨迹（用户消息 + 模型回复 + 工具执行结果）;
• 注意: 没有工具定义，Agent 无法识别与调用任何工具，但不会因此停下来——见消融实验;

消融实验怎样判断各组件的贡献？

• 方法（Ablation Study）: 逐一去掉组件看系统是否正常，类比医生诊断时逐一排除病因;
• 设计: 五组对照——完整基线，加上四组各缺失一个组件；系统提示词作为基本身份定义不参与消融;
• 实测原则: “每个组件都不可或缺”要靠实测；模型迭代很快，同一消融换到新模型上完全可能得出不同结论;
• 衡量标准: 该组件承载的信息能否从别处重建;

每个上下文组件的实际作用是什么？

组件	缺失后的表现	说明
工具定义	无法调用任何工具，但照样给出格式工整、语气笃定的答案	行动能力的基础；编造与否取决于模型幻觉率与诚实度，提示词约束只能降低概率
工具执行结果	Agent “盲目”执行，反复重试直到耗尽迭代预算	闭环控制的关键
思考过程（reasoning）	代价很小	当“为什么这么做”可从工具结果重建时，从历史中丢掉几乎没有代价
历史消息	冗余操作增加，重复犯同样的错误	防止重复操作

这个实验最重要的工程结论是什么？

• 能力上限: 上下文决定了 Agent 能看到什么，而 Agent 只能基于它看到的信息做决策;
• 组件不等价: 去掉工具定义或工具执行结果会直接夺走行动与闭环能力，去掉另外两者的代价取决于信息能否从当前观测重建;
• 最危险的失败: “给出了回答”不等于“完成了任务”——上下文残缺时典型的失败不是报错退出，而是一个看上去毫无破绽的答案;