详情

首页手游攻略 别再一直调 prompt 了: 让 Agent 的 Skills 自己进化!

别再一直调 prompt 了: 让 Agent 的 Skills 自己进化!

佚名 2026-07-11 07:21:51

原创 陈思州 2026-07-10 22:49 浙江

Datawhale干货

作者:陈思州,Datawhale成员

一、Skill 的三层结构

在 Agent 系统里,Skill 可以理解为一种可版本化的能力包。它通常以一个目录存在,核心入口是 SKILL.md。这个文件包含元信息和任务指令,也可以配合参考文档、模板、示例和脚本一起使用。按照 Agent Skills 的设计,一个 Skill 大致可以分成三层:第一层是路由层,包括 name、description 和路径,用来帮助 Agent 判断当前任务是否适合调用这个 Skill;第二层是指令层,也就是 SKILL.md 的正文,用来描述任务流程、判断标准、工具策略和输出约束;第三层是资源层,比如 references/、assets/、scripts/,用于存放更详细的文档、样例、模板或可执行代码。

这套结构对应一种渐进式加载机制。Agent 启动时先看到每个 Skill 的名字、描述和路径;当用户任务匹配某个 Skill 时,再读取完整的 SKILL.md;执行过程中如果需要更细的信息,再继续读取引用文件或运行脚本。这样,一个 Agent 可以同时拥有很多 Skills,同时保持上下文轻量。

图 1 · 一个 Skill 的三层结构与按需加载顺序

二、自进化:让三层结构在真实反馈中持续更新

Skills 自进化,核心是让这三层结构在真实任务反馈中持续更新。路由层可以被优化,让 Skill 的触发边界更准确;指令层可以被更新,让任务流程和判断标准更稳定;资源层可以被补充,让 Agent 在复杂场景下有示例、模板或脚本可用。每一次进化都应该能回答三个问题:改了哪一层,解决什么问题,用什么结果证明它更好。

一个例子:旅行行程规划助手

举一个中性的例子:旅行行程规划助手。最初的 travel-planner-skill v1.0 可能长这样:

    ---
    name: travel-planner
    description: Plan a multi-day travel itinerary based on destination, dates, and user preferences.
    ---
    ## Workflow
    1.Collect destination, dates, budget, and travel preferences.
    2.Search for attractions, restaurants, and transportation options.
    3.Arrange attractions by day.
    4.Generate a day-by-day itinerary.
    ## Output
    Use one section per day.
    Include attractions, food recommendations, and transportation notes.

    这个版本可以生成行程。比如用户说:“我想去京都玩三天,喜欢寺庙、咖啡店和轻松一点的节奏。” Agent 可能输出:

      Day1:清水寺、二年坂三年坂、八坂神社、祇园
      Day2:伏见稻荷大社、锦市场、鸭川
      Day3:金阁寺、岚山、竹林小径

      信息看起来完整,但真实旅行体验可能不够好。第三天把金阁寺和岚山放在一起,交通时间偏长;“轻松一点”的偏好也没有真正进入安排。用户继续输入:“第三天太赶了,我不想频繁换乘,餐厅最好顺路一点。”

      这些后续 prompt 会先被记录为任务轨迹的一部分,包括用户原始需求、Agent 初版方案、用户修改意见、最终采纳版本和结果评价。优化器会分析这些反馈,把一次性的表达抽象成更稳定的规则。比如“第三天太赶了”可以抽象成:当用户偏好轻松行程时,每天控制 2-3 个主要停靠点,并保留休息时间;“不想频繁换乘”可以抽象成:优先选择同一区域内的景点组合,减少跨区域移动和换乘次数;“餐厅最好顺路”可以抽象成:餐厅和休息点应尽量靠近当天路线。

      图 2 · 同一次旅行规划,反馈前后的行程对比
      三、把每一条反馈写到正确的一层

      这些规则会进入候选修改。系统会判断它应该写到哪一层:触发边界相关的问题,修改路由层的 description;行程安排相关的问题,修改 SKILL.md 里的 Workflow;质量判断相关的问题,修改 Quality checks;亲子旅行、长辈旅行、预算旅行等细分场景,更适合放进 references/,让 Agent 在需要时按需读取。

      改指令层:从“景点罗列”到“按区域和节奏组织”

      第一次迭代可以先改 Workflow。原来是:

        2.Search for attractions, restaurants, and transportation options.
        3.Arrange attractions by day.

        候选修改变成:

          2.Searchforattractions, restaurants,andtransportation options.
          3.Groupcandidate placesbygeographic area before assigning themtodays.
          4.Estimate transittimebetweenmajor stops.
          5.Matcheachday's density to the user's pace preference:
          -relaxed:2-3major stopsperday,withbuffertime
          -standard:3-4major stopsperday
          -packed:4-6major stopsperday

          这次改动落在指令层的任务流程。它让 Agent 在安排行程前先做区域聚类,再估算主要地点之间的交通时间,最后根据用户偏好控制每天的密度。旅行计划会从“景点罗列”变成“按区域和节奏组织”。

          加判断标准:新增 Quality checks

          接着可以改判断标准,新增一段:

            ## Quality checks


            Before finalizing the itinerary,check:
            -Whethereachdaystays mostlywithinonegeographic area.
            -Whether transittimebetweenmajor stopsisreasonable.
            -Whether the numberofmajor stopsmatchestheuser's pace preference.
            - Whether meals and rest breaks are placed near the route.

            这一步解决的是行程质量校验。Agent 生成结果前,需要自查路线是否顺、交通是否合理、餐厅和休息点是否贴近当天路线。对旅行计划来说,这类判断标准比单纯增加景点更重要。

            下沉资源层:细分场景按需读取

            如果后续发现用户经常提到“带老人小孩,少走路”,这类需求可以进入资源层。比如新增:

              references/family-travel-constraints.md

              里面写亲子或长辈出行的约束,例如减少换乘、控制步行距离、安排午休、优先选择交通便利的景点。主 SKILL.md 只保留一句触发说明:

                If the user mentions children, seniors, stroller, or limited walking ability,readreferences/family-travel-constraints.md before finalizing the itinerary.

                这样,主 Skill 保持轻量,细分场景放到资源层按需读取。Agent 只有在用户提到相关偏好时,才加载更细的参考内容。

                定期做 Skill compaction:压缩与重构

                随着迭代次数增加,Skill 会逐渐更详细。好的自进化系统还需要定期做 Skill compaction,也就是压缩和重构。它会检查哪些规则重复,哪些规则长期没有触发,哪些细节应该从主文件下沉到 references,哪些规则可以合并成更高层的原则。

                比如主文件里原本堆了很多规则:

                  - 不要把距离很远的景点放在同一天
                  - 每天要控制景点数量
                  - 轻松旅行要留休息时间
                  - 餐厅要靠近当天路线
                  - 亲子旅行要减少换乘

                  经过压缩后,可以合并成一条更稳定的质量标准:

                    Prioritize route coherenceandpace fit: keepeachdaygeographically coherent, limit major stops accordingtopace, place mealsandbreaks near the route,andreduce transfersforfamily trips.

                    用验证决定新版本能否发布

                    候选 Skill 生成后,需要进入验证环节。系统可以拿一批历史旅行规划任务,让 v1.0 和 v1.1 分别生成行程,再比较几个指标:每天跨区域移动次数是否下降,平均交通时间是否减少,用户偏好是否被显式满足,行程密度是否符合预期。如果新版本表现更好,就发布为 travel-planner-skill v1.1;如果它过度保守,导致行程内容太少,这次修改会被拒绝,并记录为下一轮优化的负反馈。

                    图 3 · Skills 自进化的完整闭环

                    小结:从调 prompt 到持续运营 Skills

                    这个例子说明,Skills 自进化关注的是可定位、可验证的小步更新。用户反馈先成为证据,证据被抽象成规则,规则被写入合适的 Skill 层级,再通过验证决定是否进入新版本。随着规则积累,系统再通过压缩、合并、下沉和删除,让 Skill 保持清晰、轻量和可维护。

                    长期来看,Agent 的能力提升会逐渐从单次 prompt 调整,走向持续运营 Skills。模型提供通用推理能力,工具连接外部系统,Skills 承载可复用的程序性知识。真实任务中的反馈不断进入 Skill 的路由层、指令层和资源层,最终形成一套可版本管理、可评估、可回滚、可复用的能力体系。

                    一起“赞”三连

                    相关资讯
                    点击查看更多
                    游戏推荐
                    推荐专题
                    热门阅读
                    推荐下载