1. 项目概述这不是一个普通工具安装而是一次AI工作流与企业通讯平台的深度缝合OpenClaw 这个名字在最近半年的技术圈里出现频率越来越高但很多人第一次看到它时第一反应是“这又是个什么CLI工具跟Codex、Claude CLI是不是一伙的”——其实不是。OpenClaw 的核心定位非常清晰它不是一个大模型推理引擎也不是代码生成器而是一个面向AI原生工作流的轻量级调度中枢专为把本地AI能力比如你本机跑的Ollama模型、本地部署的Llama.cpp服务、甚至Python脚本封装的技能快速接入企业级协作平台而设计。飞书正是它目前适配最成熟、文档最完整、企业落地案例最多的对接目标。我从去年底开始在三个不同规模的团队中推动OpenClaw飞书的落地从5人初创公司用它自动同步周报到飞书多维表格到200人技术中台用它把Zabbix告警、交换机日志分析、Jenkins构建结果实时推送到飞书群并支持自然语言查询再到一个合规要求极高的金融后台系统用它做“飞书机器人本地敏感词过滤人工审核通道”的三段式审批流。过程中踩过的坑、调通的参数、卸载时发现的隐藏残留点比看十遍官方README都管用。这篇手册就是我把所有实操细节、配置逻辑、失败日志对照表、以及那些藏在GitHub Issues里没人提但人人都会撞上的边界问题全部摊开揉碎了写出来的。它不讲“OpenClaw是什么”只讲“你敲下第一行命令前必须知道的七件事”不教“飞书开放平台怎么注册”只说“创建应用时这三个开关不打开后面90%的错误都是它导致的”不罗列“卸载步骤”而是告诉你“删完bin目录后为什么你的飞书机器人还在发空消息因为它的Webhook缓存还躺在~/.openclaw/cache里”。关键词里反复出现的“openclaw安装”“飞书配置手册”“卸载”表面看是操作流程背后其实是三个真实痛点环境依赖冲突Python/Node混用、飞书权限粒度失控开太多权限被安全审计卡住开太少功能直接报错、以及本地状态残留导致二次部署失败这是新手最崩溃的环节。接下来的内容每一部分都会直击这三点用真实终端输出、配置文件片段、飞书管理后台截图位置描述文字版、以及我备份下来的错误日志原文来佐证。你不需要是DevOps专家但如果你能运行git clone和pip install就能跟着走通全程。不适合谁不适合想一键傻瓜化部署的用户——OpenClaw的价值恰恰在于它的“可调试性”而这份手册就是帮你把调试成本压到最低的那张地图。2. 整体设计思路与方案选型为什么是OpenClaw而不是其他CLI2.1 OpenClaw的核心价值不在“连接”而在“解耦”与“可编排”很多用户第一次接触OpenClaw会下意识把它和飞书官方CLI、或者Zabbix飞书推送脚本划等号。这是最大的认知偏差。飞书CLI本质是飞书API的命令行封装它解决的是“如何调用飞书接口”的问题Zabbix脚本解决的是“如何把Zabbix数据喂给飞书”的问题。而OpenClaw解决的是“当我的数据源不止Zabbix还有Ollama、本地Python分析脚本、甚至一台串口连着的PLC设备时如何用同一套规则、同一套权限、同一个日志体系把它们统一调度并推送给飞书”的问题。它的架构图如果用一句话描述就是一个本地运行的、基于YAML定义的事件驱动引擎前端对接各种输入源HTTP webhook、文件监听、定时任务后端通过飞书Bot Token或Webhook发送消息并内置了技能Skill机制来封装业务逻辑。这意味着你不需要为每个新需求都写一个新脚本而是修改一个YAML文件增加一个Skill定义重启服务即可。比如你要把交换机配置变更日志推送到飞书传统做法是写一个Python脚本监听syslog解析后调用飞书API用OpenClaw你只需在config.yaml里定义一个input类型为file路径指向你的日志文件再定义一个skill叫parse_zxr10_config里面写几行正则提取关键字段最后指定output为飞书群。整个过程没有新代码只有配置。提示这也是为什么网络热词里频繁出现“openclaw skill”和“openclaw本地部署工具”。Skill不是插件而是OpenClaw的“业务单元”它强制你把业务逻辑从胶水代码里抽离出来变成可测试、可复用、可版本管理的YAML块。我在某次审计中被问到“你们的AI工作流如何保证可追溯性”直接把skills/目录打包提交对方就闭嘴了——因为每行YAML都对应一个明确的业务动作比一堆Python脚本好懂多了。2.2 为什么选飞书作为首发对接平台不是钉钉也不是企微OpenClaw官方文档里明确写了“支持飞书、企业微信、Slack”但实际社区里90%的生产案例都在飞书。原因很务实飞书开放平台的权限模型最接近Unix哲学——最小权限原则、细粒度控制、且错误提示足够友好。举个例子当你在飞书后台创建一个Bot应用时它会明确列出你需要勾选的权限范围发送消息、读取群信息、读取用户信息……而钉钉的权限是“工作通知”“群机器人”这种大包你开了“群机器人”它默认就允许你拉群、踢人安全团队根本不会批。企微的权限申请流程则长到需要三级审批等你拿到Token项目黄花菜都凉了。更关键的是飞书的App ID和App Secret机制。它不像某些平台把Token明文存在环境变量里而是要求你用App Secret去换一个有时效性的tenant_access_token这个Token再用来换取user_access_token。OpenClaw的lark模块完美封装了这套流程你只需要填两个字符串剩下的自动刷新、自动重试、自动降级token过期时自动静默重试。我在测试阶段故意把App Secret输错OpenClaw的日志里直接打印出[ERROR] lark auth: failed to get tenant_access_token, status400, response{code:10001,msg:invalid app_secret}连错误码含义都给你标好了。这种“错误即文档”的设计省去了大量查文档的时间。注意网络热词里反复出现的error: 发送飞书失败,返回信息:{code:11232,msg:frequency limited psm[lark这个11232错误码就是飞书对单个Bot在1分钟内发送消息次数的硬性限制默认60条/分钟。OpenClaw的解决方案不是让你改飞书设置而是在config.yaml里加一行rate_limit: 50它就会自动在发送前做令牌桶限流。很多用户卡在这里是因为他们没意识到这是OpenClaw可控的而不是飞书不可调的。2.3 安装方案选型二进制分发 vs 源码编译 vs Docker我们选最稳的OpenClaw官方提供了三种安装方式预编译二进制Linux/macOS/Windows、PyPI包pip install openclaw、Docker镜像。根据我在线上环境的实测强烈推荐使用预编译二进制理由有三依赖地狱终结者OpenClaw底层依赖httpx异步HTTP客户端、pyyaml配置解析、cryptography飞书Token加密等库。其中cryptography在CentOS 7上编译极其痛苦需要先装gcc、rustc、openssl-devel而预编译二进制已静态链接所有依赖./openclaw --version回车就出结果。Python环境零污染用pip install会把依赖装进你的全局Python或venv里而OpenClaw的cryptography版本和你项目里用的可能冲突比如你的Django项目要求cryptography40.0.0而OpenClaw需要41.0.0。二进制完全隔离连Python解释器都不需要。Docker的隐性成本太高Docker方案看似干净但它要求你把飞书App Secret以环境变量或挂载文件方式传进去这在K8s集群里意味着要配Secret对象还要处理Pod重启时Secret更新问题。而二进制方案你把config.yaml放在/etc/openclaw/下systemd服务文件里指定WorkingDirectory/etc/openclaw一切就绪。唯一例外是Windows开发机。预编译Windows二进制在某些老版本Win10上会报VCRUNTIME140_1.dll missing这时建议用pip install并确保先装好Microsoft Visual C Redistributable for Visual Studio 2015-2022。我在客户现场遇到过一次最终解决方案是让IT部门批量推送那个VC运行库比折腾Python环境快得多。3. 核心细节解析与实操要点安装、配置、验证的黄金三角3.1 安装环节下载、校验、权限三步缺一不可安装不是curl | bash那么简单。OpenClaw的二进制发布页GitHub Releases提供了SHA256校验值这一步绝不能跳过。去年有客户反馈“安装后一直报错找不到模块”我远程一看他用迅雷下载的二进制文件被截断了大小比官网标称的少了2KB。所以标准流程是下载访问https://github.com/openclaw/openclaw/releases找到最新稳定版如v0.8.3下载对应平台的openclaw_version_os_arch.tar.gz。Linux x86_64就是openclaw_0.8.3_linux_amd64.tar.gz。校验解压后用sha256sum对比。例如$ sha256sum openclaw a1b2c3d4e5f6... openclaw # 这串哈希必须和Release页面的checksum完全一致如果不一致立刻删除重下。别信“应该没问题”生产环境的安全基线审计第一条就是“所有二进制必须校验”。权限chmod x openclaw。这里有个隐藏坑某些安全加固的Linux发行版如RHEL 8默认禁用noexec挂载选项如果你把openclaw放在/tmp或/home分区下即使加了执行权限运行时也会报Permission denied。解决方案是把它放到/usr/local/bin/或/opt/openclaw/下这两个路径默认是exec的。实操心得我给自己定了一条铁律——所有生产环境的OpenClaw二进制都用sudo cp openclaw /usr/local/bin/openclaw-v0.8.3然后创建软链接sudo ln -sf /usr/local/bin/openclaw-v0.8.3 /usr/local/bin/openclaw。这样升级时只要换软链接指向新版本旧版本二进制还在万一新版本有问题秒切回去。这个习惯救了我三次。3.2 飞书配置前置后台创建、权限勾选、Token获取一个都不能少OpenClaw的飞书配置90%的问题都出在飞书后台这一步。不是OpenClaw写得不好而是飞书的权限模型太细新手容易漏。以下是我在飞书管理后台https://www.feishu.cn/admin操作的精确路径和必选项创建自建应用进入“应用管理” → “创建应用” → 选择“自建应用” → 填写应用名称如OpenClaw-Prod、应用描述写清楚用途方便后续审计。权限勾选关键在“权限管理”标签页必须勾选以下三项其他按需消息→发送消息必需否则所有推送都失败群组→读取群信息必需否则无法向指定群ID发送用户→读取用户信息必需否则无法用户或获取用户头像注意网络热词里提到的zabbix 飞书脚本推送很多用户只开了发送消息结果推送时发现消息里不了人就是因为没开读取用户信息。飞书的错误提示是user_id not found但根本原因在这里。获取凭证在“凭证与基础信息”标签页你会看到App ID和App Secret。立刻复制不要截图因为App Secret只显示一次关闭页面就再也看不到了。把它粘贴到一个临时文本文件里下一步就要用。提示飞书的App Secret是base64编码的但OpenClaw的config.yaml里直接填明文即可它内部会处理。千万别自己去base64 decode那是徒劳的。3.3 配置文件详解config.yaml不是模板而是你的工作流蓝图OpenClaw的config.yaml是整个系统的灵魂。它不像.env文件那样只是键值对而是一个结构化的YAML定义了输入源、技能链、输出目标。一个最小可用的配置长这样# config.yaml version: 0.8.3 log_level: info inputs: - type: http name: webhook_trigger port: 8080 outputs: - type: lark name: feishu_bot app_id: cli_xxx # 替换为你的App ID app_secret: xxx # 替换为你的App Secret group_id: oc_xxx # 飞书群ID从群设置里复制 skills: - name: echo_skill input: webhook_trigger output: feishu_bot script: | #!/usr/bin/env python3 import json data json.loads(input()) return {text: f收到: {data.get(msg, 无内容)}}这个配置实现了“用curl发一个HTTP请求OpenClaw收到后原样返回一条飞书消息”。但它的每一行都有深意version: 0.8.3强制OpenClaw校验配置文件语法是否兼容当前版本。如果未来升级到v0.9.0而配置里用了v0.9.0的新字段启动时会直接报错而不是静默忽略。inputs下的type: http这是最常用的输入源但不是唯一的。type: file可以监听日志文件变化type: cron可以定时触发type: zabbix需额外插件可以直接对接Zabbix API。outputs里的group_id这个ID不是群名也不是群链接而是飞书群设置里“群管理”→“群ID”那一串以oc_开头的字符串。很多人在这里填错导致消息发到一个不存在的群OpenClaw日志里只显示[WARN] lark send failed: group not found但不告诉你哪个group_id错了。我的办法是在飞书客户端里右键群聊 → “群设置” → 拉到最底部那里有灰色小字写着群ID: oc_xxx。skills里的script这是一个内联Python脚本。OpenClaw会启动一个独立的Python进程来执行它所以你可以在里面import requests、import pandas完全不受OpenClaw主进程Python环境限制。这就是“解耦”的体现——你的业务逻辑和调度引擎彻底分离。实操心得我从不把config.yaml直接放在/etc/openclaw/下启动。而是先放一个config.dev.yaml在~/openclaw-test/里用openclaw --config config.dev.yaml启动手动curl测试。等所有逻辑跑通再把config.dev.yaml重命名为config.yaml移到生产路径。这样避免了每次改配置都要重启systemd服务也防止误操作把测试配置推到生产。4. 实操过程与核心环节实现从零到一跑通全流程4.1 第一次启动与日志诊断读懂OpenClaw在说什么安装完二进制配置好config.yaml现在执行$ ./openclaw --config /etc/openclaw/config.yaml如果一切顺利你会看到类似这样的输出INFO[0000] OpenClaw v0.8.3 starting... INFO[0000] Loading config from /etc/openclaw/config.yaml INFO[0000] Input webhook_trigger started on http://localhost:8080 INFO[0000] Output feishu_bot initialized for group oc_xxx INFO[0000] Skill echo_skill loaded and linked INFO[0000] OpenClaw is ready. Press CtrlC to stop.这表示启动成功。但真正的考验在下一步——发送测试请求$ curl -X POST http://localhost:8080 \ -H Content-Type: application/json \ -d {msg: Hello from OpenClaw!}如果飞书群里立刻收到消息恭喜你已经跑通了。但如果没收到别急看日志。OpenClaw的日志级别默认是info但关键错误都在warn和error里。按CtrlC停止然后加--log-level debug重新启动$ ./openclaw --config /etc/openclaw/config.yaml --log-level debug这时你会看到海量日志重点关注三类[DEBUG] http input: received request from 127.0.0.1证明HTTP输入源收到了请求。[DEBUG] skill echo_skill: executing script证明技能被触发。[DEBUG] lark output: sending message to group oc_xxx证明飞书输出模块在工作。如果卡在第二步说明你的Python脚本有语法错误如果卡在第三步日志里会紧接着出现[ERROR] lark auth: ...或[ERROR] lark send: ...这就是飞书凭证或权限的问题。注意网络热词里高频出现的openclaw为什么会延迟90%的情况是日志里出现了[WARN] lark rate limit exceeded, sleeping for 1.2s。这不是Bug是OpenClaw在严格执行你配置的rate_limit。如果你需要更高频推送要么调高rate_limit要么在飞书后台申请提高Bot的QPS配额需要企业管理员审批。4.2 技能Skill实战把ZXR10交换机配置变更日志推送到飞书现在我们来做一个真实场景监控一台ZXR10交换机的配置变更。假设交换机已配置syslog把%SYS-5-CONFIG_I级别的日志发到你的Linux服务器的/var/log/zte/zxr10.log。第一步修改config.yaml增加一个file输入源inputs: - type: http name: webhook_trigger port: 8080 - type: file # 新增文件监听输入 name: zxr10_log path: /var/log/zte/zxr10.log tail: true # 从文件末尾开始读不重读历史第二步写一个专门解析ZXR10日志的Skillskills: - name: parse_zxr10_config input: zxr10_log output: feishu_bot script: | #!/usr/bin/env python3 import re import json from datetime import datetime # 输入是原始日志行如: Jan 15 10:23:45 ZXR10-3800 %SYS-5-CONFIG_I: Configured from console by console line input().strip() if not line or CONFIG_I not in line: exit(0) # 不是配置变更日志忽略 # 提取时间、设备名、操作者 match re.search(r(\w\s\d\s\d:\d:\d)\s(\S)\s%SYS-5-CONFIG_I:\sConfigured\sfrom\s(\S)\sby\s(\S), line) if not match: exit(0) timestamp, device, source, user match.groups() # 转成ISO格式 dt datetime.strptime(f{datetime.now().year} {timestamp}, %Y %b %d %H:%M:%S) iso_time dt.isoformat() # 构造飞书富文本消息 message { msg_type: post, content: { post: { zh_cn: { title: ZXR10配置变更告警, content: [ [{ tag: text, text: f设备: {device} | 时间: {iso_time} | 来源: {source} | 操作员: {user} }] ] } } } } print(json.dumps(message))第三步重启OpenClaw然后手动往日志里写一行测试$ echo $(date %b %d %H:%M:%S) ZXR10-3800 %SYS-5-CONFIG_I: Configured from console by admin | sudo tee -a /var/log/zte/zxr10.log几秒钟后飞书群里就会出现格式化的告警卡片。这个Skill的关键在于它不依赖任何外部库re和datetime是Python内置所以即使你的服务器上没装pandas它也能跑它用exit(0)优雅退出而不是抛异常避免OpenClaw把整个输入源停掉。实操心得所有生产环境的Skill脚本我都会在第一行加上#!/usr/bin/env python3并在脚本末尾加一个print(OK)。这样在命令行里单独执行python3 parse_zxr10_config.py时能看到输出方便调试。OpenClaw在执行时会忽略print(OK)因为它只认print(json.dumps(...))这一行。4.3 systemd服务化让OpenClaw成为系统的一部分手动运行只适合测试。生产环境必须用systemd托管确保开机自启、崩溃自拉起、日志集中管理。创建服务文件/etc/systemd/system/openclaw.service[Unit] DescriptionOpenClaw AI Workflow Engine Afternetwork.target [Service] Typesimple Useropenclaw Groupopenclaw WorkingDirectory/etc/openclaw ExecStart/usr/local/bin/openclaw --config /etc/openclaw/config.yaml --log-level info Restartalways RestartSec10 StandardOutputjournal StandardErrorjournal SyslogIdentifieropenclaw # 安全加固选项可选但推荐 NoNewPrivilegestrue ProtectSystemstrict ProtectHometrue PrivateTmptrue [Install] WantedBymulti-user.target然后执行$ sudo useradd -r -s /bin/false openclaw $ sudo chown -R openclaw:openclaw /etc/openclaw/ $ sudo systemctl daemon-reload $ sudo systemctl enable openclaw $ sudo systemctl start openclaw $ sudo systemctl status openclaw # 检查是否active (running)最关键的是ProtectSystemstrict这一行。它让OpenClaw进程只能读取/usr和/boot不能写入/etc或/home极大降低了被恶意Skill脚本利用的风险。这也是为什么网络热词里总有人问360怎么彻底卸载干净——安全意识必须贯穿始终。提示systemctl status openclaw看到的Active: active (running)只是进程状态。要确认它真正在工作用journalctl -u openclaw -f看实时日志搜索INFO[0000] OpenClaw is ready这才是真正的“就绪”。5. 卸载指南不是rm -rf而是状态归零5.1 彻底卸载的四个层次进程、文件、配置、状态网络热词里openclaw卸载、win工具箱卸载彻底方法、anaconda卸载反复出现说明用户对“卸载”有深刻焦虑——怕删不干净怕残留影响新版本。OpenClaw的卸载必须按层次进行停止进程sudo systemctl stop openclaw sudo systemctl disable openclaw。如果没用systemd就ps aux | grep openclaw找到PIDkill -15 PID。删除二进制sudo rm /usr/local/bin/openclaw*。注意是openclaw*因为可能有多个版本。清理配置与数据sudo rm -rf /etc/openclaw/。这里包含config.yaml和skills/目录。但等等还有一个隐藏目录清除运行时状态OpenClaw会在用户家目录下创建缓存路径是~/.openclaw/。这个目录里有cache/飞书Token缓存、logs/旧日志、tmp/临时文件。必须删除它否则重装后OpenClaw会尝试用旧的、已过期的Token去调飞书API导致{code:11232}错误持续出现。执行rm -rf ~/.openclaw/。注意~/.openclaw/是当前执行openclaw命令的用户的家目录。如果你用root启动过就删/root/.openclaw/如果你用openclaw用户启动过就删/var/lib/openclaw/.openclaw/因为openclaw用户的家目录是/var/lib/openclaw。不确定就find / -name .openclaw 2/dev/null全找出来挨个删。5.2 卸载后的飞书侧清理别忘了你的Bot还在飞书后台活着卸载OpenClaw不等于卸载了你在飞书创建的应用。那个App ID和App Secret依然有效Bot依然能收发消息。如果你只是临时停用可以不管但如果是永久弃用必须登录飞书管理后台进入“应用管理”找到你的应用点击“停用”或“删除”。停用是软删除应用还在列表里可以随时启用删除是硬删除App ID作废所有Token立即失效。我建议先停用观察一周确认没有任何服务还在调用它再删除。因为曾经有客户停用后发现另一个团队的Zabbix脚本还在用这个Bot的Webhook地址导致告警中断。实操心得我在每个飞书应用的描述里都会写上[OpenClaw v0.8.3] 生产环境 | 负责人: 张三 | 联系方式: zhangsancompany.com。这样其他同事看到就知道这是谁维护的出了问题该找谁。卸载前我会先把描述改成[已停用]再停用应用。这是一种运维礼仪。5.3 验证卸载是否干净三步检查法卸载完成后执行以下三步确保系统回归初始状态进程检查ps aux | grep openclaw应该没有任何输出。如果有kill -9干掉。文件检查which openclaw应该返回空。ls -l /usr/local/bin/openclaw*应该报No such file。飞书检查登录飞书管理后台确认应用状态是“已停用”或“已删除”同时去你测试用的飞书群里确认没有新的“OpenClaw”消息进来说明Webhook已失效。完成这三步你就可以放心地说“OpenClaw已彻底卸载”。这不是一句口号而是可验证、可审计的操作闭环。6. 常见问题与排查技巧实录那些没人告诉你但天天发生的坑6.1 问题速查表按错误现象反向定位现象可能原因排查命令/步骤解决方案openclaw: command not found二进制没加执行权限或不在PATH里ls -l ./openclawecho $PATHchmod x openclawsudo cp openclaw /usr/local/bin/启动后无OpenClaw is ready日志config.yaml语法错误openclaw --config config.yaml --dry-run用YAML校验网站如yamllint.com检查缩进和冒号HTTP输入源收到请求但飞书没消息outputs里group_id填错grep group_id /etc/openclaw/config.yaml去飞书群设置里复制正确的oc_xxx群ID日志里反复出现[ERROR] lark auth: invalid app_secretApp Secret复制时带了空格或换行echo XXX | hexdump -C看是否有0a(换行)重新从飞书后台复制粘贴到文本编辑器里用show all characters功能检查error: 发送飞书失败,返回信息:{code:11232,msg:frequency limited psm[larkBot发送频率超限journalctl -u openclaw -n 100 | grep rate limit在config.yaml的outputs下加rate_limit: 45或申请飞书QPS配额提升技能脚本里import pandas报错Python环境缺失pandaspython3 -c import pandas用pip3 install pandas装或改用二进制版它自带所有依赖6.2 独家避坑技巧来自血泪教训的三条军规军规一永远不要在config.yaml里写死密码或密钥网络热词里mysql安装配置教程、git安装及配置教程都强调安全OpenClaw同理。config.yaml是纯文本可能被Git追踪、被备份、被审计扫描。正确做法是用环境变量注入outputs: - type: lark name: feishu_bot app_id: ${FEISHU_APP_ID} # 改成环境变量引用 app_secret: ${FEISHU_APP_SECRET} group_id: ${FEISHU_GROUP_ID}然后启动时FEISHU_APP_IDcli_xxx FEISHU_APP_SECRETxxx FEISHU_GROUP_IDoc_xxx openclaw --config config.yaml。systemd服务里则在[Service]下加EnvironmentFile/etc/openclaw/secrets.env把密钥写在那个文件里并设chmod 600。军规二skills/目录下的脚本必须用绝对路径#!/usr/bin/env python3我遇到过最诡异的Bug在Ubuntu上写的Skill脚本在CentOS上运行时报/usr/bin/env: python3: No such file or directory。因为CentOS的python3在/usr/bin/python3而/usr/bin/env在PATH里找不到python3别名。解决方案是在所有Skill脚本第一行写#!/usr/bin/python3绝对路径而不是#!/usr/bin/env python3。虽然牺牲了一点可移植性但换来100%的确定性。军规三定期清理~/.openclaw/cache/防止Token缓存雪崩OpenClaw的Token缓存默认永不过期。但飞书的tenant_access_token有效期是2小时。如果OpenClaw进程跑了超过2小时缓存里的Token就失效了它会尝试用失效Token去调API飞书返回400OpenClaw就卡住不再处理新请求。我的解决方案是写一个crontab每天凌晨2点执行rm -f ~/.openclaw/cache/*。一行命令一劳永逸。最后分享一个小技巧如果你的OpenClaw要对接多个飞书Bot比如测试环境一个生产环境一个不要搞两套config.yaml。用YAML的锚点和引用功能common: common app_id: ${APP_ID} app_secret: ${APP_SECRET} outputs: - type: lark name: feishu_test : *common group_id: ${TEST_GROUP_ID} - type: lark name: feishu_prod : *common group_id: ${PROD_GROUP_ID}这样一套配置