构建多智能体系统——LLM Agents 与多智能体系统是什么？

数据智能老司机
58 阅读29分钟

本章内容

  • LLM 智能体与多智能体系统（MAS）的真实落地应用
  • 什么是 LLM 智能体，以及为何“仅有 LLM”并不够
  • 设计 LLM 智能体的重要模式、增强手段与协议
  • 何时应采用多智能体系统
  • 构建 LLM 智能体与多智能体系统的路线图

如果你让一个大语言模型（LLM）回答“在纽约哪里能买到性价比最高的牛角包”，LLM 可能会说：“我将搜索网络上评价高的牛角包及其价格。” LLM 非常擅长表达达成目标的意图——它能生成文字，告诉我们“它打算如何”解决问题。可此时会遇到一个关键限制：LLM 只是文本生成器，无法真正执行这些意图。它能阐述计划，却无法落地——除非有一个系统来编排该计划并驱动动作执行。

这些编排系统就叫作 LLM 智能体（LLM agents） 。稍后我们会更细化定义，但就本书语境而言，LLM 智能体就是把 LLM 的意图自动转化为行动的系统。

LLM 智能体通过对接现代 LLM 的一个关键能力来工作：工具调用（tool-calling） 。所谓工具调用，是指我们可以（以文本方式）向 LLM 提供一组工具及其说明，LLM 便能（以文本形式）生成调用请求，去触发合适的工具来落实其意图。工具的实际执行发生在应用的其它部分，执行结果再回传给 LLM 进行综合与回答。

在为用户办事时，LLM 智能体会大量使用工具调用：它负责确保 LLM 发起的工具调用被执行，并把结果送回 LLM。如果没有智能体，用户就得自己在“LLM ↔ 工具执行”之间来回搬运信息。

就像现实中的工具箱——工具越多，能做的事越多。给 LLM 配上网页搜索、数学计算、代码解释器等工具，它就能胜任多种任务。我们既可以自建工具，也能复用他人提供的工具。**Anthropic 的 MCP（Model Context Protocol）**是一个广泛使用的标准，规定了 LLM 智能体如何访问第三方工具与资源。借助 MCP 可用的众多工具与资源，智能体的能力边界被大幅拓展。

我们也可以把多个 LLM 智能体组合成一个系统来提升任务效果，这类系统称为多智能体系统（MAS） 。在 MAS 中，多个 LLM 智能体协作为用户完成任务。Google 的 Agent2Agent（A2A）协议为智能体间协作提供了标准，使得不同框架构建的智能体也能彼此协同完成任务。

要有效地使用 LLM 智能体与 MAS，并发挥其优势，首先需要深入理解其工作机理。为此，我们将从零开始自建 LLM 智能体与 MAS：搭建完整基础设施，包括与 LLM 的接口、工具、MCP 资源、A2A 互联，并将它们打包成我们自己的智能体框架。

当然，已有不少现成的 LLM 智能体框架可供使用，多数工程师也都会选用。但本书的目标是让你吃透其原理，从而在使用现成框架时更自信高效，或在需要时构建更贴合场景的专用方案。这也是我们从头实现的原因。

1.1 何处适合使用 LLM 智能体与多智能体系统

为了解其广泛用途，我们先看几个真实场景（部分见图 1.1）。

image.png

图 1.1 LLM 智能体的应用非常丰富，包括代理式 RAG、报告生成、深度搜索与电脑操控等，而这些都可通过 MAS 获益。

1.1.1 报告生成

制作报告通常涉及：收集大量信息、综合提炼关键洞见，并将其结构化输出。由于 LLM 善于在大文本中归纳与综合，报告生成已成为 LLM 智能体的热门任务。例如，我们可以让智能体收集各类投资机会的统计数据，并给出每项的风险–机会评估报告。注意：此类报告容易受 LLM 幻觉影响，监控与校验至关重要。

1.1.2 网页搜索与深度研究（Deep Search）

面向一般用户查询的搜索是 LLM 智能体的常见用途。此时的智能体通常内置强化推理的 LLM与网页搜索工具。Perplexity.ai 是采用 LLM 智能体的新型搜索引擎之一，OpenAI 的 ChatGPT 和 Anthropic 的 Claude 也近期加入了联网搜索。

网页搜索的延伸是深度研究（Deep Research） ：它需要多步编排逻辑——深度浏览网页 → 归纳综合 → 生成报告。Google 的 Gemini Deep Research 就采用了包含规划、搜索、推理、汇报的编排流程。其他大型 LLM 提供商也有类似产品。后文我们会用自建的智能体框架实现一个深度研究智能体。

1.1.3 代理式 RAG（Agentic RAG）

LLM 智能体也可作为 RAG（检索增强生成） 系统的一部分，即Agentic RAG。在这类应用中，智能体配备查询知识库的工具，从已构建的知识库（如公司会议纪要、内部文档）中检索上下文来回答员工问题。

1.1.4 编码类 LLM 智能体

LLM/智能体在编程与软件开发中应用尤为广泛，甚至衍生出“vibe coding”——由 LLM/智能体几乎独立完成项目/应用的编码，人工只提供自然语言指令。多个编码智能体也可像人类团队一样，共同维护代码库。在这类应用中，智能体通常配备沙箱代码解释器，以便在安全环境中执行任意代码。

1.1.5 电脑操控（Computer Use）

近期，LLM 智能体被赋予更广的权限与工具，包括控制完整应用（如浏览器）乃至整个操作系统层。有了这类权限，智能体可以像人一样在电脑上点外卖、买演出票等。某种意义上，LLM 智能体可视作下一代 RPA：传统 RPA 基于规则，缺乏灵活适应与推理，而智能体可以。

1.1.6 用 MAS 增强应用

上述所有场景，都能通过 MAS 得到增强：把复杂任务拆解为若干子任务，由专长各异的智能体分别承担。例如在报告生成中，可配置一个擅长处理金融文本的总结/抽取智能体，与另一个擅长结构化成稿的智能体协作；在全栈开发中，一个负责前端、另一个负责后端。原则上，当任务可被高质量地拆分，并且专长型智能体优于通才型智能体时，MAS 的优势最明显。

1.2 什么是 LLM 智能体？

对“智能体”的一个简单定义是：能自主采取行动以完成任务的实体。由于 LLM 只能生成文本、不能行动，本身不能被视为智能体。
如前所述，LLM 可以通过文本表达行动意图：它能生成工具调用请求并制定执行任务的计划。因此，若我们在 LLM 周围构建一个系统，去编排并执行这些由 LLM 生成的工具调用与计划，那么这个系统就可以被视为一个智能体。

定义

LLM 智能体是由“骨干 LLM + 工具”组成的自治系统，它根据骨干 LLM 制定的工具调用请求与计划替用户执行任务。

图 1.2 展示了一个以 Qwen3-7b（即 Qwen3 的 70 亿参数版本）作为骨干 LLM、并装备了 5 个工具的 LLM 智能体。其中有 3 个工具通过 Anthropic 的 MCP 接入，这意味着它们可能由第三方工具提供方创建。

image.png

1.2.1 作为前提的 LLM 能力

按照上述定义，LLM 智能体依赖骨干 LLM 的计划与工具调用请求来完成任务。要想高效，骨干 LLM 必须在综合此前动作结果后，合理选择下一步（包括调用哪一个工具）。能满足这一要求的两项关键能力是：规划（planning）与工具调用（tool calling） 。

规划（Planning）

LLM 智能体通常让骨干 LLM 在任务开始时先生成初始计划。这完全取决于骨干 LLM 的规划能力：一开始就制定了错误计划，可能导致结果错误、执行超时或巨大低效。

继续“在纽约寻找性价比最高的牛角包”的例子，智能体接收原始请求后，可能生成这样的初始计划（当然是以文本产生）：

“我需要找到纽约所有售卖牛角包的面包店，并核对它们的价格和评分。然后基于这些信息做一份分析，得出纽约性价比最高的牛角包。”

这个初始计划通常会开启一个新的子步骤执行，属于更大任务流程的一部分。可以想见，规划不仅发生在开头，也会贯穿整个过程。

一种常见实现是循环式处理：不断产出迈向完成的步骤/动作。我们利用 LLM 的规划能力来综合前序步骤的结果与贡献，并据此调整当前计划。如果之前的路径不佳，智能体就“纠偏”；若判断任务已提前完成，则带着适当的结果提前结束。图 1.3 展示了智能体如何借助 LLM 进行规划。

image.png

规划 vs. 思维链（Chain-of-Thought）与“推理型 LLM”

与“规划”相关的概念是思维链（CoT） ：一种提示工程技巧，促使 LLM 在给出最终答案之外，展示其中间推理与演绎步骤。这类提示常用少样本示例来示范回答格式。
例如，在“77 是素数吗？”的示例中，可给出示范性答案：“77 能被 7 与 11 整除，因此不是素数。”
提示中也常出现如“show your work”“let’s solve this step-by-step”等语句。

近来，一些 LLM 经过额外训练以生成更长的推理链条，被称为推理型 LLM（reasoning LLMs） 。它们常在输出中包含上述长链条文本，并以 <thinking>…</thinking> 这类标签包裹。由于这种后训练，推理型 LLM 的规划能力也可能增强，因此很适合作为智能体的骨干 LLM。

工具调用（Tool Calling）

骨干 LLM 的第二项前提能力是工具调用。前面我们提到，给 LLM 提供工具的文本化描述（功能与参数），即可让 LLM 产生使用该工具的意图。图 1.4 展示了“给智能体装备工具”的过程。

image.png

进一步看整个工具调用流程（图 1.5）：

image.png

当工具已被装备后，任一工具都可以在后续被调用。每次工具调用流程都从 LLM 生成一个工具调用请求开始——这是 LLM 生成的一段结构化文本，包含工具标识以及该工具所需参数的取值。LLM 常用如 JSON 的结构化格式来表达。继续我们“寻找纽约牛角包性价比”的任务，LLM 可能生成如下的网页搜索工具调用请求：

{
  "tool_name": "web-search-tool",  // A
  "parameters": {                  // B
    "query": "Croissant bakeries in New York City and their prices."
  }
}
  • A 工具由 LLM 选择
  • B 参数由 LLM 填充

可见，LLM 的请求同时包含了**“选哪个工具”与“该工具的参数值” 。
随后，系统以这些参数执行工具**，并将结果回传给 LLM，由其综合并生成回应。

如何教会 LLM 进行工具调用

为了让 LLM 具备“工具使用”能力，通常需要进行有监督微调（SFT）等后训练：使用带指令的示例来演示应如何生成工具调用，包括格式约束与何时调用合适。不会生成工具调用请求的 LLM，显然不适合作为智能体的骨干 LLM。

在明确骨干 LLM 的两项前提能力之后，下面我们将看看：智能体如何在其处理循环中，利用这些能力来执行任务。

1.3 处理循环（Processing loop）

LLM 智能体的处理循环就是一切行动发生的地方：这里会制定计划、发起工具调用，并一步步推进任务直至完成。若初始计划失效，还可以在循环中进行调整并最终把任务做好。LLM 的规划与工具调用能力会在处理循环中被反复使用。图 1.6 展示了处理循环以及任务在其中的执行方式。下面一起按照这个心智模型走一遍。

image.png

图 1.6 通过处理循环执行任务的 LLM 智能体心智模型：反复使用工具调用与规划。任务通常以一系列子步骤（sub-steps）的方式推进。

当一个任务被提交给 LLM 智能体执行时，就会启动处理循环。如何在循环内具体执行，属于架构设计选择。在本书的智能体框架中，我们采用“一系列子步骤”的方式推进任务（如图 1.6）。

每个步骤开始时，LLM 智能体都会综合到目前为止的结果与进展，以生成下一步的中间计划或动作。对于任务的第一个步骤，由于还没有任何进展，智能体就直接依据用户请求/任务说明来制定初始计划。在任意步骤中，智能体都可以发起工具调用。

以“在纽约寻找性价比最高的牛角包”为例，假设前文讲到的初始计划与工具调用（在介绍前置 LLM 能力时出现过）就构成了第一个子步骤。该步骤在整个任务执行中的大致轨迹如下：

=== Task Start ===

*** Step Start ***

💬 LLM agent: 我需要找到纽约所有售卖牛角包的面包店，并检查它们的价格与评分。随后基于这些信息做分析，确定纽约性价比最高的牛角包。

💬 LLM agent: 我需要进行如下工具调用：

{
    "tool_name": "web-search-tool",
    "parameters": {
        "query": "Croissant bakeries in New York City and their prices."
    }
}.

💬 tool: 以下是一次工具调用的结果：
{
    "tool_name": "web-search-tool",
    "result": {
        "hits": [
            {
                "name": "Bob’s Bakery",
                "has_croissants": true,
                "price": 3.50,
                "yelp_rating": 4.8
            },
            ...  #A
        ]
    }
}

💬 LLM agent: 搜索成功返回了若干纽约售卖牛角包的面包店，以及它们的价格与评分。  #B

*** Step End ***

…  #C
=== Task End ===
#A  其他搜索结果
#B  LLM 对工具调用结果的综述
#C  其余子步骤

上面的概览是处理循环中的一个重要“产物”，常被称为智能体的轨迹（trajectory / rollout） 。在轨迹中，可以看到任务执行期间每一步的计划与工具调用。智能体轨迹通常不会包含在返回给用户的最终结果里，但若将其记录下来，对于调试与改进智能体非常有价值。第 4 章我们会实现从处理循环中采集轨迹的逻辑。

刚才的示例轨迹只展示了第一步。实际上，步骤会一直推进，直到任务完成，或触达某个预设停止条件（比如最大步数）。轨迹中，下一步可能如下所示：

=== Task Start ===

*** Step Start ***

…  #A

*** Step End ***

*** Step Start ***

💬 LLM agent: 我需要用刚才返回的纽约牛角包价格与评分做一次分析，以找出性价比最高的牛角包。

💬 LLM agent: 我需要进行如下工具调用：

{
    "tool_name": "code-interpreter",
    "parameters": {
        "code": "…",  #B
    }
}

*** Step End ***

…  #C
=== Task End ===
#A  上文展示的第一步
#B  LLM 生成的代码，用价格与评分计算“牛角包性价比”
#C  其余子步骤

如前所述，智能体会先综合前一步的结果来制定本步计划。这里它判断需要对搜索结果进行分析，因此调用代码解释器工具，执行其自行生成的代码，基于价格和评分计算“性价比”。

在随后的步骤中，智能体可能认为代码解释器的结果已经足以完成任务，于是计划在最后一个子步骤中下结论、结束执行：

=== Task Start ===

*** Step Start ***

…  #A

*** Step End ***

*** Step Start ***

…  #B

*** Step End ***

*** Step Start ***

💬 LLM agent: 我已经具备完成任务所需的全部信息。Bob’s Bakery 的“牛角包性价比（price/yelp_rating）”计算值最高，为 0.73，售价 $3.50。

*** Step End ***
=== Task End ===
#A  上文的第一步
#B  上文的第二步

以上两个收尾步骤也对应于图 1.3 中的展示。

说明（NOTE）
LLM 智能体的一个重要特性，是可以回溯与追问它在任务执行中所做的某个动作或计划。最简单的方式是与智能体对话，请它对某一步进行详细说明；查看执行轨迹也是一种方式。推理型 LLM还可以显式展示其“思考过程”。

LLM 智能体 vs. 大动作模型（LAM）智能体

你已经了解了作为 LLM 智能体骨干 LLM 的两项前提能力：规划与工具调用。如果骨干 LLM 缺少这些能力，智能体的准确性与能力都会显著受限。

一种增强思路是：在高度专业的任务域内对 LLM 进行微调，让它在该域里对“行动序列”的规划与工具调用更为准确。例如，把 LLM 后训练为在通用 GUI 操作中擅长生成动作（如“点击开始按钮”）。

与“LLM 智能体由骨干 LLM 组成”类似，LAM 智能体由骨干 LAM（Large Action Model）组成，用于生成将被执行的动作序列。

  • LLM 智能体可视为通用型；
  • LAM 智能体则是高度专用型，聚焦于其骨干 LAM 经过严格训练的特定领域任务。

1.4 关键增强与设计模式

我们对 LLM 智能体的定义并不保证其有效性。一个不能把活儿做好、或效率极低的智能体，基本没用。为提升任务完成的效果与效率，业界为 LLM 智能体发展出一系列特性与模式。其中常见的一项是：让智能体具备记忆（memory） ，能回忆过去任务的执行过程及其工具调用结果，以便用于未来任务。稍后我们会深入讨论记忆模块。我们还将介绍两个重要的设计模式：人类在环（human-in-the-loop）与多智能体系统（MAS） 。

记忆（Memory）

很多场景下，LLM 智能体若能访问以前任务执行的结果（包括子步骤与工具调用），就能更高效。例如，它可以避免重复做曾经做过的工具调用，从而节省时间。

为此，可以为智能体提供记忆模块：用来保存可能有用的信息（如历史轨迹），并在处理未来任务时将其加载回当前的上下文（即：作为输入文本的一部分供模型生成时使用）。见图 1.7。

image.png

图 1.7 带记忆模块的 LLM 智能体：可将任务执行关键信息存入记忆，并在未来任务中加载回上下文。

这些记忆模块会在处理循环中使用；何时加载/保存、保存什么，属于设计选择。图 1.8 展示了一个心智模型：智能体在任务开始时先检查记忆模块，加载对当前任务有帮助的信息；同时将在每个子步骤的结果、工具调用结果与最终任务结果写回记忆。后文实现时你会更直观地理解智能体如何与记忆模块交互。

image.png

图 1.8 带记忆模块的处理循环：在执行过程中保存/加载重要信息。

人类在环（Human-in-the-loop）

“人类在环”设计模式可以降低级联错误的风险——即早期关键步骤的错误会在后续放大。例如，若一开始的分类步骤出错，后续全链条都可能被带偏。

人类还可以被用于审阅并批准智能体制定的计划，再执行。例如在“寻找纽约性价比最高的牛角包”任务中，人类可以在进行网页搜索调用前审阅智能体拟定的查询语句。图 1.9 所示的处理循环可以接入人类操作员；最终结果也可由人类复核。若判定失败，人类可让智能体重试并给出失败原因。

引入人类能显著提升准确性，但也会显著拉长执行时间——每次等待人工输入，循环都要暂停。因此是否采用人类在环，需要权衡可接受错误率与最大执行时长等约束。稍后我们会实现一个变体：每个子步骤都可由人类确认，并调整下一步指令后再继续。

image.png

图 1.9 带人类在环的处理循环：每次需要人类输入时循环会暂停。

1.5 LLM 智能体相关协议

随着 LLM 智能体受到重视，也涌现出一批标准化协议，用于在特定场景下构建智能体。这里介绍两个在生态中很重要的协议。

模型上下文协议（MCP, Model Context Protocol）

如前所述，Anthropic 的 MCP 为将第三方工具与其他资源集成进你的智能体应用提供了标准。MCP 的采用速度与规模前所未有，来自公司、组织与个人开发者的广泛贡献，形成了一个繁荣生态，提供了海量 MCP 兼容工具。除工具外，MCP 也规范了智能体如何访问其他类型的数据资源。

Agent2Agent 协议（A2A）

Google 的 A2A 提供了智能体到智能体通信的标准。与 MCP 类似，A2A 可集成到任意 LLM 智能体框架中。这意味着可以组装由不同框架构建的智能体组成的 MAS（多智能体系统），包括你将在本书中实现的框架。许多从业者预见，未来会有越来越多的智能体间协作来处理现有与新型工作流，因此 A2A 的重要性在上升。

LLM 智能体 vs. 强化学习（RL）智能体

“智能体（Agent）”在 AI 领域里有多重含义，取决于上下文。这也是本书特意使用“LLM 智能体”这个前缀的原因。另一种常见用法来自强化学习（RL） 。两者都强调“具备某种自治性”，但目标和建模方式差异很大：

  • RL 智能体在一个环境中交互：在给定状态下选择动作，并从环境得到奖励。训练目标是学得最优策略，使累计期望奖励最大化。
  • LLM 智能体并不以学习某任务的最优策略为目标；而是复用预训练的 LLM（以“下一个词预测”在通用语料上训练），在文本表示的当前任务进度下，生成将要采取的动作。换言之，我们押注于 LLM “生成连贯文本”的通用能力，把它当作做出正确决策以完成任务的手段。

同样值得一提的是，LLM 本身也可以被视为一种策略（policy），并可能通过强化学习方法进行对齐训练（例如基于人类偏好的奖励信号来微调），以“最大化某种定义的奖励”（如更符合人类偏好的回复）。

1.6 多智能体系统（Multi-Agent Systems, MAS）

就像一个团队里的人各司其职，在 MAS 中，聚焦型的 LLM 智能体可以分别处理整体任务执行的特定部分。图 1.10 展示了两个 LLM 智能体协作完成一个更大任务：各自处理循环（processing loop）的产出被组合，形成该总体任务的结果。

image.png

图 1.10 多个 LLM 智能体协作完成总体任务：把每个智能体处理循环的结果合并为整体输出。

延续前面的牛角包案例，现在把范围扩展为“在纽约市寻找高性价比美食”。先前的 LLM 智能体可能专精于“牛角包子任务”；另一个 LLM 智能体则专注“高性价比披萨”。将两者完成的子任务结果组合起来，便得到总体任务的答案。

需要指出的是：虽然在某些应用上，MAS 的表现优于单智能体系统，但它并非完美无缺。书的后半部分我们将讨论 LLM 智能体与 MAS 的失效模式以及可能的应对方式。

1.7 我们的 LLM 智能体框架

要真正从零构建一个 MAS，我们先从零实现一个单个 LLM 智能体。我们会编写代码，实现自定义的智能体类及其所需的基础设施组件，包括：组成智能体的工具（tools）与LLM的基类；还需要一些辅助的数据结构，如任务（Task） 、工具调用（ToolCall）及其结果。我们把所有代码封装成一个自有框架，后文简称 llm-agents-from-scratch。图 1.11 给出了该框架的高层组织结构。

image.png

图 1.11 我们将共同构建的 llm-agents-from-scratch 框架的首览。

按我们的定义，LLM 智能体会利用其骨干 LLM与可用工具，自主执行任务。正如图 1.11 所示，我们会在框架的一个独立模块里编写工具与 LLM 的基类定义；基于这些定义扩展出来的具体工具实现放在 tools 模块，LLM 实现放在 llms 模块。

后续我们一起实现的LLM 智能体类以及处理循环的逻辑位于 agent 模块；多智能体协同（如 A2A）的协调逻辑也放在该模块。包括 Task、ToolCall 及其结果在内的数据结构集中在 data_structures 模块。

最后，各类支撑性基础设施（如自定义错误与日志工具）也会有各自的模块。

1.8 如何使用本书

本书以动手实践为主。虽然只阅读也能掌握核心概念，但要想对 LLM 智能体有更深入的理解，建议跟着一起编码，把 llm-agents-from-scratch 框架一步步搭起来。

章节安排尽量循序渐进，前文为后文打基础，建议顺序阅读。不过在我们完成核心概念与首个智能体、工具、LLM 的编码后，阅读后续章节时适度跳读也没有问题。

1.8.1 代码

书中的代码清单（listing）属于框架内部代码。每个清单顶部都会说明应保存到的模块与子目录。示例如下：

清单 1.1 框架代码示例

# src/llm_agents_from_scratch/base/llm.py  #A

class BaseLLM:  #B
    …

#A 表示此清单代码应保存的位置；#B 是实际代码。

与之不同，代码片段（snippet）用于演示或示例框架代码的用法，不一定要放入框架内部。示例如下：

from llm_agents_from_scratch.data_structures import Task  #A

task = Task(
    instruction="find the best-value croissants in New York City",
)
print(task)
#A 本片段演示如何使用我们稍后在第 4 章实现的 Task 数据结构

本书代码仓库位于：github.com/nerdai/llm-…，其中包含框架的完整实现。为便于跟随章节代码，推荐使用框架的专用 Python 虚拟环境。该环境由流行的包管理与构建工具 uv 管理依赖与打包。

安装 uv 的命令如下：

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

完整安装说明见官方文档：docs.astral.sh/uv/getting-… 。

安装完成后，在项目根目录执行以下命令同步并启用框架的虚拟环境：

# 同步虚拟环境依赖
uv sync

# 激活（macOS / Linux）
source .venv/bin/activate

# 激活（Windows PowerShell）
.venv\Scripts\activate

该虚拟环境确保你具备运行与实验全书示例代码的所有依赖。

此外，我还为每章准备了专用 Jupyter 笔记本，包含可执行的示例与演示代码，位于仓库的 examples/ 目录。建议使用 uv 启动 Jupyter，以保证依赖正确：

uv run --with jupyter jupyter lab  #A
#A 在项目根目录执行

1.8.2 UML 图基础

为更清晰地表达实现思路，书中会使用贴近 UML 规范的图示。UML 很强大，也可能让人望而生畏。本书仅使用类图与时序图两种，足以支撑我们后续的设计交流；若后续用到其他 UML 元素，会在当处补充说明。

图 1.12 展示了一个简单的 UML 类图。

image.png

图 1.12 一个简单的 UML 类图：展示了框架中的两个类。BaseTool 位于 base 模块，ToolCallResult 位于 data_structures 模块；各自的属性与方法，以及它们之间的关系也在图中标注。

类图用于展示类的结构及相互关系。在该示例中：base 模块中的 BaseTool 类拥有一个字符串类型的 name 属性，并实现了 __call__() 方法；data_structures 模块的 ToolCallResult 类包含 tool_call_id、content、error 三个属性、无方法。两者之间是依赖关系：当 BaseTool 被调用时会产出一个 ToolCallResult。

除了类图，我们还将使用 UML 时序图来帮助理解类之间的交互流程。图 1.13 展示了在一次工具调用中，BaseTool 如何与 ToolCallResult 协作。

image.png

图 1.13 UML 时序图：展示工具调用的流程。LLM 智能体先准备 ToolCall 并调用 BaseTool，工具开始处理，完成后构造 ToolCallResult 并返回给智能体。

在时序图中，参与该流程的实体称为参与者（participant） 。图 1.13 的工具调用流程有三个参与者：LLM 智能体、工具与工具调用结果。虚线竖条表示参与者的生命线（在该流程中的存在时间）。

时序图由**消息（message）**构成；**自消息（self-message）**表示参与者给自己发送消息，通常代表调用自身的方法。阅读顺序自上而下。

图 1.13 的流程如下：

  1. 智能体先给自己发消息：准备一个工具调用；
  2. 智能体向工具发送消息：请求执行该调用；
  3. 工具给自己发消息：开始处理（长方形表示该处理的激活区时段）；
  4. 处理完成后，工具创建一个 ToolCallResult，结果对象完成初始化；
  5. 工具将完成的结果返回给智能体，流程结束。

1.9 我们的路线图（Our roadmap）

我们已经覆盖了从零构建 LLM 智能体、MAS 以及所需基础设施的全部背景知识。作为本章收尾，来看看从零构建 llm-agents-from-scratch 的路线图。图 1.14 展示了我们的构建计划，将分为四个阶段完成。

image.png

图 1.14 我们的 llm-agents-from-scratch 框架构建计划：四个阶段。第 1 阶段实现工具与 LLM 的接口以及 LLM 智能体类；第 2 阶段让智能体兼容 MCP，以便为骨干 LLM 装载 MCP 工具；第 3 阶段实现“人类在环”和记忆模块；第 4 阶段加入 A2A 与多智能体协同逻辑以支持 MAS。

在阶段 1，我们将编写从零实现 LLM 智能体所必需的全部代码。

  • 第 2 章：在 BaseTool 类中定义工具接口，并实现若干子类，把 Python 函数封装为可供 LLM/智能体使用的“工具”。
  • 第 3 章：通过 BaseLLM 类定义框架中 LLM 的实现接口；同时实现 OllamaLLM（BaseLLM 的子类），使框架能使用 Ollama 支持的任意开源 LLM（本地运行）。
  • 第 4 章（最关键）：定义 LLMAgent 类，并实现我们自己的编排逻辑（processing loop）来执行任务。
  • 第 5 章：以“反复调用工具生成指定数字的冰雹序列（Hailstone sequence）”为任务，创建第一个 LLM 智能体；同时介绍贯穿全书的智能体评测通用方法。

在阶段 2，在打好基础后，我们将为智能体加入能力：为骨干 LLM装载由 MCP 服务器提供支持的工具。也就是说，阶段 2 会让框架 MCP-ready。秉承“从零构建”的主题，我们不仅让智能体能使用 MCP 工具，还会从零实现一个 MCP 工具（服务器） ，更深入掌握该关键协议。本阶段压轴任务在第 7 章：基于若干 MCP 服务器，用我们的框架实现一个深度搜索 LLM 智能体。

在阶段 3，进一步增强智能体：加入记忆模块并实现人类在环。

  • 第 8 章：简化在人类在环模式下的实现。
  • 第 9 章：为智能体加入记忆能力，例如从记忆中回忆长耗时工具调用的结果，以提升处理效率。
  • 第 10 章：回到“深度研究”智能体，展示这些增强带来的潜在收益。

所有铺垫指向第四、也是最后阶段：从零构建 MAS。

  • 第 11 章：加入 A2A 支持和其他多智能体协同逻辑，使框架能构建 MAS。最终项目是把多个 LLM 智能体组合起来生成财务报告：其中一个负责检索/深搜，另一个负责综合信息并产出最终报告。

希望你已整装待发，一起踏上从零构建 LLM 智能体与 MAS 的精彩旅程！

1.10 小结（Summary）

  • LLM 已成为强大的文本生成器，适用于摘要、问答、文本分类等任务，但无法执行动作；它们只能以文本形式表达行动意图（如工具调用）。这正是 LLM 智能体的价值所在：让意图得以真正执行。
  • LLM 智能体应用广泛：报告生成、深度研究、电脑/网页操作、代码生成等。
  • 在 MAS 中，多个 LLM 智能体协作完成任务；当任务可拆解为子任务且专长智能体优于通用智能体时，MAS 通常更有优势。
  • LLM 智能体 = LLM + 工具，能自主代表用户执行任务。
  • 智能体通过处理循环（processing loop）来执行任务；工具调用与规划是该循环的关键能力。
  • MCP 与 A2A 等协议推动了智能体生态的发展：MCP（Anthropic）让智能体可使用第三方工具；A2A（Google）规范了 MAS 中的智能体间交互。
  • 构建 LLM 智能体需要基础设施：LLM 接口、工具接口、任务/数据结构等。
  • 我们将把 LLM 智能体、MAS 以及所需基础设施从零实现为一个 Python 框架：llm-agents-from-scratch。
avatar
文章
阅读
粉丝