SuperAPI AI 工具集

refining-workflows-from-artifacts

智能体与模型

查看项目

更新于 10-15 10:16

技能介绍

用途

本技能用于基于一次真实执行结果来改进可复用的智能体工作流。它明确区分:不要用它改进产物本身,而要用它改进产出该产物的工作流。目标是通过一次小规模、有证据支撑的工作流改动,让下一次运行更可靠。

何时使用

  • 某个工作流、提示词、技能或智能体流程已被应用到真实任务
  • 存在可检查的产物、评审、测试结果、模拟结果或人工关切
  • 预期类似任务会重复出现

何时不使用

  • 产物没有可改进的关联工作流
  • 问题明显是一次性任务问题,没有复发风险
  • 目标是使用子智能体分派进行经验性提示词准确度评估(应改用 empirical-prompt-tuning)
  • 目标是从已完成项目中提取可复用知识(应改用 extracting-agent-skills)

所需输入

按可用情况使用:

  1. 当前工作流或技能
  2. 所使用的任务、种子或输入
  3. 产出的产物
  4. 评审、测试结果、模拟结果或人工关切
  5. 类似任务是否会重复出现

若输入不完整,应在明确不确定性的前提下继续。把缺失证据视为评估局限,而不是工作流失败的证明。

核心原则

不要把每一次产物失败都当作工作流失败。先对原因进行分类。通常只有工作流导致(C)、评估导致(D)和输出格式导致(F)的问题才应产生工作流改动。对于能力边界导致(E)的问题,应增加人工评审点、工具需求、原型测试或观察标准,而不是假装智能体能够验证它。

角色执行模型

四个角色为:成功提取者、失败分类者、工作流差异编辑者、删除评审者。

对于小型、局部的工作流修复,可将它们作为单次执行运行。子智能体可用本身并不构成分派它们的理由。当出现以下任一情况时,应把角色拆分为独立评审者(独立子智能体,或在子智能体不可用时使用隔离的顺序执行):

  • 改动影响多个工作流或技能
  • 评估标准本身存在争议
  • 错误修复的撤销成本很高
  • 独立性会实质性提升结论可信度

无论哪种模式,失败分类者必须先于工作流差异编辑者完成原因分类。对于 A(任务导致)或 B(执行导致)问题,工作流差异编辑者不得改动工作流,除非同一问题在多次运行中复发。

原因分类

将每个重要问题归为以下之一:

  • A. 任务导致:输入含糊、过量、矛盾或不可测试。
  • B. 执行导致:工作流已说明该做什么,但智能体未遵循。
  • C. 工作流导致:工作流缺少必要步骤、标准、输出字段或修复规则。
  • D. 评估导致:成功或失败标准不清晰。
  • E. 能力边界导致:验证需要工具、原型、人工测试或外部数据。
  • F. 输出格式导致:结果存在,但难以检查、复用、比较或审计。
  • G. 过度约束导致:工作流过于严格,损害了新颖性、灵活性或有用性。

若不确定,保守地归为 D 或 E。不要基于薄弱证据添加工作流规则。

流程

  1. 用 1–3 句话总结当前工作流的预期用途。
  2. 找出 1–3 件有效的事情。
  3. 找出最重要的问题(无硬性上限,按影响排序)。
  4. 对每个问题按原因分类(A–G)。对每个 C 或 F:(a) 该问题是否在多次运行中出现——若仅一次,除非结构性缺口明确无疑,否则优先标记为“仅在复发时处理”;(b) 该问题在同一工作流中换一个产物是否也会出现——若它依赖产物特定特征,优先归为 B 而非 C。
  5. 只修订 C、D、F 问题。A、B、E、G 问题除非复发,否则保留。
  6. 提出最小可用的工作流差异(一次一个主题)。
  7. 说明每个差异可能带来的副作用。
  8. 至少提出一个删除候选。
  9. 为下一次运行留下 1–3 个验证点。

修订优先级

按以下顺序应用改动:

  1. 修复输出格式
  2. 澄清检查标准
  3. 改变执行顺序
  4. 缩短输入格式
  5. 添加修复规则
  6. 拆分角色
  7. 添加约束
  8. 添加人工或外部工具介入点

约束是较晚的补救手段。许多失败来自输出形态不佳或缺少原因分类,而不是规则太少。

删除规则

每次改进必须至少提出一个删除候选:

  • 未使用的步骤
  • 重复的检查
  • 未帮助判断的输出字段
  • 只产出文字的角色
  • 削弱了产物的约束
  • 未被使用的长段落

若删除有风险,标记为“下次运行观察”,而不是立即删除。若所有候选都被推迟,应明确说明本次为何没有实际删除。

能力边界

较易验证:格式合规、缺失字段、显式矛盾、未解决的术语定义、简单策略比较、测试用例覆盖、重复的输出失败。

较难验证:趣味性、品味、手感、美感、节奏、说服力、品牌契合度、人类满意度。

对于难以验证的品质,不要假装确定。应改为增加人工评审点、原型测试、样本比较或观察标准。

反模式

  • 把每一次产物失败都当作工作流失败,然后添加约束
  • 每次运行都重写整个工作流
  • 只扩展检查清单而不删除任何内容
  • 让不可验证的品质看起来已被验证
  • 隐藏不确定性
  • 把紧凑的工作流变成官僚流程

输出

输出时加载 references/improvement-log-template.md。保持改动小、可逆,并能在下一次运行中测试。

配套技能

  • empirical-prompt-tuning:使用子智能体分派对技能进行经验性准确度测量;当你想跨场景测量成功率时使用
  • extracting-agent-skills:从已完成或已放弃的项目中提取可复用技能