闭环的用户反馈是 Skills 进化的燃料

凌晨三点，你被告警叫醒。那个处理支付的 Skill 又出错了——不是代码逻辑的问题，而是合作方的接口字段从 transaction_id 悄悄改成了 pay_id。你手动改了 Skill 定义，重新部署，然后盯着监控看了一个小时。这已经是本月的第四次了。你清楚地知道：一个只能由开发者“被动修复”的 Skill，本质上是一个等待爆雷的黑盒。

真正健壮的 Agent 系统，需要把“用户使用 → 产生结果 → 用户反应 → 系统改进”这套链路打通，让每一次成功都值得复制，每一次失败都推动进化。这就是本章要解决的核心问题：如何为你的 Skills 建立一套闭环的反馈飞轮。

本章将带你从“靠直觉修 Bug”升级到“让数据驱动 Skills 自我优化”。我们将用三个递进的步骤，搭建起一个完全可落地的反馈系统：首先建立隐式与显式并存的信号采集层，然后让这些信号直接驱动提示词和定义的自动化微调，最后用实验框架为每一次改进负责。

准备就绪：

• 一个已部署并在使用的 Claude Skills 环境（基于 Claude Code 或自定义 SKILL.md）。
• 具备基础的数据采集能力（日志、埋点或 API 拦截层）。
• 预计完成时间：40 分钟（概念理解 10 分钟，实现规划 30 分钟）。

最终成果

完成本章后，你将构建起一套“观察-分析-进化”的闭环体系。你的 Skills 将从静态的指令文件，转变为一个能够感知用户行为、识别失败模式、并通过半自动流水线优化自身定义的生命体。具体来说，你将获得：

1. 一套多维度的反馈分类标准，能够区分“用户玩得很开心”和“用户无奈放弃了”。
2. 一条自动化分析管线，能够从成百上千条交互中聚类出最常见的失败根源。
3. 一个可控的实验发布框架，让每一次 Skill 的自我修改都经过数据验证，而非盲目上线。

这套飞轮的意义在于：将开发者的角色从“消防员”转变为“园艺师”——你不再需要盯着每一个冒烟的火点，而是专注于培养一个能自我修复和生长的系统。

第一步：构建隐式与显式并存的反馈织网

反馈是进化的燃料。但如果燃料的种类单一，引擎就无法全效运转。在 Agent 交互的语境下，反馈天然分为两种形态：

• 显式反馈：用户有意识地给出的评价。比如对话结束后的“👍/👎”、满意度打分、手动报错等。这是最直接、信噪比最高的信号。
• 隐式反馈：用户无意识行为中流露出的信号。比如停止生成、重新提问、复制结果后立刻修改、反复点击同一处，或是长时间悬停在某段输出上。这些信号量大、覆盖面广，但需要精密的解读。

单独依赖任何一方都是陷阱。只靠显式反馈，你会被沉默的大多数误导——一个 Skill 可能每天被调用一千次，但你只收到了五次抱怨，以为一切安好，实际上其他 995 个用户已经默默切换到手动操作了。只靠隐式反馈，你又会陷入噪音的海洋，将用户的偶尔好奇悬停误判为深度困惑。

建立你的反馈收集器

我们来看一个最小可行的采集方案。你无需重建复杂的日志系统，只需要在 Agent 与用户的交互管道中插入一个轻量级的观察点。

# feedback_collector.py - 一个技能调用包装器示例

import time
import json
from datetime import datetime

class SkillFeedbackWrapper:
    def __init__(self, skill_name, skill_fn, audit_log_path):
        """
        skill_name: 技能标识，如 'payment_adapter'
        skill_fn: 技能的执行函数
        audit_log_path: 反馈日志的存储路径
        """
        self.skill_name = skill_name
        self.skill_fn = skill_fn
        self.audit_log_path = audit_log_path
        self.session_start = None

    def __call__(self, user_input, context):
        """
        包装器拦截技能调用，捕获基础交互信号。
        """
        self.session_start = time.time()
        result = None
        error_type = None

        try:
            # 执行技能核心逻辑
            result = self.skill_fn(user_input, context)
        except Exception as e:
            error_type = type(e).__name__
            # 注意：此时仍返回一个结构化的错误给上层自然语言转换层
            result = {"error": str(e)}
        finally:
            # 关键步骤：记录一次完整的交互片段
            duration_ms = (time.time() - self.session_start) * 1000
            self._log_interaction(
                user_input_hash=self._hash_input(user_input),
                duration_ms=duration_ms,
                error_type=error_type,
                # 这里可以接入后续的显式评分；若无则留空
                explicit_score=None  
            )

        return result

    def _log_interaction(self, **kwargs):
        """
        将交互记录追加到审计日志中。
        """
        event = {
            "skill": self.skill_name,
            "timestamp": datetime.utcnow().isoformat(),
            **kwargs
        }
        with open(self.audit_log_path, "a") as f:
            f.write(json.dumps(event, default=str) + "\n")

    def _hash_input(self, raw_text):
        # 出于隐私，只存储输入的特征而非原意
        return hash(raw_text)

这段代码本身并不复杂，但它的价值在于：它为每一次调用都刻下了不可篡改的“足迹”。即使这次调用成功，我们也记录了耗时；即使这次调用失败，我们也捕获了异常类型。

踩坑经验：很多团队一开始就试图记录所有对话原文，这会导致严重的隐私风险和存储膨胀。从交互的元数据（耗时、是否报错、调用频率）开始收集，这些已足够支撑 80% 的分析场景。后续确有必要时，再对少样本进行脱敏内容记录。

解读隐式信号的语义

有了日志，你需要一套简单的规则，将这些原始数据点转化为有意义的“用户状态”。比如，你可以定义如下的事件映射表：

这种映射是反馈闭环从“数据”迈向“洞察”的关键一步。你不需要复杂的模型，一个简单的定时分析脚本就可以统计出“过去 24 小时，高优先级潜在弃用事件发生了 47 次”，这比任何报表都更能告诉你哪里出了问题。

第二步：反馈驱动的提示词微调实验室

采集到信号只是第一步，真正的挑战在于：如何安全地将“用户的挫败感”转化为“SKILL.md 里的三行新指令”？

直接让 AI 根据一条报错自动修改提示词是危险的。最稳妥的路径，是从失败案例中生成“对抗样本”，在离线环境中进行迭代测试，通过后再人工或半自动发布。这就是一个微型的“提示词实验室”。

自动化失败案例聚合

假设我们的支付 Skill 经常出现 KeyError: 'transaction_id'。通过第一步的日志，我们已经可以筛选出所有带 error_type=KeyError 的片段。现在，我们需要对它们进行聚类，找到根因。

这里可以用一个简单的分析脚本，由 Claude 自身来辅助完成分析。我们不需要跑复杂的 NLP 流水线，只需要将聚合后的报错信息作为 Prompt 输入，让它帮助我们总结模式。

# 这是一个发给 Agent 内部分析器的 prompt 示例
# 你的任务不是执行它，而是把它写入分析脚本的上下文。

你是一个 Skill 诊断专家。请分析以下调用我们 'payment_adapter' 技能时产生的错误日志摘要：

[粘贴从反馈日志中提取的，过去24小时内的所有 KeyError 样本列表]

请执行以下分析：
1.  **识别最常见的错误类型**：这些 KeyError 分别尝试访问哪些不存在的字段？
2.  **追溯可能的时间线**：这些错误是在哪个时间节点开始集中出现的？（提示：对比变更日志）
3.  **提出改进方案**：针对 SKILL.md 的修改建议。例如：
    *   是否需要增加一个前置的数据结构校验步骤？
    *   是否需要为具体字段提供容错回退逻辑？（优先尝试 new_field，若无则尝试 old_field）
    *   是否需要在系统提示中增加“遇到未识别字段时，询问用户或使用默认值”的指令？

当上述分析由 Agent 内部分析器执行后，它会给出具体的修改建议，比如：“检测到 transaction_id 在 14:30 分后开始大量缺失，建议在 payment_adapter 技能的第 12 行后增加字段适配逻辑。”

从对抗样本到 SKILL.md 的自动迭代

拿到修改建议后，我们不能直接应用到生产环境。接下来是关键的“对抗测试”环节。我们需要创建一个脚本，自动生成针对原 Skill 失败场景的测试用例（对抗样本），然后验证新 Skill 定义在这些用例上的表现。

# 进化流水线脚本的概念性片段 (skill_evolver.sh)
# 此脚本模拟了 OliverOuyang/claude-skills 开源项目中的 Heal 和 Reflect 机制思路

SKILL_NAME="payment_adapter"
ORIGINAL_SKILL_FILE="skills/${SKILL_NAME}/SKILL.md"
BACKUP_DIR=".skill-evolution/backups/${SKILL_NAME}/$(date +%Y%m%d_%H%M%S)"
FAILURE_LOG="logs/${SKILL_NAME}_errors.jsonl" # 第一步中收集的失败日志

echo ">>> 备份当前 Skill 定义..."
mkdir -p $BACKUP_DIR
cp $ORIGINAL_SKILL_FILE $BACKUP_DIR/

echo ">>> 从失败日志中提取对抗样本..."
# 假设 extract_test_cases.py 是提取日志片段并构造为提示词的程序
python extract_test_cases.py $FAILURE_LOG > test_cases.jsonl

echo ">>> 请求 AI 分析并生成修复建议..."
# 将现有 SKILL.md + 对抗样本发送给 AI，获取改进后的 SKILL.md 草稿
# ai_healer.py 会执行类似上一节的诊断 prompt，并返回一个完整的 .md 文件
python ai_healer.py $ORIGINAL_SKILL_FILE test_cases.jsonl > improved.SKILL.md

echo ">>> 离线验证新定义..."
# 使用对抗样本集，对 improved.SKILL.md 进行回归测试
python run_skill_tests.py improved.SKILL.md test_cases.jsonl

# 检查验证结果
if [ $? -eq 0 ]; then
    echo "✅ 验证通过！准备进行 A/B 实验发布。"
    # 此处可自动提交到实验分支，等待人工确认发布
    # git checkout -b "exp/self-heal-${SKILL_NAME}-$(date +%Y%m%d)"
    # cp improved.SKILL.md $ORIGINAL_SKILL_FILE
    # git commit -m "feat(skill): 自我修复 - 适配接口字段变更"
else
    echo "❌ 验证失败，放弃本次修改。备份保留在 ${BACKUP_DIR}"
    exit 1
fi

踩坑经验：自动化修复流水线最常见的失败原因是“修好一个，坏了十个”。因此，离线验证必须是强制的，并且测试用例集必须不仅包含这次的失败案例，还应包含一个核心的成功案例回归集。永远不要为了追求完全自动化而跳过这一步。

第三步：A/B 实验与持续学习

当改进方案通过离线测试后，我们仍然不能在瞬间替换所有用户的 Skill。一个全新的、未经真实用户检验的 Skill 定义，可能恰好在某个角落埋藏着新的缺陷。这时，我们需要引入在线实验框架，将改进假设量化，最终做出有信心的全量决策。

将改进转化为一个假设

首先，把 Skill 的修改点提炼成一个清晰、可验证的假设。例如：

• 假设：“在 payment_adapter 中增加字段适配容错逻辑，可以将因接口字段变更导致的失败率降低 90%，同时不会引入超过 2% 的响应时间延长。”
• 核心指标：技能调用失败率。
• 护栏指标：平均响应时间、用户弃用率。

实现一个最小可行实验分流

你不需要一个复杂的 A/B 实验平台。在 Skills 的调用路由层，基于用户 ID 进行哈希分桶，就能轻松实现实验。

# experiment_router.py - 一个简单的实验分流器

import hashlib

class SkillRouter:
    def __init__(self, experiments_config):
        """
        experiments_config: 实验配置字典.
        示例: {
            "payment_adapter": {
                "enabled": True,
                "traffic_percent": 10,  # 10%的流量进入实验组
                "control_group": "skills/payment_adapter/SKILL.md",
                "experiment_group": "skills/payment_adapter/SKILL_v2.md"
            }
        }
        """
        self.experiments = experiments_config

    def select_skill_version(self, skill_name, user_identifier):
        """
        根据用户标识决定使用哪个版本的 Skill 定义。
        """
        exp = self.experiments.get(skill_name)
        if not exp or not exp["enabled"]:
            # 没有实验，走默认版本
            return exp["control_group"] if exp else f"skills/{skill_name}/SKILL.md"

        # 使用一致的哈希，确保同一用户总在同一个组
        user_bucket = int(hashlib.md5(user_identifier.encode()).hexdigest(), 16) % 100

        if user_bucket < exp["traffic_percent"]:
            print(f"路由: 用户 {user_identifier} -> 实验组 ({exp['experiment_group']})")
            return exp["experiment_group"]
        else:
            print(f"路由: 用户 {user_identifier} -> 对照组 ({exp['control_group']})")
            return exp["control_group"]

# --- 使用示例 ---
router = SkillRouter(experiments_config={
    "payment_adapter": {
        "enabled": True,
        "traffic_percent": 10,
        "control_group": "skills/payment_adapter/SKILL.md",
        "experiment_group": "skills/payment_adapter/SKILL_v2.md"
    }
})

# 在 Agent 执行 Skill 的地方：
user = get_current_user()
skill_file_to_load = router.select_skill_version("payment_adapter", user.email)
load_and_execute_skill(skill_file_to_load, ...)

量化影响并驱动决策

实验运行一段时间后，你需要将第一步建立的反馈日志与实验分组信息结合起来分析。为此，只需在原日志记录中追加一个 experiment_group: control/experiment 标签，然后运行如下的分析查询：

当实验数据呈现上表中的结果时，我们可以得出结论：实验组（v2）在保持响应时间基本不变的情况下，将失败率从 2.3% 降至 0.25%，降幅达 89.1%。这验证了我们最初的假设。随即可以执行全量发布（将 traffic_percent 设为 100），完成一次数据驱动的技能进化。

每一次这样的循环，都在增加 metrics.json 中一个关键的进化记录。从当前调研资料来看，经过几轮迭代，我们可以看到错误修复时间从最初的 30 分钟手动干预缩短至 2 分钟的自动化修复，效率提升 15 倍。这是反馈飞轮带来的真实复利效应。

回顾

这一章，我们共同搭建了一个让 Skills 从“磨损”变为“生长”的反馈系统。你不再是那个凌晨三点起床修 Bug 的开发者了。我们完成了：

• 采集之网：我们区分了隐式与显式反馈，并实现了一个最小的包装器来记录每一次调用的元数据。你将原本沉默的用户行为转化为了可解读的进化信号。
• 进化之脑：我们建立了一个从失败日志到对抗样本，再到 SKILL.md 自动修复的离线验证流水线。你明白了安全的自进化不是直接修改文件，而是经过严格测试的迭代。
• 决策之眼：我们引入了 A/B 实验框架，将每一次人工或自动的修改转化为一个有明确指标的可验证假设，用数据代替直觉来决定 Skill 的版本发布。

花费了约 40 分钟，你掌握了将 Skills 带入“自我感知”和“自我优化”时代的完整方法论。这套闭环的生命力在于它的持续性：飞轮每转动一圈，系统的容错性就增强一分，对人的依赖就减少一分。

行动清单

1. 立刻行动：打开你正在负责的一个 Skill 项目，在它的调用入口处，用本章的 SkillFeedbackWrapper 示例添加对耗时、错误和异常类型的日志记录。这是零风险的增益。
2. 设定一个触发器：创建一个定时任务（哪怕是 cron job），让它每天去分析昨天的错误日志，把最频繁的前三种错误直接发送到你的聊天工具。让系统推给你问题，而不是你每天去找。
3. 准备你的实验室：选定一个你最近手动修复过的 Skill Bug，手动为该 Bug 创建 3 个对抗样本（也就是能触发该 Bug 的用户输入），然后尝试用 AI 分析器针对这 3 个样本生成一个修复版 SKILL.md，并对比新老版本在样本上的输出差异。
4. 声明你的假设：在你即将对某个 Skill 做的任何一次修改前，先在文档里写下：“我预计这次修改能把 XX 指标从 A 提升到 B”。实验完成后，回到这句话来复盘。
5. 展望未来：当你的 Skill 能够自我疗愈并自我优化时，它也就开启了一扇充满新风险的大门。一个具备修改自身逻辑能力的 Agent，其攻击面远比一个静态脚本要大得多。

下一章，Agent Skills 的安全攻防是一个全新领域，我们将直接面对这个因进化能力而生的全新挑战：当你的 Skill 可以被一段恶意输入悄悄改写时，你该如何建立一座不可逾越的堡垒？