Coze背后的人，你什么时候顿悟的Agent？

过去一段时间，我深度体验了coze平台，随着它新版本的发布，我意识到自己以前对Agent的理解在细节上的偏差，而coze背后的产品团队，让我理解了真正的Agent，应该长什么样子。

从开发网页的Agent说起

在ChatGPT引领的大模型AI时代伊始，编程就在不断被颠覆。最早，有一款叫AutoGPT的软件震惊了所有业内人士，它可以自动根据开发者输入的自然语言而编写出符合其意图的软件（代码）。随后，越来越多的code领域的机器人出现，其中上了热搜榜的就有全球第一个AI程序员Devin和第一个入职阿里的AI程序员工号AI001。基于视觉描述的OpenUI项目（openui.fly.dev）可以把你描述的内容转化为网页，只要prompt给的好，前端程序员就地失业。

现在，我们回到想要开发网页的人的视角。我们如何来构建自己的开发网页的AI呢？

实际上，如果我们已经有了一定的Agent基础，我们可以基于LangChain来构建一个Agent。不过，此时，在已经加载了各种编程工具的基础上，我们需要对Agent进行较为复杂的设定，让Agent可以理解我们创造它的意图，并且按照我们给出的话进行工具调度，当然，它的底层依赖LLM来完成这种理解。

对应到coze平台上，就是我们以单Agent模式来开发一个Bot，此时，我们需要对Agent层面进行设定，当然也包括各种工具的载入。

然而这个设定（Character）对我们和AI来说，都是考验。通过单Agent实现这种设定实在是有点为难，我们需要写非常多的文案，而且人类的语言表达往往并不能被LLM 100%准确的理解到，稍微一改动，可能带来的变化都是巨大的。

因此，一种新的模式——多Agent模式——出现。在这种模式下，我们将一段长长的设定进行拆分，相当于把一个多面手解雇，让一些单面手上岗，颇有当代企业的作风。于是，我们需要对每一个Agent进行设定，我们可以把这个Agent设定的很小，这一我们的语言描述就可以更精准，使得它的工作过程更符合我们的预期。同时，我们把载入的工具想象成现实中人所会的技能，我们还可以把具有关联性强技能的一拨人分配到一个办公室。

对应到coze平台上，当我们以多Agent模式来开发一个Bot时，我们需要添加多个Agent（或者代表单一Agent的Bot）节点，每一个Agent有自己的工具（包含插件、工作流、知识库等），从效果上，这里的节点Agent和单一Agent Bot中的Agent本质上是一样的，只不过承担的任务轻一些，注意力更集中一些。再由一个起始的Agent来分配初始的任务，这样，一个基于多Agent的Bot就可以完成目标更准确、效果更优秀的任务。

有了多Agent模式，我们也可以开发出类似Devin那样庞大复杂的AI程序员。

一些误区雷

我们必须再次反问自己：我真的理解什么是Agent吗？

在coze平台上，我意识到自己以前理解的Agent，在细节上是有瑕疵的，而coze背后的产品设计和开发人员，真正理解了Agent的真谛。我过去在文章中说过Agent即应用，这个说法现在需要斟酌。在coze中，Agent是经骨，应用（Bot）是肉身。对于终端用户而言，他们只使用了应用（包括API），而不是直接使用Agent，应用的形态是可以变化的，但是不同的形态，背后可以是同一个Agent。

技术一点讲，Agent=LLM+Tools。当然，这里的+可以是LangChain也可以是AutoGen这样的框架，但本质上，就是让LLM理解文本语言的设定（自己要干啥）、上文输入（自己什么时候干）、下文输出（接下来找谁干）、调用什么工具（如何干）。当一个Agent运行时，我们不需要人工去干预它运行的原理，甚至我们都不需要关心它们运行的对不对，自主决策是Agent作为AI能力的本色。

所以，在coze上，一个Agent设定主要包含：适用场景、Agent提示词、技能三个部分。适用场景让上一个节点的Agent知道啥时候调用自己，Agent提示词让自己内部的LLM理解自己应该在什么情况下调用什么工具，技能就是加载的工具所蕴含这个Agent最终能干什么事。

当然，作为Agent大脑的LLM，也可以切换和参数调整。最近coze疯狂上大模型，已经有了千问、MiniMax、Moonshot（Kimi）这3个第三方大模型。海外版则在GPT-3.5、GPT-4的基础上，增加了GPT-4o。

通过上文的阐述，你或许也感受到我感受到的东西。那就是构建一个Agent的核心，不是如何运行LLM，也不是如何开发一个Tool，而是如何利用LLM来调度Tools。如果抛开LLM和Tools（这两者都可以用第三方的），Agent就是一个调度工具，只不过和传统调度工具不同，Agent不基于固定配置和代码实现，而是基于某种特定组织方式，如LangChain、AutoGen等。这种调度，在coze平台的背后，被藏了起来，成为coze平台和其他Agent平台的不同之处，也决定了coze产品中，这些配置、引用、编排，为啥要这么设计。我用过类似dify这样的优秀平台，仍然觉得coze是我目前用过最能揭露Agent应用真相的平台。很多其他模仿coze的平台，其开发团队或许根本没有搞明白一些底层的概念逻辑，所以做出来的东西只能抄到表面，不能令人觉得心旷神怡。

当然，作为一款平台类产品，coze有些超前，特别是调度被藏着后面之后，开发者无法理解Bot是怎么工作的，它为什么会调用某个工作流（或者说开发者会问：我怎么才能让它调其中的某个工作流），以及如何调优自己的配置。

开发自己的独立Agent？

当类似coze这样的平台，已经做得非常超前的时候，我们还有必要做自己的Agent吗？我觉得是需要的。

首先，coze无法满足我们的需求和审美。虽然coze上已经积累了很多插件，但是我认为质量并不算高，在其bot商店中，很多都是标题党，根本无法完成我们真正想要的目标，一些类似声音克隆+文生图实现口播效果的能力，根本无法做出来，它的生态还比较薄弱，就像GPTs上一样，虽然看上去多，但是都是一些能力平平，没啥惊艳的。另外，coze的操作界面在审美上也不尽如人意，当然，这一点每个人各不相同。

其次，我们可以利用Agent开发框架，基于代码实现，使得自己的Agent具备更加优秀的能力。为什么Devin当初出来的时候能够如此惊艳，就是因为它能很好的符合我们的预期，如果不是它的开发团队，在LLM和代码层面做到了最好的优化，相信无法做到这样惊艳的效果。

再者，独立Agent作为服务，可以为B端或C端提供API或应用，实现盈利。我们可以根据自己的情况，根据Agent的能力来挑选价格合适的LLM，在Tools层面，我们可以开发自己的闭源工具，从而提升自己的竞争力。另外，在应用的表现层面，我们可以实现人机交互体验的变革式创新，把颠覆传统工具作为目标，甚至去挑战类似Adobe这样的巨头。

结语

本文虽然围绕coze平台Agent的使用来展开，但实际上和coze本身无关，而是想阐明Agent的本质是基于LLM调度Tools这一核心观点。这听上去没什么，但是对于开发者们而言，这可是颠覆行业造成原地失业的根源，基于LLM理解意图是什么、要做什么、怎么做，再根据LLM理解的结果调用Tools完成目标，这对比我们以前用写命令式代码来实现，你会如何应对？效率上，或许真的是10分钟对比30天的关系。庆幸的是，现在真正的AGI还未到来，LLM还不够智能，Agent的框架还有待改进，Tools生态还比较薄弱，AI对现实世界的影响还不足以令人恐慌，我们还有时间。