预测未来最好的方式，就是去创造它。
—— Alan Kay，计算机科学家
虽然语言模型为理解用户目标提供了推理基底，但真正让智能体能够执行任务并影响现实世界的，是工具的使用。本章将建立理解智能体如何通过三种递进模式，将推理转化为行动的架构基础：
我们首先介绍一种基础模式：单个智能体通过调用外部函数并管理执行结果来扩展自身能力，也就是工具使用型智能体。随后，我们考察能够协调多个专门智能体，并通过任务分解和并行执行解决复杂、多面向问题的架构，也就是 chain-of-agents orchestrators，智能体链编排器。最后，我们探索如何实现持久、有状态的业务流程，并在关键决策点纳入人工监督，也就是 agentic workflow systems，智能体工作流系统。
除了这些模式之外，本章还包括一些贯穿性内容，涉及适用于三者的设计考量、安全性和评估。
工具调用代表着连接认知操作与具体行动的基础机制，它将智能体从简单对话者转变为功能性系统组件。架构挑战在于创建这样的系统：工具调用不再是脆弱的集成点，而是智能体认知的无缝延伸。
本章提出的原则代表了设计生产就绪智能体系统所需的实践知识，这些系统能够交付可衡量的业务价值。我们将探索支持可靠工具使用的通用模式，无论工具是一个简单计算器，还是一个复杂的地理空间分析库。这些模式为更高级的多智能体编排器和工作流系统提供必要基础，而后者是构建复杂 AI 应用的关键。
本章将覆盖以下主题：
- 行动中的智能体：工具调用模式
- 工具发现与选择算法
- 工具集成中的错误处理
- Chain-of-Agents 编排器
- 记忆增强型多智能体系统
- 冲突解决机制
- 智能体工作流系统
行动中的智能体：工具调用模式
能够在恰当时刻选择、适配和编排合适工具，长期以来都被认为是智慧的标志。工匠并不由其拥有多少工具定义，而是由其选择和使用工具的判断力定义。智能体也是如此：衡量智能体的，不只是底层模型的复杂度，还包括它通过有效工具使用，将推理延伸为有目的行动的能力。
工具调用是智能体将认知操作转化为具体结果的基础机制。语言模型为理解目标和制定策略提供推理基底，但工具让智能体能够执行影响现实世界的任务。架构挑战在于确保这一过程不是脆弱的集成点，而是智能体认知的无缝延伸。
本节探索支持可靠工具调用的设计模式。我们将考察三个核心问题：智能体如何决定调用哪些工具，如何构造输入并管理执行结果，以及如何在整体智能体循环中从失败中恢复。这些原则普遍适用，无论工具是简单计算器，还是高级地理空间分析引擎。
即便在引入多智能体编排器之前，一个设计良好、工具箱聚焦的单个智能体，也能交付可观业务价值。通过将自然语言理解与领域特定 API 结合，这类智能体可以自动化过去需要人工脚本或专门专业知识才能完成的任务。这些单智能体模式，构成了本章后续更高级编排器和工作流系统的架构基础。
工具使用型智能体模式
工具使用型智能体，是一种基于语言模型的系统，它通过调用一组预定义外部函数，也就是工具，来扩展自身核心推理能力。这一模式捕捉了 AI 智能体能够采取具体行动，而不只是生成文本的最简单形式。工具使用型智能体架构使智能体能够超越纯语言处理，执行访问实时数据、完成复杂计算，或与外部系统交互等专门任务。整个过程遵循经典的 Think, Plan, Act 循环：智能体首先解释用户目标（Think），然后制定一组工具调用以实现该目标（Plan），最后执行该计划（Act）。
一个稳健的工具使用型智能体架构，由四个主要组件组成，它们协同工作，将自然语言请求转化为具体结果。这种设计将决策逻辑与执行机制清晰分离，从而提升模块化和韧性。
推理核心
这是智能体的“大脑”，负责循环中的 Think 和 Plan 阶段。它解析用户意图，并制定达成目标的逐步计划。
工具注册表
为了制定有效计划，推理核心会查询工具注册表。工具注册表相当于智能体可用工具和能力目录。注册表为每个工具维护关键元数据，包括名称、描述和输入/输出 schema。这些 schema 是显式、可靠的契约，使智能体确切知道应该提供哪些参数，以及预期会收到什么回应。
执行引擎
这个组件是负责 Act 阶段的“工头”。它从推理核心接收执行计划，并管理对实际工具的调用。其职责包括在步骤之间管理状态、处理重试，并传播错误，以确保计划可靠执行。
工具箱
这是智能体可以执行的函数集合。智能体的有效性与其工具质量直接相关。设计良好的工具箱应包含模块化函数，每个函数具有单一且清晰定义的职责。这个原则可以简化系统的构建、测试和长期扩展。每个函数还应包装自身安全逻辑，例如超时和异常处理，以确保其行为可预测。
这种解耦架构为智能体开发提供了有韧性的基础。注册表中的显式契约和执行引擎中的稳健错误处理，使同一结构既能支持对单个函数的简单反应式调用，也能支持链式调用多个工具来解决复杂问题的审议式计划。
图 7.1 展示了工具使用型智能体如何将自然语言查询转化为具体输出：
图 7.1——工具使用型智能体的内部架构
用户请求如 “Show chart” 会被推理核心处理，推理核心解析意图并制定计划。它会查询工具注册表，其中每个工具都通过元数据描述，例如名称、用途、输入/输出 schema 和运行状态。这种显式契约支持精确规划。
推理核心随后将计划传给执行引擎，执行引擎负责管理状态、重试和错误处理。随后，引擎调用工具箱中存储的函数。每个函数都被包装了保护措施，例如超时、异常处理和输入验证。在我们的贯穿示例中，工具箱可能包含四个可组合函数：
load_csv：用于数据摄取aggregate：用于摘要汇总plot_chart：用于可视化validate：用于输出验证
中间结果会流经这些函数，直到生成最终可视化结果。
这种架构清晰分离了决策逻辑与执行逻辑。显式 schema 使接口可预测，而安全包装提供韧性。同一结构既支持反应式查询，也就是意图到单个工具的直接映射，也支持将多个工具串联成序列的审议式计划。
综合来看，这些组件展示了工具使用型智能体的核心模式：一个负责规划的推理核心，一个暴露工具目录的注册表，一个管理调用和失败的执行引擎，以及一个真正执行工作的受保护工具箱。在本章剩余部分，我们将基于这个基础，从单个工具使用型智能体转向 chain-of-agents orchestrators，在那里，多个专门智能体将协作解决更复杂的任务。
函数调用架构模式
在智能体系统中调用工具，不只是发起一次函数调用。智能体必须推理选择哪个工具，提供有效参数，预判错误，并在执行不如预期时作出适当回应。设计工具调用层，需要在灵活性、模块化和可观测性之间取得平衡：灵活性用于支持不断增长的工具集，模块化用于保持函数可组合且独立，可观测性用于监控和调试执行过程。
以下是有效设计中的几种反复出现的模式：
接口 schema 作为契约：每个工具都注册精确的输入—输出签名，通常通过 JSON schema 或 Pydantic 等类型化模型表达。这些 schema 充当推理核心与执行层之间的契约，确保参数和返回值可预测。
决策与执行分离：推理组件决定调用什么以及何时调用，而执行层负责真正调用。这种分离提升可追踪性，并使两层可以独立演进。
反应式调用与审议式调用：在反应式模式中，用户请求会直接映射到一个工具。例如，“Generate a bar chart of sales by region” 可能立即触发绘图函数。在审议式模式中，智能体会先制定计划：加载数据、过滤、聚合，然后可视化，并在每一步执行工具。
安全包装与 fallback 逻辑：工具调用本质上存在不确定性。稳健系统会用重试逻辑、超时和异常处理包装每次调用。fallback 策略支持优雅降级，例如饼图函数失败时改用柱状图。
通过元数据动态发现：工具会发布元数据，包括描述、输入/输出类型和运行状态。智能体可以在运行时使用这些元数据发现并排序工具，从而适应不断变化的工具集，而不需要手动重新配置。
这些模式共同构成有韧性的智能体架构骨架。它们使推理组件保持模型无关，而执行层则强化严谨性、安全性和透明性。随着智能体范围和工具复杂度扩大，这些模式对于维持可靠性至关重要。
为了让这些函数调用模式更具体，我们现在来看一个前文数据可视化智能体的小型实现。下一个示例展示接口 schema、安全包装和执行层如何直接映射到工具箱中的 Python 函数。
实现示例
下面的 Python 代码展示了一个简单但有效的工具箱，用于本节前面介绍的数据分析助手，重点是其数据可视化能力。每个函数都代表一个独立工具，遵循单一职责原则。请注意，Python 类型提示，例如 file_path: str、df: pd.DataFrame，就是前文讨论的 schema contract 的实现。它们提供可靠接口，使智能体推理核心能够构造有效调用。
import pandas as pd
# Tool 1: Handles data ingestion
def load_csv(file_path: str) -> pd.DataFrame | None:
"""Loads data from a specified CSV file into a pandas DataFrame."""
try:
df = pd.read_csv(file_path)
print(f"[load_csv] Loaded {len(df)} rows from '{file_path}'.")
return df
except FileNotFoundError:
print(f"[load_csv] Error: File '{file_path}' not found.")
return None
# Tool 2: Performs data transformation and summarization
def group_by_and_aggregate(
df: pd.DataFrame,
group_by_col: str,
agg_col: str,
agg_func: str
) -> pd.DataFrame | None:
"""Groups the DataFrame and applies an aggregation function."""
if group_by_col not in df.columns or agg_col not in df.columns:
print(f"[group_by] Error: Column not found in DataFrame.")
return None
func = {"sum": "sum", "mean": "mean", "count": "count"}.get(agg_func, "sum")
result = df.groupby(group_by_col)[agg_col].agg(func).reset_index()
print(f"[group_by] Grouped '{agg_col}' by '{group_by_col}' using '{func}'.")
return result
# Tool 3: Handles final rendering for a bar chart
def plot_bar_chart(
df: pd.DataFrame,
x_col: str,
y_col: str,
title: str,
output_path: str
):
"""Generates and saves a bar chart from the data."""
fig, ax = plt.subplots()
ax.bar(df[x_col].astype(str), df[y_col])
ax.set_xlabel(x_col); ax.set_ylabel(y_col); ax.set_title(title)
fig.tight_layout(); fig.savefig(output_path); plt.close(fig)
print(f"[plot_bar_chart] Saved chart to '{output_path}'.")
# Tool 4: Handles final rendering for a line chart
def plot_line_chart(
df: pd.DataFrame,
x_col: str,
y_col: str,
title: str,
output_path: str
):
"""Generates and saves a line chart from the data."""
fig, ax = plt.subplots()
ax.plot(df[x_col].astype(str), df[y_col], marker="o")
ax.set_xlabel(x_col); ax.set_ylabel(y_col); ax.set_title(title)
fig.tight_layout(); fig.savefig(output_path); plt.close(fig)
print(f"[plot_line_chart] Saved chart to '{output_path}'.")
这四个工具将可视化管线拆分为清晰、可测试步骤。load_csv 函数负责数据摄取，从磁盘读取 CSV 文件并返回 pandas.DataFrame，供下游工具使用。group_by_and_aggregate 函数通过按指定列分组，并应用 sum 或 mean 等聚合操作来完成数据摘要。随后，plot_bar_chart 函数将聚合数据渲染为柱状图，并将图像写入指定 output_path；plot_line_chart 则生成对应折线图。通过让每个工具承担单一职责，这种模块化设计使智能体能够组合不同可视化方式，也让新增绘图工具变得直接，而不需要修改智能体核心逻辑。
工具发现与选择算法
随着智能体工具箱不断扩大，它会开始像一个庞大图书馆；价值不只在于藏书本身，而在于能否在正确时刻找到正确的书。一个拥有一百个工具的强大智能体，如果无法为给定任务可靠选择正确工具，就是无效的。这个选择过程，是智能体循环中 Think 组件的核心。设计一种稳健方法来导航这个“能力图书馆”，是一个关键架构挑战，尤其当可用工具数量扩展到几十个或几百个时。
为解决这一问题，我们可以设计一个多阶段过滤流程，如图 7.2 中的选择漏斗所示。该方法通过逐步缩小候选范围，将大型工具注册表高效转化为一个经过验证且可执行的选择。
选择漏斗
我们将考察这个漏斗的三个主要阶段：广泛意图分类、通过语义搜索进行候选排序，以及使用约束过滤进行最终验证。
图 7.2——工具选择
如前所述，该过程包含三个主要阶段：
意图分类（广泛过滤） ：流程从一个高层、粗粒度过滤器开始。智能体首先对用户意图进行分类，以识别相关工具类别，立即缩小搜索空间。例如，请求 “chart sales data” 会快速排除文件操作或数据库管理相关工具。
语义搜索（候选排序） ：接着，智能体对剩余候选工具执行细粒度相似度搜索。为此，用户请求和工具元数据，例如描述和参数名称，都会被转换为数值向量表示，也就是 embeddings。随后，智能体计算请求与每个工具之间的语义距离，按相似度排序，并丢弃低于配置置信度阈值的工具，例如 0.7。
约束过滤（最终验证） ：从最终候选短名单中，智能体应用一系列确定性检查。这是最后的安全性和合理性检查，基于输入类型、用户权限，甚至工具历史失败状态等规则，剪除不兼容选择。最终结果是一个准备执行的可行工具。
这种多阶段漏斗提供了一种在效率与安全之间平衡的稳健策略。初始分类缩小搜索空间，语义搜索识别最有希望的选项，最终约束检查维持系统可信度。对于需要一系列动作的复杂任务，该漏斗可以在计划的每一步被调用；如果选中工具失败或返回低置信度结果，动态重排序过程可以重新启动漏斗。
选择策略
选择漏斗为缩小工具候选提供概念模型，但架构师可以使用几种不同策略实现每个阶段。最佳选择取决于智能体复杂度、所管理工具数量，以及所需灵活性水平。一个简单、单用途智能体可能依赖一种技术，而复杂智能体可能组合多种策略，以在速度、准确性和安全性之间取得平衡。下面回顾一些技术。
意图分类或模板匹配
这是最直接的方法，通过预定义规则或简单分类模型，将用户查询映射到具体工具。它最适合用户意图可预测的受限领域。
用例：考虑一个电商网站客服聊天机器人。基于规则的解析器可以将关键词直接映射到工具：包含 “track my order” 的查询调用 get_order_status 工具，而 “return an item” 则调用 start_return_process 工具。这种方法对已知意图速度快且高度可靠，但扩展性差，也无法处理模糊或新颖请求。
基于 embedding 的相似度搜索
这种灵活方法依赖语义意义而不是关键词。用户请求和工具元数据，包括名称、描述和参数，都会被转换为数值向量表示，即 embeddings。系统随后筛选出 embedding 与用户查询 embedding 在语义上最接近的工具。
用例：在我们的数据可视化智能体中，用户可能问：“What was the trend of our ad clicks over time?” 这里没有直接匹配某个函数的关键词。然而，embedding 搜索会发现该查询与 plot_line_chart 工具描述之间存在强语义相似性，从而使智能体正确选择它。
基于约束的过滤
这种策略更多是关键安全和验证层，而不是主要选择方法。初始候选集合被筛选出来后，通常通过相似度搜索得到，然后应用过滤器剪除任何不兼容或不安全的选项。
用例：当管理云基础设施的智能体接收到清理未使用测试资源的指令时，相似度搜索可能会识别 delete_vm_instance 工具为可能匹配。在执行之前，约束过滤器会检查智能体是否有足够权限。如果智能体只有只读权限，过滤器会自动从候选工具集中移除 delete_vm_instance，防止误删关键资源。
计划驱动的工具分配
对于多步骤任务，智能体可能先生成计划，然后为每一步顺序选择工具。这使一个工具的结果能够影响下一工具的选择或执行。
用例：旅行智能体被要求 “plan a trip to Lahore”。推理核心首先生成高层计划：[1. find_flights, 2. find_hotels, 3. create_itinerary]。find_flights 工具首先被选择并执行。其输出，也就是确认的航班日期，随后成为下一步 find_hotels 工具的关键输入参数。
带反馈的动态重排序
这种策略赋予智能体在出错时适应的能力。如果选中工具失败，或返回低置信度结果，智能体可以评估该反馈，并重新运行选择流程以寻找替代工具。
用例：金融智能体使用 fetch_stock_price_from_api_X 工具获取市场数据，但该 API 超时。智能体不会中止整个任务，而是记录失败，临时增加一个约束以避免再次使用该工具，并重新进入选择漏斗。随后，它发现并执行 fallback 工具 fetch_stock_price_from_api_Y，从而成功完成用户请求。
为了将这些想法落地，我们现在来看数据分析助手如何实现工具选择的第一步：解释用户请求并映射到结构化意图。下面的示例展示一个简单基于模板的分类器如何将自然语言转换为驱动前文选择漏斗的参数。
实现示例：通过模板匹配进行意图分类
任何智能体推理过程中的第一步，都是将含糊的人类语言转换为结构化、机器可读格式。在我们的数据可视化智能体中，parse_query 函数负责这一关键角色。它充当轻量且高效的意图分类器，实现了前文讨论的模板匹配策略。
该函数并不试图理解查询的全部语义细微差别，而是扫描特定关键词和模式，提取可视化所需的核心参数：一个指标、一个维度，以及期望图表类型。这种方法快速且可预测，因此对于运行在定义良好领域中的智能体来说，是一种务实选择。
def parse_query(query: str) -> dict | None:
"""
A simple natural language parser to extract intent from the user's query.
Uses keyword matching to identify the metric, dimension, and chart type.
"""
query = query.lower() # Normalize the query for case-insensitive matching
# --- Step 1: Identify the metric ---
# A simple lookup to map known metric keywords to their column names
metric_map = {'spend': 'spend', 'conversions': 'conversions', 'clicks': 'clicks'}
metric = next((metric_map[key] for key in metric_map if key in query), None)
# --- Step 2: Identify the dimension and chart type ---
# Use keywords to infer how the user wants to group the data and visualize it
dimension, chart_type = (None, None)
if "by campaign" in query or "which campaign" in query:
dimension, chart_type = 'campaign_name', 'bar'
elif "over time" in query or "trend" in query:
dimension, chart_type = 'date', 'line'
# --- Step 3: Validate and return the structured intent ---
# If any of the essential components are missing, the intent is invalid
if not all([metric, dimension, chart_type]):
return None
return {'metric': metric, 'dimension': dimension, 'chart_type': chart_type}
这个函数充当智能体的意图解析器。对于 “What was the trend of clicks over time?” 这样的查询，它会识别出 “clicks” 是指标，“over time” 表示维度为 date，而 “line” 是合适图表类型。这个结构化输出会传递给编排器，用于形成计划。
结果是一条有纪律的路径：从普通英文请求，到系统可以可靠执行的精确、安全工具调用。
有了意图分类，智能体就能可靠地将自然语言请求转换为结构化计划和具体工具调用。然而，即使选择了完全正确的工具，它也可能在运行时因网络问题、格式错误输入或下游服务中断而失败。要构建生产就绪智能体，我们必须把工具集成中的错误处理视为一等架构关注点。
工具集成中的错误处理
在任何依赖外部组件的系统中，失败不是可能性，而是必然性。网络连接会中断，API 会变化，输入会格式错误，服务会下线。设计一个没有稳健错误处理策略的智能体，就像在薄弱地基上建摩天大楼，注定会倒塌。目标不是防止每一种可以想象的失败，而是构建一个有韧性的系统，使其能够在错误发生时预判、吸收并优雅恢复。
常见故障模式
预判失败始于识别最常见来源，然后为每一种来源设计针对性缓解策略。本小节将首先把工具相关失败分为四类，后续再将这些类别映射到具体验证门、重试与超时、fallback 工具和人工审查等策略：
输入验证错误：当提供给工具的数据不符合其预期 schema 时发生。例如，智能体可能将一个不存在的列名传给 group_by_and_aggregate 函数。
运行时失败：这些是在工具执行期间发生的意外错误，例如网络超时、外部 API 错误或文件系统 I/O 异常。一个常见例子是，load_csv 工具因为目标文件被另一个进程锁定而失败。
语义错配：这是一类微妙但关键的失败模式，即工具执行成功，但结果并不符合用户意图。例如，用户要求 “top campaigns by spend”，智能体生成的图表正确按 campaign 分组，但按字母顺序而不是按 spend 指标排序，导致输出无用。
工具不可用：工具可能因其依赖的外部服务下线或被废弃而临时或永久不可用。
预判这些失败是第一步；下一步是设计能够从这些失败中恢复的架构。
架构恢复策略
生产就绪智能体使用以下多种策略实现分层防御：
安全调用包装器：这是第一道防线。每个工具调用都应被包含在包装函数中，该函数类似专门的 try/except 块。这个包装器负责捕获已知异常，实现有针对性的重试逻辑，例如针对网络错误使用指数退避，并记录结果以支持可观测性。
Fallback 工具链：当主工具失败时，系统应该能够调用次级替代工具来完成同一目标。例如，如果 fetch_stock_data_from_api_A 工具因服务中断失败，智能体可以自动尝试使用 fetch_stock_data_from_api_B 执行相同请求。
基于置信度的切换：当工具返回有效结果，但智能体对其正确性置信度较低时，智能体可以丢弃结果，并在置信分数低于预定义阈值时，使用可能更合适的不同工具重试任务。这在涉及 LLM 的任务中很常见，例如如果初始摘要缺乏连贯性，智能体可能切换到更强大的模型。
失败记忆：为了防止智能体反复尝试使用明显失败的工具，系统可以实现短期失败记忆。它类似断路器。如果某个工具在短时间窗口内多次失败，智能体会临时将其标记为不可用，并在预定义时间内不再尝试选择它，从而避免浪费循环。
升级路径：当自动恢复策略耗尽时，最终 fallback 是将任务升级给人工操作员。设计良好的升级路径会暂停工作流，并向人工审阅者展示问题的完整上下文，包括初始输入、已经尝试过的工具，以及遇到的具体错误。
全面日志与遥测：你无法修复看不见的问题。每个行动、错误和恢复尝试都必须被记录。详细日志和指标不仅用于调试，也提供数据，用于分析系统性弱点、识别不可靠工具，并持续提升智能体整体韧性。
为了在上下文中理解这些可靠性模式，我们现在回到数据分析助手，查看其端到端控制流。下面的实现将意图解析、工具选择，以及刚刚讨论的错误处理策略整合进一个 data_viz_agent 函数。
实现示例
现在，我们将这些概念串联起来。下面的 data_viz_agent 函数是数据分析助手的中央编排器。这个函数实现了前面介绍的完整 Think, Plan, Act 循环。它首先调用 parse_query 来解释用户目标（Think）。基于结构化意图，它动态构造一份工具调用列表作为计划（Plan）。最后，它遍历该计划并顺序执行每个工具，在数据从一个步骤传递到下一步骤时管理 data_state，最终生成结果（Act）。
def data_viz_agent(query: str, file_path: str):
# 1. THINK: Interpret the user's goal.
intent = parse_query(query)
if not intent:
print("AGENT-ERROR: Could not understand the request...")
return
print(f"Agent Intent Analysis: Metric: {intent['metric']}, "
f"Dimension: {intent['dimension']}, Chart: {intent['chart_type']}")
# 2. PLAN: Create a sequence of tool calls based on the intent.
plan = [
('load_csv', [file_path]),
('group_by_and_aggregate', [intent['dimension'], intent['metric'], 'sum']),
]
if intent['chart_type'] == 'bar':
plot_tool = 'plot_bar_chart'
base_title = f"{intent['metric']} by {intent['dimension']}"
else:
plot_tool = 'plot_line_chart'
base_title = f"{intent['metric']} over {intent['dimension']}"
full_output_path = f"output_{intent['metric']}_{intent['dimension']}.png"
plan.append((plot_tool, [intent['dimension'], intent['metric'],
base_title, full_output_path]))
print("Agent Action Plan:")
for step, _ in plan:
print(f" - Step: {step}")
# 3. ACT: Execute the plan step-by-step.
data_state = None
tool_functions = {
'load_csv': load_csv,
'group_by_and_aggregate': group_by_and_aggregate,
'plot_bar_chart': plot_bar_chart,
'plot_line_chart': plot_line_chart
}
for tool_name, args in plan:
tool_func = tool_functions[tool_name]
current_args = [data_state] + args if tool_name != 'load_csv' else args
result = tool_func(*current_args)
if isinstance(result, pd.DataFrame):
data_state = result
elif data_state is None and tool_name != 'load_csv':
print("Error: Execution failed at a critical step. Aborting plan.")
return
这个编排器创建一个基础计划，用于加载和聚合数据，然后基于意图动态追加正确绘图工具。在执行期间，data_state 变量会以 pandas DataFrame 形式保存数据，并将其传递给后续工具。这种状态传递模式，是创建连贯、多步骤智能体流程的基础。
在可视化智能体中，如果用户请求不支持的图表类型，系统会优雅 fallback 或请求澄清。它也会记录失败尝试以供分析。
数据分析助手展示了单个工具使用型智能体能够走多远。它可以解析意图、选择工具、管理状态并从失败中恢复，所有这些都发生在一个连贯循环内。然而，许多真实问题超出了单个智能体的能力范围：它们涉及异构数据源、专门推理技能，以及受益于责任拆分的长时间运行工作流。为了处理这些场景，我们转向 chain-of-agents orchestrators，也就是由多个专门智能体在协调策略下协作的智能体链编排器。
Chain-of-Agents 编排器
人类活动中的智慧很少来自单一视角。它往往来自多元头脑贡献互补技能：科学家跨学科合作，音乐家在乐团中和声，工程师跨领域对齐。每个参与者都带来专门知识，而真正价值在于编排如何将个体贡献转化为连贯整体。
同样，人工智能中的复杂任务往往超出任何单个智能体的能力。chain-of-agents orchestrator 提供了一种架构模式，使系统能够从个体工具使用扩展到集体问题解决。在这一模型中，manager agent 协调一个专家团队，每个专家都有自身领域专业能力和工具箱。这种方法允许我们通过拆解问题，并将每个子任务分配给最适合处理它的智能体，来解决多面向问题。
无论是人类协作还是人工智能协作，有效协作都不是偶然发生的。它需要一个清晰框架，用于定义个体如何互动、共享信息并朝共同目标工作。在多智能体系统中，这个框架称为 cooperation protocol，也就是协作协议。该协议是一组规则和架构组件，使智能体团队能够作为有纪律、有目的的整体运行，而不是一堆彼此脱节的部分。
一个稳健的协作协议建立在四个关键架构支柱之上：
明确定义的角色和能力：团队中的每个智能体都被分配独特目的，并获得完成该角色所需的具体工具访问权。就像电影剧组有导演、摄影师和声音剪辑师一样，智能体团队也有 PlannerAgent、DataFetcherAgent 和 ValidatorAgent 等专家。这种专业化确保复杂任务的每一部分都由专家处理。
共同通信基础设施：智能体需要可靠渠道交换结构化消息，例如指令、结果和状态更新。这可以通过远程过程调用（RPC）、专用消息队列或共享记忆存储等多种技术实现。该基础设施就像团队的“对讲机”系统，确保信息在智能体之间可靠传递。
共享上下文或记忆：为了在任务从一个智能体交接给另一个智能体时保持连续性，团队需要一个共享工作区或知识库。这个共享记忆就像电影中唯一权威剧本；它确保每个智能体都基于同一组事实工作，并确保 SummarizerAgent 能访问 DataFetcherAgent 收集到的上下文。
执行编排：supervisor 或 manager agent 负责整体工作流编排。这个智能体将任务委派给合适专家，管理任务之间的依赖关系，例如确保先获取数据再进行总结，并监控整个操作进展。manager 就像片场导演，确保项目保持正轨，并让所有部分正确组合起来。
经过周密设计后，这四个元素构成有效多智能体系统的骨架，将一组个体专家转化为一个连贯、智能团队。
上面四个支柱会通过协作协议具体表达：一个团队中每个智能体都必须遵守的最小 schema。表 7.1 总结了一个结构良好协议必须定义的四个元素。
| Protocol element | Definition |
|---|---|
| Message format | 共享消息信封结构，例如包含 sender、recipient、task_id、payload 的 JSON，每个智能体都读写该结构 |
| Role declaration | 每个智能体向 manager 注册自身名称、能力和可接受任务类型，使委派决策不含歧义 |
| Task delegation scheme | 类型化请求对象，指定目标智能体、请求动作、所需输入和预期输出 schema |
| Status signaling | 标准化状态字段，例如 pending、running、done、error，manager 会轮询这些状态以正确排序下游任务 |
表 7.1——智能体通信协议的核心元素
这些协议元素与新兴行业标准对齐。第 6 章介绍的 Model Context Protocol（MCP）和 Agent-to-Agent（A2A）协议，正是将这种消息 schema 和角色声明层形式化为开放、可互操作规范。第 6 章讨论了它们的结构和协商机制，而本章则应用这些基础：上面描述的协作协议，是 MCP 和 A2A 在线路级标准化内容的实践表达。
在这四个支柱中，共享上下文或记忆也许是实现真正协作最关键的部分。一支由聪明专家组成但不能记住先前对话或共享笔记的团队，会极其低效。因此，我们现在必须从一般概念出发，探索使这种共享记忆成为可能的具体架构。
记忆增强型多智能体系统
一支无法记住先前对话或共享笔记的聪明专家团队，会极其低效。它们会陷入重复发现的循环，浪费时间，并得出不一致结论。没有共享记忆的多智能体系统也会面对同样命运。记忆是提供连续性和共享现实理解的关键架构组件，它将一组独立专家转化为连贯、智能团队。它允许系统在复杂任务中保留状态，从过往交互中学习，并确保每个智能体都基于一致事实行动。
记忆增强型架构
稳健多智能体系统会实现多层记忆架构，如图 7.3 所示。该设计将即时、短期上下文与持久、长期知识分离，使智能体团队能够兼具速度和深度。
图 7.3——记忆增强型智能体架构
工作记忆（短期上下文）
这是智能体针对当前任务的活跃“草稿纸”。它保存即时上下文，例如用户初始查询和最近工具调用结果。Agent Core 充当活跃上下文管理器，决定哪些信息足够相关，应保留在这个有限窗口中，哪些信息可以在步骤完成后卸载。
长期记忆（知识库）
这是团队共享的持久图书馆，通常在向量数据库中建立索引以支持快速语义检索。它由两种不同类型组成：
情节记忆：这是系统交互的历史记录，像日志本或一系列会议纪要。它存储过去和当前任务中的事件序列、智能体对话和工具输出。
语义记忆：这是持久事实知识的仓库，也就是与智能体领域相关概念的百科全书，例如公司描述、产品目录或监管指南。
当新任务开始时，Agent Core 会查询长期记忆以检索相关信息，并将其加载到工作记忆中。这确保下游智能体能够访问与 planner 制定初始策略时相同的基础事实，从而在整个工作流中保持一致性。
为了看到这种分层记忆架构如何在实践中运行，我们现在考察一个市场情报系统。该示例展示了专门智能体中的简单无状态函数，如何通过共享记忆架构在更大的有状态工作流中被协调。
实现示例：市场情报系统
这种记忆架构允许简单、无状态函数在更大的有状态工作流中充当专门智能体。在我们的市场情报系统中，每个专家接收公司名称，并返回一个结构化的发现 payload：例如，NewsAgent 返回近期头条，FinancialAgent 返回关键财务指标，SentimentAgent 返回带支持证据的聚合情绪分数。三者都用相同字典布局包装结果：{"source": ..., "status": ..., "data": ...}，使其输出可预测，并便于编排器处理。
from typing import Dict, Any
def NewsAgent(company_name: str) -> Dict[str, Any]:
"""Fetches top news headlines from a data source."""
print("[NewsAgent] Fetching headlines...")
headlines = [
f"{company_name}: Q3 earnings beat analyst estimates by 8%",
f"{company_name} announces expansion into cloud infrastructure",
f"Regulatory review concluded; {company_name} cleared to proceed",
]
response = {"data": headlines}
# response = news_api.get(company_name)
return {"source": "NewsAgent", "status": "success", "data": response["data"]}
def FinancialAgent(company_name: str) -> Dict[str, Any]:
"""Fetches financial data from a data source."""
print("[FinancialAgent] Fetching financial data...")
response = {
"data": {
"pe_ratio": 24.5,
"revenue_growth": 0.12,
"debt_to_equity": 0.38,
"last_close": 142.73,
}
}
# response = financial_api.get(company_name)
return {"source": "FinancialAgent", "status": "success", "data": response["data"]}
def SentimentAgent(company_name: str) -> Dict[str, Any]:
"""Fetches a sentiment score from a data source."""
print("[SentimentAgent] Fetching sentiment score...")
response = {
"data": {
"score": 0.72,
"label": "positive",
"evidence": [
f"Investor confidence in {company_name} remains high.",
"Social media tone broadly favorable this week.",
],
}
}
# response = sentiment_api.get(company_name)
return {"source": "SentimentAgent", "status": "success", "data": response["data"]}
在这个系统中，manager agent 协调三个专门智能体：NewsAgent、FinancialAgent 和 SentimentAgent。它将同一个公司名称委派给每个专家，并等待它们返回结构化回应。每个智能体返回其发现字典后，manager 会将结果写入情节记忆，创建带时间戳的记录，说明发现了什么以及何时发现。随后，LLMAnalystAgent 被要求创建摘要。它会查询检索层，将两类信息拉入工作记忆：来自情节记忆的新鲜发现，包括新闻、财务指标、情绪，以及来自语义记忆的持久公司背景信息。通过将即时结果与长期上下文结合，分析智能体可以生成丰富、有洞察力且有依据的报告。该模式跨交接保留状态，减少冗余，并允许由简单智能体组成的团队执行复杂、知识密集型工作。
一旦允许多个专门智能体将各自观点贡献到共享记忆中，我们获得了更广的洞察，但也引入了分歧可能。新闻、财务和情绪信号可能指向不同方向，两个检索智能体也可能就同一个实体返回相互矛盾的证据。为了构建可信多智能体系统，我们需要明确机制来检测这些冲突，并以保持透明性和可审计性的方式解决冲突。
冲突解决机制
在任何由多个专家分析复杂信息的系统中，分歧不仅可能发生，而且不可避免，甚至可能是稳健、多元分析的标志。多智能体系统的架构强度，不取决于避免冲突的能力，而取决于以建设性方式解决冲突的能力。在 manager agent 委派任务之后，它最终且最关键的责任是综合：聚合结果、识别冲突，并将竞争性输出转化为一个单一、连贯且可辩护的最终产物。
仲裁架构
为了可靠管理分歧，我们需要一个形式化、自动化的仲裁流程。图 7.4 所示工作流提供了一份蓝图，用于将相互冲突的智能体输出转化为单一可信结果。该过程通常包含几个自动化阶段，并以人类专业能力作为最终安全网。
图 7.4——冲突解决机制
这个工作流建立在几个关键阶段之上。它始于冲突检测，自动识别智能体之间何时存在分歧。随后，仲裁智能体会尝试通过查询可信知识库来进行自动仲裁。仲裁是否成功，由基于置信度的共识机制衡量。最后，如果置信度仍然较低，系统会按照预定义路径升级给人工，确保复杂歧义由专家处理。
我们将逐步走过这个仲裁工作流：先看系统如何检测两个智能体存在分歧，再看仲裁智能体如何提出整合答案，最后解释人类何时以及如何作为最后审查阶段介入。
冲突检测：当两个或多个独立智能体产生冲突输出时，流程开始，例如 Report A 和 Report B。系统必须首先自动检测这种分歧。常见技术是计算输出之间的语义相似度；如果结果分数低于预定义阈值，例如 0.7，就会标记冲突，并触发仲裁工作流。
自动仲裁：冲突报告随后被路由给专门的仲裁智能体进行调和。该智能体充当中立法官，通过查询可信知识库、重新审查源数据，或应用已学习策略，评估竞争性主张，判断哪个结论更可信。在某些情况下，它可能综合两个原始报告中的部分内容，形成新的输出。
基于置信度的共识：仲裁智能体不只是作出决定；它还会生成经过校准的置信度分数，量化自身对结果的确定性。该分数随后与策略阈值比较，例如 95%。如果仲裁智能体的置信度足够高，其决策被接受，形成自动化共识。
人工升级：如果仲裁智能体置信度较低，系统会承认歧义，并将问题升级给人工审阅者。这是一个关键设计原则：人工审查不被视为失败，而是控制流中计划好的、一等分支，确保细腻或高风险决策由必要专业知识处理。
在整个过程中，系统会持久记录所有输入、中间决策、置信度分数和最终理由。这创建了完整审计轨迹，对治理、调试和未来系统改进至关重要。这种结构化工作流将冲突从潜在失败，转化为获得更可靠、更充分验证结果的机制。
为了使这个仲裁工作流更加具体，我们现在看它如何在多智能体研究系统中实现。下一个示例展示 manager 如何检测冲突信号、计算冲突分数，并通过自动和人工审查路由案例，以达成最终综合报告。
实现示例
在我们的市场情报系统中，ManagerAgent 使用 _synthesize_report 方法执行工作流的最后一步：将所有专家发现聚合为一个单一、连贯报告。这个方法也实现了一种简单冲突检测形式。下面代码展示它如何计算 conflict_score，用于衡量 SentimentAgent 和 FinancialAgent 发现之间的分歧，具体是公众情绪与股票表现之间的分歧：
class ManagerAgent:
def _synthesize_report(self, results: Dict[str, Any]) -> str:
financial_data = results.get("FinancialAgent", {}).get("data", {})
sentiment_data = results.get("SentimentAgent", {}).get("data", {})
news_items = results.get("NewsAgent", {}).get("data", [])
stock_change = financial_data['change_pct']
sentiment_score = sentiment_data['sentiment_score']
# A simple score to quantify the difference between sentiment
# and financial performance.
conflict_score = abs(sentiment_score - (stock_change / 10))
headlines = '; '.join(news_items[:2]) if news_items else "no headlines"
report = f"Market Intelligence Report\n"
report += f"Recent news: {headlines}\n"
report += f"P/E ratio: {financial_data.get('pe_ratio', 'N/A')}, Revenue growth: {financial_data.get('revenue_growth', 0):.0%}\n"
if conflict_score > 0.5:
report += (
f"**Conflict Detected (Score: {conflict_score:.2f}):** "
f"A significant discrepancy exists..."
)
else:
report += (
f"**Alignment Confirmed (Score: {conflict_score:.2f}):** "
f"Public perception and market performance are well-aligned..."
)
return report
这个综合步骤执行的不只是简单数据聚合。conflict_score 通过指出市场信号何时相互矛盾，提供更高层洞察。这使最终报告能够提供综合分析，而不只是原始数据，展示了一种基础冲突解决机制。
该公式会在比较之前，将两个输入归一化到兼容尺度上。
sentiment_score 已经由 SentimentAgent 限制在 [−1, 1] 范围内。stock_change 表示百分比，例如 5.0 表示 5% 变化；除以 10 会将典型每日波动的 ±10% 映射到相同的 [−1, 1] 尺度。0.5 阈值表示归一化尺度上的半单位偏差，相当于情绪和股价变化之间有 5 个点差距，系统将这种分歧视为足够重要，需要标记给分析师。
到目前为止，我们关注的是相对短生命周期的交互：单个智能体调用工具、智能体链协作完成任务，以及仲裁机制解决输出冲突。然而，在许多企业中，这些能力存在于运行时间更长的业务流程中，这些流程跨越数小时、数天甚至数周，并要求持久状态、检查点和人工监督。为处理这种更广泛语境，我们现在转向智能体工作流系统模式。
智能体工作流系统
真正的智慧也需要耐心和视角。有些决策必须随着时间展开，需要记忆、持久性，以及在高风险情境中暂停等待人类判断的能力。就像明智领导者会在果断行动和反思等待之间取得平衡一样，智能体系统也必须被设计为不仅能快速行动，还能维持跨数小时、数天，甚至 human-in-the-loop（HITL）周期的复杂流程。
智能体工作流系统将编排扩展为长时间运行、有状态的业务流程。不同于短生命周期工具调用或临时智能体链，工作流需要持久性、分支、错误恢复，以及用于人工监督的检查点。这些系统将自动化速度与治理审慎结合起来，确保结果始终与业务目标和伦理约束保持一致。
本节探索工作流管理器如何将流程建模为状态机或图，将智能体集成到每个阶段，并嵌入升级路径，使人工操作员能够在需要时介入。为了使这些概念具体化，我们将考察两个实践案例。首先，我们会构建一个电商订单处理工作流，展示如何将智能体和 human-in-the-loop 检查点嵌入流程。随后，我们分析一个更复杂的多智能体保险理赔工作流，展示这类系统如何处理分支逻辑和状态转换。最终得到的是一种既体现自动化效率，又体现人类智慧问责的架构。
案例研究：电商订单处理工作流
为了理解这些原则如何应用，我们从一个熟悉业务流程中的智能体工作流开始：处理一笔简单电商订单。第一个案例研究聚焦于将工作流表示为一系列步骤的基础机制，并把工具和智能体连接进一个简单、基本自动化的“happy path”。在下一个案例研究中，我们会将相同模式复用到一个更复杂、长时间运行的企业工作流中，其中包含更丰富分支和人工参与。
我们的工作流将流程建模为一系列步骤，每个步骤由一个工具或专门智能体执行。编排器，也就是 workflow manager，负责按正确顺序执行这些步骤并管理流程状态。最初的 happy-path 版本定义了标准订单的清晰四步流程。
def workflow_manager_agent(order: Dict[str, Any], inventory_db: pd.DataFrame):
order_id = order.get('order_id', 'N/A')
print(f"\n--- Starting Workflow for Order #{order_id} ---")
try:
# Step 1: Validate the order data
is_valid, order_total = validate_order(order, inventory_db)
if not is_valid:
raise AgentError("Order validation failed.")
# Step 2: Assess fraud risk with an intelligent agent
risk_analysis = llm_analyst_agent(order, order_total)
# ... Human-in-the-Loop logic will be added here ...
# Step 3: Check and reserve inventory
if not check_inventory(order, inventory_db):
raise AgentError("Inventory check failed.")
# Step 4: Process the payment
if not process_payment(order, order_total):
raise AgentError("Payment processing failed.")
print(f"--- Workflow for Order #{order_id} COMPLETED SUCCESSFULLY ---")
except AgentError as e:
print(f"--- Workflow for Order #{order_id} TERMINATED. Reason: {e} ---")
在工作流节点中嵌入智能
虽然工作流中的某些步骤是确定性的，例如 check_inventory，另一些则需要细致判断。第 2 步风险评估，就是一个很难用简单规则编码的非确定性任务示例。这时，我们可以将一个由 LLM 驱动的智能体直接嵌入工作流。llm_analyst_agent 被设计为具备适应性，如果主模型不可用，则 fallback 到简单基于规则的系统。
def llm_analyst_agent(order: Dict[str, Any], order_total: float) -> Dict[str, str]:
print(f" [Step 2] Assessing risk for Order #{order.get('order_id', 'N/A')}...")
# Fallback mode if a powerful model is unavailable
if not OPENAI_API_KEY:
print(" - Mode: Using rule-based mock analysis.")
# ... rule-based logic for high value or mismatched addresses ...
return {'risk_level': 'low', 'reason': 'Standard order parameters.'}
# Primary mode using an LLM for nuanced analysis
print(" - Mode: Using OpenAI GPT for analysis.")
try:
# ... logic to create a prompt and call the OpenAI API ...
analysis = json.loads(response.choices[0].message.content)
print(f" - LLM Analysis complete. Risk Level: {analysis.get('risk_level')}")
return analysis
except Exception as e:
print(f" - FAILED: ... Defaulting to high risk.")
return {'risk_level': 'high', 'reason': 'LLM analysis failed.'}
Human-in-the-loop 协调
嵌入智能体来评估风险，会产生一个新需求：系统应该如何处理被标记为高风险的订单？自动拒绝可能失去一位有价值客户，而自动批准可能导致欺诈。这个决策点非常适合 HITL 协调。HITL 机制充当安全阀，暂停自动化以请求人类判断。
为了使其具体化，我们扩展前面的电商工作流：下面的 workflow_manager_agent 与之前的编排器相同，但现在加入了一个 “Step 2.5” 升级门。它会调用基于 LLM 的风险分析师；当风险为中等或高时，暂停工作流，以获得人工操作员明确的 approve 或 reject 决策。
# Enhanced workflow_manager_agent with HITL logic
def workflow_manager_agent(
order: Dict[str, Any], inventory_db: pd.DataFrame
):
try:
# ... Step 1 and 2 from before ...
risk_analysis = llm_analyst_agent(order, order_total)
risk_level = risk_analysis.get('risk_level', 'high').lower()
risk_reason = risk_analysis.get('reason', 'No reason provided.')
# Step 2.5: Human-in-the-Loop Escalation Gate
if risk_level in ['high', 'medium']:
print(f"\n [!] HUMAN INTERVENTION REQUIRED for Order #{order_id}!")
print(f" Reason: Analyst flagged order for '{risk_reason}'.")
prompt = " Please type 'approve' or 'reject' to proceed: "
decision = ""
while decision not in ['approve', 'reject']:
decision = input(prompt).lower().strip()
if decision == 'reject':
print(" - DECISION: Human operator rejected the order.")
raise AgentError("Workflow terminated by human operator.")
else:
print(" - DECISION: Human operator approved the order. Resuming...")
# ... Steps 3 and 4 resume if approved ...
except AgentError as e:
# ... error handling ...
这个 HITL 块是安全自动化的核心。input() 提示会暂停程序，将控制权交给人类。这种模式对在错误代价很高的关键业务系统中部署智能体非常重要。
我们的电商示例凸显了超越简单线性链所需的能力。真实业务流程需要更复杂逻辑：如果库存不足怎么办？工作流是否应该暂停并等待补货事件？如果付款失败怎么办？是否需要回滚库存预留？
这些场景要求将工作流建模为有向图，而不是链，并具备以下特性：
- 条件分支逻辑
- 等待外部事件的状态，例如人工输入或文档上传
- 恢复与回滚路径
LangGraph 和 CrewAI 等现代编排引擎，正是为帮助开发者定义这些复杂、有状态且有韧性的智能体工作流而设计的。
电商工作流展示了单个 workflow manager 如何沿着基本线性的 “happy path” 协调工具和少量智能体，并为高风险订单设置简单 HITL 门。为了看到相同模式如何扩展到更丰富且更受监管的领域，我们现在转向第二个案例研究：自动化保险理赔处理。这个场景引入更大的专门智能体团队、更深层分支逻辑和多个升级路径，展示智能体工作流如何支持长时间运行、高风险流程，在这类流程中，治理和可审计性与吞吐同等重要。
案例研究：多智能体保险理赔工作流
为了展示多智能体系统如何在实际高风险环境中运行，考虑一个自动化保险理赔处理工作流。理赔必须从最初提交流转到最终解决，经过多个检查和决策点。整个过程由一组专门 AI 智能体管理，每个智能体都有不同角色，并在结构化状态机中协调。
该架构在效率与风险管理之间取得平衡。它自动化常规、低风险理赔以提升速度，同时确保复杂或高风险案例升级给人工专家审查。
系统由多个专门智能体组成，分别处理理赔流程的不同阶段：
Intake agent 摄取智能体：这是第一接触点。它使用光学字符识别（OCR）和自然语言处理（NLP）读取并数字化提交的理赔表格信息。
Validator agent 验证智能体：它充当守门人。它检查索赔人的保单状态，交叉检索数据库中的欺诈信号，并确保所有必需文件都已提供。
Classifier agent 分类智能体：在理赔被验证后，它根据所提供细节评估理赔类型、紧急程度和总体风险水平。
Payout agent 赔付智能体：它计算赔偿金额，并为获批低风险理赔处理付款。
Escalation agent 升级智能体：它监控工作流中特定触发器，例如高风险标记或其他智能体给出的低置信度分数，并在必要时将理赔路由给人工审查。
工作流状态机
理赔的旅程被可视化为一个状态机，它决定从一个阶段到下一阶段的流程和转换。图 7.5 展示了完整运行生命周期：
图 7.5——保险理赔状态机
理想路径会自动处理直接、低风险理赔。一条理赔进入 Intake 状态，随后进入 Validating，由验证智能体检查合法性；接着进入 Assessing Risk，由分类智能体进行分析；然后进入 Processing Payout，由赔付智能体执行结算；最后进入 Closed: Approved 状态。
系统会智能升级需要人工判断的理赔。如果分类智能体在 Assessing Risk 状态下将理赔标记为高风险，工作流会将其重定向到 Pending Human Review。人工审阅者可以批准理赔，使其回到 Processing Payout；也可以拒绝理赔，使其进入 Closed: Rejected。
工作流还考虑失败情况。如果 Processing Payout 期间付款失败，或人工专家拒绝理赔，流程会终止在 Closed: Rejected。
具体演练：Claim CLM-4821
为了让状态转换变得具体，我们端到端追踪一条理赔。Claim CLM-4821 是一条金额为 8,400 美元的房屋水损保单理赔，保单编号为 POL-992317，保单有效，且记录中没有欺诈标记。表 7.2 中的 guard conditions 驱动每次转换。
Intake：OCR 智能体提取字段：claim_id = CLM-4821，policy_id = POL-992317，type = water_damage，amount = 8400.00，并将其写入理赔记录。
Guard：所有必填字段已填充 → 前进到 Validating。
Validating：验证智能体确认保单 POL-992317 有效，且不存在欺诈标记。
Guard：验证通过 → 前进到 Assessing Risk。
Assessing Risk（批准路径） ：分类智能体返回 confidence_score = 0.91，risk = low。
Guard：confidence_score ≥ 0.85 且低风险 → 前进到 Processing Payout。
赔付智能体计算 8,400 美元赔偿，并将状态标记为已支付。理赔到达 Closed: Approved。
Assessing Risk（升级路径） ：假设分类智能体返回 confidence_score = 0.79，并带高风险标记。
Guard：confidence_score < 0.85 → 重路由到 Pending Human Review。
审阅者检查文件，并可以批准（→ Processing Payout）或拒绝（→ Closed: Rejected）。
这个状态机代表一个受治理系统，其中每个行动都被控制和记录。状态之间的转换由特定 guard 触发。例如：
| Guard condition | Action |
|---|---|
| If claim_amount > threshold | Route to human for approval |
| If validation fails | Transition to Closed: Rejected |
| if confidence_score < 0.85 | Escalate to Pending Human Review |
表 7.2——保险理赔工作流的状态转换 guard
在每次转换时，系统都会记录智能体的推理、使用的工具、人工决策，以及理赔记录的更新。这会创建完整审计轨迹，对合规、调试和事后复盘至关重要。通过将专门智能体与结构化状态机结合，这种架构既能快速处理常规理赔，又能安全、可追踪地处理复杂理赔。
小结
本章展示了从基础工具调用，到复杂多智能体编排和持久工作流系统的递进过程。我们考察了智能体如何通过三种架构模式，将推理能力延伸到行动中：调用外部函数的工具使用型智能体，协调专门智能体的 chain-of-agents orchestrators，以及实现带人工监督、有状态业务流程的智能体工作流系统。
三个案例研究通过不同实现细节层级展示了这些架构模式。数据可视化助手提供了完整可执行代码，展示意图解析、工具编排和错误处理。市场情报平台将可运行的专门智能体，与记忆和冲突解决层的架构描述结合起来。保险理赔工作流则呈现了状态机和治理架构，并通过具体 CLM-4821 演练展示 guard conditions 如何在实践中驱动转换。它们共同展示了支撑每种模式的关键原则：清晰的函数调用契约支持可靠工具调用，动态发现算法可扩展到大型工具集，分层错误处理提供韧性，智能体协作协议支持专业化，人工检查点确保治理。
这些模式为开发生产就绪智能体系统提供了基础，使其能够交付可衡量业务价值，同时维持安全性和问责性。本章建立的架构原则，将直接延伸到后续章节探索的领域特定智能体。第 8 章中，我们将转向数据分析与推理智能体，将这些编排模式应用到探索数据集、推荐可视化并执行统计推理以支持业务决策的系统中。后续章节还会介绍软件开发智能体，它们将与人类开发者协作编写、测试和维护代码。
