对话百度孙珂：想玩好AI Agent，大模型的“外挂”生意怎么做？

原创：亲爱的数据

（一）

若说大模型应用开发是淘金，

加速应用开发的框架，工具，平台则是“生产淘金铲子”。

有人淘金，总有人生产铲子。

机会一定会被头部厂商捕捉。

而开源产品总是先出发。

LangChain是一个开源的大模型应用框架。

2023年3月，LangChain与亚马逊云、谷歌和微软云等系统集成。

当然，大模型应用开发的难易程度，取决于开发者的水平。

有开发者感慨：“LangChain真香”。

也有小白开发者吐槽：“与LangChain缠斗了几个小时，只是为了用它的两个功能。”

LangChain可提升大型语言模型的应用程序开发效率，

提供了用于构建应用的工具和模块。

举个例子，假如一个手机APP叫“绿了么”。

用大模型加持“绿了么”APP的时候，

LangChain会参与一个这样的Pipeline（执行任务的过程）：

首先，“绿了么”APP把问题发送给大模型。

其次，大模型理解并回答问题。

第三，大模型的答案发送回“绿了么”APP。

在这个Pipeline上，除了大模型的工作，剩下的工作LangChain可以接手。

LangChain是一种软件框架，便于开发各种大模型原生应用。

调戏过大模型的人都知道，开箱即用的玩法就是在那个窗口里输入提问。

只能一问一答这么个玩，就太局限了。

很快，人们开始思考，不如把大模型变成一个超级组件，和别的东西“拼”在一起玩。

但有时候会有点小麻烦。

若在大企业部署就更麻烦，牵扯到很多API，以及其他麻烦事（身份验证，流量控制，鉴别权限）。

这时候就需要大模型外挂。

我再换个例子来聊：

一个被大模型加持的AI Agent由三部分构成。

第一，信号采集，

第二，处理端，

第三，执行端。

先说大模型在哪。

大模型在第二个部分处理端里面。

这时候大模型是Agent的一部分，而工程化的连接工作存在于第一部分和第三部分，这些工作可以自动化，并且交给大模型外挂。

或者说，把信号采集和执行端合起来的需求都交给大模型外挂。

除了大模型干好自己的工作，剩下的大模型外挂接手。

外挂接收外界请求，大语言模型来生成答案，外挂将答案转换为响应，并将响应返回给 API。API它是软件系统之间相互交互的一种手段。API 定义了软件系统如何相互调用，并提供一个标准的接口，外挂自动生成大语言模型服务的API。

这个AI Agent工作的例子不复杂，外挂当然充当省事神器。

结论来了，大模型要实现丰富的功能就要调用“外挂”。

外挂是一个挺大的概念，种类多，使用方法颇多。

外挂可以是自动调用API的工具，

也可以是RAG框架只做了一个问答功能。

​AI Agent自己可以是外挂，AI Agent也可以调用另一个AI Agent做外挂。

多AI Agent的情况下，一个AI Agent是其他AI Agent外挂。

谭老师我赶紧说，禁止俄罗斯套娃梗。

如此看来，大模型“外挂”的生意体量，也会非常可观。

（二）

那么，早期AI Agent和大模型加持下的AI Agent有何不同？

早古时期强化学习里的Agent有很多例子：

在机器人游戏中，Agent是机器人本身。

Agent 的目标：赢得游戏。

Agent 的状态：游戏的当前状态。

Agent 的动作：游戏的下一步操作。

动作可以是向左、向右移动，或者跳跃。

首先，Agent感知环境的状态，比如机器人的当前位置。

其次，根据感知到的状态，Agent（机器人）使用策略函数来选择动作。

策略函数是一个从状态到动作的映射，

它可以是确定性的，也可以是概率性的。

再次，Agent 执行选择的动作，改变环境的状态。

最后，Agent 从环境中获得奖励。

游戏机器人，战死零分，战胜得分。

早期AI Agent 只能感知有限的环境信息，只能有限自动化地完成部分规定好的响应，适应能力并没有打开。

此时此景，谭老师我总结一句，彼时AI Agent，格局没有打开。

大模型加持下的Agent，能针对开放环境做自主的行为规划。

并且在自己所能够操作的，能控制的范畴内，尽可能使用它能使用的工具，以及对这个开放环境的信息进行响应。

完成这一过程，需要用到Agent的四个基本能力：理解、生成、逻辑、记忆。

它们分别代表了 AI Agent 对外部世界的感知、对信息的处理、对决策的制定和对经验的积累。

假设有一个 AI Agent 正在帮助用户查找明星全部绯闻，并总结成故事线。

AI Agent 首先需要理解用户的需求，这需要具备理解能力。

然后，AI Agent 需要搜索互联网，理解发生了什么。

再生成贴合事实的，有前因后果的故事线，这需要具备生成，逻辑和记忆能力（历史新闻）。

在整个过程中，四个能力都发挥了重要作用。

由此看来，打开格局的前提，还是大模型能力强。

当然，也少不了大模型外挂的帮助。

（三）

大模型的外挂范围既然这么大，五花八门的软件框架，

从中找到共性，并形成一个平台，那事情会不会变得更方便。

我前面提到，这个提升开发效率，加速开发大模型原生应用的机会，

一定会被头部厂商捕捉。

我看到百度就是这么做的，2023年12月20号百度智能云千帆AppBuilder正式开放。

此前更早，2023年10月17日的百度世界大会上，

一个“三分钟开发三一重工官网客服”演示，也“揭示”了这个方向上的进展。

并且，我认为，百度AppBuilder不仅设计了“大模型外挂平台”这个产品，而且设计了生态。

第一，产品生态。

李彦宏说，只有拥有数以百万计的AI应用，大模型才可以算得上成功。

百度剑指百万量级的应用生态，底座上必有要有好工具支持应用的开发。

百度推出这类产品，也符合了李彦宏常说的那句“卷 AI 原生应用才有价值”。

第二，技术生态。

百度锋芒所向百万量级的开发者，开放者粘性能带动百度大模型使用量。

第三，产业生态。

发展产业生态，需要降开发门槛，促协作创新，加速落地，这些大模型外挂都能助益。

除以上三点，再加一点，带动B端企业级客户的订单。

目前看来，很多B端企业心热大模型技术，苦于不知道怎么用。

目前百度AppBuilder现有三种（支持知识增强的应用框架RAG、具备思维链及工具使用能力的Agent框架、生成式数据分析框架GBI）都是客户需求旺盛的反映。

客户可以快速上手AppBuilder，此后无论照猫画虎，亦或是激发灵感，有助于

找到大模型的更多用法，成为很好的销售切入点。

带着这些思考，2023年年末的最后几天里，我在百度大厦见到了百度智能云技术委员会主席孙珂博士。和上次见到他的时候一样，他依然身着深色帽衫。我很想把话题聊透，他也非常坦诚。

部分对话已省略，我摘要了核心部分。

谭婧：AI Agent有哪些激动人心的发展方向？

孙珂：如果未来真的技术发展到多AI Agent这个状态，有可能一个AI Agent永远可以被另外一个AI Agent拎起来，作为一个插件来使用。在这个状态下，你可以认为我的这些东西都有可能会被某一个更大的AI Agent拎起来，作为它的一个插件去使用。这个就是我们预见的AI Agent接下来要去发展的一些方向，当然大家正在探索和开发。

谭婧：随着大模型能力提升，Agent架构会被淘汰吗？

孙珂：肯定有些策略就没有用了。但是，作为开发大语言模型原生应用的重要工具，Agent架构可以紧跟趋势，调整策略，目标是让人更容易地使用。

谭婧：有一天，Agent架构会消失吗？

孙珂：有一天，大模型膨胀到它填满了整个AI Agent，但是，它最终外面还是一个AI Agent，它还是表现出这些行为（信号采集，处理，执行）。

更进一步，大模型是AI Agent的一部分，只要大模型跟现实世界连接，做各种执行动作（action）。最终都需要行为和能力对接，所以，这个工程框架应该会长时间存在。

我想了解，AppBuilder在百度现有AI体系里面处于什么位置，又如何发挥作用

谭婧：换个角度来思考，在大模型应用和大模型之间再加一层的办法可行吗？

孙珂：千帆大模型平台在百度云的PaaS层。本质上，你可以认为是在千帆大模型平台之上，长出来的一个A（application) PaaS，应用PaaS，我们内部代号就叫APaaS。

AppBuilder跟千帆大模型平台耦合。耦合点在于计费逻辑，底层计算资源和大模型的调用。当然包括我们以前推出一系列能力引擎PaaS的接口，所以，你可以认为之前的AI PaaS层，是更偏底层的PaaS。

谭婧：和以前MLOPs的关系是什么？

孙珂：如果你对以前MLOPs那层比较熟悉的话，我认为是在此基础上又盖了一层 ，也可以说，在大模型应用和大模型之间再加一层。

谭婧：上一代公有云上的A-PaaS代表产品是什么？

孙珂：以前，因模型效果所限，侧重于模型训练和部署的PaaS，这种形态的组件，并不容易被真正软件工程的这种系统所集成。

谭婧：新旧相比，我们如何一句话总结这种变化？

孙珂：把大模型的常用能力封装成了API。

谭婧：能不能讲一下AppBuilder的问世时间线？

孙珂：更早之前，我们团队已经对RAG等各类框架非常熟悉了，后来发现这个框架存在通用化的可能性。

所以，决定先把这个东西实现出来，实现出来以后发现真的是一个很通用的框架，我们就一直这么做下去，直到AppBuilder现在这个形态。

（完）

《我看见了风暴：人工智能基建革命》，作者：谭婧