智能工作流中上下文和工具如何分工智能工作流经常在两个极端之间摇摆把所有历史、表结构和原始数据塞进模型上下文或者把每一个小动作都拆成工具调用。前者看似省步骤后者看似可控但两者都会在任务变长时暴露问题。更实用的目标不是让模型“看到一切”或“调用一切”而是让它在正确的时机取得足够的信息并把可验证的事实留在系统边界内。上下文适合保存任务目标、权限范围、输出格式、当前计划和少量已经确认的事实。数据库查询、金额计算、时间处理、写入操作和外部系统访问应由受控工具执行。这样做不是因为模型不能生成计算结果而是因为这些操作需要确定输入、审计记录和明确的失败语义。先按任务风险划边界对于一次性文案生成少量会话上下文可能已经足够对于财务报表、工单更新或合规审查模型不应凭记忆复述数据更不应自己决定写入。工具需要在服务端重新校验身份和资源权限不能因为模型在上下文里看过某个用户 ID 就允许查询。工具返回的原始数据也不该无上限进入下一轮提示词。可以返回结构化摘要、分页结果或一份带权限的结果引用模型需要更多细节时再请求指定字段。摘要必须注明来源、时间范围和不确定项不能为了节省 token 把影响结论的条件压掉。最终给用户的数值或结论最好能回链到工具结果和计算过程。type ToolResultT | { ok: true; data: T; sourceId: string } | { ok: false; code: NOT_FOUND | FORBIDDEN | TEMPORARY_FAILURE } type MonthlySummary { month: string total: string currency: string itemCount: number } async function getMonthlySummary(userId: string, month: string): PromiseToolResultMonthlySummary { // 省略服务端鉴权、精确计算和审计记录 return { ok: true, data: { month, total: 0.00, currency: CNY, itemCount: 0 }, sourceId: report_x } }这个接口示意了结果类型的边界不代表所有工具都该返回摘要。文件搜索、批量导出和写操作会需要不同的错误码、分页或确认机制关键是把结构与语义明确下来而不是把一段自然语言错误信息交给模型猜。工具粒度围绕业务动作而非内部表结构过细的工具会让模型为了回答一个问题不断往返先找用户再找订单再找地址再做计算。过粗的工具又容易拥有过大的权限返回不必要的数据。好的粒度通常对应一个用户能理解、可以授权、可以审计的动作例如“获取某月已授权账户的汇总”或“提交一份待确认草稿”。定义工具时要限制输入范围、返回大小、调用次数和截止时间。模型对同一失败反复尝试时调度层应基于预算、步骤和状态进展停止任务而不是继续把错误塞回上下文。对于有副作用的工具先生成草稿或预览再由用户或规则确认会比让模型一次完成所有动作安全得多。上下文裁剪不能依赖字符数猜 token不同模型和语言的 token 化方式不同字符数只能做粗略容量预估。更可靠的是使用目标模型的计数器或给提示词留出固定输出空间并在服务端记录实际用量。裁剪时应优先保留系统约束、当前任务状态、用户明确要求和最近相关事实被移出的信息要么可通过工具重新取得要么被压缩为带来源的摘要。同时要警惕“摘要的摘要”逐渐偏离原始事实。任务跨多轮时可将关键事实存成结构化状态由代码更新模型只负责解释、规划或提出下一步查询而不负责维护唯一真相。对用户上传的文本和工具返回内容也要把其中的指令视为数据不能因为它出现在上下文中就提高权限。用观测结果调整边界上线后记录每类任务的提示词大小、工具次数、失败原因、重试、完成率和端到端耗时。若某类任务总是在同一组工具间往返可能需要合并为一个受限的业务操作若模型频繁要求同样的原始数据可能需要改进摘要或索引。调整前用真实样本验证质量和权限边界避免单纯为了少几次调用而扩大数据暴露范围。上下文负责让模型理解当前任务工具负责取得事实并执行受控动作。分工清楚后系统既不会把所有数据押在一次提示词里也不会陷入无意义的工具编排后续优化才有可以衡量的方向。