建构 AI Agent 应用——智能体系统设计

设计智能体系统

大多数从业者在构建智能体系统时，并不会先写一份宏大的设计文档。他们通常从一个杂乱的问题、一个基础模型 API 密钥，以及一个也许能奏效的粗略想法开始。本章是一份快速入门，帮助你立刻上手。书的其余部分会对下面各主题做更深入的讲解，很多主题甚至会独立成章；而本章将以电商平台客服这一具体示例为基础，给出设计智能体系统的全貌。

我们的第一个智能体系统（Our First Agent System）

先从要解决的问题讲起。每天，你的客服团队都会收到几十甚至上百封邮件：申请为破损的杯子退款、取消尚未发货的订单，或变更收货地址。每封邮件都需要人工客服去读自由文本、在后端查询订单、调用相应API，再回一封确认邮件。这个重复的两分钟流程非常适合自动化——前提是我们把边界切得合适。只要意识到人类是在按规则/指南敲键盘、点按钮，就会看到：这些模式很多都能由基于基础模型的、精心设计的系统来完成。

我们希望智能体接收原始的客户消息 + 订单记录，决定调用哪一个工具（issue_refund、cancel_order 或 update_address_for_order），以正确参数调用该工具，然后发送简短确认。这个两步工作流足够聚焦（便于快速构建）、足够有价值（释放人力）、也足够智能（能展示智能行为）。用下面几行代码，我们就能为这个用例做出一个可运行的智能体：

from langchain.tools import tool
from langchain_openai.chat_models import ChatOpenAI
from langchain.schema import SystemMessage, HumanMessage, AIMessage
from langchain_core.messages.tool import ToolMessage
from langgraph.graph import StateGraph

# -- 1) 定义唯一的业务工具
@tool
def cancel_order(order_id: str) -> str:
    """取消尚未发货的订单。"""
    # （这里应调用你的真实后端 API）
    return f"Order {order_id} has been cancelled."

# -- 2) 智能体“大脑”：先调用 LLM，若需则运行工具，再调用 LLM 生成确认
def call_model(state):
    msgs = state["messages"]
    order = state.get("order", {"order_id": "UNKNOWN"})

    # 系统提示：明确告知模型要做什么
    prompt = (
        f'''You are an ecommerce support agent.
        ORDER ID: {order['order_id']}
        If the customer asks to cancel, call cancel_order(order_id) 
        and then send a simple confirmation.
        Otherwise, just respond normally.'''
    )
    full = [SystemMessage(prompt)] + msgs

    # 第一次 LLM 调用：判断是否需要调用工具
    AIMessage = ChatOpenAI(model="gpt-5", temperature=0)(full)
    out = [first]

    if getattr(first, "tool_calls", None):
        # 运行 cancel_order 工具
        tc = first.tool_calls[0]
        result = cancel_order(**tc["args"])
        out.append(ToolMessage(content=result, tool_call_id=tc["id"]))

        # 第二次 LLM 调用：生成最终确认文本
        AIMessage = ChatOpenAI(model="gpt-5", temperature=0)(full + out)
        out.append(second)

    return {"messages": out}

# -- 3) 用 StateGraph 组装起来
def construct_graph():
    g = StateGraph({"order": None, "messages": []})
    g.add_node("assistant", call_model)
    g.set_entry_point("assistant")
    return g.compile()

graph = construct_graph()

if __name__ == "__main__":
    example_order = {"order_id": "A12345"}
    convo = [HumanMessage(content="Please cancel my order A12345.")]
    result = graph.invoke({"order": example_order, "messages": convo})
    for msg in result["messages"]:
        print(f"{msg.type}: {msg.content}")  

很好——你已经拥有一个可用的“取消订单”智能体了。在扩展之前，先想想为什么我们从这样一个小切片开始。划定范围永远是权衡：切得太窄（只做取消）会错过退款、改地址等高频需求，现实价值受限；切得太宽（“自动化所有客服请求”）又会被账单纠纷、商品推荐、技术排障等边界情况淹没；若目标太虚（“提升客户满意度”），你也很难判断成功的时刻。

反之，专注于清晰、封闭的工作流（取消订单），就能确保输入具体（客户消息 + 订单记录）、输出结构化（工具调用 + 确认）、并具备紧闭环。例如，一封邮件写着：“请取消订单 #B73973，因为我找到了更便宜的。”人工会查订单、确认未发货、点“取消”，再回一封确认。转成代码，就是调用 cancel_order(order_id="B73973")，然后把一条简明确认发给客户。

现在有了一个能运行的“取消订单”智能体，下一个问题是：它真的好用吗？在生产里，我们不只关心“能跑”，还关心效果如何、对在哪、错在哪。对本例来说，我们关注：

• 有否调用正确的工具（cancel_order）？
• 是否传入正确参数（正确的订单号）？
• 是否向客户发送了清晰、正确的确认信息？

在我们的开源仓库里，你会找到完整评测脚本来自动化这一流程：

• 评测数据集
• 批量评测脚本

下面是一个极简版本，展示如何直接测试你的智能体：

# 极简评测检查
example_order = {"order_id": "B73973"}
convo = [HumanMessage(content='''Please cancel order #B73973. 
    I found a cheaper option elsewhere.''')]
result = graph.invoke({"order": example_order, "messages": convo})

assert any("cancel_order" in str(m.content) for m in result["messages"], 
    "Cancel order tool not called")
assert any("cancelled" in m.content.lower() for m in result["messages"], 
    "Confirmation message missing")

print("✅ Agent passed minimal evaluation.")

这段代码确保调用了工具且发出了确认。当然，真实评测会更深入：可在上百个样本上度量工具精准率、参数准确率与整体任务成功率，提前捕捉边界情形。第 9 章我们会系统讨论评测策略与框架；但请记住：未被测试的智能体，不值得信任。

由于这两个步骤都通过 @tool 装饰器自动化了，针对真实工单编写测试几乎不费力——而且你能立刻得到可度量的指标（工具召回、参数准确、确认质量）。现在我们已构建并评测了一个最小可用智能体，接下来看看决定其能力与影响的核心设计抉择。

智能体系统的核心组件（Core Components of Agent Systems）

要设计一个高效的智能体系统，需要深入理解那些支撑智能体成功履职的核心组件。每个组件都会影响智能体的能力、效率与适应性。从选择合适的模型，到为智能体配备工具、记忆与规划能力，这些要素必须协同，以便在动态而复杂的环境中运行。本节聚焦三个关键组件——基础模型、工具、记忆——并探讨它们如何交互，形成一个内聚的智能体系统。图 2-1展示了智能体系统的核心组件。

图 2-1. 智能体系统的核心组件。

模型选择（Model Selection）

每个基于智能体的系统的核心，都是驱动其决策、交互与学习的模型。模型选择是基础性决策：它决定智能体如何理解输入、生成输出并适应环境，也深刻影响性能、可扩展性、时延与成本。恰当的选择取决于任务复杂度、输入数据特性、基础设施约束，以及通用性-速度-精度之间的权衡。

粗略说，模型选择从任务复杂度评估开始。大型基础模型（如 GPT-5 或 Claude Opus 4.1）适用于开放式环境中的智能体：需要细腻理解、灵活推理与创造性生成。它们在存在歧义、情境细节或多步骤的任务上表现出色。但代价是：需要可观算力、往往依赖云基础设施，并引入更高时延。它们最适合个人助理、研究智能体或企业级系统等需要处理广泛不可预测查询的应用。

相较之下，小型模型（如蒸馏的 ModernBERT 变体或 Phi-4）更适合定义清晰、重复性强的任务。它们在本地硬件上高效运行、响应迅速、部署维护成本低。面向客服、信息检索、数据标注这类结构化场景，所需是精确性而非创造性/灵活性时，小模型更合适。当实时性或资源约束关键时，小模型反而因为务实而胜出。

模态（modality）也愈发重要。如今的智能体往往需要处理文本 + 图像/音频/结构化数据。多模态模型（如 GPT-5、Claude 4.1）能联合理解文本、视觉、语音等多种数据，扩展了在医疗、机器人、客服等领域的适用性；这些领域的决策依赖于多形态输入的整合。相对地，纯文本模型仍非常适合语言驱动的用例，在额外模态价值不大的场景中，复杂度更低、推理更快。

另一个关键考量是开放性与可定制性。开源/开放权重模型（如 Llama、DeepSeek）为开发者提供透明度与微调/改动自由，这对隐私敏感、受监管或强领域应用尤其重要。它们可以在私有基础设施上托管，面向独特用例裁剪部署，无需许可费用——但需要更多工程投入。与之对照，专有模型（如 GPT-5、Claude、Cohere）通过 API 提供强大能力，并附带托管基础设施、监控与性能优化。这类模型适合寻求快速开发/部署的团队，但定制空间有限，且成本随用量上升。

至于通用预训练模型 vs 自定义训练模型：取决于领域的特异性与风险等级。基于互联网规模语料预训练的通用模型非常适合快速原型与对领域精度要求不高的场景；往往只需少量微调或提示工程就能达到不错的效果。而在医学、法律、技术支持等专门领域，自定义训练可带来显著优势：用经过甄选的领域数据训练，能赋予更深的专业知识与情境理解，输出更准确可靠。

成本与时延往往决定现实部署的取舍。大模型性能高，但运行贵且响应慢；难以接受时，小模型或大模型的压缩版本更均衡。很多团队采用混合策略：用强模型处理最复杂的请求，用轻模型处理常规任务；有的系统做动态路由，按请求的复杂度/紧急度选择模型，从而同时优化成本与质量。

斯坦福“基础模型研究中心”推出了 HELM（Holistic Evaluation of Language Models） ，为多种模型提供第三方的系统测评。表 2-1展示了一小部分语言模型在 MMLU 基准上的表现（该基准常用于模型能力的通用评估）。这些指标并不完美，但提供了一个可对比的尺子。总体看，更大的模型通常表现更好，但并非线性（有的模型小而强）。要实现高性能，通常需要显著更多的算力。

表 2-1. 部分开放权重模型的性能与规模

模型	维护方	MMLU	参数量（十亿）	显存（全精度，GB）	参考硬件
Llama 3.1 Instruct Turbo	Meta	56.1	8	20	RTX 3090
Gemma 2	Google	72.1	9	22.5	RTX 3090
NeMo	Mistral	65.3	12	24	RTX 3090
Phi-3	Microsoft	77.5	14.7	29.4	A100
Qwen1.5	Alibaba	74.4	32	60.11	A100
Llama 3	Meta	79.3	70	160	4×A100

反过来，这意味着：中等性能可以用很少一部分成本获得。如表 2-1 所示，大约14B 参数以内的模型，通常可在一块消费级 GPU（如 24GB 显存的 RTX 3090）上运行；超过这个门槛，往往需要服务器级 GPU（如 A100 40GB/80GB）。当模型的架构与权重向公众开放时，我们称为开放权重——任何有相应硬件的人都可加载推理，无需付费访问。我们不会深入硬件选型，但这些开放权重小模型展示了不同规模-性能的组合，而且仍在快速进步：把越来越多的智能装进更小的体量。它们也许不适合你最难的任务，却能以极低价格胜任简单/常规工作。对本文的电商客服智能体，一个小而快的模型就够；若扩展到商品推荐或基于情绪的升级，更大的模型能释放新能力。

接下来看看几款大型旗舰模型。需要注意：其中 DeepSeek-v3 与 Llama 3.1 Instruct Turbo 405B是开放权重，其余不是。一般而言，这些大模型要想达到合理性能，至少需要12 块 GPU，甚至更多；几乎总是在大型数据中心的服务器上使用。通常，模型提供方按输入/输出 token 数计费。好处是开发者无需操心服务器与 GPU 利用率，能直接开干。表 2-2给出了它们在相同 MMLU 基准上的成本与性能。

表 2-2. 部分大型模型的性能与成本

模型	维护方	MMLU	相对价格/百万输入 token	相对价格/百万输出 token
DeepSeek-v3	DeepSeek	87.2	2.75	3.65
Claude 4 Opus Extended Thinking	Anthropic	86.5	75	125
Gemini 2.5 Pro	Google	86.2	12.5	25
Llama 3.1 Instruct Turbo 405B	Meta	84.5	1	1
o4-mini	OpenAI	83.2	5.5	7.33
Grok 3	xAI	79.9	15	25
Nova Pro	Amazon	82.0	4	5.33
Mistral Large 2	Mistral	80.0	10	10

表 2-2 中的价格以 Llama 3.1 的百万 token 价格为基准倍数（其为最便宜者）。写作时，Meta 对输入 token定价 $0.20/百万**、对**输出 token**定价 **$0.60/百万。你也会注意到：性能并不与价格严格相关。基准能提供有用指导，但与你的具体任务匹配度因场景而异。尽可能用你的任务去对比模型，找到性价比最优者。

归根结底，模型选择不是一次性决定，而是一项需要随着智能体能力、用户需求与基础设施演进而反复权衡的战略设计。开发者必须在通用 vs 专用、性能 vs 成本、简洁 vs 可扩展之间做取舍。通过审慎考量任务复杂度、输入模态、运行约束与定制需求，团队就能选出既高效行动、又可靠扩展、并能在真实世界中精准表现的模型。

工具（Tools）

在基于智能体的系统中，工具是使智能体能够执行特定动作或解决问题的基础能力。工具构成了智能体的功能“积木”，赋予其执行任务、与用户及其他系统交互的能力。一个智能体的有效性，很大程度取决于其工具的范围与复杂度。

为特定任务设计能力（Designing Capabilities for Specific Tasks）

工具通常围绕智能体要解决的任务来定制。设计工具时，开发者需要考虑智能体在不同条件与语境下将如何表现。良好的工具集能确保智能体以精准且高效的方式处理多样任务。工具可分为三个主要类别：

本地工具（Local tools）

这类工具基于内部逻辑与计算执行动作，不依赖外部系统。常见形态包括基于规则或预定义函数的执行。示例：数学计算、从本地数据库取数、或基于既定标准做出简单决策（如依据阈值决定是否审批一个请求）。

基于 API 的工具（API-based tools）

这类工具让智能体与外部服务或数据源交互。借助它们，智能体可走出本地环境，获取实时数据或利用第三方系统。例如，虚拟助手可以通过 API 获取天气、股票或社交媒体更新，从而对用户查询给出更有情境、更相关的回复。

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

基于 MCP 的工具让智能体以标准化模式向语言模型提供结构化、实时的上下文——这是一种把外部知识、记忆与状态注入到模型提示中的通用架构。与传统 API 需要全往返执行不同，MCP 允许智能体将用户画像、会话历史、世界状态或任务元数据等丰富动态的上下文直接注入模型的推理过程，而无需另行调用工具。它对减少冗余工具调用、保持会话状态、并为模型注入实时态势感知尤为有效。

小结：本地工具使智能体可依靠内部逻辑独立完成计算或本地取数；API 工具让智能体连接外部服务，获取实时数据或对接第三方系统，从而扩展功能并生成更具情境的响应。

工具集成与模块化（Tool Integration and Modularity）

模块化设计对工具开发至关重要。每个工具都应设计为自包含模块，可按需容易集成或替换。这样开发者就能在无需重构整个系统的前提下，更新或扩展智能体能力。比如，一个客服聊天机器人可以先以处理简单问答的基础工具上线，随后再无缝加入诸如纠纷处理、高级排障等复杂工具，而不干扰核心运行。

记忆（Memory）

记忆是让智能体能够存储与检索信息的关键组件，使其得以保持上下文、从历史交互中学习，并随着时间推移改进决策。有效的记忆管理可确保智能体在动态环境中高效运作，并基于历史数据适应新情境。第 6 章将对记忆进行更深入的讨论。

短期记忆（Short-Term Memory）

短期记忆指智能体存储与当前任务或对话直接相关信息的能力。它帮助智能体在交互期间维持上下文，从而实时做出连贯决策。比如，一个客服智能体若能在同一会话中记住用户之前的问题，就能提供更准确、更具上下文的回复，提升体验。

短期记忆常通过**滚动上下文窗口（rolling context windows）**实现：保留近期信息的滑动窗口，同时丢弃过时内容。这对聊天机器人或虚拟助手尤为有用——它们需要记住最近交互，但可以忘记更早、已无关的细节。

长期记忆（Long-Term Memory）

长期记忆则用于在更长时间跨度内存储知识与经验，使智能体能够借鉴过去信息来指导未来行为。这对需要长期改进或基于用户偏好提供个性化体验的智能体尤为重要。

长期记忆常以数据库、知识图谱或微调模型等形态实现。它们可存储结构化数据（如用户偏好、历史绩效指标）并在需要时检索。例如，健康监测智能体可保存患者的长期生命体征数据，从而发现趋势或向医护人员提供历史洞察。

记忆管理与检索（Memory Management and Retrieval）

有效的记忆管理要求对存储数据进行组织与索引，以便在需要时快速检索。依赖记忆的智能体必须能区分相关与无关信息，并以足够快的速度取回所需内容，以保证流畅表现。在某些情况下，智能体还需要遗忘部分信息，以避免过时或无用数据挤占记忆空间。

例如，一个电商推荐智能体需要保存用户偏好与历史购买记录以提供个性化推荐；但它也必须优先考虑近期数据，以便在用户偏好随时间变化时，仍能保持推荐的相关性与准确性。

编排（Orchestration）

编排把彼此孤立的能力串接成端到端方案：它是那层组合、调度与监督一系列技能的逻辑，使每一步动作顺畅衔接并朝着清晰目标推进。从本质上讲，编排会评估可能的工具/技能调用序列、预测其可能结果，并在多步骤任务中选择最有成功概率的路径——无论是规划一条在交通、时间窗与车辆可用性间权衡的最优配送路线，还是组装一条复杂的数据处理流水线。

由于现实条件可能瞬息万变——新信息到来、优先级改变、资源不可用——编排器必须持续监控进度与环境，并在需要时暂停或改道，以保持在正确轨道上。许多场景中，智能体会增量式地制定计划：先执行若干步，再基于新结果复盘并更新后续流程。比如，一个对话式助理可能在规划下一步前，先确认每个子任务的结果，从而动态调整执行顺序，以确保响应性与稳健性。

没有稳固的编排层，即便最强的技能也可能相互掣肘或陷入停滞。我们将在第 5 章深入探讨构建弹性且灵活的编排引擎的模式、架构与最佳实践。

设计取舍（Design Trade-Offs）

设计基于智能体的系统，必须在性能、可扩展性、可靠性与成本之间取得平衡。这些取舍要求开发者做出将显著影响真实环境表现的战略性决策。本节聚焦关键取舍，并给出应对思路。

性能：速度 / 准确性的取舍（Performance: Speed/Accuracy Trade-Offs）

核心取舍之一是速度与准确性的平衡。高性能让智能体能快速处理信息、做决策、执行任务，但可能以精度为代价；反之，追求高精度（复杂模型、重计算技术）往往会降速。

在实时场景（如自动驾驶或交易系统）中，毫秒之间可能决定成败；此时为确保及时响应，可能需要优先速度。而在法律分析或医疗诊断等任务中，高精度更重要，适当牺牲速度以保证可靠性是可以接受的。

一种有效的混合策略是：先给出快速的近似答案，随后以更准确的跟进来细化。这在推荐系统或诊断中很常见：先给出快速建议，再用更多时间与数据进行验证与改进。

可扩展性：为智能体系统工程化扩展（Scalability: Engineering Scalability for Agent Systems）

现代智能体系统（尤其重度依赖深度学习与实时处理者）的可扩展性是重大挑战。随着系统在复杂度、数据量与并发任务上的增长，如何管理算力资源（尤其 GPU）变得至关重要。GPU 是大模型训练与推理的加速基石；要实现高效扩展，必须精心工程化，避免瓶颈、低利用率与成本攀升。以下是通过优化 GPU 资源与架构来有效扩展的策略：

• 动态 GPU 分配：按实时需求分配 GPU，而非静态绑定到智能体/任务；只在必要时占用 GPU，减少空转，提升利用率。
• 弹性供给（Elastic GPU Provisioning） ：使用云服务或本地 GPU 集群，依据当前负载自动扩缩资源。
• 优先级队列与智能调度：高优先级任务即时获得 GPU，低优先级任务在峰值期排队，平衡吞吐与体验。
• 异步任务执行：并行处理 GPU 任务，不必等待前一任务完成，最大化利用率并减少空闲间隔。
• 动态负载均衡：在多 GPU 之间调度任务，避免单卡成为瓶颈，充分利用未饱和的资源。
• 分布式/多 GPU 并行与推理：不仅是“加卡”，而是通过并行与分布式设计确保新增 GPU 可被有效利用。
• 水平扩展（Horizontal Scaling） ：在集群中增加 GPU 节点，以承担实时推理或训练等高吞吐任务。
• 混合云与突发扩容（Burst Scaling） ：本地 + 云 GPU 组合；在峰值将任务暂时外包到云端，需求回落即释放，避免长期资本开支。
• 离峰时段的云实例：在低需求、价格更优的时段运行任务，显著降低成本，同时保有需要时的快速扩容能力。

要有效扩展依赖 GPU 的系统，远非“堆更多 GPU”即可；关键在于让资源真正跑满，并使系统能随需求高效扩展。

可靠性：确保稳健、一致的智能体行为（Reliability: Ensuring Robust and Consistent Agent Behavior）

可靠性指智能体能够长期一致、准确地完成任务。可靠的智能体应能在可预期与不可预期条件下不失效，赢得用户与干系人的信任。但提高可靠性通常会增加系统复杂度、成本与开发时间。

容错性（Fault tolerance）
让智能体在错误或意外事件下不崩溃或异常至关重要。这需要构建故障检测与优雅恢复机制（如应对网络中断、硬件故障）。常见做法包括冗余——复制关键组件/流程，以确保局部故障不影响整体。

一致性与稳健性（Consistency and robustness）
智能体需在不同场景、输入与环境下表现一致，尤其是安全关键系统（自动驾驶、医疗）。开发者必须保证不仅在理想条件下表现良好，也能经受边界条件、压力测试与真实约束。达成可靠性通常依赖于：

• 广泛测试：单元、集成与贴近真实的仿真测试；覆盖边界、意外与对抗性输入。
• 监控与反馈回路：生产环境的持续监控以发现异常，并通过反馈持续改进，增强稳健性。

成本：在性能与开销间取得平衡（Costs: Balancing Performance and Expense）

成本常被忽视，却是智能体系统设计中的关键取舍。开发、部署与运维成本必须与预期价值与 ROI相衡量，并影响围绕模型复杂度、基础设施与扩展性的决策。

开发成本（Development costs）
复杂智能体的开发成本高：先进模型需要大数据集、专业人才与算力；而迭代式设计、测试与优化进一步推高成本。高性能系统往往需要数据科学家、ML 工程师与领域专家等复合团队，并需大量测试基础设施（仿真环境、测试工具与框架）。

运营成本（Operational costs）
上线后，运行成本可能可观，尤其是实时决策或持续数据处理的系统：

• 算力成本：深度学习推理/算法依赖的 GPU 或云服务昂贵。
• 数据流量与存储：大数据处理与大记忆带来更高的存储与带宽成本。
• 日常维护：缺陷修复、功能改进与可靠性保障也需要持续投入。

成本 vs 价值（Cost versus value）
最终，系统成本必须被其带来的价值所证明。对非关键任务，可优先选择更便宜、简单的智能体；对关键任务，再投入更复杂的方案。常见优化策略包括：

• 精益模型（Lean models） ：在合适场景用更简单、高效的模型，降低开发与运维成本；若规则系统能达类似结果，就不必上深度学习。
• 云资源：以云计算降低前期投入，实现按需计费、弹性扩展。
• 开源模型与工具：利用开源库/框架降低软件成本，同时仍可构建高质量系统。

设计智能体系统就是在多重取舍间权衡：为性能可能牺牲部分准确性；扩展到多智能体架构会引入协同与一致性的新挑战；确保可靠性要求严格测试与监控，但也会拉长周期、增加复杂度；最后，必须从开发与运维两端纳入成本考量，确保系统在预算内创造价值。下一节，我们将回顾构建高效智能体系统时最常见的设计模式。

架构设计模式（Architecture Design Patterns）

基于智能体系统的架构设计，决定了智能体如何被组织、如何与环境交互、以及如何执行任务。架构选择会影响系统的可扩展性、可维护性与灵活性。本节探讨三类常见的设计模式——单智能体架构与多智能体架构——并讨论其优势、挑战与适用场景。第 8 章将做更详尽的展开。

单智能体架构（Single-Agent Architectures）

单智能体架构是最简单直接的设计之一：由一个智能体负责系统中的全部任务。该智能体直接与环境交互，独立完成决策、规划与执行，不依赖其他智能体。

这种架构非常适合定义明确、范围狭窄的任务，工作负载可由单体承担。其简单性意味着易于设计、开发与部署，避免了多组件之间的协同、通信与同步复杂度。面对不需要协作或分布式努力的窄域任务，单智能体表现突出，例如：处理基础客户咨询（FAQ、订单跟踪）的简单聊天机器人，或面向数据录入/文件管理的特定任务自动化。

当问题域清晰、任务直观且无需显著扩展时，单智能体配置能很好地工作——适用于客服机器人、通用助理、代码生成智能体等。关于单/多智能体架构，我们将在第 8 章继续深入。

多智能体架构：协作、并行与协调（Multiagent Architectures: Collaboration, Parallelism, and Coordination）

在多智能体架构中，多个智能体协同以实现共同目标。根据任务性质，智能体可独立运行、并行执行，或通过协调合作。多智能体常用于复杂环境：任务的不同方面需要专门化智能体管理，或通过并行处理提升效率与可扩展性。其主要优势包括：

• 协作与专门化
  每个智能体可专注于特定子任务/领域。例如：一个负责数据采集，另一个处理数据，第三个面向用户交互。分工使系统比单体更高效地处理复杂任务。
• 并行性
  可同时执行多项任务。例如物流系统中，不同智能体并行规划不同路线，缩短整体处理时间、提升效率。
• 更好的可扩展性
  随系统增长，可引入更多智能体分担任务或分配负载，使系统能管理更大、更复杂的环境。
• 冗余与韧性
  多个智能体独立运行，单个失效不必然导致系统崩溃；其他智能体可继续工作，甚至接管失效者职责，提升整体可靠性。

同时，多智能体也带来显著挑战：

• 协调与通信
  管理智能体间通信较为复杂。它们必须高效地交换信息并协调行动，以避免重复劳动、冲突操作或资源争用。缺少恰当的编排，多智能体容易无序低效。
• 复杂度提升
  需要通信协议、协同策略、同步机制等，令设计、开发与维护更具挑战。
• 效率下降的风险
  并非总是如此，但多智能体为完成任务往往需要更高的 token 消耗：频繁的沟通、上下文共享与动作协调会占用更多算力与资源；若通信/协调未优化，还可能放慢完成速度。因此需精细的资源管理。

多智能体架构适用于任务复杂、分布式或需要跨组件专门化的环境。在金融交易系统、网络安全调查、协作式 AI 研究平台等场景中，多个智能体共同解决复杂的分布式问题。

小结：单智能体简单，适合定义良好的任务；多智能体带来协作、并行与可扩展性，适合复杂环境。选型取决于任务复杂度、扩展需求与系统寿命。下一节将介绍一些可帮助我们从智能体系统中获得最佳效果的原则。

最佳实践（Best Practices）

设计智能体系统不只是选对模型、技能与架构。要确保系统在真实环境中最佳表现并能随环境演进持续进化，需要在整个开发生命周期中遵循最佳实践。本节强调三项关键实践：迭代式设计、评测策略、真实环境测试，以打造可适应、高效、可靠的智能体系统。

迭代式设计（Iterative Design）

迭代式设计强调增量构建 + 持续吸收反馈。与其试图一次构建“完美方案”，不如先做好小而用的原型，在多轮迭代中评估、改进与打磨。其好处包括：

• 早发现问题：尽早发布原型，有助于在问题“固化”前发现设计缺陷与性能瓶颈，迅速修复，减少长期成本与大改动。
• 以用户为中心：频繁收集干系人/终端用户/开发者反馈，确保系统持续对齐真实需求；在真实场景中试用，迭代优化行为与响应。
• 可扩展成长：从 MVP/基础智能体起步，系统可渐进式增长；每个新功能在全面上线前都可充分验证。

实践要点：

• 快速做原型：先实现核心价值点，别追求完美。
• 测试并收集反馈：每次迭代后聚合反馈，为下轮迭代确定优先级。
• 反复打磨：基于数据与反馈持续改进，直至满足性能、可用性与可扩展目标。

评测策略（Evaluation Strategy）

评估智能体的性能与可靠性是开发流程的关键。健全的评测要覆盖多维度：准确性、效率、稳健性、可扩展性，并以系统化方式验证智能体在不同条件下的表现（第 9 章将更深入）。

• 功能性测试：逐一验证每个技能/模块在不同输入与场景下是否按预期工作。关注：

  • 正确性：输出与设计预期一致且稳定。
  • 边界测试：在极端/异常输入（大数据量、罕见查询、歧义指令）下的表现。
  • 任务特定指标：如法律/医疗等领域需满足合规与精度要求。

• 泛化能力：尤其对基于 ML 的智能体，需验证其超出训练分布时仍能保持准确与可靠。通用型或运行于动态环境的智能体尤需如此。

• 用户体验评估：不只看技术指标，还要评估是否满足真实应用中的用户期望。

  • 用户满意度：NPS、CSAT 等。
  • 任务完成率：低完成率可能暴露设计混乱或低效。
  • 显式信号：点赞/点踩、星级、接受/拒绝/修改结果等反馈入口。
  • 隐式信号：从交互日志分析误解点、延迟、情绪、失当回复等。

• 人参与验证（Human-in-the-loop） ：在可能情况下引入领域专家抽检，校验正确性、伦理合规、最佳实践对齐，并用结果标定与改进自动化评估。

• 端到端环境评测：在贴近真实的全链路环境中（数据摄取→处理→执行→产出）进行测试，确保跨系统/数据源/平台的整体一致性。

真实环境测试（Real-World Testing）

在可控开发环境中构建/初测固然关键，但同样需要在真实环境下验证，确保智能体与实际用户/场景交互时表现如预期。真实环境测试能暴露开发阶段难以显现的问题，评估稳健性、可靠性与用户影响：

• 暴露真实复杂性：真实世界动态多变、用户多样、边界层出；测试可验证智能体能否应对真实复杂度与变异性。
• 发现边界情形：脚本化测试往往覆盖不全；真实交互能暴露未预料输入、歧义问题、语言多样性等。
• 评估负载表现：观察在高并发/高流量下的表现，尤其适用于客服机器人、电商推荐等波动场景。

落地方法：

• 分阶段发布：从小范围试点逐步扩大，渐进式定位并修复问题。
• 监控行为：以监控工具跟踪响应时间、准确率、满意度、稳定性等 KPI。
• 收集用户反馈：组织用户回访，定位可用性问题与需求落差。
• 基于洞见迭代：将实测洞见回灌到开发周期，持续优化能力与体验。

遵循迭代设计、完善评测与真实环境测试等最佳实践，能构建可适应、可扩展、具韧性的智能体系统。通过在开发全周期内贯彻这些做法，开发者可以打造更可靠、高效、有效的系统，使其在动态环境中持续发挥价值。

结论（Conclusion）

要开始构建一个优秀的智能体系统，你并不需要一份 30 页的计划——但适度的前瞻能事半功倍。正如电商客服智能体的案例所示，选择一个可落地的切片（例如“取消订单”）就能让你构建出小而可测且立刻有用的功能。明确成功的标准，避免目标含糊或范围失控，并专注于尽快交付清晰价值。

高效的智能体系统并非“部件之和”。它们依赖扎实的架构、严格的工程实践与紧密的反馈闭环。选择合适的结构模式为可扩展性与韧性奠定基础；而迭代式开发与稳健评测则确保你的智能体随时间持续改进。诸如分阶段发布与真实环境测试等最佳实践，能把一个看似有前景的原型——比如我们那个简单的“取消订单”智能体——打磨成可在生产中信赖的系统。

在第 3 章，我们将把焦点转向以人为本的一面——如何为依赖这些系统的人们设计清晰、响应迅速、直观易用的智能体体验。归根结底，无论你的系统架构多么强大，其成败取决于它如何被人所用。