Apollo
全部栏目

上下文构建器

上下文构建器把当前任务所需的指令、历史与证据整理成一次模型输入，决定模型这一次能看见什么。

返回概念图谱 →

理解与应用

上下文构建器（Context Builder）是应用中负责组装模型输入的部分。它可以是一个函数，也可以是一组处理步骤，并不是某个统一协议或必须使用的类名。它把当前请求、相关对话、已有状态和检索结果放到合适的位置，同时控制长度与来源边界。

例如用户问“我的杭州住宿能报多少”，构建器已经拿到员工类别、出差日期、几版差旅制度和此前聊天。它不应该把所有材料都堆给模型再祈望模型选对，而是先由可信系统筛出用户能访问的文件，保留适用日期的制度，再取出杭州住宿条款及其脚注。无关的机票讨论则可以省略。

输入的组织方式也影响理解。当前问题、系统指令与制度原文分别标明角色和来源，模型就不必从一大段拼接文本中猜测谁在说话。原文中若出现“忽略之前指令”，那仍是文件内容，不能因进入提示而变成系统要求。权限检查也不能交给文件自报的“公开可读”标签。

构建器最后需要在预算内保留足够的证据及限定条件，并记录选入了哪些材料、为什么省略其他材料。这样回答出错时，才能判断模型是没看到正确条款，还是看到了却解释错误。复用缓存时还要对应用户、权限和文档版本，否则同一问题可能拿到另一个人的资料或已经失效的制度。

关系速览
上下文工程应用于 →上下文构建器

上下文构建器是落实选取、排序、预算和来源边界的一种应用实现。

工作记忆应用于 →上下文构建器

构建上下文时可选取当前任务状态，不能把全部临时数据无差别塞入提示。

最小权限约束 →上下文构建器

构建提示时只取任务必要的数据，避免把无关敏感记录传给模型。

看看如何配置：一次住宿限额问答的输入组成

这是应用配置与输入结构示意，不是某个框架的配置语法。构建器确定模型能看见哪些内容，但条款解释是否正确仍要通过问答评估检查。

以下为教学示意，未连接真实业务系统。

配置示意

当前任务：回答本次杭州出差的每晚住宿限额。
可信业务字段：普通员工；出差日期 10 月 12 日。
资料范围：服务端确认用户有权读取的差旅制度。
选入证据：10 月 1 日生效版本的杭州行、表头与相关脚注。
未选入：已失效制度、无关机票对话、其他员工的报销明细。
来源标签：每段证据保留文件 ID、页码和生效日期。

配置对应的行为

模型输入包含当前问题、判断适用范围所需的字段和完整条款。
构建记录保留选入项、省略原因与预算占用，方便复查。

常见误区

  • 先取回所有资料再让模型判断可见性，已经越过了数据访问边界。
  • 把指令和引用原文拼成同一种文本，会让内容来源与权限变得模糊。
  • 缓存只按问题建立索引，可能混入其他用户的资料或过期文档。

前置与延伸

建议先读

相关概念

参考与版本

Apollo 原创讲解与教学示例。参考资料用于核对技术定义；核验日不代表资料的发布日期。