用于构建多智能体系统的智能体架构模式——用例：用于贷款处理的多智能体系统

数据智能老司机
25 阅读37分钟

在上一章中，我们成功构建并测试了一个用于处理贷款申请的单体（monolithic）单智能体系统。通过引入 FCoT 模式以及一组健壮的工具，我们构建了一个Level 3 的智能体，它能够编排（orchestrate）整个工作流。

这种单智能体架构，是智能体成熟度演进过程中的一个强大且必要的里程碑。它能端到端交付自治价值，并为接下来的演进提供了理想的基础。

然而，当我们分析系统性能并考虑真实生产环境的要求时，我们识别出单智能体设计天然存在的若干架构性限制：

  • 认知过载与可维护性：智能体中心的 FCoT 主提示（prompt）会变得越来越大、越来越复杂。随着我们加入更多工具或更细致的业务逻辑，这种单体提示将变得难以调试与维护，并且在修改时很容易引入意料之外的副作用。
  • 单点故障：整个流程依赖于一个智能体的推理循环。一旦该智能体在某一步发生误读，或因底层模型问题而失败，整个工作流就会停摆。系统缺乏面向关键任务所必需的模块化韧性。
  • 缺乏专业化：虽然智能体可以调用专用工具，但智能体本身仍是通才（generalist） 。它必须理解文档校验、征信政策、风险建模与合规等各领域的细节，这会加重其认知负担，也会让“只更新某一块专业能力而不影响其他部分”变得非常困难。

在看到了单一自治智能体的能力与局限之后，我们将正面解决这些挑战。

在本章中，我们将把方案从 Level 3 演进到 Level 4：通过将其重新架构为一个多智能体系统。

我们将应用 Supervisor（Orchestrator）Architecture（监督者/编排者架构）模式，把之前的专用“工具”提升（promote）为一支由多个单一职责智能体组成的协作团队。这种做法不仅能解决前一版设计的限制，还将为我们的智能体应用解锁新的可扩展性、韧性与可维护性层级。

这一新的结构，会把我们的应用从一个单一、复杂的实体，转变为由更简单、并且更重要的是**高度可互操作（highly interoperable）**的组件所构成的系统——我们将在“分层式智能体架构（Hierarchical agent architectures）”一节中看到这一点。

本章将覆盖以下主题：

  • 分层式智能体架构
  • 构建多智能体系统
  • 在实践中检视这些模式
  • 将该用例映射到 Agentic AI Levels（智能体 AI 等级）

技术要求

要成功完成本章的动手示例，你需要具备以下条件：

  • 一个 Google 账号：用于访问 Google Colab 与 Google AI Studio。
  • Google Colab：代码示例将以 Google Colab Notebook 形式运行，它提供免费的云端 Python 环境。示例较轻量，不需要高性能本地硬件；一个普通浏览器即可。
  • Google AI Studio API key：需要有效的 API key 才能访问示例中使用的 Gemini 模型。你可以按该文档获取：
    ai.google.dev/gemini-api/…
  • Python 库：示例依赖 google-adk 以及其他标准 Python 包。Notebook 中包含安装这些依赖的命令。

本章完整代码（包括可运行的 notebooks 与辅助脚本）位于本书的 GitHub 仓库：
github.com/PacktPublis…

分层式智能体架构

尽管多智能体系统可以采用多种拓扑结构来组织，例如适用于开放式创造任务的去中心化蜂群（decentralized swarms）或点对点网络（peer-to-peer networks），但受监管的企业工作流需要更严格的控制。对于贷款处理流水线而言，可审计性以及对特定步骤的严格遵循是不可妥协的，因此最有效的设计是分层式架构，也称为 Supervisor/Orchestrator 模式。

该模式将智能体组织为类似公司团队的结构：由一位“经理”管理一组“专家”。与其让一个单体智能体试图包揽一切，我们构建一个职责清晰划分的系统。

该模型由两类明确的智能体角色组成：

  • 监督者（父）智能体（supervisor / parent agent） ：该智能体扮演经理角色。它的核心职责是规划整体工作流，将子任务委派给合适的专家，监控进度，并将专家们的结果综合为最终输出。
  • 专家（子）智能体（specialist / sub-agent） ：这些智能体是各自领域的专家。每一个都被设计为把一件事做到极致，例如校验文档或计算风险评分。它接收任务，使用其专属工具执行，并将结果返回给监督者。

在角色明确之后，我们来看看支撑这种编排与模块化的具体架构模式：

  • Agent Delegates to Agent（智能体委派给智能体） ：这是该架构的核心模式。监督者智能体并不亲自执行工作，而是把工作委派给另一个自治智能体。ADK 的 AgentTool 类就是这一模式的直接实现。它把一个完整独立的智能体（包含其自身的 LLM、指令与工具）封装在标准“工具接口”之后，使监督者能够像同步调用普通函数一样调用它——当然代价是会引入嵌套式的延迟与 token 成本。
  • Fault Tolerance and Isolation（容错与隔离） ：通过把工作流拆分为相互独立的智能体，我们实现了故障隔离。如果 CreditCheckAgent 失败，它不会让整个系统崩溃。监督者可以捕获错误并决定后续策略，例如终止流程或升级给人类处理。这相比单体设计是显著改进。
  • Modularity（模块化） ：每个专家智能体都是一个自包含的专业模块。我们可以更新、改进，甚至替换 RiskAssessmentAgent，而无需触碰系统的其他部分，从而获得更高的可维护性与可扩展性。

下图展示了这种清晰的分层关系：

image.png

图 14.1——分层式智能体架构的简化模型

我们也将对比这一新架构与上一章讨论过的单体架构。

这一新结构将我们的应用从单一、复杂实体，转变为由更简单、可互操作组件组成的系统，如下所示：

image.png

图 14.2——单体架构与多智能体架构对比

接下来，我们将深入剖析我们的多智能体架构。

构建多智能体系统（Building the multi-agent system）

现在，我们将重构（refactor）我们的 Notebook 来实现这一更优的架构。这个过程包括创建真正专业化的智能体：每个智能体都有自己的模型、指令（instructions）以及一个专属工具（single dedicated tool） 。

为专家智能体配备专属工具（Equipping specialists with dedicated tools）

首先，我们定义将作为每个专家智能体专属工具的 Python 函数。为了简化示例，我们使用了标准的 Python 类型提示（type hints）；但在生产级系统中，应当通过更严格的输入/输出 schema（例如使用 Pydantic 等库）来强制校验，从而保证智能体之间的数据完整性（data integrity）。

现在，每个函数都包含其任务对应的精确业务逻辑，包括我们“不那么快乐路径（unhappy path）”场景的特定规则，例如：将低于 600 的信用分数立即标记为高风险失败条件：

#@title Create and Equip All Specialist Sub-Agents with Tools
from google.adk.agents.llm_agent import LlmAgent

from google.adk.tools import FunctionTool, AgentTool

import json

# --- 1. Define Python Functions to Serve as Tools ---
def validate_document_fields(application_data: str) -> str:

   # ... (function definition from the notebook) ...
def query_credit_bureau_api(customer_id: str) -> str:

   # ... (function definition from the notebook) ...
def calculate_risk_score(loan_amount: int, income: str, credit_score: int) -> str:

   # ... (final, refined function definition from the notebook) ...
def check_lending_compliance(credit_history: str, risk_score: int) -> str:

   # ... (final, refined function definition from the notebook) ...
# --- 2. Wrap Functions in ADK FunctionTools ---

validation_tool = FunctionTool(func=validate_document_fields)

credit_tool = FunctionTool(func=query_credit_bureau_api)

risk_tool = FunctionTool(func=calculate_risk_score)

compliance_tool = FunctionTool(func=check_lending_compliance)

在上面的代码块中，我们建立了系统的基础能力：我们定义了四个相互独立的 Python 函数，每一个都代表一个特定的领域能力（domain capability）：

  • validate_document_fields：模拟对传入贷款申请文档的解析，确保 JSON 结构有效，并且包含所有必填字段
  • query_credit_bureau_api：作为外部数据接口，为给定客户 ID 拉取信用分数
  • calculate_risk_score：封装核心金融逻辑，基于收入、贷款金额与信用分之间的关系计算风险指标
  • check_lending_compliance：实施业务治理，验证所计算的风险画像是否满足机构的监管标准

我们将这些函数分别用 ADK 的 FunctionTool 对象进行了封装（wrap）。这个封装是关键：它会检查（inspect）Python 函数签名，并生成 LLM 所需要的 schema 描述，从而让模型理解如何调用该工具。

现在，我们已经锻造好了各个工具并定义了它们所强制执行的严格数据契约（data contracts），下一步就需要把这些工具交到有能力的“操作者”手上。在下一节中，我们将实例化这些专家智能体本身，为每一个智能体赋予不同的身份（identity）、明确的任务（mission）以及刚刚创建的专属工具。

创建专家智能体小队（Creating the specialist agent crew）

在工具定义完成后，我们开始创建专家智能体。关键点在于：每个智能体现在都是一个独立的 LlmAgent 实例，拥有模型、极度聚焦的指令集，以及唯一的专属工具。它们的指令变得更简单，只要求它们使用自己的工具，并期望特定输入。这在智能体之间强制建立了清晰的数据契约（data contract）。

这种解耦还带来了一个强大的生产策略：异构模型选择（heterogeneous model selection） 。你不再需要用同一个模型贯穿整个工作流。你可以给 document_validator 分配一个轻量、低延迟的模型（例如 Gemini Flash）以实现快速抽取；同时保留一个更强的推理模型（例如 Gemini Pro）给 compliance_checker 去处理细致的政策解释。虽然这样能优化成本与性能，但需要注意：混用模型可能引入细微的行为差异；像我们这样依赖严格 FunctionTool 定义，是在多样化智能体团队中维持一致性的最佳方式。

随后，我们将每个专家智能体封装进 AgentTool。这是最关键的一步，因为 AgentTool 充当了适配器（adapter），使得一个智能体可以被另一个智能体调用，从而启用 Agent Delegates to Agent 模式：

# --- 3. Update Agent Instructions with Explicit Input Requirements ---

doc_validator_instructions = """
You are a Document Validation Agent.
Your ONLY task is to call the `validate_document_fields` tool.
**INPUT REQUIREMENT:** You must receive the complete, original loan application as a JSON string.
If you receive the required input, call the tool and return its exact output.
If the input is missing or malformed, respond with an error: 'ERROR: Missing or invalid application_data input.'
"""
# ... (and so on for the other 3 agents' instructions) ...
# --- 4. Create Agent Instances, Assigning a Model to Each ---

document_validation_agent = LlmAgent(

   model="gemini-3-flash",

   instruction=doc_validator_instructions,

   name="document_validator",

   description="Use this agent to validate the structure and content of a new loan application document.",

   tools=[validation_tool]

)

# ... (and so on for the other 3 agents) ...
# --- 5. Wrap Agents in AgentTools ---

validator_agent_tool = AgentTool(agent=document_validation_agent)

credit_checker_agent_tool = AgentTool(agent=credit_check_agent)

risk_assessor_agent_tool = AgentTool(agent=risk_assessment_agent)

compliance_checker_agent_tool = AgentTool(agent=compliance_agent)

生产警告：抽象的成本（Production warning: The cost of abstraction）
要谨慎使用深层委派链（例如 supervisor → manager → team lead → worker）。每增加一层都会引入一次完整的 LLM 推理往返（round-trip），显著增加延迟与 token 成本。

设计说明：通过 GenerateContentConfig 进行生产配置（Design note: Production configuration via GenerateContentConfig）
尽管我们的代码强调了智能体结构的“连线方式（structural wiring）”，但生产系统还需要严格的行为控制。在 ADK（以及 Google GenAI SDK）中，这通常通过 generate_content_config 参数来管理，它接收一个 types.GenerateContentConfig 对象。为了让我们的专家智能体在企业级工作流中行为可预测，我们必须配置若干关键参数：

  • Temperature（temperature） ：专家智能体（例如 validator 与 compliance agent）应设为 0.0，以强制确定性、分析型输出。只有在创意或对话角色中才使用更高值（例如 0.7）。
  • 输出限制（max_output_tokens） ：设置严格上限，防止失控循环或过度冗长。
  • 安全（safety_settings） ：配置阻断阈值，确保智能体处理敏感金融数据时不会产生误报式拒答。

在本次架构演示中，我们依赖默认配置以聚焦编排模式，但在真实部署中你应始终显式配置这些参数。

在前述代码中，我们将每个专用智能体封装成 AgentTool。这一关键步骤把自治子智能体转化为编排者可调用的工具，从而有效实现 Agent Delegates to Agent 模式。
现在专家小队已全部定义并可访问，我们必须更新带领他们的编排者（orchestrator）。

添加生产级护栏（Adding production guardrails）

我们的架构定义了智能体之间如何对话，但 Level 4 系统还必须应对生产环境的噪声。在更新后的实现中，我们引入企业级鲁棒性模式，确保系统不会在 API 压力下崩溃。

# 1. Configure the agent's reasoning engine with a Thinking Budget
thinking_config = ThinkingConfig(
include_thoughts=True,
thinking_budget=1024
)

# 2. Implement the Robust Runner with Retries and Throttling
@sleep_and_retry
@limits(calls=15, period=60)
@retry(
stop=stop_after_attempt(5),
wait=wait_exponential(multiplier=2, min=4, max=30),
retry=retry_if_exception(is_rate_limit_error)
)
def start_agent_run(runner, user_id, session_id, content):
return runner.run(user_id=user_id, session_id=session_id, new_message=content)

如上所示，我们将执行逻辑封装在一个健壮的 runner 中，它实现了：

  • 限流（Rate limiting） ：使用 @limits 装饰器主动节流请求，确保不超过提供方配额（例如每分钟 15 次调用）。
  • 指数退避（Exponential backoff） ：使用 tenacity 库，在遭遇 RESOURCE_EXHAUSTED (429) 错误时智能重试。系统不会直接让贷款申请失败，而是以递增间隔等待并重试。
  • 思考预算（Thinking budgets） ：通过 ThinkingConfig 配置 thinking_budget，让编排者能在内部推理上投入更多计算周期，这对解析子智能体返回的嵌套 JSON 数据非常关键。

修订编排者的“心智”（Revising the orchestrator's mind）

此时，我们的主智能体角色从“执行者（doer）”转变为“管理者（manager）”。

架构说明：上下文状态管理（Architectural note: Contextual state management）
与工作流引擎那种在步骤间传递结构化 Python 字典（例如 state = {'id': 123}）不同，我们的编排者依赖上下文状态（contextual state） 。“状态”是专家智能体的 JSON 输出在上下文窗口中的累积历史。

例如，当文档校验智能体返回：

{"status": "valid", "extracted_data": {"customer_id": "CUST-123", "income": "5000"}}

编排者会从其上下文窗口中读取该结果，并动态构造下一次委派调用的 payload：

credit_checker_tool(customer_id="CUST-123")

这要求编排者被明确指示需要提取并转发哪些字段，从而在语义层面扮演“数据映射器（semantic data mapper）”。

我们据此更新主智能体的 FCoT 提示：它的指令不再引用一组普通工具，而是引用其专家团队。该提示也让编排者对“从一个智能体向下一个智能体传递正确数据上下文”承担显式责任，从而解决我们在最终调试阶段识别出的“上下文丢失（loss of context）”问题：

#@title Create the Orchestrator Agent (with Self-Correction and Data Awareness)

orchestrator_instructions = """
You are an FCoT-powered Orchestrator Agent managing a team of specialist agents...
Your primary role is to plan the workflow, delegate tasks, and intelligently handle exceptions.
**Failure Handling Policy:**
   1.  **Reflect:** If a specialist agent returns an error, first analyze the error message.
   2.  **Resolve:** If the error is due to missing information, review the original request...
   3.  **Escalate:** Only if you cannot resolve the error on your own should you escalate...
**Your Specialist Team (Available Agents for Delegation):**
   * **`document_validator`:** ... It returns the validated data.
   * **`credit_checker`:** ... You must pass it the `customer_id` from the validated data.
   * **`risk_assessor`:** ... You must pass it the `loan_amount`, `income`, and `credit_score`...
   * **`compliance_checker`:** ... You must pass it the `credit_history` AND the `risk_score`...
"""
# ... (rest of the agent initialization code) ...

这些指令定义了监督者的运行原则。通过显式定义失败处理策略（failure handling policy）以及带严格输入要求的专家团队名册（roster），我们确保编排者负责管理工作流，而不是试图亲自执行每一步。

至此，从各个工具到中心编排者，我们的架构已经完整定义。接下来，我们准备对系统进行测试。

执行与分析（Execution and analysis）

当我们的多智能体系统完整组装完成后，就可以准备部署了。为此，我们需要建立一个运行时环境，它不仅能够执行智能体，还能捕获其复杂的内部推理过程，以便进行分析。

我们将设置 ADK 的 Runner 对象来管理智能体的生命周期，并定义一个 call_agent 函数。这个函数相当于我们观察智能体心智的窗口：它通过过滤并展示执行循环中产生的原始事件（raw events）来实现可观测性（Observability） 模式——包括思考（thoughts）、工具调用（tool calls）与输出（outputs）。

会话初始化（Session initialization）

首先，我们初始化会话服务（session service）。它维护交互状态，使智能体在必要时能够跨多个轮次保留上下文：

#@title Session init
# Define unique IDs for our test user and session
USER_ID = "loan_officer_01"
SESSION_ID = str(uuid.uuid4()) # Generate a new session ID for this run
APP_NAME = "Loan_Agent"

session_service = InMemorySessionService()
session = await session_service.create_session(app_name=APP_NAME, user_id=USER_ID, session_id=SESSION_ID)
runner = Runner(agent=agent, app_name=APP_NAME, session_service=session_service)

print(f"Runner is set up. Using Session ID: {SESSION_ID}")

执行循环：实现可观测性（The execution loop: implementing observability）

下面的 call_agent 函数充当我们的执行“测试台”（execution harness）。它将用户查询发送给 runner，然后遍历智能体返回的事件流（stream of events）。

关键在于：这个函数会解析智能体输出，将思考（由我们的 FCoT 指令驱动的内部独白）与工具调用（实际采取的动作）分离开来。这种细粒度日志对于验证编排器（orchestrator）是否按照我们设计的模式正确规划与委派任务至关重要：

#@title Call Agent Method
def call_agent(query: str):
    """
    Packages a query, runs it, and prints a clean, filtered log of the
    agent's thoughts, tool calls, and final response.
    """
print(f"\n > > > > USER REQUEST: {query.strip()}\n")

    # Create the user message content and run the agent
    content = types.Content(role='user', parts=[types.Part(text=query)])
    events = runner.run(user_id=USER_ID, session_id=SESSION_ID, new_message=content)

    print("--- Agent Activity Log (Filtered) ---")
    for event in events:
        if event.content:
            for part in event.content.parts:
                # Check for a thought by checking for a truthy value
if part.thought and part.text:
                    print(f"\n🧠 THOUGHT:\n{part.text.strip()}")

                # Check for a tool call by checking for a truthy value
if part.function_call:
                    tool_name = part.function_call.name
                    tool_args = dict(part.function_call.args)
                    print(f"\n🛠️ TOOL CALL: {tool_name}({tool_args})")

                # Check for a tool output by checking for a truthy value
if part.function_response:
                    tool_name = part.function_response.name
                    tool_output = dict(part.function_response.response)
                    print(f"\n↩️ TOOL OUTPUT from {tool_name}:\n{tool_output}")

        # Extract the final text response at the end
if event.is_final_response() and event.content:
            final_text = ""
# The final answer is in a Part with text but is not a thought
for part in event.content.parts:
                if part.text and not part.thought:
                    final_text = part.text.strip()
                    break # Use the first non-thought text part as the answer
if final_text:
                print("\n---------------------------------")
                print("✅ FINAL RESPONSE:")
                print(final_text)
                print("---------------------------------")

当我们把这个执行“测试台”搭好之后，就可以让智能体跑一些特定场景了。

场景分析：深入剖析智能体推理（Analysis of scenarios: a deep dive into agent reasoning）

通过检查 call_agent 产生的日志，我们将验证 Supervisor 与 Agent Delegates to Agent 这两个模式在实践中是如何运作的。

场景 1：快乐路径（成功批准）（Scenario 1: The happy path (successful approval)）

在这个场景里，我们提供一份来自资质良好申请人的有效申请。目标是观察多智能体协作的完美、不中断流转，以及编排器的推理过程。

下面是快乐路径的完整智能体活动日志：

>>>> USER REQUEST: Please process this new loan application: …
Please process this new loan application:
  "customer_id": "CUST-12345"
  "income": "USD 5000 a month"
  "loan_amount": 50000,
  "credit_history": "Very Solid",
  "loan_documents": ["doc_1.pdf","doc_2.pdf","credit_history.pdf","loan_application.docx"]


🧠 THOUGHT (Iteration 1: Planning):
RECAP: Okay, so I've got a loan application here... I see the user has provided all the necessary details: the customer ID ("CUST-12345"), their income (USD 5000 a month), the requested loan amount (50000), the credit history ("Very Solid")... My team of specialized agents are set up to handle each stage of the process...
REASON: The first agent, the document_validator, requires the entire application data in a single JSON string... Once validated, I'll extract the customer ID and feed that to the credit_checker... Then, using that score along with the loan amount and income, I'll pass those to the risk_assessor... Finally, the risk score and the original credit history will be analyzed by the compliance_checker...
VERIFY: I've verified that each agent's input matches their expected data contract, making sure that everything is set up correctly for the agents to do their jobs. Now, it's time to execute the plan...
🛠️ TOOL CALL: document_validator(...)
...
↩️ TOOL OUTPUT from document_validator: {'result': '{"status": "validated", ...}'}
...
🧠 THOUGHT (Iteration 2: Synthesis):
RECAP: Okay, here's the final call. I've run this application through the complete origination pipeline...
REASON: ...document validation was a clean pass... credit check came back with a solid score - 810... risk assessment gave us a risk score of 6, which falls within acceptable parameters... compliance check? That's a green light... I will combine all these results.
VERIFY: Taking all of this into account, I have everything I need to render the final summary and recommendation.
✅ FINAL RESPONSE:
The loan application... has been successfully processed... Loan Decision: Approved.

这条执行轨迹为 FCoT 模式如何治理智能体行为提供了一个完美、可观测的例子：

迭代 1（Iteration 1），规划阶段（planning phase） ：编排器的第一段思考就是一个完整的 FCoT 规划环：

  • 它以 RECAP 开始，确认用户请求并盘点可用资源（专家智能体）。
  • 接着进入 REASON，制定精确的多步骤计划。关键在于：它不仅在排序各个智能体，还在推理智能体之间的数据流转，明确提到会从上一步“提取 customer ID”用于下一步。这体现出它对我们嵌入提示词的数据契约的认知。
  • 最后执行 VERIFY，这是 FCoT 的关键组件。它用内部规则批判/检查自己的计划，写道：“我已验证每个智能体输入与其预期数据契约匹配。”这种自我校验确保智能体高置信度地推进，降低错误风险。

迭代 2（Iteration 2），综合阶段（synthesis phase） ：在所有工具调用完成后，智能体在回复之前的最后一次思考是另一个 FCoT 环，这次聚焦于综合输出：

  • 以 RECAP 开始，总结工作流状态（“我已跑完整个贷款发放流水线……”）。
  • 进入 REASON，把各个专家的发现整合成连贯叙述（“文档校验通过……信用分 810……风险分 6……合规绿灯……”）。
  • 以 VERIFY 结束，确认已经拥有生成最终交付物所需的一切信息，直接满足其指令契约。

这种结构化的两阶段推理过程正是 FCoT 模式的标志：它强制智能体在规划上更谨慎、在结论上更严谨，使其成为复杂多步骤任务的高可靠编排器。

在已验证策略之后出现的一系列 TOOL CALL 日志，就是该策略的直接执行，清晰展示了 Supervisor（Orchestrator） 与 Agent Delegates to Agent 两个模式在实践中的运作方式。

场景 2：拒绝路径（高风险失败）（Scenario 2: The denied path (high-risk failure)）

该场景测试系统观察、约束并执行关键业务规则的能力，这通常被称为策略遵循（policy adherence） 。在负面但预期的结果下，智能体的推理能力是其鲁棒性的关键测试。

下面是拒绝路径的完整智能体活动日志：

>>>> USER REQUEST: Please process the loan application: …
"customer_id": "CUST-55555"
  "income": "USD 1000 a month"
  "loan_amount": 1000000,
  "credit_history": "Presenting Gaps",
  "loan_documents": ["drivers_license.pdf"]

🧠 THOUGHT (Iteration 1: Planning):
RECAP: Okay, so I've got the application details: customer ID "CUST-55555," income of USD 1000 a month, a hefty loan amount of 1,000,000...
REASON: I'll kick things off by feeding the entire application data... into the document_validator... Next, I'll extract the customer_id... and pass it to the credit_checker... and so on.
VERIFY: Data dependencies are solid.
... (A series of successful TOOL CALLS for validator, credit checker, and risk assessor) ...
↩️ TOOL OUTPUT from risk_assessor:
{'result': '{"risk_score": 8}'}
... (TOOL CALL to compliance_checker with risk_score: 8) ...
↩️ TOOL OUTPUT from compliance_checker:
{'result': '{"is_compliant": false, "reason": "Policy violation: Risk score of 8 is too high for approval."}'}
🧠 THOUGHT (Iteration 2: Synthesis):
RECAP: Okay, so I've run through the entire process.
REASON: First, the documents looked good... Next, the credit check showed a score of 680... The risk assessment flagged something though; a risk score of 8 came back. That's a bit high, and that's where the problem is. The compliance check flagged it right away: a risk score of 8 violates policy. It's a clear-cut policy violation; that's the bottom line.
VERIFY: The primary reason for denial is the high-risk score of 8, which exceeds the acceptable threshold for loan approval according to internal policy.
✅ FINAL RESPONSE:
The loan application for CUST-55555 is rejected. The primary reason for the rejection is a policy violation...

这条执行轨迹揭示了：即便结果为负，FCoT 模式也能确保鲁棒性。智能体不会简单失败或返回泛化错误，而是用同样严谨的认知结构来诊断问题并为拒绝提供正当理由。我们可以从中看到若干关键点：

  • 一致的规划（Consistent planning） ：编排器最初的 FCoT 规划环与快乐路径完全一致。这体现了系统的可靠性：无论申请内容如何，都遵循同样的 RECAP、REASON、VERIFY 严谨流程，保证过程一致性。

  • 综合相互矛盾的证据（Synthesizing contradictory evidence） ：日志中最有洞察的是最终一次思考——这里是 FCoT 综合环真正体现价值的地方：

    • 智能体先 RECAP 总结已完成的工作流。
    • 在 REASON 步中，它面对冲突证据：前几步成功（“文档没问题……信用分 680……”），但最后一步硬失败（“合规立刻拦截……明确的政策违规”）。智能体正确地推断：合规失败是最重要、最具决定性的因素。
    • 在 VERIFY 步中，它把最终结论直接锚定到专家智能体输出：“拒绝的主要原因是高风险分 8……”。这通过提供透明、可验证的否决理由，满足了**可解释性与审计追踪（Explainability and Audit Trail）**模式的要求。

这种“权衡证据并正确优先级排序关键失败”的能力是一种高级推理能力。FCoT 框架提供了让智能体能够稳定执行这种分析的结构，展示了它不仅能跑流程，还能基于结果做出可靠、可审计的判断。

现在我们已经逐步分析了多智能体系统的执行过程，接下来可以正式把观察到的行为与本书前面介绍的设计模式做一次明确映射。通过把智能体行为显式映射到这些模式上，我们能更好地理解它们如何作为构建鲁棒、智能的智能体系统的“基础蓝图”。

实践中的模式剖析（Examining the patterns in practice）

在本书中，我们系统性地探讨了一套用于高效且有效构建多智能体系统的设计与架构模式目录。每一种模式都像是一张蓝图，用来解决智能体工程中的某一类特定挑战。我们的多智能体贷款处理器并不仅仅是“一段代码跑一个智能体”；它是一个动态的智能体生态系统：这些模式在其中汇聚，塑造出一种与业务与领域需求相呼应的智能——这种智能通过严格评估得到验证，并由安全护栏加以保护，从而形成一种能力，其整体效用远远大于各个部分能力的简单相加。

通过这个例子，我们见证了：那些关于编排、推理与韧性的抽象模式，如何被落地实现，用以构建一个不仅智能、而且健壮且可审计的高级智能体。

接下来，让我们拆解我们的实现，看看这些关键模式究竟是如何被“注入生命”的——并把智能体自身的内部独白作为我们的导航。

模式：Supervisor（AI 编排器 / 元智能体）架构（Pattern: Supervisor (AI orchestrator or meta-agent) architecture）

Supervisor 模式是我们整个系统的“总蓝图”（master blueprint）。它要解决的核心问题是：当系统复杂度大到令人不堪重负时，如何管理这种复杂性——它通过建立清晰的控制层级来实现这一点。与其让一个单体智能体什么都懂、什么都做，这一模式主张采用“经理 + 团队”的组织结构。

Supervisor 智能体的职责不是亲自执行任务，而是理解高层目标，把目标拆解成逻辑步骤，把这些步骤委派给合适的专家角色，并将专家的发现综合为一个最终的、连贯的结果。

在我们的用例中，编排器智能体就是典型的 supervisor。它的 FCoT 提示词并不包含用于校验文档或评估风险的业务逻辑；它的整个认知过程都专注于工作流管理。

通过把细节工作卸载给专家，supervisor 可以把全部注意力集中在流程的战略性执行上，确保所有步骤都被正确且按顺序完成。正是这种抽象，使系统能够处理复杂、多步骤的业务流程，而不会把所有认知负载压到单一智能体身上——这对构建可扩展且具韧性的智能体应用至关重要。

我们在“拒绝路径（denied path）”场景中，能非常清晰地看到这一模式：当它收到了所有专家的报告后，它的推理完全是经理式的：

🧠 THOUGHT from the log: Okay, so I've run through the entire process. First, the documents looked good... Next, the credit check showed a score of 680... The risk assessment flagged something though; a risk score of 8 came back... The compliance check flagged it right away... a risk score of 8 violates policy.

智能体并没有自己去计算风险或做合规校验；它是在接收、解释并对团队的报告做优先级排序，从而做出最终的“高层执行决策”。这种**关注点分离（separation of concerns）**正是 Supervisor 模式的核心收益。

再看另一个例子：自动化供应链管理系统。一个 supervisor 智能体会监控整体库存水平。如果它检测到某个产品库存偏低，就会把任务委派给 SupplierContactAgent 去确认供货情况，把任务委派给 LogisticsAgent 去计算运输成本与时效，把任务委派给 PurchaseOrderAgent 去创建并提交采购订单——它编排整个采购流程，但不需要管理任何单一步骤的细节。

模式：Agent Delegates to Agent（Pattern: Agent Delegates to Agent）

该模式是实现 Supervisor 架构的主要机制。它为“一个智能体调用另一个自治智能体的能力”提供了标准化方法。

要让它工作，调用方并不需要理解被调用智能体的内部实现；它只需要知道：对方能做什么，以及对方需要哪些输入。这形成了一种强大的抽象，使我们能够构建模块化、可互操作的智能体系统。

在实现上，我们直接使用 ADK 的 AgentTool 来落地这一模式。通过把每一个专家（例如 document_validation_agent）包裹进 AgentTool，我们把它们变成了可调用组件，使编排器可以像使用工具带里的其他工具一样去调用它们。

这种封装至关重要：所有复杂逻辑（专家自身的指令、其专用的 Python 工具、以及它所使用的特定 LLM）都被完整地封装在专家智能体内部。这样一来，我们可以独立开发、测试，甚至替换专家智能体，而无需修改编排器。

智能体日志在工作流最开始就给出了一个清晰、无歧义的示例，展示了这一模式如何运作：

🧠 THOUGHT from the log: The first agent, the document_validator, requires the entire application data in a single JSON string... it's time to execute the plan and get this loan application processed.

🛠️ TOOL CALL: document_validator({'request': '{"customer_id": "CUST-12345", ...}'})

这个序列展示了编排器如何先规划委派，然后执行交接。AgentTool 提供了技术桥梁，把任务及必要数据传递给 document_validator 专家，而该专家随即启动它自己的独立推理循环。

再看另一个例子：智能家居系统。当中央 HomeManager 智能体收到诸如 Movie time 的指令时，它会通过 Agent Delegates to Agent 模式，把任务分别委派给：LightingAgent（调暗灯光）、BlindsAgent（放下窗帘）、MediaAgent（打开电视与音响系统）。

模式：FCoT（Pattern: FCoT）

FCoT 是支配 supervisor 心智的模式，它像是其认知操作系统（cognitive operating system）。它要解决的关键挑战是：如何确保智能体的推理过程是审慎的、可审计的，并且与核心指令保持对齐，从而在复杂、多步骤任务中防止“目标漂移（goal drift）”。它通过强制智能体在规划与最终综合时都遵循一种自适应、递归的 RECAP → REASON → VERIFY 循环来实现这一点。

它使用一个双目标函数（dual objective function）来优化每次迭代，因为在迭代推进时，它会逐渐收拢并聚焦其上下文“光圈”（context aperture）。

这种结构化推理，正是我们编排器能够成为可靠、值得信赖的经理的原因。它不会冲动行事；它的每个关键阶段都会先经历一段结构化反思与自我校正。

在“拒绝路径”场景中，FCoT 的综合循环尤为关键：它让智能体能够权衡相互矛盾的证据（前面步骤成功 vs 最终合规失败），并正确推断“政策违规”才是决定性因素。

在快乐路径日志里，智能体的第一段思考就是 FCoT 规划循环的完美示例：

🧠 THOUGHT from the log: RECAP: Okay, so I've got a loan application here... My team of specialized agents are set up to handle each stage... REASON: The first agent, the document_validator, requires the entire application data... Once validated, I'll extract the customer ID and feed that to the credit_checker... VERIFY: I've verified that each agent's input matches their expected data contract... Now, it's time to execute...

这不仅是一个简单计划；它是一套结构化、经过自我批判的策略，让智能体对后续行动具备高置信度，使其行为可预测、审计轨迹清晰。

再看另一个例子：一个负责总结论文的科研智能体。它的 FCoT 规划循环可能如下：

RECAP: 我需要总结这篇科学论文。
REASON: 首先我会阅读摘要与结论以把握主旨；其次阅读方法部分；第三起草总结。
VERIFY: 这是一个合乎逻辑且高效的计划，可以产出准确的总结。

在拆解了这些让智能体“活起来”的具体设计模式之后，我们现在需要把视角拉远。通过把我们的实践实现映射回本书开篇提出的 Agentic AI Levels，我们能更好地理解我们架构选择的战略含义。

我们的用例——从单智能体演进为多智能体团队——不仅仅是一次技术练习；它是组织在提升智能体能力、以解决日益复杂问题时所经历旅程的一个可触达、可验证的示范。

将该用例映射到 Agentic AI Levels（Mapping the use case to the Agentic AI Levels）

这个横跨两章的用例，清晰而务实地展示了在 Agentic AI Levels 最高层级中的演进之旅——不仅说明每个层级“是什么”，更解释了为什么这种逐级演进对企业成功至关重要。

Level 3：能力强但脆弱的单体（The capable but brittle monolith）

我们最初构建的单智能体系统，是典型的 Level 5 系统。在这一阶段，组织达成了一个重要里程碑：拥有一个能够端到端执行复杂业务流程的自治智能体。

我们在第 13 章构建的 LoanProcessing 智能体，能够成功完成文档校验、征信查询、风险评估与合规检查，从而交付真实的业务价值。然而，它的单体特性——把所有认知负载、业务逻辑与工作流控制都集中在一个庞大的提示词里——会引入显著的生产级挑战。

这种集中式设计会让系统天然“脆”：提示词中某一处很小的逻辑错误，可能对整个工作流产生意外的连锁影响。此外，随着业务流程演进，维护并更新这个复杂的单一“大脑”会越来越困难且风险越来越高，从而限制系统的长期可扩展性。

Level 4：具韧性的协作团队（The resilient, collaborative team）

我们在本章构建的层级化多智能体系统，是 Level 4 系统的直接实现。从 Level 3 跃迁到 Level 4 并不仅仅是“多加几个智能体”；它是一次以**问题分解（problem decomposition）**为核心原则的根本性架构转变。

我们把一个复杂的大问题拆成一系列更小、更简单的任务，然后构建了一支高度专业化的专家智能体团队——每个智能体都只负责把一件事做到极致。这相当于从“一个卓越的全才”转变为“一个协调配合的专家团队”的智能体工程等价形态。

正是这种架构演进，解锁了真正的企业级能力。系统的韧性显著增强：某个专家智能体发生故障时，故障被隔离在局部，supervisor 可以优雅地处理，而不会拖垮整个流程。

系统也更易维护：风险评估的业务逻辑可以在其专属智能体内部更新，而不会有影响征信流程的风险。更重要的是，它更可扩展——不仅是技术意义上的扩展，也是认知意义上的扩展。通过分摊认知负载，这种 Level 4 架构能够应对更高阶、更复杂的问题，构建出远超任何单一智能体所能达到的能力系统。

从“亲自做事者（doer）”转变为“管理专精工人的经理（manager of specialized workers）”，是 Level 4 的决定性特征，也是我们 Agentic AI Levels 中的巅峰。

超越 Level 4：智能体协作的未来（Beyond Level 4: The future of agentic collaboration）

尽管我们的 Level 4 层级化系统代表了当前生产级智能体应用的最先进形态，但旅程并未止步于此。我们已经构建的模式与架构，是更动态系统的地基。我们很快会看到 Level 5 系统利用元智能体（meta-agents）实现实时任务重分配；但智能体 AI 的终极未来，属于那些能够自组织、自改进，甚至能参与自身经济体系的系统。

设想一个以涌现群体（emergent swarms）为特征的未来 Level 6 系统。在这一范式中，没有固定的 supervisor。相反，一组专门化智能体可以接收一个复杂且新颖的问题，并自治地临时组建一支团队来解决它。例如在复杂的公司贷款重组场景中，一个规划智能体可能临时担任领导者，招募一个数据分析智能体来建模现金流预测，再招募一个报告智能体来汇总法律风险，形成一个临时层级结构；当重组方案完成后，这个结构随即解散。

如果把视野进一步推进到 Level 6 的更远处，我们会看到自我改进的智能体系统：一个贷款处理器不仅处理申请，还会分析自身表现。它可能识别出 risk_assessor 专家经常成为瓶颈，并提出改进建议；甚至尝试重写底层工具代码以提升效率。它也可能对不同版本的提示词自行做 A/B 测试，以在准确率与成本之间实现最优。

这会让系统从“执行”迈向一种持续的、自治的、自我校正优化状态——我们会在本书最后部分进一步展开这一概念。未来这些层级将依赖行业标准的通信协议，以实现流畅而可靠的交互。Agent-to-Agent（A2A）协议如今已成为 Linux Foundation 旗下的官方项目，为这种互操作性提供经认证的标准。在跨行业指导委员会的治理下，A2A 允许智能体在不受底层框架限制的情况下完成发现、协商与协作。正是这种形式化标准化，才能支撑一个真正的“智能体经济”：智能体能够发现、招募并协同解决我们才刚刚开始想象的规模级问题。

下面我们来回顾本章所覆盖的内容。

总结（Summary）

在本章中，我们把设计模式与架构理论真正落到了实处，最终构建出一个用于贷款处理的复杂多智能体系统。通过从抽象概念走向可运行的实现，我们现在可以梳理这次转变带来的关键经验要点：

  • 从单体到智能体团队：
    我们的旅程始于一个能力强但脆弱的 Level 3 单体智能体。我们有意暴露其架构弱点（故障隔离差、可维护性困难），以此驱动向 Level 4 多智能体系统的演进。从“单个执行者”转变为“管理一组专精智能体的管理者”，是最高层级智能体成熟度的决定性特征。
  • 模式是成功的蓝图：
    我们亲眼见证了多种设计模式组合如何共同塑造一个既鲁棒又智能的系统。Supervisor（Orchestrator）架构提供了整体结构，而 Agent Delegates to Agent 模式是其主要运行机制。Orchestrator 的认知过程由 FCoT 模式治理，并通过显式的数据契约实现高效与可靠。
  • 实现可用于生产的韧性：
    最终的多智能体系统展现了真正的企业级特质。它通过将故障隔离在各个专家智能体内部并进行优雅处理来实现容错；其模块化设计支持每个智能体的专业能力被独立开发与维护；最后，系统还能为决策给出清晰、逐步的理由说明，从而满足对**可解释性（Explainability）与审计轨迹（Audit Trail）**的关键需求。
  • Agentic AI 是一门软件工程学科：
    该用例表明，优秀的软件架构原则可以直接迁移到 agentic AI 的世界。通过应用经过验证的问题分解与关注点分离模式，我们构建的系统不仅“聪明”，而且具备韧性、可扩展性，并能应对现实世界的复杂性。

我们在构建这个 Level 4 系统的过程中，获得了一个强大而务实的基础。在本书的最后部分，我们将以此为起点，进一步探讨持续改进与治理等关键主题——这些主题对于高级 agentic 系统的长期成功与负责任部署至关重要。

现在，我们已经对“构建这些高级 agentic 系统”意味着什么有了清晰理解，接下来必须把注意力转向支配其使用的关键原则。
在下一章中，我们将探讨确保我们构建的系统不仅强大，而且安全、公平、可信所必需的框架。

avatar
文章
阅读
粉丝