0、前言

本文是谈Agent构建平台的设计【2023H2】的续篇，主要是补充一些内容，以及基于目前各产品的现状做一些更新评论。前文的内容都仍然有效，没有读过的读者建议先读前文。

本文讨论的Agent构建平台是指类似Coze这样的产品，但目前的Coze仍远没有达到我的期望。

以下简要列举前文的一些关键观点，方便之前读过的读者进行回忆：

• 综述

• 平台产品的构建是一个生态构建的问题，不同于单一生态位的产品构建。不解决整个价值链上的所有卡点就不算成功。特别是本文主题下，该领域尚没有已经建成的生态，所以光抄现有开源方案和产品是远远不够的。

• 大部分low-code产品和Agent构建产品的价值都较低，不值得用户学习，成功的low-code产品的案例是Excel，大家会自发去学习它。

• 目前小微Agent构建的主要卡点是在【技术方案能达到的效果-成本曲线】和客户的【需求满足度-付费意愿曲线】之间寻找交叉点，这需要两方面能力的人紧密合作才能实现。这里除了前文外也可以参考为什么我不建议去指望找一个AI产品经理【2024Q2】中的讨论

• 面向开发者 和 面向产品/领域专家的平台产品并不是同一种类型的产品，而现有的大部分产品的定位模糊。

• 面向开发者的Agent构建平台

• 对于开发者来说，平台不需要从技术上赋能，更多该做的是：不要制约开发者的开发空间、对于各Agent都需要的通用能力提供云化的支持来分摊成本、对于客户的支付渠道/营销等独立开发者不具备的能力进行赋能。

• 面向产品/领域专家的Agent构建平台

• 非开发者并不只是“不写代码”，他们主要是没有程序员具有的相关知识，更没有算法策略调优的相关知识。但这不意味着他们只面对容易的需求。

• 用户不会写代码不意味着可操控性就可以舍弃。以民用轿车来说，即使用户不懂得如何修车，但车还是要可以打开引擎盖、可以被维修的，因为用户可以找人去帮他们修车。

• 由于用户缺乏某些方面的大部分知识，所以封装的时候对于某些能力/知识的封装要完整。客户只要有一个环节没搞定，他就无法自立完成换轮胎的工作。

1、现有产品的能力回顾

勉强符合本文讨论范围的产品有：字节的扣子Coze、昆仑万维的SkyAgent、百度的文心智能体平台、Dify的工作流编排、Bisheng。其他知名度不足的小公司产品不再一一列举。简而言之，入选的最低标准是支持workflow的配置，能够支持对于用户的单次请求调用不止一次LLM。

以下产品只支持线性的workflow，不属于本文讨论范围：zapier、极简云、等（同样忽略不知名小公司的产品）。

以下产品不支持workflow配置，同样不属于本文讨论范围：OpenAI的GPTs、科大讯飞的助手/友伴、智谱的智能体、等。

目前来看，过去近半年中，大厂的产品只有Coze在迭代，剩下的各家产品都是停滞状态。小公司的产品较多，更新也不少，但其实大多与本文后续主题也没有太多关系，所以本文从略。本文主要还是讨论的大厂的平台产品未来可以如何发展。虽然说很多产品方案小公司也能做，但目前看来小公司想要成功建立Agent生态是很难的。以及本文列名的Dify、Bisheng产品也没有太多我想评论的点。

所以尴尬的就是，本文只有Coze这一个产品可以评论（喷），其他大厂的竞品看起来都已经弃疗了。巧合的是上次其实我也是以Coze为靶子，当时其实还可以讨论MindOS的高级模式，但考虑到MindOS都已经基本放弃了这类定制路线，所以上次还是选择以Coze为靶子。

1.1、Coze

本节仅谈一些在我看来有特点且其他竞品大多没有的功能，假设读者至少知道2024元旦之前workflow类产品的普遍功能。

【支持非自家的LLM】

似乎Coze是国内第一个支持非自家LLM的，支持了Moonshot的LLM。虽然说技术上不难，但这是一个商业上的战略和心胸的问题。碰巧在Agent构建平台上发力的不少公司本身的LLM模型能力很鸡肋，所以是否允许其他家LLM的接入就更是一个重要的战略选择，不接别人就拖累了Agent平台的价值，接入别家就似乎对自己的LLM不够自信。

字节的LLM很难说很好，Moonshot的也很难说是Top1，但好歹算是开了一个可以接入别家的先例。

在Coze的插件中似乎还有非官方的其他LLM支持。

【插件的开发与托管】

插件可谓是Coze产品设计上的一个重要决定。虽然其他家都支持外部API的调用，但这其实很受限。而Coze的插件是为Agent的构建服务所设计的。

从产品设计上很明显就能看出来，Coze的插件是为开发者设计的，默认插件的开发者会写代码。而Coze的workflow和单Agent功能则是为不会写代码的人所准备的。插件并不是绑定Agent的，插件有自己的生态和市场，Agent是在插件之上的更上层产品。

目前Coze上的插件数量虽然算不上非常多，但相对来说绝不算少，而且似乎有一些是并没有公开的API。Coze团队似乎已经意识到插件生态对于Agent构建平台的重要价值，单就这一点就显著领先于其他大小公司的同类产品。

【Agent的记忆功能】

记忆功能要实现也不算特别复杂，ChatGPT Memory也很早就发布了这个功能，（虽然直到近期才完全公开）。

但把这个功能加入到Agent平台中，而不是等着抄别人这点还是值得肯定的。

【多Agent模式】

Coze的多Agent模式看起来也像是一个workflow，但每个节点是一个可配置workflow的Agent。

官方文档里对此功能都没有说明，我自己也懒得研究它能实现的具体效果。

我个人不看好在Agent构建平台中引入MultiAgent的模式，除非用户的目的就是了解不同角色之间的交互方式，例如：

• 把观察多Agent的反应当作娱乐，例如Rimworld等沙盒模拟器

• 观察工作流中不同岗位之间的协作（摩擦）过程

如果未来有Agent商店，希望通过第三方使用别人构建的Agent来组合出更上一层的MultiAgent实例的话，也许会有点用，但这个产品用起来大概率会慢死。

2、展望未来的产品发展

2.1、插件和Agent的收费模式

让生态最快转起来的方式就是让每个参与者都能尽快拿到收益，典型的耐心是一周。收益最好的方式就是获得现金收入，就好像去外卖平台接单一样。但无论是Agent还是插件，都不是一次性服务，相对来说更合适的方式是直接按量收费，或者是以广告或其他基于流量的方式收益。而目前现在小微Agent和插件的广告模式还没有适合的方式，特别是对于插件来说，几乎没法做广告。所以向C按量收费功能并分解给Agent和插件的开发者的功能是需要的。具体形式也未必是要平台直接向C收费，也可以是这个平台接入到某个更大流量来源的产品上，从上游产品获得一些流量分成来支付给开发者。

有很多人认为中国2C收费是很难的，这事不该这么做。但实际上Agent构建平台本来服务的就是长尾需求场景，长尾需求中按量收费很常见，例如：某个领域的某个从业者做了个特定小工具，分享给同个领域里的其他同行，只要这个工具提供了价值，那么就可以收低于这个价值的钱。如果连这种盈利方式都不做，那么还有什么能让Agent和插件开发者获利的方式呢？都靠做软广告卖货么？

如果把Agent作为快消品一样不指望长期消费的娱乐性内容的话，也有一些运营思路，具体讨论见 轻娱乐性GPTs内容平台的一种设想【2024.1】

2.2、不要执着于Agent和大模型

如果我们的思路够开阔，就会注意到一件事情：我们非要做一个Agent平台或者大模型应用的平台么？其实未必。

目前Coze的插件开发能力实际上可以写任意的应用，只要有一个适当的UI就可以了。

简单来想，似乎做一个App的UI还是有不小成本的事情，很多开发者做不好。但近些年的各种混合性feed流产品和chatbot的对话式模式的普及给了我们一些别的选择：在一些场景下，我们可以直接使用chatbot的对话式UI，并适当配合一些小的卡片放在对话消息流中。它不是那种元素位置固定、功能也固定的传统UI，但它可能也足够一些小场景了，例如一个计算各种化合物在各种溶剂中溶解度的工具，做成传统UI和做成对话式问答有多大差异？对于他们的用户来说，差异可能没有那么大，但如果后者可以大幅降低开发成本，让他们能够用上这些小工具了，那就没有任何问题。

所以我们可以用类似的方案来做一些核心能力并非大模型的传统应用，只不过它们使用了现在的一些更通用的UI组件，且可以提供语音和自然语言理解能力，并可能由LLM提供了一些智能。但归根结底，它的核心价值并不是大模型提供的，例如就是查现有的溶解率数据表。只是从易用性、开发成本、触达用户等方面可以被新的方案改善。

所以也许Agent构建平台长线会跟serverless云服务融合，Agent也只是一种类型的serverless应用而已。

2.3、补全营销工具与能力

除了少数应用可能是供给稀缺的，例如少数领域专家写给同行的，在自己的领域里口口传播。大部分场景下，大概Agent的供给都是过剩的，面对Agent自己的推广和营销问题。

这个问题要么平台解决，要么Agent开发者解决。但很明显平台不想解决，也解决不了。所以平台要向Agent开发者提供一些营销工具和能力。目前的Coze有一个活跃用户数统计分析能力，但也仅此而已了。

而实际上Agent的开发者在这上需要的平台支持很多。例如上面提到的按量付费的功能，是不是我们也应该支持向C用户提供免费试用额度？是否应该限制大量机器注册的低成本账号来薅这个免费试用的羊毛？这些是Agent开发者能做的么？其实做不了，这些都是平台该向Agent开发者提供的能力。

回身瞅瞅各大公司自己的产品的运营和营销功能，为什么这些功能Agent的开发者就不需要呢？其实是需要的，只不过未必要做的很复杂。

一个好的Agent构建平台，应该能够让本公司自己的demo性质的试水应用能全生命周期的在该平台上实现，无论是开发还是营销。Agent构建平台应该能够成为新应用的孵化器，直到该应用的用户量变得很大。现在的Agent构建平台的能力如何？会有别的部门的团队想主动去用来开发demo产品么？

2.4、Agent构建平台 相当于 编程语言的生态

Agent构建平台是一个新东西，很多人对此无法形成一个清晰的想象。我发现一个很适合与之作比较的例子，那就是传统编程语言的生态。

具体来说：

• Agent平台上提供的基本组件设计相当于编程语言的语法，语法一般都是很少的，学会他虽然有成本，但并不难。

• Agent平台上的各种插件和功能性组件相当于编程语言的各种标准库和开源库，这才是大家使用这个语言的主要目的，也是上手成本较高的内容。没有库的编程语言几乎没有任何实用价值。很多做Agent平台的人只关注于语法，而完全忽略库的建设。

• 编程语言生态的构建需要大量的培训、案例项目。

• 编程语言一般都会有UGC的问答社区，来帮助新用户解决一些问题。

只有实际做过几年程序开发人才知道编程语言的生态是怎么一回事，产品和其他非技术岗位可能很难一下理解，这方面请考虑找编程语言的开源社区的人咨询。

某种意义上，Agent构建平台应该要成为一个新一代的更加闭环的编程语言生态社区，不止包含了上面所有功能，还包括参与者如何获取收入的方式等等更加广泛的维度。

结语

前一篇文章洋洋洒洒写了1w字，读者看起来费劲，我写起来也很累。

本篇就适可而止吧，毕竟本来也只是前一篇的补充。

也许可能每1-2个季度可以接续该主题写一篇补充。