mcpField
S
self-learning-feedback

self-learning-feedback

github.com/proftraderAgent 工作流042 次安装35 周前更新
代码仓库

关于 self-learning-feedback

self-learning-feedback 是一种 Agent 技能，在任务完成后收集反馈并用于改进后续输出。它按任务上下文跟踪认可次数，并为需要改进的结果设置结构化迭代流程。

主要功能

  1. 01任务完成后触发反馈
  2. 02按上下文跟踪连续认可
  3. 03结构化改进问题
  4. 04按严重程度设置迭代上限
  5. 05改进请求后重置认可计数

适用场景

  1. 01收集单项任务完成后的反馈
  2. 02跟踪周期性 cron job 的质量信号
  3. 03根据改进请求调整后续输出

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/proftrader/openclaw-self-learning-skill --skill self-learning-feedback

安装后在 Claude Code 中输入/self-learning-feedback确认已加载。

附带文件reference.md

详细介绍

自我学习反馈

目的

使用此技能，在每项任务或定时任务完成后开展递归学习，且不打断用户流程。

默认值

  • GOOD_APPROVAL_TARGET = 10
  • SLIGHT_MAX_ITERATIONS = 5
  • MEDIUM_MAX_ITERATIONS = 10
  • SEVERE_MAX_ITERATIONS = 20

如果用户明确要求不同的阈值（例如 20 次认可），只更新 GOOD_APPROVAL_TARGET。

触发时机

在明确的完成节点后触发：

  • 一项独立任务已完成。
  • 一次定时任务已执行完毕并已回复。

根据请求识别任务类型／上下文（例如定时任务名称、报告类型、命令或目标），以便按范围正确统计认可次数和问题特征。

以下情况不要触发：

  • 任务进行到一半时。
  • 多步骤流程中尚未到达自然完成节点时。
  • 同一完成事件不得触发多次。

非干扰式反馈提示

任务完成后，发送一条简短的反馈提示：

任务已完成。效果好吗？还是需要改进？

提示控制在 1 到 3 行。

反馈分支

分支 A：用户表示“好”
  1. 在同一轮中询问：这次输出有哪些地方做得好？
  2. 记录用户的正面反馈（质量、格式、风格、速度、清晰度等）。
  3. 增加此任务类型／上下文的连续认可计数（例如同一定时任务、同一报告类型、同一命令）。如果用户在此前的任务中表示过“需要改进”，该上下文的计数已经重置；只有连续收到“好”的反馈，才能计入目标。
  4. 在同一任务类型的后续每次完成时重复此学习流程，直到计数达到 GOOD_APPROVAL_TARGET。
  5. 达到目标后，视为已掌握该模式并降低提示频率：
    • 仅在任务类型发生变化、质量下降或需要定期重新校准时询问“哪些地方做得好”。
  6. 重置计数：如果用户针对此任务类型／上下文表示“需要改进”，则将其认可计数重置为 0。之后的“好”反馈将重新开始累计连续次数，以达到目标。
分支 B：用户表示“需要改进”

先通过选择题收集信息，再进行开放式细化，开展结构化学习流程。

  1. 从以下三个维度收集改进意向：
    • 需要改进的原因。
    • 应如何改进。
    • 应调整哪些上下文或风格。
  2. 尽可能询问示例。
  3. 判断严重程度并设定迭代上限。
  4. 通过网络调研和迭代推理解决问题。
  5. 在下一次类似输出中应用改进。
  6. 任务完成后再次征求反馈。

选择题收集模板

如果可用，请使用 AskQuestion。

需要改进的原因

选项：

  • 结果有误或不完整
  • 格式或结构不合适
  • 速度太慢或效率太低
  • 语气或风格不合适
  • 缺少上下文或假设
  • 其他（由用户说明）
应如何改进

选项：

  • 增加细节／深度
  • 减少细节／更简洁
  • 调整结构／顺序
  • 更换方法／工具
  • 加强验证或检查
  • 其他（由用户说明）
应改进哪些上下文／风格

选项：

  • 代码风格／规范
  • 输出格式（Markdown、JSON、表格、散文）
  • 术语／领域语言
  • 长度／范围界限
  • 受众／语气预期
  • 其他（由用户说明）

然后询问：

如果你能提供期望的输出／风格示例，请分享一下。

严重程度指标与迭代控制

根据用户的为什么／如何／什么对问题进行分类（如果不清楚，则简短询问）：

  • 轻微：措辞／格式／风格方面的小调整 → 最多 5 次迭代
  • 中等：结构／深度／方法方面的修改 → 最多 10 次迭代
  • 严重：根本性问题或反复出现的问题 → 最多 20 次迭代

按问题特征（why + how + what + context）跟踪学习循环。一次迭代 = 一个完整周期：应用所学内容 → 提交修订后的输出 → 再次询问“可以吗，还是需要改进？”。如果用户随后回复“可以”，则该改进问题即告关闭（并适用该任务的肯定反馈流程）。如果用户针对同一问题再次回复“需要改进”，则计为下一次迭代。

  • 如果尚未达到上限：继续迭代优化（应用 → 再次征求反馈）。
  • 如果已达到上限：总结经验教训，停止针对该问题进行迭代，并继续正常征求反馈（后续任务完成后仍需询问“可以吗，还是需要改进？”）。

为什么—如何—什么的解决要求

实施改进时，始终说明：

  • 为什么需要此项更改。
  • 将如何进行更改（具体步骤）。
  • 适用的上下文／风格约束。

如果外部参考资料有助于提高准确性，请使用网络搜索。通过迭代思考来检验和完善假设。

UX 安全规则

  • 切勿反复发送反馈提示。
  • 切勿因征求反馈而中断用户当前的工作流程。
  • 提示应简洁且可预测。
  • 无需进行 UI 或产品更改；这只是对话行为层。

轻量输出模式

任务完成后：

  1. 完成说明。
  2. 一个反馈问题。
  3. 仅当用户选择“需要改进”时，才提供一个可选的后续内容块。

其他资源

评论

支持 Markdown