大型语言模型 (LLM) 与人工智能体 (Agent) 技术深度研究报告
- Published on
目录
- I. 大型语言模型 (LLM) 简介
- II. 人工智能体 (AI Agent) 基础
- III. 主流 AI Agent 架构与核心模块
- IV. AI Agent 与 Agentic Workflow (智能体工作流)
- V. AI Agent 的 LLM 模型选型
- VI. 主流 Agent 实现方案调研
- VII. 模型上下文协议 (Model Context Protocol, MCP)
I. 大型语言模型 (LLM) 简介
A. 定义 LLM:核心概念与能力
大型语言模型 (Large Language Models, LLMs) 是指能够执行多种自然语言处理 (Natural Language Processing, NLP) 任务的深度学习算法。这些模型通常基于 Transformer 架构,并通过在海量数据集上进行训练,从而获得识别、翻译、预测或生成文本及其他内容的能力。LLM 也被称为神经网络 (Neural Networks, NNs),其计算系统受到人脑结构的启发,通过分层的节点网络(类似于神经元)进行工作。
- 问答 (Question Answering):准确响应用户查询,例如
"什么是量子力学?"
。 - 文本摘要 (Summarization):将长篇文档提炼为结构化要点,如将《红楼梦》浓缩为核心情节列表。
- 多语言翻译 (Machine Translation):支持中英、法德等多语对互译。
- 代码生成 (Code Generation):根据需求自动生成代码示例,例如
def add(a, b): return a + b
。
应用示例:
- 科研领域: LLM 可用于自动撰写实验报告初稿,节省研究人员时间。
- 金融行业: 通过市场数据自动生成深度分析摘要,辅助决策。
B. 底层架构:Transformer 模型
Transformer 模型是 LLM 的主流架构,由 Vaswani 等人在其 2017 年的开创性论文《Attention is All You Need》中首次提出,被认为是深度学习领域的一个分水岭。与先前依赖循环和卷积层的序列处理模型不同,Transformer 模型独特地采用了注意力机制和前馈网络层 。
1. 编码器-解码器结构
完整的 Transformer 模型由编码器 (Encoder) 和解码器 (Decoder) 两部分组成。编码器负责将输入文本转换为一种中间表示,而解码器则将这种中间表示转换为目标输出文本。这种结构对于机器翻译等任务至关重要。然而,也存在一些变体:例如,仅编码器模型(如 BERT),用于文本分类或嵌入生成等任务;以及仅解码器模型(如 GPT 系列),主要用于文本生成。具体采用何种结构取决于 LLM 的主要应用场景。
下图是完整的 Transformer 包含一个编码器和一个解码器。基于 Transformer 的翻译器从编码器开始,生成英文句子的中间表示。解码器将该中间表示转换为法语句子。
2. 自注意力机制 (Self-Attention Mechanism)
自注意力机制是 Transformer 模型的核心创新,它允许模型在处理输入序列时,权衡序列中不同单词之间的相对重要性,从而捕捉上下文和依赖关系。该机制的核心问题可以概括为:“输入序列中的其他每个词符(token)对当前词符的解释有多大影响?” 。
这一机制使得模型能够理解语言的细微差别,解决歧义问题(例如,根据上下文“温暖”或“疲倦”判断代词“it”指代“垫子”还是“猫”),并且比 RNN 更有效地处理长序列。此外,多头注意力 (Multi-head Attention) 机制允许模型同时关注输入的不同方面,从不同角度捕捉信息。
下图是自注意力机制示意图,展示了句子 "The animal didn't cross the street because it was too tired." 中代词 "it" 与句子中其他词语(如 "animal", "street")的相关性权重,其中 "animal" 与 "it" 的相关性最高。
C. LLM 的工作方式:训练、微调与提示 (Prompting)
LLM 首先在包含数万亿单词的海量文本数据集上进行预训练,这一过程通常采用无监督学习(或称自监督学习)的方式。通过这种方式,模型学习语言的语法、知识以及单词之间的关系 。这个预训练阶段赋予了 LLM 对语言和世界的基本理解。训练数据的质量和多样性对模型性能有显著影响。
# 伪代码:预训练循环
for batch in corpus:
logits = model(batch_input)
loss = cross_entropy(logits, batch_target)
loss.backward()
optimizer.step()
为了使预训练的 LLM 适应特定任务(如翻译、情感分析),需要进行微调 (Fine-tuning)。
微调 (Fine-tuning):在特定领域或任务数据集上进一步训练,以获得针对性能力。
示例: 在法律判例语料上微调,提升法律文本理解与生成功能。
提示工程 (Prompt Engineering):通过设计高质量
prompt
实现零样本 (Zero-shot) 与少样本 (Few-shot) 推理:Zero-shot: 直接给出任务指令,如
"请将以下段落翻译为英文:..."
。Few-shot: 在 prompt 中嵌入示例(2-5 条),指导模型模仿完成相似任务。
Prompt 示例:
请将以下新闻摘要为三点: 示例1: ... -> 要点1... 示例2: ... -> 要点2... 现在请对文本“...”进行同样的提炼。
D. LLM 的类型与应用
根据其训练方式和目标功能,LLM 可以分为几类:
通用或原始语言模型 (Generic or raw language models),主要基于训练数据中的语言预测下一个词,适用于信息检索任务;
指令调优语言模型 (Instruction-tuned language models),经过训练以预测对输入指令的响应,能够执行情感分析或生成文本/代码;
对话调优语言模型 (Dialog-tuned language models),经过训练以通过预测下一个响应来进行对话,常见于聊天机器人或对话式 AI。
II. 人工智能体 (AI Agent) 基础
A. 定义 AI Agent:自主性与目标导向行为
人工智能体 (AI Agent) 是指利用人工智能来观察其所处环境、自主做出决策并执行任务,以达成特定目标的计算机程序或系统 。它们的核心特征在于能够在没有持续人工干预的情况下自主运作 。自主性和目标导向性是区分 AI Agent 的关键。与被动工具不同,智能体主动追求其既定目标。
B. AI Agent 的核心组件
AI Agent 的四个基本组件是感知 (Perception)、推理 (Reasoning)、行动 (Action) 和学习 (Learning) 。这些组件以持续循环的方式协同工作,这个循环通常被称为“智能体循环” (agent loop) ,是智能体运作和适应的基础。
1. 感知:感知环境
感知是指智能体通过其传感器(对于机器人等物理智能体)或数字接口(对于与 API、数据库或 Web 服务交互的软件智能体)收集和解释来自其周围环境的信息的能力。这包括收集关于环境当前状态的原始数据。感知是智能体的输入机制,为后续的决策制定提供原始数据。
2. 推理与规划:决策核心
推理过程涉及分析收集到的信息,识别模式,并得出结论,从而将原始数据转化为可操作的洞察。智能体用于推理的技术包括基于规则的系统、机器学习算法和神经网络 。规划则涉及制定策略或行动序列以实现既定目标 。这是智能体的“大脑”,它基于其感知和目标来决定“做什么”。
3. 行动:与环境交互
基于其推理结果,智能体采取物理行动(如机器人移动物体)或数字行动(如软件智能体生成报告或发送电子邮件),从而影响其环境 。物理智能体通过执行器 (actuators) 执行动作,软件智能体则通过软件命令执行。行动是智能体体现其决策并试图实现其目标的方式。
4. 学习:适应与改进
学习是指 AI Agent 通过经验提升其性能,适应新情况并优化其决策过程的能力。学习方式包括监督学习、无监督学习或强化学习。学习使得智能体能够变得更加有效和高效,适应变化的环境或用户偏好。
C. AI Agent 的分类
AI Agent 可以根据其能力和设计原理分为多种类型,常见的包括:
- 简单反射型智能体 (Simple Reflex Agents): 基于当前感知和预定义规则行动,没有对过去的记忆。例如,恒温器在温度低于阈值时启动加热。
- 基于模型的反射型智能体 (Model-Based Reflex Agents): 维护世界的内部模型,能够处理部分可观察的环境,并基于过去的经验做决策。例如,自动驾驶汽车使用传感器和地图数据导航。
- 基于目标的智能体 (Goal-Based Agents): 考虑期望的结果,使用规划和搜索算法来实现特定目标。例如,能够预判多步棋的国际象棋 AI。
- 基于效用的智能体 (Utility-Based Agents): 使用效用函数评估不同状态的可取性,优化以满足偏好,处理冲突目标。例如,权衡风险与潜在回报的交易机器人。
- 学习型智能体 (Learning Agents): 根据经验调整策略,随时间推移不断改进性能。例如,根据用户交互优化推荐的推荐系统。
- 其他类型: 还包括多智能体系统 (Multi-agent Systems, MAS)、分层智能体 (Hierarchical Agents)、认知智能体 (Cognitive Agents) 和具身智能体 (Embodied Agents) 。
表1:AI Agent 类型、特征及示例
Agent 类型 | 特征 | 示例 |
---|---|---|
简单反射型智能体 | 对刺激立即做出反应,无内部状态或记忆,基于预定义的条件-行动规则 | 温度低于阈值时自动开启暖气的恒温器 |
基于模型的反射型智能体 | 拥有环境的内部表示,能处理部分可观察的环境,可基于过去的经验做决策 | 使用传感器和地图数据导航的自动驾驶汽车 |
基于目标的智能体 | 有明确定义的目标,能够规划行动序列,评估潜在结果 | 能够预判多步棋的国际象棋 AI |
基于效用的智能体 | 使用效用函数评估结果,能够在复杂场景中平衡多个目标,做出最优决策 | 权衡风险与潜在回报的 AI 驱动的金融交易系统 |
学习型智能体 | 能够从经验中学习,性能持续改进,适应变化的环境 | 根据用户交互不断优化推荐结果的推荐系统 |
III. 主流 AI Agent 架构与核心模块
A. 关键架构模块
1. 感知模块 (输入处理与理解)
感知模块负责收集和解释来自环境的输入,这些输入可能包括用户消息、系统日志或通过 API 获取的外部数据 。对于基于语言的智能体,此过程涉及自然语言处理 (NLP) 任务,如分词、意图提取、实体识别,以及将输入转换为结构化数据。该模块是智能体的“感官”,其准确理解用户意图和环境状态的能力对后续的规划和行动至关重要。LLM 本身就为该模块提供了强大的能力。
2. 记忆与上下文存储 (短期、长期、外部)
智能体需要记忆来存储和检索信息,这包括用于当前会话上下文的短期记忆、用于存储过去交互和学习知识的长期记忆,以及访问外部记忆(如数据库、API、知识图谱)的能力。向量数据库常用于对嵌入向量进行语义搜索。记忆对于实现上下文感知行为、学习以及避免重复错误至关重要。短期记忆辅助正在进行的任务,而长期记忆则支持个性化和持续改进。集成外部知识源的能力显著扩展了智能体在其预训练知识之外的能力。记忆模块被认为是智能体的“认知支柱” 。
3. 规划与推理引擎
这是智能体的“大脑”,它根据感知到的上下文和既定目标来决定采取哪些步骤。它可以将复杂的查询分解为较小的任务,并对它们进行排序。规划器可以是静态的(基于规则)或动态的(基于 LLM 进行实时规划)。LLM 的推理能力在该模块中得到充分体现,它制定策略、处理任务分解并确定操作顺序。基于 LLM 的动态规划允许对新情况具有更大的灵活性和适应性。
4. 决策模块
决策模块评估规划器生成的各种可能的后续步骤,并选择最有效的一个。这与规划(提供选项)不同,因为它涉及选择一个具体的行动。它可能使用效用函数、偏好模型或强化学习模型来对选项进行排序 。如果规划阶段生成了多个潜在路径,决策模块会根据预定义标准或学习到的偏好选择最优路径。
5. 执行层与工具使用 (行动引擎)
这是系统的“肌肉”,负责执行选定的行动 。行动可以包括发送 HTTP 请求、运行本地函数、查询数据库或调用外部工具/API 。基于工具的架构(例如 LangChain, CrewAI)将函数封装为智能体可以调用的“工具” 。该模块允许智能体与其环境(包括通过 API 的数字环境)交互并施加影响。使用工具的能力是现代 AI Agent 的一个决定性特征,使其能够克服 LLM 的局限性(例如,访问实时数据、执行计算)。例如,一个 LLM Agent 可能会使用特定的天气 API 来获取准确信息 。
6. 学习与反馈循环
随着交互的积累,学习与反馈循环不断优化智能体的理解和性能。它可以根据反馈(通过强化学习、监督学习、人机协同或自我批判)改进意图分类、响应质量或调整目标策略。这使得智能体能够从反应式转变为适应式 ,持续提高其有效性和效率。
IV. AI Agent 与 Agentic Workflow (智能体工作流)
A. 定义 Agentic Workflow:超越单个智能体
Agentic Workflow (智能体工作流) 是指由自主的 AI Agent 做出决策、采取行动并协调任务,以最少的人工干预来执行复杂任务的 AI 驱动过程,这些过程利用了推理、规划和工具使用等智能体核心组件 。它们以多步骤、迭代的方式处理问题 。智能体工作流是一个比单个 AI Agent 更高层次的概念,它代表一个使用一个或多个 AI Agent 来实现更广泛目标的系统或过程。与遵循预定义规则的传统自动化(如机器人流程自动化 RPA)不同,智能体工作流是动态的,能够适应实时数据和意外情况 ,这突出了智能体工作流相比旧有自动化范式所带来的灵活性和智能性。
B. 关键区别:自主性、复杂性、主动性、多智能体协作
- AI Agent: 通常是一个为特定任务设计的单一自主实体。它在预定义的框架内运作,但可以根据学习到的模式和输入进行调整 。其行为往往是被动响应式的。
- Agentic Workflow / Agentic AI: 协调多个步骤或多个智能体。它使用多个智能体来处理复杂的工作流,并能实时学习和适应。这类系统更具主动性,能够识别战略目标 ,涉及更高阶的推理、动态任务分解,并可能包含多智能体协作。
正如一些分析所指出的,“虽然 AI Agent 可以被视为构建模块,但 Agentic AI 是一个更复杂的设置,它将所有构建模块组合在一起,允许多个智能体协同工作以实现组织的宏大目标” 。研究同样强调,AI Agent 通常是用于执行目标导向任务的单实体系统,而 Agentic AI 系统(通常实现智能体工作流)则由多个协调运作的专业智能体组成 。Agentic AI 甚至可能决定“它应该设定什么目标”或如何对多个目标进行优先级排序,这比 AI Agent 执行给定任务更进了一步 ,指向了智能体系统中更高层次的战略自主性。
C. Agentic Workflow 的核心组件
Agentic Workflow 的关键组件包括:AI Agent(作为主要行动者)、LLM(作为智能体的核心)、工具(用于获取训练数据之外的信息)、反馈机制(人机协同或其他智能体)以及提示工程(对性能至关重要)。多智能体协作和数据集成也同样重要 。这些组件表明,智能体工作流是一个精心编排的系统,其中 AI Agent 是主要参与者,但其有效性依赖于 LLM、工具的可用性以及设计良好的交互协议。
D. Agentic Workflow 中的常见设计模式
领域专家 Andrew Ng 确定了四种常见的智能体工作流设计模式:
- 规划 (Planning): AI 模型自主决定为达成某一目标所需的任务序列;基于用户查询进行任务分解(例如,撰写一篇关于肠道微生物组的文章可能分解为:询问主题细节、长度、受众和内容要求;进行网络研究;综合发现;然后生成和完善文章)。
- 工具使用 (Tool Use): 与外部服务或资源(API、网页浏览、数据库)交互以执行某些任务,包括查找信息、完成操作或编辑数据库。智能体系统会选择使用哪种工具 。
- 反思 (Reflection): 通过迭代提示让 AI 模型优化其针对特定任务的输出(自我批判或使用另一个智能体提供反馈)。
- 多智能体协作 (Multi-agent Collaboration): 多个专业智能体协同工作,可能由一个主要/协调智能体进行协调 。
V. AI Agent 的 LLM 模型选型
A. 选型标准
为 AI Agent 选择合适的 LLM 是一个关键决策,它会影响性能、成本和用户体验。关键的考虑因素包括 :
- 任务复杂度: 复杂的推理、研究或创造性任务可能需要更高准确度的模型(即使它们更慢或更昂贵)。对于更简单、常规的任务,速度更快、准确度中等的模型可能就足够了。
- 响应时间要求: 需要实时交互的应用(例如面向客户的机器人)需要快速响应的模型。
- 上下文需求: 处理长文档或需要维持扩展对话的应用,应选择具有较大上下文窗口的模型。
- 预算约束: 不同模型的成本差异很大。免费或低成本的选项适合初创企业或高流量应用,而对于准确性至关重要的任务关键型企业应用,则可能需要选用价格较高的模型。
- 特定能力: 一些模型在特定任务上表现出色,如代码生成、多模态理解或多语言支持。
- 工具处理、函数调用、精细控制: 对于需要与外部系统交互的智能体至关重要 。
- 部署环境: 内部工具与面向客户的应用、受监管行业等因素也会影响模型选择 。
选择 LLM 并非一刀切的决定,它涉及基于 AI Agent 的具体需求及其预期应用的权衡分析。重要的是根据业务目标而非仅仅是原始规格来定制选择 。
B. Agentic系统中LLM的关键评估指标
评估 LLM 在 Agentic 系统中的适用性时,指标应具备量化性、可靠性和准确性(与人类期望一致)。
性能与输出质量 :
- 准确性 (Accuracy): 工作流选择和执行的精确度,任务成功率,问答准确性,(基于基准事实的)正确性。
- 延迟/响应时间 (Latency/Response Time): 任务执行/响应生成的速度。
- 相关性 (Relevance): 与用户查询的相关程度,答案相关性(是否以信息丰富且简洁的方式回应输入),上下文相关性(针对 RAG 系统)。
- 流畅性与连贯性 (Fluency & Coherence): 生成文本的自然流畅度和可读性(例如使用 Perplexity, Coh-Metrix 指标)。
- 幻觉率 (Hallucination Rate): 产生事实不正确或不合逻辑陈述的频率。
- 任务完成度 (Task Completion): 智能体是否完成了其设定的任务。
- 稳定性 (Stability): 模型在不同输入、领域和操作条件下的稳健性。
安全性与责任 :
- 毒性 (Toxicity): 输出内容中是否不含攻击性或有害内容。
- 偏见 (Bias): 通过差异分析识别和减轻模型响应中的偏见。
用户体验指标 :
- 用户满意度 (User Satisfaction): 通过用户反馈和参与度衡量。
- 错误恢复能力 (Error Recovery): LLM 处理错误或误解的能力。
基准测试工具/技术 :
- BLEU 分数: 用于评估翻译任务中机器翻译文本与人工参考翻译的相似度。
- ROUGE 分数: 用于评估摘要任务中模型生成摘要的质量。
- TruthfulQA, LLM-as-a-Judge: 用于评估模型真实性和进行模型辅助评估的模板/方法。
需要一个全面的评估框架。值得注意的是,模型评估(使用 MMLU 等指标评估 LLM 在多任务上的整体性能)与系统评估(针对智能体的特定性能)有所区别 。对于智能体而言,任务完成度、工具使用准确性和上下文相关性等指标尤为重要。
C. 主流 LLM 在 Agent 开发中的比较
下表综合了文献 的信息,对当前主流 LLM 在 AI Agent 开发中的适用性进行了比较,重点关注其在推理能力、上下文长度、工具调用、速度以及成本等方面的表现,并列举了理想的智能体应用场景。
表2:主流 LLM 在 AI Agent 开发中的比较
模型名称 | 供应商 | 针对 Agent 的关键优势 | 相对成本 | 理想的 Agent 应用场景 |
---|---|---|---|---|
GPT-4o | OpenAI | 多模态能力,强大的推理和编码,良好的工具调用能力 | 3 | 多模态助手(文本、音频、图像),复杂推理和编码任务,对成本敏感的部署 |
GPT-4 Turbo | OpenAI | 卓越的推理能力,确定性函数调用,长上下文,结构化输出 | 较高 | 企业级 Copilot,工具密集型工作流,多模态支持,RAG 流水线,需要审计追踪的受监管环境 |
o1 (GPT-4 级别) | OpenAI | 极高的准确性,适用于科学、数学、编码等高度复杂问题 | 4 | 高级战略或研究规划,可接受高延迟/成本以换取卓越准确性的场景 |
o1 Mini | OpenAI | 较好的速度和准确性平衡,适用于成本敏感且需要一定推理能力的场景 | 1 | 需要平衡成本与性能的通用任务,交互式助手 |
Claude 3 Opus | Anthropic | 极佳的上下文长度处理能力,可靠性高,安全性对齐 | 9 (相对较高) | 文档分析,复杂推理任务,长篇内容总结或生成,法律、人力资源、研究等需要多文档参考的工作流 |
Claude 3 Sonnet | Anthropic | 良好的长上下文处理,有益的语气,平衡性能与成本 | 中等 | 需要处理较长输入且注重交互体验的内部操作,如长工单解决 |
Gemini 2.0 Pro | 专家级代码生成和调试,复杂提示处理和多步推理 | 5 | 需要最高准确性的前沿研究应用,复杂的编码和数学问题解决 | |
Gemini 2.0 Flash | 快速响应,良好的准确性和极长的上下文窗口 | 1 | 交互式智能体和聊天机器人,处理大量输入,需要良好推理能力且成本最低的通用任务 | |
Gemini 1.5 Pro | 极长的上下文窗口 (1M tokens),与 Google Cloud 工具原生集成 | 中等 | 结合视觉、长文本和结构化函数调用的多模态智能体 | |
Gemini 1.5 Flash | 快速,可处理长输入,成本低,通用任务的良好推理能力 | 1 | 实时助手和聊天服务,处理长输入,需要体面推理且成本最低的通用任务 | |
Mistral Large | Mistral AI | 强大的推理能力,多语言支持 | 中等 | 需要高性能推理和多语言能力的复杂任务 |
Mistral 7B / Mixtral | Mistral AI | 高效性能,优秀的本地托管能力 | 较低/开源 | 轻量级智能体,部署于安全环境(如制造业、BPO),需要低延迟、无云依赖或严格数据控制的企业 |
Gemma 7B It | 开源,适用于需要成本效益和一定推理能力的场景 | 0 (开源) | 研究和开发,需要本地部署或预算有限的场景 |
不同的应用场景需要不同的权衡。例如,一个高度复杂的研究型智能体可能会优先考虑准确性和上下文长度(如 Claude 3 Opus, GPT-4 Turbo),而非成本和速度;而一个实时的客户服务智能体则可能更看重速度和成本效益(如 Gemini 1.5 Flash, o1 Mini)。有效调用工具和处理长对话上下文的能力对于智能体尤为关键。
VI. 主流 Agent 实现方案调研
A. Agent 构建框架
1. Langchain
Langchain 是一个开源 Python 框架,旨在通过提供模块化工具、提示模板、向量存储、检索器、索引和智能体等组件,简化使用 LLM 构建 AI 应用的复杂工作流程 。其核心目标是弥合 LLM 本身无法直接行动或访问实时/业务特定数据的差距 ,从而创建具备上下文感知和推理能力的应用。
a. 设计理念与核心组件
Langchain 的设计理念强调模块化和可组合性,使 LLM 能够连接到其他数据源并与其环境交互 。其核心组件包括 :
- Langchain-core: 提供基础抽象和 LangChain 表达式语言 (LCEL),是构建复杂认知架构的支柱。
- Langchain-community: 通过与第三方系统的集成,增强 Langchain 的功能,实现与外部服务的无缝交互。
- Langchain (主包): 包含链 (Chains)、智能体 (Agents) 和检索策略 (Retrieval strategies),这些对于塑造应用的认知架构至关重要。
- 链 (Chains): 一系列调用的序列(调用 LLM 或其他实用程序)。
- 智能体 (Agents): LLM 根据输入、上下文和可用资源决定采取何种行动,执行行动,观察结果,然后重复此过程。智能体依赖工具来与外部世界交互。
- 记忆 (Memory): 在链或智能体的多次调用之间持久化状态。
- 工具 (Tools): 智能体可以用来与世界交互的函数(例如 API、数据库)。
- 回调 (Callbacks): 允许在 LLM 应用的内置组件中执行自定义的辅助代码,用于流式传输 LLM 输出、追踪应用中间步骤等。
- LangChain 表达式语言 (LCEL): 一种用于声明式地组合链的语法,简化了原型部署并提升了开发效率 。
这些组件允许开发者通过连接 LLM、数据源和自定义逻辑来构建复杂的应用程序。LCEL 对于定义自定义执行流程尤为重要。
b. 工作原理与简单应用示例
一个简单的 Langchain 应用示例可以说明其工作原理。首先,定义一个工具,例如一个执行乘法运算的自定义工具 :
from langchain_core.tools import tool
@tool
def multiply(first_int: int, second_int: int) -> int:
"""Multiply two integers together."""
return first_int * second_int
然后,初始化一个 LLM(例如 OpenAI 的 gpt-4o-mini),并使用 bind_tools 方法将该工具的定义传递给 LLM,以便模型在适当时可以调用该工具 。
# 假设 llm 已被初始化为 ChatOpenAI(model="gpt-4o-mini")
llm_with_tools = llm.bind_tools([multiply])
当用户发出一个需要使用该工具的请求时(例如,“5 乘以 42 是多少?”),LLM 会在其响应的 tool_calls 属性中生成工具调用信息。开发者可以解析这些信息,提取参数并实际调用工具函数,然后将工具的输出反馈给 LLM 或智能体,以形成最终答案 。
对于更复杂的场景,可以使用 Langchain Agent。例如,一个使用 TavilySearchResults 工具进行网络搜索并具备对话记忆功能的 Agent 可以通过 langgraph.prebuilt 中的 create_react_agent 来构建。
# 伪代码示例
from langchain_anthropic import ChatAnthropic
from langchain_community.tools.tavily_search import TavilySearchResults
from langgraph.checkpoint.memory import MemorySaver
from langgraph.prebuilt import create_react_agent
model = ChatAnthropic(model_name="claude-3-sonnet-20240229")
search_tool = TavilySearchResults(max_results=2)
tools = [search_tool]
memory = MemorySaver()
agent_executor = create_react_agent(model, tools, checkpointer=memory)
response = agent_executor.invoke(
{"messages": [("user", "旧金山现在天气怎么样?")]},
config={"configurable": {"thread_id": "some_conversation_id"}}
)
在这个流程中:
- 用户提供一个需要工具使用的提示。
- Agent (由 LLM 驱动) 决定调用哪个工具以及使用什么参数。
- 执行工具并将结果返回给 Agent。
- Agent 使用工具的结果来形成最终答案。
- 如果配置了记忆模块,对话历史可以被保存,允许进行多轮对话和上下文相关的后续提问。
2. AutoGen (Microsoft)
AutoGen 是微软开发的一个开源框架,用于构建 AI Agent 和应用,通过对话式 Agent 促进多 Agent 协作 。它简化了复杂 LLM 工作流的编排、自动化和优化 。AutoGen 的核心优势在于使多个通常具有不同角色和能力的 Agent 能够通过相互“交谈”来协同工作。
a. 架构:独立与分布式运行时
AutoGen 为 Agent 通信、生命周期管理和安全提供了运行时环境 :
- 独立运行时 (Standalone Runtime): 适用于所有 Agent 都在同一进程中运行的单进程应用(例如 SingleThreadedAgentRuntime)。Agent 通过此运行时经由消息进行通信。
- 分布式运行时 (Distributed Runtime): 由一个主机服务方 (Host Servicer) 和多个工作方 (Workers) 组成。主机服务方负责协调跨工作方的 Agent 通信并维护连接状态。工作方运行 Agent 并通过网关 (Gateways) 与主机服务方通信。
b. 特性
AutoGen 的主要特性包括:可对话的 Agent、LLM 和工具使用支持、自主和人机协同工作流、多样化的多 Agent 对话模式(例如,为编码员、规划员、审查员等角色扮演定义的 Agent)、用于 UI 驱动工作流设计的 AutoGen Studio。它还支持 MCP 服务器和 Docker 代码执行等扩展 。这些特性使得可以灵活构建复杂的多 Agent 应用,其中 Agent 可以协作、批判和迭代以解决问题。
c. 优缺点与应用场景
- 优点: 非常适合动态 Agent 协作,拥有先进的消息传递框架,在大型对话系统中表现出色,由微软支持,提供 GUI 工具 (AutoGen Studio) 以实现快速原型设计,适用于分布式系统和并行处理。
- 缺点: 可能消耗大量资源,多 Agent 系统中存在 AI Agent 失败的潜在风险 。与 LangChain 相比,其对标准化的侧重可能会限制深度定制。
- 应用场景: 具有明确角色的协作型 AI Agent,通过对话流实现任务自动化,多 Agent 编排,多 Agent 协作研究,复杂推理任务 。
3. CrewAI
CrewAI 是一个 Python 框架,用于编排角色扮演型的自主 AI Agent。它专为协作智能而设计,其中 Agent 们以特定的角色、工具和目标协同工作。该框架独立于 LangChain。CrewAI 专注于创建 AI Agent “团队”,模仿人类团队的动态来处理复杂任务。
a. 架构:Agent、任务、工具、流程、团队 (Crew)
CrewAI 的核心组件包括 :
- Agent (智能体): 具有已定义角色、专业知识、目标和背景故事的专业化实体,可以配备工具。
- Task (任务): 分配给 Agent 的具体作业,具有清晰的指令和预期输出。
- Tool (工具): Agent 可以使用的函数(类似于 LangChain 中的工具)。
- Process (流程): 定义团队如何协作(例如,顺序型、层级型)。
- Crew (团队): 组织 Agent,分配任务,并管理整个工作流程。
- CrewAI Flows: 支持精细的、事件驱动的控制和单 LLM 调用,以实现精确的任务编排,并原生支持 Crew。
b. 特性
CrewAI 的主要特性包括:类人的基于角色的协作,用于多智能体系统的直观 API,内置的流程管理,灵活的工具集成,以及任务管理(支持顺序或并行工作流)。其重点是使多智能体协作易于定义和管理。
c. 优缺点与应用场景
- 优点: 直观的基于角色的 API,协作型系统开发速度快,样板代码少,自然语言任务描述。非常适合受益于不同视角和涌现性思维的任务。
- 缺点: 对于高度复杂、非线性的工作流,灵活性可能不如 LangGraph;当 Agent 数量较多时,可能会有较高的延迟;自定义工具的学习曲线较陡峭。
- 应用场景: 市场调研,内容创作流水线,旅行规划,代码文档生成 。适用于协作智能和角色专业化能带来益处的任务。
B. 值得关注的 Agentic 系统与产品
1. Microsoft JARVIS (实为 Outshift JARVIS)
由 Outshift by Cisco 开发的 JARVIS 是一种用于平台工程的智能体 AI 方法。它使用 LangGraph 实现了一个分层主管型多智能体系统 (hierarchical supervisor multi-agent system) 。
a. 架构
- 主管智能体 (Supervisor Agent) (语义路由器 Semantic Router): 解释用户请求,并将任务委派给专门的策划智能体 (Curated Agents) 。
- 策划智能体 (Curated Agents, CAs): 针对特定领域(如 Jira, PagerDuty, GitHub)进行特化,采用 ReAct (Reason-and-Act) 范式 。
- 反思智能体 (Reflection Agent): 使用 LLM-as-a-judge 模式评估响应,如果响应不完整则将其路由回主管智能体,或最终确定响应 。
该架构强调专业化、分层控制以及通过反思进行的迭代优化。
b. 关键技术
JARVIS 依赖 LangGraph 进行编排,并使用 AGNTCY Agent Connect Protocol 进行分布式智能体通信 。这表明其构建依赖于像 LangGraph 这样的框架和标准化协议,以实现稳健的多智能体系统。
2. BabyAGI
BabyAGI 是一个早期的多智能体系统,它使用 LLM 进行任务管理、记忆和学习,旨在模仿人类的思维和学习过程 。BabyAGI 展示了由 LLM 驱动的自主任务分解和执行的潜力。
a. 核心架构
BabyAGI 的核心组件包括 :
- LLM: 作为推理引擎,负责任务分解、规划和提出新任务。
- 向量数据库 (Vector Database): 用作长期记忆,存储已完成的任务和结果(使用嵌入进行语义搜索)。
- 任务列表 (Task List) (队列): 管理工作流程,存储待办任务。
- 执行智能体 (Execution Agent): 使用 LLM 和记忆来执行任务。
- 任务创建智能体 (Task Creation Agent): 根据当前任务的结果和总体目标生成新任务。
- 优先级排序智能体 (Prioritization Agent): 使用 LLM 对任务列表重新排序。
BabyAGI 通过这些组件的持续循环来运作:用户提供一个目标,LLM 将其分解为任务并添加到任务列表。执行智能体选择一个任务,利用 LLM 和从向量数据库中获取的上下文(相关任务的结果)来完成它。结果被存储起来。创建智能体根据结果生成新任务。优先级排序智能体对列表进行重新排序。这个循环不断进行 。
值得注意的是,有文献指出 BabyAGI 的创建者承认其最初并非“真正的”多智能体系统,因为所有智能体共享同一个 LLM、代码库和服务器,但后来通过 Naptha SDK 等工具已将其实现为真正的多智能体系统 。这凸显了多智能体系统定义和实现的演变。
3. 其他有影响力的商业 AI Agent 产品概览 (2024-2025)
除了上述框架和特定系统外,市场上还涌现了许多有影响力的商业 AI Agent 产品。下表概述了其中一部分。
表3:其他有影响力的商业 AI Agent 产品 (2024-2025)
产品名称 | 供应商/开发者 | 专业领域/应用范畴 | 关键 Agentic 特性 | 主要 LLM (若已知) |
---|---|---|---|---|
Otter.ai | Otter.ai | 生产力 (会议转录与总结) | 实时转录,自动总结,协作功能 | 未明确 |
Kompas AI | Kompas AI | 商业智能 | 数据集成,可定制 Agent,分析与决策支持 | 未明确 |
GitHub Copilot X | GitHub / OpenAI | 编码与开发 | 上下文感知代码建议,PR 自动化,自然语言理解 | Codex (OpenAI) |
ChemCrow | 未明确 (研究项目) | 医疗与科学 (化学) | 化学结构分析,反应预测 | 未明确 |
GPT Researcher | 未明确 (开源项目) | 研究与分析 | 自主执行详细的互联网研究 | GPT 系列 |
Salesforce Einstein GPT | Salesforce | 客户关系管理,销售 | 个性化内容生成,任务自动化,数据驱动洞察 | GPT 系列 (定制) |
OpenAI Swarm | OpenAI | 多智能体系统平台 | Agent 编排,协作任务解决 | GPT 系列 |
Microsoft Magentic AI | Microsoft | 多智能体系统平台 | Agent 管理与部署,企业级应用 | Azure OpenAI |
Chatbase AI Agents | Chatbase | 客户服务 | 自动化客户支持工单处理,问题解决 | 未明确 |
Find AI | Find AI | 销售与市场营销 | 基于用户意图和行为的潜在客户生成 | 未明确 |
Google Health AI | 医疗与科学 | 辅助疾病识别,提升诊断效率 | Google LLMs | |
Netflix Recommendation | Netflix | 娱乐 | 基于用户行为的个性化内容推荐 | 自有模型 |
NinjaTech AI | NinjaTech AI | 多用途 | 图像生成,日程安排,代码辅助等 | 未明确 |
AIlice (MyShell) | MyShell | 多用途 | 主题研究,编码,系统管理 | 未明确 |
VII. 模型上下文协议 (Model Context Protocol, MCP)
A. MCP 简介:标准化 Agent-Tool 交互
模型上下文协议 (Model Context Protocol, MCP) 是由 Anthropic 开发的一项开放协议,旨在标准化应用程序(包括 AI Agent)向 LLM 提供上下文(数据和工具)以及与外部系统交互的方式。它被比作“AI 应用的 USB-C 端口” 。MCP 的目标是解决当前 LLM/Agent 与其可能需要访问的大量工具和数据源之间存在的自定义、临时集成的问题,提供一种通用的语言或接口。
B. MCP 架构:客户端-服务器模型 (主机、客户端、服务器)
MCP 采用客户端-服务器模型 。其核心组件包括:
- 主机 (Hosts): 发起连接的 LLM 应用程序(例如 Claude Desktop、IDE 或 AI Agent)。
- 客户端 (Clients): 位于主机应用程序内部的协议客户端/适配器,与服务器维持 1:1 连接 。在实践中,AI 应用程序/主机通常被直接称为“MCP 客户端” 。
- 服务器 (Servers): 通过 MCP 协议暴露特定功能(数据、工具、提示)的程序/工具提供者 。
这意味着,一个 AI Agent(作为主机)会使用一个 MCP 客户端组件来与一个封装了特定工具(例如 Gmail API、数据库)的 MCP 服务器进行通信。这种方式将 Agent 与工具的具体实现细节解耦。
C. 消息类型与连接生命周期
MCP 的通信机制如下:
消息类型:
请求 (Requests): 期望对方响应的消息,通常包含 method (方法名) 和可选的 params (参数)。
结果 (Results): 对请求的成功响应。
错误 (Errors): 表明请求失败的消息,包含 code (错误码)、message (错误信息) 和可选的 data (附加数据)。
通知 (Notifications): 单向消息,不期望响应。 每种消息类型都有定义的结构。
连接生命周期:
初始化 (Initialization): 客户端发送 initialize 请求(包含协议版本和自身能力),服务器响应(包含其协议版本和能力),客户端发送 initialized 通知以确认建立连接。 消息交换 (Message Exchange): 建立连接后,客户端和服务器之间可以进行请求-响应和通知类型的消息交换。 终止 (Termination): 连接可以由客户端或服务器通过正常关闭流程或因断开、错误等情况而终止。