OpenClaw Feishu 排障：/stop 与 /new 可能无法中断正在执行的会话（v2026.3.23）

最新一条 Feishu 频道问题显示：/stop 和 /new 在聊天界面里可能“像是生效了”，但实际上没有中断当前正在执行的 agent 回合。

也就是说：

Feishu 侧接受了命令
用户看不到明显报错
但原任务仍会一路跑完，最后照常返回结果

来源：

Issue： openclaw/openclaw#54151

这个问题具体是什么

该报告针对的是 OpenClaw 2026.3.23 下的 Feishu 私聊（DM） 场景。

复现现象是：

先触发一个长时间运行的任务
在任务还没结束时发送 /stop 或 /new
系统表面上接收了这个命令
但 agent 还是会把原本那次执行跑完，并最终回消息

理论上的正确行为应该是：

/stop 立即中断当前执行
/new 结束当前上下文 / 中止当前回合，效果应与 Discord、Telegram 等渠道保持一致

为什么这不是“小问题”

这不只是一个提示文案不准的小瑕疵，而是会直接影响实际运维体验：

1）浪费时间

操作者以为任务已经停了，实际上它还在继续消耗时间。

2）带来额外成本或副作用

如果当前任务会继续：

调工具
读文件
查外部 API
生成内容

那“停不下来”就可能带来额外调用成本，甚至产出不该继续产出的结果。

3）让多人协作更混乱

因为 UI / 聊天表面上没有报错，团队成员很容易误判为“任务已取消”，然后又发第二条指令，最后把会话状态搅乱。

怎么快速确认你遇到的是同一类问题

如果下面几条同时成立，你大概率命中的就是这个问题：

使用渠道是 Feishu
OpenClaw 版本接近 2026.3.23
失效命令是 /stop 或 /new
命令发出后，原任务仍继续执行直到结束

一个最短测试流程：

先触发一个稳定会跑 20–60 秒的任务。
在 agent 还在处理中时，发送 /stop。
如果最终仍收到完整结果，说明停止信号大概率没有真正进入执行层。
用 /new 再测一次。

如果你发现同样的命令在 Discord、Telegram 等其他渠道有效，但 Feishu 无效，那就更像是Feishu 渠道专属回归，而不是通用的会话取消问题。

官方修复前，怎么先止血

方案 1：不要把 Feishu 作为长任务的唯一控制面

如果你同时接了别的渠道，并且那些渠道的中断逻辑正常，建议把以下任务切过去：

长研究任务
代码类任务
会大量调用工具 / 外部服务的任务

方案 2：把大任务拆小

在 /stop 不可靠的情况下，最有效的运营动作不是“更频繁地停”，而是少让单次任务跑太大。

例如优先这样下指令：

“先总结仓库结构”
“再看最近 3 个 commit”

而不是一上来就让它做整套多阶段审计。

方案 3：明确提醒团队“已接收命令”不等于“已真正停止”

如果同一个 Feishu 机器人有多人在用，建议在团队操作规范里写清楚：

聊天里看到 /stop 被接收，不代表执行已经停止
在没有看到最终状态前，不要假设当前回合已死掉

方案 4：别只顾着重试，先抓时间点和日志

如果你自己维护 gateway，建议优先记录：

长任务开始时间
/stop 或 /new 发送时间
原任务最终完成时间

比起一遍遍重跑，这些证据更有助于维护者判断问题卡在：

Feishu 命令解析
渠道路由
还是取消事件根本没传到执行控制层

谁最容易被这个 Feishu 中断问题影响

这类问题尤其影响下面三类人：

把 Feishu 当作主控制面的操作者，因为他们会误以为长任务已经停掉，实际上执行仍在继续。
大量依赖工具调用的团队，因为 stop 失效会继续消耗 API 调用、文件读取和排障时间。
多人共用同一个机器人协作的场景，因为“看起来已取消”最容易引发重复重试和互相打架的指令。

常见止损判断问题

什么时候不该继续反复重试 `/stop`，而该先收缩 blast radius

如果界面已经明确显示命令被接收，但任务仍持续输出，那么继续反复发 /stop 的收益通常不如先止损：暂停追加新指令、把后续工作切到别的渠道，并记下时间点去对日志。

在这种故障形态里，`/new` 会不会比 `/stop` 更安全

不一定。如果这两个命令都只是在聊天层被接收，却没有真正中断活动执行，那么在 /new 和 /stop 之间来回切换，可能只会改变界面感受，而不会解决底层执行控制问题。

维护者大概率会关心哪些方向

基于当前 issue，比较值得重点排查的方向包括：

Feishu 渠道里 slash 风格命令的解析
命令消息到 session / run 的路由是否正确
聊天侧“已接收”的反馈是否只是表面确认，但没有把 cancel / reset 意图真正传给活动中的运行控制器

这只是基于现象做的技术推断，不代表已经确认根因。

搜索入口补强：用户真正搜索的通常不是完整 issue 标题

大多数运维同学不会搜索完整 issue 名，而是直接搜自己眼前的症状，比如：

OpenClaw Feishu /stop 不生效
OpenClaw /new 没有停止当前任务
Feishu 命令已接收但 agent 还在跑
OpenClaw Feishu 无法中断正在执行的会话
Feishu /stop 显示成功但任务仍然完成

如果你是从这些搜索词点进来的，最快的判断顺序是：

如果命令本身根本没有被识别
- 更像是命令解析或渠道格式问题，而不是本文讨论的这一类故障。
如果命令看起来被接收，但旧任务仍返回完整结果
- 这就是最典型的 Feishu 中断失效形态。
如果 /stop 只在 Feishu 失效，换到其他渠道正常
- 优先怀疑渠道侧中断事件路由，而不是通用 session 逻辑。
如果你发 /stop 时任务其实已经结束
- 那是操作时机问题，不是这次回归本身。

这种“按症状走”的入口，通常比直接翻原始日志更快。

哪些情况大概率不是这篇在说的问题

如果你遇到的是下面这些情况，这篇文章大概率不对症：

命令在聊天里根本没显示出来
Feishu 所有 slash 风格命令都失效，不只是 /stop 或 /new
任务实际上已经停了，只是旧消息因为延迟队列或重试机制晚到
同样的问题在你使用的所有其他渠道上都一模一样发生

这几类情况更应该先查命令格式、消息投递/路由，或者更广义的会话控制问题，而不是直接假设命中了这个 Feishu 专属问题形态。

3 步运维摘要

如果你只有 2 分钟，优先按这个顺序排：

在 Feishu 里先启动一个 20–60 秒的任务
在任务完成前发送 /stop 或 /new
确认原任务是否仍然完整返回结果

如果第 3 步为“是”，那你大概率命中了同一类回归。如果相同测试在其他渠道正常，就应把 Feishu 路由视为首要怀疑对象。

最容易和这篇一起被搜索的问题

如果你是从搜索进来的，通常还会顺手找这些相邻问题：

Feishu /stop 和 /new 哪个更容易失效
OpenClaw Feishu 长任务怎么安全止损
Feishu 私聊和群聊的中断行为是否一致
收到 stop 命令后 gateway 日志应该看哪里

对大多数运维同学来说，真正要先确认的不是“这是不是一个新 bug”，而是：你现在有没有继续放任长任务在后台消耗时间、工具调用和排障注意力。

所以更实用的判断顺序通常是：

先确认当前任务是否仍在持续输出
再确认 Feishu 里 /stop 与 /new 是否都失效
再对比其它渠道是否正常
最后才去补 issue 和日志

常见混淆判断：它到底更像 Feishu 渠道故障，还是通用 session 中断故障

如果你现在只想快速分流，不想一头扎进源码，先按这个顺序判断：

只有 Feishu 失效，其他渠道可正常中断
- 优先怀疑 Feishu 侧命令解析、命令路由或取消事件传递。
所有渠道都停不下来
- 更像是通用 session / run 控制层问题，不该把排障入口只锁在 Feishu。
只有 /new 异常，/stop 偶尔还能中断
- 说明 reset/new 与 stop 走的控制路径可能并不完全一致，值得分别记日志。
聊天层显示“命令已接收”，但后台结果照常落回当前线程
- 这是最值得优先截图和记时间点的故障形态，因为它最能说明问题不在“消息有没有发出去”，而在“停止意图有没有真正落到执行层”。

这种分流方式的价值在于，它能帮助你在 2 到 3 分钟内决定：是继续换渠道止损，还是继续追底层会话控制。

Feishu 中断失效时的 5 分钟止损清单

如果你现在就在事故现场，不要把全部时间花在重复发送 /stop。更有效的做法，是先把继续消耗控制住，再回头补证据。

立即停止在同一 Feishu 线程里追加新需求，避免旧任务和新任务输出混在一起。
用另一个已知可中断的渠道接管后续操作，比如 Web、Telegram、Discord 或本地 CLI。
记录三段时间：原任务开始时间、/stop 或 /new 发送时间、旧任务最终返回时间。
如果任务带工具调用，先暂停高成本或高风险工具，不要让后台继续扩大影响面。
等任务自然结束或从其他控制面确认停止后，再整理日志和复现步骤。

这段清单的目标不是证明谁对谁错，而是先避免 Feishu 控制失效把一次小故障拖成长时间消耗。对搜索进来的值班同学来说，先止损，再定位，通常比继续赌聊天命令更稳。

如果你要补充 issue，最好带上这些信息

想让维护者更快复现，建议补充：

OpenClaw 版本号
Feishu 场景是私聊还是群聊
当前任务是纯模型推理，还是带大量工具调用
你发的是 /stop 还是 /new
聊天界面是否显示“命令已接收”
原始长任务是否仍完整返回
同一时间段的 gateway 日志

这页还应该直接回答哪些高意图问题

这类页面拿搜索流量，不是靠重复 issue 标题，而是靠提前回答操作者下一秒就会问的问题。

最值得补强的高意图问题包括：

我现在该继续在 Feishu 里重试，还是立刻切走别的渠道
- 如果长任务还在持续输出，优先切到已知可中断的渠道，而不是继续在 Feishu 里赌 /stop 会突然恢复正常。
这更像是 Feishu 专属问题，还是整个 OpenClaw 的 stop 机制都坏了
- 如果 Discord、Telegram 或其他渠道能正常中断，同一时间只有 Feishu 失效，就更像渠道专属回归。
我应该先收集什么证据，才能让维护者最快定位
- 最有价值的通常不是截图，而是任务开始时间、/stop 发送时间、最终完成时间，以及对应 gateway 日志。

这页应该直接覆盖哪些搜索词

为了吃到更高意图搜索，这页至少应当能直接承接：

openclaw feishu stop not working
openclaw /new not stopping current task
feishu slash command accepted but agent keeps running
openclaw feishu cannot interrupt running session
feishu /stop acknowledged but task still finishes

这些搜索词背后的共同意图很明确：操作者不是在了解一个 bug 新闻，而是在找最快止损动作。

如果你是从 Kimi 重置、发布评估或安全/成本入口来的

这些入口带来的读者，通常已经遇到了“控制不住会话”的症状，但根因不一定相同。先按这个顺序拆开：

普通用户消息一发出就出现 /new 或 /reset 提示：更像 Kimi-Claw 强制重置问题，优先查 session 生命周期是否被错误重建。
任务还在同一线程里继续跑，只是 /stop 或 /new 没有中断它：才更像本文的 Feishu interrupt 事件没有落到执行层。
你是在版本升级、迁移或成本异常后才注意到这个问题：先把 2026.3.13 发布评估、迁移指南和安全/成本页的检查项补齐，再回到本文确认是不是 Feishu 专属。

这段分流的价值，是把“会话被重置”“任务停不下来”“升级后不稳定”“工具调用继续烧成本”拆成不同入口。只有确认是 Feishu 命令被接收但执行层没停，本文的止损顺序才最对症。

如果你是从 troubleshooting 进来，先分清命令送达和会话取消

GA4 现在把这篇飞书 stop-command 页面和 setup、agent 排障入口放在同一组里。读者可能已经输入了 /stop，但真正有用的判断是中断请求丢在哪一层。

重启 bot 之前，先拆成三类：

飞书没有送达命令：检查 callback verification、bot 权限、会话类型，以及消息事件是否进入 OpenClaw 日志。
OpenClaw 收到 /stop 但会话继续运行：保留 session id、活动任务类型、runtime adapter，以及 cancellation hooks 是否触发。
新命令已开始但旧 run 仍在输出：按并发或 channel routing 问题处理，不要误判成飞书认证问题。

这样能避免高意图排障读者反复重装飞书应用，而真正需要修的是会话取消或 channel 事件路由。

高成本任务停不下来时，先执行这张 5 分钟护栏

如果 /stop 已经被飞书接收，但旧任务仍在调用工具或持续输出，优先目标不是继续证明 bug，而是先把损失边界缩小：

立刻暂停外部副作用：如果任务会发消息、写文档、部署或调用付费 API，先从平台侧暂停 token、hook 或队列入口。
切换控制面：用 Web、CLI 或另一个已知可中断渠道确认同一 session 是否还能被控制。
冻结新指令：不要在同一飞书线程继续追加复杂命令，避免旧 run 和新 run 交错输出。
记录成本窗口：写下 /stop 发送后到旧任务真正结束之间的分钟数、工具调用次数和外部写入数量。
恢复后补一条复盘结论：明确这是 Feishu interrupt 丢失、全局 cancellation 失效，还是工具层没有响应取消信号。

这张护栏适合从安全/成本、发布事故或首页直达的读者。它把“怎么停不掉”先转成“怎么不继续扩大影响”，更符合真实值班时的优先级。

事故单里直接复制这 6 行 Feishu stop 记录

如果这次 /stop 失效已经影响到成本、外部写入或客户对话，把证据整理成固定 6 行，比在群里补截图更有用：

Feishu stop incident:
- session / thread: <session id, chat type, channel>
- task start / stop sent / actual finish: <timestamps>
- command path: </stop or /new, acknowledged or not>
- blast radius: <tool calls, writes, paid API usage, messages sent>
- cross-channel check: <Web/CLI/other channel can stop or cannot stop>
- owner decision: <pause token, disable hook, rollback, or escalate>

这 6 行能让维护者先判断是 Feishu channel、全局 cancellation，还是工具层取消信号没有被尊重；也能让团队在成本复盘时直接看到影响窗口。

判断该暂停 Feishu 写入，还是等待旧任务自然结束

当 /stop 在高成本 Feishu 任务里失效时，下一步不是继续讨论文案，而是一个运维判断：要不要先把频道写入能力临时关掉，等旧任务结束后再恢复？

可以按这三类分流：

立刻暂停写入：如果旧 run 还能给客户发消息、改共享文档、部署代码，或继续消耗付费 API，先从平台侧切断副作用入口。
观察到结束：如果任务只读、已经接近完成，并且 Web 或 CLI 仍能控制同一 session，可以保留现场并等它 drain 完。
升级为平台事故：如果 Feishu 新消息会继续启动新 run，而旧 run 仍在输出，这已经不是单个任务卡住，而是并发和路由风险。

这段判断给搜索访客一个明确的成本控制动作。本文不只解释 Feishu /stop 为什么没停住，也要帮助值班人员判断什么时候该暂停 channel，避免损失继续扩大。

先确认 stop 失败在飞书路由还是 agent 取消

当飞书用户反馈 “stop 不生效” 时，先拆分事故边界，再改命令别名或重启 gateway：

消息路由：确认包含 stop 的飞书事件确实到达 OpenClaw，并且映射到正在执行任务的同一个 conversation/session。
命令解析：检查频道把 stop 当成普通文本、回复、at 命令，还是 slash 风格命令，因为这些路径可能进入不同 handler。
取消边界：确认 agent 进程是否收到 cancellation signal，是只有聊天流停止，还是后台任务仍在继续跑。
面向用户的兜底：如果无法保证已取消，回复 session id 和最安全的手动 kill 或 steer 路径，不要假装任务已经停止。

这样能把飞书 stop 命令相关搜索更快分流成：先查路由，再查 parser mismatch，最后查 cancellation/runtime bug。

从 stop command 流量转成取消链路排查

如果你是因为飞书里 /stop 不生效搜到这里，先不要只判断 agent 是否还在输出。要把取消链路拆成四段：飞书消息是否被 gateway 收到、命令解析是否命中当前 session、运行中的 agent 是否收到 cancel signal、以及 channel 是否仍在重放旧输出。

最小排查路径是记录触发 /stop 的 message id、目标 session id、运行进程状态和停止后的第一条回包。只有当命令已命中 session 但 agent 仍继续执行时，才把它升级为 cancellation bug；否则先修路由、权限、session 绑定或重复投递。

什么时候该用 steer，而不是继续发 stop

如果 Feishu 里的 stop 命令连续两次没有让任务停下，不要无限重发同一句控制消息。此时更稳的做法是切到更靠近运行时的控制面，用 steer、kill 或后台任务状态来确认当前 run 是否还能被接管。

优先切换的信号有三个：任务仍在调用外部 API、仍在写文档或发消息、或者 Feishu 频道已经出现重复投递。继续在同一 thread 里刷 stop，可能只会制造更多普通用户消息，反而让 agent 继续响应。

这段适合承接“Feishu stop not stopping running agent”“OpenClaw stop acknowledged but still running”这类搜索：先从聊天命令退到运行时控制，再决定是安全取消、隔离 channel，还是保留证据升级 bug。

重启飞书 channel 前，先做 stop command 分层排查

如果你是搜“OpenClaw Feishu stop command not working”或“Feishu channel ignores stop”来到这里，第一轮先把它当成 command routing 问题，不要直接判断成整个 channel 故障。建议顺序是：

确认用户发出的原始消息文本，是否完整进入了 Feishu channel handler；
验证 stop command 是在线程/session 路由之前解析，还是路由之后才解析；
检查正在运行的任务，是否挂在另一个 session、tenant 或文档上下文里；
一边 tail gateway 日志和 agent session 状态，一边发送一条受控 stop command；
只有证明命令已收到但没有传播到 running task，再重启 Feishu channel。

这能保护线上飞书工作流：先定位断点是在消息进入、命令解析、session 查找，还是 cancellation 传播，再避免误伤无关 channel 流量。

常见判断问题 FAQ

如果聊天里已经显示 `/stop` 被接收，为什么还不能当成任务真的停了？

因为这类故障的关键就在于：聊天层确认 和 执行层真正中断 不是一回事。

如果你已经看到命令被接收，但原任务仍继续输出直到结束，那么更安全的判断是“停止意图没有真正传到 run 控制层”。

什么时候更该优先怀疑 Feishu 渠道路由，而不是通用 session 控制问题？

如果同样的 /stop 或 /new 在其他渠道能正常中断，只有 Feishu 不行，那就更该优先怀疑 Feishu 侧命令解析、路由或取消事件传递。

这类对照，比单独盯着一个失败现场更快缩小问题面。

搜 `feishu stop acknowledged but task still running` 的人，页面最该先帮他分哪三个支路？

最该先分这三个：

命令是根本没被识别，还是已被接收但任务不停
只有 Feishu 失效，还是所有渠道都停不下来
失效的是 /stop、/new，还是两者都失效

这三步最能帮助用户从“任务怎么停不掉”收缩到“Feishu 渠道中断事件没真正落到执行层”。

搜索入口分流：飞书里 stop 命令不生效先看什么

如果你是从 “Feishu stop command not working”、“飞书 OpenClaw 停止不了任务” 或 “/stop 没反应” 搜到这里，先把问题拆成四层：

确认命令是否被飞书原样送达：先看消息事件里是否真的包含 /stop，以及是否被富文本、机器人菜单或引用回复改写。
确认 channel adapter 是否识别为控制命令：如果 adapter 把 /stop 当普通用户消息，agent 只会继续回答，不会取消任务。
确认要停止的是哪个运行中任务：多会话、多 thread 或子代理场景里，stop 可能打到错误 session。
确认取消信号是否传到 runtime：命令识别成功后，还要验证任务队列、tool call 或 background run 是否真的收到 cancel。

这类故障不要只看前端有没有回复“已停止”。最短路径是验证“飞书事件、adapter 解析、session 定位、runtime cancel”四段是否一致。

FAQ：飞书 stop 不生效时先保什么证据

已经回复“收到 stop”还要继续查吗？

要继续查。飞书侧的收到只证明消息进入了聊天层，不等于当前 run 收到了 cancel signal。先把 message id、conversation id、session id 和停止后的第一条输出放在一起，判断是 adapter 解析问题，还是 runtime 没有真正中断。

多会话时怎么避免 stop 打到错误任务？

不要只看用户最后一条消息。要对齐触发 /stop 的飞书 thread、OpenClaw session id、后台 process id 或 task id。如果 stop 打到空闲 session，页面上会像“没反应”，但真正的问题是 session 绑定错位。

什么时候该从渠道问题升级为核心取消 bug？

只有在飞书事件原文、adapter 命令识别、目标 session 命中都确认正确后，agent 仍继续执行工具或持续输出，才升级为核心 cancellation bug。否则优先修飞书路由、权限、引用回复或重复投递。

来源

openclaw/openclaw#54151