这篇是一次真实问题的复盘。
我要记录的不是“怎么写提示词”，而是一个更底层、更影响交付效率的问题：
在 Gateway Dashboard 的 Agents 页面里，飞书渠道默认不能正常新增“可持续使用的 Agent”，只能临时拉起一次性 Agent。
如果这个点不修，表面看是“能用”，实际会造成：上下文断裂、任务不可追踪、每次都像重新开工。
现象：为什么说它是“只能一次性”
在故障出现时，典型表现是：
- 你在 Dashboard 的 Agents 页面操作“新增 Agent”；
- 飞书渠道看起来会响应，但 Agent 不会稳定进入可持续协作状态；
- 任务可以短暂跑起来，但后续承接、追踪和复用都很弱；
- 结果上就像“临时会话机器人”，而不是“持久 Agent”。
这会直接影响日常工作流：
- 多任务并发时，回报链路容易乱；
- 上下文跨任务衔接差；
- 交付标准（路径、build、commit、push）难稳定执行。
根因（业务视角）
从业务层理解，这个问题本质是：
- Dashboard 的新增 Agent 流程对飞书渠道的默认处理不完整；
- 导致 Agent 生命周期没有按“持久协作”路径落地；
- 最终用户侧感知就是“只能临时用一次，不能长期接力”。
换句话说，不是“AI 不够聪明”，而是“渠道接入与 Agent 生命周期管理”没有对齐。
修复目标：不是能回消息，而是能长期协作
修复目标应该明确成 4 点：
- 可创建：在 Agents 页面新增飞书 Agent 能稳定成功；
- 可持续：不是一次性任务，后续可持续承接；
- 可追踪：有清晰的任务状态、回报与结果链路；
- 可复用：同一 Agent 可用于后续同类流程。
修复后带来的变化
修复完成后，协作方式会发生明显变化：
- 你不再需要每次从头解释背景；
- 可以把任务拆分给多个子任务并发推进；
- 回报可以按“文件路径 / build 结果 / commit hash / push 状态”标准化；
- 整体节奏从“救火式问答”变成“工程化协作”。
为什么我要专门写这篇
因为这个问题非常容易被误判。
很多人会说“不是已经能回复了吗？”
但真正影响效率的是：
- 能不能持续承接上下文；
- 能不能形成稳定的任务闭环；
- 能不能把每次交付变成可复验的结果。
所以这篇的重点不是“飞书接上了”，而是：
在 Gateway Dashboard 的 Agents 页面里，飞书渠道新增 Agent 这件事，必须按持久协作逻辑修正。
给团队的落地建议
如果你也在做类似接入，建议把验收标准写死：
- 新增 Agent 后是否能跨消息持续工作；
- 是否支持任务并发与异步回报；
- 是否能稳定产出可验证交付（路径、构建、提交、发布）；
- 是否可以在同一 Agent 上连续迭代，而不是频繁重建。
当这些都满足，才算真正“解锁持久 Agent”。
如果你在飞书渠道也遇到“看似可用、实则一次性”的情况，这篇复盘希望能帮你少走弯路。
