| name | funasr-task-manager-local-batch-transcribe |
| description | Scan server-local directories for audio/video files, batch-submit them for transcription, monitor progress with proactive feedback, archive results, and handle retries. Use when: user requests batch transcription of local files, mentions scanning directories, inbox, or wants to retry failed items.
|
适配项目版本：V0.4.28-Build0476-20260518
服务器本地文件批量转写
funasr-task-manager-local-batch-transcribe 是面向服务器本地文件的批量转写自动执行规程。它把"发现文件 → 预检查 → 批量提交 → 委托监控 → 结果归档 → 失败重试"固化为 Phase 0-7，智能体拿到触发词即可自主走完整个流程。
异步调度架构：本 Skill 采用"主 Agent 调度 + 子 Agent 监控播报"模式。主 Agent 负责 Phase 0-4（扫描/预检/提交），完成提交后立即委托子 Agent 执行 batch-monitor Skill 进行进度监控和结果下载（Phase 5-6），自身释放以继续接收新任务。架构要点如下：
- 职责分离：主 Agent 控制扫描、预检、提交全流程；子 Agent 仅做"定期查询 + 播报 + 下载结果"，不参与意图理解和任务创建。
- 委托协议：主 Agent 通过
sessions_spawn（OpenClaw）或等效 API 启动子 Agent，传递 task_group_ids、batch_id、notification_context 等参数。
- Watchdog 机制：主 Agent 维护
batch_watchdog 状态表，在被动（收到用户消息）或空闲时检查子 Agent 存活性，超时或失联时接管监控。
- Fallback：当运行环境无子 Agent 能力（Cursor/Claude Code/Codex 等）或子 Agent 启动失败时，主 Agent 自行轮询。
执行检查清单（强制）
实时通知规范：本 Skill 的所有用户通知必须遵循 6-skills/_shared/CHANNEL-NOTIFICATION.md。禁止用普通文本替代 send_user_notice()。
强制规则：Agent 在执行本 Skill 流程时，必须逐条通过 send_user_notice() 确认以下通知已送达。禁止静默执行整个批量流程。禁止把阶段通知仅写入普通 assistant 文本回复。
| # | 检查项 | 时机 | 模板引用 | send_user_notice() 后再执行 |
|---|
| 1 | 启动通知 | Phase 1 开始 | progress-templates.md §1 | 目录扫描 |
| 2 | 扫描结果通知 | Phase 2 完成 | progress-templates.md §2 | 预检查 |
| 3 | 预估耗时通知 | Phase 3 完成 | progress-templates.md §2 | 批量提交 |
| 4 | 提交确认 | Phase 4 每 chunk 完成 | progress-templates.md §3 | 下一 chunk / 监控 |
| 5 | 定期进度更新 | Phase 5 每 30s 或每 5 个完成 | progress-templates.md §4 | 继续轮询 |
| 6 | 异常即时通知 | 任何阶段出错 | progress-templates.md §5 | 错误处理 |
| 7 | 完成汇总通知 | Phase 6 完成 | progress-templates.md §6 | 归档/退出 |
send_user_notice() 调用方式
OpenClaw 环境（首选）：
{"name": "message", "arguments": {"action": "send", "message": "我将扫描 runtime/agent-local-batch/inbox/ 中的待转写文件..."}}
CLI fallback（无 message tool 时）：
python -m cli notify send --text "我将扫描 runtime/agent-local-batch/inbox/ 中的待转写文件..." --chat-id "<chat_id>" --reply-to "<reply_to_id>"
python -m cli notify send --text "我将扫描 runtime/agent-local-batch/inbox/ 中的待转写文件..." --receive-id-type open_id --chat-id "<open_id>"
时序要求：每条通知必须在对应耗时操作之前发送并等待返回成功，然后再执行扫描/提交/轮询等操作。
2026-05-05 排查结论：批量转写 session c6105436 中 Agent 有 message tool 可用但未调用，14:14 发出的指令到 14:25 才集中收到所有中间通知。根因是 Agent 只输出普通文本，被 OpenClaw 飞书 bridge 在 turn 结束后统一推送。修复方案：每个通知点必须显式调用 send_user_notice()。
触发条件
自动触发
- 用户要求批量转写服务器本地文件
- 用户要求扫描本地目录、待处理目录、inbox 或 workdir
- 用户要求继续上次批量转写
- 用户要求重试失败项
关键词
本地批量转写 / 服务器本地文件 / 扫描目录 / 待处理目录 / inbox / 批量识别 / 继续跑 / 重试失败 / local batch transcribe
不触发
- 用户在聊天中发送单个音视频文件（→
channel-intake）
- 用户要求 benchmark 或服务器管理
- 纯文本闲聊
核心执行流程
Phase 0：运行上下文检查
0a. 通知能力预检 + 路由验证（强制）
在进入业务逻辑前，先检测通知能力并验证路由：
- 检查
message tool 是否在工具列表中。
- 执行
python -m cli notify auth-check --channel feishu，检查退出码。
- 从 runtime context 提取
notification_context（chat_id、open_id、is_group_chat 等）。
- 路由验证（首条通知）：Phase 1 启动通知即为路由验证探针。发送后检查
message tool 返回的 chatId：
- 匹配预期目标 → 继续使用
message tool
- 不匹配 → 立即标记
route_locked_to_cli = true，通过 CLI notify 携带显式路由参数向正确目标重发同一条消息，后续全部走 CLI
- 验证规则详见
NOTICE-PRIMITIVE.md §路由验证机制
预检输出：
notification_precheck:
message_tool_available: true/false
cli_notify_available: true/false
is_group_chat: true/false
adapter_priority: ["message", "cli_notify"] / ["cli_notify"] / ["assistant_text"]
notice_capable: true/false
route_locked_to_cli: false # 首条通知后可能变为 true
expected_chat_id: oc_xxx / ou_xxx # 用于路由验证的预期目标
- 两者都不可用时：继续执行业务，但最终报告标注"⚠ 实时通知不可用"。
- 子 Agent 委托决策：如果
notice_capable == false，Phase 5 不启动子 Agent 监控播报，主 Agent 自行轮询。
- 路由锁定传递：如果主 Agent 的路由验证触发了 CLI 锁定，Phase 5 委托子 Agent 时应在
notification_context 中额外传递 prefer_cli_notify: true，提示子 Agent 跳过 message tool 直接使用 CLI。
0b. 仓库与后端检查
- 确认当前目录是
funasr-task-manager 仓库（存在 3-dev/src/backend/app/main.py）。
- 检查后端健康状态：
curl -sf http://127.0.0.1:15797/health
- 后端不可达时，先进入
funasr-task-manager-init 启动流程。
- 确认
runtime/agent-local-batch/ 目录存在；不存在则幂等创建全部子目录。
- 检查是否有未完成的批次（扫描
manifests/ 目录中 status 为 INTERRUPTED/SUBMITTING/MONITORING 的文件），如有则提示用户是否恢复。
- 执行 stale monitor 清理（见 Phase 0c），避免上一轮子 Agent 残留影响本轮。
0c. stale monitor 清理（强制）
在每次新批量开始前，主 Agent 必须扫描：
runtime/agent-local-batch/monitors/*.json
每个 monitor state 至少包含：
{
"batch_id": "round-10",
"task_group_ids": ["01..."],
"child_session_key": "batch-monitor-round-10",
"status": "running",
"spawn_time": "2026-05-17T14:30:00+08:00",
"last_notice_at": "2026-05-17T14:35:00+08:00",
"completed_at": null
}
清理规则：
- 对 state 中每个
task_group_id 执行 python -m cli --output json task-group status {group_id}。
- 若所有 group 均为
is_complete == true（或 succeeded + failed + canceled == total），将 monitor state 更新为 completed，写入 completed_at，移动到 runtime/agent-local-batch/archive/monitors/。
- 若平台提供
sessions_list / sessions_close / sessions_cancel，且能找到 child_session_key 对应的子 Agent，会话仍在运行时必须关闭它。
- 若 group 仍未完成，但子 Agent 不存在或已退出，主 Agent 应接管监控或重新委托
batch-monitor。
- 若只发现 monitor state、但对应 group 已全部成功，禁止继续沿用旧 monitor；直接归档并开始本轮新批次。
0d. 批量/压测独占窗口检查（强制）
本项目只能调度经由 task-manager API 创建的任务；如果其他机器绕过本系统直接请求 FunASR 10095 / 10096 / 10097，后端无法让这些外部请求排队，只能看到本轮实际 RTF 变慢。为了得到可复现的批量测试结果，执行 round/benchmark 类批量测试前必须：
- 通过
python -m cli --output json admin active-slots 确认 task-manager 内部无其它活跃任务；若有，等待或取消后再提交。
- 创建独占窗口 state：
runtime/agent-local-batch/locks/asr-exclusive-{batch_id}.json
内容包括 batch_id、owner、reason、server_ids、created_at、status=active。
3. Agent 管理的其它入口（channel-intake / 本地批量恢复 / benchmark）发现 active exclusive lock 时，默认等待，不再提交新任务；除非用户明确要求抢占或急停。
4. 直连 FunASR 的外部服务必须通过运维手段解决：将 10095-10097 仅暴露给 task-manager 或统一网关，其他调用方改走 task-manager API，由本系统排队。单靠本 Skill 不能拦截绕过网关的直连请求。
5. Phase 6 收尾时必须释放该 lock；异常退出时下一轮 Phase 0 按 task_group status 校验，若对应批次已终态则自动释放 stale lock。
Phase 1：确定扫描来源
优先级：
- 用户本轮明确指定的目录或文件列表。
- 用户指定的上次批次 ID（恢复模式）。
- 默认固定扫描目录
runtime/agent-local-batch/inbox/。
如果默认扫描目录为空，直接反馈后退出：
未发现待转写文件。请把音视频文件放入 runtime/agent-local-batch/inbox/，或告诉我具体目录。
Phase 2：扫描与建清单
扫描规则：
| 项 | 规则 |
|---|
| 递归 | 默认递归扫描子目录 |
| 支持格式 | .wav .mp3 .mp4 .flac .ogg .webm .m4a .aac .wma .mkv .avi .mov .pcm |
| 跳过隐藏文件 | 跳过以 . 开头的文件和系统临时文件（Thumbs.db、.DS_Store） |
| 跳过未完成文件 | 文件大小为 0 或 mtime 在 10 秒内变化时暂不提交 |
| 本地去重依据 | 文件名 + 文件大小(bytes) + mtime(unix timestamp)，拼接为 {name}-{size}-{mtime_int} |
| 已完成跳过 | 同目录下最近 manifest 中标记 SUCCEEDED 且指纹未变化时跳过 |
后端 task-group submit 还会启用 30 分钟活跃批次去重，依据为同一用户下的文件名、大小、语言、热词/选项和 segment_level。检测到重复时 CLI 返回已有 task_group_id，Agent 应当进入监控复用流程，而不是再次提交。
创建批次清单：
runtime/agent-local-batch/manifests/local-YYYYMMDD-HHMMSS.json
清单格式详见 references/manifest-schema.json。
此阶段完成后必须向用户反馈扫描结果。
Phase 3：媒体预检查
对每个候选文件执行 funasr-task-manager-media-preflight 逻辑：
- 验证文件存在、大小 > 0、扩展名在支持列表中。
- 使用
ffprobe 获取时长、编码、采样率、声道数。
- 标记是否需要转码（非 wav/pcm 格式）。
- 累计总音频时长。
预检查失败的文件状态设为 FAILED_PRECHECK，写入错误原因，不提交。
估算总耗时：
estimated_wall_clock = total_audio_duration_sec * rtf / num_online_servers / avg_concurrency
RTF 优先从 GET /api/v1/stats 获取 avg_rtf 字段；无数据时使用默认值 0.1。
此阶段完成后向用户反馈预估耗时（见 progress-templates §2）。
Phase 4：批量提交（使用 task-group 短命令）
设计原则
使用 task-group 短命令序列，每条命令秒级返回，主 Agent 在每步之间保持控制权，可以调用 send_user_notice() 发送通知。
Step 4a：扫描（如果 Phase 2 未使用 CLI）
工作目录：3-dev/src/backend
python -m cli --output json task-group scan {source_dir} --chunk-size 50
返回 JSON 包含 items（文件清单）和 chunks（分块信息）。如果 Phase 2 已手动扫描并创建了 manifest，可跳过此步，直接使用已有 manifest。
将扫描结果保存为 manifest 文件：
python -m cli --output json task-group scan {source_dir} --chunk-size 50 > runtime/agent-local-batch/manifests/{batch_id}.json
Step 4b：提交
python -m cli --output json task-group submit \
--manifest runtime/agent-local-batch/manifests/{batch_id}.json \
--language auto \
--segment-level 10m
返回 JSON 包含每个 chunk 的 task_group_id。
默认去重行为：
- 30 分钟内同一用户、相同文件集和相同识别参数仍有活跃批次时，CLI 会返回已有
task_group_id，total_deduplicated > 0，退出码仍为 0。
- 确认需要重新创建独立批次时，追加
--force。
- 如果 submit 命令异常退出、输出损坏或 JSON 解析失败，禁止直接重试。必须先查询近 30 分钟任务组或后端日志确认是否已经创建批次；找到了就复用并监控，确认未创建后再重试。
分 chunk 提交（大批量场景）：
python -m cli --output json task-group submit \
--manifest runtime/agent-local-batch/manifests/{batch_id}.json \
--chunk 0
逐个 chunk 提交，每个 chunk 提交后通过 send_user_notice() 反馈（见 progress-templates §3）。
分块策略
| 文件数 | 策略 |
|---|
| 1-50 | 单次 submit 全部提交 |
| 51-300 | 逐 chunk submit，每次通知 |
| 300+ | 同上，但提交前必须向用户确认 |
Step 4c：记录 task_group_ids
从 submit 返回的 JSON 中提取所有 task_group_id，传递给下一步。
Phase 5：委托子 Agent 监控（异步调度核心）
关键变更：主 Agent 在此阶段不再自己轮询，而是委托子 Agent 执行 batch-monitor Skill。
委托前提检查
主 Agent 在委托前必须检查以下条件，任一不满足则不启动子 Agent 监控播报，直接 fallback 到主 Agent 自行轮询：
- 通知预检结果：Phase 0a 的
notice_capable == true（至少有一种通知通道可用）。
- 子 Agent 启动能力可用：工具列表中包含
sessions_spawn（OpenClaw）或 spawn_agent（Codex）等子 Agent 启动工具。
- 子 Agent 有消息工具：
message tool 需显式配置子 Agent 工具策略（tools.subagents.tools.allow '["message"]'），不自动继承；cli notify 可通过 exec 工具调用，子 Agent 自然继承此能力。
如果子 Agent 启动后发现自身 message tool 和 cli notify 都不可用，子 Agent 应立即报告失败并退出（见 batch-monitor Step 0）。
委托协议
主 Agent 发送以下委托消息启动子 Agent（通过 sessions_spawn）：
请执行 batch-monitor 监控任务：
- task_group_ids: ["{group_id_1}", "{group_id_2}", ...]
- batch_id: {batch_id}
- total_files: {total_files}
- poll_interval_sec: 30
- timeout_sec: 3600
- result_format: txt
- output_dir: runtime/agent-local-batch/outputs/{batch_id}
- notification_context:
chat_id: {chat_id} # oc_xxx（群聊）
open_id: {open_id} # ou_xxx（私聊，可选）
message_id: {message_id} # om_xxx（触发消息 ID）
reply_to_id: {reply_to_id} # om_xxx（回复目标，可选）
sender_id: {sender_id} # ou_xxx（发送者 ID，用于 @ 提及）
is_group_chat: {true/false}
- notification_policy:
at_user_on_error: {true/false} # 异常时 @ 触发用户（群聊 true，私聊 false）
at_user_on_complete: {true/false}
reply_to_thread: {true/false} # 优先回复原消息线程
template_variant: "group" / "dm" # 群聊 / 私聊模板
启动方式：主 Agent 调用 sessions_spawn 启动子 Agent：
{"name": "sessions_spawn", "arguments": {"task": "请执行 batch-monitor 监控任务：...", "label": "batch-monitor-{batch_id}"}}
委托后主 Agent 的行为
- 发送委托通知：通过
send_user_notice() 告知用户"已启动后台监控"。
- 记录监控状态：写入
runtime/agent-local-batch/monitors/{batch_id}.json，内容为 batch_id -> {task_group_ids, spawn_time, last_notice_at: null, child_session_key, status: "spawned"}。
- 等待启动确认（ack）：使用
sessions_yield 等待子 Agent 的启动确认事件，或设 5 秒超时。
- 5 秒内收到 ack：释放控制权，继续接新任务。
- 5 秒无 ack：fallback 到主 Agent 自行轮询（见下方 Fallback）。
子 Agent 负责的工作
子 Agent 按 funasr-task-manager-batch-monitor Skill 执行：
- 工具权限自检：检查
message tool 和 cli notify 可用性，两者都不可用则立即报告失败退出
- 发送启动确认（ack）
- 定期查询
task-group status
- 通过
send_user_notice() 发送进度通知（每条记录 adapter、message_id、delivered）
- 异常和完成时 @ 触发用户（群聊）/ 不 @（私聊）
- 全部完成后执行
task-group download 下载结果
- 发送完成汇总通知
- 退出
Fallback：无子 Agent 能力时
以下任一条件成立时，主 Agent 回退到自行轮询模式：
- 运行环境无子 Agent 启动能力（如 Cursor / Claude Code 等无
sessions_spawn 或 spawn_agent）
- Phase 0a 预检
notice_capable == false（子 Agent 没有消息工具，无法播报）
- 子 Agent 启动后 5 秒无 ack
- 子 Agent 报告"消息工具不可用"并退出
while not all_groups_complete:
for each group_id:
python -m cli --output json task-group status {group_id}
if progress_changed or elapsed > 30s:
send_user_notice(进度通知)
sleep 30
Phase 5.5：Watchdog 监控（主 Agent 职责）
子 Agent 委托成功后，主 Agent 不主动轮询，但需维护 Watchdog 状态以防子 Agent 静默失联。
监控状态表
主 Agent 维护以下状态，用于检测子 Agent 是否仍在正常播报：
{
"batch_watchdog": {
"{batch_id}": {
"spawn_time": "2026-05-07T15:30:00Z",
"last_notice_at": null,
"child_session_key": "batch-monitor-{batch_id}",
"ack_received": false,
"status": "spawned"
}
}
}
| 字段 | 说明 |
|---|
spawn_time | 子 Agent 启动时间 |
last_notice_at | 最近一次收到子 Agent 通知的时间（初始为 null） |
child_session_key | 子 Agent 的 session label，用于 sessions_list 查询 |
ack_received | 是否收到启动确认 |
status | spawned → acked → running → completed / failed / timeout |
Watchdog 检查逻辑
主 Agent 在以下时机检查 Watchdog 状态：
- 收到用户新消息时（被动触发）：顺便检查 watchdog。
- 当前无其他任务时（空闲触发）：主动检查 watchdog。
for each batch_id in batch_watchdog:
wd = batch_watchdog[batch_id]
# 场景 A：启动后一直无通知
if wd.status == "spawned" and now() - wd.spawn_time > 60s:
# 子 Agent 可能已失败，主动查询
sessions_list → 找到 child_session_key → 检查状态
if child_exited or child_not_found:
send_user_notice("⚠️ 批次 {batch_id} 的后台监控可能已中断，正在接管...")
fallback 到主 Agent 自行轮询
# 场景 B：曾有通知但长时间无更新（2 个轮询周期）
if wd.last_notice_at and now() - wd.last_notice_at > poll_interval_sec * 2:
# 检查子 Agent 是否还活着
sessions_list → 找到 child_session_key
if child_exited:
# 子 Agent 退出但没发完成通知
send_user_notice("⚠️ 批次 {batch_id} 的监控已结束，正在检查结果...")
检查 task-group status → 补发完成/异常汇总
elif child_running:
# 子 Agent 还在但不发通知了，可能通知通道有问题
记录 warning，继续等待
# 场景 C：任务超时
if now() - wd.spawn_time > timeout_sec * 1.2:
send_user_notice("⚠️ 批次 {batch_id} 超时（已超过子 Agent 设定上限的 120%），检查状态中...")
检查 task-group status → 补发汇总
补发逻辑
| 场景 | 主 Agent 动作 |
|---|
| 子 Agent 已退出但未发完成通知 | 查询 task-group status，补发完成/异常汇总 |
| 子 Agent 已退出但结果未下载 | 执行 task-group download，补发结果 |
| 子 Agent 异常退出 | send_user_notice("⚠️ 批次 {batch_id} 的后台监控异常中断。当前进度：{status_summary}。你可以说\"重启监控\"来恢复。") |
| 全部完成但无汇总 | 补发完成汇总（使用 progress-templates 模板） |
补发或确认完成后，必须执行 monitor 收尾：更新 runtime/agent-local-batch/monitors/{batch_id}.json 为 completed，移动到 runtime/agent-local-batch/archive/monitors/；若存在 asr-exclusive-{batch_id}.json，也更新为 released 并归档。
Phase 5.6：用户主动取消/中止批次
当用户明确要求"取消 / 停止 / 中止"正在运行的批次时，Agent 必须走取消流程，不能只终止监控子 Agent，也不能只停止心跳播报。
取消步骤
- 先通过
send_user_notice() 告知用户将取消哪个 batch_id / task_group_id。
- 查询批次内任务列表：
python -m cli --output json task list --group {group_id} --page-size 500
- 对每个非终态任务执行取消：
python -m cli --output json task cancel {task_id}
- 取消后立即重新查询：
python -m cli --output json task-group status {group_id}
- 只有当
is_complete == true，或 succeeded + failed + canceled == total 时，才向用户报告"取消完成"。
- 如果仍有
in_progress > 0，必须报告"取消已提交但仍有活跃任务"，并继续每 10-30 秒检查，直到进入终态或超时。
segment 清理校验
后端取消接口必须释放分段任务的活跃 segment，包括 PENDING、DISPATCHED、TRANSCRIBING。Agent 侧取消后如发现某台服务器长期少 slot、某个 group 已取消但仍有 TRANSCRIBING segment，应按故障处理上报，不要反复新建批次掩盖问题。
必要时使用只读诊断确认是否存在僵尸 segment：
SELECT s.segment_id, s.task_id, s.status, s.assigned_server_id, t.status AS parent_status
FROM task_segments s
JOIN tasks t ON t.task_id = s.task_id
WHERE s.status IN ('DISPATCHED', 'TRANSCRIBING')
AND t.status IN ('CANCELED', 'FAILED', 'SUCCEEDED');
如果查询命中，说明后端取消/恢复流程存在 bug；Agent 应报告异常并请求人工确认后再做数据库修复。
Phase 6：结果归档（由子 Agent 或主 Agent 完成）
在异步模式下，结果下载由子 Agent 通过 task-group download 完成：
python -m cli --output json task-group download {group_id} \
--format txt \
--output-dir runtime/agent-local-batch/outputs/{batch_id}
在 fallback 模式下，主 Agent 自行执行上述命令。
归档目录结构：
runtime/agent-local-batch/outputs/<batch_id>/
├── {file1}_result.txt
├── {file2}_result.txt
├── ...
└── batch-summary.json # 自动生成
批次汇总文件必须满足项目规范（文件名以 -YYYYMMDD.md 结尾）。
此阶段完成后向用户反馈完成汇总（见 progress-templates §6 或 monitor-templates §5）。
Phase 6b：监控与独占窗口收尾（强制）
无论结果下载由子 Agent 还是主 Agent 完成，最终收尾必须执行：
- 查询所有
task_group_id，确认 is_complete == true 或 succeeded + failed + canceled == total。
- 将
runtime/agent-local-batch/monitors/{batch_id}.json 更新为 completed，写入 completed_at 和最终统计，然后移动到 runtime/agent-local-batch/archive/monitors/{batch_id}.json。
- 如果平台支持关闭子 Agent，会话仍运行时关闭
child_session_key。
- 将
runtime/agent-local-batch/locks/asr-exclusive-{batch_id}.json 更新为 released，写入 released_at，移动到 runtime/agent-local-batch/archive/locks/{batch_id}.json。
- 再次扫描
monitors/，若只剩已终态批次的 stale monitor，立即归档，不允许留给下一轮。
Phase 7：失败处理与重试
失败分类及处理：
| 状态 | 可自动重试 | 处理方式 |
|---|
FAILED_PRECHECK | 否 | 提示用户检查文件格式 |
FAILED_UPLOAD | 是（1 次） | 自动重试上传 |
FAILED_TRANSCRIBE | 需确认 | 询问用户是否重试 |
FAILED_DOWNLOAD | 是（1 次） | 自动重试下载 |
TIMEOUT | 需确认 | 查询后端状态后决定 |
用户说"重试失败项"时：
- 读取最近一个 manifest
- 筛选可重试状态的 items
- 创建新批次（ID 格式：
retry-of-<原batch_id>-YYYYMMDD-HHMMSS）
- 重新进入 Phase 4
不得覆盖原 manifest。
断点续传
当检测到 INTERRUPTED 状态的 manifest 时：
| 中断点 | 恢复动作 |
|---|
| 提交阶段 | 从 resume_from.last_submitted_index 继续提交 |
| 监控阶段 | 查询所有已提交 group 的最新状态，继续监控 |
| 下载阶段 | 补下载 output_path 为空的 SUCCEEDED 任务 |
与其他 Skill 的协作
| 协作场景 | Skill | 时机 | 交接数据 |
|---|
| 文件预检查 | funasr-task-manager-media-preflight | Phase 3 | 文件路径 → duration/format/warnings |
| 进度监控 | funasr-task-manager-batch-monitor | Phase 5 | task_group_ids + batch_id → 子 Agent 异步播报 |
| 结果格式化 | funasr-task-manager-result-delivery | Phase 6 | 可复用其 txt/srt/json 格式化规则 |
| 服务器性能 | funasr-task-manager-server-benchmark | Phase 3 | RTF baseline 用于耗时预估 |
| 渠道入口 | funasr-task-manager-channel-intake | Phase 5 | 让步检测 — intake 优先 |
| 环境初始化 | funasr-task-manager-init | Phase 0 | 后端不可达时触发 |
错误处理规范
| 错误场景 | Agent 应做的事 | 不应做的事 |
|---|
| 目录不存在 | 报告路径无效，询问正确路径 | 静默创建用户指定的外部目录 |
| 后端不可达 | 尝试启动后端，失败则通知用户 | 静默等待或反复重试 |
| 全部文件预检查失败 | 报告失败原因列表，建议操作 | 尝试强行提交 |
| CLI 命令执行失败 | 报告错误输出，建议排查 | 静默切换到 API 模式 |
| manifest 写入失败 | 报告权限问题 | 继续执行但不记录状态 |
| 后端返回 413 | 报告文件过大，告知大小限制 | 尝试压缩音频 |
安全与边界规则
- 默认不删除、不移动用户源文件。
- 不把大音视频文件复制到 Git 管理目录。
- 不把转写全文刷屏输出；长结果保存为文件并给出路径。
- 不在项目根目录生成散落文件。
- 失败重试必须创建新批次，不覆盖历史 manifest。
- manifest 只记录路径、状态、错误信息；敏感文件名按用户要求脱敏。
相关文件
references/manifest-schema.json：manifest JSON Schema 定义references/progress-templates.md：用户交互通知模板（Phase 0-4 由主 Agent 使用）references/platform-adapters.md：各平台进度监控实现差异6-skills/funasr-task-manager-batch-monitor/SKILL.md：子 Agent 监控播报规程（Phase 5-6）6-skills/funasr-task-manager-batch-monitor/references/monitor-templates.md：子 Agent 通知模板
