从用户输入到返回结果，Agent 经历哪些流程？

核心回答

从请求到结果，可以分成接入、理解与补全、上下文组装、模型决策和工具执行、结果验收与返回五个阶段。中间的决策和执行通常会循环多次。

请求进入后，系统关联用户、会话和任务；保留原始目标，提取业务参数，缺关键条件就澄清。随后装配系统规则、当前状态、必要历史、检索资料和工具说明。模型生成回答或结构化工具请求，执行层完成校验、调用与结果回填，模型根据反馈决定下一步。最终检查结果是否满足任务，再返回内容、产物和未完成事项。

例如“查一下最受欢迎的无线耳机还有没有库存”，链路会先搜索产品，拿到产品标识，再查库存，最后把两项结果合成答案。模型不直接访问数据库，接口返回也不会自动变成可靠回答。

请求怎样进入运行系统

接入层完成身份验证、会话定位和请求记录，将附件或文件标识与本次任务关联。用户给出的业务范围要保存在任务状态中，后续检索和工具执行还要由服务端检查权限。

理解层将自然语言整理成目标和必要参数，例如类别是无线耳机，排序按工具提供的受欢迎程度，目标是查询第一名是否有库存。上下文不足时补问；明显的拼写纠正可以做，但不能把“是否有货”改成“帮我购买”。

模型与工具之间发生什么

上下文组装不等于复制全部聊天记录。它需要放入本轮目标、有效约束、相关历史与可用工具说明；资料过长时只带必要片段，并保留可继续读取的原文位置。

模型提出工具调用后，执行层按名称找到处理器，校验参数与权限，执行后返回内容、状态和必要证据。工具请求与结果必须保持对应关系。存在结果依赖的调用按顺序执行；彼此独立，且副作用和一致性约束允许的操作可以并行，不必只限于只读查询。

在示例中，搜索结果中的产品标识是库存查询的输入。如果库存工具返回“未知产品”，下一步应检查标识映射，而不是直接回答缺货。运行循环应把这个错误交回模型，允许它补查或停止，并记录工具调用与状态变化。

返回前后怎样闭环

返回前先检查用户关心的字段是否齐全、结论是否来自实际工具结果、产物是否真实存在。内容生成完毕和任务成功是两个状态；缺少结果时可以返回部分进度，不能把未知补成确定值。

运行记录至少关联任务、模型调用、工具名与参数、执行状态和耗时，用于区分“没选对工具”“工具没执行成功”“有结果但总结错了”。流式界面可以展示等待、工具执行和最终内容，但状态提示也必须对应真实事件。

对话记录持久化和任务恢复属于运行层责任。若需要中途等用户回复，保存缺失字段和任务位置；收到补充后先合并并重新校验，再继续执行。

追问

为什么不把权限判断完全交给模型？

模型看到的范围说明只能影响选择，实际工具和数据服务仍需按身份校验，防止构造参数越过用户的可访问范围。

模型调用完一次，整个请求就结束了吗？

不一定。它可能只提出了第一项工具请求，也可能正在等待用户。请求生命周期由任务状态和运行循环决定，并非单次模型接口的生命周期。

多轮任务如何避免重复操作？

保存操作标识、实际结果和未决状态。恢复后先确认外部动作是否发生，再继续；仅恢复聊天文本不能保证不重复执行。

对应教程

参考资料