从 Chatbot 到 Agent：AI 智能体架构设计的 5 个关键模式

当大模型从"对话者"进化为"执行者"，我们需要重新思考 AI 应用的架构设计。

引言：为什么 Chatbot 不够用了？

2023 年，ChatGPT 引爆了生成式 AI 的浪潮。我们见证了无数聊天机器人的诞生------它们能写诗、能编程、能回答问题。但很快，开发者们发现了一个尴尬的事实：会说话的 AI 不等于能做事的 AI。

用户想要的不只是对话，而是真正能够帮他们完成任务的智能助手。于是，AI Agent（智能体）的概念应运而生。

Agent 与 Chatbot 的本质区别在于：Agent 具备自主规划、工具调用和任务执行的能力。它不再是被动的回答者，而是主动的问题解决者。

本文将深入探讨从 Chatbot 演进为 Agent 的 5 个关键架构模式，帮助开发者构建真正可用的 AI 应用。

---

模式一：ReAct ------ 思考与行动的循环

核心思想

ReAct（Reasoning + Acting）是 Agent 架构的基石。它模仿人类解决问题的方式：先思考，再行动，观察结果，继续思考。

架构设计

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Thought   │────▶│    Action   │────▶│ Observation │
│  (思考)     │     │   (行动)    │     │  (观察)     │
└─────────────┘     └─────────────┘     └──────┬──────┘
       ▲───────────────────────────────────────┘

实践示例

假设用户提问："北京明天天气如何？我需要带伞吗？"

传统 Chatbot：直接调用天气 API，返回结果。

ReAct Agent：

1. Thought: 用户询问北京明天的天气和是否需要带伞。我需要先获取北京的天气预报。
2. Action: 调用天气查询工具，参数：location="北京", date="明天"
3. Observation: 获取到天气数据------明天北京多云转小雨，气温 15-22°C
4. Thought: 有降雨概率，建议带伞。我需要整理一个清晰的回答。
5. Action: 生成最终回复

代码实现要点

# 伪代码示例
class ReActAgent:
    def run(self, query):
        context = []
        for step in range(max_steps):
            # LLM 生成思考和行动
            response = llm.generate(
                prompt=build_react_prompt(query, context),
                tools=available_tools
            )
            
            thought = response.thought
            action = response.action
            
            if action.type == "finish":
                return action.answer
            
            # 执行工具调用
            observation = execute_tool(action)
            context.append({thought, action, observation})

适用场景

• 多步骤推理任务
• 需要外部工具辅助的问答
• 复杂问题分解

---

模式二：Plan-and-Solve ------ 先规划，后执行

核心思想

对于复杂任务，ReAct 的逐步推理可能效率低下。Plan-and-Solve 模式采用"先制定完整计划，再逐步执行"的策略。

架构设计

┌─────────────────┐
│  Task Input     │
└────────┬────────┘
         ▼
┌─────────────────┐
│  Planner (LLM)  │ ← 生成完整执行计划
└────────┬────────┘
         ▼
┌─────────────────┐
│  Executor       │ ← 按计划逐步执行
│  (可并行/串行)   │
└─────────────────┘

实践示例

用户请求："帮我策划一次 3 天 2 晚的杭州旅行，预算 3000 元"

Planner 输出：

{
  "plan": [
    {"step": 1, "task": "查询杭州热门景点", "deps": []},
    {"step": 2, "task": "搜索经济型酒店", "deps": []},
    {"step": 3, "task": "规划每日行程路线", "deps": [1, 2]},
    {"step": 4, "task": "估算交通和餐饮费用", "deps": [3]},
    {"step": 5, "task": "生成完整旅行方案", "deps": [4]}
  ]
}

优势与权衡

维度	ReAct	Plan-and-Solve
执行效率	较低（逐步探索）	较高（计划先行）
灵活性	高（可动态调整）	中（需重新规划）
并行能力	弱	强（识别无依赖任务）
适用任务	探索性任务	确定性任务

---

模式三：Multi-Agent 协作 ------ 分而治之

核心思想

单一 Agent 难以应对复杂场景。Multi-Agent 架构将任务分解给多个专业 Agent，通过协作完成复杂目标。

典型架构

                    ┌─────────────┐
                    │  Supervisor │ ← 协调者 Agent
                    │   Agent     │
                    └──────┬──────┘
                           │
       ┌───────────────────┼───────────────────┐
       ▼                   ▼                   ▼
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Research   │    │   Writer    │    │   Reviewer  │
│   Agent     │    │   Agent     │    │   Agent     │
│  (资料搜集)  │    │  (内容创作)  │    │  (质量审核)  │
└─────────────┘    └─────────────┘    └─────────────┘

协作模式

1. 层级式（Hierarchical）：Supervisor 分配任务，子 Agent 执行
2. 对等式（Peer-to-Peer）：Agent 之间直接通信协商
3. 流水线式（Pipeline）：任务按阶段流转，每个 Agent 处理特定环节

实践案例：自动写作系统

• Research Agent：搜索资料、整理数据
• Outline Agent：根据资料生成文章大纲
• Writer Agent：撰写具体内容
• Editor Agent：润色、检查语法和逻辑
• SEO Agent：优化标题和关键词

---

模式四：Reflection & Self-Critique ------ 自我反思

核心思想

人会在犯错后反思改进，Agent 也可以。通过让 LLM 审视自己的输出，可以显著提升质量。

架构设计

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Generate  │────▶│   Reflect   │────▶│   Revise    │
│   (初稿)    │     │  (反思问题)  │     │  (改进优化)  │
└─────────────┘     └──────┬──────┘     └──────┬──────┘
                           │                    │
                    ┌──────┴──────┐            │
                    │  Critique   │            │
                    │  (批评意见)  │────────────┘
                    └─────────────┘

实现策略

单模型自反思：

• 使用同一个 LLM，通过不同 prompt 分别扮演生成者和批评者
• 成本低，但可能陷入自我重复

双模型协作：

• Generator 模型负责生成
• Critic 模型（可以是更强的模型或专门微调的模型）负责评估
• 效果更好，但成本更高

反思 Prompt 示例

请审视以下回答，找出其中的问题：
1. 事实准确性：是否有错误或幻觉？
2. 完整性：是否遗漏了重要信息？
3. 逻辑性：推理过程是否严谨？
4. 清晰度：表达是否易于理解？

回答内容：{generated_content}

请以 JSON 格式输出发现的问题及改进建议。

---

模式五：Tool Use with MCP ------ 工具的标准化

核心思想

Agent 的能力边界取决于它能使用什么工具。MCP（Model Context Protocol）是 Anthropic 推出的开放协议，旨在标准化 LLM 与外部工具的交互。

为什么需要 MCP？

在 MCP 之前，每个 Agent 框架都有自己的工具定义格式：

• LangChain 的 Tool 接口
• OpenAI 的 Function Calling 格式
• AutoGPT 的插件系统

MCP 的目标：一次编写，到处运行。

MCP 架构

┌─────────────────────────────────────────┐
│           MCP Client (Agent)            │
│         (统一协议，多源接入)              │
└─────────────────────────────────────────┘
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ File System │ │   GitHub    │ │   Slack     │
│   Server    │ │   Server    │ │   Server    │
└─────────────┘ └─────────────┘ └─────────────┘

MCP 的核心优势

1. 标准化接口：统一的工具发现和调用机制
2. 安全隔离：工具运行在独立进程中，通过 STDIO/SSE 通信
3. 生态互通：任何支持 MCP 的 Agent 都能使用兼容的工具

工具设计最佳实践

// MCP Tool 定义示例
{
  name: "search_code",
  description: "在代码库中搜索特定模式",
  parameters: {
    type: "object",
    properties: {
      query: {
        type: "string",
        description: "搜索关键词或正则表达式"
      },
      language: {
        type: "string",
        enum: ["python", "javascript", "go"],
        description: "限定搜索的编程语言"
      }
    },
    required: ["query"]
  }
}

---

实战：构建一个可用的 Agent

技术选型建议

组件	推荐方案	说明
LLM	Claude 3.5 Sonnet / GPT-4	推理能力强，适合 Agent
框架	LangChain / LlamaIndex	生态成熟，工具丰富
协议	MCP	新兴标准，值得关注
记忆	Redis / Vector DB	支持长期记忆和检索
监控	LangSmith / AgentOps	追踪和调试 Agent 行为

最小可行架构

from typing import List, Dict, Any
import json

class SimpleAgent:
    def __init__(self, llm, tools: List[Tool]):
        self.llm = llm
        self.tools = {tool.name: tool for tool in tools}
    
    def run(self, query: str) -> str:
        # 1. 构建系统提示
        system_prompt = self._build_system_prompt()
        
        # 2. 循环执行直到完成
        messages = [
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": query}
        ]
        
        for _ in range(self.max_iterations):
            # LLM 决策
            response = self.llm.chat(messages)
            
            # 解析工具调用
            tool_calls = self._parse_tool_calls(response)
            
            if not tool_calls:
                # 没有工具调用，直接返回
                return response
            
            # 执行工具
            for call in tool_calls:
                result = self._execute_tool(call)
                messages.append({
                    "role": "tool",
                    "content": json.dumps(result)
                })
        
        return "达到最大迭代次数"

---

未来展望：Agent 的下一个前沿

1. Computer Use Agent

Claude 3.5 Sonnet 已经展示了通过截图和 UI 操作控制计算机的能力。未来 Agent 将能够：

• 操作任何软件界面
• 跨应用自动化工作流
• 像人类一样使用电脑

2. Agent 间的协作网络

单个 Agent 能力有限，但 Agent 网络将形成新的智能生态：

• 专业 Agent 提供服务
• 通用 Agent 协调调度
• 形成"AI 经济"的基础

3. 持续学习与进化

未来的 Agent 将具备：

• 从交互中持续学习
• 自我改进能力
• 个性化适配用户习惯

---

结语

从 Chatbot 到 Agent，不仅是技术的演进，更是 AI 应用范式的转变。

ReAct 让我们学会了如何让 AI 思考与行动；Plan-and-Solve 教会我们规划的重要性；Multi-Agent 展示了协作的力量；Reflection 带来了质量的提升；MCP 则为工具生态铺平了道路。

作为开发者，我们正站在一个激动人心的时代节点。Agent 架构还在快速演进，但核心原则已经清晰：让 AI 不只是会说话，而是真正能够解决问题。

希望本文的 5 个模式能为你的 Agent 开发之旅提供有价值的参考。如果你正在构建 Agent 应用，欢迎在评论区分享你的经验和思考。

---

参考资源

• ReAct: Synergizing Reasoning and Acting in Language Models
• MCP Documentation
• LangChain Agent Documentation
• Claude Computer Use Demo

---

本文首发于稀土掘金，转载请注明出处。