[JS/TS] OpenClaw实战：飞书部署私人AI助理与Discord搭建协作Agent团队

最近我用OpenClaw这个框架搭建了两套风格迥异的人工智能系统，一套部署在国内腾讯云，对接飞书；另一套跑在海外VPS，连接Discord。虽然底层是同一个框架，但实际用下来，它们展现出的“性格”和适用场景差异巨大。

飞书系统：高效克制的私人助理

飞书里的这个AI，更像是我每天都会用到的私人助手。它的存在感不强，但干活利索。比如，我在群里随口说一句“你先提交代码，我一会儿review”，它就能自动帮我整理好代码提交信息，包括分支名、提交SHA、改动文件列表，格式清晰明了。

日常提醒也做得很好。我设置了让它每天固定时间提醒我写日记，到点它就会准时出现：“今天2026年2月11日，该写日记了。” 无论是工作进展、一闪而过的灵感还是日常琐碎，直接丢给它，它就能帮我整理成结构化的日记内容。

更有意思的是，我通过MCP将日记发布流程也自动化了。整个流程在飞书聊天窗口内一气呵成：我口述日记内容，AI助手帮我整理格式、确认天气信息，然后一键发布到墨问笔记。它会明确反馈“日记已发布到墨问笔记！”，并附上访问链接。

这种体验让我感觉到，AI的价值不只在于处理单一任务，更在于帮你“完成闭环”，从信息输入到归档输出全程无缝衔接。

它还能充当安全哨兵。有一次，它主动发来一份安全检查报告，提示服务器存在持续的SSH暴力破解攻击，列举了近期的失败登录IP，并建议立即配置fail2ban。这时候你不会觉得它只是在回答问题，而是真感觉有个助手在帮你盯着服务器。

总的来说，飞书这套系统非常稳定、日常、克制。它适合生产环境，契合公司协作语境，能有效管理每日效率。但相应地，它也比较“规矩”，受限于网络访问策略和权限控制，像一个在标准流程下工作的办公室员工。

VPS系统：自由实验的AI团队

切换到VPS上的Discord系统，画风就完全变了。这里我没有只部署一个Bot，而是搭建了五个，构成了一个小型AI团队。每个角色都有独立的profile、Gateway和端口。

端口规划是关键，我采用了间隔20的分配方案：

18789
18809
18829
18849
18869

为什么要间隔20？因为Gateway启动时不止占用一个端口，它会自动派生出一系列用于浏览器控制、画布、CDP等的内部端口。如果两个实例的端口挨得太近，这些派生端口就会发生冲突，导致实例无法启动，表象就是“起不来”，根因是浏览器调试端口冲突。这是踩过坑后总结的经验。

部署流程其实很清晰：

1. 初始化角色：

   openclaw --profile daxiong onboard

2. 配置端口：

   openclaw --profile daxiong config set gateway.port 18809

3. 前台验证（看到listening on ws://127.0.0.1:18809即成功）：

   openclaw --profile daxiong gateway --port 18809

4. 安装为服务：

   openclaw --profile daxiong gateway install

   部署中也遇到过问题，比如手改openclaw.json添加mcpServers字段导致网关挂掉，终端报错Unrecognized key: "mcpServers"。好在官方提供了修复命令兜底：

   openclaw --profile daxiong doctor --fix

   从此我学会了尽量用命令行配置，避免直接手改JSON文件。

为什么选择Discord？因为自由

选择Discord连接这套系统，核心原因就是自由。相较于飞书那种“办公室”氛围，Discord更像一个“实验室”，至少在网络连通性上省心不少。

在Discord群里，我可以让五个AI角色互相@，进行任务交接。我为他们设定了分工：大熊（项目经理/需求分析）、冯道（架构）、莉莉（需求细化）、阿杰（开发）、静静（测试）。

当我发出指令“@大熊 我想做一个审批系统”，它会开始拆解需求，然后@冯道进行架构设计，架构完成后@阿杰进行开发实现，阿杰交付后再@静静进行测试。这种感觉很奇妙——你不是在和一个机器人对话，而是在指挥一个真实的团队协同工作。

例如，有一次我让团队升级OpenClaw版本。大熊作为项目经理，直接在群里@了其他四位成员，发布升级命令npm update -g openclaw，并要求大家完成后回复“已完成”。

随后，大熊又让大家运行openclaw --version确认升级状态。你能看到莉莉、冯道、静静陆续回复“已完成”或具体的版本号。

尽管你清楚地知道他们都是AI，但当看到五个角色在聊天群里接力完成一项任务时，那种“团队在有序运转”的沉浸感是真实可感的。

目前这五个角色都运行着zai/glm-4.7模型，能够正常工作。我下一步的计划是根据岗位特性匹配不同的模型：让开发角色使用编码推理能力更强的模型（如Claude Code），需求分析角色使用表达更清晰的模型，架构师使用推理能力更强的模型，测试角色可以继续使用glm-4.7（它生成测试矩阵很稳定）。当模型能力与岗位职责相匹配时，每个AI的输出才会真正具备独特的“性格”，而不是五个简单的复制体。

总结：两种部署，双重价值

回顾这两套系统，它们对我而言意义不同。飞书那套是提升效率的私人助理，专注于帮我处理具体事务、设置提醒、监控服务器。VPS上的Discord系统则是一个探索未来的组织实验场，我在上面测试角色协作、分工流程以及模型与岗位的匹配度。一套务实，一套前瞻。

这让我思考，AI Agent的真正价值或许不在于替代某个人，而在于让个体有能力驱动一个团队。当你真正在服务器上部署好多个独立角色，并看着他们在聊天工具中协作推进项目时，你会突然意识到：你不仅仅是在使用工具，你正在设计一种全新的、数字化的组织形态。

这正是一场激动人心的开源实战。如果你也对Agent的落地应用感兴趣，或者想聊聊具体的部署细节，欢迎来云栈社区的开发者广场一起交流探讨。