Skip to content
FunCoding

Search

Search docs, Skills and MCP

钉钉输出与后台任务

比较按轮次、响应和任务发送的策略,识别等待、取消与部分结果。

This page has not been translated into English yet. The original Chinese version is shown below.

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 分钟尚未结束时,可能交付部分结果。

因此,任务完成、卡片结束和消息成功送达是不同状态。需要判断实际结果时,结合后台任务状态和渠道日志;不要仅凭最后一张卡片推断所有工作都已成功。