从只会聊天的“鹦鹉”，到能规划、会执行、懂协作的智能同事，这背后是一场关于架构、工具与思想的深刻演进。

最近，随着各种AI Agent框架和应用的爆发，我花了些时间深入研究其技术脉络。我发现，AI Agent的发展史，本质上是如何为一个大语言模型（LLM）这个“最强大脑”逐步装配“身体器官”和“神经系统”，使其从空谈走向实干的过程。

本文将带你回顾这一历程，从最初的简单聊天，到工具调用，再到如今模块化、标准化的MCP与Skill体系，并剖析其中的关键架构思想。

---

第一阶段：单纯的LLM Chat——“聪明的鹦鹉”

最初的LLM，如早期的ChatGPT，是一个令人惊叹的文本生成器。它能聊天、写诗、总结、翻译，但其能力被严格限制在训练数据截止日期前的知识范围内，且没有与现实世界交互的任何“手脚”。它就像一个被关在信息茧房里的、学识渊博的鹦鹉，能复述知识，却无法执行任何具体操作。所有复杂任务都依赖其“即兴发挥”，导致输出不稳定且容易产生“幻觉”。

第二阶段：初始Agent——“长了手脚的鹦鹉”

为了解决“空谈”问题，业界引入了 “工具调用”（Function Calling） 能力。这标志着Agent时代的开端。其核心流程是：

1. LLM分析：用户提问后，LLM分析需求。
2. 决策与调用：若需外部能力，LLM输出一个结构化调用请求（如 {“name”: “get_weather”, “arguments”: {“location”: “北京”}}）。
3. 执行与回复：系统执行相应代码（如调用天气API），将结果返回给LLM，由LLM组织成自然语言回复。

然而，这个阶段的架构很快暴露出痛点：

• 工具集成地狱：每个项目都需重复编写工具连接代码，无法复用。
• 上下文臃肿：冗长的工具描述占满Token，拖慢速度、增加成本。
• 流程脆弱：LLM需临场规划多步工具调用，极易出错。

第三阶段：标准化协议（以MCP为代表）——“为世界装上统一插座”

为解决工具集成的混乱，出现了以 模型上下文协议（Model Context Protocol， MCP） 为代表的标准化协议。MCP的核心思想是将工具本身标准化和外部化。

它采用客户端-服务器模型：

• MCP服务器：一个独立进程，专门负责连接某一类资源（如数据库、GitHub）。它对外暴露统一的接口。
• MCP客户端（如Claude Desktop、Cursor IDE）：只需实现一次协议对接，就能自动发现、加载和使用所有兼容的MCP服务器。

这就像为AI世界制定了USB-C标准。数据库专家写好一个MCP服务器后，任何支持MCP的AI应用都能直接使用，彻底解决了工具集成和移植的难题。MCP成为了Agent可靠的“手”。

第四阶段：Skills的提出——“拥有SOP的专家老师傅”

有了标准化的“手”（MCP），如何让它“会办事”？这就需要 Skills（技能）。Skills的核心是固化最佳实践和流程。

一个Skill通常包含：

• 触发条件：当用户提到“画架构图”时触发。
• 核心指令：分步骤的详细指导，告诉AI先做什么、后做什么，用什么格式。
• 工具调用：明确指示在某一步调用哪个MCP工具。

Skills与MCP的关系：

• MCP 是基础设施，解决“能力接入”（能干什么）。
• Skills 是上层应用，解决“高质量执行”（该怎么干）。
• Agent 是运行时，在Skills指导下，通过MCP调用工具完成任务。

使用Skills时，通常无需在对话中明确指出，系统会根据问题自动匹配调用，让AI如同一位经验丰富的老师傅，稳定输出高质量成果。

关键架构思想演进：从ReAct到Plan-and-Execute

在Agent内部，如何组织“思考”与“行动”也经历了演进，诞生了两种核心模式：

模式	哲学	工作流	适用场景
ReAct （推理与行动）	边想边做，敏捷探索	思考 → 行动 → 观察 → 思考…	开放探索性任务，如复杂调试、研究
Plan-and-Execute （规划与执行）	先谋后动，严格执行	规划者制定完整计划 → 执行者逐步执行	目标明确、步骤清晰的任务，如数据ETL、报告生成

ReAct 像一个在迷宫中探索的人，每走一步都观察四周再做决定，灵活但可能效率低。Plan-and-Execute 则像按蓝图施工，先由资深工程师（规划者LLM）制定完整计划，再由工人（执行者）严格执行，高效但依赖初始计划质量。

---

Agent的工程核心：工具与上下文管理的实战剖析

如果说MCP和Skills定义了Agent的“身体”和“经验”，那么工具调用（Function Call）的精细调度和上下文（Context）的智能管理就是维持其高效、稳定运行的“血液循环系统”与“短期记忆”。它们是工程实践中成本、性能与可靠性的决定性因素。本章将深入探讨你在实践中关心的几个核心问题。

5.1 工具精选：从“全盘供给”到“按需检索”的三大方案

在第二阶段的Agent中，一个常见的误区是将所有工具描述一次性塞给LLM。现代最佳实践是进行工具精选，主要方案对比如下：

方案	核心机制	优点	缺点	适用场景
静态路由	预先按业务场景绑定固定工具集。	简单直接，零延迟。	僵化，无法处理跨场景复杂请求。	功能单一、固定的简单助手。
基于规则过滤	使用关键词、正则表达式匹配用户输入和工具描述。	速度快，成本低，确定性强。	泛化能力差，维护负担随工具增多而剧增。	工具少、意图表述标准化的内部系统。
动态意图识别与检索（主流）	用轻量级LLM或向量检索，实时分析用户意图并召回相关工具。	灵活、精准、泛化能力强，用户体验好。	引入少量延迟和额外计算成本。	绝大多数现代复杂Agent系统。

其中，动态意图识别与检索是最佳实践，其核心流程如同一个智能调度中心：

1. 向量化知识库：将所有工具的功能描述转换为向量（Embedding），存入向量数据库。
2. 意图检索：当用户提问时，将问题也向量化，并从工具库中实时检索出最相关的几个工具（通常为3-5个）。
3. 精准投喂：只将这些少量高相关工具的描述注入本次对话的提示词中，供主LLM决策调用。

这确保了LLM总是在最清晰、最相关的选项下工作，显著提升了工具调用的准确率和效率。

5.2 意图识别：架构中的“前哨”与框架集成

意图识别是整个流程的**“前哨”，它发生在主LLM进行深度推理和工具调用之前**，核心任务是快速判断用户意图，为主LLM筛选出合适的工具或技能。

• 是否必须集成在AI Agent框架中？
  并非必须，但高度推荐。现代框架（如LangChain、LlamaIndex）提供了成熟的工具路由（Tool Router）、智能工具选择等组件，能方便地与记忆、历史等模块集成，降低开发复杂度。当然，你也可以将其设计为独立的微服务，通过API与Agent核心通信，这在需要特定技术栈或极高定制化时是合理的选择。

5.3 意图识别是否使用LLM？两种路径的权衡

这是一个关键的架构决策。答案是：两种方案都存在，但使用（轻量级）LLM的方案正成为主流，因为它能更好地平衡成本与效果。

1. 传统规则方案（早期/简单场景）：

   • 做法：通过if-else、关键词、正则表达式判断。
   • 优点：速度极快、成本为零、完全可控。
   • 缺点：泛化能力差，无法理解复杂、模糊的用户表达，维护成本高。

2. 使用LLM的方案（当前主流）：

   • 做法：通常不是粗暴地将全部工具描述拼给LLM（Token成本高），而是采用更高效的方式：
     • 路径A（检索+LLM过滤）：先通过向量检索快速从上百个工具中召回Top N个候选工具，再将这些候选工具的描述交给一个轻量级、快速的LLM（如GPT-3.5-Turbo）做最终筛选或分类。这是精度和成本的绝佳平衡。
     • 路径B（直接LLM分类）：对于工具总数不多（例如少于50个）的场景，也可以直接将用户输入和工具分类描述交给小模型判断。
   • 优点：泛化能力强，能理解用户的各种自然语言表达，准确率高。
   • 结论：在专业的Agent系统中，意图识别层引入一次轻量级LLM调用，被认为是“值得的成本投入”，因为它能从根本上提升主流程的成功率，从整体上优化体验和成本。

5.4 复杂任务中的LLM调用循环：为何需要“两次”及以上的思考

在复杂任务处理中，你观察到的“至少两次LLM调用”的循环，是AI Agent从“理解”跨越到“执行”并最终“交付”的关键机制。这个 LLM → 工具执行 → LLM → ... 的链条，并非设计冗余，而是职责分离与工作流完整的必然要求。

为何需要多次LLM调用？

我们可以将一次完整的复杂任务分解为三个核心阶段，其工作流与数据转换过程如下图所示：

这个流程的必要性，根植于每次调用不可替代的独特价值：

1. 第一次调用：“指挥官”的价值（理解与规划）

   • 核心任务：将模糊、复杂的用户自然语言指令，翻译成明确、可执行的结构化计划。这本身就是一个高级的推理和决策过程。
   • 输出：决定调用哪个工具、参数是什么，在ReAct模式下还包括下一步的“思考”。
   • 不可替代性：只有LLM具备深度理解开放世界指令并做出初步规划的能力。系统代码无法直接“理解”用户意图。

2. 第二次调用：“分析师与发言人”的价值（综合与交付）

   • 核心任务：将工具返回的原始、冰冷、非人性化的数据（如JSON、数据库记录、API响应码），转化、综合、组织成连贯、友好、有价值的自然语言回答。
   • 关键动作：
     • 信息综合：当任务涉及多个工具时（如先查天气再规划行程），LLM需要将多个结果融合成一个连贯叙述。
     • 推理与洞察：基于数据进行简单推理（如“因为销量增长了30%，所以建议增产”）。
     • 格式化与对齐：使回答符合对话历史、用户偏好及系统设定的语气风格。
   • 不可替代性：直接向用户抛出一段{“product”: “A”, “sales”: 10000}的JSON是糟糕的体验。LLM在此充当了至关重要的“人机界面”角色。

简单来说，第一次调用解决“做什么”，第二次调用解决“怎么说”。 对于多步骤任务，这个“规划-执行-总结”的循环可能会重复多次，形成更长的链条。

关于优化与成本的讨论

虽然多次调用增加了成本与延迟，但这是实现复杂功能的基础。优化的目标不是盲目减少调用次数，而是 “让每次调用都更具价值，并避免不必要的调用” 。前沿优化策略主要围绕以下三个方向展开：

优化方向	具体策略	预期效果
流程优化	采用更高效的推理框架：如 Plan-and-Execute 让强大的LLM一次生成详细步骤计划，然后由廉价执行器按步执行，减少主LLM的反复调用。	减少总调用次数，尤其是昂贵大模型的调用。
模型优化	大小模型分工：意图识别、简单回复用轻量模型（如GPT-3.5-Turbo）；深度规划、复杂生成用重型模型（如GPT-4）。此即 “Cascading” 或 “模型级联” 技术。	显著降低单次任务平均成本。
架构优化	结果缓存与模板化：对常见、确定性的查询（如“查询A产品的标准参数”），将“工具结果→最终回答”的映射固化，或缓存LLM生成的答案，跳过第二次调用。	对特定高频任务实现近零延迟响应。

总结

因此，你对“至少需要两次LLM调用”的理解完全正确且深刻。这并非系统的低效，而是其能力强大的体现。它标志着AI Agent不再是简单的“问答机”，而是一个能够主动规划、与真实世界交互、并从交互中学习合成新知识的智能体。

未来Agent的智能化竞赛，将不仅是比拼核心LLM的能力，更是优化这一“思考-行动”循环效率的工程竞赛。 如何在保证任务完成质量的前提下，通过精妙的架构设计减少昂贵LLM的调用、降低延迟，是提升Agent实用性和经济性的关键。目前，Plan-and-Execute 模式与 大小模型分工 策略，正成为平衡性能与成本的主流选择。

5.5 RAG上下文管理：从“堆砌”到“精炼”的策略矩阵

对于RAG应用，上下文管理的目标是以最小成本提供最相关信息。以下是围绕检索流程的优化策略矩阵：

优化环节	核心策略	目的与效果	推荐技术/工具
检索前 (Query阶段)	查询重写/扩展：用LLM基于对话历史重写问题，使其更准确。	提升查询意图的清晰度。	LangChain的 QueryTransformer
	元数据过滤：根据文档来源、日期等属性预先筛选。	缩小检索范围，提升相关性。	向量数据库（如Weaviate, Pinecone）的过滤功能。
检索中 (Retrieval阶段)	混合检索：结合关键词（召回全）与向量检索（语义准）。	兼顾召回率与准确率。	LangChain的 EnsembleRetriever
	分层检索：先检索粗粒度文档，再在其内部检索细粒度片段。	提升精度，控制Token数。	LlamaIndex的 SentenceWindowNodeParser
检索后 (Post-processing)	重新排序：用小模型对召回结果二次打分排序。	让最相关文档排在最前。	Cohere的 rerank API， LangChain的 LLMChainFilter
	上下文压缩/提炼：用LLM从长文档中提取与问题最相关的片段。	直接节省核心Token，是王牌策略。	LangChain的 ContextualCompressionRetriever
系统级	对话记忆摘要：将多轮对话总结成要点，替代原始历史。	避免历史上下文无限膨胀。	自定义摘要链或使用框架内存模块。
	缓存机制：对常见问题缓存答案或上下文片段。	减少重复检索与计算，提速降本。	Redis, 或LangChain的缓存组件。

其核心理念是：将上下文视为宝贵资源，通过“检索前过滤+检索后精炼”的组合拳，确保最终交付给LLM的，是信息密度最高、相关度最强的“弹药”，从而以最小成本激发LLM的最大效能。

---

总结

通过对工具精选、意图识别、LLM调用循环和RAG优化的深入剖析，我们可以看到，现代AI Agent的成熟不仅体现在宏观架构（MCP/Skill）上，更依赖于这些微观工程实践的精雕细琢。让强大的LLM在清晰、精简、高相关性的信息和工具环境中工作，是构建高效、可靠、实用Agent的唯一路径。 这些实践共同构成了Agent从“玩具”走向“工具”的技术基石。

（本文是基于与deepseek的对话总结生成，其中包含了AI技术讨论与行业实践整理而成，旨在梳理核心脉络与解决方案，纯AI总结，自用。）