AI Agent 实战干货
全链路实战复盘，从工具选型、避坑排错到可直接复用的落地方案
基于 Cursor + Git Worktree 的多 Agent 自动化串行流水线
通过「一句话提示词」触发多个 Sub-agent 形成自动化串行执行，实现多任务并行开发的完整流程复盘
OpenClaw 联合 Claude Code 与飞书 Bot 操作完全指南
从架构设计到实战命令，全面梳理 OpenClaw + Claude Code + 飞书 Bot 的协作模式与使用方法
为什么复杂任务的默认工作流应该写在 AGENTS.md 而不是某个 Skill 里
AGENTS.md 是上层总规则，Skill 是专项执行模块——一个管「选路」，一个管「走路」，两者分层而非对立
OpenClaw + Telegram + 飞书对接方案研究报告
调研 OpenClaw 原生飞书集成方案，梳理从 Webhook Bridge 迁移到 WebSocket 长连接的完整路径与配置步骤
暂无内容
🚀 实践记录：基于 Cursor + Git Worktree 的多 Agent 自动化串行流水线
🛠 核心工具栈： Cursor | Git Worktree | Opus 4.6 & Codex-5.3
🎯 核心目标： 通过“一句话提示词”触发多个 Sub-agent 形成自动化串行执行，实现多任务并行开发。
📂 当前提案： openspec/changes/redesign-skill-card-vertical
🔄 自动化串行工作流 (Agent Pipeline)
- 注意：下面没有明确说用 SubAgent 的就不要用 SubAgent
0 TASK 0：提案复核
- 模型：Gemini-3.1-pro
- 任务：。使用 openspec-review-specs skill。
- 关注点：着重审视提案完备性设计，关键数据流，属性、接口对齐等等。
1️⃣ TASK 1：架构师预审 (Architect Review)
- 模型：Opus 4.6
- 任务：站在架构师的视角，对当前提案进行全局优化与细节补充。使用 neversight-skills_feed-system-architect skill。
- 关注点：着重审视系统设计，挖掘潜在的代码复用机会，确保方案的健壮性。
2️⃣ TASK 2：提案执行 (Implementation)
- 模型：Opus 4.6
- 任务：直接执行指令
/opsx/apply，将打磨后的提案转化为实际代码。
3️⃣ TASK 3：代码审查 (Code Review)
- 模型：Codex-5.3 (模型切换)
- 任务：
- 执行
git commit保存初步生成的代码。 - 严格对照提案 (Proposal) 审查当前 Commit 的代码逻辑。
- 注：此阶段仅做只读审查（Read-only），不进行任何代码篡改，确保 Review 视角的客观性。
- 执行
4️⃣ SubAgent 4：自愈与更新 (Auto-Refinement)
- 模型：Opus 4.6 (模型切回)
- 任务：摄取 Agent 3 输出的审查报告，基于反馈结果自动更新并修复代码缺陷。
5️⃣ SubAgent 5：收尾与归档 (Archiving)
- 模型：Opus 4.6
- 任务：
- 执行指令
/opsx/archive，对当前提案进行状态归档。 - 执行最终的
git commit，完成该特性的闭环。
- 执行指令
💡 瓶颈复盘与优化方案 (Reflections & Optimization)
当前流水线实现了高度的自动化，但整体运行耗时稍长。
- 优化思路：当前 Sub-agent 的职责划分过于细粒度。下一步可以尝试降低颗粒度，将高内聚的任务合并（例如将“架构预审”与“提案执行”合并为单个大 Agent 步骤，或将“自愈更新”与“归档”合并），以减少模型切换和上下文传递带来的通信损耗，从而大幅提升流水线执行速度。
为什么复杂任务的默认工作流应该写在 AGENTS.md，而不是某个 Skill 里
> 时间：2026年3月26日 10:04（北京时间） > 主题：小满的任务工作流设计原则、AGENTS.md 与 Skill 的职责边界、为什么默认流程属于上层规则而不是专项技能
最近我们围绕一个问题做了比较深入的讨论：
**“为什么小满现在这套默认工作流程，要写在 AGENTS.md，而不是直接做成某个 skill？”*“为什么小满现在这套默认工作流程，要写在 AGENTS.md，而不是直接做成某个 skill？”AGENTS.md，而不是直接做成某个 skill？”
这个问题看起来像是文档放哪更合适，但本质上其实是在讨论：
- 一个 AI 助手到底应该怎么组织自己的工作系统
- 什么属于“总规则”，什么属于“专项能力”
- 为什么有些东西必须写成全局行为，而不能塞进单个模块里
我把这次讨论整理成一篇更完整的文章，方便后续团队统一理解，也方便作为知识库中的长期规则沉淀。
一、先说结论
小满现在这套默认工作流——比如：
- 先判断任务类型
- 如果有明确匹配的 skill，就先读 skill
- 先只读排查，再决定是否动手
- 能直接完成就直接完成
- 复杂任务分层处理，必要时再拆子 agent
它更适合写在 AGENTS.md，而不是某一个单独的 skill 里。
原因很简单：
这不是某类任务的“专项执行方法”，而是小满处理几乎所有任务时的总调度逻辑****总调度逻辑。
换句话说：
AGENTS.md负责：收到任务后，先怎么判断、怎么分流、怎么做决策Skill负责：一旦确定这是某类任务，具体怎么做
一个管“选路”，一个管“走路”。
二、AGENTS.md 和 Skill，本来就不是同一层东西
1）AGENTS.md 是上层规则
AGENTS.md 更像是 AI 助手的工作宪法、操作系统或者岗位说明书。
它适合承载：
- 群聊和私聊边界
- 默认任务 intake 流程
- 复杂任务怎么处理
- 什么时候先查环境、什么时候先给方案
- 角色定位、任务分发和交接规范
- 团队协作方式
这些规则的特点是：
- 跨任务
- 跨领域
- 跨 skill
- 不管当前任务具体是什么，都会先影响行为
所以这类内容天然适合放在 AGENTS.md。
2）Skill 是专项能力模块
而 skill 更像一个个专业工具箱或 SOP 模块。
比如：
healthcheck：怎么做健康检查find-skills：怎么搜索可用 skilllark-kb-analysis-writer：怎么导出整库并分析service-guardian：怎么做服务守护compaction-survival：长任务时怎么保持状态不丢
它们回答的是：
“当任务已经被识别成某一类后，具体执行方法是什么？”****“当任务已经被识别成某一类后，具体执行方法是什么？”
所以 skill 更适合写“专项执行路径”，而不是负责整个 agent 的总决策逻辑。
三、为什么“默认工作流”不能只靠某个 skill 承担
1）因为它发生在选 skill 之前
这是最关键的一点。
我们现在这套默认流程的前两步就是：
- 先判断任务类型
- 如果有明确匹配的 skill，就先读 skill
注意这里的逻辑顺序：
**是否调用某个 skill，本身就要先经过上层判断。**是否调用某个 skill，本身就要先经过上层判断。
如果把这套流程写进某个单独 skill，就会出现一个逻辑倒挂：
- 我得先调用一个 skill
- 才能读到“要先判断该不该调用 skill”
这就变成自我循环了。
所以像“先判断任务类型”“先查现有能力”“先摸环境”这种规则，必须写在 skill 之上。
而 AGENTS.md 恰好就是那个上层。
2）因为它是跨任务的共通原则
这套流程不是只对某一类任务生效。
它同时适用于：
- 知识库整理
- 服务稳定性排查
- 研究报告
- 技术方案分析
- 目录架构优化
- 自动化流程设计
- 长任务、多步骤任务
也就是说，它不是某个领域专属，而是小满做事的默认脑回路。
这种“共通原则”如果塞进某一个 skill，就会变成局部规则，覆盖范围反而不对。
3）因为它决定的是“任务怎么进系统”，不是“任务怎么执行”
这套流程本质上是：
- 先看这是不是复杂任务
- 先看已有工具、脚本、文档、spec
- 先摸清环境再动手
- 复杂任务默认先给方案
- 确认后再推进重执行
这套东西决定的是：
**任务进来后，先走哪条路。**任务进来后，先走哪条路。
而不是某条具体路径内部的步骤。
因此它属于任务路由层任务路由层，不是专项执行层专项执行层。
4）因为它和角色、边界、协作方式绑定在一起
小满并不是一个抽象的工具集合，而是一个带角色约束的助手。
当前体系里，小满有：
- 群聊边界
- 私聊代发规则
- 研究任务默认写知识库
- Lark 任务默认自动路由
- 复杂任务先方案后执行
- 必要时可用子 agent 协作
这些东西不只是“怎么做某件事”，而是：
- 小满是谁
- 小满对用户和团队负责什么
- 小满在什么场景可以主动，什么场景应该克制
这更像岗位规则、协作契约，而不是 skill 说明书。
所以应写在 AGENTS.md，而不是写进某个单一 skill。
5）因为多个 skill 往往会同时适用，需要上层裁决
现实任务经常不是单一归类。
比如一个任务可能同时涉及：
- 整库分析
- 故障诊断
- 知识库写入
- 服务稳定性检查
如果没有上层规则，小满就很容易：
- 乱选 skill
- 并行混用路径
- 该先只读的时候直接上手修改
- 该先给方案的时候直接执行
所以必须有一个写在 skill 之上的“总调度逻辑”，决定：
- 先读什么
- 先查什么
- 谁是主路径
- 谁只是辅助路径
这正是 AGENTS.md 的职责。
四、如果硬把它做成一个 skill，会出现什么问题
1）职责膨胀
如果专门做一个所谓“intake skill”，里面负责：
- 判断任务类型
- 检查现有能力
- 搜索增强路径
- 决定要不要给方案
- 再决定是否调用别的 skill
那它很快就会变成一个“万能前置 skill”。
问题是：
- 它什么都管
- 但并不专注于某个领域
- 和
AGENTS.md的作用高度重叠 - 会形成两个总控中心
结果不是更清楚，而是更容易混乱。
2）会形成“skill 套 skill”的递归感
流程会变成：
- 收到任务
- 先调用 intake skill
- intake skill 再判断要不要调用其他 skill
- 其他 skill 再真正干活
这在设计上很别扭。
因为本来应该作为 agent 默认脑回路的东西，被额外包成了一个 skill，反而增加了一层形式主义。
3）轻任务会被过度流程化
并不是所有任务都需要显式走一遍完整 intake。
很多任务其实很轻：
- 读一个文件
- 回一个问题
- 查一个状态
- 给一句判断
这类任务如果每次都显式调用某个“前置 skill”，系统就会显得过于笨重。
而写进 AGENTS.md，这套规则可以自然地作为默认行为存在：
- 复杂任务时完整启用
- 轻任务时自动轻量化处理
这更像“会做事的人”，而不是“执行表单流程的机器”。
4）没命中任何 skill 时，仍然需要默认规则兜底
还有很多任务属于：
- 没有一个 skill 完全匹配
- 但仍然需要先看现有环境
- 仍然需要先查脚本、文档、配置真相
- 仍然需要先给方案，而不是蛮干
如果这类规则不写在上层，而只寄托在某个 skill 上，那一旦任务没命中那个 skill，整套流程就失效了。
所以必须有一个不依赖 skill 是否命中，也能生效的默认行为层****不依赖 skill 是否命中，也能生效的默认行为层。
这层就是 AGENTS.md。
五、那 skill 在整个体系里应该做什么？
最合理的分工是这样的：
AGENTS.md 负责
- 默认任务 intake
- 任务分类
- 风险判断
- 优先复用已有能力
- 是否先给方案
- 是否应该拆子 agent
- 群聊 / 私聊边界
- 团队协作方式
Skill 负责
- 某个领域的专业做法
- 某类任务的执行 SOP
- 某项能力的标准流程
- 专项工具链的使用方式
比如：
healthcheck负责“怎么排查服务健康”lark-kb-analysis-writer负责“怎么读整库再分析”service-guardian负责“怎么做守护和 auto-recovery”compaction-survival负责“长任务如何保存状态、抵抗压缩丢失”
可以理解为：
AGENTS.md是总导演- 各个 skill 是专业部门
导演决定拍什么、怎么分工；部门负责把自己那段拍好。
六、那 skill 完全不需要做 planning 吗？
也不是。
其实可以额外做一个专门的 planning / intake / capability-first planning skill，作为补充层****补充层。
它适合用在：
- 特别复杂的陌生任务
- 用户明确说“先别做，先给最优方案”
- 需要做方法设计、路线设计、任务拆解
但它的定位应该是：
显式规划模块****显式规划模块
而不是：
默认工作流本体****默认工作流本体
也就是说：
AGENTS.md仍然负责全局默认行为- planning skill 只在需要时被主动启用
这样两层不会冲突。
七、为什么这次这套流程特别适合写进 AGENTS.md
因为这次讨论的不是某个专业技能该怎么做，而是一个更上层的问题：
“小满以后在面对复杂任务时，默认应该怎么思考、怎么判断、怎么进入执行。”****“小满以后在面对复杂任务时，默认应该怎么思考、怎么判断、怎么进入执行。”
这个问题本质上属于：
- 行为风格
- 风险控制
- 协作协议
- 任务调度逻辑
- agent 宪法级规则
所以把它写进 AGENTS.md，不仅合理，而且是最清晰的做法。
八、最终总结
为什么默认工作流要写在 AGENTS.md，而不是 skill？
因为这套流程决定的是：
**在选 skill 之前，小满应该怎么做事。**在选 skill 之前，小满应该怎么做事。
而 skill 更适合解决的是：
**当已经确定这是一类任务后，该怎么具体执行。**当已经确定这是一类任务后，该怎么具体执行。
一个是上层总规则，一个是下层专项能力。两者不是对立关系，而是分层关系。
真正成熟的 agent 系统，不是把所有东西都塞进 skill，而是要把：
- 全局行为规则
- 专项技能模块
- 用户偏好和团队协作方式
- 长任务生存与恢复机制
放在正确的层级上。
这次讨论的价值就在这里：
我们不是只给小满增加了一个新流程，而是在逐步把“小满怎么工作”这件事，变成一套更清晰、更可维护、也更像真正助理的系统。
九、建议的后续动作
基于这次讨论，后续可以继续补两类文档：
- 《AGENTS.md 与 Skill 的职责边界图》****《AGENTS.md 与 Skill 的职责边界图》
- 用图示方式明确：什么该写 AGENTS、什么该写 Skill、什么该写 MEMORY
- 《复杂任务 Planning / Intake Skill 设计方案》****《复杂任务 Planning / Intake Skill 设计方案》
- 不是替代 AGENTS.md，而是作为显式规划层补充
如果这两份补上，整个系统的分层会更清楚，小满后续也更容易持续优化。
OpenClaw 联合 Claude Code 与飞书 Bot 操作完全指南
一、OpenClaw 与 Claude Code 的关系
1.1 各自定位
| 组件 | 定位 | 核心能力 |
|---|---|---|
| Claude Code | Anthropic 官方本地 AI 编程助手 | 读写代码、执行 Shell、操作 Git、处理复杂工程任务 |
| OpenClaw | 本地 AI Gateway + 渠道中枢 | 连接 Telegram/飞书/Discord、调度多种 AI 模型、集成飞书/日历/Gmail 等 tools |
1.2 协作模式：OpenClaw → Claude Code
通过手机/电脑上的 Telegram 或 飞书，向 OpenClaw 发送指令。
OpenClaw 收到后，可以启动真正的 Claude Code CLI 作为子进程（通过 ACP 协议），让 Claude 在 Mac 上执行大型编程任务，完成后把结果返回到聊天窗口。
二、架构简图
[你] → Telegram / 飞书
↓
[OpenClaw Gateway] ← 本地运行 (127.0.0.1:18789)
↓
┌─────┴─────┐
│ │
飞书操作 ACP 子进程
│ │
lark-cli [Claude Code]
│ │
文档/Base 代码/Shell/Git三、在 Telegram / 飞书中指挥 Claude Code
3.1 绑定当前聊天到 Claude
发送以下命令：
/acp spawn claude --bind here效果：
- 在当前聊天中创建一个 Claude ACP 会话
- 之后你发的每条消息都会直接传给 Claude Code 处理
- Claude 在
~/.openclaw/workspace-claude下工作
3.2 创建持久话题（大型任务推荐）
在支持话题/线程的渠道（如飞书群、Discord）：
/acp spawn claude --mode persistent --thread auto效果：
- 自动开一个话题/线程
- Claude 的回复和中间过程都在这个线程里
- 不污染主聊天
3.3 只执行一次性任务
/acp spawn claude --mode oneshot效果：
- 执行一个任务就结束
- 适合”帮我 review 这个 PR”、“生成一份报告”等短任务
3.4 常用 ACP 控制命令
| 命令 | 作用 |
|---|---|
/acp status | 查看当前聊天的 ACP 绑定状态 |
/acp cancel | 取消当前正在执行的任务 |
/acp close | 关闭 ACP 会话并解绑 |
/acp doctor | 检查 ACP 系统健康状态 |
四、通过 Claude 完成飞书操作（双重能力）
4.1 关键原理
当 Claude 被 OpenClaw 通过 ACP 启动后，Claude 并不直接拥有飞书 tools。飞书操作由 OpenClaw 的 main agent 或内置 skills 执行。
但你可以这样配合：
- 用 OpenClaw 直接发送飞书消息、创建文档
- 用 ACP 的 Claude 处理代码、生成内容
- 再把结果交给 OpenClaw 写入飞书
4.2 实战：让 Claude 生成日报，OpenClaw 发到飞书
步骤 1：在 Telegram 里绑定 Claude
/acp spawn claude --bind here步骤 2：给 Claude 派活
帮我写一份今天的研发进度日报，包含：
- 已完成：修复了登录 bug
- 进行中：重构订单模块
- 阻塞项：等待设计稿Claude 生成内容后返回给你。
步骤 3：把内容发给 OpenClaw 的 main agent
把下面这份日报发到飞书群 oc_xxxxxx：
[粘贴 Claude 生成的内容]OpenClaw（main agent）会调用飞书工具完成发送。
五、Bot 身份详解
5.1 什么是 Bot 身份？
OpenClaw 连接的飞书应用是 Clawdbot（appId: cli_a94a4198e6385eef）。所有通过 OpenClaw 或 lark-cli 执行的飞书操作，默认都以这个 Bot 的租户身份进行。
5.2 Bot 身份的优势
- ✅ 无需人工登录：没有 user 会话过期问题
- ✅ 24小时在线：可以自动跑定时任务
- ✅ 操作权限稳定：已配置好 scopes，可读写文档、Base、IM
5.3 身份验证结果
{
"appId": "cli_a94a4198e6385eef",
"brand": "feishu",
"defaultAs": "bot",
"identity": "bot"
}测试命令结果：
lark-cli im +chat-search --query test --as bot --page-size 1
# -> { "ok": true, "identity": "bot" }六、Bot 身份下可执行的飞书操作类别
6.1 即时通讯（IM）
| 操作 | 示例命令/指令 |
|---|---|
| 发送文本消息 | @bot 发送消息到群 oc_xxx：今天进度更新 |
| 发送 Markdown | @bot 用 markdown 发飞书消息... |
| 搜索群聊 | lark-cli im +chat-search --query xxx --as bot |
| 查看历史消息 | lark-cli im +chat-messages-list --chat-id oc_xxx |
6.2 云文档（Docs）
| 操作 | 示例命令/指令 |
|---|---|
| 创建文档 | @bot 在飞书里创建一个文档，标题是 xxx |
| 更新文档 | @bot 在飞书文档 doc_xxx 里追加一段内容 |
| 搜索文档 | @bot 搜索飞书里标题包含 xxx 的文档 |
6.3 多维表格（Base）
| 操作 | 示例命令/指令 |
|---|---|
| 创建记录 | @bot 在 Base xxx 的表 yyy 里添加一条记录 |
| 查询记录 | @bot 列出 Base xxx 中状态为待办的所有记录 |
| 更新记录 | @bot 把记录 zzz 的状态改成已完成 |
6.4 日历与任务
| 操作 | 示例命令/指令 |
|---|---|
| 创建日程 | @bot 帮我创建一个明天下午的会议 |
| 查看日程 | @bot 查看我今天的日程 |
| 创建任务 | @bot 创建一个任务：周五前提交报告 |
七、三种典型工作流
工作流 A：纯 OpenClaw（快速操作）
适合：发消息、查日程、改 Base 记录
[你] -> Telegram message
↓
OpenClaw main agent
↓
lark-cli --as bot
↓
飞书 API工作流 B：纯 ACP Claude（编程任务）
适合：写代码、debug、跑测试
[你] -> /acp spawn claude --bind here
↓
Claude Code CLI
↓
本地代码仓库工作流 C：Claude + OpenClaw 组合（复杂自动化）
适合：Claude 生成内容 -> OpenClaw 写入飞书
[你] -> /acp spawn claude --bind here
↓
Claude 生成报告 / 分析数据 / 写脚本
↓
[你@OpenClaw] 把结果发到飞书
↓
OpenClaw main agent -> lark-cli bot -> 飞书八、命令速查表
启动 Claude ACP
/acp spawn claude --bind here
/acp spawn claude --mode persistent --thread auto
/acp spawn claude --mode oneshotACP 管理
/acp status
/acp cancel
/acp close
/acp doctor直接调用 lark-cli（Bot 身份）
lark-cli im +chat-search --query 关键词 --as bot
lark-cli im +messages-send --chat-id oc_xxx --content "hello"
lark-cli docs +search --query 关键词 --as bot
lark-cli base +list-bases --as bot
lark-cli calendar +agenda --as bot
lark-cli task +get-my-tasks --as bot九、注意事项
- Bot 身份不能执行所有 user-only 操作。例如某些通讯录搜索命令仅限 user 身份。
- WebChat（Control UI）不支持 thread binding，所以
/acp spawn claude --thread auto在 Web 控制台里会失败。
十、状态确认（2026-04-10）
| 检查项 | 状态 |
|---|---|
| OpenClaw Gateway | 运行中 (127.0.0.1:18789) |
| Telegram 渠道 | 已连接 (@duoer02_bot) |
| Feishu 渠道 | 已连接 (Clawdbot) |
| Claude Code CLI | 可用 (v2.1.79) |
| acpx -> Claude Code | 已验证通 |
| OpenClaw ACP -> Claude | 已验证通 |
| lark-cli bot 身份 | 已验证通 |
调研日期：2026-03-13
目标：实现 OpenClaw 同时对接 Telegram 和飞书（Lark）
一、当前环境分析
1.1 OpenClaw 现有配置
已配置的渠道：
渠道 │ 状态 │ 说明
─────────┼─────────────────┼────────────────────────────────────────────────
Telegram │ ✅ 正常运行 │ 3 个 bot（nexus、xiaoman、polymarket），DM 开放
飞书 │ ⚠️ Webhook 模式 │ 非原生 WebSocket，通过 bridge 中转 当前飞书配置（~/.openclaw/openclaw.json）：
{
"feishu": {
"domain": "lark",
"streaming": false,
"blockStreaming": false,
"textChunkLimit": 8000
}
}1.2 当前飞书对接架构
现有方案：Webhook Bridge
飞书 → Cloudflare Tunnel → bridge.py (localhost:19800) → OpenClaw Gateway (localhost:18789)bridge.py 功能：
- 接收飞书事件（卡片消息、私聊、群聊）
- 转发给 OpenClaw Gateway
- 群聊智能回复（strict 模式：必须 @ 才回复）
- 消息去重和持久化
问题：
- 非原生集成，依赖额外 bridge 服务
- 需要 Cloudflare Tunnel 暴露公网
- 功能受限（无法使用 OpenClaw 原生飞书功能）
二、OpenClaw 原生飞书集成
2.1 官方支持情况
OpenClaw 官方原生支持飞书，通过 WebSocket 长连接接收事件，无需公网暴露。
支持的功能：
- 私聊消息
- 群聊消息（支持 @ 机器人）
- 卡片消息（Interactive Card）
- 发送消息（send_as_bot）
- 媒体文件处理
2.2 配置步骤
步骤 1：创建飞书应用
- 访问 飞书开放平台
- 创建企业应用
- 获取 App ID 和 App Secret
步骤 2：配置权限
在飞书应用权限中批量导入：
{
"scopes": {
"tenant": [
"im:message",
"im:message:send_as_bot",
"im:message:readonly",
"im:chat.members:bot_access",
"im:resource",
"aily:file:read",
"aily:file:write"
]
}
}步骤 3：启用机器人能力
在 应用能力 → 机器人 中启用并设置机器人名称。
步骤 4：配置事件订阅
- 选择 使用长连接接收事件（WebSocket）
- 添加事件：
im.message.receive_v1
步骤 5：发布应用
在 版本管理与发布 中创建版本并提交审核。
2.3 OpenClaw 配置
方式一：CLI 配置（推荐）
openclaw channels add
# 选择 Feishu，输入 App ID 和 App Secret方式二：配置文件
{
"channels": {
"feishu": {
"enabled": true,
"dmPolicy": "pairing",
"accounts": {
"main": {
"appId": "cli_xxx",
"appSecret": "xxx",
"botName": "小满"
}
}
}
}
}飞书国际版（Lark）配置：
{
"channels": {
"feishu": {
"domain": "lark"
}
}
}三、Telegram 对接现状
3.1 当前配置
已有 3 个 Telegram bot：
Bot │ Token │ DM 策略 │ 群聊策略
───────────┼───────────────────────────────┼─────────┼──────────
nexus │ 8605513784:AAHpV9JvZECkHc0... │ pairing │ allowlist
xiaoman │ 8679985454:AAFMmTZSHeBL_... │ open │ open
polymarket │ 8617997098:AAFtetMdfopk_... │ open │ allowlist配置特点：
- 均使用代理：
http://127.0.0.1:7897 - DM 策略：nexus 需配对，其他开放
- 群聊：xiaoman 完全开放，其他需白名单
3.2 优化建议
- 统一代理：可考虑移除代理（如果网络可达）
- 安全策略：生产环境建议使用 pairing 模式
- Streaming：可开启流式响应提升体验
四、完整对接方案
4.1 目标架构
┌─────────────────────────────────────────────────────────────┐
│ 用户 │
├──────────────┬──────────────────────┬──────────────────────┤
│ Telegram │ 飞书 │ │
│ (原生) │ (原生) │ │
└──────┬───────┴──────────┬──────────┴──────────┬───────────┘
│ │ │
▼ ▼ ▼
┌──────────────────────────────────────────────────────────────┐
│ OpenClaw Gateway │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ Telegram │ │ Feishu │ │ 其他渠道 │ │
│ │ (WebSocket)│ │ (WebSocket)│ │ (WhatsApp等) │ │
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
└──────────────────────────────────────────────────────────────┘4.2 实施步骤
第一步：切换到原生飞书集成
- 停止当前 bridge 服务
- 配置 OpenClaw 飞书原生支持
- 重启 Gateway
- 验证飞书消息接收
# 配置飞书
openclaw channels add
# 选择 Feishu，输入 App ID 和 App Secret
# 重启 Gateway
openclaw gateway restart
# 查看状态
openclaw gateway status第二步：优化 Telegram 配置
根据需要调整 DM 和群聊策略：
{
"channels": {
"telegram": {
"dmPolicy": "pairing",
"groupPolicy": "allowlist",
"streaming": "partial"
}
}
}第三步：配置群聊回复规则
飞书群聊支持两种模式：
strict：必须 @ 机器人才回复smart：智能判断，无 @ 也回复有价值的消息
{
"channels": {
"feishu": {
"accounts": {
"main": {
"groupPolicy": {
"groups": {
"oc_0c097efa8e1dd026ed84a61d7a22fe80": {
"requireMention": true
}
}
}
}
}
}
}
}五、飞书 Bot 高级功能
5.1 当前飞书 Bot 能力
基于现有配置，空空拥有的飞书 Bot：
能力 │ 状态 │ 说明
─────────────┼──────┼─────────────────
接收私聊消息 │ ✅ │ DM 策略：开放
接收群聊消息 │ ✅ │ 需 @ 或在群里
发送消息 │ ✅ │ send_as_bot
发送卡片消息 │ ✅ │ Interactive Card
处理媒体 │ ✅ │ 图片、文件等 5.2 飞书 API 能力（需额外配置）
能力 │ 权限名称 │ 用途
─────────────┼───────────────────────────────────┼─────────────
读取用户信息 │ contact:user.employee_id:readonly │ 获取用户身份
上传文件 │ im:resource │ 文件上传下载
创建群聊 │ im:chat:create │ 自动建群
@人 │ at:user │ 群聊@功能 5.3 消息类型支持
类型 │ 支持 │ 说明
───────┼──────┼─────────────────
文本 │ ✅ │ 基础文本消息
富文本 │ ✅ │ post 消息
卡片 │ ✅ │ Interactive Card
图片 │ ✅ │ image 消息
文件 │ ✅ │ file 消息
语音 │ ✅ │ audio 消息 六、问题排查
6.1 常见问题
问题 │ 可能原因 │ 解决方案
───────────────┼──────────────────┼─────────────────────────
飞书消息收不到 │ Gateway 未运行 │ `openclaw gateway start`
事件订阅失败 │ WebSocket 未连接 │ 检查 gateway 状态
权限不足 │ 权限未配置 │ 在飞书开放平台添加权限
群聊无法回复 │ 未发布应用 │ 提交审核并发布 6.2 调试命令
# 查看 Gateway 状态
openclaw gateway status
# 查看飞书通道日志
openclaw logs --follow | grep -i feishu
# 测试发送消息
openclaw message send --to <user_id> --message "测试"
# 飞书通道诊断
openclaw doctor七、结论与建议
7.1 当前评估
维度 │ Telegram │ 飞书
───────────┼────────────────┼─────────────────────────
集成方式 │ 原生 WebSocket │ Webhook Bridge（需改造）
稳定性 │ 高 │ 中（依赖 bridge）
功能完整性 │ 完整 │ 部分（bridge 限制）
维护成本 │ 低 │ 高（额外服务） 7.2 建议方案
推荐：切换到原生飞书集成
优点：
- 无需公网暴露（WebSocket 长连接）
- 功能完整（原生支持所有飞书能力）
- 维护简单（OpenClaw 内置）
- 稳定性高
实施难度：
- 中等（需要重新配置飞书应用）
- 需要停机迁移（约 5 分钟）
7.3 实施优先级
- P0：切换飞书到原生集成
- P1：优化 Telegram 配置
- P2：添加飞书高级功能（文件上传、用户识别等）
附录
A. 飞书应用权限清单
im:message # 接收消息
im:message:send_as_bot # 发送消息
im:message:readonly # 读取消息
im:chat.members:bot_access # 获取群成员
im:resource # 资源文件
aily:file:read # 读取文件
aily:file:write # 写入文件B. 相关链接
- 飞书开放平台：https://open.feishu.cn
- OpenClaw 飞书文档：https://docs.openclaw.ai/channels/feishu
- 飞书 Bot 开发指南：https://open.feishu.cn/document/server-docs/im-v1/message-content-description
C. 当前配置参考
飞书 App ID: cli_a9147270bf785eef
飞书 App Secret: E0uJ4NbE4eAlMzN2wxbZIfTLgtmxZahD
GenGo 群 chat_id: oc_0c097efa8e1dd026ed84a61d7a22fe80
测试群 chat_id: oc_ff7ba9324d31ac25051ddb1e927cfa2b
空空 open_id: ou_f51b1ac9513c91b557b2e1017ae75fc4报告撰写：小满 🌾
最后更新：2026-03-13 18:55 GMT+8