多 Agent Skill 编排要先管调度层：状态、失败和证据链

多 Agent 系统最容易被演示误导。单个 Skill 能跑、单个 Agent 会写代码，并不代表整条流水线可以稳定交付。进入真实项目后，问题通常出在调度层：任务什么时候开始、谁持有上下文、失败后怎么恢复、哪些输出能作为下一步输入、哪些权限不能被传递。

因此，评估 Skill 编排时，重点不应该是“接了多少工具”，而是调度器是否能把过程变成可审计的状态机。

• 任务 ID、输入版本、依赖关系和当前状态。
• 每一步调用的 Skill、工具、参数摘要和输出证据。
• 失败类型：模型失败、工具失败、权限失败、数据缺失还是用户约束冲突。
• 重试策略和人工接管点。
• 最终产物与中间证据之间的对应关系。

没有这些信息，多 Agent 编排很快会变成“看起来自动化，出了问题没人知道为什么”。尤其是内容发布、代码修改、数据处理和部署任务，单步成功不等于整体可信。

适合拆分的任务通常有清晰输入、可验证输出和稳定流程，例如抓取资料、生成草稿、运行测试、检查链接、部署 smoke。每个 Skill 都应该有边界：它能做什么、不能做什么、失败时输出什么证据。

不适合拆分的是模糊判断、需要持续用户沟通、或依赖隐含业务背景的任务。强行拆成多个 Agent，反而会增加上下文丢失和责任不清。

上线前至少验证四件事：第一，失败能不能重放；第二，权限是否最小化；第三，输出是否有证据链；第四，人工能不能在中间节点接管。做不到这四点，系统可以用来辅助，但不应该直接接生产发布、资金、用户数据或不可逆操作。