判断 WorkSwarm 能不能把这条多步流程接过去，先别问它够不够聪明，先问一件事：交给它跑完之后，你被打断了几次，每次打断是不是都落在真正需要人判断的地方。如果一次完整流程里人被叫回来五趟，其中三趟只是确认某个格式对不对、某条数据有没有拉全，那说明确认点设错了位置，不是 WorkSwarm 推进得不好。反过来，如果流程一路跑完你都没被叫，最后看到结果才发现方向偏了，那是确认点设得太少或者太靠后。可用的做法是先按“产出结论的节点”决定人工介入密度，跑一次完整流程统计实际被打断的次数，再反过来调整确认点，把人工守的位置收敛到不可逆、不可自检的那几个。
WorkSwarm 适合连续推进多步任务，但人工确认点不宜凭感觉设。建议先列出流程里所有产出结论的节点，逐个标注产出的是草稿、待选项还是终稿；再按“判对错的依据是否存在、错了能否回退”分成可自检与需人看两类，只人为需人看的节点写清查看项；随后跑一次完整流程，记录每次打断发生在哪个节点、等待和处理各花了多久；最后按实际打断次数合并或下沉确认点。边界：涉及对外发布、不可逆写入的节点，即使打断频繁也应保留人工确认。
列出这条流程里所有会产出结论的节点
先不要列“执行步骤”，只列“产出结论的节点”。判断标准很直接：这一步结束时会生成一个东西，而这个东西会影响后面步骤往哪走。中间的数据拉取、格式转换、重试这类步骤通常不算，除非它本身会产出一个需要定稿的结果。
每个节点都要写清产出的是一份草稿、一个待选项还是一份终稿。草稿是还需要改写的中间产物；待选项意味着这里存在多条都说得通的路，需要人来选一条；终稿是这一步定下来就不再回头改、后面步骤直接依赖它。三类混在一起写，后面就没法判断该不该打断人。
# gates.yaml —— 只声明会产出结论的节点，执行步骤不写在这里
# 初始 human 一律标 unknown，等跑完一次完整流程再回填
gates:
- id: topic_outline
output: draft # 大纲草稿，可能被改写
human: unknown
- id: source_pick
output: options # 选哪几个信息源，多条路都可行
human: unknown
- id: report_body
output: draft # 正文草稿
human: unknown
- id: publish
output: final # 对外发布，不可逆
human: required # 这类先固定保留，不在优化范围内写完之后检查一遍：如果某个节点的产出既不影响后续分支、也不会被人拿去做决定，那它大概率只是过程日志，不属于确认节点。
把结论节点分成可自检和需人看两类
分类只看两条依据，不要引入主观重要性判断。第一条：判对错的依据是否存在。如果这一步的正确性可以用一个规则、一个 schema、一段断言或者一条已有记录来核对，那它可自检；如果“对不对”本身取决于人的偏好、口径或者业务取舍，那它需人看。第二条：错了能不能回退。如果错了只影响后面几步、重跑一次就能覆盖，代价可控；如果错了会写到外部、发出去、删掉数据，那就接近不可逆。
两条合起来用：依据存在且可回退，归到可自检，交给 WorkSwarm 自己校验，最多记一条日志；依据不存在或不可回退，归到需人看。注意这两条不是“重要性”排序，一个节点业务上很重要，但只要能机器校验、错了能重跑，就没必要打断人。
可自检：schema 校验 / 字段完整性 / 格式规范 / 重复检测 / 可重跑的草稿
需人看：口径选择 / 多方案取舍 / 对外发布 / 不可逆写入 / 依赖业务上下文为需人看的节点写好确认时要看的三样东西
需人看的节点，每次打断都要能一次看完，否则人得自己回去翻上下文，处理时长会被拖长。每个节点固定给三样：待确认草稿、判断依据、可选项及各自后果。
- 待确认草稿：把这一步真正产出的内容原样放上来，不要只给一句“已完成，请确认”。草稿要能直接读，不要让人再点开链接或翻日志找。
- 判断依据：写清这一步是基于什么做的决定，比如用了哪几条输入、套了什么口径、跳过了哪些备选。依据要具体到可核对，不要写“综合判断”。
- 可选项及后果：待选项类节点列出两条到三条路，每条后面写明选了会怎样，比如选 A 会沿用上一轮的结论、选 B 会重跑下游两步。没有后果说明的选项等于没给。
可以用一个消息模板固定这三段，让 WorkSwarm 在需要人看的节点上按模板发起确认，这样每次打断的格式一致，也不会漏项。
【节点】source_pick
【待确认草稿】本轮拟采用 3 个信息源：A / B / C
【判断依据】命中关键词，且近两周有更新
【可选项】
1) 确认这 3 个 —— 下游按现状继续，不重跑
2) 换成 A / B / D —— 需重跑取数一步
3) 只保留 A —— 范围收窄，结论覆盖面变小跑一次完整流程并记录人工被打断的次数
确认点写完后不要直接下结论，先完整跑一遍，把实际打断记录下来。记录两项就够：这次打断发生在哪个节点、从人到场到处理完花了多久。等待时长和处理时长建议分开记，等待久说明确认点设得太密或者时机不对，处理久说明给的信息不够、需要补查看项。
如果 WorkSwarm 的确认过程会写日志，可以直接筛出来；日志字段名以实际配置为准，这里只是筛选思路。
# 假设确认发起和恢复各写一条日志，字段里带 gate id
grep -nE 'gate_(request|resume)' swarm.log
# 想只看某个节点的打断
# grep -n 'gate_request' swarm.log | grep source_pick把结果整理成一张简单记录，节点名、打断次数、每次处理时长各自记实。跑完之后看两件事：哪些节点重复被打断，哪些节点一次都没打断但当时标了需人看。
节点 打断次数 处理时长(逐个记)
topic_outline 1 短
source_pick 2 中等 / 中等
report_body 3 短 / 短 / 中等
publish 1 中等按打断次数调整确认点密度
拿着记录做收敛，目标是把介入密度压到你能接受的水平，而不是把确认点全砍掉。改法按情况分三种。
- 合并：同一个节点反复打断，通常是一次只给一部分信息，人看完又得再来一次。改法是把同一节点同一阶段的草稿攒成一批再看，比如 report_body 把三处待改点一次性列全，确认一次而不是三次。
- 下沉：如果某个上游节点的结论其实由下游节点决定，那确认点应该往下游挪。比如 source_pick 反复被打断，往往是因为选择标准要等正文结构出来才清楚，那就把它并到 report_body 的确认里，在正文草稿旁边标注用了哪些源。
- 降级为自检：如果某个需人看的节点实际每次都是直接确认、从没改过，说明它有可核对的依据，可以改成自检并写一条断言，只在断言失败时才打断人。
改动落到配置上就是改 human 字段和批处理范围，比如把 report_body 从逐段确认改成整篇确认一次，把 source_pick 从独立确认改为并入下游。改完再跑一次完整流程，重新记录打断次数和处理时长，和上一轮对比。这个过程通常要来回一两轮才能稳定；publish 这类不可逆节点不参与合并和降级，保留人工守。