Agent 详解：模型怎样调用工具完成任务
用查询工单的案例区分普通问答、固定工作流和 Agent，解释工具、状态、权限与任务结束条件。
01从回答问题到改变系统状态
“请解释工单优先级”可以通过资料问答完成；“找到我负责的紧急工单并整理摘要”需要查询业务系统；“把其中一条转给同事”还会改变系统状态。三种任务的要求不同，不能只因为界面都是聊天框，就认为它们是同一种能力。
工作流预先组织步骤和分支，例如识别工单编号、查询详情、生成摘要。Agent 则可以根据当前任务与执行反馈选择下一步行动。是否需要动态选择，取决于任务：输入输出清楚、流程稳定时，固定工作流通常更容易理解与控制。
02工具调用究竟发生了什么
工具是应用提供给模型使用的外部能力，例如查询工单、读取日历或创建草稿。模型通常提出工具名称和参数，由应用代码检查并执行，随后把结果交回模型。模型说“已经修改”并不表示业务接口真的成功，最终结果应以系统返回和实际状态为准。
一个“查询工单”工具需要说明可查询字段、参数格式、权限范围以及找不到记录时的返回方式。工具描述越贴近真实业务对象，越容易让系统选择合适动作。工具返回的数据也要区分正文、状态与错误，不能把一段失败提示当成查到的业务事实。
| 阶段 | 教学案例中的实际内容 |
|---|---|
| 用户任务 | 整理我负责的未关闭紧急工单 |
| 工具请求 | 按当前用户、紧急程度和状态筛选工单 |
| 应用执行 | 检查登录身份，调用工单查询接口 |
| 工具结果 | 返回允许访问的工单记录与查询状态 |
| 模型整理 | 归纳工单主题、负责人和待办事项 |
| 用户确认 | 若继续请求转派，展示具体对象和操作后再执行 |
03上下文、状态和记忆不是同一件事
上下文是模型这次调用实际看到的信息；状态是任务当前已完成哪些步骤、获得哪些结果；记忆通常指跨轮次或跨会话保留的信息。把全部聊天记录永久拼进提示，并不能自动得到可靠记忆，还可能保留已经过期的条件。
例如用户先要求查询全部工单，随后补充“只看我负责的”。应用需要更新有效筛选条件，而不是让旧条件与新条件并列竞争。已查询到的工单编号、尚未执行的操作、用户最后确认的对象，可以作为明确状态保存。哪些信息应长期保留，则要看业务需要与用户授权。
04任务什么时候算完成
查询类任务完成，意味着所需信息已经取得并向用户说明；修改类任务完成，则需要业务状态真的改变。评价 Agent 不能只看最终回答是否流畅，还要看工具是否选对、参数是否正确、必要步骤是否执行。
系统还要定义正常停止条件：任务已完成、需要用户补充信息、权限不足或无法继续。对于写入、发送、删除等操作，确认对象与范围尤其重要。工具接口的权限由应用控制，不能因为模型在文本中声称获得授权就扩大权限。
05为什么增加 Agent 数量不一定更好
多个 Agent 可以分担相对独立的工作，但也会增加信息传递、协调和检查成本。如果一个固定查询加一次摘要就能完成任务，拆成多个角色不一定带来收益。比较方案时，需要同时观察任务结果、执行时间、调用成本与可定位性。
分析失败案例时，可以沿“理解任务—选工具—填参数—执行—解释结果”逐段定位。工具返回正确而摘要遗漏关键工单，与工具根本查错负责人，是两种不同错误。这样的区分能帮助产品决定规则、开发修改接口，也能帮助算法团队选择需要优化的部分。