> ## Content Index
> Fetch the complete content index at: https://nigzu.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Coze 平台 AI 聊天机器人的搭建案例
- URL: https://nigzu.com/coze-ai-chatbot-construction-case/
- Published: 2024-06-27T00:09:00.000Z
- Updated: 2025-06-08T17:41:55.000Z
- Author: 宁嘉
- Tags: 人工智障

大语言模型问世一年半，出现了越来越多有意思的东西，例如可以在聊天中触发一些UI互动，让大模型使用第三方工具，执行一些自动化工作流，使用低代码开发Agent 代理最近也非常火热，扣子（Coze）是其中优秀的平台，本次，我尝试在coze.cn搭建应用，看看目前主流平台的 AI 智能体开发方式，能不能替代前后端，能不能落地，具体会碰到什么问题？顺便也看看国产大模型表现如何。

我首先想到一种需求，了解开源领域的朋友们都知道，Github是开源项目的主要集中地，我们大抵是通过标星（stars）来关注一个仓库，长时间下来，stars数量已经有几百个乃至上千个之多了，这带来一个问题，我们关注一个项目通常不会细致的研究它的文档和代码，只大致了解了它的用处，过后可能也就忘了。当我们实际需要某种工具时，又常常想不起来，只能借助传统的搜索，包括GitHub自己的搜索功能，这效率有点低，经常就搜不到，因为开源项目的描述和我们关键词并不一定匹配。诚然，现在的大模型基本上都会爬取GitHub上的数据，但实际测试发现，它并不是真的“记住了”什么知识，并不能当作信息搜索引擎来用，要命的是，它还会一本正经的瞎编乱造，很难对它有什么信任，还有一点，开源领域，尤其是AI领域，发展地极为迅速，每周都有新的项目上榜，这方面大模型是完全无知的。很自然的我想到可以用知识库，AI+知识库是个有许多案例证明可以落地的解决方案。

## 现在，我来尝试用AI智能体解决这个需求

### 最理想的方案是什么？

通常我们会从多个渠道关注到GitHub上的项目，Star之后我希望能够自动的抓取、用AI分析、翻译总结（如果是中文用户的话）其产品功能特点及使用说明，然后导入到知识库，方便随时问询。

扣子提供了一整套在线开发AI应用的平台工具，首先可以用一个插件用来访问GitHub API 请求，然后用 工作流执行自动化，用AI整理信息然后导入到知识库，从用户体验上来说，就是在和 Bot 机器人聊天过程中智能调用工作流和知识库来完成从采集到查询的所有动作。

当然，首先从Coze的Bot商店、插件商店和工作流商店搜一下有没有同类工具，免得重复造轮子。

没有？先建一个GitHub API插件，有两种方式，一种是调用外部API来执行操作，扣子的API插件只能进行简单的单次请求，而GitHub Stars涉及到分页查询，并且我希望减少对外部工具的依赖，因此使用第二种方式：在Coze IDE中创建，这相当于是扣子内置的一个云函数平台，支持Node.js和Python3。

值得一提的这个IDE支持调试、手动导入依赖包，执行网络请求等，IDE中还有AI组件帮忙写代码，生成测试数据，很好很强大。

![](https://nigzu.com/file/Pasted%20image%2020240626184225.png)

在AI的帮助下，很快就把python脚本写好了，分别执行获取Stars列表、获取仓库基本信息、获取版本信息、获取readme的操作：

![](https://nigzu.com/file/Pasted%20image%2020240626183806.png)

为了美观，可以给插件绑定卡片，当获取到项目信息时，在聊天窗口增加一点展示效果。

![](https://nigzu.com/file/Pasted%20image%2020240626184627.png)

定义好接口，然后需要一个知识库来承接最终整理好的数据，然而我很悲催的发现，扣子对知识库的开放权限相当保守，不支持在插件或工作流中调用增删改的操作，也不提供知识库的API（这方面某些开源替代产品例如dify、fastgpt走在前面），基本上只能手动导入——从本地文档、飞书和外部API导入，其中API导入方式可以定时拉取，最快一天更新一次，虽然不支持即时同步，有比没有强。

我想尝试飞书表格，它提供开放API，然而接着悲催的发现，想在第三方应用接入飞书API，得在飞书上申请一堆认证，并且扣子知识库只支持从没有鉴权的API上导入，并且只能把API上返回json的一级节点作为表头，如果数据在子节点里面，那么它们会被折叠到一列里。

这是个麻烦，因为所有的在线表格产品都需要鉴权的，当然可以在服务器写一个脚本，处理数据并转发请求，先试试看再说！

[nocodb/nocodb](https://github.com/nocodb/nocodb?ref=nigzu.com) 是一款在线表格开源项目，支持多维表格、和外部数据库同步，提供docker部署，并且也提供云托管的产品，对于个人用户免费版完全够用，不过为了演示，我在自己的闲置的阿里云99服务器上装上了，只需一行 `docker run`：

需要API对NocoDB进行操作，很快在扣子平台创建好插件，这样coze从GitHub获取的数据也能直接在coze上导入nocodb，插件也支持自定义baseurl，方便其他开发者使用这个插件：

![](https://nigzu.com/file/Pasted%20image%2020240626192204.png)

接着要有一个转发请求，让无鉴权的知识库去定时拉取nocodb上需要鉴权的表格，为了方便演示，我还用开源的低代码平台[n8n-io/n8n](https://github.com/n8n-io/n8n?ref=nigzu.com)实现这一点，用户需要的话，可以用云托管的例如[Zapier](https://zapier.com/?ref=nigzu.com)。

![](https://nigzu.com/file/Pasted%20image%2020240626192858.png)

等准备好这一切，继续悲催的发现，知识库是能直接拉API，但是不稳定，有时候要手动试几次才成功，这涉及到网络问题还是没法调试的，只能放弃了/(ㄒoㄒ)/\~\~

![](https://nigzu.com/file/Pasted%20image%2020240626193208.png)

### 实施第二种方案

那就分两步，先在扣子上获取GitHub项目用AI整理并同步到在线表格中，然后再从平台下载表格文件（nocodb支持csv或xlsx导出），最后手动导入到扣子知识库。

这对用户来说，场景从原来的只需在一个聊天框提供账号名就能掌握自己stars的仓库回落到需要在第一个应用上生成数据，然后在第三方平台导出，接着再自己手动创建知识库和机器人，导入数据，然后开始对话，如果Star了新仓库，则重复执行上面的流程。

这对用户来说显然太麻烦了，中间也会碰到无数问题。不过，也可以根据这种方案来构想第二种应用场景：例如对于想要关注AI开源资讯的朋友，我可以提供一个聊天机器人，里面随时更新我追踪 的AI开源项目，这需要经常手动维护这个机器人。

![](https://nigzu.com/file/Pasted%20image%2020240626223641.png)

这个需求不明朗，后期要持续投入运维成本。但至少，可以先把从GitHub抓取再导入到nocodb这步流程先搭起来，这将面向所有GitHub用户，都可以用得上。

这也是我本次搭建花费时间最多的工作，在coze上搭建工作流，基本上就是面向过程拖控件，看到画布上挤满了模块控件和扭曲的线条，感觉头昏眼花，因为视觉元素在开发过程中本质是一种人脑工作带宽的低效占用。看看我创建的这两条流程（一条子流程）感受一下：

![](https://nigzu.com/file/Pasted%20image%2020240626200102.png)

![](https://nigzu.com/file/Pasted%20image%2020240626200121.png)

只要流程能跑通，这都不叫事！流程的处理方式一定时间能适应，最关键的是很容易弄得异常复杂，而且调试起来非常麻烦！怎么说呢，工作流中可以创建代码、调用插件和其他工作流，如果需要调试插件和子工作流，只能切换到另一个工作面板，拿数据一个参数一个参数的复制过去。为什么不在一个工作流中完成？避免过于复杂是一方面，另一方面工作流的代码模块能力有限（只是个沙盒），例如不能网络请求，流程不能执行循环复用、多线程，碰到数组数据或者分支并用只能创建一个子流程让它挨个处理。

我个人认为coze的工作流平台有很多优化的空间，例如自动创建输入参数、在参数输入时使用链式编程处理数据、增加对知识库的增删改操作、增加工作流内的全局变量、优化性能使页面不卡顿...

不过上面仍然是小问题，接下来才是重中之重：调用AI大模型，如果不是为了用上AI的能力，工作流也不是很有必要。在本次搭建的应用场景中，需要用AI总结GitHub项目的关键词，GitHub上自带的关键词不太够，还需要翻译readme说明文档。

扣子上支持自家的豆包和通义千问、智谱GLM-4、MiniMax、Moonshot、以及百川的，水平嘛半斤八两，模型该有的缺点它们都有，据说可以用插件悄咪咪的用上国外大模型😀。但是话又说回来了，扣子上自带的模型是免费的！免费？能用就完了！

多轮测试翻译大约3000字的内容，几个支持长文本输出的模型表现如下：

| 模型             | 平均运行时长 | 错误率                   |
| -------------- | ------ | --------------------- |
| 百川的Baichuan4   | 60s以上  | 错误率高（没有生成正确内容）        |
| Moonshot（128k） | 25s    | 错误率一般（未按格式输出，奇怪的响应错误） |
| MiniMax (6.5s) | 24s    | 错误率一般（未按格式输出）         |
| 豆包-角色扮演模型      | 48s    | 错误率高（没有生成正确内容）        |

大模型能不能高质量输出关键是prompt提示词，有人说调试大模型就像炼丹，玩的是玄学，这是我费了一番功夫调制出来的提示词，用户可能需要用不同的方式总结提炼GitHub项目的关键词，因此其中部分提示词可以通过外部参数传入：

![](https://nigzu.com/file/Pasted%20image%2020240626205351.png)

为啥像炼丹捏？无论你怎么调制，都无法100%确定它会输出符合要求的数据，扣子上支持约束它的输出格式：文本、markdown还是json，理想是json，如果是文本，还需要用代码正则表达式之类的去过滤其中的数据，这就是异常复杂，所以指定输出json，然后用变量直接获取其中的字段。我在提示词中反复强调输出的条件，饶是如此，模型有时候仍然无法产生有效的输出，我分析有三种情况涉及到模型的缺陷导致很难通过提示词来约束的：首先是输出内容格式和json不兼容，例如markdown中的某些语法；然后是输出超出长度限制导致json对象无法闭合，尽管提示模型压缩长度，但它实际上是无法准确判断字数的；还有就是模型响应超时。总而言之就是总有意外的情况出现，为此最终的解决办法是多试几次，不行拉倒。

为了方便做一些其他操作，我让数据导入到nocodb也更新到数据库，数据库也是coze提供的，在bot应用中，可以为用户创建个人的或公共的数据表，因此可以在会话记忆之外再保存一些长期可用的结构化数据，例如用户在聊天时关注一些特别的项目，同步到自己聊天机器人的数据库，再配合机器人附带的快捷指令、定时任务执行一些特别任务，例如接受某个项目发布新版本的定时推送。

上面两个流程是通的，更新数据库、导入到外部表最后输出响应，全程跑下来都没问题。但是回到最初的需求：我GitHub上都关注了几百个仓库，一个没问题，一多就出故障了，除了上面说的模型可能未能正确输出外，扣子平台对使用批处理也有限制（最大并发10，批次数200，也就是一个工作流最多执行2000次子流程），一个项目流程运行大概需要1分钟，在工作流中如果并发多个需要长时间响应的子流程就失败了（有时候又成功），没有足够的错误信息，不知道为什么。

![](https://nigzu.com/file/Pasted%20image%2020240627033657.png)

另外，如果工作流传出的是数组，尽管对特殊字符做了处理，聊天机器人响应这些数据可能报错：

![](https://nigzu.com/file/Pasted%20image%2020240626220541.png)

这大概是内部数据转换出了问题，属于系统的BUG。

好吧，只得进一步简化工作流，去除数据库等查询功能，AI重试次数改为1次，不做翻译了，只总结+提词，然后把应用搭起来，只做导入功能：

![](https://nigzu.com/file/Pasted%20image%2020240627045618.png)

成功在NocoDB看到导入的数据：

![](https://nigzu.com/file/Pasted%20image%2020240627045905.png)

尽力了，可惜扣子不支持导出应用和工作流，不然我可以拿到它在海外的平台（coze.com）上试试gpt-4的表现，或者开源。有时间了我在自己的服务器上搭这套流程试一下，现在就这样吧！

### 实施第三种方案

自动维护知识库看起来是很难找到方案落实了。现在用上面做的插件还可以实现一种需求：在聊天机器人上获取GitHub的信息，考虑到扣子提供数据库等一些独有的工具，我们还可以让机器人记住并做一些自动化的工作。我把上面的数据库相关的工作流摘了出了：

![](https://nigzu.com/file/Pasted%20image%2020240627061652.png)

其中模型只做提取关键词，不做翻译了，另外值得一提的是写数据表需要对sql做出检查（如下），不然很容易因为意外出错，而扣子工作流的数据库节点只能对sql语句进行拼接，碰到参数为null的情况无法处理，因此要用代码节点做这番工作：

![](https://nigzu.com/file/Pasted%20image%2020240626230938.png)

最后构建Bot应用，扣子支持单Agent和多Agents模式，单Agent就是在一个代理中安装所有的插件、工作流，然后用提示词引导机器人在对话中决定应该调用哪个工具，而多Agents则是前置一个Agent先尝试对用户的问题进行分类，然后再引导到后面不同的Agent使用不同的提示词和调用不同的工具。

我选择多Agents构建 GitHub追踪的应用，分为获取账号中Stars列表，获取仓库最新发布的版本信息以及调用一上面的工作流获取仓库的详细信息并存入用户个人的数据库。

![](https://nigzu.com/file/Pasted%20image%2020240626232234.png)

然后发布应用，扣子在多个平台都有聊天机器人接口，一键上架，这也是它的好处之一，不一会儿就可以在Bot商店搜到。

考验模型真正实力的时候到了，先点个“最近关注”试试：

![](https://nigzu.com/file/Pasted%20image%2020240626233218.png)

尽管设置了提示词和多Agents模式，模型仍然无法准确的识别用户对话的意图以决定调用哪个工具，为此特意设置四个快捷指令，分别从数据库查询、从GitHub账号中查询和指定调用工作流或插件，就像一只老喜欢跑东跑西的马儿，得有根桩给它栓在那儿，等跑偏的时候，就拽一下马绳。

![](https://nigzu.com/file/Pasted%20image%2020240627061200.png)

# 总结

终于，我花了将近一周的时间开发两个AI应用，一个我只能说测试用途大于实际用途。一个还算能做一些便捷的事情。目前的结论是Agent 类应用想要落地存在诸多困难，从开发体验上来说，扣子这个平台有许多亮点，传统的开发需要配置开发环境、准备测试用例，然后发布、上架都要费一番周折。扣子最大的亮点我认为有两个，一个是在云上随开即用，一个是用无缝融合AI辅助开发，包括生成logo、生成代码、测试数据...我觉得这类AI应用及其开发方式能替代相当一部分传统互联网产品，未来可期。

![](https://nigzu.com/content/images/2024/06/Pasted-image-20240627074348.png)

![](https://nigzu.com/content/images/2024/06/Pasted-image-20240627074429.png)

![](https://nigzu.com/content/images/2024/06/Pasted-image-20240627074446.png)