把 15 个 Skills 变成可验收的 Agent

Sat, 17 Oct 2026 00:00:00 +0000

装好 15 个 Skills，就等于有了一个可靠的 Data Agent 吗？

还差最关键的一步：把“会做什么”变成“怎样证明已经做好”。

这一篇不是新的官方 Skill，而是基于前 9 期原文整理的产品化方法。文中提到的任务协议、验收链和陷阱清单都是编辑整理的框架，不是原文定义的统一规范。

别把 Skill 数量当成系统成熟度

工作流需要按任务选择：补背景、定指标、诊断变化、检查质量、组织计算、表达或发布。

不是每次都串行跑一遍，也不是 15 个文档就代表 15 个独立 Agent。原文的口径一直很明确：主 Skill 只有一个，支持 Skill 按需加入，由主 Skill 决定什么算完成。

真正重要的是交接：前一步交给后一步什么证据？来源缺失时停在哪里？完成条件由谁核验？

这三个问题，正好对应下文的协议、工作链和验收链。

建议至少写清六项：

以“解释留存变化”为例：

六项写全之后，一个任务的“完成”就不再依赖模型的自我判断。

分析负责形成判断，验证负责检查判断有没有超出证据。

两条链并行推进，而不是串联：在工作链里，Metric Diagnostics 形成解释；在验收链里，Validate Data 检查这个解释的方法、数字和措辞。

高风险结论应当复算数字、核对口径、检查比较基线与表达边界，而不是让模型再润色一遍。润色只会让措辞更自信，不会让证据更充分。

可复用的语义层值得保存，但当前分析的临时背景不必全部写入。维护动作和任务分析要保持边界，否则语义层会被一次性上下文污染，反而降低可靠性。

这是最实用的一部分：与其问 Agent “你会不会”，不如设计具体的失败场景。