基于agent以软件体系结构为中心的网构软件模型有哪些，构建平台还是搭建平台

仔细阅读各种商业LLM API文档和各种开源LLM技术报告可以发现，不同LLM实例的推荐温度范围明显不同。但是大多数允许在多个LLM之间切换的框架是否都将此参数与LLM地址结合起来以允许用户批量切换配置？这让用户知道在LLM之间切换时，其他地方有一些奇怪的参数需要更改，并且他们不知道需要更改多少。

当然，目前还没有完全设计出一种方法来为温度、top_p、top_k以及其他也控制解码链路随机性的参数提供更人性化的控制/封装方法。

但这只是把这个问题留给这个令人困惑的领域的专家的理由吗？新的Bing Chat很早就给了我们答案。与其直接向用户提出问题，不如根据用户的理解将级别划分为固定配置。

如果需要精确控制，可以启用高级配置。

这种对用户不友好的参数在当前LLM申请相关的生态系统中非常常见。

，为了改善这种用户体验，不同平台具体做了哪些工作？大多数平台只是“隐藏这些参数”，所以很难隐藏温度，所以我觉得我别无选择，只能把它放在那里。

4.3. 设计适合目标用户知识水平的产品许多产品都有美观且友好的界面，但仔细分析界面上的每个控制点/参数就会发现，您需要知道如何配置它们。有。需要多少知识和能力？他们的目标客户是否具备这些能力？可能没有，这也是这些产品不成功的原因之一。

让非开发人员能够独立使用代理产品是一个比许多开发团队想象的困难得多的挑战。

这不仅仅是图形化一些开发人员的设置，配置他们知道如何配置的部分，以及向用户抛出他们不理解的东西。

仅仅因为产品团队向你抛出一个问题，用户就不会自然地学会它。在这种情况下，普通用户会选择放弃使用。

，除非你玩的是Office系列。

正如1.1节中提到的，

这是建立一个生态系统，生态系统内部的问题必须有人来解决。如果一个平台不能解决问题，平台上的用户也不能解决问题，你就无法启动一个生态系统。平台需要发现并解决客户无法解决且解决成本非常高的问题。

否则，您将无法享受平台的红利。

上面列出的温度只是示例。在实际的Agent开发中，会出现很多问题需要通过策略调优来解决。这里我们将讨论一些基于工作流的DAG 配置功能的更多示例。

4.3.1. 处理单个调用失败产品和领域专家了解业务逻辑和业务流程，因此他们可以在高层分解流程。在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】，说的就是知识库平台产品在很多场景会被 虚拟员工/虚拟专家等开箱即用的服务产品替代。