HuggingGPT vs RestGPT：让大模型学会“调用工具”的两种经典范式

zmrm_123

394人浏览 · 2026-03-19 21:11:58

zmrm_123 · 2026-03-19 21:11:58 发布

📝 写在前面

2023年是AI Agent爆发的一年，HuggingGPT和RestGPT是其中两个非常有代表性的工作。它们回答了一个共同的问题：大语言模型（LLM）很聪明，但它只能输出文字，怎么让它真正“做事”？

本文不讲复杂的公式，用大白话和例子，带你理解这两个框架的核心思想，并以2026年的视角回看它们对行业的深远影响。

一、为什么需要HuggingGPT和RestGPT？

1.1 LLM的“手无缚鸡之力”困境

想象一下：

你让ChatGPT：“帮我把这张图里的文字翻译成英文，然后念给我听。”

ChatGPT能做什么？

✅ 理解你的需求
✅ 用文字回答你
❌ 不能直接识别图片
❌ 不能直接翻译
❌ 不能直接朗读

问题出在哪？ LLM是语言模型，它擅长的是“思考”和“说话”，而不是“动手干活”。

1.2 解决方案的思路

那怎么办？一个很自然的想法是：让LLM当“指挥官”，调用各种专业的工具来干活。

就像人类一样：

你不会修车，但你知道找修车师傅
你不会做饭，但你知道点外卖
LLM不会图像识别，但它可以调用图像识别模型

HuggingGPT和RestGPT就是基于这个思路，让LLM学会“调用工具”。

二、先理解两个基础思想：ReAct 和 Plan-and-Execute

在深入HuggingGPT和RestGPT之前，需要先了解两个更基础的“思考框架”。这两个框架是所有AI Agent的底层逻辑。

2.1 ReAct：边想边做

核心思想：思考→行动→观察→再思考→再行动……循环往复。

打个比方：
你在一个陌生的商场里找某家店：

思考：我应该往哪边走？
行动：往前走几步
观察：看到指示牌，发现方向不对
再思考：应该往反方向走
再行动：转身继续走
观察：终于看到了那家店

特点：

✅ 灵活，能根据实时反馈调整
❌ 可能走弯路，token消耗大

2.2 Plan-and-Execute：先想好再做

核心思想：先制定完整计划，然后按计划执行。

打个比方：
你要从北京去上海旅游：

规划：先查好路线→订机票→订酒店→列景点清单
执行：按计划一步步来

特点：

✅ 全局视野，步骤可控
❌ 计划赶不上变化，遇到意外可能卡住

2.3 两者的关系

在实际系统中，往往混合使用：

高层用Plan-and-Execute把控整体流程
低层用ReAct处理具体步骤的灵活性

三、HuggingGPT：AI模型的“调度中心”

3.1 它要解决什么问题？

HuggingFace上有几十万个AI模型：

图像识别的
语音合成的
翻译的
画图的
……

每个模型都是某个领域的“专家”。但问题是：用户怎么让这些专家协同工作？

用户需求往往是跨领域的：

“把这张图里的文字翻译成英文，然后念给我听”

这需要：图像识别专家 + 翻译专家 + 语音合成专家

3.2 核心思想：LLM当大脑，模型当专家

HuggingGPT的解决方案很简单：让LLM当“总指挥”，从HuggingFace上挑合适的模型来干活。

（上图展示了HuggingGPT的四步流程：规划→选模型→执行→汇总）

3.3 举个例子

用户输入：“生成一个女孩看书的图片，然后用声音描述这张图片”

HuggingGPT的处理流程：

步骤	做什么	具体内容
1. 任务规划	拆解需求	子任务1：生成图片子任务2：图像描述子任务3：语音合成
2. 模型选择	选合适的模型	图片生成：选Stable Diffusion 图像描述：选BLIP模型语音合成：选Tacotron2
3. 任务执行	调用模型	依次调用三个模型，后一个依赖前一个的输出
4. 结果汇总	整合输出	生成图片 + 生成音频，返回给用户

3.4 关键技术点

模型选择怎么做？

需要澄清一点：LLM并不是实时去爬取HuggingFace网站。在实际实现中，系统会预先构建一个模型库索引，包含热门模型的元数据（名称、任务类型、功能描述、下载量等）。LLM基于这个索引（而不是整个互联网）来做选择。

大致流程：

系统把HuggingFace上热门模型的元数据组织成可检索的形式（向量数据库或结构化列表）
当有任务时，LLM从索引中筛选出最匹配的候选模型
综合考虑：功能描述匹配度、下载量（作为质量信号）

这样做的好处：

✅ 速度快（不需要实时爬取）
✅ 可控性强（可以过滤低质量或未测试的模型）
✅ token消耗可控

任务依赖怎么处理？

用dep字段标记依赖关系
例如：任务2依赖任务1的输出，就等任务1完成后再执行任务2

执行效率问题？

实际执行时，模型已经提前部署好（本地或云端）
高频模型常驻内存，低频模型走API调用

3.5 解决了什么问题？

问题	HuggingGPT的解决方案
单一模型能力有限	整合成千上万个专业模型
多模态任务割裂	自动拆解任务，协调多个模型
模型选择困难	LLM基于索引自动选模型
能力扩展难	HuggingFace每增加一个新模型，系统就多一项技能

四、RestGPT：真实世界的“API调用大师”

4.1 它要解决什么问题？

现实世界中有无数RESTful API：

Spotify听歌API
TMDB查电影API
Twitter发推API
Gmail发邮件API

如果LLM能调用这些API，就能真正操作真实世界的应用。

但难点在于：

API太多，每个参数规则不同
返回的JSON可能嵌套几十层
需要根据上下文动态调整

4.2 核心思想：三模块架构 + Coarse-to-Fine规划

RestGPT的核心创新在于Coarse-to-Fine（由粗到细）的分层规划：

粗粒度规划：先生成高层计划（比如“搜导演→找电影→查评分”）
细粒度执行：在执行每一步时，再根据API文档动态细化具体参数

这种分层设计既保持了Plan-and-Execute的全局视野，又融入了ReAct的灵活性。

具体由三个模块实现：

（上图展示了RestGPT的三模块架构和Coarse-to-Fine规划的闭环流程）

4.3 举个例子

用户输入：“在Spotify上创建一个歌单，包含周杰伦的所有热门歌曲，歌名叫‘周董经典’”

RestGPT的处理流程：

步骤	谁来做	做什么
1. 粗规划	Planner	需要三步：搜周杰伦→找热门歌→创建歌单
2. 选API	API Selector	搜周杰伦：用`GET /search?q=周杰伦` 找热门歌：用`GET /artists/{id}/top-tracks` 创建歌单：用`POST /users/{id}/playlists`
3. 调用API	Caller	构造HTTP请求，传参，发请求
4. 解析结果	Parser	从返回的JSON中提取artist_id、track_ids等
5. 继续循环	Planner	拿到artist_id后，规划下一步

4.4 最精彩的设计：Parser怎么解析JSON？

你可能会问：API返回的JSON可能有几十层嵌套，LLM怎么知道从哪提取数据？

RestGPT用了一个很聪明的办法：让LLM自己写Python代码来解析。

流程是这样的：

1. 调用API前，RestGPT已经从OpenAPI规范中知道了返回数据的结构（Schema）
2. 把Schema告诉LLM：“这个API会返回这样的JSON结构”
3. LLM根据Schema，生成一段Python解析代码
4. RestGPT执行这段代码，从实际返回的JSON中提取所需信息

举个例子：

TMDB搜导演的API返回结构（Schema）告诉LLM：

{
  "results": [
    {
      "id": 123,
      "name": "Christopher Nolan",
      "known_for": [...]
    }
  ]
}

LLM生成的解析代码：

def parse_response(response):
    # 从results数组里找出name是Christopher Nolan的项，返回它的id
    for person in response.get("results", []):
        if person.get("name") == "Christopher Nolan":
            return person.get("id")
    return None

RestGPT执行这段代码，拿到导演ID，用于下一步调用。

⚠️ 注：这种“生成代码并执行”的方式虽然灵活，但也带来了安全挑战——如果LLM生成的代码包含恶意逻辑怎么办？后来的技术演进（如2024-2025年的主流框架）更多转向了结构化输出或确定性解析器，在沙箱中执行生成的代码也逐渐成为标准实践。

这个设计的妙处：

LLM不需要知道实际数据（比如ID是多少），只需要知道数据的结构
代码生成和执行分离：LLM负责“知道怎么解析”，系统负责“实际执行”
一次生成，可复用

4.5 解决了什么问题？

问题	RestGPT的解决方案
API调用门槛高	用自然语言操控API，无需懂HTTP细节
多步任务复杂	Coarse-to-Fine分层规划，兼顾全局和灵活
JSON解析难	让LLM写代码解析，灵活处理各种结构
动态调整需求	根据上一步结果，动态规划下一步

五、两个框架的核心对比

对比维度	HuggingGPT	RestGPT
要连接的对象	HuggingFace上的AI模型	互联网上的RESTful API
典型场景	跨模态任务（图像+语音+文字）	操作真实应用（听歌+查电影+发邮件）
核心挑战	如何在万千模型中选对模型	如何构造合法HTTP请求、解析复杂JSON
规划方式	一次性规划所有子任务（Plan-and-Execute风格）	分层规划（Coarse-to-Fine）：先定大步骤，执行时细化参数
关键技术	基于索引的模型选择、任务依赖管理	参数构造、让LLM写代码解析JSON
底层思想	Plan-and-Execute为主，ReAct为辅	分层规划 + 迭代执行

一句话总结：

HuggingGPT：让LLM成为“AI模型的总指挥”，调动各种专业模型干活
RestGPT：让LLM成为“真实应用的操控者”，像人一样用API操作各种服务

六、对现代技术的影响（2026年回看）

站在2026年3月回看，HuggingGPT和RestGPT是AI Agent领域的“先驱”，它们的影响深远。

6.1 它们奠定了“LLM作为控制器”的范式

今天所有AI Agent系统，无论多复杂，底层逻辑都是：

LLM负责思考（规划、决策）
工具负责执行（API、模型、数据库等）

这个范式就是由HuggingGPT和RestGPT等早期工作确立的。

6.2 它们暴露了问题，推动了新技术

RestGPT遇到的痛点，直接催生了后来的技术进步：

RestGPT的痛点	后来的解决方案	2026年的现状
每个API要手动接入	MCP协议：统一标准，即插即用	如今（2026年），MCP已成为连接模型与工具的通用语言，就像当年的USB接口一样普及
解析JSON依赖LLM写代码	结构化输出：模型直接返回JSON	最新LLM原生支持JSON Mode，无需二次解析
单Agent容易出错	多智能体系统：多个Agent分工协作	企业级应用已普遍采用多Agent架构
代码执行有安全风险	沙箱执行 + 确定性解析器	生成代码仍在用，但都在隔离环境中运行

6.3 核心思想至今仍在使用

虽然实现方式进化了，但RestGPT和HuggingGPT教给我们的核心思想依然有效：

核心思想	今天的体现
任务规划	多智能体系统中的规划Agent
工具选择	MCP协议中的服务发现
参数构造	工具调用函数的参数绑定
结果解析	模型结构化输出 + 确定性解析