1. 从“手动点点点”到“一键触发”为什么我们需要自动化工作流如果你每天的工作有超过30%的时间是在重复点击、复制粘贴、切换应用、填写表单那么你很可能已经掉进了“低效陷阱”。我过去就是这样尤其是在处理飞书上的各种协作任务时——每天要手动把十几个群里的重要消息摘录到多维表格定时给项目群发日报还要把代码仓库的合并请求状态同步到飞书文档。这些操作本身不复杂但架不住量大、频次高把人变成了一个没有感情的“人肉机器人”。直到我看到飞书开源了它的命令行工具CLI事情开始有了转机。这个工具叫feishu-cli它本质上是一个桥梁让你能用终端命令直接操作飞书里的资源比如消息、文档、表格、审批流。这意味着那些需要打开浏览器、登录飞书、找到对应页面才能完成的操作现在可以用一行脚本命令来替代。但光有桥还不够你需要一辆能自动过桥的“车”。这就是OpenClaw出现的时机。OpenClaw是一个开源的、基于事件驱动的自动化工作流引擎。你可以把它想象成一个超级智能的“胶水”它能把feishu-cli、你的本地脚本、其他API服务比如GitHub、Jenkins甚至AI模型比如Claude Code粘合在一起编排成一个完整的自动化流程。当我发现它时我的第一反应是就是它了。当天下午我就用它把我最头疼的几个手动流程给自动化了。这篇文章就是记录我如何利用飞书开源CLI和OpenClaw在几个小时内搭建起一套个人工作自动化系统的全过程。这不是一个高深莫测的架构设计而是一个务实、可复现的“抄作业”指南。2. 核心工具拆解feishu-cli 与 OpenClaw 能做什么不能做什么在动手之前我们必须清晰地了解手中工具的能力边界和设计哲学。盲目上手很容易陷入“为什么这个功能实现不了”的困惑。2.1 feishu-cli飞书资源的“程序化遥控器”飞书开源CLI (feishu-cli) 不是一个图形界面工具的替代品它的核心价值在于“可编程性”和“可集成性”。它能做什么身份认证与管理通过feishu-cli auth命令可以完成基于OAuth 2.0的应用授权获取访问令牌access_token。这是所有后续操作的基础。消息操作发送消息到个人、群聊或频道是它的基础功能。支持文本、富文本post、图片、文件等多种消息类型。例如feishu-cli message send --chat_id id --text “Hello”。多维表格Bitable交互这是自动化潜力最大的部分。你可以通过CLI查询表格数据、新增记录、更新记录、甚至通过视图过滤数据。这意味着你可以用脚本动态地向表格中写入数据或从表格中读取数据作为其他流程的输入。文档与云空间操作可以获取文档内容、列表管理云空间文件。审批与通讯录触发审批实例、查询审批详情获取部门用户列表等。它的限制与设计逻辑非实时监听feishu-cli本身是一个“发起方”工具它只能主动去调用飞书API而不能被动地接收飞书上的事件比如有人你、新增了一条评论。要实现事件监听你需要借助飞书的“事件订阅”功能这通常需要一个公网可访问的服务器来接收Webhook。feishu-cli不包含这个服务器。命令式而非声明式你需要明确写出“发送消息”、“添加记录”这样的具体命令。它不适合描述复杂的、“如果...就...”的逻辑流。状态管理简单它主要处理单次请求-响应。对于需要维护状态、进行多步骤条件判断的复杂流程光靠一堆CLI命令脚本会非常难以维护。这正是我们需要OpenClaw的原因。2.2 OpenClaw工作流的“大脑”与“调度中心”OpenClaw是一个本地优先的自动化工作流平台。它的核心概念是“触发器Trigger”和“动作Action”。触发器定义流程何时启动。例如“每隔1小时”、“当某个HTTP端点被调用时”、“当某个目录下新增了文件时”。动作定义流程要做什么。例如“执行一个Shell命令”、“调用一个HTTP API”、“运行一段Python脚本”。OpenClaw 如何补足 feishu-cli 的短板解决“监听”问题虽然OpenClaw本身也不是一个公网服务器但它可以很容易地与其他工具结合来实现“准实时”监听。例如你可以写一个简单的脚本定期比如每5分钟使用feishu-cli查询一次飞书消息如果发现新消息就触发OpenClaw工作流。OpenClaw自带定时触发器这让定期轮询变得非常简单。编排复杂逻辑在OpenClaw中你可以通过图形化界面或YAML文件以“拖拽”或“配置”的方式将多个动作串联起来中间可以加入条件判断、循环、数据转换等逻辑节点。比如“先调用feishu-cli获取表格A的数据 - 用Python脚本处理数据 - 如果处理结果满足条件X则调用feishu-cli向群Y发送消息否则将结果写入表格B”。集成异构系统OpenClaw的一个动作可以是“执行Shell命令”。这意味着你不仅可以用它来运行feishu-cli还可以运行任何其他命令行工具比如curl调用第三方API、git操作仓库、python运行数据分析脚本。它成了所有本地自动化任务的统一调度入口。状态与数据流OpenClaw可以在不同的动作之间传递数据。上一个动作的输出可以作为下一个动作的输入。这使得构建多步骤的、数据驱动的流程变得清晰。简单来说feishu-cli提供了操作飞书的“手”而OpenClaw提供了思考“何时动、怎么动”的“大脑”以及协调其他“手”其他CLI工具、脚本的能力。3. 环境准备与核心配置避开第一个坑理论清晰了我们开始动手。整个环境的搭建围绕两个核心安装工具和配置飞书应用权限。这里每一步都有细节需要注意。3.1 安装 feishu-cli 与 OpenClawfeishu-cli 安装飞书CLI通常通过包管理器安装。以macOS (brew) 和 Linux/Mac/WSL (npm) 为例# 方法一使用 Homebrew (macOS) brew install feishu-cli # 方法二使用 npm (跨平台) npm install -g larksuite/cli安装后运行feishu-cli --version验证。这里有个关键点不同安装渠道的CLI命令可能略有差异如主命令是feishu还是lark务必查阅安装后给出的官方文档确认基础命令。我使用的是npm安装的larksuite/cli所以后续命令都以lark开头。OpenClaw 安装OpenClaw推荐使用Docker安装这是最干净、避免环境冲突的方式。# 拉取最新镜像 docker pull openclaw/openclaw:latest # 创建数据持久化目录 mkdir -p ~/openclaw/data # 运行容器 docker run -d \ --name openclaw \ -p 3000:3000 \ # Web管理界面端口 -v ~/openclaw/data:/app/data \ # 挂载数据卷确保配置不丢失 -v /var/run/docker.sock:/var/run/docker.sock \ # 允许OpenClaw运行其他Docker容器高级功能 openclaw/openclaw:latest运行后在浏览器打开http://localhost:3000即可看到OpenClaw的Web配置界面。默认用户名密码通常是admin/admin首次登录后会要求修改。注意如果你在Windows上使用Docker Desktop确保已经开启了WSL2集成或Hyper-V后端。直接使用docker run命令可能需要在PowerShell或CMD中以管理员身份运行。更稳妥的方式是使用Docker Desktop提供的图形界面先测试镜像能否正常拉取。3.2 配置飞书应用获取关键的 App ID 和 App Secret这是整个流程中最容易出错的一步90%的“无效请求”错误都源于此。我们需要在飞书开发者后台创建一个“企业自建应用”。登录与创建访问 飞书开放平台 用你的飞书账号登录。在“开发者后台”点击“创建企业自建应用”。给应用起个名字比如“我的自动化助手”。获取凭证在应用的“凭证与基础信息”页面你会看到App ID和App Secret。立即把它们复制保存到安全的地方如本地的密码管理器。App Secret只显示一次丢失后需要重置。配置权限Scopes这是灵魂步骤。在“权限管理”页面为你需要自动化的功能添加对应的“权限”。例如发送消息需要添加im:message下的send_as_bot、send_to_group、send_to_user等权限。操作多维表格需要添加bitable:app下的app:readonly或app:record:write等权限。读取通讯录需要添加contact:user下的user:read等权限。重要添加权限后页面顶端会出现一个“申请线上发布”或类似按钮。你必须点击它并填写申请理由可以写“用于个人工作流程自动化”提交审核。只有审核通过后这些权限才能真正生效。个人测试环境下审核通常很快。配置事件订阅可选但重要如果你希望实现基于事件的自动化如有人机器人时触发需要配置“事件订阅”。但这需要你有公网IP或域名因为飞书需要将事件推送到一个你能控制的URLWebhook。对于纯本地、轮询驱动的自动化这一步可以跳过。这也是为什么我初期选择“定时轮询”方案的原因——它不需要公网环境。发布应用在“版本管理与发布”页面创建一个新版本并发布。发布后你需要在飞书客户端中找到这个应用并添加到你的工作台或群聊中应用才能被正确授权访问相关资源。3.3 初始化 feishu-cli 认证有了App ID和App Secret我们回到命令行让CLI获得访问令牌。lark auth执行这个命令后CLI会引导你完成OAuth流程。它会生成一个授权链接让你在浏览器中登录飞书并授权刚才创建的应用。授权成功后令牌信息会默认保存在~/.lark/config文件中。你可以通过lark config查看当前配置。踩坑点有时授权会失败提示invalid redirect_uri。这通常是因为在飞书开发者后台“安全设置”中配置的“重定向URL”与CLI内置的不匹配。一个更稳定的方式是使用“自建应用”的“凭证”模式而非默认的OAuth。你可以尝试lark auth --app-id YOUR_APP_ID --app-secret YOUR_APP_SECRET这种方式直接使用App Secret获取 tenant access token更适合服务器端、无交互的自动化场景。这也是后续我们在OpenClaw中推荐使用的方式。4. 实战构建三个立竿见影的自动化工作流环境就绪我们来打造几个能立刻提升效率的自动化流程。我将以复杂度递增的顺序介绍三个例子。4.1 工作流一每日站会提醒与纪要自动归档场景每天上午10点自动在项目群发送站会提醒并在站会后将指定群聊中关于“今日计划”的消息自动汇总到飞书多维表格。OpenClaw 工作流配置创建触发器在OpenClaw界面创建一个新的工作流。添加第一个节点选择“Schedule” (定时)触发器。设置为每天工作日周一至周五上午9:55触发。添加动作 - 发送提醒添加一个“Execute Shell Command” (执行Shell命令)动作。在命令框中填入lark message send --chat_id “你的项目群ChatID” --text “各位5分钟后10点准时开始每日站会请准备好更新。会议纪要链接[你的文档链接]”如何获取 Chat ID在飞书网页版打开群聊浏览器地址栏中chat/后面的那一串数字就是Chat ID。测试保存工作流后可以手动点击“测试”按钮看消息是否能成功发送到群聊。添加第二个触发器或条件判断我们希望在站会结束后比如上午10:30自动收集信息。这里有两种设计方案A简单再添加一个定时触发器设定为每天10:30。然后接续收集信息的动作。方案B更智能使用一个“延迟”节点。在发送提醒的动作后添加一个“Delay” (延迟)节点设置为35分钟从9:55到10:30。这样整个流程就是线性的9:55触发 - 发送提醒 - 等待35分钟 - 执行收集。添加动作 - 收集消息并归档步骤1获取群消息添加一个Shell动作使用larkCLI获取最近一小时或特定时间段的群消息。lark-cli的消息列表命令可能需要消息ID作为起点一个更实用的方法是结合飞书开放平台的API通过curl调用。这里假设我们用一个Python脚本collect_standup.py来实现更复杂的逻辑。python3 /path/to/your/scripts/collect_standup.py步骤2Python脚本逻辑collect_standup.py脚本内需要 a. 使用larkCLI 或直接使用requests库调用飞书API需带上tenant_access_token获取群聊历史消息。 b. 解析消息筛选出包含“今日计划”、“TODO”等关键词或特定格式的消息。 c. 将筛选后的内容发言人、计划内容、时间整理成结构化数据。步骤3写入多维表格在Python脚本中继续调用飞书API向预先创建好的多维表格中新增一条记录。表格的字段可以设计为日期、姓名、今日计划、备注。为什么用Python脚本而不是一连串Shell命令因为消息处理和逻辑判断在Shell中非常笨拙而Python有丰富的字符串处理库和JSON解析能力更适合这种任务。OpenClaw的Shell动作完美地充当了调用这个Python脚本的入口。实操心得权限隔离用于发送消息和读取消息的机器人最好拥有不同的权限范围。发送提醒的机器人只需要“发消息”权限而收集消息的机器人需要“读取群消息”权限。在实际操作中我创建了两个不同的飞书自建应用来实现这样更安全。错误处理在OpenClaw的动作设置中可以配置“失败重试”策略。对于发送消息这类动作可以设置重试2-3次。对于Python脚本务必在脚本内部做好异常捕获和日志记录将错误信息写入文件或通过OpenClaw的“发送通知”动作告警。4.2 工作流二代码仓库动态同步至飞书文档场景监控GitHub仓库的main分支每当有新的Pull Request被合并时自动将PR的标题、描述、提交者信息更新到一个飞书文档中作为项目更新日志。OpenClaw 工作流配置这个工作流需要整合外部服务GitHub和飞书。触发器使用“Webhook”触发器。在OpenClaw中创建一个Webhook节点它会生成一个唯一的URL如http://your-openclaw-server:3000/webhook/abc123。配置GitHub Webhook在你的GitHub仓库设置中找到Webhooks选项。Payload URL填入上一步OpenClaw生成的URL。Content type选择application/json。Which events...选择Let me select individual events然后勾选Pull requests或者更精确地选择Pull request reviews和Pushes。保存后GitHub会在指定事件发生时向你的OpenClaw发送一个POST请求请求体里包含了PR的详细信息。添加动作 - 解析与处理OpenClaw的Webhook触发后会将GitHub的请求体作为数据传递给下一个节点。添加一个“Code” (代码)节点OpenClaw可能叫Function或Script节点。这里我们用JavaScript或Python写一段简单的逻辑// 假设OpenClaw的代码节点支持JS const payload JSON.parse(workflow.input.body); // 获取GitHub的Webhook数据 if (payload.action ‘closed’ payload.pull_request.merged true) { // 这是一个已合并的PR const prTitle payload.pull_request.title; const prBody payload.pull_request.body; const author payload.pull_request.user.login; const mergeTime new Date().toISOString().split(‘T’)[0]; // 将需要的信息赋值给输出变量供下一个节点使用 workflow.output { title: prTitle, body: prBody, author: author, date: mergeTime, url: payload.pull_request.html_url }; } else { // 如果不是合并事件可以提前结束工作流 workflow.exit(‘Not a merged PR event’); }添加动作 - 更新飞书文档添加一个Shell动作。这个动作调用一个本地脚本update_doc.py并将上一步输出的变量作为环境变量或参数传递进去。export PR_TITLE“{{workflow.output.title}}” export PR_AUTHOR“{{workflow.output.author}}” python3 /path/to/update_doc.py “$PR_TITLE” “$PR_AUTHOR” “{{workflow.output.url}}”在update_doc.py脚本中使用飞书API的“更新文档内容”接口。你需要知道目标文档的doc_token。接口支持以特定格式如{“elements”: [...]}在文档末尾追加内容。你可以设计一个固定的Markdown模板将PR信息填充进去然后追加。踩坑记录网络可达性OpenClaw的Webhook URL必须能被GitHub访问到。如果你的OpenClaw运行在家庭网络无公网IP这个方案行不通。替代方案是使用“定时轮询”GitHub API检查最新的合并PR。虽然实时性差一些但更可靠。安全验证GitHub Webhook可以设置一个Secret用于验证请求来源。你需要在OpenClaw的Webhook触发器配置中或你的处理代码中验证这个签名以防止伪造请求。文档Token获取飞书文档的doc_token不像Chat ID那么容易获取。最可靠的方式是通过飞书开放平台的“获取文档信息”API传入文档的URL来查询。这个Token需要提前获取并保存在配置文件中。4.3 工作流三跨平台信息聚合与智能摘要场景这是一个更进阶的场景。监控多个来源如某个RSS订阅、一个内部系统API、甚至邮箱将获取到的信息去重、汇总然后利用AI模型如Claude API生成一份摘要最后将摘要发送到飞书群或更新到知识库文档。OpenClaw 工作流配置这个工作流体现了OpenClaw作为“调度中心”的真正威力。触发器使用“Schedule”触发器每2小时运行一次。动作1 - 数据采集并行或串行执行多个Shell/HTTP请求动作。动作1A执行curl命令获取RSS源用xml2json或python解析。动作1B执行一个Python脚本调用内部系统的REST API获取数据。动作1C使用imap相关的命令行工具或Python库检查特定邮箱文件夹。每个动作的输出原始文本或JSON都设置为OpenClaw的工作流变量。动作2 - 数据清洗与聚合添加一个“Code”节点。在这里用Python或JS编写逻辑将所有来源的数据解析成统一的格式例如包含title,content,source,time的对象列表。基于标题、内容或URL进行简单的去重。将过去2小时内所有的新项目合并成一个大的文本块。动作3 - 调用AI生成摘要添加一个“HTTP Request”动作如果OpenClaw支持或“Shell”动作。如果是Shell动作调用一个Python脚本call_ai_summary.py。在这个脚本中使用requests库调用Claude、ChatGPT或国内大模型的API。提示词Prompt可以设计为“请将以下多条信息汇总成一份简洁的摘要报告分点列出核心内容{合并后的文本块}”。将API返回的摘要文本保存为工作流变量。动作4 - 结果推送分支判断根据摘要内容长度或关键词决定推送到哪里。分支A重要通知如果摘要中包含“紧急”、“错误”等关键词使用lark-cli发送一条所有人的消息到运维群。分支B知识归档使用lark-cli或API将摘要内容追加到团队的知识库飞书文档中。经验技巧成本与速率控制频繁调用AI API会产生费用。可以在“数据清洗”节点后加一个判断如果收集到的新信息条目少于3条则跳过AI摘要步骤直接简单罗列并推送。或者将调度时间从2小时改为6小时。密钥管理AI API的密钥、飞书的App Secret都是敏感信息。绝对不要硬编码在脚本或OpenClaw的明文配置里。OpenClaw通常支持“环境变量”或“密钥库”功能。将密钥保存在OpenClaw的密钥管理中在脚本中通过环境变量如OPENAI_API_KEY来引用。流程可视化与调试OpenClaw的Web界面会显示每个工作流每次运行的详细日志哪个节点成功哪个节点失败输入输出是什么。这对于调试这种多步骤的复杂流程至关重要。务必善用这个功能在开发阶段打开详细的日志输出。5. 进阶技巧与避坑指南在真实使用中你会遇到一些预料之外的问题。这里分享一些进阶配置和常见坑的解决方案。5.1 飞书API的速率限制与令牌管理飞书API有严格的调用频率限制。如果你在短时间内触发大量工作流可能会遇到429 Too Many Requests错误。策略一错峰与缓存在OpenClaw的工作流中在调用飞书API的动作前可以增加一个随机延迟如1-5秒避免所有请求同时发出。对于获取后短期内不会变化的数据如部门列表可以在本地进行缓存定期如每小时更新一次而不是每次工作流都去查询。策略二令牌刷新通过App Secret获取的tenant_access_token有效期为2小时。你需要一个机制在令牌过期前刷新它。feishu-cli的auth命令在“凭证”模式下可能不会自动处理。一个健壮的做法是写一个独立的定时任务比如cron job每90分钟运行一次lark auth --app-id ... --app-secret ...来刷新令牌。或者在你的Python脚本中在每次调用API前先检查令牌是否有效无效则重新获取。5.2 OpenClaw工作流的稳定性保障失败重试与告警为每一个调用外部API飞书、GitHub、AI的动作节点在OpenClaw中配置失败重试策略例如最多重试3次每次间隔30秒。同时为整个工作流设置一个“错误处理”分支当任何节点最终失败时触发一个告警动作比如发送一条飞书消息给你自己。资源隔离与版本控制如果你有多个自动化流程建议为它们创建不同的飞书应用实现权限隔离。对于OpenClaw的工作流配置定期使用其导出功能进行备份。复杂的流程可以先用一个简单的“Hello World”流程测试通再逐步增加节点。处理“请求不合规”错误在配置飞书应用时特别是涉及H5页面或移动端如果遇到“invalid redirect uri in h5 case 请求不合规”这类错误请仔细检查开发者后台“安全设置”中的“重定向URL”列表。确保你添加的URL与你的应用实际使用的回调地址完全一致包括协议http/https、域名、端口和路径。对于本地测试http://localhost:端口号/回调路径是常用的格式。5.3 将OpenClaw部署到更稳定的环境在个人电脑上运行Docker容器电脑一关机自动化就停了。对于需要7x24小时运行的核心流程可以考虑将其部署到云服务器或家里的树莓派/NAS上。云服务器部署过程与本地类似。确保服务器安全组开放了OpenClaw的Web端口如3000以及你可能用到的其他端口。使用docker-compose来管理容器和配置更为方便。使用进程守护在Linux服务器上不要仅仅使用docker run -d。使用systemd为Docker容器创建服务单元文件或者使用docker-compose配合restart: always策略确保容器在异常退出或服务器重启后能自动恢复。数据备份定期备份你挂载的~/openclaw/data目录。这个目录里包含了所有的工作流配置、执行日志和密钥如果存储在OpenClaw内。6. 思路扩展超越基础自动化当你熟悉了feishu-cliOpenClaw这套组合拳后可以尝试更多有趣的集成对接本地AI模型除了调用云端AI API你可以在本地部署开源大模型如通过Ollama。让OpenClaw的工作流将需要总结的文本发送给本地模型的API生成摘要后再发回飞书实现完全离线的智能摘要。与硬件联动OpenClaw可以通过Shell动作执行任意命令。你可以写一个脚本当收到飞书特定的指令时如“打开客厅灯”通过调用Home Assistant的API或发送MQTT消息来控制智能家居设备。构建自动化仪表盘结合飞书多维表格的API你可以让OpenClaw定期从数据库、监控系统如Prometheus拉取数据计算关键指标如日活、系统错误率并更新到多维表格中。然后利用多维表格的“仪表盘”功能自动生成可视化的数据看板。自动化测试集成正如热词中提到的“自动化测试”你可以配置一个OpenClaw工作流监听代码仓库的推送事件触发自动化测试套件如基于Selenium或Appium的测试并将测试报告以富文本消息的形式发送到飞书质量群。自动化不是要创造一个无人值守的完美系统而是将你从重复、琐碎、低价值的操作中解放出来让你能更专注于需要人类判断力和创造力的部分。飞书开源CLI降低了程序化操作飞书的门槛而OpenClaw这样的工具则让编排复杂任务变得像搭积木一样简单。我当天的体验从手动点击到脚本自动运行那种效率提升的愉悦感是实实在在的。希望这篇详尽的指南能帮你顺利跨出第一步打造属于你自己的自动化工作流。