企业官网建设流程全解析

智能体系统中上下文和工具如何分工

智能体的上下文不是一个越大越好的缓存区，工具也不是注册得越多越强。上下文用来保留当前任务需要的事实、约束和状态；工具用来读取外部数据或执行受控动作。两者混在一起，会让模型难以选择能力，也会把权限和数据暴露面一起扩大。

上下文保存可解释的最小状态

保留当前用户目标、必要的会话摘要、已确认的事实和工具结果的引用。订单明细、大型检索结果、文件内容和图像原件放在权限受控的存储中，只有在当前任务确实需要时再取回。摘要必须带来源、时间和引用标识；没有这些信息，下一轮模型无法判断它是过期事实还是可继续使用的结论。

上下文裁剪不能只按最近几条消息删除。系统规则、用户显式约束和未完成动作通常要优先保留；旧聊天内容则可以压缩成可审阅的摘要。预算应以实际模型的 token 计算为依据，并为失败、重试和工具返回预留空间。

工具按任务和权限动态暴露

不要把所有 API schema 都交给模型。根据当前步骤选择少量相关工具，并让每个工具有清楚的名称、输入结构、输出上限和副作用说明。读取订单与取消订单应是不同权限的工具；涉及资金、发布或删除的操作默认需要额外确认。

def allowed(tool: str, approved: bool) -> bool: readonly = {"search_docs", "get_order"} return tool in readonly or (tool == "cancel_order" and approved)

这只是第一层检查。工具服务还要验证当前身份、租户、资源归属、参数范围和有效期。模型输出不应直接拼接为 shell 命令或数据库查询；使用参数化接口、白名单和超时限制。重复调用必须有幂等或去重设计，避免网络重试造成重复副作用。

用状态机连接两层

每次工具调用记录请求 ID、输入摘要、授权依据和结果状态，例如已提议、待确认、已发送、已成功或失败。模型只有在结果被外部系统确认后，才能说动作完成。遇到工具超时或数据源不可用时，返回可理解的状态并允许用户重试或转人工，而不是把未知当作成功。

最后通过端到端测试验证：权限撤销后旧会话不能继续调用，长对话不会丢失关键约束，工具返回异常时不会污染记忆。清楚的分工能降低成本和延迟，更重要的是让系统在出错时仍知道谁能做什么、发生了什么。

上线后监控工具选择分布、无效参数、授权拒绝和端到端耗时。若某个工具经常被错误选择，应改进任务编排或缩小它的暴露范围，而不是不断给模型追加描述。随着产品增加新领域，也应把工具按领域和风险重新分组，避免注册表逐渐变成无法维护的全局权限清单。

这一点应有明确的维护人。

并纳入常规评审周期。

持续复核。