Agent 长任务的三次"断点"：从沙箱排队说起，聊交互模型的三个改进方向

这是"AI Agent 全链路交付"系列的第三篇。第一篇讲了成功（一次对话把 2048 游戏部署到公网），第二篇讲了失败（10 个真实踩坑）。这一篇想认真聊聊：这 10 个坑里，有 4 个其实指向同一个根源——Agent 的交互模型还没为"长任务"做好准备。

引子：半小时的排队，和被打断的重试

事情从沙箱部署开始。我让 Agent 把一个游戏部署到华为云沙箱，它遇到节点池满载（HD.99003001），正确地选择了每 15 秒重试一次。排队、失败、重置、再连——一切都在正轨上。

然后，循环检测机制把这个重试循环判定为"疑似死循环"，禁用了所有工具，直到我手动发一条"继续"才恢复。用户明明授权过"每 15 秒重试"，任务还是断了。

这不是个例。复盘整个交付过程，"断点"出现了三次，每次都对应一个交互模型的设计缺口。

断点一：用户说不上话——缺少非中断式引导

现状：Agent 执行长任务时，用户只能等任务完全结束才能补充指示。发现方向错了，要么看它跑完再返工，要么中断从头再来。

实测代价：沙箱部署任务中，排队期间我明知该换个时间段或检查其他资源，却没有任何通道把这个判断"插"给 Agent。它按原计划盲跑了半小时。

改进方向：工具调用的间隙天然是"检查点"。允许用户在检查点插入引导消息（补充约束、修正方向），Agent 在下一个工具调用前消费并调整计划。任务不必中断，上下文不必重建。竞品 WorkBuddy 已经验证了这种"非中断式插入"的可行性。

一句话总结：用户要的不是"随时打断"，而是"插得上话"。

断点二：系统分不清"死循环"和"有进展的等待"

现状：循环检测通常按"调用参数是否重复"判定。但长任务里最常见的模式恰恰是"固定间隔重试 + 错误信息变化"——参数一模一样，错误却在演化：

• 第一轮：No available node pool（排队）
• 第 N 轮：not closed and cannot be started（实例卡死，需要重置）
• 重置后：又回到排队……

参数相同、错误在变、每轮都有自动处置动作——这是有进展的等待，不是死循环。但检测机制一视同仁地掐断了它。

改进方向：① 检测器识别"响应内容仍在变化"的特征，放宽阈值；② 允许用户显式授权重试豁免（"每隔 N 秒重试"这句话本该被理解为授权）；③ 触发禁用时提供"转后台脚本继续"的选项而非直接冻结。

一句话总结：等待外部资源 ≠ 死循环，判定器需要读懂错误信息的演化。

断点三：环境一重置，Agent 就"失忆"

现状：长会话中途环境重置，本地状态大面积丢失——CLI 二进制消失（同一天装了 3 次）、OAuth token 失效（重新授权 2 次）、已装技能目录被清空。每次都要重装重授权，任务连续性被打断。

实测代价：最痛的一次是发布流程进行到一半，STS 凭证刷新依赖的 CLI 路径突然失效，spawnSync ENOENT 直接卡住自动刷新机制，只能人工重建整条链路。

改进方向：① 会话生命周期内保证用户级状态（$PATH、~/.local/bin、~/.gitcode）持久；② 重置不可避免时，先快照关键状态、恢复后自动还原，并明确告知 Agent 需要重建什么；③ 至少把"环境重置"做成一个 Agent 可感知的事件，而不是让它排错排到一半才发现世界变了。

一句话总结：Agent 的"记忆"不该比用户的会话更短命。

更深一层：从"工具执行者"到"可协作的同事"

这三个断点背后是同一个命题：当前的 Agent 交互模型，本质是"用户发起 → Agent 执行 → 返回结果"的一次性委托。而真实的知识工作（运维、发布、排障）是长周期、多干扰、需要人持续在场的过程。

理想的模型更接近"同事协作"：

这不需要架构革命——三个改进点（检查点插入、响应演化感知、状态持久化）都是渐进式的，却决定了用户敢不敢把重要任务交给 Agent。

结语

系列三篇写完了：它做到了什么、它哪里会坏、它该怎么变。2048 游戏还挂在公网上，3000 活动积分已落袋，但比积分更有价值的是这个认知：Agent 的上限不取决于它多聪明，而取决于它在最不可预测的时刻，还能不能和你保持协作。

系列前篇：《一次对话，从零到公网上线》《AI Agent 全链路交付实录：10 个真实踩坑与解法》。文中三个改进方向已通过云声平台提交华为云产品团队。