Agent 设计模式

本页系统梳理 LLM Agent 的核心设计模式：从最基础的 ReAct 循环到 Plan-and-Execute、Reflexion 反思、Multi-Agent 协作，再到支撑这些模式运转的记忆系统与工具编排策略。如果说 Agent 与多智能体回答了”Agent 是什么”，本页则回答”Agent 内部怎么设计才好用”。前置阅读：Agent 与多智能体、记忆系统、MCP 协议与工具调用、提示工程。

核心直觉

不同 Agent 设计模式的差别，就像不同工作风格的同事：

ReAct（边想边干）= 经验丰富的维修师傅。拧一颗螺丝看一眼，摸一摸再决定下一步——每一步行动都基于上一步的真实反馈。灵活，但每次决策都要停下来想一想，比较慢。
Plan-and-Execute（先规划再执行）= 建筑工程师。动工前先画完整图纸、列好施工顺序，然后照图施工。方向明确、效率高，但如果图纸本身基于错误假设，整栋楼都得返工。
Reflexion（做完复盘）= 打比赛的运动队。每打完一场就回看录像、总结教训（“下次对方快攻要提前退防”），把经验写进战术手册，下一场带着手册上场。打一百场，就比第一场强一百倍。
Multi-Agent 协作（团队合作）= 一个小型创业公司。产品经理管需求、工程师管实现、测试管质量——角色分工明确，通过对话或流程协调，能完成单兵作战搞不定的大任务。
记忆系统= 每种模式的”大脑后台”。短期记忆是”当前任务的草稿纸”，长期记忆是”跨项目的经验库”，工具记忆是”哪个工具好用、参数怎么填”的操作手册。
工具编排与错误恢复= 模式的”应急方案”。工具调用失败了怎么办——重试、换方案、自我修复——让 Agent 在真实世界中不脆弱。

2025 年趋势提示：Anthropic 在 2024 年底发布的”Building Effective Agents”一文中明确指出：大多数生产环境的 Agent 应用并不需要复杂的多智能体架构，简单的 LLM + 工具调用循环（即 ReAct 变体）往往就够了。复杂度应只在明确需要时才引入——这是 2025 年 Agent 工程的基调。

原理详解

ReAct（Reasoning + Acting）

ReAct 是最经典的 Agent 模式，核心是一个紧凑的三步循环：Thought → Action → Observation。

Thought（推理）：LLM 用自然语言”自言自语”，分析当前状态，决定下一步该干什么。例如：“用户问 2024 年的诺贝尔物理学奖得主，我需要先搜索。”
Action（行动）：根据推理结果选择一个工具并调用。例如调用 search("2024 Nobel Physics winner")。这一步通常以 Function Calling（函数调用，即 LLM 输出结构化的 JSON 指定要调用的函数名和参数）的形式实现。
Observation（观察）：把工具返回的结果塞回上下文（context window，即 LLM 单次能处理的输入文本长度），LLM 基于新信息继续推理。

这三步反复循环，直到 LLM 判断任务已完成、可以给出最终答案为止。

底层机制——为什么 ReAct 有效？ 关键在于推理和行动的协同效应。纯推理（Chain-of-Thought）只依赖模型内部知识，遇到事实性问题容易产生幻觉（hallucination，即模型生成看似合理但实际错误的内容）；纯行动（直接调工具但不推理）则缺乏规划，工具调用可能漫无目的。ReAct 让推理指导行动选择，行动反馈又更新推理依据，形成闭环。

适用场景：探索性、信息收集型任务——调研、问答、调试。每一步的决策依赖上一步的真实世界反馈，无法提前规划。

优点：灵活适应，遇到意外情况能即时调整；实现简单，一个循环加几个工具就能跑起来。

缺点：每步都调一次 LLM，长任务下 token 消耗和延迟都很高；如果某步推理跑偏（幻觉、误判），后续步骤会连锁出错，且没有全局纠偏机制。

ReAct 是几乎所有 Agent 框架（LangChain、LangGraph、OpenAI Function Calling）的默认底座。详见提示工程中 ReAct 提示的写法。

Plan-and-Execute

Plan-and-Execute 把 Agent 拆成两个角色：**Planner（规划器）**和 Executor（执行器）。

Planner：收到用户目标后，用一个 LLM 调用一次性生成完整的多步计划。例如目标”对比 A、B、C 三款数据库的性能”，Planner 输出：
- 步骤 1：搜索 A 的基准测试数据
- 步骤 2：搜索 B 的基准测试数据
- 步骤 3：搜索 C 的基准测试数据
- 步骤 4：汇总对比，生成表格
Executor：逐步执行计划中的每一步。每步可能是一个工具调用，也可能是一个小型 ReAct 子循环。
Re-Plan（重新规划）：执行过程中如果发现计划有误（比如步骤 1 搜不到数据），Executor 反馈给 Planner，Planner 基于新信息调整剩余计划。

适用场景：步骤较多、目标明确、且可以提前拆解的任务——数据分析、报告撰写、自动化运维。

优点：方向明确，Planner 一次调用就定全局方向，总 LLM 调用次数往往比 ReAct 少；执行过程可追踪（有明确的步骤列表）。

缺点：计划基于 Planner 在任务开始时的信息，如果初始假设错误（比如搜索词选偏了），整个计划可能全盘皆错，需要 Re-Plan 兜底；对模糊、需要边做边探索的任务反而不灵活。

2025 进展：Anthropic 在其”Building Effective Agents”中提出了”Orchestrator-Worker”模式，本质上是 Plan-and-Execute 的变体——一个 Orchestrator LLM 动态拆解任务并分配给 Worker LLM，Worker 完成后汇总。与经典 Plan-and-Execute 的区别在于拆解是动态的而非一次性的。Manus AI（2025 年爆火的通用 Agent）也采用了类似的动态规划 + 执行架构。

Reflexion（反思）

Reflexion 的灵感来自强化学习（Reinforcement Learning，RL），但巧妙地用自然语言反馈代替数值奖励信号。它的工作流程是一个”执行—评估—反思”的外循环：

Attempt（尝试）：Agent 用 ReAct 或 Plan-and-Execute 执行任务。
Evaluate（评估）：执行结束后，用一个评估器（可以是另一个 LLM、单元测试、或人工规则）判断结果是否正确。
Reflect（反思）：如果失败，LLM 回顾整个执行轨迹（trajectory，即从开始到结束的全部 Thought-Action-Observation 序列），生成一段”经验教训”——用自然语言写成的反思，例如：“第一步搜索词太宽泛，返回了大量无关结果，下次应加更具体的时间限定词。”
Memorize（写入记忆）：把反思存入记忆库。
Retry（重试）：带着记忆中的反思重新执行任务。下次 Attempt 时，LLM 的 prompt（提示词）里会注入历史反思，避免重蹈覆辙。

本质：语言层面的强化学习。传统 RL 用标量奖励（+1/-1）更新模型权重；Reflexion 用自然语言反馈更新 Agent 的上下文——不动权重，只动 prompt，却能达到”越做越好”的效果。

适用场景：有明确成败判据、允许多次尝试的任务——编程题（跑测试就知道对不对）、数学推理（答案可验证）、游戏闯关。

2025 进展：Reflexion 思想在 2025 年的推理模型（如 OpenAI o1/o3、DeepSeek-R1）中得到了更深层的发展——这些模型在训练阶段就学会了”内在反思”（通过 RL 让模型自动生成推理链和自我纠错），而非依赖外部循环。但在 Agent 场景中，外部的 Reflexion 循环仍然是强大工具，因为它可以基于真实环境反馈（如测试结果、API 返回）进行纠错，而不只是模型自身推理。

Multi-Agent 协作

当任务复杂到单个 Agent 的 prompt 装不下或容易顾此失彼时，把任务拆给多个角色化 Agent（即每个 Agent 有自己的角色设定、工具集和行为约束）。主流框架有几种协调哲学：

AutoGen（对话协调）：微软开源的多智能体框架。Agent 之间像开会一样互相发消息。用户定义几个角色（如”coder”和”reviewer”），框架让它们按对话轮次交流——coder 提交代码，reviewer 提意见，coder 再改。协调靠”对话协议”：谁接谁的话、何时结束，由消息路由规则控制。2024 年底 AutoGen v0.4 进行了重大重写，引入了基于事件的异步架构（ scalable agent architecture），支持更好的并发和调试。灵活，但对话轮次可能膨胀。
CrewAI（流程协调）：用户预先定义好角色（Role）、任务（Task）和执行顺序（Process）——像编排一条流水线。每个 Agent 有明确的 backstory 和 goal，任务按指定顺序（串行或并行）传递。2025 年 CrewAI 推出了 Flows 功能，允许用事件驱动的方式编排复杂工作流，兼具结构化和灵活性。结构清晰、可控性强，适合流程固定的场景。
OpenAI Swarm / Agents SDK（轻量协调）：OpenAI 在 2024 年底发布了 Swarm（实验性轻量多智能体框架），2025 年正式推出 Agents SDK。核心理念是用”handoff”（交接）机制让 Agent 之间转交控制权——一个 Agent 遇到不擅长的子任务时，直接把对话 handoff 给更合适的 Agent。极简设计，几行代码定义一个 Agent。
Google A2A 协议（Agent-to-Agent）：2025 年 Google 提出了 A2A（Agent2Agent）开放协议，目标是让不同厂商、不同框架构建的 Agent 能够互相发现、通信和协作——类似 Agent 领域的 HTTP 协议。

这些哲学的根本区别在于”谁决定执行顺序”：AutoGen 让 Agent 在运行时通过对话自行涌现顺序；CrewAI 让人类在设计时就把顺序定死；Swarm/Agents SDK 用轻量交接让 Agent 自主路由。

多智能体并不总是比单 Agent 好。它增加了协调开销和出错面——Agent 之间的误解、消息丢失、死循环都可能发生。任务能用一个 Agent 搞定的，不要强行拆成多个。Anthropic 的实践建议是：先从单 Agent + 工具开始，只在明确遇到瓶颈时才引入多 Agent 架构。

Agent 记忆系统

记忆是让 Agent 从”金鱼脑”变成”有经验的老手”的关键。三种记忆各有分工：

短期记忆（Short-term）：当前任务或对话的上下文，存在于 LLM 的 context window 中。包括用户指令、已执行步骤、中间结果。容量受 context window 大小限制（几千到几十万 token），任务结束即消失。管理短期记忆的核心是上下文工程——哪些信息留、哪些压缩、哪些丢弃。
长期记忆（Long-term）：跨会话的经验和知识。典型实现是”向量化存储 + 检索”——把历史对话、任务总结、用户偏好编码成 embedding（嵌入向量，即把文本映射成高维空间中的数值向量，语义相近的文本向量距离更近）存入向量数据库，每次新任务时检索最相关的几条注入 prompt。这让 Agent 能”记住”三个月前用户的偏好，而非每次从零开始。详见记忆系统与向量数据库。
工具记忆（Tool Memory）：记录”哪个工具在什么场景下有效、参数怎么填、常见错误是什么”。可以是一个 JSON 映射（工具名→使用经验），也可以是更结构化的技能库。高级系统会让 Agent 自动维护这份记忆——每次工具调用成功或失败后，更新对应的经验条目。

2025 进展：随着上下文窗口从 4K 扩展到百万 token（如 Gemini 的 2M context），短期记忆的容量限制有所缓解，但”能装”不等于”能用”——长上下文中信息利用率下降（Lost in the Middle 效应）仍是核心问题。长期记忆方面，Mem0（开源记忆层框架）和 Letta（原 MemGPT）等产品化方案日趋成熟，为 Agent 提供了开箱即用的跨会话记忆能力。OpenAI 也在 2025 年为 ChatGPT 加入了持久化记忆功能。

工具编排与错误恢复

真实世界中工具调用会失败：API 超时、参数格式错误、返回意外数据、权限不足。一个健壮的 Agent 必须有编排和容错策略：

工具选择的决策逻辑：当 Agent 有十几个工具时，选哪个？靠工具描述（description）的质量——描述要清晰说明”什么情况下用这个工具”。模糊的描述会导致选错工具。好的做法是给每个工具配使用示例和边界说明。2025 年随着 MCP（Model Context Protocol，模型上下文协议——Anthropic 于 2024 年底开源的标准协议，统一了 LLM 与外部工具/数据源的连接方式）的广泛采用，工具定义的标准化程度大幅提升。详见 MCP 协议与工具调用。
错误处理三策略：
- 重试（Retry）：瞬时错误（网络抖动、限流）直接重试，可加指数退避（exponential backoff，即每次重试间隔时间加倍）。
- 降级（Fallback）：主工具不可用时切换备用工具（如主搜索 API 挂了，换备用搜索）。
- 自我修复（Self-heal）：把错误信息回传给 LLM，让它分析原因并修正参数或换工具——这本质上是让 ReAct 循环自然处理异常。
并行 vs 串行：多个独立工具调用（如同时查三个数据库）应并行执行以降低延迟；有依赖关系的调用（先搜索再基于结果查询）必须串行。LangGraph 等框架支持显式声明并行分支。

Agent 的可观测性与评估

2025 年 Agent 工程的一个重大进展是对**可观测性（Observability）**的重视——Agent 的执行过程是一个多步骤的黑盒，不打开就不知道哪一步出了问题：

全链路追踪（Tracing）：记录每一步的 Thought、Action、Observation、延迟、token 消耗，形成完整的执行轨迹。LangSmith、Langfuse、Arize Phoenix 等工具提供了 Agent 级别的追踪能力。
Agent 评估指标：
- 任务成功率：最终是否完成了用户目标（最关键但最难自动衡量）。
- 步骤效率：用了多少步完成，是否走了弯路。
- 工具调用准确率：选对工具、参数正确的比例。
- 成本效率：每完成一个任务消耗多少 token、多少 API 费用。
AgentEval / τ-bench：学术界推出了专门评估 Agent 能力的基准——τ-bench 测试 Agent 在真实业务场景（如零售客服、航空预订）中的多轮工具调用能力。

原理图解

ReAct 循环

ReAct 的核心是 Thought → Action → Observation 的紧凑循环：

Plan-and-Execute 流程

Planner 先出计划，Executor 逐步执行，出错则重新规划：

Reflexion 反思循环

每次失败后生成反思、写入记忆，下次带着反思重试：

Multi-Agent 协作模式对比

动手实践

用 LangGraph 实现 Plan-and-Execute

以下用 LangGraph 展示 Plan-and-Execute 的骨架：Planner 生成步骤列表，Executor 逐步执行，全部完成后汇总。

from langgraph.graph import StateGraph, START, END
from langchain_openai import ChatOpenAI
from typing import TypedDict, List

# 定义状态：当前计划、执行进度、执行结果
class PlanState(TypedDict):
    goal: str
    plan: List[str]          # Planner 生成的步骤列表
    results: List[str]       # 每步的执行结果
    step: int                # 当前执行到第几步

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# Planner 节点：让 LLM 把目标拆成多步计划
def planner(state: PlanState):
    prompt = f"把以下目标拆成 3-5 个具体步骤，用 JSON 数组返回：\n{state['goal']}"
    steps = llm.invoke(prompt).content        # 实际应解析 JSON
    return {"plan": eval(steps), "step": 0, "results": []}

# Executor 节点：执行当前步骤（这里用 LLM 模拟工具调用）
def executor(state: PlanState):
    i = state["step"]
    res = llm.invoke(f"执行这一步：{state['plan'][i]}").content
    state["results"].append(res)
    state["step"] = i + 1
    return state

# 路由：还有步骤就继续执行，否则结束
def should_continue(state: PlanState):
    return "exec" if state["step"] < len(state["plan"]) else "done"

g = StateGraph(PlanState)
g.add_node("plan", planner); g.add_node("exec", executor)
g.add_edge(START, "plan"); g.add_edge("plan", "exec")
g.add_conditional_edges("exec", should_continue, {"exec": "exec", "done": END})
app = g.compile()

用 OpenAI Agents SDK 实现带交接的 Agent

2025 年 OpenAI 发布的 Agents SDK 提供了极简的多智能体交接模式：

from agents import Agent, Runner

# 定义两个角色不同的 Agent
triage_agent = Agent(
    name="前台分诊",
    instructions="你是客服前台。技术问题交给技术Agent，退款问题交给财务Agent。",
    handoffs=[],  # 下方动态指定
)

tech_agent = Agent(
    name="技术支持",
    instructions="你是技术支持工程师，负责排查和解决技术问题。",
)

finance_agent = Agent(
    name="财务支持",
    instructions="你是财务支持专员，负责处理退款和账单问题。",
)

# 设置交接关系：前台根据问题类型 handoff 给对应专家
triage_agent.handoffs = [tech_agent, finance_agent]

# 运行：Agent 会自动判断该交接给谁
result = Runner.run_sync(
    triage_agent,
    "我的 API 调用一直返回 500 错误"
)
print(result.final_output)
# 前台判断是技术问题 → handoff 给技术支持 → 技术支持给出排查建议

用 Reflexion 实现自动调试循环

import openai

client = openai.OpenAI()

def run_code(code: str) -> str:
    """执行代码并返回结果或错误信息"""
    import subprocess
    result = subprocess.run(
        ["python", "-c", code], capture_output=True, text=True, timeout=10
    )
    if result.returncode == 0:
        return f"成功:\n{result.stdout}"
    return f"失败:\n{result.stderr}"

def reflexion_debug(task: str, max_attempts: int = 3):
    """Reflexion 循环：执行 → 检查 → 反思 → 重试"""
    reflections = []  # 积累的经验教训

    for attempt in range(max_attempts):
        # 注入历史反思，让模型不重蹈覆辙
        reflection_text = "\n".join(f"- {r}" for r in reflections)
        prompt = f"任务: {task}\n"
        if reflection_text:
            prompt += f"\n之前的经验教训:\n{reflection_text}\n"
        prompt += "\n请直接输出 Python 代码，不要解释。"

        resp = client.chat.completions.create(
            model="gpt-4o",
            messages=[{"role": "user", "content": prompt}],
        )
        code = resp.choices[0].message.content
        # 提取代码块
        if "```python" in code:
            code = code.split("```python")[1].split("```")[0]

        # 执行并检查
        result = run_code(code)
        if "成功" in result:
            return f"✅ 第 {attempt+1} 次尝试成功:\n{result}"

        # 失败则反思
        reflect_prompt = f"代码执行失败:\n{code}\n\n错误:\n{result}\n\n用一句话总结教训:"
        reflect_resp = client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{"role": "user", "content": reflect_prompt}],
        )
        lesson = reflect_resp.choices[0].message.content
        reflections.append(lesson)
        print(f"第 {attempt+1} 次失败，反思: {lesson}")

    return "❌ 超过最大尝试次数"

# reflexion_debug("写一个二分查找函数，包含测试用例")

实践要点

ReAct 适合探索，Plan-Execute 适合执行：如果任务步骤无法提前预知（如调试一个未知 bug），用 ReAct 让 Agent 边做边判断；如果步骤清晰且较多（如按清单部署一套系统），用 Plan-and-Execute 减少调用次数、提高可追踪性。
Agent 循环必须设最大步数：无论 ReAct 还是 Reflexion，都要设硬上限（如 20 步）。否则一旦 Agent 陷入”再试一次”的死循环，token 消耗会爆炸，甚至拖垮后端。
工具描述是 Agent 的”眼睛”：Agent 选工具全靠读 description。描述要写清”做什么、何时用、参数格式、返回什么”，并附使用示例。一个描述不清的工具等于不存在。2025 年 MCP 协议的标准化大大改善了这一问题——工具描述有了统一的 Schema 格式。
Reflexion 需要可靠的评估器：反思的前提是能判断”对不对”。如果用 LLM 当评估器，它本身可能误判。最佳实践是优先用确定性判据——单元测试通过与否、正则匹配、API 返回状态码。
长期记忆要用检索而非全量注入：跨会话经验越积越多，不可能全塞进 context window。用向量检索按相关性取 top-k 条注入，既省 token 又聚焦。详见记忆系统。
错误恢复要分层：网络错误重试、工具不可用降级、逻辑错误让 LLM 自我修复——三层策略叠加，才能让 Agent 在真实环境中稳定运行。不要假设工具永远成功。
可观测性不是可选的：生产级 Agent 必须接入全链路追踪（LangSmith、Langfuse 等）。没有追踪，Agent 的调试全靠猜——你不知道它在第几步选错了工具、给了错误参数、还是上下文组装有问题。
先简单后复杂（Start Simple）：2025 年的 Agent 工程共识是——先从单 Agent + 工具循环开始，验证核心路径走通后，再逐步引入规划、反思、多智能体等复杂机制。过早引入复杂架构是 Agent 项目失败的首要原因。

典型应用

Devin / Cursor Agent / Claude Code：AI 编程 Agent 的代表。Devin 接收需求后自主编写代码、运行测试、读报错、修 bug——内部是 ReAct 循环加 Reflexion（测试失败后反思修改），并大量使用工具编排（终端、浏览器、编辑器）。详见AI 编程助手。
Manus：2025 年爆火的通用型 Agent 产品，能处理数据分析、文档处理、网页操作等多类型任务。采用 Plan-and-Execute + 动态 Re-Plan 拆解复杂目标，配合虚拟机工具集执行。
OpenAI Operator / Anthropic Computer Use：2025 年浏览器/桌面操作型 Agent 的代表——Agent 能直接操控浏览器点击、输入、滚动，或操控桌面应用程序。这类 Agent 需要处理视觉输入（截图）和精确的鼠标键盘控制，工具集从 API 调用扩展到了 UI 交互。
AutoGen：微软开源的多智能体框架。2024 年底 v0.4 重写后引入异步事件架构，支持更复杂的 Agent 拓扑和更好的可调试性。典型用法是定义多个角色 Agent，通过消息传递协作完成任务。
CrewAI：角色驱动的多智能体框架。2025 年推出 Flows 功能，支持事件驱动编排。用户定义角色（如”研究员""撰稿人""编辑”）、分配任务、设定流程，框架自动协调各角色串行或并行工作，适合内容生产、市场调研等流程化场景。
LangGraph：LangChain 团队推出的 Agent 编排框架，用状态图（StateGraph）显式定义 Agent 的执行流程——节点是 Agent 或工具，边是条件路由。2025 年 LangGraph 成为生产级 Agent 开发的主流选择，因为它的有状态图模型天然支持 Re-Plan、Human-in-the-loop（人类介入审核）等复杂控制流。适合实现 Plan-and-Execute、Reflexion 等需要复杂控制流的模式。

典型类库与工具

类库	语言	说明
LangGraph	Python / TS	基于状态图的 Agent 编排框架，支持 ReAct、Plan-and-Execute、Reflexion 等模式，2025 年生产级 Agent 首选
OpenAI Agents SDK	Python	OpenAI 2025 年正式发布的 Agent SDK，支持 handoff 交接、工具调用、追踪
AutoGen	Python	微软多智能体框架，v0.4 重写后支持异步事件架构，以”对话”为核心协调机制
CrewAI	Python	角色驱动的多智能体框架，2025 年新增 Flows 事件驱动编排
LlamaIndex Workflows	Python	事件驱动的 Agent 工作流编排，支持复杂分支与并行
MetaGPT	Python	模拟软件公司 SOP 的多智能体框架，角色分工精细
LangSmith / Langfuse	Python / TS	Agent 全链路追踪与评估平台，Agent 可观测性必备工具
Mem0 / Letta	Python	开源 Agent 记忆层框架，提供跨会话持久化记忆

术语表

术语	英文	解释
推理与行动	ReAct	Thought → Action → Observation 循环，Agent 边推理边执行的核心模式
函数调用	Function Calling	LLM 输出结构化 JSON 指定要调用的函数名和参数，是 Agent 调用工具的底层机制
规划与执行	Plan-and-Execute	先由 Planner 生成完整计划，再由 Executor 逐步执行，必要时重新规划
反思	Reflexion	执行失败后生成语言化经验教训并写入记忆，下次重试时参考
执行轨迹	Trajectory	Agent 从开始到结束的全部 Thought-Action-Observation 序列
重新规划	Re-Plan	执行中发现计划有误，反馈给 Planner 调整剩余步骤
多智能体	Multi-Agent	多个角色化 Agent 分工协作完成复杂任务的系统
交接	Handoff	一个 Agent 将控制权转交给另一个更适合当前子任务的 Agent
短期记忆	Short-term Memory	当前任务上下文，存在于 LLM context window 中，任务结束即消失
长期记忆	Long-term Memory	跨会话的经验，通常用向量数据库存储并按相关性检索注入
工具记忆	Tool Memory	记录各工具有效性、参数格式、常见错误的操作经验库
自我修复	Self-healing	工具调用出错时把错误信息回传 LLM，让其分析并修正参数或换工具
语言强化学习	Verbal Reinforcement Learning	用自然语言反馈代替数值奖励信号来改进 Agent 行为的范式
全链路追踪	Tracing	记录 Agent 每一步的推理、行动、观察、延迟和成本，用于调试和评估
MCP	Model Context Protocol	Anthropic 开源的统一协议，标准化 LLM 与外部工具/数据源的连接方式