Agent 框架类型

Agents 类型有 CodeAgents, retrieval agents、tools calling agents、multi-agent systems、vision agents 和 browser agents。

这些多样的 Agents 为我构建动态的、感知上下文的应用提供了多种可能。我的目的是组合多种类型的 Agents 来构建强大的系统。

除了 LLM本身（权重文件）、Agent 框架控制（TAO/RAG控制逻辑）、用户之外，还有一个角色：LLM 提供商（。。。）。

CodeAgents

这是 smolagents 主要 agent 类型。这种 agent 不生成 JSON 而是高级语言像 python 来执行操作。

ToolCallingAgents

是 smolagents 第二种支持的类型，这类 agents 依赖系统解析和解释 JSON 块来执行操作。

过于 Tools，如何创建工具、它们的结构以及使用 Tool 类或 @tool 装饰器进行不同实现方法。还将学习默认工具箱、如何与社区共享工具，以及如何加载社区贡献的工具用于我的代理。

这类 Agents 使用 LLM 提供商的内置API约束来生成 JSON 结构，然后执行工具调用。这是 OpenAI、Anthropic 和许多其他提供商会使用的标准方法。

这里的内置API约束具体指 LLM 提供商在 API 层面对模型输出做了结构化约束和后处理，强制模型以预定义的 JSON Schema 输出工具调用请求。换句话说，JSON 结构仍然是 LLM 生成的，但格式由 API 强制规范，不再是自由文本 <

ToolCallingAgent 通过 System prompt 引导 LLM 输出标准 JSON 工具调用列表。比如，该 Agent 生成 JSON 结构（LLM负责）：

[
    {"name": "web_search", "arguments": "Best catering services in Gotham City"},
    {"name": "web_search", "arguments": "Party theme ideas for superheroes"}
]

JSON array 每一个元素都是一个工具调用说明。然后自动解析并执行这些工具(见下)。

from smolagents import ToolCallingAgent, DuckDuckGoSearchTool, InferenceClientModel
agent = ToolCallingAgent(tools=[DuckDuckGoSearchTool()], model=InferenceClientModel())
agent.run("Search for the best music recommendations for a party at the Wayne's mansion.")

用户只需用自然语言提问。

KAQ：Agent 解析 LLM 输出的 JSON 如何做？

Agent 解析 LLM 输出的 JSON；
对每个 {“name”: “web_search”, “arguments”: “…"}：
- 找到对应的 DuckDuckGoSearchTool 实例；
- 调用 tool.run(arguments)；
- 收集结果（如搜索摘要）。
生成最终回答

为什么必须 import DuckDuckGoSearchTool？LLM 不能直接访问互联网，LLM 生成的 JSON 中的 "name": "web_search" 只是一个“调用指令”，纯文本就像一条TODO，本身没有任何动作。所以需要工具类DuckDuckGoSearchTool 来真正执行动作。这个 DuckDuckGoSearchTool 封装了 duckduckgo 搜索引擎，传入"arguments” 返回搜索结果。

这里的关键是，Agent 会遍历你的 tools 列表找到其中 tool.name == "web_search" 的那个工具实例。DuckDuckGoSearchTool 的 name 属性必须与 JSON 中的 “name” 完全一致，否则匹配不上。

让 LLM 生成结构化的 JSON

response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "What's the weather in Tokyo?"}],
    functions=[  # <- 提前定义工具 JSON schema
        {
            "name": "get_weather",
            "parameters": {"type": "object", "properties": {"location": {"type": "string"}}}
        }
    ]
)

如此之后，LLM 的 response 就是结构化约束的形式，方便后续的 parse：

response.choices[0].message.function_call
#-> { "name": "get_weather", "arguments": '{"location": "Tokyo"}' }

开发者提供的 JSON Schema 是“指令”，而 OpenAI （LLM提供商）负责确保这个指令被正确执行和解析（注入到prompt中）。

AI Agent 系统中不需要推理引擎吗？

有呀，回忆本地部署的 LLM，你在 Agent 中可以使用的 LLM，code 字面上 LLM 只是一个静态权重文件。你有后台运行的 Ollama、llama.cpp 这是推理引擎，负责加载 LLM 权重、处理输入、执行计算、生成输出的底层。

HuggingFace 是模型分发/托管平台, 它本身托管 LLM 模型的权重、配置和 tokenizer。

HuggingFace 的 Transformer 库本身作用推理引擎。

但是在使用 HuggingFace 及其相关的库时，由于HuggingFace Transformer 没有类似 OpenAI Function Calling 的内置约束机制。在构建Agent时，需要自己通过 prompt 工程 来指导 LLM 结构化输出了（使用结构化生成库：OutLines）。

Retrieval Agents

检索代理允许模型访问知识库，使其能够从多个来源搜索、综合和检索信息。这种 agent 实现 Retrieval-Augmented Generation（RAG）模式。这类 agent 特别适用于将网络搜索与自定义知识库集成，同时通过记忆系统保持对话上下文。

Multi-Agent Systems

通过结合具有不同能力的智能体，可以创建更复杂的解决方案。侧重于设计、实现和管理多智能体系统，以最大限度地提高效率和可靠性。

Vision and Browser agents

使用VLM 。考虑如何设计和集成 VLM 驱动的智能体，解锁高级功能，如基于图像的推理、视觉数据分析和多模态交互。我们还将使用视觉智能体构建一个可以浏览网页并从中提取信息的浏览器智能体。

CodeAgents#

ToolCallingAgents#

KAQ：Agent 解析 LLM 输出的 JSON 如何做？#

让 LLM 生成结构化的 JSON#

AI Agent 系统中不需要推理引擎吗？#

Retrieval Agents#

Multi-Agent Systems#

Vision and Browser agents#