2Dev：针对开发人员
2Pro：针对主要业务不是程序开发等的产品经理和领域专家等。
2用户：针对最终用户，可能是C端用户，也可能是企业内的普通用户。
下面将逐步讨论平台产品设计的几个阶段：
2Dev平台产品
2Pro平台产品
Agent作为API平台
浅谈直接2User平台产品
这些方面并不相互排斥，同一平台可以同时支持它们。
1. 平台设计的一般原则
1.1.新生态建设
上述平台（2User除外）要想成功，本质上需要建立一个生态系统。产品再好，但生态系统根本启动不了，那就毫无价值。
生态建设理念和产品不同。做产品的时候，往往可以只专注于自己的部分，扬长避短，做出更好的竞品也是一个好主意。但建设一个生态系统，尤其是一个新的生态系统，情况就完全不同了。现在很明显，基于构建Agent的平台还没有现成的生态系统，所以这是一个如何构建新生态系统的问题。我之前也有一篇文章讨论了类似的主题：构建价值链必须先于生态位[2023H2]。
构建新生态最容易遇到的问题，也是最难遇到的问题，就是生态位中只有部分团队只做好自己的部分，而其他团队不知道如何行动，如何解决其他岗位的问题，如何协作以获得收入。如果分配的话，还是不会成功。很多企业家并不傻。他们可能了解新生态系统中哪个生态位最有利可图，然后他们就选择那个生态位，并依靠其他生态位的人来解决其他问题。成本和风险降低了，但最终成功的概率却增加了？很难说，毕竟你自己的成功也必须建立在生态系统中其他方的成功的基础上。
新生态肯定有一些难题需要解决，也需要投入一些努力。必须有人做这些。谁应该做？我认为这个生态系统中最大的平台需要解决这个问题，因为只有它才最有可能有资源和动力去解决它。生态中其他分散的小个体很难解决生态的系统性问题，也没有动力从盈利的角度去填补整个生态的漏洞。这个可以参考《聪明猪游戏》的标准答案，只不过这里的规模比较不是不同团队当前的实力，而是不同生态位的长期平均实力。
当然，并不是生态系统中所有的难点和关键问题都需要平台来解决。最典型的问题之一是如何触及和理解需求。这不是平台所擅长的，也不需要大规模的团队来做。生态系统中的一个小团队足以最终连接并找到需求方。这也是了解需求的领域专家所擅长的。
因此，平台必须做的事情很明确：如果该平台比生态系统中的其他利基市场更有可能做某事，那么它应该在早期阶段就做。加快生态系统的成功上线是当务之急。就算原型完成了，以后交给单独的生态位进行精细打磨，你还是得先投入自己的钱来做。而这并不意味着，如果目前瞄准平台的团队实力较弱，就可以承担责任。如果目前没有足够的权力，那么就应该通过金融手段筹集资金，将未来的利润转化为当前的权力。
既然你有兴趣搭建一个平台，那么你就应该设计一个最高效的生态内协作模型。这是【新方案生态】与【旧方案生态】之间的效率竞争。即使这样也不一定能成功，更何况是“你和别人不做，只是抢占那些虚幻的有利生态位”的情况。旧生态系统的效率还不错。如果新解决方案的效率不够高，则很难将用户从旧生态系统中迁移出来。这里的新生态和旧生态不一定生产相同的产品，但它们提供的产品和服务是有一定替代性的，比如“卖电钻”和“提供上门钻孔服务”的关系。
总结起来，其实有一个很简单的标准。如果你想成为新生态的主导平台之一，那么：如果你发现一个难题而没有人在做，而且显然没有人比你更适合做。如果你想做，那么你就应该自己做，首先提供一个基础服务，让整个生态运行起来。
1.2.低代码失败的反思（常见场景）
事实上，低代码在很多方面与现在的Agent构建平台非常相似，但是过去针对一般场景的低代码并不成功。虽然在一些很窄的、垂直的小方向上没有问题，但是还没有一个广泛使用的低代码平台更通用。这是为什么呢？难道只是因为“不可能建立一个通用的平台”？虽然构建通用平台会更加困难，但我认为这并非不可能。事实上，很多常见的平台解决方案都运行良好，比如用于开发低代码产品的编程语言本身、Office中的Excel等，它们可能不能解决所有问题，但确实可以解决相当多的问题字段。它也被广泛接受和使用。
低代码平台大多是由具有前端和后端开发背景的人设计和开发的。他们大多按照自己的想法打造产品，解决自己能解决的问题。解决不了的问题要么被忽视，要么被忽视。直接暴露给客户进行加工。这就导致了低代码产品设计中经常出现的一些问题：
底层实现细节封装得不够充分，导致用户仍然需要了解底层细节才能处理各种长尾情况。
平台不够灵活，提供的能力不够强大
对于非开发者用户：他们很难在平台上[独立]构建可靠的应用程序，并且仍然经常需要寻找具有开发能力的人来帮助。
对于有开发能力的人来说：使用这种平台能够降低的开发成本是有限的，缺乏灵活性给他的开发过程带来不必要的困难；而且他们也更喜欢使用自己熟悉的编程语言和框架。学习一个低代码平台的半生不熟的子系统并没有太大的好处。
很多产品的能力尴尬地介于这两类用户之间：对于有开发能力的人来说无用甚至无用，但对于没有开发能力的人来说却不够好。失败就成为自然的结果。
事实上，我们身边有很多好的低代码产品/生态系统，比如：
[兼容SQL标准的数据库]
开发者可以自己读写文件来管理数据，甚至可能比调用DB Client、编写SQL还要简单。然而，数据库可以提供一些关键功能。开发者自己实现这些能力的成本太高，所以开发者学习使用这些数据库是值得的。
许多非开发人员也学过SQL。这个学习过程的成本并不算低，而且可以直接访问数据库。相比于自己无法独立分析，需要别人来跑分析，自学SQL是值得的。的。
【办公Excel】
Excel现在被用作“便携式小型数据库+简单的数据处理工具+数据展示UI”。
Excel的很多功能相当复杂，甚至开发人员也可能不熟悉。许多功能需要努力学习和习惯才能充分利用。但与各种低代码平台、Agent平台、GPT平台不同的是，学习Excel有巨大的市场需求，并且有很多教Excel的书籍。即使对于开发人员来说，学习Excel 也是有价值的。
但学习很多低代码平台其实是[没有价值]。这些平台上缺乏好的学习材料只是一个次要因素。主要因素是它们提供的价值不足以与用户习惯的其他解决方案竞争，并且不值得用户付出学习和迁移成本。
【总结】
上面的例子给了我们几个启示：
平台的目标用户是什么？平台的功能是否满足他们的需求？平台会对他们提出过高的技能/知识要求吗？
平台提供的能力是否有价值，足以让用户主动学习？许多平台的设计师和开发人员常常高估其产品的价值。
现有项目中经常出现的问题有：
目标客户实际上并不存在，“两者都想要，还想要更多”的结果是一个空集。
对于客户来说：产品的能力还不够强，不值得从其他解决方案迁移，甚至不值得学习。
2、构建具体Agent实例的主要难点
这不是UI看起来不够好，或者产品的非LLM部分不够快，或者产品的服务经常无法访问的问题，而是最直接的问题是否满足用户需求。
在我看来，更大的弹性有两个维度：
用户对不同产品功能的精准需求和付费意愿
Agent的能力以及相应的研发和使用成本
用户的需求并不是刚性的。可能有些核心功能是现有解决方案可以满足的，但这需要非常了解用户场景的领域专家进行分析。 Agent的能力不仅仅是无用的。有些能力是可以付出更高的成本来开发的，只要用户确实有这个需求。
现在Agent实例开发的核心就是寻找两者的交集，而打磨的过程需要两个方面的协同设计甚至多轮迭代才能完成。优化效果是关键，要千方百计优化、降低成本、提升效果，这决定了产品的最终效果能否满足用户的付费标准。
在这里，掌握用户需求的领域专家不会过多依赖Agent开发平台，只要能够作为用户体验即可。剩下的就是：开发Agent能力的人能够做出满足需求的效果，能够以尽可能低的研发成本进行【原型开发-需求满足验证】的联合迭代。我认为目前Agent开发平台的核心功能应该是更好地支持这种能力效果的调试过程，至少作为关键功能之一。
迭代Agent能力的角色一般有两类：1.能够优化算法策略的人，2.具有领域知识的领域专家。前者可以在相对闭环中完成一轮调优工作，但如果有良好的平台支持，则可以加速这一过程。领域专家可能缺乏一些开发能力，不了解算法策略的细节。如果有好用的平台，他们可以独立开发调优，但这对平台封装的易用性要求更高。此类2Pro 的产品要求将在第4 节中讨论。
打磨特工的能力有多困难和复杂？可以参考我上一篇文章复杂Agent策略框架的设计（二）[2023Q4]。当然，我并不认为现在的Agent构建平台一定要支持如此复杂的策略，但长期的方向是这样的。
3、开发商代建平台
3.1.介绍
本节中的开发者是指能够独立进行策略调优的开发者，其策略调优能力是核心。他能否同时写一些后端基础设施和前端交互相对来说并不重要，因为他可以把这些方面的子需求明确下来然后外包或者干脆自学去实现。然而，政策调整过程和需求理解目前过于模糊和复杂，无法外包。
在这个目标客户群下，主要目标是更好地协助他们进行战略优化，加速他们的整个产品开发流程，而不是阻碍他们的战略优化进程。
目前我见过的唯一基于Agent的云平台产品在这方面稍微好一些：
Mircosoft 的副驾驶工作室
Byte在海外面对Coze.com，但其所能支撑的战略能力仍存在倾斜
MindOS的Agent定制功能与Coze处于同一水平。而且MindOS 整体已经转向直接2User。
其余的如科大讯飞、OpenAI的GPT、Dify、Vanus等只能支持知识库+API插件的策略能力。 Agent的算法策略限制太强，其所能承载的Agent能力太弱。它们不适合此目的。讨论范围之内。
为开发者设计一个平台并不难，但很容易遇到以下问题：
平台的设计者和开发者实际上没有能力和经验来调整实现的算法策略，但他们认为自己理解，导致无法做出合理的设计妥协。
目标用户的识别不够清晰，导致一些设计不一致。
让我们从开发者和用户的角度来看待这些错误的设计。
3.2.错误案例
3.2.1.浪链封装
虽然LangChain本身并不是一个Agent构建云平台，但它非常具有代表性和知名度，因此这里也以它为例。之前我有一篇单独的文章讨论LangChain设计反思LangChain（一）：包装的灵活性[2023Q3]
对于特定的应用开发者来说，简单地结合LangChain的能力往往无法满足其客户的需求。经常发生的情况是，当你进一步尝试定制它时，你发现它提供的封装和二次开发抽象设计不够好。 LangChain内部封装的工作量并不多，所以大部分都放弃了，自己重写定制的解决方案。分析一下原因：
对于有能力调优算法策略的人来说，浪链不够灵活，提供的能力也不够强大，所以无法使用。
对于那些不具备调优算法策略能力的人来说，浪链并没有完全解决LLM的常见问题，也无法组装出一个基本可靠的应用。
那么在此基础上，即使我们构建一个图形化的LangChain，问题就解决了吗？不，根本问题还没有解决。是我们缺少前端吗？不，即使UI 很丑，它仍然可以工作。我们缺少的是有能力调优算法和策略、完全熟悉业务场景的人。他们可以坐在那里慢慢调整算法策略。如果输出结果不好，整个产品就毫无价值。
很多前端和后端团队都搭建了平台，完成了后端和部分前端工作。其他疑难问题尚未解决。相反，他们经常将功能变得过于简单并限制算法以照顾非开发人员。优化人们空间的策略最终会导致双方的不满。
3.2.2.以Coze为例的一些详细评论
怎样才能不阻碍算法策略调优的工作呢？给一个简单的参考：开发者在单机上编写的任何策略流程都应该能够在平台上实现。不需要直接上传代码库运行，但至少要能够支持：任意编程过程调用任意LLM、其他API、各种第三方库；能够嵌入Python（和其他常用的编程语言）函数代码片段。
【参数配置能力不完整】
很多平台或许是为了省事，或者是为了让非开发者用户更容易理解，在调用LLM API时只能配置几个主要参数。例如，Coze 只能配置温度。如果开发者用户需要使用OpenAI的logit_bias参数来达到想要的效果怎么办？他可能只会咒骂并改变平台。
对于开发者来说，平台不应该过度封装原有的API，无故失去一些能力，尤其是当这个能力会影响他的核心工作时。以这个场景为例，至少提供代码片段输入能力直接调用底层API，然后再决定是否提供简单的配置UI，降低非开发者的门槛。
【配置项UI元素化过多】
Coze工作流的整体UI设计类似于图形化的LangChain。以下是其中一个节点的配置UI：
输入参数和输出参数均被制作成单独的UI 元素，每个名称和类型至少有2 个输入框。
考虑到本节的目标用户是开发人员，编写Python（或某种编程语言）不成问题，他们会觉得直接输入Python语法片段更方便，还是一一填写单元格更方便？这是UI设计师需要考虑的。简单的时候可能没什么关系，但是复杂的时候，或者开发者需要配置大量这样的调用时，这种UI设计就很糟糕了，可以说增加了手动操作量无缘无故。
【看起来不错但不好用的DAG配置UI】
我们看一下Coze的整体工作流程配置：
这种方法可视化程度比较好，整体流程比较清晰（图节点较多时效果有限）。但更重要的问题是：这种方法适合大规模编辑吗？线下开发项目或者其他平台迁移到这个平台的成本能否降低？实际上非常糟糕。
我认为我们至少应该提供一种更符合开发者习惯和输入速度的输入方式，比如可以在单个窗口中编辑多个具有相互调用关系的函数的代码片段编辑器。如果你想做得更好，可以同时提供简单代码片段和这个DAG图的双向转换功能。当一些复杂的情况无法轻易识别时，可以要求用户进行配置。我认为Agent平台的开发者有必要研究一下代码分析技术。
当然，这样的UI设计是为了降低非开发者的使用门槛，但实际上这是不可能的。通过将代码改为AST的图形显示，并不意味着它是为非开发人员设计的。我们将在第4 节中详细讨论如何为非开发人员设计产品。
3.2.3.概括
我觉得对于开发者用户来说，首先要给予他们足够、必要的底层控制能力，然后再问是否有一个简化的功能集和UI，可以降低非程序员用户的使用成本。
否则，我们就会陷入“产品功能、UI设计是给非开发人员看的，只有开发人员才能理解，但开发人员会觉得有障碍”的尴尬境地，重蹈低代码的覆辙。
3.3.开发者用户的其他需求
剩下的工作对于平台开发者来说很容易想象。重点是积累足够的使用价值，让用户觉得这个产品值得使用和学习。我们简单罗列一下平台应该做的一些维度：
客户支付和计费系统。包括统包订阅和即用即付模式，能够根据内部执行所用的资源进行定价。
对于弹性计算和存储资源，最好是无服务器，可以参考AWS的Lambda和微软的Copilot Studio。
为开发者和最终用户提供足够友好的日志界面和会话级查询系统。
基本的多模态聊天机器人交互UI，这种形式可以为很多产品提供基础解决方案。
网站托管、归档和其他支持
研发成本较高的常用能力（这方面不限于前端和后端能力），例如PDF解析、常用的RAG方案、常用的微调方案、常用的策略架构等。
我单独解释一下最后一项。虽然不是平台本体的所有后端和前端能力都在这方面，但这些能力确实应该由平台提供，因为：
部分能力成本较高，小微团队难以支撑自主开发。但使用场景很多，开发成本是可以摊销的。例如更好的PDF布局分析等。该平台短期内可以通过外包或内部维护一个小型算法策略团队来支持。
从长远来看，这些能力可以由平台上的其他开发者通过API、细分能力和生态位来提供。
一般来说，对于开发者来说，平台的目标应该是完全基于云、灵活、分成按需付费的服务，包括：
传统服务器资源云化等
GPU算力云化
通用能力API化，将研发成本平均摊销到单次调用成本
访问其他第三方开发人员提供的功能
未来部分领域模型训练成本共建共享
综上所述，降低了共性需求的开发成本。功能可以在组件组合中使用，并按即用即付的方式计费，这有助于而不是阻碍具有其他功能的角色的工作流程。提供尽可能多的专业知识，分担平台应该分担的成本和风险，并且不要妨碍。
4、产品及领域专家代理搭建平台
4.1.非开发人员有什么特点？
非开发人员不仅仅是“不会写代码”，他们主要不具备程序员所具备的相关知识，更不用说算法策略调优的相关知识了。但这并不意味着他们只面临简单的需求。
回顾目前很多针对非开发人员的低代码平台设计和Agent平台设计，他们只把非开发人员当作会写但不会写代码的程序员。他们知道如何处理工程失败以及如何处理LLM幻觉。同时，他们也认为自己想做的产品并不复杂，要求不高，只需要指定一些通用的参数就可以达到预期。
有这样的用户、这样的需求吗？事实上，很少。
可能有很多人认为非开发者不值得使用高级模式的产品。但请考虑民用汽车的设计：即使用户不知道如何修理汽车，汽车仍然必须是可修理的，因为用户可以找到人为他们修理汽车。
以上就是本节的核心内容，请大家停下来思考一下。对产品设计有一定了解的读者应该已经明白我在本节中的主要观点。
本节接下来的一切都是为了提供如何应用这种思维方式来思考产品设计的进一步示例，但由于篇幅有限，我只能举几个例子。
4.2.预热案例
4.2.1.数据库的SQL抽象
对于写SQL的非开发人员来说，理解SQL的语法结构对他来说已经是有点困难了。他们不太可能理解：
该查询需要并发执行，以充分利用CPU并减少延迟。
该请求与另一个请求读取和写入同一行，并且必须等待该事务完成运行才能执行。
为什么一些非常简单的数据库变更请求会长时间锁定整个表，导致数据库不可用？
这些问题确实存在，只是用户不理解。事实上，能够理解“需要创建某些索引来加速一些常见请求”、“视图和物化视图的查询性能不同”、“当数据太多时应该分库”的用户和表”.已经被视为用户。对数据库比较熟悉的用户。这些问题都是数据库开发人员自己解决的，有的确实很难解决，这就导致了DBA职位的出现。
如果你了解了数据库系统的实现细节，然后对比SQL标准[屏蔽]了哪些细节和知识，结合本节的主题，你就会意识到它的设计有多么好。
4.2.1. LLM温度参数
很多程序员和产品经理无法理解哪些参数应该屏蔽，哪些参数应该暴露，哪些参数不能直接暴露、屏蔽或自动化。他们必须找到另一种方式让用户理解和控制。
在LLM应用中，最典型的例子就是温度参数。几乎所有的Agent开发平台产品都会直接将这个参数暴露给用户，即使它的目标用户是非开发者。
但同样直接针对C端用户的OpenAI的ChatGPT和GPT，以及微软的New Bing Chat/Copilot都从未这样做过。新Bing Chat自发布以来就选择为用户提供【更有创意】、【更平衡】、【更准确】三种选择。这实际上是在秘密配置温度参数。为什么要这么麻烦呢？
虽然温度是一个重要参数，但它并不是一个“好的”参数。这是因为大多数人很难通过它的数值直接想象出这个值的具体效果，而且温度与具体型号和版本有很大差异。紧密耦合。温度=0.5算小还是大？是更稳定还是更多样化？我从gpt-4-turbo换成了百度千帆4.0。之前设置的温度=0.8，现在应该改成什么？不仅非开发人员几乎不可能理解温度的精细设置，事实上大多数开发人员和调试算法策略的人也很难说他们完全理解。
当我们仔细阅读各种商业LLM API的文档以及开源LLM的各种技术报告时，我们会发现不同LLM实例的推荐温度范围明显不同。但是大多数可以在多个LLM之间切换的框架是否都会将此参数与LLM地址放在一起，以便用户可以一起切换配置？几乎没有。这就导致用户在切换LLM的时候知道有一些奇怪的参数需要在其他地方修改，却不知道需要改多少。
当然，如何为温度和top_p、top_k等参数提供更人性化的控制/封装方式，同时控制解码环节的随机性，目前还没有完全设计出来，但这是我们应该扔进去的东西困惑。成为该领域专家的原因是什么？新必应聊天很早就给了我们答案。最好根据用户的理解能力将级别划分为固定配置，而不是直接将问题抛给用户。如果您想要精确控制，可以启用高级配置。
在当前LLM申请相关的生态系统中，此类对用户不友好的参数非常常见。各个平台为了改善这种用户体验做了什么？大多数平台只做“隐藏这些参数”。感觉温度很难隐藏，只能放在那里。
4.3.针对目标用户的知识水平设计产品
很多产品都有看似美观、友好的界面，但当我们仔细分析界面上的每个控制点/参数时，我们就会意识到“知道如何设置这些参数”需要多少知识和能力。而他们的目标客户有这些能力吗？可能不会，这是这些产品不成功的原因之一。
制作出让非开发人员能够独立使用的Agent产品是一个难题，比很多开发团队想象的要困难得多。它不仅仅是将一些开发人员的设置图形化，设置你知道如何设置的部分，然后把你不理解的东西扔给用户。用户不会因为产品团队把问题抛给他们就自然而然地学会了。一般用户在这种情况下都会选择放弃使用，除非你使用的是Office系列。
正如1.1节提到的，这是一个生态的建设，生态中的问题必须有人解决。如果平台解决不了问题，平台上的用户也解决不了，那么生态就无法启动。平台需要发现并解决客户无法解决且解决成本非常高的问题，否则他们将无法获得平台的红利。
上述温度只是一个小例子。在实际的Agent开发中，存在大量的策略调优问题需要解决。这里还有一些例子。下面基于工作流的DAG配置能力进行讨论。
4.3.1.单次调用失败的处理
非开发人员也可以使用DAG。产品和领域专家了解业务逻辑和业务流程，粗粒度流程拆解没有问题。只不过在DAG流程中，每个节点要么是对外部的调用，要么是平台提供的函数，并没有自己编写的代码块。
【限速通话功能】
这种场景下就会出现调用失败的问题。例如，调用OpenAI时，将返回“429 - 请求的速率限制”。我们的用户可能无法理解此错误消息。他该如何解决这个问题呢？几乎没有办法。将此信息返回给最终用户有用吗？它可能有一些用处，但也不是很好。
在这种情况下，平台最基本的功能就是首先将错误信息映射成领域专家和最终用户可以理解的信息，包括翻译、术语解释，并在错误消息——“稍等一下”中编写最简单的应对计划。再试一次”等等，但产品体验仍然很糟糕，也许这个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，结果就是产品能力主要只保留一些主要能力的开关配置，其他开发功能都隐藏在它的“高级功能”中了。 我个人为目前认为对于最终用户需要提供的可能更多是服务，而不是开发平台。这不只是2C的，2B领域中不少场景也是最终用户没有太多开发能力，只能直接用成品服务的。 这方面可以参考我之前的文章虚拟员工类产品 的实现方式思考 【2023.9】，说的就是知识库平台产品在很多场景会被 虚拟员工/虚拟专家等开箱即用的服务产品替代。
用户评论
对于Agent构建平台的设计，我个人觉得非常赞同作者的想法！现在各种智能助手都离不开这种平台的支持，提供一个易用、灵活的设计是极其重要的。
有12位网友表示赞同！
这篇文章讲解的很有条理，从功能设计到技术细节都触及了关键点。作为一名开发者，对构建平台的理解有了更深的认识！
有8位网友表示赞同！
我觉得平台的选择很重要，不同平台各有千秋，需要根据具体应用场景来选择合适的解决方案。文中提到的常见框架和工具很实用的指导。
有8位网友表示赞同！
作为AI领域的爱好者，一直在关注Agent的发展趋势。这篇文章让我对未来的构建平台有了一些新的思考，期待看到更强大、更智能的Agent誕生!
有11位网友表示赞同！
在实际应用中，我感觉很多现有的平台限制性比较大，难以满足个性化需求。希望将来能出现更加灵活、开放的构建平台！
有17位网友表示赞同！
我觉得文中对安全性分析的缺失比较可惜。一个好的构建平台应该兼顾功能和安全，才能真正被信赖和广泛使用。
有13位网友表示赞同！
我对开源平台的潜力一直很看好，希望在Agent构建领域也能涌现出优秀的开源解决方案，让每个人都能轻松地搭建自己的AI助理！
有9位网友表示赞同！
这篇文章给我的启发是：Agent构建平台的设计不应该局限于技术层面，还需要考虑用户体验和应用场景，才能真正造就赋能人类的智能工具！
有8位网友表示赞同！
我之前接触过一些Agent构建平台，感觉有些过于复杂，没有足够的友好性。希望作者能够进一步探讨如何降低平台门槛，让更多人参与进来！
有7位网友表示赞同！
文中提到的多模态Agent设计思路很有创意，我觉得未来AI助理将朝着更加智能、更自然的交互方向发展！
有10位网友表示赞同！
作为一个程序员来说，非常理解作者关于代码可读性和维护性方面的阐述。一个良好的构建平台应该能让开发者轻松地管理和升级Agent模型！
有8位网友表示赞同！
在实际应用中，我认为Agent的训练数据也是至关重要的因素。希望未来能够出现更加高效、智能的数据标注工具，帮助开发者快速构建高质量的Agent模型。
有12位网友表示赞同！
这篇文章让我意识到，Agent构建平台的设计并非是一项单打独斗的任务，需要各方共同努力才能打造出真正优秀的解决方案！
有15位网友表示赞同！
在AI伦理方面，我想作者应该进一步探讨如何确保Agent的构建和使用符合道德规范，避免潜在的风险！
有14位网友表示赞同！
我对文中提到的个性化配置非常感兴趣，希望能尽快看到更灵活、可定制的Agent构建平台！
有11位网友表示赞同！
作为一个日常用户来说，我希望能够更容易地使用Agent平台搭建自己的智能助手，无需复杂的编程知识也能轻松实现。
有12位网友表示赞同！
平台是否支持跨领域应用是一个值得思考的问题。希望未来我们可以看到更加通用、适配不同场景的Agent构建平台！
有9位网友表示赞同！
这篇文章让我对Agent构建技术有了更深入的理解，期待未来能够见证更多精彩的应用，让AI真正服务于人类!
有6位网友表示赞同！
虽然文章讲得很透彻，但我还是感觉有些理论性强，缺乏具体的实例分析。如果能结合实际案例，更加直观地展示平台的设计思路和应用场景，会更有感染力。
有8位网友表示赞同！