企业官网建设流程全解析

大模型后端中上下文和工具如何分工

大模型后端容易走向两个极端：把历史、检索文档和所有工具说明一次塞进请求，或者为了缩短 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只有服务端保存可重放事件时才可能续传；涉及写工具时，重连尤其不能重新执行已成功的动作。一次响应应能追踪用了哪些证据、暴露了哪些工具、调用为何失败以及客户端何时断开。边界清楚后，才知道该删的是无关上下文，该移到工具的是外部动作，而该保留的是让模型做出可靠判断的证据。