Agent Skill 不应只会执行：怎样构建可验证的自进化能力？
文 | AI编程实践
团队给代码 Agent 写了一份“数据库迁移 Skill”。第一次，它正确生成变更脚本；第二次，它漏了回滚；第三次，工程师继续往 SKILL.md 里补规则。三个月后，这份文件长到没人敢删一句，模型仍会在新数据库版本上犯旧问题。
所谓自进化不能等同于“Agent 自动改 Prompt”。可靠的进化链至少包含失败样本、归因、候选修改、隔离评测、版本发布和回滚。DSPy 和 GEPA 提供了程序化优化 Prompt 的方法，但生产系统还要补上数据隔离、变更治理和安全准出。
一、先把 Skill 从长 Prompt 里拆出来
Skill 是一个按需加载的能力包，可以包含说明、脚本、模板、参考资料和验收规则。它的价值不在于文件名，而在于渐进披露：模型先看到短描述，只有意图匹配时才读取完整说明，需要执行时再加载脚本或资料。
database-migration-skill:
SKILL.md: 适用场景、流程、风险、验收
scripts/: schema_diff、dry_run、rollback_check
references/: 各数据库版本差异
assets/: 迁移计划模板
这能减少上下文膨胀，也让知识可以版本化。但 Skill 仍可能失败：触发描述选错、流程不适应新场景、多个 Skill 无法组合，或者脚本本身已经过期。
二、自进化的最小闭环是什么
闭环从 Trace 开始，而不是从 LLM 反思开始。系统要记录模型当时看到的输入、加载了哪个 Skill 版本、调用了什么工具、结果是什么、验证器为何判错。没有这些证据，反思模型很容易对结果进行事后编故事。
归因完成后生成候选补丁。候选可能改触发描述、流程步骤、工具 Schema、停止条件或验收脚本。原版本保持不动，所有修改带来源 badcase 和补丁理由。
接下来必须在隔离数据上评测。不能拿生成补丁的同一批失败样本既训练又验收，也不能只看平均分。数据库迁移 Skill 至少要通过语法、dry-run、数据不丢失、回滚可用和权限边界测试。
线上 badcase 进入闭环前先冻结快照：输入、历史、Skill 版本、模型、工具 Schema 和依赖环境都要可重放。否则补丁在新环境里“修好了”，可能只是依赖版本变化，而不是 Skill 真正学会了。
三、DSPy 与 GEPA 解决了什么
DSPy 用 Signature 和 Module 描述“输入、输出与推理结构”，再让 Optimizer 根据训练样本和 Metric 搜索 Prompt 或示例。它把优化目标从“这句话听起来更好”变成“这个程序在数据集上得分更高”。DSPy 官方文档
GEPA 则读取完整轨迹，用自然语言反思失败原因，提出候选指令，并在 Pareto 前沿上保留不同优势的版本。论文报告其在六类任务中以显著更少的 rollout 超过若干强化学习和提示优化基线，但这些数字不能直接外推到企业 Skill；数据分布、评测器和工具环境都会改变结果。GEPA 论文
工程上可以这样分工：
DSPy 的 Signature 适合固定输入输出契约，Optimizer 根据 Metric 搜索指令和 Few-shot 示例。GEPA 更适合从完整轨迹提取自然语言规则。两者都不负责生产发布，因此优化结果应该先转成受限的 Patch，而不是直接覆盖 SKILL.md。
allowed_patch_ops:
- append_example
- replace_instruction
- tighten_trigger
- add_validation_step
forbidden_without_review:
- remove_guardrail
- widen_tool_scope
- change_credential_source
- disable_human_approval
限制补丁操作能让审查与回滚更可靠。优化器输出“删除回滚检查可以提高完成率”时，策略层会拒绝，而不是因为离线分数更高就放行。
四、训练集、回归集和安全集必须隔离
可以将样本拆成四个池：用于发现问题的线上 badcase，用于优化的 train pool，用于选候选的 validation pool，以及从不暴露给优化器的 holdout 与安全红队集。
同一用户或同一任务模板的近重复样本不能跨池，否则优化器只是记住答案。去重不仅看文本相似度，还要看任务 ID、工具轨迹和期望 Artifact。时间切分也很重要：用旧版本案例优化，用更新业务规则验证，才能发现过拟合到历史政策的问题。
每轮优化消耗也要记账。候选数量、Rollout 数、Judge 调用和总 Token 都进入实验记录。一个只提升 0.5%、却把优化成本提高十倍的候选，不一定值得发布。
五、评测器决定了进化方向
一个错误的 Metric 会稳定地产出错误优化。常见评测器有三类：
规则检查适合结构、编译、测试、Schema 和确定性业务约束； 人工标注适合少量高价值样本和模糊边界； LLM-as-a-judge 适合语义质量，但要固定 Rubric、顺序随机化，并用人工样本校准偏差。
可靠系统通常把三者组合起来。先用规则拒绝硬错误，再让 Judge 评价可读性和完整性，最后对低置信或高风险样本人工复核。Judge 模型、Prompt 和版本都要写入评测记录。
准出不能只看候选 Skill 在失败集上的提升，还要看完整回归集：原本会做的任务是否退化，Token 和时延是否恶化，错误工具调用是否增加，安全红队集是否被击穿。
一个可执行的准出策略可以是：修复集提升达到预期；核心回归集的置信区间下界不低于基线；安全集零新增违规；P95 Token 和时延增幅不超过预算；规则评测与人工抽检不发生系统性分歧。具体阈值由业务风险决定。
六、可观测性要能回答“哪个版本导致了什么”
一条有效的进化记录至少包含：
evolution_patch:
source_cases: [case_103, case_287]
base_version: [email protected]
changed_sections: [rollback, verification]
optimizer: gepa@config_hash
eval_dataset: migration-regression@2026-09
quality_delta: +4.2%
cost_delta: +1.1%
safety_gate: pass
rollout: 5% -> 25% -> 100%
如果线上成功率下降，系统可以沿着 run → skill_version → patch → source_cases 找到根因，并一键回滚。只有“最新 Skill 内容”而没有版本关系，所谓学习就只是不可审计的在线修改。
发布后采用影子流量或小比例灰度。系统同时计算新旧版本的任务结果，不让候选 Skill 立即执行高风险副作用。观察窗口内除了平均效果，还要看分群退化：某种数据库、语言或租户是否明显变差。
七、从半自动进化开始
第一阶段让系统自动归因和生成补丁，但由人审查 Diff。第二阶段允许低风险文案和示例自动进入离线评测，发布仍需审批。只有当回归集成熟、版本回滚可靠、监控能发现退化时，才让部分低风险 Skill 自动灰度。
核心指标包括触发准确率、任务成功率、旧能力保持率、修复命中率、回滚率、单任务 Token、工具错误率和安全违规率。自进化的目标不是让 Skill 每天变化，而是让每次变化都有证据、有边界，也能撤销。
参考资料
DSPy Documentation GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning