大模型后端中上下文和工具如何分工大模型后端容易走向两个极端把历史、检索文档和所有工具说明一次塞进请求或者为了缩短 Prompt删掉模型判断真正需要的证据。更实用的划分是上下文提供本轮决策所需的信息工具在受控权限内读取数据或执行动作。两者都要少而够用而不是越多越保险。上下文只保留和当前任务有关的部分系统约束、当前问题、必要会话状态、检索证据与候选工具定义都应能回答“模型为什么此刻要看到它”。无关历史、整篇原文和不可调用的 Schema 只会挤占窗口也会稀释关键限制。长 Prompt 的延迟和成本受模型、缓存、硬件与调度影响不能拿简单公式直接推断应记录输入 Token、首字延迟、总耗时和缓存命中再按任务类型比较。会话压缩也没有固定保留轮数。把稳定事实抽成结构化状态近期原文保留在短窗口较早内容按需检索通常比无止境堆叠更可控。涉及金额、权限或用户承诺时应优先引用原始记录。检索结果同样要附带文档标识、版本和片段来源证据不足或互相冲突时把不确定性明确传入而不是拼出一个貌似确定的答案。工具负责受控地接触外部系统模型可以选择工具和提出参数后端仍要负责鉴权、参数校验、超时、幂等、审计和结果裁剪。模型给出的参数不应绕开正常 API 权限用户无权读取的数据也不能通过工具回填到上下文。工具清单可按场景缩小但路由结果只是候选集合不是授权结论。高风险动作适合两阶段处理先生成操作草案展示关键参数并取得确认再使用幂等键执行。工具 Schema 说明字段、类型、枚举和语义即可不应暴露内部表名、凭证或实现细节工具返回也应裁剪大结果可分页或先聚合。func (e *Engine) Handle(ctx context.Context, name string, raw json.RawMessage) Result { tool, ok : e.tools[name] if !ok { return Result{Code: tool_not_available} } if !json.Valid(raw) || tool.Validate(raw) ! nil { return Result{Code: invalid_arguments} } callCtx, cancel : context.WithTimeout(ctx, tool.Timeout) defer cancel() reply : make(chan reply, 1) go func() { data, err : tool.Execute(callCtx, raw); reply - reply{data, err} }() select { case r : -reply: if r.err ! nil { return Result{Code: tool_failed} } return Result{Data: r.data} case -callCtx.Done(): return Result{Code: tool_timeout} } }这里的 Context 只能传递取消信号不能强行停止忽略它的函数数据库和 HTTP 客户端也必须设置自己的超时并响应取消。写操作还需要授权、幂等记录与审计通用执行器无法替业务自动推断这些规则。返回模型的错误应稳定且简短原始 SQL、地址和用户数据留在受控日志中。上下文和工具结果进入日志、追踪或评测集前也要做最小化处理。完整提示词、检索原文和用户输入可能包含敏感信息排障不等于无限制保留。为不同任务定义保留范围、脱敏方式和访问权限才能在质量分析与数据保护之间保留清晰边界。流式接口也要定义事件、结束、错误和取消语义。SSE 的Last-Event-ID只有服务端保存可重放事件时才可能续传涉及写工具时重连尤其不能重新执行已成功的动作。一次响应应能追踪用了哪些证据、暴露了哪些工具、调用为何失败以及客户端何时断开。边界清楚后才知道该删的是无关上下文该移到工具的是外部动作而该保留的是让模型做出可靠判断的证据。