收益：
- 将代理定义为“模型+工具+循环”并决定何时需要它
- 使用名称、描述和 input_schema 编写工具定义
- 监控 tool_use 和 tool_result 循环的流程和错误处理
到目前为止，该模型始终只完成一项工作：接收文本输入，生成文本响应。但实际工作往往需要的不仅仅是文本；执行计算、查询数据库、调用 API、找出当前汇率。模特无法自己做这些事情，但她可以决定何时需要完成这些事情并要求别人做。这就是工具使用给出的模型，这是人工智能代理的基础。在本单元中，我们将了解代理是什么、工具是如何定义的以及 tool_use 循环如何工作。
什么是代理？模型+工具+循环
人工智能代理由三部分组成：模型（做出决策的大脑）、工具（模型可以调用的功能：天气、数据库查询、发送电子邮件）和循环（循环；模型调用工具，获取结果，再次决定做什么，等等）。
关键区别：单个模式调用不是代理。代理是模型逐步进行的过程，每一步都根据工具结果选择下一步行动。 “像人一样思考，用你的双手，看看结果，再想一想。”
一个重要事实：模型本身并不操作车辆。该模型只是说“我想用这些输入来调用这个工具”。您的应用程序（称为harness）运行该工具并将结果返回给模型。这对于安全性至关重要：模型不会直接接触您的系统；每一个动作都在你的掌控之中。
提示：不要试图通过代理解决所有问题。代理人;增加了延误、成本和错误的风险。首先询问：“这个问题可以通过一次调用还是固定的工作流程来解决？”如果答案是肯定的，则无需代理人。代理适用于无法提前知道步骤的开放式任务。
工具定义：名称、描述、input_schema
要将工具引入模型，您需要提供三件事：
- name：车辆的身份，例如获取天气。
- 描述：该工具的作用以及何时调用它。这是允许模型在正确的时间选择正确的工具的最重要的领域。不仅要写“做什么”，还要写“何时调用”。
- input_schema（输入模式）：定义工具需要哪些参数、类型的 JSON 模式。
# 车辆定义（概念 — JSON 模式）{ "name": "get_order_status", "description": "检索订单的当前发货状态。当用户询问订单号在哪里或何时到达时调用。", "input_schema": { "type": "object", "properties": { "order_no": {"type": "string", "description": "订单号，例如SP-1024"} }, "必需": ["order_no"] }}
一个好的工具描述的规则：清晰简洁的名称，带有“何时使用”的描述，每个参数的描述，将真正强制的参数放在必需的位置。保持车辆数量集中；数十种类似车型令人惊讶。
面积
它有什么作用？
好例子
坏榜样
姓名
车辆ID
订单状态获取
带
描述
它的作用 + 何时调用
“返回货物状态；当用户询问订单在哪里时调用”
“获取数据”
输入模式
参数类型及要求
{order_no：字符串，带注释}
无图表/无描述
tool_use → tool_result 循环
这个循环是这样一步步进行的：
- 您将用户问题+工具描述发送给模型。
- 该模型要么直接响应，要么生成一个 tool_use 块：“使用 order_no=SP-1024 调用 order_durumu_getir”。
- 您的应用程序实际上运行该工具（查询数据库）。
- 您将结果作为 tool_result 发送回模型。
- 根据此结果，模型要么生成最终答案，要么调用另一个工具。这个循环一直持续到模型说“我完成了”。
# 代理循环（概念）messages = [user_question]while True: response = model.uret(messages, tools=tool_definitions) if response.tur == "tool_use": result =harness.run(response.tool_name, response.entries) # 应用程序运行 messages += [response, tool_result(result)] # 返回结果 else: break # 最终响应;循环结束
现代 SDK 提供了为您运行此循环的工具运行程序；您只需编写工具功能即可。但这正是幕后发生的事情。
错误管理
工具可能会失败：找不到订单、API 超时、输入无效。如果无法运行该工具，请将错误作为描述性 tool_result（“错误：未找到订单号 SP-9999”）和错误标志返回到模型。模型可以看到这一点并温和地向用户解释，或者尝试不同的方式。不要吞下错误并返回空结果；模型必须知道出了什么问题。
弱/强车辆描述
弱（不定名词，没有“何时”）：
name: "data", description: "fetches data"# 模型不知道何时以及如何调用；它要么根本不调用，要么调用不正确。
强（网名+when+参数说明）：
name: "musteri_bakiyesi_getir"description: "返回客户的当前帐户余额。当用户要求借记、贷记或余额时调用。不进行付款。"input_schema: {custeri_id: string ("Customer ID")}# 模型在正确的时间、使用正确的参数调用，知道其限制。
三个迷你箱
情况 1 — 不必要的代理。一个团队使用多工具代理构建了“摘要文本”业务；每次回顾需要 4 次模型调用和 9 秒。这项工作实际上是一项一次性工作。当我们删除代理并将其减少为单个调用时，时间减少到 1.5 秒，成本减少到四分之一。教训：在真正必要时使用代理。
案例 2——解释不力，判断错误。在支持代理中，模型在余额问题和运输问题中随机调用了一个名为 fetch 的不起眼的工具。当车辆被分为balance_getir和cargo_durumu_getir并添加“调用时间”解释时，错误的车辆选择从50个例子中的18个减少到1个。
案例 3 — 错误被吞没。未找到订单时，代理返回空结果；该模型将此解释为“订单已交付”并误导了客户。当错误消息显式写入 tool_result（“未找到订单”）时，模型正确地说“我找不到这个号码，你能检查一下吗？”他开始说道。
常见错误
- 将所有事情交给代理：虽然一个电话就足够了，但代理会增加成本和延迟。
- 车辆描述模糊：车型不知道什么时候打电话；选择错误。
- 认为模型驱动车辆：线束驱动车辆；模型只是想要。
- 吞下错误：模型必须知道出了什么问题；将错误作为 open tool_result。
- 相似车辆过多：车型混乱；保持工具集的重点和最小化。
注意：仅仅因为模型说“呼叫该车辆”并不意味着应该采取行动。对于破坏性工具（删除、结帐、电子邮件），您的应用程序不应盲目执行调用 - 这是下一个单元中安全主题的核心。
综上所述
- Agent = 模型（决策）+ 工具（函数）+ 循环（调用工具，得到结果，再次决策）。
- 单个模式调用不是代理；代理是一个循序渐进的过程。
- 该模型不运行车辆；您的应用程序运行（harness）并将结果作为 tool_result 返回。
- 该工具通过名称、描述（特别是“调用时间”）和 input_schema 进行标识。
- 循环继续为 tool_use → 线束运行 → tool_result → 模型继续，直到模型显示“完成”；错误会明确报告给模型。
应用任务
从您自己的业务中设计 3 个可以提供给代理的工具。 (1) 为每个写上名称、描述和“调用时间”，以及 input_schema；至少让一个是非破坏性读取工具，一个是计算工具。 (2) 选择一个现实的用户问题，并手动逐步（在循环中）编写模型将使用哪些输入调用哪些工具以及在 tool_result 到达后它将执行哪些操作。 (3) 设置一个场景，其中一个工具发生故障，并显示错误消息将如何返回到模型。
清单
- [ ] 我可以将代理定义为“模型+工具+循环”并决定何时需要它。
- [ ] 我知道线束驱动车辆，模型只是想要它。
- 我可以使用 [ ] 名称、描述（“调用时间”）和 input_schema 编写可靠的车辆描述。
- 我可以按照 [ ] tool_use → tool_result 循环一步步进行。
- [ ] 我将工具错误报告给模型作为 open tool_result。