OpenClaw Launch（https://openclawlaunch.com）创始人。记录关于智能体运维、自托管以及生产环境中实际会出问题的地方。
在多智能体聊天中，取消边界可能导致用户消息已被保存、进行中的回复仍然可见，而后续智能体未被调用。这是三种不同的结果。
我构建了 OpenClaw Launch，其中包含一个群聊功能，一个智能体可以将工作传递给另一个智能体。在阅读队列运行器时，我发现了一个对任何围绕异步工作构建“停止”按钮的人都有用的提醒：取消检查的位置决定了什么会被停止。它不会抹除检查之前已经发生的效果。
考虑一个群组回合：包含一条用户消息、一个前门智能体和一个对等智能体。运行器首先复制之前的对话记录。每一行新内容都遵循以下顺序：
append to the turn result append to the working transcript notify the live UI through onLine await the persistence write
只有在发出用户的那一行之后，运行器才会规划智能体步骤并进入其队列循环。在每次迭代的开头，它会检查信号是否已中止。这种顺序会产生一个可能让界面阅读者感到意外的结果：如果信号已经中止，则不会启动任何智能体发送，但用户的那一行仍然已被发出并写入。“在任何机器人回复之前停止”并不意味着“这个回合从未存在过”。
进行中的发送有不同的边界
运行器在采取下一个排队步骤之前检查取消，然后等待注入的发送函数。它不会在该 await 之后立即再次检查信号。
设想前门发送处于待处理状态时，用户按下了停止。如果该发送仍然成功完成，运行器可以追加并持久化其回复。它将在分派下一个排队的对等智能体之前停止。由此产生的对话记录可以合理地包含用户消息和一条机器人回复，即使用户在请求进行中按下了停止。
这比“停止会取消网络请求”是一个更窄的主张。队列运行器的发送依赖接收的是一个步骤和对话记录，而不是中止信号。调用方可以通过闭包捕获信号并将其传递给 HTTP 适配器，但此运行器并不保证这种连接。此实现中的适配器可以将信号传递给 fetch 并传播中止，但已中止的 fetch 仍然无法证明远程服务撤销了它已经执行的工作。
可见并不等同于持久
逐行发射序列还有第二个后果。onLine 在持久化 promise 解决之前触发。如果该写入失败，查看者可能已经看到了一行从未被确认保存的内容。运行器不会捕获持久化拒绝并返回正常结果；该函数会拒绝。之前成功的写入不会被回滚。onLine 内部的同步失败甚至可能阻止该行的持久化调用。
这不是隐藏流式输出的理由。这是准确命名其状态的理由。接口可以区分 received、shown 和 saved，而不是将可见的一行视为持久化的证明。是否暴露全部三种状态取决于产品，但实现不应模糊它们。
我会如何测试边界
这些用例需要受控的 promise，而不是 sleep：
从一个已经中止的信号开始。断言用户行被持久化，且 send 从未被调用。
暂停一个假的 send，中止信号，然后成功解决该 send。断言其回复被发射，且下一个排队的 send 从未启动。
让用户写入成功，然后拒绝机器人回复的持久化。断言 onLine 在写入被拒绝之前看到了机器人回复，并且运行器拒绝而不是返回成功结果。
单独将信号接入实际适配器，并测试中止拒绝路径。这检查传输行为，而不会将其与队列循环的行为混淆。
实用规则是在每个边界定义“Stop”：未来调度、进行中的传输、UI 显示、持久化和远程副作用。单个中止标志无法使这五个全部原子化。
关于作者
OpenClaw Launch (https://openclawlaunch.com) 创始人。关于智能体运维、自托管以及生产环境中实际会出什么问题。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：Hacker Noon
原文作者：Zack Chew；如有侵权，请联系管理员删除。
