自己给自己造工具，字节跳动的 Agent 超过了人类专家写的技能

2026 年 5 月 26 日，字节跳动 ByteBrain 团队在 arXiv 上发布了一篇题为《MUSE-Autoskill: Self-Evolving Agents via Skill Creation, Memory, Management, and Evaluation》的论文。论文第一作者林华威来自美国罗切斯特理工大学，实习期间在字节完成这项研究；通讯作者张铁英来自字节跳动。这支团队做的事情，用一句话概括：让 AI Agent 能自己给自己造工具，越用越聪明。

这个时间节点本身有意思。就在同一周，开源 Agent 框架 DeerFlow 正在 GitHub Trending 持续发酵，字节旗下的 Doubao 2.0 已经全面转向"Agent 时代"，Anthropic 的 Agent Skills 开放标准也刚刚推出不久。整个行业正在从"模型够不够聪明"的讨论，快速切换到"Agent 会不会用工具、能不能积累经验"这条新战线。MUSE-Autoskill 这篇论文，恰好站在这条战线最前沿。

但它提出的核心问题，其实很朴素：现有 Agent 造出来的技能，都是"用完就扔"的——没有记忆，没有测试，没有改进。能不能换一种思路，把技能当成有生命周期的资产来管理？

先说说"技能"是什么

理解 MUSE-Autoskill，必须先说清楚"技能（Skill）"这个核心概念。

在这个框架里，技能不是 Agent 大脑里的知识，而是一个放在文件系统里的目录，遵循 Anthropic 制定的 Agent Skills 开放标准。它的结构很简单：必须有一个 SKILL.md 文件，定义技能的名称、描述、输入输出接口；可以有 scripts/ 存放可执行代码、resources/ 存放辅助数据、tests/ 存放单元测试。

打个比方：如果把 Agent 比作一位厨师，技能就是他的菜谱本。SKILL.md 是菜谱的封面和步骤说明，scripts/ 是预处理好的半成品食材，tests/ 是每次做完这道菜之后用来验证味道是否达标的标准。

为什么要做成这种格式？因为它是可移植的。一位厨师学会的菜谱，可以直接给另一位厨师用，不需要重新解释原理。这正是 MUSE-Autoskill 后来做到"跨 Agent 技能迁移"的基础。

现有框架缺了什么

技能这个思路并不新鲜。Minecraft 里的 Voyager、通用 Agent 框架里的 AutoSkill、EvoSkill，都在往这个方向走。但论文指出了现有方案普遍存在的四个缺口：

创建和使用脱节。 技能是在 Agent 运行上下文之外预先生成的，生成者并不了解 Agent 实际跑任务时遇到的具体问题。

没有技能级别的记忆。 Agent 用过一个技能之后，学到的教训会消失——下次碰到同样的技能，还是从零开始。

技能不经测试就上线。 没有单元测试，没有验证机制，一个错的技能和一个对的技能在库里地位相同。

上下文管理差。 长任务积累的对话历史会把模型的 token 窗口撑爆，导致关键早期信息丢失。

这四个问题叠加在一起，结果就是：Agent 造技能越多，技能库越乱，用起来越不可靠。

统一生命周期：从"用完就扔"到"长期资产"

MUSE-Autoskill 的核心贡献，是把技能的管理抽象成一个五阶段的统一生命周期：创建、记忆、管理、评估、改进。

每一个阶段在系统里都有具体机制落地：

创建阶段，Agent 在任务执行的 ReAct 循环内部，通过内置的 skill_create 工具实时生成技能，同时生成 SKILL.md、scripts/、tests/ 等完整包。技能不是离线批量生产的，而是"按需现场造"。

评估阶段，技能创建完之后不能直接入库——系统会先在沙箱里跑 tests/ 目录里的单元测试。只有所有测试通过，技能才能注册进技能银行（Skill Bank）。测试失败，Agent 检查错误，调用 update_skill 修补代码，循环直到通过为止。这是一个"造完即测，测完才存"的硬门槛。

记忆阶段，这里有一个论文最有创意的设计：每个技能旁边都有一个 .memory.md 文件，记录该技能在历次任务中积累的经验——已知的失败场景、输入格式的坑、性能上的注意事项。下次加载同一个技能时，这份经验会一并注入上下文，Agent 不需要重新踩同样的坑。

管理阶段，每次任务开始时，系统将技能库的目录（只含名称和描述）注入系统提示，Agent 自行决定用哪个技能。对于冗余技能，系统支持合并；对于长期失败或未使用的技能，系统会将其删除。技能库保持精简可用。

改进阶段，当技能在执行过程中产出错误结果时，Agent 直接 patch 代码，再次验证，持续迭代。

五个阶段合在一起，把技能从"一次性耗材"变成了"可维护、可测试、可迁移的知识资产"。

上下文不够用怎么办

长任务还有一个绕不过去的工程难题：对话历史越积越长，模型的 token 窗口撑不住。

MUSE-Autoskill 设计了一套两级自适应压缩机制，思路借鉴了操作系统的内存管理。

整个对话历史被组织成一个有向无环图（DAG），每个节点是一轮（Plan/Action/Observation 三元组）。当总 token 量接近阈值，触发压缩：

一级压缩（L1）：扫描中间节点，找到单独超出大小限制的节点，原地替换成摘要。首尾各保留若干轮不压缩——最早的几轮包含任务背景，最近的几轮包含当前状态，都不能动。

二级压缩（L2）：如果 L1 之后还超预算，说明没有单节点特别大，而是中间积累了太多轮次，此时把中间一段合并成一个合成节点。

关键设计：压缩操作只影响活跃链，原始历史通过不可变的指针链完整保留，支持跨会话恢复和事后回放。压缩不是丢信息，是换一种更省空间的表示方式。

数字说话：自生成技能超过了人类专家写的技能

论文在 SkillsBench 上做了评测，这是一个包含 51 个真实任务的基准，每个任务跑在独立的 Docker 容器里，由自动验证器打分。三个参与对比的 Agent（MUSE-Autoskill、Codex、Hermes）都用 GPT-5.5 作为底座——模型相同，比的是 Agent 系统设计的差异。

结果最重要的几个数字：

带人类专家写的技能时，MUSE-Autoskill 准确率达到 68.40%，高于 Codex 的 67.28% 和 Hermes 的 61.21%。

更值得关注的是第二组数据：MUSE-Autoskill 从自己的成功轨迹中生成技能（35 个任务成功生成），再用这些自生成技能重新跑同样的任务，准确率达到 87.94%，超过了人类专家写的技能所能达到的上限（68.40%）。

为什么自己造的技能反而更好？论文给出的解释很直接：从真实成功轨迹里蒸馏出来的技能，包含了针对这个具体任务的程序性知识——输入输出格式、工具选择、失败处理逻辑——而人类写的通用技能往往只写了大方向，把细节留给 Agent 自己推理。

还有一组数据证明了技能的可移植性：把 MUSE-Autoskill 生成的技能原封不动注入另一个 Agent（Hermes），Hermes 的准确率从 47.89% 提升到 58.40%，抹平了和"Hermes + 人类技能"之间 79% 的差距。两个 Agent 架构不同，提示不同，但技能本身作为可读文档和脚本，跨系统传递没有损耗。

效率反直觉：技能越详细，Token 反而越省

MUSE 生成的技能平均有 326 行，是人类专家写的技能（146 行）的 2.2 倍。直觉上，技能越长，加载进上下文消耗的 Token 越多，成本越高。

实际数据完全相反。

在 35 个有自生成技能的任务上：

MUSE-Autoskill 使用人类技能时，中位 Token 用量 615K，耗时 656 秒使用自生成技能时，中位 Token 用量降到 493K（-20%），耗时降到 411 秒（-37%），轮次从 19 轮降到 15 轮Hermes 使用相同的 MUSE 生成技能时，Token 用量从 186K 降到 97K（-48%），耗时从 369 秒降到 257 秒（-30%）。

机制是这样的：技能里详细的程序性说明，替代了 Agent 在任务执行过程中大量的探索性推理。用一个更长的"菜谱"换掉了更多轮次的"边做边想"，总账反而更划算。生成一个技能的一次性成本约为 383K Token 和 164 秒，但从第一次复用起就开始回本。

论文专门提了一个有意思的细节：MUSE 是 51 个 Agent 里 Token 消耗最重的（515-577K），但因为自适应压缩控制了每轮的 prompt 规模，它的延迟尾部（P90）反而比 Codex 短。深循环不一定慢，关键在于每轮的成本是否可控。

一个失败案例和它说明的问题

论文没有回避回归案例。hvac-control 任务要求用 PI 控制器驱动一个热力学模拟器，MUSE 的准确率从基线的 80% 跌到了使用自生成技能后的 20%。

原因在于：蒸馏技能所用的那条成功轨迹，包含了针对特定随机噪声分布的校准逻辑。这套校准参数在其他随机种子下不稳定，偶尔产生超出验证器容忍范围的增益值。技能把一次碰巧成功的策略固化下来了，而不是提炼出通用的控制原理。

这个问题揭示了技能生成的一个根本局限：单条轨迹蒸馏，很容易把任务特异性的细节当成通用知识编码进去。论文提出的改进方向是从多条轨迹（包括部分失败的轨迹）中综合提炼，而不是等一条完美轨迹出现再蒸馏。

技能生命周期管理的产业化走向

论文专门用一节篇幅描述了已在生产中落地的三个系统，给出了这套思路的产业走向：

SkillMarket：对终端用户开放技能创建流水线，把成功轨迹直接蒸馏成可分享的技能包，无需人工编写。计划加入技能版本管理和持续更新机制。

ArkClaw：接入技能检索能力，让 Agent 在造新技能之前先查查已有的。还计划支持把整个 Agent 当成一个可调用的子 Agent，一个技能可以封装完整的多 Agent 协作行为。

SkillHub：把整个技能生命周期（创建、评估、记忆、管理、改进）做成托管服务，团队共享技能库，技能改进自动传播给所有依赖它的 Agent 和产品。

这三个系统合在一起，指向同一个方向：技能不只是单个 Agent 的私有工具，而是团队级别、产品级别的共享知识基础设施。一个技能的改进，可以同时惠及所有使用它的下游系统。

Q&A

Q1：MUSE-Autoskill 生成的技能，为什么能超过人类专家写的技能？

人类专家写的 SkillsBench 技能是针对一类问题设计的通用指南，偏向告诉 Agent "要做什么"，把具体实现细节留给 Agent 推理。MUSE 从真实成功执行轨迹中蒸馏技能，能捕获"这个任务实际上怎么做才对"——包括输入格式、工具调用顺序、错误处理模式等程序性细节。通用指南 vs 针对性操作手册，后者在具体任务上的命中率更高。代价是在同一任务分布之外的泛化性可能较弱。

Q2：技能级别的记忆（.memory.md）和通用的长期记忆有什么本质区别？

通用长期记忆记录的是跨任务的全局经验，比如"这个环境偏好批量 I/O"，粒度是 Agent 级别的。技能级别的记忆绑定在具体技能上，记录的是"当这个技能被调用时，已经遇到过哪些坑"——比如某个 PDF 解析技能在文件超过 100MB 时会超时。这种经验只有在执行同一个技能时才有意义，混进全局记忆里反而是噪声。把经验的归属明确到技能粒度，是这个设计最细致的地方。

Q3：自生成技能只能覆盖 68.6% 的任务，剩下那些为什么做不到？

失败的 16 个任务有两个集中成因：一是需要特定专有工具的深度知识（比如 Azure BGP 路由诊断、特定 LLM 服务栈的日志回放），这类知识不在预训练模型的知识范围内，也无法在任务内从文档推导；二是需要重型数值计算或非文本格式解析（比如偏微分方程求解、Excel 损坏文件恢复），基线成功率本身就接近零，没有成功轨迹可以蒸馏。瓶颈在"Phase 1 能不能解对"，而不是"技能质量"。