谈Agent构建平台的设计【2023H2】

本文共计约11,300字。

0、前言

无论是2023年10月发布的讯飞友伴，还是11月发布的OpenAI的GPTs，还有国内小团队的dify和Vanus等的云平台，简单Agent（基于知识库的chatbot）的构建平台这一形态已经广为人知。

本文与这些已有方案不同，主要讨论更为更强能力的Agent构建平台，主要目标是解决实际中稍微复杂一些的问题。此外本文主要讨论的是云上的平台，但其实很多考量可以应用在私有化部署的平台或者内部工具上。

从平台产品面向的客户角度可以分为三类：

• 2Dev：面向开发者

• 2Pro：面向产品经理、以及主业并非程序开发的领域专家等

• 2User：面向终端用户，可能是C端用户，也可能是企业中的普通用户。

要提醒的是：2Dev、2Pro、2User的这个维度划分跟2B、2C是正交的，6种组合都存在。从本文的角度来说，2B和2C这两边的差异没有那么明显，所以后续不再单独讨论这个维度，更多从用户能力角度进行讨论。

以下会递进地讨论几个阶段的平台产品设计：

• 2Dev的平台产品

• 2Pro的平台产品

• Agent as a API平台

• 简略讨论直接2User的平台产品

以上这些方面并不是互斥的，同一个平台完全可以同时支持上述所有。

1、平台设计的总原则

1.1、新生态的构建

上述各类平台（除了2User）想要成功本质上都要构建一个生态。假如产品做的再好，而生态完全启动不了，那么也毫无价值。

而生态的构建思路和产品是不同的。做产品很多时候可以只专注做好自己的部分，扬长避短，做一个更好的竞品也是一种不错的思路。但构建一个生态，特别是新的生态的时候就完全不同了。现在很明显，还没有现成的基于构建Agent的平台的生态，所以这是一个如何构建新生态的问题。我之前也有篇文章讨论了类似的主题 构建价值链 要先于 生态位 【2023H2】。

构建新生态最容易遇到、也最难的问题是：只有一部分生态位的团队光做好自己的部分，而其他人不知道要怎么行动、如何解决其他位置的问题、如何大家协作获取收入进行分配的话，仍然也无法成功。很多创业者“不傻”，大概看懂了新生态中哪个生态位最好赚钱，就跑去只做那个，其他的问题都指望别的生态位的人来解决。自己成本和风险是低了，但最后做成的概率提升了么？很难说，毕竟自己的成功也要建立在生态中其他方也都成功的基础上。

新生态中肯定有一些困难的问题要解决、有一些苦功夫要去投入，这些总要有人去做。谁该去做呢？我认为这个生态中最大的平台方要解决，因为只有它才最可能有资源有动力去解决。生态中的其他分散小个体很难去解决生态上的系统性问题，从利益上也没动力去给整个生态填坑。这可以参考“智猪博弈”的标准答案，只不过这里大小比的不是不同团队当前的力量，而是不同生态位的长期平均力量。

当然生态中并非所有困难和关键的问题都要平台来解决，一个最典型的问题就是如何触达需求和了解需求，而这并非平台擅长的，也并不需要大规模的团队才能做。生态中最终对接和寻找需求方的小团队就足以，这也是了解需求的领域专家擅长的事情。

所以平台要做的事情也就明确了：如果平台比生态中的其他生态位更有可能做成某件事，那么它就应该在前期去做。加速生态的成功启动才是第一要务，哪怕做完原型之后未来交给单独的生态位去精细打磨也要自己投资先去做。而且这不是说如果现在瞄着平台的团队很弱小，它就可以甩锅了，它当下没有足够的力量，那么它应该去融资来把未来的利润通过金融手段折算成现在的力量。

既然有志于做平台，那么就应该去设计最高效的生态内协作模式，这是【新解决方案的生态】和【旧解决方案生态】之间的效率竞争。即使这样都不一定能保证成功，更别说“自己和别人都不去做，只顾抢占那些虚幻的有利生态位”的情况。旧生态的效率也没有那么差，新方案的效率不够高的话，很难把用户从旧生态迁移过来。这里的新生态和旧生态未必是做同样的产品，但它们提供的产品和服务有一些相互替代性，例如“卖电钻”与“提供上门钻孔服务”的关系。

总结一下，其实有个很简单的标准，如果你想做新生态中占主导地位的几个平台之一，那么则：如果发现一个难点没人去做，且也没人明显比自己更适合去做，那么就应该自己去做，先提供一个基础的服务让整个生态运行起来。

1.2、反思（通用场景）low-code的失败

其实在很多方面low-code和现在Agent构建平台是很像的，但通用场景的low-code在过去并不成功。虽然在一些非常狭窄、垂直的小方向上是没问题的，但现在也没有什么广泛使用的稍微通用一点的low-code平台。这是为什么呢？单纯的因为“通用平台的构建是不可能的”么？虽然通用平台的构建难度更大，但我并非觉得这不可能。事实上很多通用的平台方案活的不错，例如开发low-code产品所使用的编程语言本身、Office中的Excel等等，它们未必能解决所有的问题，但它们确实能解决相当多领域的问题，也被相当广泛的接受和使用。

low-code的平台大多是前端和后端开发为背景的人去设计和开发的，他们大多按照自己的想法把产品构建了出来，解决了自己能解决的问题，解决不了的问题要么忽略、要么直接暴露给客户处理。这导致low-code的产品设计经常会出现一些问题：

• 底层的实施细节封装的不足够，导致用户仍然需要了解底层细节知识才能处理各种长尾情况。

• 平台的灵活度不够，而提供的能力又不够强

对于非开发者用户来说：他们很难在平台上【独立地】构建出可靠的应用，仍然经常需要找有开发能力的人进行帮忙。

对于有开发能力的人来说：使用这种平台能够减少的开发成本有限，灵活度的不足给他的开发过程带来了不必要的困难；而他们也更喜欢使用自己熟悉的编程语言和框架，学习low-code平台的半吊子系统没什么太多好处。

很多产品的能力就尴尬的介于这两类用户之间：对于有开发能力的人鸡肋甚至无用，对没有开发能力的人则不够好。而失败也就成了某种自然的结果。

其实我们身边有不少不错的low-code产品/生态，例如：

【兼容SQL标准的数据库】

开发者可以自己读写文件来管理数据，甚至可能比调用DB Client和写SQL还要简单。但数据库能够提供一些关键功能，这些能力靠开发者自己实现的成本太高，所以开发者学习使用这些数据库是值得的。

不少非开发者也学习了SQL，这个学习过程的成本并不算太低，但他们可以由此直接访问数据库，相对于不能独立进行分析、需要通过其他人来跑分析，自己学习SQL是值得的。

【Office的Excel】

Excel现在是作为“可迁移的小型数据库+简单数据处理工具+数据展示UI”来使用。

Excel的不少功能颇为复杂，即使是开发者也未必就熟悉，很多功能是需要投入精力去学习和习惯才能够充分利用的。但与各种low-code平台、Agent平台、GPT平台不同，市场对学习Excel的需求很大，教Excel的书很多。甚至是对于开发者来说，学习Excel也是有价值的。

而学习很多low-code平台其实【没有价值】。这些平台的学习材料不够好只是次要因素，主要因素是他们提供的价值不够大，不足以跟用户习惯的其他方案竞争，不值得用户出学习成本和迁移成本。

【总结】

上述例子给了我们几点启示：

• 平台的目标用户到底是什么样的？平台的能力是否满足了他们的需求？平台是否会对他们提出过分的技能/知识要求？

• 平台提供的能力是否价值足够大到让用户来主动学习？很多平台的设计者和开发者经常会高估自己产品的价值。

已有的项目经常出现的问题是：

• 目标的客户其实不存在，“既要又要还要”的结果就是空集。

• 对于客户来说：产品的能力不够强，不值得他从其他方案迁移过来，甚至都不值得他来学习。

2、构建具体Agent实例的主要难点

在具体讨论针对每种客户的平台设计之前，先明确一下目前Agent构建的难点。Agent的概念很泛，可能包括各种能力和因素，本文只讨论其共性的部分，以下只以没有太多外部依赖的简单工具性Agent产品为例。

基于LLM和其他已有技术的Agent的能力上限可能很高，但现阶段的大部分方案能力水平都很低。很多时候我们觉得已经了解了需求，但就是在研发成本和推理成本限制范围内做不出能满足需求的方案。（当然不少情况是不是真的搞清楚了需求我是存疑的，不过这偏离了本文主题，就再讨论了）

这并非UI不够好看、或者产品的非LLM部分速度不够快、或者产品的服务经常无法访问之类的问题，就是最直接的是否有满足用户需求的问题。

在我看来，有两个维度的弹性较大：

• 用户的精确需求、以及对不同产品能力的付费意愿

• Agent的能力、以及对应的研发和使用成本

用户的需求并非刚性，可能有一些核心的功能用现有的方案就能满足，但这需要非常懂用户场景的领域专家来分析。Agent的能力也并非只能是鸡肋，有些能力可以投入较高的成本来研发，只要用户真的有这个需求。

现在Agent实例的开发的核心是要在这两者之间找到交集，而这个的打磨过程需要这两方面协同设计，甚至多轮迭代才能完成。效果的调优是关键，需要尽一切手段进行优化，降低成本并提升效果，这决定了产品的最终效果是否能达到用户的付费标准。

这里面，把握用户需求的领域专家自己并不太依赖于Agent开发平台，只要能作为用户进行体验就好了。剩下的是：做Agent能力开发的人能够做出满足需求的效果、能够以尽量低的研发成本来进行【原型开发-需求满足性验证】的联合迭代。我认为目前Agent开发平台的最核心功能应该是：更好的支持这个能力效果的调试过程，至少说要把这作为重点功能之一。

迭代这个Agent能力的角色一般有两种：1能做算法策略调优的人，2有领域知识的领域专家。前者能够相对闭环的完成一轮调优工作，但如果有好用的平台支持则可以加速这个过程。领域专家可能缺乏一些开发能力，对于算法策略的细节也没有那么了解，如果有好用的平台也可以独立进行开发和调优，但这对平台封装的易用性要求较高。这类2Pro的产品要求会在第4节进行讨论。

Agent的能力打磨到底有多难多复杂呢？可以参考我的上一篇文章 谈复杂Agent策略框架的设计（2）【2023Q4】，当然我并不认为目前的Agent构建平台就要支撑那么复杂的策略，但长期方向是这样的。

3、面向开发者的Agent构建平台

3.1、简介

本节的开发者是指：能够独立进行策略调优的开发者，其策略调优能力才是核心。是否能够同时写一些后端基础设施和前端交互则相对次要，因为他可以明确这些方面的子需求之后将其外包或简单自学实现。但策略的调优过程和需求的把握目前则因为过于模糊和复杂没法外包。

在这个目标客群下，更好的辅助他们进行策略调优，加速他们的产品全流程开发过程，不阻碍他们的策略调优过程是主要的目标。

我目前看到的Agent构建云平台产品在这方面做的稍好的只有：

• Mircosoft的Copilot Studio

• 字节面向海外的Coze.com ，但其能支持的策略能力仍然偏差

• MindOS的Agent定制功能，这方面与Coze是同一水平。而且MindOS整体已经转向直接2User了。

剩下如讯飞友伴、OpenAI的GPT、Dify、Vanus等等都只能支持类知识库+API插件的策略能力，对Agent的算法策略限制太强，能交付的Agent能力太弱，不在本节讨论范围之内。

面向开发者的平台其实并不难设计，但容易遇到以下问题：

• 平台的设计者和开发者实际上没有做落地的算法策略的调优的能力和经验，但却自认为明白，导致做不出合理的设计折中。

• 对于目标用户的认定不够清晰，导致做出一些四不像的设计。

以下以开发者用户角度来审视一下这些错误设计。

3.2、错误案例

3.2.1、LangChain的封装

虽然LangChain本身并非Agent构建云平台，但它很有代表性并广为人知，所以这里还将其作为一个例子。我之前有一篇单独讨论LangChain设计的文章 Rethinking LangChain（1）：封装的灵活度 【2023Q3】

对于具体的应用开发者来说，简单组合LangChain的能力经常无法很好的满足自己客户的需求。经常出现的情况是：当进一步试图对其进行定制时，又发现它提供的封装和二次开发抽象设计不够好。LangChain内部封装的工作量又不多，所以大多还是放弃它转而自己重写了一套为自己定制的方案。分析一下原因：

• 对于有算法策略调优能力的人来说，LangChain不够灵活，提供的能力也不够强，所以没法用。

• 对于没有算法策略调优能力的人来说，LangChain又没有完全搞定LLM的常见问题，也没法组合出基本可靠的应用。

所以在此基础上，就算搞了图形化LangChain，就能解决问题了么？不行，本质问题还没解决，我们缺的是前端么？不，就算UI丑一点也能凑合用。我们缺的是有算法策略调优能力、且充分熟悉业务场景，能坐在那里慢慢调算法策略的人，输出的结果不行，整个产品就没价值了。

不少前端和后端为主体的团队做了个平台，完成了后端和部分前端工作，其他困难的问题没解决，反而经常由于为了照顾非开发者而把功能做的过于简单，限制了算法策略调优人的空间，最终两头不讨好。

3.2.2、以Coze为例的一些细节点评

如何才算不阻碍算法策略调优的工作呢？给一个简单的参考：开发者在单机上写的任何策略流程都应该能够在平台上实现。不要求直接上传代码库就能运行，但至少要能够支持：以任意的编程流程调用任意LLM、其他API、各种第三方库；能够嵌入Python（及其他常用编程语言）函数代码片段。

【不完整的参数配置能力】

有不少平台可能是为了省事，或让非开发者用户容易理解，在调用LLM API只能配几个主要的参数，例如Coze只能配置temperature。如果某个开发者用户需要用OpenAI的logit_bias参数才能调出来期望的效果时怎么办呢？他很可能只能骂骂咧咧的去换一个平台。

对于开发者来说，平台不应该过度地封装原始API并无故丧失了一部分能力，特别是这个能力会影响他的核心工作时。以这个场景为例，至少要提供一个代码片段输入能力来直接调用底层API，然后才说是不是再提供一个简易配置UI来降低非开发者的使用门槛。

【配置项的过度UI元素化】

Coze workflow的整体UI设计类似于一个图形化的LangChain，以下是其中一个节点的配置UI：

输入参数和输出参数每个都做成了单独UI元素，每个的名字和类型至少2个输入框。

考虑到本节的目标用户都是开发者，写Python（或某种编程语言）不是问题，那么他会觉得直接输入Python语法片段方便呢，还是一个一个填单元格方便呢？这是UI设计者需要考虑的问题。简单的时候可能无所谓，但复杂的时候，或者是开发者需要大量配置这样的调用时候，这种UI设计是很糟糕的，可以说是平白无故增加了人工操作量。

【好看不好用的DAG配置UI】

再看Coze的workflow流程配置整体：

这个方式的可视化程度是好一些，总体的流程清晰一些，（当图的节点非常多的时候效果也有限）。但更主要的问题是：这种方式适合大量编辑么？能降低从离线的开发项目或其他平台往该平台上迁移的成本么？其实是很糟糕的。

我认为至少要提供更符合开发者习惯和录入速度的输入方式，例如在单个窗口能内编辑有相互调用关系的多个函数的代码片段编辑器。想要做的更好一些可以同时提供 简单代码片段和这种DAG图的双向互转功能，一些复杂的情况不能很好识别的时候可以再要求用户进行配置。Agent平台的开发者去调研下代码分析技术我觉得是有必要的。

当然这种UI设计是为了降低非开发者的使用门槛，但其实这并不能如愿，并不是把代码改成AST的图形方式显示就可以说是为非开发者设计的。具体会在第4节来讨论如何为非开发者进行产品设计。

3.2.3、总结

我觉得对于开发者用户来说，首先要给他们足够且必要的底层控制能力，然后再说是不是再有一个简化的功能集和UI可以降低非程序员用户的使用成本。

否则就会陷入“产品功能和UI设计是给非开发者，但却要开发者才能用明白，但又让开发者觉得碍手碍脚”的尴尬局面，重蹈low-code的覆辙。

3.3、开发者用户的其他需求

剩下的工作是平台开发者容易想象的，重点在于堆积起足够的使用价值，让用户觉得值得来使用这个产品、学习这个产品。简单列举一些平台该做的维度：

• 客户的支付和账单系统。包括整包订阅和按量计费模式，并且能够根据内部执行使用的资源来进行定价。

• 弹性的计算和存储资源，最好是serverless，参考AWS的Lambda和微软的Copilot Studio。

• 足够友好的日志接口和session级查询系统，面向开发者和最终用户。

• 基本的多模态chatbot交互UI，这个形式可以为很多产品提供一个base方案。

• 网站托管、备案等支持

• 常用且研发成本较高的能力（这方面不限于前端和后端能力），例如PDF解析、常用的RAG方案、常用的微调方案、常见的策略架构等等

单独解释一下最后一条，虽然这方面并非都是平台主体的后端和前端能力，但这些能力也确实应该由平台提供，因为：

• 有些能力的成本较高，小微团队很难支撑独立开发，但使用场景很多，开发成本可以分摊。例如较好的PDF版式解析等。平台短期可以通过外包或者内部维持一个小算法策略团队来支持。

• 这些能力长期来说可以由平台上的其他开发者通过API方式提供，细分能力和生态位。

总体来说，对于开发者来说平台的目标应该充分的云化、弹性化，拆分成按量付费，包括：

• 传统服务器资源等的云化

• GPU算力的云化

• 通用能力的API化，把研发成本均摊到单次调用成本

• 其他第三方开发者提供的能力的接入

• 未来一些领域模型训练成本的共建分摊

总结一下就是：降低通用需求的开发成本，能力可以组件式的组合使用、按量计费，对其他能力的角色的工作流提供帮助而非阻碍。尽量多的提供自己擅长的能力，分摊该由平台分摊的成本和风险，不要碍事。

4、面向产品、领域专家的 Agent构建平台

到本节终于能开始讨论面向非开发者的Agent构建平台的设计了，本节的内容是本文的核心。（我也觉得前面太长了）

4.1、非开发者的特点究竟是什么？

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

再回头看现在的很多low-code平台设计和面向非开发者的Agent平台设计，它们都只是把非开发者当成：会写但不写代码的程序员，他们懂得如何处理工程上的故障，懂得如何处理LLM的幻觉。同时还认为他们要做的产品并不复杂、要求也不高，仅仅靠指定一些常见的参数就能够符合期望。

有这种用户和这样的需求么？其实很少很少。

可能有不少人觉得非开发者就不配去用一个有高级模式的产品。但请考虑一下民用车的设计：即使用户不懂得如何修车，但车还是要可以被维修的，因为用户可以找人去帮他们修车。

以上是本节的核心，请暂停思考一下。读到这里有一些产品设计视角的读者应该就已经明白我本节的主要观点了。

本节接下来的所有内容都是进一步去举例如何应用这个思维方式去思考产品设计，但篇幅有限，我只能举有限几个例子。

4.2、热身案例

4.2.1、数据库的SQL抽象

对于写SQL的非开发者，他能理解SQL的语法结构就已经有点吃力了。他们不太可能理解：

• 这个query需要并发执行，充分利用CPU，减少延迟

• 这个请求和另一个请求读写了相同的行，必要等那个事务运行完才能执行

• 为什么某些很简单的数据库变更请求会长时间锁死整个表导致数据库不可用

这些问题是存在的，但用户并不懂。实际上能够理解“要创建某些索引以加速某些常用请求”、“视图和物化视图的查询性能是不同的”、“数据太多的时候应该分库分表”……的用户就已经算是比较熟悉数据库的用户了。这些问题都是数据库的开发人员自己解决的，有些实在不好弄导致了DBA岗位的出现。

如果去了解一下数据库系统的实现细节，然后再去对比一下SQL标准【屏蔽】了哪些细节和知识，再结合本节的主题，你会认识到它的设计到底好在哪里。

4.2.1、LLM的temperature参数

很多程序员和产品经理无法理解什么样的参数该屏蔽、什么样的参数该暴露、什么样的参数不能直接暴露又不能屏蔽也无法自动化必须要换种方式来让用户理解和操控。

LLM应用中，最典型的例子就是temperature参数，几乎所有的Agent开发平台产品都会直接暴露这个参数给用户，即使它的目标用户是非开发者。

但同样直接面向C终端用户的OpenAI的ChatGPT和GPTs、微软的New Bing Chat/Copilot从来没有这么干过。New Bing Chat从发布一开始就选择提供了【更有创造力】、【更平衡】、【更精确】三个选项给用户，这其实就是暗中配置了temperature参数。为什么要费劲这么干呢？

虽然temperature是一个重要的参数，但它并不是一个“好”的参数，这表现为大部分人很难通过它的值来直接想象这个值的具体效果，而且temperature跟具体的模型和版本有非常紧密的耦合。temperature=0.5是算小还是算大呢？是算更稳定还是更多样呢？我从gpt-4-turbo换成了百度千帆4.0，之前设置的temperature=0.8，现在应该改成多少呢？不光非开发者几乎无法理解temperature的精细设定，实际上大部分开发者和调试算法策略的人都很难说充分理解了。当我们认真阅读各个商业LLM API的文档和开源LLM的各种技术报告后，会发现不同的LLM实例推荐使用的temperature范围都是明显不同的。但大部分可以切换多种LLM的框架有把这个参数跟LLM地址放在一起让用户可以一起切换配置么？几乎没有。这导致用户在切换LLM时候，还要知道还有一些奇怪的参数在另外一些地方需要一起修改，他们还不知道到底要改成多少。

当然，如何为temperature以及同样控制decode环节随机性的top_p、top_k等参数的更用户友好的控制/封装方式暂时还没有很完善的设计，但这是我们就该直接把它丢给一头雾水的领域专家的理由么？New Bing Chat很早就给了我们答案，按用户能力理解的方式划分几个档位做固定配置好过直接把问题甩给用户。想要可以精确把控可以再开一个高级配置。

在现在LLM应用相关生态中，这样用户不友好的参数很常见，各种平台到底做了哪些工作来改善这方面的使用体验呢？大部分平台做的只有“隐藏这些参数”，像temperature感觉是在不好隐藏，所以只能放在那里。

4.3、为目标用户的知识水平设计产品

很多产品做了似乎很美观、很友好的界面，但当我们认真分析界面上的每个控制点/参数时，会认识到“要知道如何设置这些参数”到底需要多少知识和能力。而他们的目标客户有这些能力么？可能并没有，这就是这些产品不成功的原因之一。

把Agent产品做的可以让非开发者独立使用是一个很难的问题，比很多开发团队想象的要难得多。绝不仅仅是把一些开发者的设置项图形化，设置了自己知道如何设置的部分，然后把自己也不懂的东西抛给用户。用户也不会因为产品团队把难题抛给他了自然就能学会了，一般的用户在这样的情况下会选择放弃使用，除非你做的是Office系列。

1.1节已经说了，这是生态的构建，生态中的难题总要有人解决。如果平台不去解决，平台上的用户解决不了，那么这个生态就无法启动。平台就需要去寻找和解决哪些客户解决不了、解决成本很高的问题，否则就别想吃平台的红利。

上面的temperature只是一个很小的例子，在实际Agent开发中有大量的策略调优中会遇到的问题需要解决。下面再举一些例子，以下都基于workflow的DAG配置能力进行讨论。

4.3.1、单次调用失败的处理

非开发者也是可以使用DAG的，产品和领域专家是懂业务逻辑和业务流程的，粗粒度的流程拆解没有问题。只是在DAG流程中，每个节点要么是对外部的调用，要么是平台提供的功能，没有自己写的代码块。

【限速调用功能】

在这个场景下就会有调用失败的问题，例如调用OpenAI时候返回“429 - Rate limit reached for requests”。我们的用户可能能理解这个错误信息，也可能不能，他该如何解决这个问题呢？几乎没有办法。把这个信息返回给终端用户有用么？可能有一些用，但也并不好。

这个案例中，平台至少要做的最基本的功能是首先把错误信息映射为领域专家和终端用户能理解的信息，包括翻译、术语解释、在错误提示里写上最简单的应对方案——“稍等一会重试”等等，但这产品体验仍然很糟糕。可能这一次DAG调用中包含了很贵的操作，由于这一个失败就浪费了。

这个问题需要被更完整的被解决，例如：对于每个API key，提供调用限速能力并可以配置。到达限速时等待在那里，并考虑向最终端用户展示“任务进入队列排队等待”之类的信息。某些严格的场景下甚至要提供“取消执行”，甚至“回滚事务”。

【LLM指令遵从失败（显式）】

假设某个LLM调用需要输出json格式，将结构化信息传递给其他节点模块。那么当LLM没有遵从指令导致输出中没有json的时候，我们的领域专家能做什么呢？还是只能放任请求的失败？

无论是对于产品、领域专家还是最终用户，LLM的失败都是莫名其妙的，他也不知道有什么好的方式来改善这个问题。其实目前很多平台的设计者和开发者大概也不明白该如何改善。

这个细节问题应该尽量在平台的层面解决，即使无法100%解决，也至少要先试图尝试解决一部分能解决的。例如在配置的时候就强制使用OpenAI的json mode功能，或者是再出现失败的时候自动重试或换用其他LLM重试等等。毕竟我们不写代码的领域专家用户没法替平台去做这件事，但需求是无法逃避的。

实际上最终产品的可用性就是在这一点一滴的长尾case处理中提高的，对于领域专家和最终客户来说，看的总的产品可用率。虽然在乎的不是单个具体的细节，但这些细节都不做肯定做不到很高的可用率。

这些并不是苦功夫，我认为这才是对于非开发者用户平台的核心价值之一。

【LLM指令遵从失败（隐式）】

上一个例子是硬性的失败，但至少不会给出错误的结果。而有不少情况下LLM只是给出了一个错误的结果，例如：让LLM进行日文翻译中文的任务，但LLM进行了续写，或者是翻译为了错误的语言，例如英语。

如果平台的用户是开发者，那么他可能会在一些测试之后发现这个小概率的情况，并自己写一个检验函数来识别这些情况并重试。

但非开发者用户要如何解决这个问题呢？他几乎没有办法，他没法手工写一段检验程序并再触发重试，也很难找到一个外部API来实现这个结果检查功能。所以在这里也需要平台来尽量实现这方面的能力，不见得非要完美解决所有情况，能减少80%的失败要明显好过没有，因为非开发者用户没有自己实现它的能力。

也就是说，平台需要为各种常见的LLM任务来做一些封装，核心在于提供结果检查逻辑并支持以某种方式重试或降级。不光显示失败的情况下需要平台进行尽量兜底和降级重试，隐式失败的发现和处理也是一样重要的。

4.3.2、组件的鲁棒与自适应

和开发者不同，非开发者很难自己处理失败和发现错误，他们在这方面的能力其实比平台的开发者要差得多。平台要提供好的处理方案、发现错误结果的方式，每个节点都应该是尽量鲁棒的，一点一滴的改善整个平台上Agent实例的可用性。

不光是选择LLM会有平衡费用和效果的问题，其他一些复杂的问题也会有，这里举一个不同的例子：不同质量的PDF文档版面解析逻辑API。目前这种服务的定价都不是按请求输入的页面的解析难度自动调整的，所以为了优化成本和效果需要把容易解析的页面交给便宜的方案，难解析的页面交给困难的方案。或者至少是当一种API解析失败时候再去尝试调用别的API。

继续问同样的问题：非开发者用户能够搞定这件事么？能够自己实现一个PDF解析难度识别逻辑，并按需的分发给不同的API调用么？能够写一个好的方案对于PDF解析API的结果进行检查来判断是否应该调用另一个API么？想想就知道大部分非开发者是做不到的，但需求是存在的，而且它对产品的效果和成本的影响很显著。

非开发者用户能够理解说要读取一个文档需要先解析它的内容，但更进一步的各种细节，自适应的调用合适的方案等等对他们来说比较难，更主要的是他们没法写代码并插入到流程中。所以平台提供的每个节点不只应该是鲁棒的，还应该是自适应“各种非开发者不熟悉的细节问题”的。在这个案例中，对于PDF解析的所有处理都应该尽量封装在这一个节点之内，（这个节点可以有复杂一些的各种高级参数的配置，但这些参数都应该有默认值）。如果这个节点内的逻辑失败了或者犯错了，非开发者用户也没有什么其他办法了。

在具体业务流程上或者领域上的问题的处理和应对需要依赖领域专家的知识，他们有他们的业务流程经验，可以在DAG图的层面表达。但我们能指望领域专家告诉你如何实现一个自适应且低成本的PDF版式解析方案么？明显不应该指望他们。

4.3.3、总结

好的平台就是要尽量封装用户不熟悉的领域的问题/信息。

领域专家可以也需要在他们的领域内构建复杂的流程，所以他们也会需要DAG这种复杂性的配置能力。但他们也有很多不懂的领域，这些领域上我们没法对他们有太多的期待。总之如果他们以足够的可靠性实现他们想要的功能，那他们最终只会流失。

这里批评的不是DAG的设计或者图形化的设计方向不对，而是说已有的这些还远远不够。DAG中的每个节点过于底层、细节过多，离领域专家用户所能够操作的抽象程度还有不短的距离。要基于用户能理解的范围来设计每个节点的功能，而不是从底层实现方便的角度。

同样，即使不是对于DAG的配置方式也是如此，每个功能、每个配置项，都应该是用户能理解的，能明白该如何设置的。领域专家和Agent的平台开发者的知识和能力有很大的不同，一些开发者觉得显然、很容易处理的细节点对于用户来说可能很难处理。

反过来，领域专家也有不少知识，需要平台的设计能够发挥他们的能力，平台能够要足够配置他们希望的流程。如果平台封装过度，无法发挥领域专家的优势，也会显著限制平台自身的价值。

4.4、高级模式

对于非开发者易用的产品设计并不意味着要剥夺用户对细节的掌控能力，只要这些细节对于用户的某些场景是有用的，那么就应该提供，避免强迫用户削足适履或从平台流失。

就像是民用轿车大家也可以打开引擎盖，虽然大部分开车的用户自己不会修车。

结合2Dev和2Pro产品的方式并不是只做他们的交集，这只会导致产品定位不清，对于两边都不可用。而是要为不同能力的用户提供适合他们的交互方式。普通模式和高级模式，甚至更多的细分模式，这很难理解么？不难理解。

模式的切换未必是要在整个产品上进行的，也可以小到在DAG的单个节点上进行，这个问题需要具体的思考和设计，这里就点到为止了。

5、Agent as a API 平台

现在来看，用户的需求根本谈不上简单或者容易，很多需求需要比较多方面的技术储备和基础设施，即使是对于LLM算法策略调优经验丰富的团队也经常陷于泥潭或卡在一切其他技术方面的能力上。最为典型的例子就是PDF页面的版式解析能力。

从生态的角度上来看，这类问题靠单个团队是不行的，最后只会回到上一代的RPA、2B软件开发、定制软件开发的效率水平，LLM提升了一些能力，但还远远不够。为了满足这些需要，整个生态需要研发模式上的升级——细化分工。每个团队或个人开发者做好自己擅长的一部分，平台上各个组件能够协同，由最终对接用户的团队组装出可用的产品，每个环节按量计费。

并不是说所有产品最后的交付都是以这种分散形式的，但第一代产品的构建，商业模式的验证和打磨都可以由此快速完成。整个价值链都验证完成后，还想要提升效率，减少中间环节的话，可以再开独立开发，整个各个环节，对各个环节做低成本替代和效果优化。但最初的价值链构建是需要以低成本、快速迭代的方式来完成的，这才能有一个可以期待的未来生态规模。

具体的产品设计上还可以有不少讨论，但本文的内容已经太长，本节的内容又似乎比较超前，就不在本文中展开讨论了。真的有志于做这方面平台设计的读者可以找我单独讨论。

相关材料：我7月有一篇文章就从技术角度讨论了这个方向，但它的内容已经有一些过时，有兴趣的读者可以参考Agent as a Service云平台的一种设想 【2023Q3】

6、面向最终用户的Agent平台

当产品目标设定为最终端用户时（无论是2C还是2B场景下企业中的普通用户），用户是否还需要开发Agent的能力似乎就成了一个问题。MindOS就是从2Dev/2Pro转向了2User，结果就是产品能力主要只保留一些主要能力的开关配置，其他开发功能都隐藏在它的“高级功能”中了。

到这里就已经算是偏离本文（Agent构建平台）的主题了，不过还是顺带给相关读者一点提醒。

我个人为目前认为对于最终用户需要提供的可能更多是服务，而不是开发平台。这不只是2C的，2B领域中不少场景也是最终用户没有太多开发能力，只能直接用成品服务的。

这方面可以参考我之前的文章虚拟员工类产品 的实现方式思考 【2023.9】，说的就是知识库平台产品在很多场景会被 虚拟员工/虚拟专家等开箱即用的服务产品替代。

交流与合作

如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。

希望留言可以到知乎对应文章下留言。

本文于2023.12.15首发于微信公众号与知乎。

知乎链接 https://zhuanlan.zhihu.com/p/672460687