钉钉输出与后台任务
比较按轮次、响应和任务发送的策略，识别等待、取消与部分结果。
outputMode 目前只适用于 type 为 dingtalk 的渠道。它决定哪些完成的助手文本成为可发送回复；不把所有中间内容自动汇总成一个新答案。
三种模式
| 值 | 发送时机 | 适用判断 |
|---|---|---|
| per_turn | 每轮使用最后一个非空助手回复；默认值 | 一般交互，后台完成不重新打开已经结束的主回复 |
| per_response | 每个完成的助手响应分别发送 | 需要看到一轮中的多个完整响应；不是逐 token 消息 |
| per_task | 等关联任务结束后，发送保留的最后回复 | 希望等待本次任务的后台工作完成 |
在渠道对象中配置，例如：
{
"outputMode": "per_task"
}final_only、process_and_result 不是有效别名。关闭状态卡后仍按相同策略发普通消息，媒体投递和既有长消息回退继续生效。Loops 和 Webhook 的既有输出路径不因这里的模式变成相同语义。
per_task 等待什么
等待范围包括当前任务关联的 agent、shell、monitor 和 workflow，以及完成通知轮次继续创建的关联工作。暂停或长时间运行的 monitor 可能让任务一直等待，直至完成或取消。
未来的 cron 调度和独立管理的子会话不在这个关联范围内。不要把 per_task 理解成“工作区里所有进程都结束后才回复”。它保留最后回复，不连接所有文本，也不自动生成总结。
后台 shell、monitor、workflow 通知在按任务输出时带有类别、状态与标签；按响应模式使用响应正文。agent 回复仍按该模式选择正文。
中断和完成的边界
TodoStopGuard 让出执行、或排队工作取消时，per_task 保留但尚未发送的回复不应显示成成功结果；相关后台工作可能仍然存在。独立运行路径中，后台工作被中断或超过 10 分钟尚未结束时，可能交付部分结果。
因此，任务完成、卡片结束和消息成功送达是不同状态。需要判断实际结果时，结合后台任务状态和渠道日志；不要仅凭最后一张卡片推断所有工作都已成功。