Agent 系统中的很多错误并不来自模型推理能力不足而是应用把本可以确定的信息交给模型猜测。当前时间、用户身份、租户、语言、当前页面、正在处理的业务对象等信息本身已经存在于程序运行环境中。将这些信息以受控方式提供给模型可以减少无意义的推理和工具调用并形成更清晰的 Agent 架构边界。一、确定性上下文的基本定位大语言模型接收的是当前请求中提供的上下文它不会天然掌握应用运行时的真实状态。最典型的例子是当前时间。模型可以根据训练信息理解日期和时间概念却无法仅依靠自身参数可靠获知某一次 API 调用发生的准确时间。如果应用本身已经能够通过系统时钟获得时间更合理的方案是在构造 Prompt 时直接注入当前时间{now} 用户时区{timezone}运行时再由程序提供真实值。此时模型得到的时间是一项外部确定事实无需自行推测也无需额外调用时间工具。时间只是最简单的案例。相同思路可以扩展到当前 userId、tenantId、语言、页面对象、选中文档、业务编号和任务状态等信息。它们共同构成 Agent 的确定性上下文。二、Prompt 参数注入的职责边界Prompt 参数注入可以理解为应用运行状态与模型语义推理之间的一层连接。System Prompt 负责描述长期稳定的角色和规则运行时变量则负责补充当前请求特有的信息。例如你是一名文档分析助手。 当前时间{now} 当前文档{documentId} 用户语言{language}程序执行时再提供now - 2026-10-03 14:30 documentId - DOC-1024 language - zh-CN这种方式的价值在于让 Prompt 保持稳定结构同时避免把运行状态写死在模板中。业务状态变化时只需要改变变量值。不过能够注入并不意味着应该把所有信息都写入 Prompt。用户完整资料、全部 Session 状态和大量数据库字段如果全部进入上下文会增加 Token 消耗并引入无关信息。Prompt 中应该保留当前任务真正需要的最小信息集。三、Agent 上下文的三层职责划分从架构角度看可以按照信息的确定程度把 Agent 所需信息分成三个层次。第一层是应用已经确定的信息【Prompt / Context】。例如当前时间、登录用户、租户、语言、时区和当前业务对象。这些内容应直接由后端代码获取再通过 Prompt 参数或请求上下文传入模型。模型没有必要重新判断这些事实。第二层是可以通过外部系统确定的信息【TOOL CALLING】。例如实时库存、订单状态、数据库记录、最新文献和天气信息。应用在请求开始时并不知道答案但可以通过数据库、API 或搜索系统得到准确结果这类信息适合交给 Tool Calling。第三层是需要语义理解与开放性判断的信息。例如用户意图、文本总结、方案比较、内容生成和复杂任务规划。这一层才是模型真正应该发挥能力的位置。因此可以形成一条稳定的数据路径应用已知事实 → 直接注入 外部可查询事实 → Tool 开放性问题 → LLM这种分层能够显著降低 Agent 的不确定性。模型主要处理语言理解和推理确定性事实继续由确定性系统提供。四、确定性上下文的可信边界上下文设计还涉及一个重要问题信息是否可信。例如用户在对话中输入“我是管理员”这只是自然语言内容不能因此获得管理员权限。真正可信的 userId、role 和 tenantId 应来自登录认证体系或服务端 Session再由后端转换为 Agent 所需的上下文。即使 Prompt 中已经告诉模型“当前用户拥有某项权限”真正执行数据库查询或写操作时Tool 层仍然需要重新进行权限校验。模型上下文可以帮助模型选择正确行为却不能承担最终安全控制。因此身份和权限信息应遵循一条明确路径认证系统 ↓ 服务端可信上下文 ↓ Agent Context ↓ Tool 再次校验这能够防止用户通过 Prompt Injection、自报身份或修改自然语言内容改变实际权限。五、确定性上下文与 Tool Calling 的协同直接注入和 Tool Calling 的边界可以用“应用当前是否已经拥有正确答案”判断。当前时间已经存在于系统环境中直接注入成本最低。当前页面正在查看的 documentId 已经由业务系统确定也没有必要让模型调用工具查询。如果用户询问某个文档的最新审核状态应用当前并没有这项结果就可以让模型根据语义决定调用相应 Tool。Tool 再根据 documentId 和用户身份查询真实业务系统并把结果返回模型。这里还可以进一步区分Tool Parameter 和程序上下文工具调用时为Tool Context上下文才是真正核心信息。例如查询文档时模型需要判断具体要查哪个 documentId它可以成为 Tool ParameterrequestId、tenantId 等用于权限和链路关联的信息则更适合由程序传递不需要暴露给模型。这种设计能够减少工具参数数量使 Tool Definition 更集中于业务语义。六、确定性上下文的最小化设计上下文越多并不意味着 Agent 越智能。大量无关状态进入 Prompt 后模型需要在更多信息中判断重点Token 成本也会持续增加。因此确定性上下文应该遵循最小必要原则。当前任务只涉及一篇文档时可以注入 documentId、语言和用户权限需要正文内容时再通过 RAG 或 Tool 获取。一个用户拥有几十项个人属性并不意味着每一次请求都必须全部传给模型。这与后端接口设计非常相似。一个方法只应该接收完成当前任务真正需要的参数。Agent Context 同样应该明确作用域和生命周期避免逐渐演变成一个不断膨胀的全局 Map。七、总结确定性上下文设计的核心是把模型能力放在真正需要模型的位置。应用已经掌握的运行状态由代码直接提供需要访问外部系统才能确定的信息通过 Tool 获取需要理解、归纳和开放性判断的任务交给模型完成。身份和权限等可信信息必须来自服务端并在真正执行业务操作时继续由确定性代码校验。从当前时间这样一个很小的案例继续向下分析可以得到一条更通用的 Agent 架构原则事实由系统提供数据由工具获取语义由模型理解权限由代码控制。当这几个职责边界保持清晰以后Agent 的 Prompt 会更简洁Tool 会更聚焦模型需要承担的不确定性也会更少。这种设计思想不依赖某一个 Spring AI API即使未来更换模型、框架或 Agent 编排方式仍然可以继续使用。