{"id":35809342,"url":"https://github.com/thirdgerb/chatbot","last_synced_at":"2026-01-07T14:04:11.090Z","repository":{"id":56956872,"uuid":"168803242","full_name":"thirdgerb/chatbot","owner":"thirdgerb","description":"framework to build chatbot which could handle complex multi-turn conversation by engineering, like build website or app","archived":false,"fork":false,"pushed_at":"2022-01-26T08:22:30.000Z","size":4619,"stargazers_count":153,"open_issues_count":3,"forks_count":21,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-01-21T21:36:40.187Z","etag":null,"topics":["chatbot","chatbot-framework","conversational-bots"],"latest_commit_sha":null,"homepage":"","language":"PHP","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/thirdgerb.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2019-02-02T06:43:10.000Z","updated_at":"2025-01-14T10:20:20.000Z","dependencies_parsed_at":"2022-08-21T04:40:30.412Z","dependency_job_id":null,"html_url":"https://github.com/thirdgerb/chatbot","commit_stats":null,"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"purl":"pkg:github/thirdgerb/chatbot","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thirdgerb%2Fchatbot","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thirdgerb%2Fchatbot/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thirdgerb%2Fchatbot/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thirdgerb%2Fchatbot/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/thirdgerb","download_url":"https://codeload.github.com/thirdgerb/chatbot/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thirdgerb%2Fchatbot/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28235811,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2026-01-07T02:00:05.975Z","response_time":58,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["chatbot","chatbot-framework","conversational-bots"],"created_at":"2026-01-07T14:01:51.322Z","updated_at":"2026-01-07T14:04:06.935Z","avatar_url":"https://github.com/thirdgerb.png","language":"PHP","readme":"# Commune 项目介绍\n\n\"Commune\" 有亲切交谈的意思，CommuneChatbot 项目旨在提供一个对话机器人的开源开发框架。\n\n本项目是作者本人对于 ```对话交互``` 技术领域的个人探索，2019年完成了 v0.1 版本，2020年仍在探索 v0.2版本。\n\n__由于作者犯了一些策略上的错误，\nv0.2 版短期内无法完成开源__\n\n简单来说，一个可推广的开源项目应该上手简单，文档清晰，有明确的应用方向，然后是高质量和持续维护。\n\n但由于作者的策略错误（也和 covid-19 疫情有关），用完了开发时间，却没有达到以上标准。\n\n0.2 距离理想状态还差：\n\n- 完整的文档\n- 开箱即用，有价值的应用\n- 生产级可用的组\n- 管理后台\n\n接下来的计划是：\n\n- 优先完成技术思路的相关文档\n- 作为个人项目，开发一些实际可用的应用\n- 将 0.2 版核心模块拆分成独立项目，降低开源成本\n\n您也可以把这个项目当成对话系统的一种探索思路来看待。\n如有兴趣，也可以加入讨论 QQ 群 (907985715) 交流。\n\n本文后半部分会介绍作者的开发历程和现阶段的反思，与您分享。\n\n## Commune 项目定位\n\n对话机器人目前有两种主流的应用方向，```对话交流```(闲聊，问答，陪伴等) 与 ```对话式控制``` (任务，智能家居，车载对话OS，chatops，声控等)。\n\nCommune 项目本意是实现一个通用的对话机器人框架，而偏重于 ```多轮对话管理```。\n\n目前```多轮对话管理```有偏算法和偏工程两条道路，在```对话式控制```的场景中（低资源、冷启动、对话轮次较深），目前行业多见偏工程的做法。\n\nCommune 是基于类似工作流的方案，用工程手段实现对话管理。目的在于解决 [复杂多轮对话](/zh-cn/core-concepts/complex-conversation.md)，[非阻塞对话](/zh-cn/core-concepts/nonblock-conversation.md)，[对话任务调度](/zh-cn/core-concepts/multi-task.md)，[对话式编程](/zh-cn/core-concepts/conversational-coding.md)，[跨设备对话机器人](/zh-cn/core-concepts/multi-devices.md) 等问题。\n\n对标的项目是 [botkit](https://botkit。ai/)，[hubot](https://github。com/hubotio/hubot)，[botman](https://github。com/botman/botman) 等。\n\n\n## Commune 项目现状\n\n2019 年初步完成了 v0.1 版本，相关 Demo 地址在:\n\n- 网站: https://communechatbot。com\n- 开发文档: https://communechatbot。com/docs\n\n2020 年 9月初步完成了 v0.2 的 Demo，相关 Demo 地址在:\n\n- 网站: https://communechatbot。com/chatlog\n\nv0.2 版核心功能均已实现，但已没有条件推进到开源可用的地步。目前最接近 Ready 的领域:\n\n- 钉钉机器人的对接 (outgoing + webhook)\n- ChatOps 基础功能 (命令行/异步任务)\n- 基于 Markdown 的文档库，反射成多轮对话 + 问答\n\n这几个功能接下来会优先推进。\n\n\n## 作者开发经历分享\n\n写于 2020-11-26\n\n### 为何要开发对话机器人项目?\n\n简单来说，作者对```对话式交互```有浓厚的兴趣，并有一系列对话式产品的设想，认为对话交互的优势在于:\n\n- 走向语音交互,__解放双手__ (hands free)，__解放双眼__ (eyes free)，从而解放生产力\n- 相比复杂应用的图形界面，可实现 __意图直达__\n- 交互比触屏更贴近人的直观想象，使用成本更低\n- 一套应用开发，可适用于各种 IM 和语音控制设备\n- 未来所有的智能应用，都会有对话式交互的界面\n\n关于产品的部分设想:\n\n- ```对话式 wiki```: 在对话中完成知识的 输入/编辑/查询 等，结合图形界面来展示\n- ```IM OS```: 在 IM 里完成运维，办公，购物，应用等各种任务\n- ```语音控制```: 通过语音控制图形界面，物联网硬件，智能设备等\n- ```场景控制```: 为 在线课堂/车内/家居/商场门店 等综合场景提供统一的对话式控制\n- ```机器人 IM平台```: 由对话机器人作为联系人的 IM，每个机器人都是一个独立应用\n\n作者最希望实现的是 ```对话式 wiki```，在 2015年 ~ 2018年的个人探索中，发现现有的各种技术和框架无法实现产品需求,\n主要是无法解决 [复杂多轮对话](/zh-cn/core-concepts/complex-conversation.md) 问题。\n\n按作者个人理解，```对话交互``` 本质上和其它各种常见交互 (仪表盘/桌面应用/ 触屏应用) 一样，都需要解决 ```交互``` 面临的 状态管理/任务调度 等问题。\n由于对话交互的产品现阶段还不成熟，导致这个领域的技术实现还未被行业重视，所以没有趁手的工具。\n\n作者在 2017 ~ 2018年在任职公司参与了三版对话机器人的开发，对此积累了许多技术上的思路，于是从 2019年着手独自开发 Commune 项目。\n\n由于我设想的产品功能较为复杂，几乎不可能独立开发完成。因此想加入对话交互系统的开发团队来推进想法。\n\n在 2019 年完成 Commune v0.1 版之后，一度得到了某公司对话系统团队的认可，约定年后入职。但在入职之前遭遇了 covid-19 疫情，对方单位收缩，取消了 HC。\n\n在 19 年与该单位面试交流时，我提出了一些更激进的工业场景解决方案，包括 \"跨设备机器人\" \"非阻塞对话\" \"多任务调度\" \"对话式编程\" 等。\n而在疫情期间进退两难的情况下，选择坚持独自实现了这些技术方案，于是有了 [Commune v0.2版的 Demo](https://communechatbot。com/chatlog)。\n\n\n### 目前的开发遭遇的困难\n\n而现阶段作者遇到的困难是:\n\n- 个人经济条件，不允许再脱产来完善项目\n- covid-19 疫情期间的独立开发让人极为疲惫，动力不足\n- v0.2 版架构过大，一个人已无法在短期内完善到开源可用\n- 因为种种原因，无法进入到对话系统的业内\n- 个人并没有一个短期内能落地的，能挣钱的对话应用业务\n- 认识到了自己能力不足的地方\n\n所有原因归纳起来，是因为我视野、能力和经验均有不足，导致花了很多心血所做的探索，没能力使之立刻转化成对社区的价值。\n\n所以我现在的想法是：\n\n- 回到与实际业务紧密结合的工作中，重新提高自己技术能力与视野\n- 将 v0.2 的各种技术成果拆散，应用到实际场景中\n- 坦诚总结经验教训，与朋友们分享\n\n### 开发策略错误的总结与分享\n\n#### 1. 技术方案错误地超前于行业需求\n\nCommune 在对话系统中探索的方案，如 ```复杂多轮对话/非阻塞对话/多任务调度/对话式编程/跨设备机器人``` 等，作者仍认为是对话交互技术未来必然要解决的问题。\n\n不过有大佬说得好，```你做了一个新技术，不一定是你厉害，多半是行业还不屑于做```。\n 当对话系统的工业界需求推进到这一步时，相信有工程师作出更成熟的解决方案。\n\n而现阶段对话式产品普遍交互轮次较浅，更谈不上 ```非阻塞/多任务``` 了。\n\n由于我不在行业内，不拥有业务，这些略超前的探索无法与具体产品形态结合，也无法推动行业发展。\n\n除非基于这些功能，开创出一种远超行业现状的新产品，来自我证明；但目前没有条件，缺乏信心和决心。\n\n对于开源项目而言，这些技术方案又引入了更多不同于主流方案、令开发者费解的新概念，反而增大了推广成本。\n\n\n#### 2. 技术探索优先于产品\n\n开发 Commune 项目前后有数十万行代码，但重点都放在技术方案的实现上，只有不到 1/10 的精力用于产品，且都停留在 Demo 阶段。\n\n一个不够酷的 Demo 无法让用户立刻明白项目的长处。\n\n而一些有用的产品方向，如 ```markdown 文档转多轮对话/问卷调查/问答/对话式游戏/chatops``` 等，目前没有一个推进到 __开箱即用__ 的水平。\n\n这使得现阶段推广这个项目缺乏明确应用场景。\n\n\n#### 3. 过早推行生产级方案\n\nCommune 项目代码中一直考虑生产级可用，许多环节针对生产级场景的需要，做了解决方案。\n\n例如项目需要大量读取对话逻辑的配置，考虑到分布式系统 ```配置存取一致性/存储介质差异```，设计了 [OptionRegistry](/zh-cn/studio/option.md) 的方案,\n可以从设置好的任意存储介质 (Mysql/file/redis 等) 中读取配置。\n\n且不论给出的方案不一定是最佳实践，这要求使用本项目要学会开发和注册 Option Storage，对于一个开源项目而言反而增加了使用成本。\n\n为了降低用户的成本，作者又得开发大量的默认配置方案，又增加了维护成本。\n\n#### 4. 架构设计过大\n\nCommune 项目核心技术是 \"复杂多轮对话管理\"，但项目本身试图实现一个全栈式的对话机器人框架。设计之初，作者一直按一个开发团队的思路去规划功能。\n\n因此框架 3/5 的内容都是 ```IoC 容器/服务注册/协议匹配/配置存储/服务间通讯/跨设备/消息多模态渲染``` 等，战线越来越多。\n\n这对一个工业级框架而言是必要的，但作为个人项目，它不仅意味着开发成本、还意味着线性增加的维护成本。倒过来导致许多个环节都未做到生产级可用。\n\n例如：\n\n- 目前 Shell层与 Ghost层的通讯使用的仍是 Tcp ```\\r\\n``` 分包\n- 广播总线仍使用 Redis 的 pub/sub，没解决消息送达的问题\n- 数据库连接池的异常容错不完善\n\n尽管基于 IoC 容器都设计了抽象，仍需要开发团队自己在生产环境中完善之。 这对于开源项目反而是负面的。\n\n#### 5. 技术栈脱离行业主流生态\n\nCommune 项目的方案是完全用面向对象的 [Interface](https://github。com/thirdgerb/chatbot/tree/master/src/Blueprint) 先设计完成的。\n\n而项目本身是 PHP + [Swoole](https://www。swoole。com/) + [Hyperf](https://hyperf。io) 的一个实现。\n\n作者认为由于 PHP 的几个优点:\n\n- 优秀的高级语言动态性\n- 弱类型与强类型约束兼备\n- 面向对象与匿名函数兼有\n\n使 PHP 非常适合实现 Commune 的设计。\n\n尽管如此，在我接触对话机器人相关企业时，面临的现状是绝大多数公司都在使用 Java。\nJava 在工业级架构里的生态，的确比现阶段 PHP + Swoole 要成熟。\n\n这使得作者用 PHP 实现的解决方案，对于这些公司而言风险过高，缺乏说服力。\n已经有多位朋友提出希望用 Java 重构项目的内核。\n这也是令人尴尬的现实。\n\n\n#### 6. 个人的技术瓶颈\n\n设计 Commune 项目时，许多功能组件考虑到了工业级的需求，设计成了 Interface。\n但作者自身的技术栈不够完整，许多环节无法给出工业级的实现。\n\n例如 NLU (自然语言理解单元) 部分，由于需要一个可动态添加语料的 NLU，作者找不到成熟项目替代的情况下，只能临时用 SpaCy 做了一个 [单点的 NLU 项目](https://github。com/thirdgerb/spacy-nlu)。\n\n另外接触一些对话系统的公司时，由于在起步阶段，都希望加入的是一个拥有全方位解决方案的总工角色。 而作者本人的技术能力与工作经历，还达不到工业级项目总工的水平。\n而自己对话系统的解决方案，又与行业主流的方案有较大差别。\n\n\n#### 小结\n\n综合以上分析，作者认为自己最大的错误在于没有认清 ```个人开源项目``` 的定位。\n导致:\n\n- 对于 \"项目\"，应用场景和价值不够明确\n- 对于 \"个人\"，开发工作量过大\n- 对于 \"开源\"，完成度不够高\n\n其结果是既不利于开源推广，也难以立刻得到行业认可，而自己也没有独立的业务可以去推进。\n倒过来无人参与，更难独自开发。\n\n这个经验教训供您参考。\n\n### Commune 项目接下来的计划\n\n1. 暂时不把精力用在完善开源上\n1. 优先完成技术方案的介绍文档\n1. 用业余时间推进 钉钉/chatops 等功能\n1. 作为个人项目，开发小的、有价值的应用\n1. 将核心功能 （例如对话管理内核 Ghost）独立拆分，降低开源成本\n\n对此若有任何批评与建议，欢迎您留言。\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthirdgerb%2Fchatbot","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fthirdgerb%2Fchatbot","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthirdgerb%2Fchatbot/lists"}