Agent 的架构、多智能体与落地：从 Demo 到生产系统

本文是「Agent 基本概念」系列第五篇，也是最后一篇。

前四篇分别讲了 Agent 是什么 、由哪些组件构成 、如何决策与规划 、记忆与工具 。这一篇回答最后一个问题：如何把 Agent 从 Demo 变成生产系统。

系列规划：① 什么是 AI Agent → ② 核心组件 → ③ 决策与规划 → ④ 记忆与工具 → ⑤ 架构与落地。

前言：Demo 跑通一次就够了，生产系统要跑一万次

前四篇我们讲的是 Agent 的"能力"。但能力和生产系统之间，隔着一条鸿沟。

一个 Demo 只需要跑通一次。一个生产系统需要：

• 可预测：同样的输入，行为可预测、可审计；
• 可恢复：服务重启后，任务能从中断处继续；
• 可观测：每一步都有日志、有轨迹、能回放；
• 可控制：知道 Agent 执行到哪了、什么时候必须人工介入；
• 可评估：能量化效果，能持续迭代。

打个比方：Demo 就像在空旷的停车场学开车，怎么开都行；生产系统就像在早高峰的市区上路，必须遵守交通规则、有导航、有刹车、有保险。

企业环境中的 Agent 面临的核心挑战正是：执行路径不可预测、状态难以恢复、错误难以追踪、权限控制困难。

这篇文章的主线是：

从单 Agent 架构，到多智能体协作，再到评估体系与落地路线图，给出一个完整的生产级 Agent 路线图。

一、单 Agent 架构：先给 Agent 装上"护栏"

1.1 自由 Agent Loop 的问题

第一篇的伪代码展示了一个最朴素的 Agent 循环：

while not finished:
    response = model(messages)
    if response.tool_calls:
        result = execute_tool(response.tool_calls)
        messages.append(result)
    else:
        finished = True

这种方式最大的优势是灵活，但问题恰恰来自这种自由度。

想象一下：你让 Agent 帮你处理一份合同。它读文件、查数据库、调用审批 API------看起来很顺畅。但服务突然重启了。Agent 不知道任务执行到了哪一步，不知道已经调用了哪些工具，不知道哪些结果已经拿到了。它只能从头再来，或者直接崩溃。

这就是自由 Agent Loop 在生产环境中的典型问题：

维度	自由 Agent Loop	状态机 Agent
下一步由谁决定	模型动态判断	State 和 Edge 限定
执行路径	开放、动态	显式、可预测
中断恢复	需要额外实现	天然适合 Checkpoint
人工审批	需要嵌入 Loop	可以成为正式 Node
适合场景	探索性任务	业务流程

1.2 状态机：给 Agent 装上"流程骨架"

生产级 Agent 的基本设计原则是：状态机负责控制任务如何流转，Agent 负责解决节点内部无法完全写死的智能问题。

用一个生活化的比喻：状态机就像公司的审批流程------请假需要先填单、再主管审批、再 HR 备案，每一步都有明确的先后顺序。Agent 就像每个环节的经办人，负责在给定的步骤内完成具体的智能工作。

以需求分析 Agent 为例，先定义真正影响流程的状态字段：

from typing import TypedDict

class RequirementState(TypedDict):
    raw_requirement: str        # 用户原始需求
    extracted_data: dict        # 已提取的结构化信息
    missing_fields: list[str]   # 仍然缺少什么
    requirements: list[dict]    # 当前生成的需求条目
    quality_score: int          # 当前质量得分
    revision_count: int         # 已经自动修改多少次
    human_decision: str         # 人工最终决策

最大的变化不是多定义了几个变量，而是任务的业务状态被显式建模了。即使模型上下文重新组装，系统仍然知道任务执行到了哪里。

然后把需求分析过程拆成几个职责明确的 Node：extract、check、generate、evaluate、revise、human_review。每个 Node 内部可以自由使用 LLM 推理、RAG 检索、工具调用，但流程的流转由状态机控制。

1.3 LangGraph：让状态机"活"起来

LangGraph 是当前最主流的 Agent 编排框架之一。它的核心思想是：把 Agent 工作流建模为一张图。

LangGraph 的持久化机制（Checkpointer）在每个节点后自动保存状态快照，支持 Human-in-the-loop （人工审核）、Time Travel （回放调试）和 Fault-tolerance（容错执行）。如果某个节点执行失败，可以从上一个成功节点重新开始，不需要重跑已经成功的节点。

1.4 代码示例：一个带人工确认的状态机 Agent

下面是一个简化版的需求审核流程，展示了状态机的核心机制：

from langgraph.graph import StateGraph, END
from langgraph.checkpoint.memory import MemorySaver
from typing import TypedDict, Literal


class ReviewState(TypedDict):
    content: str
    quality_score: int
    revision_count: int
    human_decision: str


def generate(state: ReviewState) -> dict:
    content = llm.invoke(f"生成方案：{state['content']}")
    return {"content": content}


def evaluate(state: ReviewState) -> dict:
    score = llm.invoke(f"给以下内容打分(0-100)：{state['content']}")
    return {"quality_score": int(score)}


def revise(state: ReviewState) -> dict:
    content = llm.invoke(f"改进以下内容：{state['content']}")
    return {
        "content": content,
        "revision_count": state["revision_count"] + 1
    }


def human_review(state: ReviewState) -> dict:
    return {"human_decision": "approved"}


def route_after_evaluate(
    state: ReviewState
) -> Literal["revise", "human_review"]:
    if state["quality_score"] >= 80:
        return "human_review"
    elif state["revision_count"] >= 3:
        return "human_review"
    else:
        return "revise"


builder = StateGraph(ReviewState)
builder.add_node("generate", generate)
builder.add_node("evaluate", evaluate)
builder.add_node("revise", revise)
builder.add_node("human_review", human_review)

builder.set_entry_point("generate")
builder.add_edge("generate", "evaluate")
builder.add_conditional_edges("evaluate", route_after_evaluate)
builder.add_edge("revise", "evaluate")
builder.add_edge("human_review", END)

checkpointer = MemorySaver()
graph = builder.compile(checkpointer=checkpointer)

config = {"configurable": {"thread_id": "task-001"}}
result = graph.invoke(
    {"content": "用户需求...", "revision_count": 0},
    config=config
)

这个例子体现了生产级 Agent 的三个核心特征：流程可控 （条件边限定路径）、状态可恢复 （Checkpoint）、人工可介入（human_review 节点）。

二、多智能体：什么时候需要，怎么协作

2.1 多智能体不是"越多越好"

单 Agent 能完成很多任务，但面对以下场景时，多智能体更有优势：

• 角色分工明确：研究员、程序员、审核员各司其职；
• 并行处理：多个子任务同时执行；
• 交叉验证：一个 Agent 的输出由另一个 Agent 审核。

但代价也很明显。CrewAI 的多 Agent 协作会产生 3～5 倍的 Token 膨胀，AutoGen 的 Group Chat 消息广播也有类似问题。这直接决定了 LLM 账单的规模。

2.2 三个主流框架：一句话定位

框架	一句话定位	最适合
CrewAI	角色分工的"团队模拟"	内容流水线、研究任务
AutoGen	群聊式的"圆桌讨论"	需要多轮对话协商的任务
LangGraph	图结构的"流程编排"	需要精确控制流程的任务

2.3 混合架构可能是最优解

IEEE 发表的一项系统性评估论文，使用 CREW-WILDFIRE 基准对三个框架做了量化对比，并提出并验证了一个 LangGraph-CrewAI 混合架构：用 LangGraph 做流程编排，用 CrewAI 做角色分工。

结果显示，相比纯 CrewAI 实现，混合架构在 17 个任务级别上达到了 96.1% 的成功率 ，同时将 Token 消耗降低了 76.2% ，决策延迟降低了 14.5 倍。

这说明：没有单一框架在所有维度上都最优，混合架构可以取长补短。

三、评估体系：Agent 上线前必须回答的四个问题

3.1 为什么 Agent 评估比传统测试难

传统软件测试是确定性的：给定输入，预期输出是固定的，pass 或 fail 一目了然。

Agent 评估面临三个新挑战：

• 指标定义模糊："好的回答"是什么？准确率怎么量化？
• 结果不确定性高：同一个问题，两次运行可能给出不同答案；
• 线上表现波动大：离线评测通过，线上可能因为用户输入分布不同而表现迥异。

但最隐蔽的问题是 "静默失败" ：Agent 可能通过错误的流程产出了正确的结果。比如一个财务审计 Agent 准确报出了 120 万的利润，但它的执行轨迹显示它读错了文档，只是由于"数字巧合"撞上了正确答案。这种"逻辑断层下的静默失败"，正是目前 Agent 大规模落地的最大死敌。

因此，Agent 评估不能只看最终输出，必须分析执行轨迹。

3.2 三支柱评估框架

参考 Google Gemini Agent Eval API 的评估实践，结合行业通用框架，可以从三个支柱来评估 Agent：

支柱一：任务质量

Agent 是否完成了用户的目标？最终回答是否准确、有用？

支柱二：过程与轨迹

Agent 的决策过程是否正确？工具选择是否合理？步骤是否高效？关键指标包括：

• 步骤效率：最优路径需要 3 步，Agent 走了 10 步，效率就是 0.3。工业级建议 ≥ 0.8。
• 错误恢复率：API 报错后，Agent 能否自我修正？生产级要求 > 90%。
• 死循环率：连续用相同错误参数尝试 ≥ 3 次。生产级红线 < 2%。

支柱三：信任与安全

Agent 在异常情况下是否可靠？能否抵御提示注入攻击？是否会产生偏见？

3.3 评估的核心原则

1. 从目标出发：先定义"成功是什么"，再定义度量指标。
2. 轨迹比结果更重要：静默失败是最大的陷阱，必须分析执行过程。
3. 离线 + 线上闭环：离线评测保证质量准出，线上监测驱动持续迭代。
4. 自动化 + 人工结合：LLM-as-Judge 做规模化评估，人工评估建立 ground truth。

四、生产落地的关键设计

4.1 五层架构模型

一个生产级 Agent 通常由五层组成：

+--------------------------------+
|         User Interface         |  用户界面
+--------------------------------+
              ↓
+--------------------------------+
|       Agent Orchestrator       |  流程编排（状态机 / LangGraph）
+--------------------------------+
              ↓
+--------------------------------+
|         Agent Runtime          |  运行时（Planner | Executor | Memory）
+--------------------------------+
              ↓
+--------------------------------+
|          Tool Layer            |  工具层（API | Database | MCP）
+--------------------------------+
              ↓
+--------------------------------+
|       Infrastructure           |  基础设施（Redis | MQ | Logs）
+--------------------------------+

Orchestrator 是系统的大脑，负责流程控制；Runtime 负责执行；Tool Layer 提供能力；Infrastructure 提供持久化和可观测性。

4.2 状态持久化与中断恢复

生产级 Agent 必须支持中断恢复。当长任务执行到一半时服务重启，系统需要知道：任务执行到哪了？已经调用了哪些工具？下一步该做什么？

LangGraph 的 Checkpointer 机制在每个节点后自动保存状态快照，配合 thread_id，可以随时从中断点恢复执行。

4.3 人机协同：高风险动作必须人工确认

不是所有操作都能让 Agent 自主执行。支付、删除、发送------这些高风险动作必须人工确认。

在状态机架构中，人工审核可以是一个正式的 Node，而不是临时嵌入的检查点。LangGraph 的 Interrupt 机制允许在指定节点暂停执行，等待外部输入后继续。

4.4 一个真实案例：神州租车

神州租车将 Agent 推向服务 1.8 亿注册用户的生产环境。核心挑战并非能否实现对话，而是如何融入既有复杂线上架构，确保端到端时延、召回质量与可观测性达到生产级要求。

其整体方案分为两层：端到端请求链路（Agent 作为请求链路末端的执行单元，复用现有网关鉴权、限流及 WAF 策略）和 Agent 内部实现架构（采用阿里云函数计算 Agent Sandbox 作为运行时底座）。Agent 服务与其他业务 API 复用同一套安全治理能力，但每接入新工具仍需在网关侧更新路由配置。因此二期计划引入主子 Agent 架构，由超级 Agent 统一路由和调度子 Agent。

五、落地路线图：从 0 到 1 的五个阶段

阶段	时间	关键动作	准出标准
1. 验证价值	1～2 周	选 1～2 个高频、低风险场景，用最简单的单 Agent 验证	人工评估确认能带来实际价值
2. 建立工作流	2～4 周	引入状态机，定义 State / Node / Edge，加入 Checkpoint	流程可中断恢复，关键节点有人工确认
3. 引入记忆与工具	2～4 周	实现三层记忆，通过 MCP 接入外部工具，建立权限控制	工具调用成功率 > 95%，权限隔离到位
4. 评估与迭代	持续	建立离线评测集，引入 LLM-as-Judge，上线后建立监测	步骤效率 ≥ 0.8，错误恢复率 > 90%
5. 多智能体（按需）	按需	只在确实需要角色分工或并行处理时引入，优先混合架构	相比单 Agent 有明确的性能提升

六、总结：生产级 Agent 的五条铁律

回到主线：

Agent 从 Demo 到生产，核心不是"让它更聪明"，而是"让它更可控"。

五条落地铁律：

1. 确定性骨架 + 概率性智能：状态机控制流程，LLM 负责节点内部的不确定问题。不要把所有决策权交给模型。
2. 可观测是底线：每一步都要有日志、有轨迹、能回放。没有可观测性，就无法调试，就无法迭代。
3. 评估驱动迭代：先定义成功，再定义指标。轨迹比结果更重要，静默失败是最大的陷阱。
4. 人机协同是常态：高风险动作必须人工确认。人工审核应该是正式的流程节点，而不是临时嵌入的检查。
5. 能单不多，混合优于单选：先做单 Agent + 状态机，按需引入多 Agent。多框架混合架构可以取长补短。

系列回顾

五篇文章，一条主线：

篇目	核心问题	一句话总结
第 1 篇	Agent 是什么？	从"生成"到"行动"，LLM 进化为 Agent
第 2 篇	Agent 由什么组成？	感知 + LLM/规划 + 记忆 + 工具 + 行动 + 循环
第 3 篇	Agent 怎么想？	ReAct、Plan-and-Execute、Reflexion、ToT
第 4 篇	Agent 怎么记和做？	分层记忆 + 工具调用 + MCP
第 5 篇	Agent 怎么落地？	状态机 + 多智能体 + 评估体系 + 落地路线图

Agent 不是一个更聪明的聊天机器人，而是一套能感知、会思考、能行动、可迭代、可控制的工程系统。

如果你要构建 Agent，记住一句话：

从工作流开始，逐步增加自主性；先做可观测性，再做自动化。
本文是「Agent 基本概念」系列第 5 篇，也是最后一篇。

如果你觉得这个系列有帮助，欢迎点赞、收藏、关注。

感谢阅读。