Transcription
26年第一个月项目总结
这个月最火的项目当然是OpenClaw，一个个人助手类的智能体平台。你有没有想过，已经出的智能体平台/框架没有几百，也有几十了。这么多的平台框架，它们究竟在比什么？咱们今天就把这些智能体平台框架的底裤扒一扒，对比一下它们究竟有什么差异。每一个都说自己多牛X，那我要开发一个智能体，如何做技术选型？该用哪一个呢？准备好了吗~发车！
我们直接先说结论：比的是“编排方式”。
我们知道，决定智能体性能的主要有三个要素：第一个就是“模型的性能”，第二个是“外部数据”，第三个是“编排方式”。现在对于大多数智能体框架平台来说，模型都是可切换的。你可以切换任意一个厂商的模型，你可以切换长思考模型或者短思考模型，都可以，所以在这方面，智能体框架平台它们的差异比不出来。
那第二个呢，就是外部接口和数据。这个又包含两部分：第一个是包含外部的知识库，你要做一个什么领域，你给它提供一个什么样的知识库；第二个是使用什么样的工具。而现在越来越多的工具都MCP化或者Skill化。对于公共类的工具大家都是差不多的，对于私有类的工具、知识库，那我可以很方便的接入到平台里，也不太会有差异。
所以各个平台真正比的，其实是它们的编排方式：我解决一个问题需要多少个智能体、每一个智能体的职责和范围是什么、它们以什么样的先后顺序串联在一起。这就是智能体的编排方式。
不同框架的主要差异其实就在这了。而编排方式解决的核心问题，就是“模型上下文范围的一个分配问题”，或者说，是模型的有限注意力的一个分配问题。
我们有过智能体开发经验，或你经常和大模型对话的，你一定有这样一种感觉，就是模型回答的这个性能，它不是一直很好或一直很坏的，它是符合这样一条曲线的。就是当你刚开始给定它的条件或上下文，你们俩刚开始对话，你说的各个背景知识也好，要解决的问题的目标领域也好，概括的不是很详细的时候，模型的回答质量是不高的。
那随着你给它的信息越来越全，那这个时候准确率会不断的上升。但是随着对话的深入和它的对话的篇幅越来越长，甚至滚动条滚半天滚不完的时候，你就会发现，它回答你的时候经常找不对重点，或者回答的性能会越来越弱，越来越弱，从而东拉西扯，总是回答不到点上。这就是模型注意力被分散，上下文太长导致的结果。
所以按照经验上来讲，一般和模型对话的时候，第5-10轮左右，它回答你的准确率或者回答的效果是最好的。那当然这也取决于具体的应用场景和你对话长度。所以我们在做智能体开发的时候，我们也希望送入到模型上下文里的长度，始终保持在这样一个范围内，就解决问题了，这样的出来的效果是最好的。
所以就出现了各种各样的编排方式，核心就是，要解决给模型送入适当长度的上下文。这里边既包含了工具，也包含了外部知识和必要的背景知识，全在这个长度的范围内。
我们结合几个实际的例子来讲一下。比如我们现在在智能体平台框架里面最常见的，就是这种React模式。它就分为两步：第一步先思考，然后思考完了行动，行动完了，再根据当前的环节继续下一步，如此循环往复，像一个链条一样展开，这就是React。
那在这个过程中，它的上下文一般是不切换的。也就是说，在每一步的环节里边，我要回顾过去所有的知识，然后决策下一步该如何行动。所以在这个过程中，随着链条的展开，它的上下文是越来越长的，换句话说，它的模型性能就会越来越弱。所以这种模式下，我们解决的问题不宜太长，太长模型回答质量就开始变弱了。
那这种模式还有一个进化版本，就是Reflection。它在每次行动后加一个反思环节，就是回顾一下我执行的这次步骤，到底好还是不好。那么很显然，加入这个步骤以后，对解决问题的质量是有帮助的。每次我都多了一个总结回顾的过程，那我下一步再执行的时候，肯定是有提升的。
那带来的问题也是很显然的，就是我加入了这么一个环节以后，我上下文的消耗的速度就更快了，换句话说，我适合解决问题的那个步骤就更短了，解决问题的领域更窄。所以实际情况下，这种模式的平台和框架会更多一些。
像这个月最火的那个OpenClaw，它用的就是React模式+Skill机制，注入了很多内置的工具给它。为什么很多人反馈这个OpenClaw消耗Token速度太快？就是因为它注入了大量的工具，占据了它上下文非常大的篇幅，然后经过多轮React以后，你的Token自然就消耗的很快了。
还有前阵子的Manus，也是类似的。Manus为什么在后期的执行效率不高？就是因为它做电脑操作的时候，它要尝试很多轮次，那多个轮次以后，那自然准确率就下降了。同样的道理。
那React是最早的模式，后来又出了几种新的模式，比如说ToT模式。那这种编排模式也很形象，就是先一开始我先做一个规划，然后把我的后续的行动分成几个分支，每个分支里再去做一个专门的尝试，那最后可能还会有一个汇总和总结，也可能没有。
那这种编排模式和React相比，又有什么异同呢？那么很显然的，它把上下文做了一个强制的划分。换句话说，在做第一步规划的时候，我可能是掌握一开始的全局的知识，但是在每一个子步骤里，我其实只需要掌握我这个路径下的上下文就可以了。我在考虑我这个步骤的时候，我不需要把这个步骤的上下文也输入进来。所以当前智能体就可以专注于当前步骤，把当前这个子任务执行到最好。那么几个好的结果加起来，可能就最终有一个更好的结果了。那这就是一种很典型的，通过上下文划分提高执行效果的一种编排方式。
那么后来我们又有越来越多的框架研究了更多的编排方式，比如说现在最主流的工作流模式。那么它就是一个有向图，按照一定的工作流程，从开始往后可能会有分支，也可能会有合并，最终结束。一方面，它把你的任务执行流程固化下来；另外一方面，它也是对上下文做了一个更强制、更细致的划分。比如当前这个环节，我其实不需要关注我前一个环节或其它环节内，它那个内部流程的上下文，我只需要关注我这个环节的输入和输出就好了，确保了一个“最小知识原则”，执行效率自然就高了。
这种编排模式下的框架也是最多的，像什么Dify、Langflow、Coze、N8N...都属于这一类的框架。
不过，还有低代码平台和无代码平台的划分。
那除了这种编排模式以外，还有一类框架另辟蹊径。刚才说的工作流是按工作流程划分环节，那其实我们现实的人类社会中，很多都是按人类的角色来划分环节。那比如说在软件开发中，是有一个产品经理角色、有程序员角色、有测试角色，它们之间相互的进行流转划分，最后把这个流程结束。这是按人类角色作为环节去划分的，前面那个是按工作环节去划分的。
那这种编排模式，有时候有固定的流程，有时候甚至没有固定的流程，可能只是当前的这个角色，它来决定下一步流向哪。那这一类的框架/平台也很多，比如CrewAI，或者是微软的那个AutoGen，或者是OpenAI的Swarm，都属于这一类的框架。
那这类的平台框架还有一个终极版，就是我连预设的流程都没有，就放这么几个智能体在那，可能每一个智能体都有自己的角色和定位，然后它们通过一块白板进行相互的交流协作。一个人发起话题，另一个人看到了就执行，再往里边加点内容，下一个环节流向哪，可能都不确定，什么时候结束也不确定。这类的模式一般适合那种开放式的研究领域的，这种智能体编排方式用这种比较合适，就像几个人坐在一起开会一样。像OpenAgents就属于这种模式。
那最后还有一类，就是框架类。那这种呢，就是我不规定你用什么编排方式，用什么编排方式都可以，我就给你提供一些元素和组件，你自己去组装吧，你组装成什么编排方式我都支持。那比如LangChain、LangGraph都属于这种的框架。
回到一开始那个问题，这么多框架，它们究竟在比什么？它们其实都想证明：“在自己设定的那个问题场景条件下，自己的这套上下文分配机制是最优的。”
所以当我们需要开发一个智能体，在做技术选型的时候，就是需要结合自己的场景。那你要解决的这个问题是长是短？是开放型的问题，还是固定流程的问题？是按人类的这种角色去划分环节呀，还是按工作流程划分环节呀？把这些问题想清楚，你就知道要用哪一个平台，哪一个框架了。
最后再结合自己的领域，看看这些平台框架都提供了哪些知识库和工具。比如像OpenClaw，它其实提供的是50多个个人的桌面类的系统工具。那如果你做一个个人助手类的智能体，那选这个平台合适。
那比如之前我们介绍过ChatDev，ChatDev那个框架，它是专门用来做软件开发类的这么一个智能体框架，它内设了很多的软件开发的角色。如果你做那一类的智能体，就选那个平台。
那如果你做金融类的，你可以选OpenBB，因为它内置了很多金融类的MCP的工具，直接用它，减少你很大的开发工作量。
综合这些，你就能最终做出你的决策了。
那我们这样讲完以后，大家也就能一眼看穿这些智能体平台框架的底裤了。
那最后再提一句，我们今年的这个项目总结文档，我把它迁移到知识库了。具体的知识库链接见视频下面的简介。希望今天的内容对你有帮助~拜拜！