AutoSkill: Experience-Driven Lifelong Learning via Skill Self-Evolution

读前先抓住结论

AutoSkill 讨论的是一个非常贴近日常使用的问题：用户在不同会话里会反复表达稳定偏好，比如“少说术语”“按照公司公文风格写”“不要编造”“每次都用某个流程处理表格”。今天很多智能体会把这些内容当作记忆片段保存，或者干脆让用户下次重新说一遍，但它们很少把这些反复出现的经验沉淀成可复用能力。

论文的核心判断是：个性化智能体的长期能力不应该只积累原始记忆，而应该把交互经验转化为显式技能。 这里的技能不是模型参数里的隐式偏好，而是外部的、可编辑的、可版本化的 SKILL.md 工件。它可以记录触发条件、行为规范、工作流程、反模式、风格要求和工具使用方式。

AutoSkill 因此被设计成一个模型无关的插件层。它不重训底座模型，而是在模型外维护技能库：从交互中抽取候选技能，把它们写成标准化工件，检索相关技能注入未来请求，并在后续反馈中合并、修订和升级版本。能力增长发生在技能层，而不是参数层。

论文还用 WildChat-1M 的真实用户交互做经验抽取实验，按中文/英文和 GPT-3.5/GPT-4 切分出四个 SkillBank 子集，展示抽取技能的规模、类别、标签和案例。结果显示，技能不仅覆盖编程和数据任务，也覆盖写作、翻译、角色扮演、平台文案和心理支持等多种稳定行为模式。

为什么只做长期记忆还不够

长期记忆系统通常保存用户事实、偏好、对话片段或过去事件。它们能回答“用户以前说过什么”，但不一定能回答“系统以后应该怎样做”。例如用户多次要求报告遵循某种写作风格，如果系统只是保存原话，下次仍需要在上下文里检索一段旧对话，再由模型临时理解成行为约束。

AutoSkill 的切入点是把这类经验操作化。用户反复表达的不是一条事实，而是一种行为模式：如何改写文本，如何回答心理支持问题，如何生成小红书文案，如何写 Selenium 自动化脚本。这些内容更像技能，而不是记忆。

这也解释了论文与参数自进化方法的区别。参数更新可以改变模型行为，但成本高、不透明，也很难在用户级偏好上频繁微调。AutoSkill 把个性化能力外置为可编辑文件，既能持续演化，又不会破坏底座模型的稳定性。

从系统角度看，这是一种更可控的终身学习。技能可以被审查、修改、删除、合并和版本回滚；用户可以看到系统到底沉淀了什么偏好；开发者可以管理技能库质量。这些都是纯参数更新或隐式记忆很难提供的能力。

技能工件：把行为知识写成 SKILL.md

AutoSkill 的基本积累单元是标准化技能工件。论文中的技能卡片通常包含标识、版本、描述、标签、触发词、提示主体、沟通风格、操作规则、工作流程和反模式。这样的结构让技能既适合机器检索，也适合人类检查。

技能描述回答“这个技能做什么”，标签和触发词回答“什么时候应该召回”，提示主体回答“召回后怎样影响模型行为”，操作规则和反模式回答“执行时要遵守什么边界”。版本字段则记录技能是否经历过迭代修订。

这种工件化有两个好处。第一，它让技能可迁移。只要不同智能体都理解同一种 SKILL.md 结构，技能就能跨模型、跨用户、跨任务共享。第二，它让技能可治理。团队可以检查技能是否过时、是否重复、是否包含风险指令，必要时做合并或降权。

技能工件还允许软技能和硬技能共存。心理咨询师风格、猫娘角色扮演、小红书文案属于偏风格和人设的软行为；专业文本改写、Selenium 自动化脚本生成属于更明确的执行流程。AutoSkill 用同一格式承载它们，说明技能并不局限于工具调用，也包括长期稳定的交互偏好。

生命周期：抽取、检索、注入、演化

AutoSkill 的核心不是一次性生成技能，而是完整生命周期。系统先从对话和交互事件中识别可复用行为，再把它总结为结构化技能；未来用户请求到来时，系统检索相关技能并注入生成过程；交互结束后，再判断是否需要创建新技能或更新已有技能。

这个闭环解决了两个问题。一个是冷启动之后的积累：用户每次重复说明偏好，系统都可以把这些经验进一步固化。另一个是避免碎片堆积：如果新经验与已有技能相似，AutoSkill 不创建重复技能，而是检索旧技能并合并更新，形成版本演化。

1Require: interaction trace $T$, skill repository $R$, current query $q$2Ensure: response $y$ and updated repository $R'$3$C \leftarrow ExtractCandidateSkills(T)$4for each candidate $c$ in $C$:5  $S \leftarrow RetrieveSimilarSkills(c, R)$6  if $S$ contains reusable skill:7    $s' \leftarrow MergeAndRefine(S, c)$8    IncrementVersion($s'$)9  else:10    $s' \leftarrow CreateSkillArtifact(c)$11  Save $s'$ into $R$12$K \leftarrow RetrieveRelevantSkills(q, R)$13$y \leftarrow GenerateResponse(q, K)$14return $y, R$

这里最关键的是“合并而不是堆积”。如果用户多次要求专业英文改写，系统不应该生成几十个类似 prompt，而应该把新约束持续合并进同一个技能。例如论文案例中的 professional_text_rewrite 已经演化到 0.1.34，说明它经历了多轮增量优化。

这种版本化让技能演化可观察。某个技能版本很高，说明相关偏好反复出现、被多次修订；某个技能仍是初始版本，说明它可能是低频或尚未充分验证的能力。对技能库维护来说，版本本身就是一种使用和演化信号。

系统架构与在线服务路径

AutoSkill 的系统架构可以看作一个外部能力层。底座模型负责通用语言理解和生成；AutoSkill 负责管理可复用行为知识。两者通过提示和检索连接，而不是通过参数耦合连接。

在线服务路径通常是：用户发起请求，系统解析当前意图，从技能库中检索相关技能，把技能正文或关键片段插入提示，再调用底座模型生成回答。回答完成后，系统根据交互内容和反馈判断是否产生新的可复用经验。

混合技能检索很重要。只靠关键词容易漏掉语义相近但表达不同的请求；只靠语义向量又可能忽略明确触发词或标签。AutoSkill 因此可以结合标签、触发词、描述和语义匹配，让技能召回既有精确匹配，也有泛化能力。

技能条件化生成则把检索结果转成行为约束。例如召回“专业文本改写”技能后，模型不仅知道要改写文本，还知道不能添加解释、不能丢失事实、不能输出多个版本。召回“心理咨询师”技能后，模型会获得温暖、非评判、尊重隐私、避免医疗诊断等风格约束。

这个架构的优点是低侵入。它可以接入不同模型和智能体框架，只要系统能在调用模型前插入检索到的技能内容。它也天然支持人工审查，因为技能是文件化工件，而不是模型内部不可见状态。

实验与 SkillBank 统计怎么读

论文使用 WildChat-1M 真实用户交互语料，并筛选超过八轮的长对话，因为短对话很难形成稳定偏好和可复用行为。随后作者按语言和模型家族构建四个子集：中文 GPT-3.5、英文 GPT-3.5、中文 GPT-4、英文 GPT-4。

统计结果显示，英文 GPT-3.5 子集最大，包含 10,243 段对话、267,681 条消息和 631 个抽取技能；中文 GPT-4 子集最小，包含 1,145 段对话、36,834 条消息和 224 个技能。四个子集合计在类别图中对应 1,858 个技能。

标签分布很有信息量。高频标签包括 Python、JavaScript、Excel、C++、creative writing、formatting、pandas、education、translation、automation、PyTorch 等。这说明真实用户交互中，最容易沉淀成技能的往往是高频技术任务、写作任务和格式化任务。

类别分布也类似。编程与软件开发有 482 个技能，写作与内容创作 363 个，数据与 AI/ML 354 个，系统/DevOps/配置 194 个，通用混合 356 个。相比之下，研究教育、运营营销和其他领域技能更少。这说明 AutoSkill 能覆盖多领域，但早期技能库中心仍是技术和写作生产力任务。

平台相关统计显示，Twitter/X、Instagram、YouTube、抖音/TikTok、微信公众号、LinkedIn、小红书和微博都有出现。其中 Twitter/X 和 Instagram 最高。这类平台技能通常与内容生成、风格模仿、运营发布或平台特定文案有关，也说明技能工件能保存平台语境下的写作习惯。

案例研究：软偏好与硬流程都能变成技能

论文展示的中文“顶级心理咨询师”技能是一类软偏好。它不是某个单次任务，而是一种稳定对话方式：温暖、有同理心、专业、非评判、尊重隐私，并避免医疗诊断或药物建议。这样的技能适合在用户需要心理支持类对话时反复调用。

英文 professional_text_rewrite 则是硬流程型技能。它要求提升英文文本的流畅性、语法和专业语气，同时严格保留原始含义、事实、数字、名称和意图。它还明确禁止解释修改、提供多个版本或添加外部信息。这个技能已经到 0.1.34，体现了持续合并和精炼。

附录还有多个技能卡片。八字命理大师技能带有娱乐免责声明和传统文化角色约束；小红书种草笔记技能强调学习阶段与生成阶段分离、年轻女性受众、emoji 和标签；猫娘角色技能强调固定前后缀和人设一致性；Selenium 自动化技能则包含可执行 Python 脚本生成流程、显式等待、动态内容稳定检查和反模式。

这些案例说明，AutoSkill 的技能表示不是单一 prompt 模板。它可以保存角色、人设、风格、流程、工具、代码规范、安全边界和输出格式。只要某种行为在交互中重复出现，并且能被结构化描述，它就可以成为技能。

局限与工程复用

AutoSkill 的第一个边界是抽取质量。系统需要判断哪些交互经验值得沉淀为技能，哪些只是一次性上下文。如果抽取过于激进，技能库会充满低质量碎片；如果过于保守，又会错过有价值偏好。论文展示了框架和案例，但真实部署还需要更强的筛选、置信度和人工审查机制。

第二个边界是合并策略。两个技能相似不代表应该合并，两个技能不同也不代表不能共享子规则。比如“专业文本改写”和“公文润色”可能部分重叠，但输出风格和边界不同。合并器需要理解技能功能边界，否则会把清晰技能合成混乱技能。

第三个边界是安全。技能会长期影响模型行为，如果某个技能包含不合适偏好、越权工具流程或误导性角色设定，它可能在未来反复被注入。AutoSkill 的可编辑性提供了治理入口，但实际系统仍需要权限、审核、风险标签和撤销机制。

第四个边界是实验形式。论文主要展示 SkillBank 统计和案例，说明框架能从真实对话中抽取多样技能；但它没有像某些 benchmark 那样大规模量化“注入技能后任务成功率提升多少”。因此读者应把它理解为系统框架和数据分析论文，而不是完整闭环评测论文。

对工程复用来说，可以从小版本做起。先为高频任务设计 SKILL.md schema，再记录用户重复偏好和常用流程；然后加入检索，让系统在新请求中自动注入相关技能；最后再做版本化合并和人工审核。这样不需要一开始就实现全自动自进化，也能获得跨会话能力积累。

读完之后应带走的判断

AutoSkill 最重要的启发是：经验只有被操作化，才会变成能力。原始记忆告诉模型过去发生了什么，技能工件告诉模型未来应该怎么做。个性化智能体要长期变强，不能只扩大记忆库，还要建立技能库。

这篇论文也解释了为什么 skill 自进化需要生命周期视角。生成一个技能只是开始，更关键的是后续如何检索、注入、反馈、合并、版本化和治理。没有这些环节，技能会变成碎片；有了这些环节，交互经验才可能逐步结晶成稳定能力。

从 Agent 产品角度看，AutoSkill 提供了一条成本可控的路线：不改底座模型，不要求每个用户单独微调，而是在外部沉淀可解释、可编辑、可迁移的行为工件。它把长期个性化从“记住用户说过什么”推进到“学会用户希望你怎么做”。

最后，把 AutoSkill 和 SkillRouter 放在一起看会很有意思。AutoSkill 解决技能如何从经验中生成和演化，SkillRouter 解决大规模技能如何被准确召回。前者让技能库生长，后者让技能库可用。真正成熟的 skill 系统，大概率需要两者同时存在。

为什么“技能”比“偏好文本”更适合长期个性化

长期个性化最难的地方，不是把一句偏好存下来，而是让偏好在合适的时刻变成稳定行为。比如用户说过“以后写邮件要正式一点”，这句话作为记忆很容易保存；但下一次用户让模型改写产品公告时，系统需要判断这条偏好是否相关、应该影响哪些措辞、是否要保留原文事实、是否禁止额外解释。只有当偏好被组织成技能，系统才更容易把它转成可执行约束。

技能还有组合性。一个真实任务可能同时需要“专业文本改写”“公司风格”“不要添加解释”“保留数字和日期”几个规则。原始记忆通常是散落的，组合时容易冲突；技能工件则可以把相关规则整理进同一个工作流或通过检索返回多个可组合技能。这样，长期个性化不再只是记住很多碎片，而是形成可调用的行为模块。

技能也更适合人类治理。用户或管理员可以打开一个 SKILL.md，看到它的触发词、描述、规则和反模式。如果某个偏好过时，可以改；如果两个技能重复，可以合并；如果某个规则有风险，可以降权或删除。相比之下，原始记忆片段数量一多，谁也很难判断哪条记忆会在未来如何影响模型。

从产品角度看，这种可治理性很关键。一个长期运行的个人智能体会积累大量用户风格、工作习惯和敏感偏好。系统不能只追求“越记越多”，还必须保证用户知道系统记住了什么、这些内容如何被使用、什么时候可以撤销。技能工件正好提供了这种可见边界。

技能抽取最容易出错的地方

AutoSkill 的自动抽取听起来很顺，但真实落地会遇到不少边界。第一个问题是一次性请求和长期偏好的区分。用户今天要求“这次请写得活泼一点”，不一定意味着以后都要这样；用户连续多次要求某种风格，才更像稳定偏好。抽取器如果不区分这两者，会把临时上下文误写成长期技能。

第二个问题是技能粒度。粒度太细，技能库会出现大量碎片，例如“把句子改正式”“把邮件改正式”“把公告改正式”三个技能其实可以合并；粒度太粗，又会让技能难以准确召回，例如“写作助手”覆盖太多场景，注入后约束不明确。好的粒度应该围绕可复用行为边界：触发条件明确、规则稳定、输出可检查。

第三个问题是冲突处理。用户可能先喜欢简洁回答，后来要求某些场景要详细解释；某个技能要求“不要解释”，另一个技能要求“给出理由”。AutoSkill 的版本化合并可以记录变化，但还需要冲突检测和优先级策略。否则技能越多，约束之间越容易互相拉扯。

第四个问题是安全边界。某些技能来自角色扮演或娱乐需求，例如命理、猫娘、心理咨询风格。它们可以作为交互偏好保存，但必须有清楚免责声明和反模式，避免在医疗、法律、投资等高风险场景被误用。技能抽取不能只看用户喜欢什么，也要看这些行为是否适合长期复用。

第五个问题是评估。一个技能看起来写得完整，不代表注入后一定提升质量。系统需要通过后续任务成功率、用户反馈、人工审核或对比实验来判断技能是否真的有用。否则技能库可能积累很多“看起来合理但很少发挥作用”的工件。

和 SkillRouter 的互补关系

AutoSkill 解决的是技能从哪里来，SkillRouter 解决的是技能多起来后怎么找。前者让系统不断从交互经验中产生和更新技能，后者让系统在大规模技能库中准确召回相关技能。两者其实是一条链上的两个环节：没有 AutoSkill，技能库增长慢；没有 SkillRouter，技能库增长后难以使用。

这种互补关系也提醒我们，技能自进化不能只关注生成。一个系统如果很会生成新技能，却不会检索、去重和合并，很快会形成噪声库。反过来，一个系统如果有很强检索器，但技能本身不能从新经验中更新，能力就会停滞。成熟的技能系统需要“生成、维护、召回、执行、反馈”全链路。

AutoSkill 的版本字段可以成为 SkillRouter 的排序特征。高版本技能通常说明它被反复触发和修订，可能更成熟；低版本技能可能仍处于初始状态，需要更谨慎使用。当然，版本不等于质量，但它提供了一个额外信号。未来系统可以把版本、使用频次、成功率和用户评分一起用于路由排序。

反过来，SkillRouter 的混淆日志也能帮助 AutoSkill 改进技能库。如果两个技能经常在召回时互相竞争，说明它们描述相近或功能重叠，可能需要合并、改名或补充边界。如果某类用户请求总是找不到合适技能，说明 AutoSkill 应该从这些交互中抽取新技能。路由失败因此也能成为技能演化信号。

如何在自己的 Agent 项目里复用

最小可行版本可以很朴素。先选一个高频领域，比如代码审查、报告改写、数据分析或社交媒体文案。然后定义一个固定技能模板，包含名称、描述、标签、触发词、适用条件、操作步骤、反模式和示例。接着从真实会话中手工或半自动整理十到二十个技能，先验证注入这些技能是否能减少用户重复说明。

第二步再引入检索。早期可以用关键词和标签匹配，不必马上训练复杂模型。只要能把当前请求和技能触发词对上，就能验证技能注入是否有价值。等技能数量增长后，再加入向量检索和重排，逐渐处理语义相似但词面不同的请求。

第三步加入反馈。每次技能被召回后，记录用户是否接受、是否要求修改、是否出现错误。对于高频修改，可以提示系统更新技能；对于低质量技能，可以要求人工审核。这样，技能库不会只是静态资料夹，而会随着使用逐步变好。

第四步处理版本和合并。不要让每次反馈都创建新技能。应先检索相似技能，如果属于同一行为模式，就合并进旧技能并提升版本；如果确实是新能力，再创建新技能。这个策略能防止技能库快速膨胀，也让用户看到某个技能是如何逐步成熟的。

第五步建立可视化管理界面。长期个性化涉及用户信任，最好让用户能查看、禁用、编辑或删除技能。比如用户可以看到“专业文本改写”技能目前有哪些规则，也可以移除某个不再需要的风格偏好。AutoSkill 的文件化表示很适合做这种管理入口。

论文没有完全解决的问题

这篇论文提出的是框架和系统思路，而不是所有问题的最终答案。它展示了 SkillBank 统计和代表性案例，但还需要更系统的任务级评估来证明技能注入在不同任务上稳定提升成功率、减少轮次或改善用户满意度。未来工作可以设计对照实验：同一模型在无技能、原始记忆、AutoSkill 技能三种条件下完成长期个性化任务。

另一个问题是技能质量自动评估。一个技能可能语法清楚，但规则过宽；也可能规则很多，却互相冲突。系统需要自动检查技能是否有明确触发条件、是否包含危险约束、是否与已有技能重复、是否有可测试的输出边界。没有质量评估，自进化可能变成自我污染。

还有跨用户共享问题。某些技能是个人偏好，不应该共享；某些技能是通用工作流，可以迁移给其他用户；某些技能包含敏感信息，必须隔离。AutoSkill 提出共享和转移的可能性，但真实系统需要权限、脱敏和组织边界。

最后，技能和模型本身的关系仍需研究。外部技能可以弥补不重训的需求，但过长或过多技能注入也会占用上下文，并可能与模型默认行为冲突。未来系统需要更好的技能压缩、优先级排序和冲突消解策略，让技能真正成为轻量能力层，而不是新的上下文负担。

技能生命周期中的关键判断点

AutoSkill 的生命周期看起来线性，但每一步都有判断。第一步是“是否值得抽取”。不是所有对话都应该变成技能。一次性事实、临时上下文、用户当下情绪和一次性任务参数通常更适合放进记忆或当前会话，而不是写成长期技能。只有当某种行为要求具有复用性、稳定性和可描述边界时，才适合进入技能库。

第二步是“抽取成什么形态”。同样的交互可以被抽成风格技能、流程技能或约束技能。例如用户多次要求“不要解释，只给改写结果”，这可以成为专业改写技能的一条反模式；用户多次要求“先检查依赖，再生成脚本”，这更像工作流程；用户多次要求“用温暖语气回应心理困扰”，这则偏风格和安全边界。抽取器需要识别经验属于哪种行为类型。

第三步是“新建还是合并”。这是技能自进化的核心。新建太容易会导致技能库膨胀，合并太激进会导致技能边界模糊。一个实用规则是：如果新经验与已有技能共享触发场景、目标产物和核心约束，就倾向合并；如果只是同领域但目标不同，就保留为独立技能。例如“专业文本改写”和“学术摘要压缩”都属于写作，但输出目标不同，不应强行合并。

第四步是“版本如何更新”。版本号不是装饰，它反映技能演化历史。每次合并都应该记录变更原因：新增了触发词、修正了反模式、补充了输出格式，还是删除了过时约束。这样，当技能表现变差时，维护者可以回滚或比较版本差异。没有变更日志的版本化，很难真正支撑长期维护。

第五步是“什么时候注入”。检索到技能不代表必须完整注入。系统应该考虑相关度、任务风险、上下文预算和技能优先级。低相关技能不应硬塞；高风险技能需要确认；多个技能冲突时需要排序或合并提示；长技能可以只注入关键片段。这个阶段决定了技能是否真正改善响应，而不是变成上下文噪声。

技能库质量如何维护

技能库会随时间增长，因此质量维护必须成为系统功能。最基本的是去重。重复技能会让检索结果分散，也会让用户难以理解系统到底遵循哪个规则。去重不一定意味着删除，可以先建立等价关系，把多个技能标记为同一能力族，再逐步合并为一个主技能。

第二是过期检测。用户偏好会变化，平台规则会变化，工具接口会变化。一个 Selenium 脚本生成技能如果还在推荐过时 API，就会影响未来任务。系统需要根据失败日志、用户修改和工具报错识别过期技能，并提示更新或降权。

第三是冲突检测。比如一个技能要求“只输出最终答案”，另一个技能要求“解释每一步推理”；一个技能要求“语气活泼”，另一个技能要求“正式公文风”。当多个技能同时被召回时，系统必须知道哪些约束优先。可行做法是给技能标注作用域和优先级：任务流程约束优先于风格偏好，安全约束优先于角色扮演，用户显式当前指令优先于历史偏好。

第四是可解释召回。用户可能想知道为什么模型突然换了写法，或者为什么回答带有某种固定格式。系统应该能展示“本次使用了哪些技能”，并允许用户禁用或修改。这对个人数字替身尤其重要，因为长期个性化如果不可见，就容易变成不可控的隐性偏见。

第五是技能效果评估。可以统计技能被召回次数、用户接受率、后续修改率、任务成功率和人工评分。高召回低接受的技能可能写得不清楚或触发过宽；低召回高质量的技能可能缺少触发词；高失败率技能需要审核。通过这些指标，技能库可以像代码库一样被持续维护。

AutoSkill 与传统 RAG 的差异

AutoSkill 很容易被误解成一种检索增强生成，但二者的目标不同。传统 RAG 检索的是外部知识，主要解决事实准确性和信息覆盖问题；AutoSkill 检索的是行为规范，主要解决个性化、流程复用和跨会话能力积累问题。一个回答可能同时需要两者：RAG 提供事实材料，AutoSkill 提供写作风格和处理流程。

RAG 文档通常是被动知识，模型读取后再决定如何使用。技能则更接近主动约束，它会直接规定模型应该怎样回答、怎样组织步骤、怎样调用工具、哪些行为不要做。比如检索到一篇政策文档只是告诉模型政策内容；检索到一个“官方公文写作”技能则会要求模型使用特定语气、结构和措辞。

传统记忆也不同。记忆可以保存“用户喜欢简洁回答”，但技能会进一步写成“回答时先给结论，再给三条要点，避免长背景解释，除非用户要求展开”。后者明显更可执行。AutoSkill 的价值就在于把模糊偏好变成操作模板。

当然，AutoSkill 可以和 RAG 结合。一个专业报告任务可能先用 RAG 检索企业知识库，再用 AutoSkill 注入企业报告风格，最后用工具生成文件。这样，知识、风格和工具流程分别由不同模块负责，系统结构更清楚。

数据统计背后的含义

SkillBank 统计中，编程与软件开发占比最高并不意外。编程任务天然有重复流程：安装依赖、调试错误、生成脚本、处理数据、调用库、配置环境。用户在这些任务中反复表达的要求也更容易结构化，例如“用 Python”“输出完整代码”“不要省略 imports”“使用显式等待”。这类经验非常适合变成技能。

写作与内容创作占比也很高，因为风格偏好具有强复用性。用户会反复要求更正式、更简洁、更像小红书、更适合公众号、更有营销感或更像学术摘要。与事实记忆相比，写作风格更需要技能化，因为它影响的是输出过程，而不是某个具体事实。

数据与人工智能类技能说明，用户经常围绕 Pandas、PyTorch、Excel、Matlab 等工具形成稳定工作流。这些技能往往介于软偏好和硬流程之间：既包含代码生成规则，也包含数据处理习惯、图表输出格式和调试策略。

平台相关技能说明，技能库也会捕捉具体生态。不同平台有不同语言风格、内容结构、标签习惯和受众预期。把这些平台偏好沉淀成技能，能减少用户每次重复说明平台语境的负担。这类技能也最需要边界管理，因为平台规范和流行风格变化很快。

版本案例则说明技能演化是不均匀的。高频生产力技能更容易被反复调用和修订，版本增长快；低频角色或场景技能可能长期停在初始版本。这个现象很自然，也有用：系统可以优先审核高频高版本技能，因为它们对用户体验影响更大。

对个人数字替身的意义

论文提到 personal digital surrogates，这个词背后是更长期的目标：一个智能体不仅能回答问题，还能逐步体现用户的稳定习惯、价值偏好和工作方式。要做到这一点，仅靠一次对话上下文不够，靠零散记忆也不够；系统需要把长期经验组织成可执行能力。

技能工件是这个目标的一种现实落点。它不要求模型真的“变成用户”，而是让系统保存一组可检查的行为规则：用户喜欢怎样写邮件，如何处理数据，怎样回复客户，哪些表达要避免，哪些流程要固定执行。这些规则组合起来，智能体就会越来越像一个熟悉用户工作方式的助手。

个人数字替身还需要可控性。用户应当能知道系统学习了什么，并能删除不想保留的技能。如果智能体默默吸收所有行为习惯，可能造成隐私和偏见风险。AutoSkill 的显式技能设计提供了一个可控接口：长期学习不是黑箱吸收，而是可见工件的积累和修订。

这也让多设备、多模型协同成为可能。用户今天在一个模型上形成的技能，明天可以迁移到另一个模型或另一个 Agent 框架中。只要技能格式标准化，个性化能力就不必绑定单一模型账户。对用户来说，这意味着自己的过程知识可以成为可携带资产。

未来评测可以怎样设计

要更严格评估 AutoSkill，可以设计长期多会话任务。第一轮让用户表达偏好，第二轮给类似但不完全相同的任务，看系统是否能自动复用偏好；第三轮加入偏好修改，看系统是否能更新技能；第四轮制造冲突，看系统是否能按优先级处理。这比单轮任务更能体现终身学习价值。

还可以比较三种条件：无长期状态、原始记忆检索、AutoSkill 技能注入。无长期状态测试底座模型能力；原始记忆检索测试保存过去文本的收益；技能注入测试操作化经验的收益。如果 AutoSkill 有效，它应当在减少用户重复说明、提高输出一致性和降低修改次数上优于原始记忆。

评测指标也应多样。除了任务成功率，可以看偏好遵循率、格式正确率、用户编辑距离、技能召回准确率、技能冲突率、用户信任度和人工可解释性评分。对于技能库本身，还可以评估重复率、过期率、平均版本数和高风险技能比例。

最后，评测应包含安全和撤销。系统学习到错误偏好后，用户能否删除？删除后是否真的不再影响生成？技能合并后能否回滚？这些问题决定长期个性化是否可信。AutoSkill 的文件化和版本化为这些评测提供了基础，但具体协议仍值得进一步研究。

因此，AutoSkill 的真正价值不只是“自动写技能”，而是把长期个性化拆成可管理的系统工程：经验如何被发现，技能如何被表示，旧技能如何被更新，新请求如何被召回，错误偏好如何被撤销。只有这些问题都有明确接口，智能体才可能在长时间使用中稳定变得更懂用户，而不是只在当前会话里显得聪明。

这也是技能自进化成为独立主题的原因：它关注能力如何沉淀、治理和复用。