long-command-check 是面向智能体开发者的一份审计清单，用于检查智能体框架运行长 shell 命令时的行为设计。它的核心问题是：当智能体执行 shell 命令时，应该等待命令结束吗？由此展开一系列设计决策——前台用于快速命令，后台用于长命令，理想情况下同一进程连接两者。
该清单是 MCode Engineering Notes 04《一条 bash 命令应等待多久》的配套材料，提供纯文本清单 checklists/long-command.md。
为什么等待代价高：智能体阻塞在命令上时有两项成本。可见成本是用户等待且无其他进展；隐藏成本是提供方的提示缓存可能过期。命令在前台运行时没有新的模型请求，若等待时间超过所用模型服务的缓存生命周期，下一次请求需重新处理整个前缀，导致首 token 更慢、成本更高。缓存生命周期需查阅所用提供方文档。将工作移到后台并不能让缓存一直保持热态，它节省的是智能体本可做其他工作却空等的时间。
如何使用：阅读目标智能体的 shell 工具与后台任务代码，对每一项以证据记录答案（文件与函数、配置或实际运行的测试）。不要猜测；代码未体现时写“未知”。
十项检查：1. 前台限制——前台最多等待多久？是否明显低于模型服务的缓存生命周期并留出生成时间？2. 不重跑——命令从前台转后台时是同一进程，还是被杀死后重新启动？3. 超时计时——转后台并读取输出后，截止时间是否被重置？（不应重置，否则卡住的命令可无限运行。）4. 结果投递——后台任务完成时，模型是通过通知得知，还是只能轮询？5. 通知位置——通知是追加在末尾，还是修改了已缓存的前缀？6. 防止轮询——阻塞等待时间是否有上限，重复读取无变化时是否提示停止轮询？7. 输出大小——大输出是被截断或写入文件增量读取，而不是整段粘贴进上下文？不完整输出是否标注为不完整？8. 清理——用户停止智能体、一次性无头运行退出、进程重启时，由谁停止后台任务？孤立任务是否被标记，而不是永远显示“运行中”？9. 压缩之后——“任务已完成但结果未读取”是否记录在对话历史之外（例如任务表），以便在压缩后仍能保留？10. 前提条件——若当前环境无法读取后台结果，是否禁用后台执行？
行为测试：若能运行智能体，可尝试并记录实际发生的情况：让它启动开发服务器再做别的事，是否卡住？运行需数分钟的命令，是否在不启动第二个副本的情况下转入后台？启动后台任务后停止智能体，任务是否停止？让后台任务完成，在读取结果前触发压缩，未读结果事后是否仍会呈现？
输出：十项检查的通过/失败/未知与证据表、行为测试结果，以及前三项修复建议。