AI Agent 架构与实践深度解析

🧩核心组件：Tools · Memory · Planning

一个功能完整的 AI Agent 通常由三大核心组件构成：Tools（工具）负责与外部世界交互；Memory（记忆）管理历史状态与上下文；Planning（规划）分解复杂任务并选择行动策略。三者协同构成 Agent 的感知-决策-执行循环。

Tools — 能力扩展的基石

工具是 Agent 连接 LLM 与真实世界的桥梁。通过工具调用，Agent 可以执行代码、查询数据库、调用 API、读写文件，甚至控制物理设备。工具定义通常包含：名称、描述、参数模式（JSON Schema）和返回格式。

// 工具定义的标准化结构
const tools = [
  {
    name: "web_search",
    description: "Search the web for current information",
    parameters: {
      type: "object",
      properties: {
        query:   { type: "string", description: "Search query" },
        top_k:   { type: "integer", description: "Max results", default: 5 }
      },
      required: ["query"]
    }
  },
  {
    name: "execute_python",
    description: "Run Python code in a sandboxed environment",
    parameters: {
      type: "object",
      properties: {
        code: { type: "string", description: "Python code to execute" }
      },
      required: ["code"]
    }
  }
];

设计原则：工具命名应清晰无歧义；参数尽量使用枚举或有限集合；每个工具应单一职责；为工具添加权限级别和安全边界。

Memory — 持续智能的保障

Memory 模块解决 LLM 有限上下文窗口与长期任务需求之间的矛盾。典型的记忆系统采用分层架构：

• 工作记忆（Working Memory）：当前会话上下文，直接参与推理，约 4-32k tokens
• 情景记忆（Episodic Memory）：历史交互片段，支持回顾与经验复用，通常存储在向量数据库
• 语义记忆（Semantic Memory）：结构化知识与事实，通过 RAG 或知识图谱访问
• 程序记忆（Procedural Memory）：Agent 的内化策略与工作流程模式

# 分层记忆系统的简化实现
class 分层记忆系统:
    def __init__(self, vector_db, kg_client):
        self.working   = []                    # 当前上下文
        self.episodic  = vector_db             # Chroma / FAISS / Milvus
        self.semantic  = kg_client             # 知识图谱
        self.procedural = "REACT"              # 当前策略模式

    def retrieve(self, query, top_k=5):
        # 1. 从情景记忆中向量检索
        episodes = self.episodic.similarity(query, top_k)
        # 2. 从语义记忆中图查询
        facts    = self.semantic.query(query)
        # 3. 合并 + 重排序返回
        return self.merge(episodes, facts)

Planning — 复杂任务的分解与执行

规划能力决定 Agent 如何将模糊目标转化为可执行步骤。主流方法包括：

• Chain-of-Thought（CoT）：逐步推理，适合线性逻辑任务
• Tree-of-Thought（ToT）：树状探索，支持回溯与分支选择
• ReAct：推理与行动交替进行，适合需要环境反馈的交互任务
• Plan-and-Execute：先规划全局路径，再逐步执行，适合长周期任务
• LLM Compiler：并行规划与依赖分析，最大化工具调用并行度

🔄ReAct 范式：推理与行动的闭环

ReAct（Reasoning + Acting）由 Google Research 在 2023 年提出，核心思想是将 LLM 的推理能力与工具执行能力深度融合，形成"思考-行动-观察"的迭代循环。这一范式解决了纯推理模型无法获取实时信息的困境，也解决了纯行动模型缺乏逻辑连贯性的问题。

ReAct 循环机制

每一轮循环中，LLM 接收到：当前任务描述 + 历史轨迹（Thought-Action-Observe 三元组）+ 当前观察结果，然后生成下一步的 Thought（推理判断）和 Action（工具调用）。

ReAct vs 其他范式对比

ReAct Prompting 示例

# ReAct 风格的系统提示
"You are a helpful assistant that uses ReAct pattern.\n\n"
"For each step, output a JSON object with fields:\n"
"  - thought: your reasoning about the current state\n"
"  - action: the tool to call (or 'finish'/'fail')\n"
"  - action_input: arguments for the tool\n\n"
"History: {history}\n"
"Current observation: {observation}\n"
"Task: {task}"

# LLM 实际输出示例：
{
  "thought": "The user wants to know the weather in Tokyo. "
           "I should first search for the current weather.",
  "action": "web_search",
  "action_input": { "query": "Tokyo weather January 2026" }
}

{
  "thought": "Got the weather data. Tokyo is 8°C and sunny. "
           "I can now provide the answer directly.",
  "action": "finish",
  "action_input": { "response": "Tokyo 今日天气：8°C，晴天" }
}

ReAct 的精髓在于：Thought 必须真正影响 Action 的选择，而不是生成一段看似推理但与行动无关的文本。每次 Action 后的 Observe 结果应当真实反馈到下一轮的 Thought 中。

🔌MCP 协议：模型上下文协议

Model Context Protocol（MCP）由 Anthropic 于 2024 年底提出并开源，是一种标准化 Agent 与外部数据源、工具连接的首选协议。MCP 的设计目标是：让 Agent 能够动态发现和连接多样化的数据源与工具，而无需为每个数据源单独定制集成代码。

MCP 架构

MCP 采用JSON-RPC 2.0作为传输层协议，支持两种连接模式：

• stdio 模式：通过标准输入/输出通信，适合本地工具集成
• HTTP + SSE 模式：通过 HTTP 传输，支持远程服务发现与调用

MCP 核心原语

MCP Server 实现示例

# 使用 FastMCP 框架的简单 MCP Server
from fastmcp import FastMCP

mcp = FastMCP("WeatherService")

@mcp.tool()
def get_weather(city: str, country: str = "US") → dict:
    "Get current weather for a city"
    # 调用天气 API 并返回结果
    return {"city": city, "temp": "8°C", "condition": "sunny"}

@mcp.resource("weather://{city}")
def weather_resource(city: str) → str:
    "Template resource for weather data"
    return f"# Weather: {city}\n\nReal-time weather data..."

MCP 的关键优势在于其可发现性：通过 list_tools 和 list_resources 等元操作，Agent 可以在运行时动态了解自身可用的能力集，而非硬编码工具列表。这为构建真正动态、可组合的 Agent 系统奠定了协议基础。

🤝A2A 协议：Agent 间通信标准

Agent-to-Agent Protocol（A2A）是 Anthropic 同期开源的另一核心协议，专注于解决不同 Agent 之间如何高效、标准地交换信息与协作的问题。如果说 MCP 是 Agent 与工具的接口标准，A2A 则是 Agent 与 Agent 之间的"外交护照"。

A2A 核心概念

• Task（任务）：A2A 的核心工作单元，每个任务有唯一 ID、状态和结果
• Agent Card（元数据）：每个 Agent 公开自身能力的描述，供其他 Agent 发现
• Message（消息）：Agent 间传递的上下文单元，支持多模态内容
• Skill（技能）：Agent 声明其擅长处理的任务类型

A2A 与 MCP 的关系

A2A 任务生命周期

A2A 协作示例：研究Agent委托

# Agent A 通过 A2A 委托任务给 Agent B
# 1. 发现 Agent B 的能力
agent_b_card = a2a_client.get_agent_card("research-agent")
# → 返回 Agent B 的 skills, description, endpoint

# 2. 提交任务
task = a2a_client.create_task(
    agent_id  = "research-agent",
    skill     = "web_research",
    input     = {"query": "MCP 协议最新进展", "depth": "comprehensive"}
)

# 3. 轮询任务状态或订阅 SSE 流
while task.status == "working":
    updates = a2a_client.get_task_updates(task.id)
    for update in updates:
        print(f"Progress: {update.message}")
    sleep(1)

# 4. 获取最终结果
result = a2a_client.get_task_result(task.id)
# → { "summary": "...", "sources": [...], "confidence": 0.92 }

👥多Agent协作模式

当单一 Agent 的能力无法满足复杂系统需求时，多 Agent 协作成为必然选择。不同 Agent 可以拥有不同的专业知识、工具集和决策策略，通过结构化的协作机制共同完成单一 Agent 无法企及的任务。

四大协作模式

协作中的挑战与应对

• 信息传递损耗：每次 Agent 间传递都可能丢失上下文细节。应对策略：使用结构化输出 Schema + 摘要压缩 + 关键信息标记。
• 循环依赖：Agent A 等 Agent B，Agent B 等 Agent A。应对策略：超时机制 + 依赖图检测 + 强制仲裁。
• 状态一致性：多个 Agent 共享状态时产生冲突。应对策略：中央协调器 + 乐观锁 + 事件溯源。
• 通信开销：频繁的 Agent 间调用带来延迟。应对策略：批量消息 + 本地缓存 + 异步非阻塞调用。

Supervisor 架构示例

# 伪代码：Supervisor 控制的多Agent系统
class Supervisor:
    agents = {
        "researcher": ResearchAgent(),
        "coder":      CodeAgent(),
        "reviewer":  ReviewAgent(),
    }

    def handle(task):
        plan = self.planner.decompose(task)
        # 顺序执行，带条件分支
        context = {}
        for step in plan.steps:
            agent = self.agents[step.agent]
            result = agent.execute(step.input, context)

            if step.branch_on and not self.evaluator.is_satisfied(result):
                # 回退到替代路径
                alt_plan = self.planner.get_alternative(step)
                plan = alt_plan + plan_rest
                continue

            context[step.key] = result

        return self.orchestrator.finalize(context)

多 Agent 系统的核心设计哲学是：让每个 Agent 保持职责单一、边界清晰，通过协议而非共享状态进行交互。这与微服务架构的思路一脉相承，却面临 LLM 输出不确定性这一全新的工程挑战。

🏗️完整 Agent 系统架构

以下是一个生产级别的 AI Agent 系统完整架构视图，涵盖从 LLM 推理引擎到外部工具集成的所有关键层次。

各层职责说明

• Agent Gateway：系统入口，负责认证鉴权、流量控制（Token Bucket / Leaky Bucket）、会话管理（维护多轮对话状态）和请求路由（根据 Agent 类型分发到对应实例）。
• Planner：决策核心，根据当前任务选择推理策略（ReAct / CoT / Plan-and-Execute），生成工具调用计划，管理执行状态机，处理回退与重试逻辑。
• Memory：采用向量数据库（如 Milvus、Pinecone）存储情景记忆，配合知识图谱（如 Neo4j）提供语义记忆能力，工作记忆层通过 Redis 实现高速读写。
• Tool Registry：基于 MCP 协议连接各类外部服务（搜索、数据库、云API），支持运行时工具注册与发现，配备沙箱执行环境保障安全。
• LLM Inference Engine：底层推理服务，支持自托管（vLLM + TensorRT）或云服务（OpenAI / Anthropic / Groq），通过连续批处理（Continuous Batching）最大化吞吐。

⚡工程实践要点

可靠性保障

• 幂等设计：工具调用应尽可能幂等，Agent 因超时重试时不会产生副作用
• 超时与熔断：每个外部调用设置合理超时（建议 5-30s），连续失败时触发熔断
• 状态快照：定期保存 Agent 状态到持久化存储，支持从故障点恢复
• 输出验证：对 LLM 输出进行 Schema 校验，防止解析失败影响后续流程

安全边界

• 最小权限：Agent 的工具调用权限应遵循最小权限原则，危险操作需二次确认
• 输入净化：对用户输入进行过滤，防止提示注入（Prompt Injection）攻击
• 沙箱执行：代码执行、Shell 命令等高危工具必须在隔离环境中运行
• 审计日志：完整记录所有工具调用的时间、参数和返回值，供事后审计

性能优化

• 批量工具发现：预热时加载所有工具定义，避免运行时动态发现的开销
• 流式输出：使用 SSE/WebSocket 流式返回推理过程，提升用户体验
• 记忆压缩：当对话历史超过阈值时，自动进行信息压缩与摘要
• 并行预取：在当前步骤执行时，后台预取下一步可能需要的数据