从一次 API 调用到一个 Agent

Agent是在一次模型调用之外，增加了什么

到这里，你已经学过模型API、消息、资料与工具。Agent可以用这些已有概念连接起来理解：应用围绕一个目标，让模型选择行动，执行允许的工具，把反馈交回模型，再根据新情况继续或停止。

本课程使用这个工作定义，是为了突出“根据反馈选择后续行动”。不同产品对Agent的命名范围可能不同，不能只凭一个产品叫作Agent，就判断它具备怎样的自主能力。

第一层：一次普通模型请求

任务是“为12人找周日14—16点可用、总价不超过600元的场地”。如果只调用一次模型，没有提供场地信息和查询能力，它可以给选址建议，却不能确认真实空位与价格。

这一层只有用户目标和模型生成。应用把结果显示给用户后就结束，不会自动知道下一步查哪一家。模型能够描述计划，不代表计划已经执行。

第二层：加入一次工具调用

应用增加query_venue工具，并向模型说明它能查营业、空位、容量与价格。模型返回“查询A”的请求，应用运行工具，得到“A周日关闭”。然后把结果交回模型，它可以说明A不合适。

此时系统已经连接了外部能力，但如果应用到此就停止，仍没有完成找场地的目标。单次工具调用解决的是一次交互，不能代替持续推进整个任务。

第三层：让反馈决定下一次调用

应用保留原目标与查询记录，再次调用模型。模型看到A关闭，可以请求查询B。工具返回“B容纳16人，目标时段可用，总价520元”。这些新事实再次进入上下文，模型才有条件做出比较。

第四层：决定什么时候可以结束

B是否满足目标，要逐项比较：16人容量能容纳12人；目标时段可用；520元不超过600元。若任务只要求推荐，交付这个候选及依据便可以结束。若还要预约，则需要预约工具与具体授权，并核对执行回执。

应用还需要规定失败条件，例如工具连续不可用、没有合适候选、预算无法满足、达到轮数上限。停止时保留已有证据，说明还缺什么，不能靠不断生成文字假装任务一直在进展。

最小实现的逻辑可以怎样写

下面是白话伪代码，用来说明控制过程，不能直接作为某个平台的可运行程序：

保存用户目标、约束和可用工具。
在次数与权限允许的范围内：
  把当前记录交给模型。
  如果返回最终答案，检查并结束。
  如果返回工具请求，检查参数与权限。
  执行工具，把真实结果加入记录。
达到限制或无法继续时，说明状态并停止。

框架可以替开发者封装这段循环、消息格式和工具分发。可视化平台也可以提供类似能力。无论使用哪一种，理解这些部件都能帮助你判断系统实际做了什么，以及为什么卡住。下一课会把这段循环展开为可观察的日志。