智能体系统中上下文和工具如何分工智能体的上下文不是一个越大越好的缓存区工具也不是注册得越多越强。上下文用来保留当前任务需要的事实、约束和状态工具用来读取外部数据或执行受控动作。两者混在一起会让模型难以选择能力也会把权限和数据暴露面一起扩大。上下文保存可解释的最小状态保留当前用户目标、必要的会话摘要、已确认的事实和工具结果的引用。订单明细、大型检索结果、文件内容和图像原件放在权限受控的存储中只有在当前任务确实需要时再取回。摘要必须带来源、时间和引用标识没有这些信息下一轮模型无法判断它是过期事实还是可继续使用的结论。上下文裁剪不能只按最近几条消息删除。系统规则、用户显式约束和未完成动作通常要优先保留旧聊天内容则可以压缩成可审阅的摘要。预算应以实际模型的 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、输入摘要、授权依据和结果状态例如已提议、待确认、已发送、已成功或失败。模型只有在结果被外部系统确认后才能说动作完成。遇到工具超时或数据源不可用时返回可理解的状态并允许用户重试或转人工而不是把未知当作成功。最后通过端到端测试验证权限撤销后旧会话不能继续调用长对话不会丢失关键约束工具返回异常时不会污染记忆。清楚的分工能降低成本和延迟更重要的是让系统在出错时仍知道谁能做什么、发生了什么。上线后监控工具选择分布、无效参数、授权拒绝和端到端耗时。若某个工具经常被错误选择应改进任务编排或缩小它的暴露范围而不是不断给模型追加描述。随着产品增加新领域也应把工具按领域和风险重新分组避免注册表逐渐变成无法维护的全局权限清单。这一点应有明确的维护人。并纳入常规评审周期。持续复核。