Agent / 多智能体系统

为什么拆成多个 Agent复制标题链接

多智能体架构如何设计复制标题链接

开发时预定义好 3 个 Agent：MathAgent、CodeAgent、WriterAgent

用户输入："计算 123 × 456"

Router 决策：
  → 这是数学问题 → 丢给 MathAgent
  → MathAgent 拿到的是**完整的原始输入**："计算 123 × 456"
  → Router 没有拆分、没有规划，只是分类

开发时同样预定义好一堆 Agent：WeatherAgent、FlightAgent、HotelAgent、WriterAgent

用户输入："帮我规划下周去东京的行程，预算 5000 元"

Supervisor 决策：
  → 拆分 3 个子任务：
      ① 子任务 A：查东京天气             → WeatherAgent
      ② 子任务 B：查航班 + 酒店预算分配   → FlightAgent + HotelAgent
      ③ 子任务 C：根据 A+B 结果写行程     → WriterAgent
  → 并行执行 A、B
  → 汇总 A+B 的结果喂给 C
  → 合成最终输出

⚠️ 这里 WeatherAgent / FlightAgent / HotelAgent 全都是开发时就定义好的。Supervisor 没有"创建"任何新 Agent。
   Supervisor 做的是"规划 + 编排 + 合成"。

子智能体划分的原则复制标题链接

设计多智能体系统时，将复杂任务合理拆分并分配给不同的子智能体是架构成败的关键。通常遵循以下五个黄金划分原则：

1. 按单一职责原则划分 (Single Responsibility Principle, SRP)：

   • 逻辑：一个 Agent 应该且仅有一个引起它变化的原因（专注于做一类事情）。
   • 示例：在电商客服系统中，不要让一个 Agent 既处理退款、又回答商品参数、还去查物流。应拆分为：退款处理 Agent、商品导购 Agent 和 物流查询 Agent。

2. 按工具调用限制划分 (Tool-driven Boundary)：

   • 逻辑：大模型能熟练使用的工具数量是有限的（通常建议单 Agent 绑定工具不超过 5 个）。
   • 示例：如果某个任务需要 15 个外部 API（数据库读写、外部搜索、邮件发送等），应按照工具的使用边界将 Agent 拆分为 3-4 个。专门负责敏感操作（如付款或数据库修改）的 Agent 应该独立出来，便于精细化控制权限和安全审计。

3. 按业务阶段/SOP 划分 (Stage-based / Pipeline Partitioning)：

   • 逻辑：沿用企业内成熟的工业标准作业程序（SOP），将线性流转的每个关键节点设计为独立的 Agent。
   • 示例：软件开发团队工作流：需求分析 Agent -> 架构设计 Agent -> 代码编写 Agent -> 代码审查 Agent。

4. 按模型能力与成本要求划分 (Model-to-Cost Boundary)：

   • 逻辑：任务的难度不同，对模型推理能力的依赖也不同。将简单任务与复杂任务剥离，分派给不同能力的模型。
   • 示例：
     • 复杂/高难度任务（算法推理、架构规划、最终输出审查）：交给强推理模型（如 Claude 3.5 Sonnet 或 GPT-4o）。
     • 简单/高频任务（数据分类、格式提取、文本翻译）：交给轻量快速模型（如 GPT-4o-mini 或 Gemini Flash）。

5. 按上下文与状态独立性划分 (Context Independence)：

   • 逻辑：如果某些子任务不需要知道主任务的完整历史上下文，就可以将其剥离为独立的子 Agent，甚至可以并行运行。
   • 示例：在撰写一份大型行业报告时，可以把“收集互联网各领域数据”的任务分发给 5 个独立的 数据搜集子 Agent，它们各自在极小的上下文中运行，收集完后由 汇总 Agent 整合。

主智能体与子智能体协作与通信复制标题链接

A2A 协议与 MCP 的区别复制标题链接

A2A 与 MCP 并不是竞争关系，而是 互补的上下层关系：A2A 解决横向的 Agent 协同，MCP 解决纵向的模型与外部资源对接。

A2A（Agent-to-Agent Protocol）：

• 发起方：Google Cloud 及其生态伙伴（Linux 基金会托管）。
• 定位：智能体之间互相发现、建立信任、协作的 横向（Lateral）开放标准。
• 核心理念：Agent A ── A2A ── Agent B，解决的是 Agent 怎么和另一个 Agent 对话。
• 形象比喻：两个独立部门的经理之间谈商务合作、任务委托。

MCP（Model Context Protocol）：

• 发起方：Anthropic 主导，开源社区快速采纳。
• 定位：LLM 与外部工具、数据源之间的 纵向（Vertical）通用接口层。
• 核心理念：LLM → MCP → 工具 / 数据源 / 外部系统，解决的是模型怎么调用外部能力。
• 形象比喻：经理（Model）打开自己的工具箱（Tools）或查阅本地数据库（Data）。

# server.py — 一个 MCP Server (STDIO 模式)
from mcp.server.fastmcp import FastMCP

# 创建 MCP Server 实例
mcp = FastMCP("我的工具箱")

# 封装一个工具：查天气
@mcp.tool()
def get_weather(city: str) -> str:
    """查询指定城市的天气"""
    # 这里写真正的业务逻辑
    return f"{city}今天晴，气温30°C"

# 封装一个工具：查数据库
@mcp.tool()
def query_db(sql: str) -> str:
    """执行 SQL 查询"""
    # 连数据库、执行 SQL...
    return "[{id: 1, name: '张三'}]"

# 封装一个资源：API 文档
@mcp.resource("docs://api-guide")
def get_api_docs() -> str:
    """返回 API 使用指南"""
    return "# API 指南\n## 接口1: /users..."

# 封装一个提示模板
@mcp.prompt()
def code_review_prompt(code: str) -> str:
    """代码审查提示词"""
    return f"请审查以下代码，关注安全性和性能：\n```\n{code}\n```"

# 启动！走 STDIO 传输
mcp.run()  # 默认就是 stdio 模式

{
  "mcpServers": {
    "我的工具箱": {
      "command": "python",
      "args": ["/path/to/server.py"]
    }
  }
}

# server_http.py — 一个 MCP Server (HTTP 模式)
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("我的远程工具箱")

@mcp.tool()
def get_weather(city: str) -> str:
    """查询指定城市的天气"""
    return f"{city}今天晴，气温30°C"

# 启动！走 HTTP 传输
mcp.run(transport="streamable-http", host="0.0.0.0", port=8080)

{
  "mcpServers": {
    "远程工具箱": {
      "url": "http://localhost:8080/mcp"
    }
  }
}

多维度对比表

为什么不用 MCP 统一所有能力？复制标题链接

“既然 MCP 能让大模型调用工具，为什么不把每个 Agent 包装成 MCP Tool，用 MCP 统一多 Agent 系统？” 主要原因有三点：

1. 自治性差异：

   • MCP Tool 是 无状态、被动的，遵循 “调用 → 执行 → 返回” 的单向链路，不具备自主决策能力。
   • Agent 是 有状态、主动的，拥有独立目标、长短期记忆、Reflection 与 ReAct 循环，可以主动决定是否调用其他 Agent。

2. 协作维度差异：

   • MCP 是 点对点的资源访问通道，缺乏管理多 Agent 会话流转、多向广播、状态图拓扑的顶层设计。
   • A2A 天然支持多角色协商、任务委托（Delegation）、SOP 状态机维护等横向协作能力。

3. 上下文爆炸风险：

   • 若用 MCP 暴露所有 Agent 的底层工具，全部工具 Schema 会被拼进 LLM 上下文，瞬间造成 上下文窗口饱和 与注意力偏移。
   • A2A 通过 Agent Card 提供 高维能力抽象（只暴露 Agent 的输入输出契约，不暴露底层工具），实现高级别路由寻址。

生产落地的最佳组合复制标题链接

工业界最科学的架构是 A2A + MCP 的分层组合：

• A2A 层：负责上层 Agent 间的能力发现、任务分发与协作谈判。
• MCP 层：负责单个 Agent 内部与具体数据库、文件系统、物理工具的本地通信。

ReAct / Planning / Reflection / Self-Reflection复制标题链接

用户问题："2025 年奥斯卡最佳影片是哪部？它的导演还导过哪些获奖影片？"

Step 1
  Thought: 我需要先查 2025 年奥斯卡最佳影片
  Action: search("2025 Oscar Best Picture winner")
  Observation: 《阿诺拉》（Anora）

Step 2
  Thought: 知道是《阿诺拉》了，现在查它的导演是谁
  Action: search("Anora director")
  Observation: Sean Baker

Step 3
  Thought: 导演是 Sean Baker，查他还导过哪些获奖影片
  Action: search("Sean Baker awards")
  Observation: 《佛罗里达乐园》《红色火箭》...

Step 4
  Thought: 信息已经够了，可以回答了
  Final Answer: 《阿诺拉》，导演 Sean Baker，
  其他获奖作品有...

Phase 1: Plan
输入：纽约 7 月东京旅行攻略
输出：有序步骤列表
  Step 1: 搜索日本 7 月天气
  Step 2: 搜索纽约 -> 东京航班
  Step 3: 搜索东京酒店
  Step 4: 汇总为行程

Phase 2: Execute
对每个 Step：
  → 执行该步骤的具体 Action
  → 收集结果
  → 如某步骤失败 → 可重规划

# 1. 线性计划（简单）
plan = ["step1", "step2", "step3"]

# 2. 树状计划（有分支）
plan = {
    "root": "规划东京行程",
    "children": [
        {"task": "查天气", "deps": []},
        {"task": "查航班", "deps": []},
        {"task": "写行程", "deps": ["查天气", "查航班"]},
    ]
}

# 3. 自适应计划（允许修改）
plan = planner.generate(state)
# 执行中如发现 plan 不可行：
plan = planner.replan(state, failed_step)

1. GENERATE ─►  Agent 产生一个初稿
2. CRITIQUE ─►  Agent（或另一个 LLM）审查：
                  - 逻辑有没有漏洞？
                  - 格式是否正确？
                  - 是否遗漏要求？
3. REFINE   ─►  根据批评意见修改输出
4. LOOP?    ─►  达到质量阈值或最大轮次才停止

了解哪些 Agent 框架？它们各自的优劣？复制标题链接

MCP 的可扩展性体现在哪里? 什么场景适合封装MCP?复制标题链接

水平扩展：一个 Client 接 N 个 Server 垂直扩展：一个 Server 暴露 N 个工具 传输扩展：STDIO / HTTP 生态扩展：社区 Server 直接拿来用