几种开源对比可参考 Coze 项目 Issue 上的讨论：
https://github.com/coze-dev/coze-studio/issues/2
然而在震惊之余，抛开散播新闻不谈，我更想分享一些所思所想，主要是两个问题：
1. 为什么这样的工作流平台很重要？
2. 开源带来了什么，有什么限制，能带来什么？
而这两个问题都深深印证着，把事情交出去的重要性，尤其是 LLM 时代。
# [01] 为什么这样的工作流平台很重要？
有很多朋友没用过 Coze 这样的工作流平台，首先我们可以从 Coze 的简介单刀直入的看到，这个平台是用来干什么的。
https://github.com/coze-dev/coze-studio?tab=readme-ov-file
简单来说，它是一个为了做 AI Agent 的低代码平台，几乎不用写代码（也可以写一点），就可以靠着前端组件交互（拖拽连接等）快速搭建一个工作流。
什么是工作流（workflow）？
工作流就是一个固定的包含各种功能模块连接或者堆叠的流程，比如这是一个简单的工作流 [用户输入一个提问->LLM 进行意图识别并选择不同的下游动作->调用工具或者调用知识库获取相关知识->LLM 基于新的知识组织语言回答]。
这里的一个问题是，面对不同的场景和任务，这样的工作流无穷无尽，即使核心组件就只有 LLM 这一个，不要检索不用工具，那也可以玩出很多花来。
例如流程 [输入一篇文章->LLM 分析文章中的专有名词->LLM 拿着分析再生成结构化的输出] 只是把 LLM 按不同的 prompt 调用了两次，但仍然算是一个工作流。这样的做法在 Agent 上面屡见不鲜，它能在 LLM 能力不够时，分拆并聚焦子任务来提升任务的完成度。
当这样的一个工作流做完后，它不仅仅可以让人来直接单独使用，也可以结合其他调用程序来做批处理。
但是这样的工作流相对比较独立，不是像 Cursor 这样和 IDE 嵌入到一起的，所以它有它自己的定位。
LLM 时代，把模型当做一个逻辑节点用，可以做的事更多了。
正如上面提到的工作流，换个 prompt 就可以做不同的生成，那么如果只是靠着后端写代码来不停做各种工作流，这类事是没有尽头的。
这一点我感受颇深。
像拿 LLM 做对话，例如客服，就有非常多的维度需要展开。因为只专门为一个客户做一个机器人，那么业务范围就太窄了，很难做大，这时就应该把更多的维度考虑进来。
比如各种场景的客服，无论是打电话来（inbound）的咨询问答还是打电话去（outbound）的推销，甚至中文、英文、日语、韩语或者其他各种国家语言等，都要纳入考虑，这样这个盘子才大。
很多时候，不是机器人做不了，是不知道要做什么机器人，需求和解决方案还在彼此追寻。
于是这里就有一个大问题，如果真有了业务，这个机器人谁做？
在上面的 Coze 简介里，我们能看到组件的种类可是不少的，什么 Prompt，Memory，RAG，Function，还有 Multi-agent 等，先不说这些概念非专业人士能不能理解透彻，知晓其中的讲究对效果的影响，只说这些东西怎么连接和堆叠，就已经是一堆问题了。
每个组件本身就是依赖算法创造出的“怪物”，绝不是什么干脆利落的标准零件，例如Embedding不只是有Dense，还有Sparse， LLM 同样还有多模态和一些变体如 DLLM 等。
每新出一个概念，对于后端代码的可插拔和可扩展性来说，都有很大挑战，可能动不动就要大改。
即使不说要大改，只说每次有新的工作流，重新单独快速写代码实现一条，那也会有非常多的兼容性问题，例如要尽量保持流程和各种日志系统以及接口 I/O 的兼容性。
早期搭建工作流，没有选择，要么自己没有章法的写一些扩展性较差代码，要么选择一些模块化设计过的框架然后做二次开发，例如 Langchain。
但用过 Langchain 的都知道，为了做好 Pipeline，更好的将各种组件连起来，它的代码现在已经非常庞大复杂了。如果不清楚这套框架的构建原理和输入输出标准，那么稍微想动个什么，还不按框架的定义来，改来改去，就很容易让 Pipeline 崩坏。
后端写代码搭建流程，直接面向代码，可毫无可视化而言。为了提效和减轻人的负担，我记得之前还有人基于 Langchain 做了一个可视化工具 Langflow，可见可视化的需求是趋势，即使程序员也需要。
刚刚已经说了组件连接的问题，但是还有一个问题就是，LLM 的 Function Call 具体实现，到底谁写？
目前的 LLM 为了能够实时访问现实世界信息，会通过 Function Call 来和系统交换信号。那么当 LLM 生成了一段 Function Call 的字符串（名称+参数），还需要系统去解析信号并帮 LLM 执行这个工具，最后把结果返回给 LLM。
Function Call 在 LLM 的视角上，是作为一个用户可自由定义的形式出现的，即用户只需要提供各种工具的描述和参数定义，LLM 就可以在适当的时候选择输出这个信号，来提醒系统该执行工具了，即工具对应的这段具体代码是系统收到 LLM 的信号后帮它执行的。
这里 LLM 自己是一点都不管具体执行的，包括直接输出 python 代码这种。
要实际执行工具，需要依赖真实的代码和环境来运行。然而既然是真实的代码，那么必然有两个问题：一是代码必定意味着有复杂的情景是需要程序员去写的（非程序员看到语法可能就打退堂鼓了），二是代码需要可靠的运行环境。
如果 Custom Function 是用户自己自由定义的，但实现却要程序员实现，还要考虑这段代码的执行要什么环境，有什么依赖，危不危险，那么整个现状就比较撕裂，一件事情绑定在好几种职能的人员上了。
而且很多时候，程序员反而不知道用户为什么要定义这种 Function，因为用户自己定义的 Function 是按自己的 Prompt 设定来的，而且由于没有代码逻辑，所以设计的Function（尤其是参数）可能都没管代码能不能实现，甚至连代码类型也不适配。
例如现在需要一个 Function 来判断用户输入的电话号码有多少位，但是用户定义的Function 预设了一个 phone_number 参数，类型是 str。
真正运行时，模型提取的参数却是单词形式的（跟 LLM 对话，我为什么一定要输入阿拉伯数字，何况语音场景更容易出单词），例如提取了一个表示区号 +86 的 plus eight six，此时代码怎么处理？如果这个需求给到程序员实现，那么就比较复杂了，要考虑的情况就非常多了。
但是如果让 LLM 就固定提取或转为阿拉伯数字（无论对话里是什么），那么实现就非常容易。
更恐怖的是，早期做机器人，Function 执行没有动态执行程序的沙盒，而是跟后端服务代码放在一块的。当做机器人的运营和程序员好不容易磨合着的把 Prompt 和 Function 打通，程序员正式发布了一个版本，然后突然又发现哪里走不通来，要改 Function，这简直令人崩溃。
这样推进事情，整个流程给人的感觉就是难受，运营无法独立完成事情，因为缺了 Function 又不好调试，而且实现不可扩展，程序员也处于一直被需求绑着的状态。
因此，程序员只有把整个机器人的关键制作环节交出去，才能让自己自由，要交出去，那就得有这个工作流平台，而有了这个平台后，我们才能专注做真正的核心功能和新组件，用户才能专注的创作。
对于这个平台，它的预期也很简单。
一是要降低非程序员的用户制作机器人时的操作难度和理解复杂度，二是平台要能切割机器人和后端的实时依赖，最终达到只在平台上操作就能完成一个机器人的搭建、测试和上线，甚至包括发布和发布后直接产生一个接口域名，能让其他产品直接集成（例如 Coze 上线工作流后，集成到公众号自动回复）。
为了达到预期，这个平台首先要做的就是隐藏直接的代码语法，取而代之的是以可视化方式呈现组件和创造过程，像画布里拖组件这种东西已经很成熟了，像游戏开发领域的虚幻引擎 5，就有类似的可视化工作流。
另外就是代码实际执行代码创造也放在平台，那么这个代码是动态代码，所以要执行还有环境依赖和安全的问题，这一点目前主要通过沙盒来实现。
只不过每一个 Function 真正执行时，如果从头开始编译代码，起进程以及 import 依赖的话，对整个流程响应的速度会有不小的影响，这一点值得优化。
总之，在制作机器人这件事上，LLM 可以做的方向太多了，因此不要什么都依赖程序员。
程序员虽然擅长写程序，但可能并没有什么好的想法，或者想不出什么好的直击用户需求的机器人，毕竟程序员不负责这块。
不过这恰好是产品，运营，以及用户擅长的，所以以低代码甚至零代码的形式把这件事交出去，是非常自然而然的趋势。
一款好的工作流框架，程序员自己也是喜欢的。这样只需要对齐标准，开关关键组件就行了，至少刚刚说的可任意定义的 Function 开发环节，也已经推到前端页面了。
同时，在平台上直接能制作工具，还方便共创分享，尤其是现在大火的 MCP，基于这个标准，很多软件都做了自己的工具集，例如有本地文件系统的工具，也有调用三方产品的工具（可以调小红书获取各种信息），这些工具和常用的 Search/Python 工具以及用户仍然可以自定义的一些工具一起组成了工具调用拼图。
最终，有了这么一个平台后，不仅事情交出去了，还意味着生产力极大的释放了。
目前，像 Coze 这种平台，来自用户的创作已经数不过来了，不乏很多高质量的、有趣的新 Idea。
不过要注意的是，如果你使用 Coze 找不到合适的已有工具，想自己制作工具实现，仍然要写点代码，可以是 python 或者 javascript。
# [02] 开源带来了什么，有什么限制，能带来什么？
那么 Coze 的开源带来了什么，又能通过开源给官方和我们继续带来什么？
首先我们看 Coze 平台的代码语言分布，这是一个前端以 JS 为主，后端以 Go 为主的平台，它只是一个平台，不代表它是 Agent，也不是 LLM。
我们可以基于这个平台添加自己的 LLM，检索模型，结点逻辑和 Function 工具等资源，然后在平台连接这些组件，并搭建一个机器人。
开发人员还可以自定义一些新的组件，所以基于 Coze 二次开发，放在不同的团队手里，必然会开不同的花。
对于一个开源项目，我们要注意两个重要事项：
1. 开源的功能有哪些？相比闭源阉割了什么功能？
2. 开源协议是什么？商用的限制是什么？
对于第一点，它的能力项如下：
它有什么阉割？
除了上面代码库 Readme 所提到的 API Reference，它应该还有一些功能是保留的，肯定要落后于商业版本才行。
但这个我暂时没法深入对比，想知道的朋友可以多关注 Github 的 Issue，因为作为开源项目，如果这个项目真的有很多团队或者个人打算部署尝试，那么哪些想要的功能没有，多给一些时间，Issue 上总能看到一大把。
Coze 作为已经上线一年多的平台产品，除了框架代码外，实际上更珍贵的是各种用户在上面的创作，包括很多工具生态，但是 Coze 目前对这些相关的资源做了保留。
这是显而易见的，否则我换个域名马上便是第二个 Coze 了。
而对于开源协议来说，这是任何做商业化的公司必须重点关注的。
像之前的 Dify 和 n8n 对商业化是有一些限制的。
其中，Dify 是一个 Apache 修改版本协议，自己加了一些商用限制。
https://github.com/langgenius/dify?tab=License-1-ov-file
而 n8n 则有明显的商业限制，想商用必须付费获得一些授权。
https://github.com/n8n-io/n8n?tab=License-1-ov-file
但是，Coze 这次的协议是原始的 Apache2.0，这是非常宽松的，可以随意使用，这意味着想商业尝试没有授权成本上的负担，个人工作室找个云部署就可以做。
https://github.com/coze-dev/coze-studio?tab=Apache-2.0-1-ov-file
对于官方来说，开源可以提高一些影响力这个不用多说。更重要的是，开源也意味着把一些事情交出去了。
一方面，开源释放了一个 to C 到 to B 的极强信号。
因为私有化部署就是要这份代码的，如果不想把内部完全体版本送给人家，那么不如搞一个开源版本。基于这个开源版本来谈合作，并商讨提供哪些优化和支持就更加方便了。
另一方面，要做 to B，每个企业有自己的需求，一定会做各种 DIY，那么光靠自己内部的团队研发，点子总是欠缺的，只有打造围绕自己产品的生态，积极拥抱社区，才能汲取更多的养分，获得更多的成长。
每一个使用 Coze 开源项目的人，只要提了 Issue，有人解决贡献代码，有人测试，都是在发展围绕 Coze 的生态。
同时，它与其他的类似平台也产生了竞争，在这块市场没准真能抢下不小的蛋糕，除了开源本身外，还应该看到开源所带来的附属价值，就好比 Qwen 开源 LLM，还可以卖微调和 cloud 服务。
对于我们来说，开源的好处就是又多了一种选择，且没有负担的那种。我们虽然不希望卷，但看到别人卷，也好像挺开心的，因为我们总是不亏的，除非我们正好是这个开源项目的打击对象，比如开源助长了竞争对手追平差距的可能性。
随着这份开源生态的完善，加上 Apache 协议，不知道又要诞生多少创业项目（套壳🐶）。
