代理作为工具

上一页显示了上下文提供程序如何为代理提供内存和动态知识，即每次调用之前主动注入的信息。 此时，你现在有一个 代理，它可以使用工具、加载技能、运行中间件，并利用丰富的上下文。 这是很强大的，但仍然是一个智能体在做所有事情。

当代理的职责超出一组指令可以很好地处理的情况时会发生什么情况？ 当代理累积工具时，工具选择能力会下降 — 模型在几个描述良好的工具中选择要优于在几十个工具中进行排序。 当说明变得宽泛时，焦点减弱 — 一个系统提示试图涵盖旅行预订、费用报告和日历管理，这导致模型要承担太多角色，难以应付。

代理作为工具 来解决此问题，方法是让你编写代理：一个代理（ 外部 代理）可以调用另一个代理（ 内部 代理），就好像它是一个常规函数工具。 每个内部代理都有一个紧密的范围 - 其自己的指令、自己的工具、自己的专业知识。 外部代理决定何时委托和要请求的内容 ， 这与它决定何时调用任何其他工具的方式完全相同。

何时使用此项

在以下情况下使用代理作为工具：

  • 你希望将 专门子任务委托给 重点代理，例如，当用户询问航班时，通用助理会调用专用“旅行预订助手”。
  • 外部代理应根据聊天决定 何时以及是否 涉及内部代理 — 委托是模型驱动的，而不是硬编码的。
  • 无需显式控制代理之间的 执行顺序 - 外部代理可以通过自己的推理来协调事务。

小窍门

每个代理还可以根据其专用化和要求使用不同的模型。 更复杂的代理可能会使用较大的模型进行推理，而更简单的代理可能会使用更小、更快的模型提高效率。

注意事项

注意事项 详细信息
单纯 代理即工具是最轻的多代理模式。 将一个代理转换为工具后，将其交给另一个代理。 当一个代理不够时，这是自然的下一步。
延迟 每个委托都是一次完整的代理调用：外部代理会调用内部代理，内部代理再调用 LLM，而 LLM 可能会调用它自己的工具。 嵌套调用相加。 让内部代理集中精力，以便迅速解决问题。
路由是模型驱动的 外部代理的 LLM 决定何时调用内部代理，就像它决定何时调用任何工具一样。 这意味着路由可能不可预知 - 如果工具说明模糊，模型可能会调用错误的代理或完全跳过它。 明确、具体的说明至关重要。
可见性有限 外部代理看到内部代理的最终文本响应 ， 它看不到内部代理的中间推理、工具调用或上下文。 如果需要对内部代理行为具有可观测性，请使用 跟踪。
上下文隔离 内部代理使用自己的指令和工具运行。 它不会自动继承外部代理的对话历史记录或上下文。 通过工具调用参数与其通信，就像任何其他函数工具一样。

工作原理

代理作为工具建立在你已知道的工具调用循环之上。 唯一的区别是被调用的“function”本身是代理。

┌──────────────────────────────────────────────────────────┐
│  User: "Book me a flight to Paris and file the expense"  │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent reasons about the request                   │
│  → decides to call the travel-booking agent first        │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Inner agent (travel-booking) runs as a tool:            │
│  • receives: "Book a flight to Paris"                    │
│  • uses its own tools (search_flights, book_flight)      │
│  • returns: "Booked Flight AF123, $450"                  │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent receives the tool result                    │
│  → decides to call the expense-filing agent next         │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Inner agent (expense-filing) runs as a tool:            │
│  • receives: "File expense for Flight AF123, $450"       │
│  • uses its own tools (create_expense, attach_receipt)   │
│  • returns: "Expense report filed"                       │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent synthesizes both results:                   │
│  "Done! Booked Flight AF123 to Paris for $450 and filed  │
│   expense report."                                       │
└──────────────────────────────────────────────────────────┘

要点：

  1. 内部代理看起来像一个函数工具。 从外部代理的角度来看，调用内部代理与调用get_weather()或search_database()没有区别。 框架处理将代理转换为具有名称、说明和输入参数的工具。
  2. 内部代理独立运行。 它具有自己的指令、工具和 LLM 调用。 它看不到外部代理的完整对话， 只显示通过工具调用传递的输入。
  3. 外部代理仅看到最终结果。 内部代理的中间步骤（工具调用、推理、重试）对外部代理不可见。 它接收文本响应，就像任何工具结果一样。

后续步骤

现在，可以在单个进程中编写代理，下一步是 代理到代理（A2A）， 使代理能够使用标准协议跨服务和组织边界进行通信。

代理对代理（A2A）

更深入：

  • Last updated on