跳转至

10篇论文看懂AI Agent Skill：表示、执行、评估与进化

Ch04.036 10篇论文看懂AI Agent Skill：表示、执行、评估与进化

📊 Level ⭐⭐ | 26.7KB | entities/skill-formal-theory-survey-10papers.md

Skill Formal Theory Survey 10Papers

10篇论文看懂AI Agent Skill：表示、执行、评估与进化

  • URL: https://mp.weixin.qq.com/s/Z2fFNWXgRHq0VogIRD69Yg
  • Author: 学术综述（arXiv风格，微信编译版）
  • Date: 2026-05
  • Length: 7849 chars
  • SHA256: 543ce5dc66d7af5c7c8e5ff67c8269e43cf415429b9b6173ed97011063e5d890
  • Score: Value=8 × Confidence=8 = 64
  • References: 12篇（含Knowledge Activation、Blueprint First等arXiv论文）

摘要

技能（Skills）正在成为支架工程中连接大语言模型智能体与结构化领域知识的关键抽象。不同于松散的提示词和原子化的工具调用，技能将复杂的多步操作固化为可组合、可复用、可验证的确定性流程，使智能体能够在遵守边界约束的前提下可靠地执行生产级任务。 本文面向算法研究人员，从六个维度系统综述： 1. 形式化表示 2. 执行机制 3. 上下文调度 4. 评估框架 5. 安全治理 6. 自动挖掘

1. 技能的形式化定义

六元组定义

技能被形式化为一个六元组： 

Skill = (ID, I, O, P, Pre, Eff)

  • ID：唯一标识符及元数据（名称、版本、适用范围、所需权限）
  • I：输入模式（Input Schema），定义技能所需的参数及其类型约束
  • O：输出模式（Output Schema），定义技能完成后产生的状态变化与返回值
  • P：步骤计划（Plan），一个偏序的步骤集合（DAG）
  • Pre：前置条件（Preconditions），必须满足方可激活的逻辑断言
  • Eff：效果描述（Effects），描述技能执行对系统预期的影响，含补偿动作

步骤计划：DAG建模

技能的步骤计划 P 建模为有向无环图（DAG）： 

P = (V, E, v_0, V_f)

  • V：步骤节点集合，每个节点 v 包含：
  • 动作类型（文件读写/工具调用/代码生成/人工确认等）
  • 动作参数模板
  • 成功/失败条件
  • 最大重试次数
  • 超时时间
  • E：步骤间的依赖边，e(v_i, v_j) 表示 v_i 必须在 v_j 成功完成后才能开始
  • v_0：唯一入口节点
  • V_f：终止节点集合 执行引擎按拓扑顺序调度节点执行，支持有限并行（多个入度为0且互不冲突的节点可并发执行）。 示例DAG（"添加API端点"技能）： 
    v0: 读取任务简报 → v1: 确认前置条件
                           ↘ v2: 启动特性百科全书加载
                           ↗ v3: 生成Schema定义
                           → v4: 生成迁移脚本
                           ↗ v5: 生成服务层代码
                           → v6: 合并与验证
                           → v7: 提交审查 → vf: 输出结果
    （v1和v2可并行，v4和v5可并行）

三种技能类型

类型 执行引擎 确定性程度 典型表示 灵活性
命令式技能 LLM逐步解释执行 中等 Markdown/YAML清单 高
蓝图式技能 确定性蓝图引擎+LLM填充槽位 高（控制流确定） 可执行TypeScript/Python代码 中
知识激活技能 知识图谱遍历+子图匹配 高（激活与组合逻辑确定） 知识图谱节点+规则 高
> 蓝图式技能将控制流从LLM中剥离，执行变异系数（CV）可降至0.02以下。

2. 执行机制

触发与匹配算法

技能的触发分为显式调用和隐式激活两种模式。 隐式激活匹配函数（级联打分）： 

1. 硬性过滤：前置条件Pre必须在上下文C中满足，否则score=0
2. 语义匹配：将C中任务描述与技能描述编码为向量，计算余弦相似度
3. 上下文关联度加分：文件路径、实体名与技能声明的领域术语重叠 → 加权加分
4. 选择：取score最高的技能；若均低于阈值τ，回退到通用自由工具调用模式

上下文预算分配与渐进式加载

问题：技能执行消耗Token预算，上下文窗口有限。 策略：渐进式披露（Progressive Disclosure）。 设DAG拓扑排序为 [v_0, v_1, ..., v_k]，每个节点Token负载为 t(v_i)。上下文调度器维护活跃Token预算 B。 在任意时刻，仅当前执行节点及其直接后继节点的详细指令被加载；其余节点信息以压缩摘要形式驻留外部记忆，仅在激活时展开。

可将活跃上下文压缩至150–300行指令的"甜点区"，避免"迷失在中间"效应。渐进式加载使技能步骤依从性提升17%。

与计划优先工作流的耦合

双向验证机制：

  • 正向验证（计划→技能）：Agent生成的结构化计划被解析为子目标；对于每个子目标，检索匹配技能；若步骤序列与计划存在结构冲突 → 标记"需人工审查"
  • 反向验证（技能→计划）：激活技能的前置条件Pre和效果Eff投射回计划，确保计划其余部分不与技能效果冲突

3. 多技能编排与并发执行

编排算法

接受一组匹配的技能 {S_1, ..., S_n} 及依赖关系，构造全局执行DAG。 依赖关系来源：

  • 显式声明（depends_on字段）
  • 效果-前置条件分析：若S_j的断言满足S_i中的某个条件，则添加边 无依赖的技能对可并行分配至不同执行子Agent，通过共享状态存储（如PLAN.md）交换中间结果。

失败回滚

补偿事务模式：每个副作用节点 v 定义补偿动作 v_comp。当执行链在v失败时，逆序执行所有补偿动作，将状态恢复至初始点。理想情况下，补偿动作与正动作满足幂等性。

4. 评估框架

评估指标体系

指标 公式 解释
任务成功率 成功次数/总执行次数 是否最终达成目标
步骤依从性 偏离步骤数/总步骤数 是否严格遵循技能DAG
执行一致性 执行时间/执行时间̄
Token效率 自由模式消耗/技能模式消耗
知识新鲜度 仍有效断言数/断言总数

基准测试方法

  1. A/B对比评估：使用技能组 vs 未使用技能组的同构Agent实例对比。Snowflake的Agent GPA框架提供标准化评分卡：目标完成度/逻辑一致性/执行效率/计划质量/计划依从性五轴。

  2. 回归测试套件：每个技能关联输入-期望输出-期望轨迹的测试用例；验证：

  3. 最终输出与期望输出匹配（确定性检查）

  4. 执行轨迹与期望DAG拓扑同构（轨迹匹配）
  5. 未触发安全违规告警
  6. 人工专家审查：评估知识正确性（KF），定期抽样判断步骤指令和领域断言是否仍符合当前最佳实践。

5. 安全与治理

安全边界的形式化

技能的安全约束表示为一组安全策略，每条策略 P_i 是四元组： 

P_i = (action, resource, condition, effect)
策略引擎（如OPA/Rego）在执行节点动作前评估：若任一策略拒绝，动作被拦截并记录审计日志。

技能完整性验证

内容签名机制：

  • 技能文件 F 的规范化表示通过哈希函数 H 生成摘要 h = H(F)
  • 用团队私钥签名
  • Agent框架在加载技能前验证签名；失败触发告警并回退到只读安全模式

知识衰减监测

技能中的领域知识会随代码库演变而过时。监测机制： 1. 依赖图跟踪：技能元数据记录引用的关键文件路径和实体名称 2. 变更触发器：被引用实体发生结构性变更时 → CI管道标记技能为"需复审"，加入人工审查队列 3. 定期自动回归：每月执行所有技能回归测试套件；若某技能回归成功率连续两个月下降超阈值 → 触发强制废弃流程

6. 技能的自动挖掘

目标：将技能创建从纯人工编写转变为"算法挖掘+人工审核"的半自动化流程。

三阶段管道

阶段1：候选模式挖掘 给定开发者IDE操作日志序列 D = [o_1, o_2, ..., o_n]，其中每个操作包含类型（打开文件/编辑/运行命令）、参数和时间戳。 使用PrefixSpan或CloSpan等频繁子序列挖掘算法提取高频且封闭的操作序列作为候选技能骨架。 过滤规则：序列必须包含至少一个"验证"或"测试"步骤。 阶段2：语义聚类与泛化 对相似但参数不同的候选序列进行聚类，泛化为参数化技能模板。 示例：

  • "打开user.controller.ts → 添加POST /users路由 → 打开user.service.ts → 添加createUser方法"

  • "打开product.controller.ts → 添加POST /products路由 → 打开product.service.ts → 添加createProduct方法" → 聚类为技能模板"添加CRUD端点"，参数化为实体名称。 阶段3：质量过滤

  • 执行验证：隔离沙箱中自动执行候选技能，统计任务成功率

  • 步骤依从性：候选技能的执行轨迹与挖掘出的序列是否高度一致
  • 专家确认：通过初步过滤的候选技能提交领域专家进行最终命名、参数调整和安全审查

    这一管道可有望覆盖中小型项目60%以上的常见工作流。

核心结论

"模型能力正在趋同，而组织对有效行动路径的编码化程度，将成为智能体时代真正的性能分水岭。" 技能工程化的终极目标：构建AI智能体的"操作系统"——由社区贡献、经过形式验证、可组合定制的知识执行层。

深度分析

1. 六元组设计的工程必然性

技能采用 (ID, I, O, P, Pre, Eff) 六元组表示，并非学术炫技，而是工程实践中的现实需求驱动的。 输入输出的模式化解决了LLM调用技能时的参数类型混乱问题。在传统工具调用中，LLM需要自行推断参数格式，而显式 schema 将这一意图匹配成本转移到了设计阶段，使得运行时调用精度大幅提升。ID元数据字段携带版本和适用范围信息，这是技能可复用性的基础——没有版本化的技能在生产环境中会迅速演变为技术债务。 前置条件与效果的形式化是技能实现自动编排的前提。Pre和Eff使得技能之间的依赖关系可以被算法推断而非硬编码。当Skill B的效果断言满足Skill A的前置条件时，系统可以自动建立A→B的依赖边，实现技能组合的自动化。这在单技能层面是小改进，但在多技能系统中，累积效应使得人工接线的工作量指数级下降。

2. DAG执行模型的局限性

将步骤计划建模为DAG是合理的选择，但需正视其局限性。 并行执行的假象：虽然理论上多个入度为0且无资源冲突的节点可并发执行，但"无资源冲突"的判断依赖于运行时状态。在实际系统中，文件句柄、数据库连接、外部API配额等资源约束难以在DAG设计阶段完全预判。并行执行的实现往往比声明式DAG要复杂得多——需要运行时资源管理器持续监控，而非静态拓扑排序一次性决策。 异常处理的简化：DAG模型对步骤失败的处理停留在"补偿动作"层面，但真实场景中的异常远比补偿/回滚二元化要复杂。部分成功、暂态失败、超时重试等状态在纯DAG模型中没有好的表示方式。实践中，很多系统将这类复杂状态外推到外部状态机，DAG本身只负责成功路径的建模。

3. 渐进式披露的深层含义

上下文预算分配与渐进式加载策略的本质，是将LLM的上下文窗口视为一种分级存储体系，而非简单的长度限制。 这一设计的洞察在于：LLM对上下文中间部分的信息"遗忘"最严重，而开头和结尾部分的保持率较高。因此，将当前执行节点及其直接后继放在上下文的"甜点区"，是一个工程上务实的逼近。150-300行指令的甜点区对应约6000-12000个token，刚好覆盖GPT-4o等模型单次输出的核心窗口。 更深的含义是，这个设计将"技能"本身变成了一种记忆层次结构：活跃执行的节点在L1（工作上下文），其余节点在L2（外部记忆），仅在激活时按需换入。这一抽象与操作系统的虚拟存储管理在思想上同构，暗示了AI Agent架构正在从"提示工程"向"系统结构化"演进。

4. 三种技能类型的演进逻辑

命令式→蓝图式→知识激活技能，代表了一条从"LLM完全控制"到"结构化知识引导"的连续谱系。 命令式技能给予LLM最大的自由度，但代价是执行变异系数（CV）高——同一条技能在多次执行中可能产生差异显著的结果。蓝图式技能将控制流抽取为确定性规则，仅让LLM填充数据槽位，使CV降至0.02以下，这是质的飞跃。 知识激活技能则更进一步，将领域知识编码为图结构，激活逻辑由图遍历而非LLM推理决定。这种模式的确定性程度最高，但适用范围受限于知识图谱的覆盖度。三种类型并非优劣之分，而是适用于不同场景：探索性任务用命令式，标准化生产流程用蓝图式，高频重复决策用知识激活式。

5. 补偿事务模式的实践困境

补偿事务模式在理论上优雅，但在实践中面临几个困境。 首先，补偿动作未必能完整撤销原始效果。网络调用可能已经触发外部状态变更，数据库写入可能被其他事务读取，补偿动作只能尽力恢复而非保证等幂恢复。其次，补偿动作本身可能失败，形成"嵌套失败"——此时系统的行为在设计上是未定义的。 理想情况下补偿动作与正动作满足幂等性，但实际上很多操作（如发送邮件、调用第三方支付接口）天然非幂等。实践中常见的妥协是"软补偿"：记录补偿意图而非真正执行，等人工审查后再决定是否应用。对于关键路径上的技能，补偿设计的完备性可能比技能本身的执行逻辑更值得审查。

6. 自动挖掘的局限性

三阶段挖掘管道将技能创建从纯人工转变为半自动化，这是正确的方向，但其局限性需要清醒认知。 PrefixSpan/CloSpan只能挖掘行为模式，无法挖掘语义意图。一个"打开文件→添加代码→保存"的序列，可能对应"添加CRUD端点"，也可能对应"修复Bug"，二者行为模式相似但意图截然不同。聚类阶段若仅依赖操作序列的相似性，可能会将意图不同的技能错误合并。 60%覆盖率的目标也值得审视：中小型项目中60%的工作流可能是CRUD类操作，这恰好是被挖掘算法最容易捕获的模式。剩下40%的复杂逻辑、边界情况处理、创新性解决方案，才是真正需要人工设计的部分。换言之，自动挖掘擅长捕捉"常规"，而技能的真正价值往往体现在处理"例外"上。

7. 安全与知识衰减的耦合

知识衰减监测机制通过依赖图跟踪+变更触发器+定期回归三者结合，形成了一套预防性维护体系。 然而，这套机制假设技能引用的关键文件路径和实体名称是稳定的。事实上，在快速迭代的项目中，文件和实体的命名本身就经常重构。当技能A引用了src/services/user.service.ts，而项目重构后该文件被拆分为src/services/user/userQuery.ts和src/services/user/userCommand.ts时，依赖图跟踪会失效除非同步更新。 更根本的问题在于：技能的"正确性"很难通过自动化测试完全验证。一个技能可能在测试套件中全部通过，但在新的业务场景下产生错误行为——因为测试用例本身可能已经过时。知识新鲜度指标（"仍有效断言数/断言总数"）是一个代理指标，而非真正的质量指标。实践中，很多团队最终依赖人工定期审查技能内容的业务相关性。

实践启示

为团队选择合适的技能类型

不同技能类型适用于不同场景，团队应根据自身成熟度选择。 初创期团队（0-1验证阶段）：建议从命令式技能入手，YAML/Markdown格式的清单式技能易于快速迭代，LLM的自由度可以加速探索。在这个阶段追求高确定性是过早优化的行为。 成长期团队（1-N复制阶段）：当某一类任务被反复执行超过5次且流程基本稳定时，应将其升级为蓝图式技能。这一转换的标志是CV从人工判断的"不稳定"下降到可量化的"低于0.02"。蓝图式技能使得同一技能的不同实例可以由不同LLM版本执行而不产生显著差异。 成熟期团队（规模化运营）：建立知识激活技能库，将高频决策模式固化为图结构遍历。同时，为所有技能建立回归测试套件，并纳入CI管道。知识衰减监测应该与代码库的CI/CD紧密绑定，而非独立运行。

设计技能的工程检查清单

创建新技能时应系统性地覆盖以下维度： 表示层：技能是否有清晰的ID和版本？输入/输出schema是否完整且经过类型检查？前置条件是否覆盖了所有必要的状态假设？效果描述是否包含了所有预期的副作用？ 执行层：步骤DAG是否有唯一的入口和终止节点？每个节点是否有明确的成功/失败判断条件？补偿动作是否已定义且经过幂等性验证？并行节点的资源依赖是否已在设计中排除？ 安全层：是否定义了安全策略四元组？策略引擎是否与技能执行解耦？技能文件是否有签名验证机制？ 维护层：技能的依赖文件列表是否已记录？知识衰减监测是否已接入CI？回归测试是否覆盖了核心路径？

上下文调优的实操建议

当技能执行出现"迷失在中间"效应时，渐进式披露是首选方案，但实施中有几个要点需要注意。 压缩而非删除：将非活跃节点的详细信息压缩为摘要时，应保留关键判断点信息（条件分支、异常路径），而非简单截断。摘要的目的是让LLM在需要时能够重建完整上下文，而非让其完全遗忘。 后继节点的提前加载：当前节点执行即将完成时，应提前将下一节点的详细信息加载至活跃上下文，而非等待拓扑顺序到达后再加载。这一"预取"策略可以减少执行节点切换时的延迟。 活跃预算的动态调整：上下文预算B应根据LLM输出长度动态调整。若前几步执行后剩余token预算充裕，可适当扩展活跃节点数；若token消耗速度超预期，应触发主动压缩而非等待OOM。

多技能编排的故障排查

当多技能编排出现异常时，以下排查路径通常有效： 1. 依赖分析：检查技能间的隐式依赖边是否正确建立。效果-前置条件分析可能因为两个技能的断言表述不一致而漏建边，导致执行顺序错误。 2. 共享状态一致性：并行的技能对通过PLAN.md等共享状态交换中间结果，若某一技能修改了共享状态而另一技能未及时感知，可能导致后续节点读取到过期数据。解决方案是引入乐观锁或版本号机制。 3. 补偿链的死锁：若补偿动作本身需要访问其他技能，可能会形成技能间的循环依赖。设计时应确保补偿动作的集合构成一个DAG而非环。

评估体系的建设优先级

建立技能评估体系时，建议按以下优先级推进： 第一优先级：任务成功率。这是最终的业务指标，也是最简单的——只需判断技能执行后目标是否达成。初始阶段可以用人工判断，成功率低于80%的技能应立即停用审查。 第二优先级：步骤依从性。通过比对执行轨迹与技能DAG的拓扑顺序，可以早期发现技能执行的"漂移"。这一指标需要自动化的轨迹捕获机制。 第三优先级：Token效率。在任务成功率和步骤依从性达标后，优化Token消耗才有意义。过早优化效率可能导致为节省Token而牺牲执行质量。 后续指标（执行一致性、知识新鲜度）应在技能稳定运行后再纳入评估，此时已有足够的baseline数据支撑这些指标的统计意义。

技能工程化的长期方向

技能作为AI Agent的"操作系统"层，其工程化方向值得持续关注。 技能市场与互操作性：若技能以六元组形式标准化，不同团队的技能可以像代码库一样共享和组合。这一互操作性的前提是schema的广泛认同和工具链的成熟。当前仍是各家自建阶段，标准化进程刚刚起步。 技能的版本治理：随着技能数量增长，版本管理、兼容性测试、废弃策略将成为运维的主要挑战。建议从第一个技能开始就建立版本号规范，并记录每个版本的breaking change。 自动挖掘的成熟度：当前挖掘管道的局限（只能捕获行为模式，无法捕获语义意图）可能在未来通过LLM辅助的语义分析得到改善。但即便如此，专家审核这一环难以完全消除——技能的最终质量责任仍在人类专家手中。

相关实体

→ 原文存档