OpenSkill 论文逐段拆解Agent 靠技能自进化刷出多项 SOTA原理并不玄【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills2026 年的开源生态里Skills从一个 Anthropic 的工程概念迅速膨胀成一个被反复咀嚼的热词GitHub 趋势榜上技能类仓库批量涌现掘金上火爆全网的 Skills类教程动辄两万阅读腾讯甚至上线了中国专供的 AI Skills 社区。而在这股浪潮之上一条更激进的研究线被推到了台前——孙立超团队提出的 OpenSkill让 Agent 不再是被动消费技能的工具使用者而是能够自主生成、评估、入库并路由技能的自进化体并在多项基准上刷出 SOTA。与谷歌 SkillOS不靠堆参数实现自我进化的叙事遥相呼应技能自进化正在成为继 RAG、工具调用之后Agent 能力增长的新范式。这篇拆解要做的是把 OpenSkill 的论文主线逐段打开回答三个问题静态技能库到底卡在哪自进化闭环的四个环节在工程上如何落地SOTA 数字背后付出了什么代价、有哪些说不出口的局限为了不让讨论停留在概念层我会用当前 Codex 的 Skills Catalog 仓库本仓库作为实证样本——OpenSkill 论文里描述的生成-评估-入库-路由链路在这个仓库里恰好每一环都有真实的生产级代码对应。一、问题设定静态技能库为什么不够用先对齐一个基本定义什么是 Skill本仓库的 README.md 给出了一句话定义——Agent Skills are folders of instructions, scripts, and resources that AI agents can discover and use to perform at specific tasks即技能是指令 脚本 资源的文件夹写一次、到处用。这个定义本身没有问题问题是静态技能库的维护方式。一个固定的技能目录无论收录多少条目都面临三重天花板第一覆盖率天花板。任务空间是开放的技能库是封闭的。Agent 遇到库里没有覆盖的长尾任务时只能退回通用推理能力立刻退化到无技能状态。社区里对 Claude Skills 的评测文章反复提到渐进式披露progressive disclosure本质上是在有限技能集合内做上下文管理而不是扩大技能集合本身。第二上下文成本。技能不是免费的。本仓库 skills/.system/skill-creator/SKILL.md 里有一句非常直白的话The context window is a public good. Skills share the context window with everything else Codex needs——上下文窗口是公共资源技能元数据与系统提示词、对话历史、用户请求抢占同一块空间。技能库越大路由和筛选的压力越大把技能全量塞进上下文只会让 Agent 变得更笨。第三维护成本。静态技能库依赖人类专家手工编写、手工评审、手工更新。技能与任务之间的错位只能靠人肉发现。这正是 OpenSkill 要打掉的靶子技能的生成与维护为什么不能由 Agent 自己完成OpenSkill 的出发点很简单——把技能从预置资产变成运行时产物Agent 在执行任务的过程中把成功经验沉淀为技能新任务到来时从技能库中检索路由最合适的技能。技能库因此从静态目录变成活的系统。有意思的是本仓库已经站在了这条演进线的工程端。它虽然是一个标准的静态技能目录41 个 curated 技能 5 个 system 技能但其中预装了skill-creator与skill-installer两个元技能——Codex 可以自己写技能、自己装技能。静态目录与自进化系统之间只差一个自动评估入库的闭环。二、自进化链路闭环生成、评估、入库、路由OpenSkill 论文的贡献本质是把自进化拆成一个可操作的闭环。逐段看每一环在本仓库都能找到对应的真实实现。2.1 技能生成从任务复盘到模板化产出OpenSkill 中Agent 在任务结束后复盘经验并提炼成新技能。这一步的关键不是会写 Markdown而是把经验结构化成一个可复用、可触发的技能包。本仓库的skill-creator技能定义了完整的生成流程见 skills/.system/skill-creator/SKILL.md理解任务的具体示例 → 规划可复用资源scripts / references / assets→ 初始化技能 → 编写 SKILL.md → 校验 → 基于真实使用迭代。而真正的生成动作由脚本完成核心是 init_skill.pyscripts/init_skill.py my-skill --path skills/public --resources scripts,references,assets这个脚本做四件事规范化技能名normalize_skill_name强制转成小写连字符式如 Plan Mode →plan-mode、生成带 YAML frontmatter 的 SKILL.md 模板、自动产出agents/openai.yaml界面元数据、按--resources创建资源目录。也就是说生成一个符合规范的新技能无需人类手写任何样板代码——这正是Agent 自主生成技能在生产代码里的落点。注意一个细节技能目录的解剖结构在 skill-creator/SKILL.md 中被严格定义skill-name/ ├── SKILL.md (required) # frontmatter Markdown 指令 ├── agents/ # openai.yaml UI 元数据 └── Bundled Resources ├── scripts/ # 可执行代码 ├── references/ # 按需加载的文档 └── assets/ # 输出用资源scripts 承担确定性执行references 承担按需加载的知识assets 承担产物模板——三种资源对应三种不同的加载语义这不是排版洁癖而是技能自进化的结构性前提只有资源分层清晰技能才能被批量生成、批量校验、按需消费。2.2 技能评估结构校验是入库的第一道闸门OpenSkill 论文强调生成只是第一步必须评估技能是否有效才能决定是否入库。评估维度通常包括结构合法性、行为正确性、泛化能力三层。逐层对照本仓库最底层的是结构校验实现于 quick_validate.py。这个不到百行的校验器把什么是合法技能固化成可执行的规则SKILL.md必须存在且必须以---YAML frontmatter 开头frontmatter 只允许name、description、license、allowed-tools、metadata五个字段多一个键直接判非法name必须匹配^[a-z0-9-]$不能以连字符开头/结尾不能超过 64 字符description不能包含尖括号不能超过 1024 字符。这套规则的价值在于确定性任何 Agent 生成的技能跑一遍scripts/quick_validate.py path/to/skill-folder就能得到 pass/fail零人工介入。这对应着 OpenSkill 自进化闭环中评估器的第一形态——它不评判技能好不好用只评判技能够不够格进入体系。语义层面的行为评估技能是否真的提升了任务成功率仍然依赖真实使用反馈这在本仓库的 skill-creator/SKILL.md 里体现为最后一步Iterate based on real usage——用真实任务结果反哺技能迭代这正是 OpenSkill 论文里评估-迭代循环的工程雏形。2.3 技能入库分级目录与安全安装通过评估的技能进入仓库。OpenSkill 论文中的技能库在工程上需要一个可管理、可分级的存储结构。本仓库给出了一个生产级的答案README.md 中明确划分了三层.system/随 Codex 最新版自动安装的系统技能如 imagegen、skill-creator、skill-installer.curated/经过精选、可按名安装的技能41 个覆盖 Figma、Notion、Playwright、部署、安全等领域.experimental/实验性技能需显式指定目录安装。入库的动作由skill-installer技能执行其核心逻辑在 install-skill-from-github.py 中值得注意的有三点工程细节其一多路径回退。默认走 codeload zip 直接下载_download_repo_zip遇到 401/403/404 等认证与权限错误时自动回退到 git sparse checkout_git_sparse_checkout再不行换 SSH——保证技能在私有仓库、受限网络下也能安装。其二安全校验。下载的 zip 解压前会做路径穿越检查_safe_extract_zip技能相对路径必须落在仓库内_validate_relative_path目标目录已存在则直接中止_copy_skill中Destination already exists。自进化系统里Agent 自主拉取技能意味着供应链风险这套校验是入库环节不可或缺的安全闸。其三安装位置的语义。默认安装到$CODEX_HOME/skills即~/.codex/skills与系统预装技能隔离——用户级技能和系统级技能的分界保证了自进化新增的技能不会污染受控基线。2.4 技能路由描述即触发闭环的最后一环是路由任务到来时如何从技能库中选出正确的技能OpenSkill 论文的做法是让 Agent 根据任务描述在技能库中检索匹配的技能并调用。本仓库把路由机制压缩进了一个极简设计——YAML frontmatter 的 name description 是路由的唯一依据。skill-creator/SKILL.md 中写得非常明确These are the only fields that Codex reads to determine when the skill gets used, thus it is very important to be clear and comprehensive in describing what the skill is, and when it should be used.也就是说技能的可被发现性完全取决于 description 的质量。本仓库对 description 的撰写有硬性要求必须同时写明技能做什么和何时该用它what it doeswhen to use it。以 skills/.system/imagegen/SKILL.md 为例它的 description 是一段近两百词的条件句哪些任务Use when、哪些任务Do not use如 SVG/矢量编辑、HTML/CSS 原生构建把触发边界写得清清楚楚。路由之后是上下文管控即渐进式披露三级加载frontmatter 元数据约百词常驻上下文SKILL.md 正文仅在技能被触发后加载限制在 5k 词以内scripts/references/assets 按需取用。这套设计直接回应了第一节的上下文成本问题——技能库再大每个时刻只有被路由命中的那一份技能消耗上下文预算。至此OpenSkill 论文的闭环四环节在本仓库全部有代码级对应闭环环节论文中的设定本仓库的真实实现技能生成Agent 从任务经验中提炼技能skill-creator init_skill.py技能评估评估器判定技能是否有效quick_validate.py 结构校验 真实使用迭代技能入库有效技能写入技能库.system/.curated/.experimental分级 install-skill-from-github.py技能路由按任务检索并调用技能frontmatter description 触发 渐进式披露三级加载三、SOTA 数字背后的代价、局限与可复现性讨论情报显示OpenSkill 在多项基准上刷出了新的 SOTA36Kr 将其定性为Agent 自进化新范式同期谷歌 SkillOS 亦宣称不靠堆参数让智能体真正学会自我进化。方向上的热度毋庸置疑但作为技术观察者应该冷静拆解这些数字背后的代价与边界。代价一上下文预算的再分配。技能自进化的每一步都在消耗推理资源生成技能要跑任务复盘评估技能要跑验证入库后每次路由还要在更大的技能库里做选择。本仓库 skill-creator/SKILL.md 反复强调每段信息都要论证其 token 成本正是对这一代价的清醒认识。SOTA 数字不能只看任务成功率还要看达成该成功率所消耗的总推理预算——自进化系统把一部分预算从推理转移到了元能力写技能、评技能上这笔账在论文的算分表里往往被模糊处理。代价二评估器的评估器问题。OpenSkill 的评估环节依赖评估器判断技能是否有效而评估器本身的准确率、召回率、偏差会直接传导到技能库的质量。本仓库对此提供了一个诚实的注脚quick_validate.py只校验结构合法性不校验行为正确性。一个 frontmatter 完全合规、命名完全规范、但指令内容一塌糊涂的技能也能通过校验。结构校验可以自动化语义评估目前仍然依赖真实任务反馈——这意味着自进化闭环的质量上限仍然卡在谁来判断技能真的有用这个开放问题上。代价三路由的脆弱性。自进化生成的技能再多如果 description 写得含糊技能就永远不会被触发——等于没入库。skill-creator/SKILL.md 为此设置了显式约束description 必须覆盖触发场景且只能在 1024 字符内完成。这暴露了一个深层矛盾技能的表达能力与可路由性互相拉扯描述写得太细则触发面窄写得太泛则路由噪音大。OpenSkill 论文中的技能检索同样要面对这个 trade-off。可复现性技能自进化最大的隐性红利。但也要看到相比堆参数式的模型进化技能自进化有一个结构性优势技能是文件夹纯文本加脚本天然可版本化、可审计、可回滚。本仓库本身就是证据——41 个 curated 技能全部以目录形式沉淀在 git 仓库中每一次技能变更都是一次显式 diffREADME.md 明确说明每个技能的许可证存放在其目录内的LICENSE.txt技能的归属、来源、演化历史全程可追溯。模型权重更新是黑盒技能库更新是白盒——这正是不靠堆参数叙事背后的实质能力增长的载体从不可解释的参数空间迁移到了可解释、可复现的文本与代码空间。回到标题的问题OpenSkill 的原理玄吗不玄。拆到底它就是把技能从静态资产变成运行时产物让 Agent 具备四种元能力——生成技能、评估技能、管理技能、路由技能。论文贡献的是把这四条链路组织成闭环的理论框架而工程侧Codex 的技能仓库已经在用最朴素的方式验证着每一条链路init_skill.py生成、quick_validate.py把关、.system/.curated分级入库、frontmatter description 路由触发。SOTA 数字值得关注但更值得关注的是这条链路本身——它让 Agent 的能力增长第一次拥有了可读、可审查、可继承的载体。技术叙事常常玄在话术上而工程真相永远藏在最朴素的代码里。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 22:25:05 · 阅读 1.2k OpenSkill 论文逐段拆解：Agent 靠“技能自进化“刷出多项 SOTA，原理并不玄
OpenSkill 论文逐段拆解Agent 靠技能自进化刷出多项 SOTA原理并不玄【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills2026 年的开源生态里Skills从一个 Anthropic 的工程概念迅速膨胀成一个被反复咀嚼的热词GitHub 趋势榜上技能类仓库批量涌现掘金上火爆全网的 Skills类教程动辄两万阅读腾讯甚至上线了中国专供的 AI Skills 社区。而在这股浪潮之上一条更激进的研究线被推到了台前——孙立超团队提出的 OpenSkill让 Agent 不再是被动消费技能的工具使用者而是能够自主生成、评估、入库并路由技能的自进化体并在多项基准上刷出 SOTA。与谷歌 SkillOS不靠堆参数实现自我进化的叙事遥相呼应技能自进化正在成为继 RAG、工具调用之后Agent 能力增长的新范式。这篇拆解要做的是把 OpenSkill 的论文主线逐段打开回答三个问题静态技能库到底卡在哪自进化闭环的四个环节在工程上如何落地SOTA 数字背后付出了什么代价、有哪些说不出口的局限为了不让讨论停留在概念层我会用当前 Codex 的 Skills Catalog 仓库本仓库作为实证样本——OpenSkill 论文里描述的生成-评估-入库-路由链路在这个仓库里恰好每一环都有真实的生产级代码对应。一、问题设定静态技能库为什么不够用先对齐一个基本定义什么是 Skill本仓库的 README.md 给出了一句话定义——Agent Skills are folders of instructions, scripts, and resources that AI agents can discover and use to perform at specific tasks即技能是指令 脚本 资源的文件夹写一次、到处用。这个定义本身没有问题问题是静态技能库的维护方式。一个固定的技能目录无论收录多少条目都面临三重天花板第一覆盖率天花板。任务空间是开放的技能库是封闭的。Agent 遇到库里没有覆盖的长尾任务时只能退回通用推理能力立刻退化到无技能状态。社区里对 Claude Skills 的评测文章反复提到渐进式披露progressive disclosure本质上是在有限技能集合内做上下文管理而不是扩大技能集合本身。第二上下文成本。技能不是免费的。本仓库 skills/.system/skill-creator/SKILL.md 里有一句非常直白的话The context window is a public good. Skills share the context window with everything else Codex needs——上下文窗口是公共资源技能元数据与系统提示词、对话历史、用户请求抢占同一块空间。技能库越大路由和筛选的压力越大把技能全量塞进上下文只会让 Agent 变得更笨。第三维护成本。静态技能库依赖人类专家手工编写、手工评审、手工更新。技能与任务之间的错位只能靠人肉发现。这正是 OpenSkill 要打掉的靶子技能的生成与维护为什么不能由 Agent 自己完成OpenSkill 的出发点很简单——把技能从预置资产变成运行时产物Agent 在执行任务的过程中把成功经验沉淀为技能新任务到来时从技能库中检索路由最合适的技能。技能库因此从静态目录变成活的系统。有意思的是本仓库已经站在了这条演进线的工程端。它虽然是一个标准的静态技能目录41 个 curated 技能 5 个 system 技能但其中预装了skill-creator与skill-installer两个元技能——Codex 可以自己写技能、自己装技能。静态目录与自进化系统之间只差一个自动评估入库的闭环。二、自进化链路闭环生成、评估、入库、路由OpenSkill 论文的贡献本质是把自进化拆成一个可操作的闭环。逐段看每一环在本仓库都能找到对应的真实实现。2.1 技能生成从任务复盘到模板化产出OpenSkill 中Agent 在任务结束后复盘经验并提炼成新技能。这一步的关键不是会写 Markdown而是把经验结构化成一个可复用、可触发的技能包。本仓库的skill-creator技能定义了完整的生成流程见 skills/.system/skill-creator/SKILL.md理解任务的具体示例 → 规划可复用资源scripts / references / assets→ 初始化技能 → 编写 SKILL.md → 校验 → 基于真实使用迭代。而真正的生成动作由脚本完成核心是 init_skill.pyscripts/init_skill.py my-skill --path skills/public --resources scripts,references,assets这个脚本做四件事规范化技能名normalize_skill_name强制转成小写连字符式如 Plan Mode →plan-mode、生成带 YAML frontmatter 的 SKILL.md 模板、自动产出agents/openai.yaml界面元数据、按--resources创建资源目录。也就是说生成一个符合规范的新技能无需人类手写任何样板代码——这正是Agent 自主生成技能在生产代码里的落点。注意一个细节技能目录的解剖结构在 skill-creator/SKILL.md 中被严格定义skill-name/ ├── SKILL.md (required) # frontmatter Markdown 指令 ├── agents/ # openai.yaml UI 元数据 └── Bundled Resources ├── scripts/ # 可执行代码 ├── references/ # 按需加载的文档 └── assets/ # 输出用资源scripts 承担确定性执行references 承担按需加载的知识assets 承担产物模板——三种资源对应三种不同的加载语义这不是排版洁癖而是技能自进化的结构性前提只有资源分层清晰技能才能被批量生成、批量校验、按需消费。2.2 技能评估结构校验是入库的第一道闸门OpenSkill 论文强调生成只是第一步必须评估技能是否有效才能决定是否入库。评估维度通常包括结构合法性、行为正确性、泛化能力三层。逐层对照本仓库最底层的是结构校验实现于 quick_validate.py。这个不到百行的校验器把什么是合法技能固化成可执行的规则SKILL.md必须存在且必须以---YAML frontmatter 开头frontmatter 只允许name、description、license、allowed-tools、metadata五个字段多一个键直接判非法name必须匹配^[a-z0-9-]$不能以连字符开头/结尾不能超过 64 字符description不能包含尖括号不能超过 1024 字符。这套规则的价值在于确定性任何 Agent 生成的技能跑一遍scripts/quick_validate.py path/to/skill-folder就能得到 pass/fail零人工介入。这对应着 OpenSkill 自进化闭环中评估器的第一形态——它不评判技能好不好用只评判技能够不够格进入体系。语义层面的行为评估技能是否真的提升了任务成功率仍然依赖真实使用反馈这在本仓库的 skill-creator/SKILL.md 里体现为最后一步Iterate based on real usage——用真实任务结果反哺技能迭代这正是 OpenSkill 论文里评估-迭代循环的工程雏形。2.3 技能入库分级目录与安全安装通过评估的技能进入仓库。OpenSkill 论文中的技能库在工程上需要一个可管理、可分级的存储结构。本仓库给出了一个生产级的答案README.md 中明确划分了三层.system/随 Codex 最新版自动安装的系统技能如 imagegen、skill-creator、skill-installer.curated/经过精选、可按名安装的技能41 个覆盖 Figma、Notion、Playwright、部署、安全等领域.experimental/实验性技能需显式指定目录安装。入库的动作由skill-installer技能执行其核心逻辑在 install-skill-from-github.py 中值得注意的有三点工程细节其一多路径回退。默认走 codeload zip 直接下载_download_repo_zip遇到 401/403/404 等认证与权限错误时自动回退到 git sparse checkout_git_sparse_checkout再不行换 SSH——保证技能在私有仓库、受限网络下也能安装。其二安全校验。下载的 zip 解压前会做路径穿越检查_safe_extract_zip技能相对路径必须落在仓库内_validate_relative_path目标目录已存在则直接中止_copy_skill中Destination already exists。自进化系统里Agent 自主拉取技能意味着供应链风险这套校验是入库环节不可或缺的安全闸。其三安装位置的语义。默认安装到$CODEX_HOME/skills即~/.codex/skills与系统预装技能隔离——用户级技能和系统级技能的分界保证了自进化新增的技能不会污染受控基线。2.4 技能路由描述即触发闭环的最后一环是路由任务到来时如何从技能库中选出正确的技能OpenSkill 论文的做法是让 Agent 根据任务描述在技能库中检索匹配的技能并调用。本仓库把路由机制压缩进了一个极简设计——YAML frontmatter 的 name description 是路由的唯一依据。skill-creator/SKILL.md 中写得非常明确These are the only fields that Codex reads to determine when the skill gets used, thus it is very important to be clear and comprehensive in describing what the skill is, and when it should be used.也就是说技能的可被发现性完全取决于 description 的质量。本仓库对 description 的撰写有硬性要求必须同时写明技能做什么和何时该用它what it doeswhen to use it。以 skills/.system/imagegen/SKILL.md 为例它的 description 是一段近两百词的条件句哪些任务Use when、哪些任务Do not use如 SVG/矢量编辑、HTML/CSS 原生构建把触发边界写得清清楚楚。路由之后是上下文管控即渐进式披露三级加载frontmatter 元数据约百词常驻上下文SKILL.md 正文仅在技能被触发后加载限制在 5k 词以内scripts/references/assets 按需取用。这套设计直接回应了第一节的上下文成本问题——技能库再大每个时刻只有被路由命中的那一份技能消耗上下文预算。至此OpenSkill 论文的闭环四环节在本仓库全部有代码级对应闭环环节论文中的设定本仓库的真实实现技能生成Agent 从任务经验中提炼技能skill-creator init_skill.py技能评估评估器判定技能是否有效quick_validate.py 结构校验 真实使用迭代技能入库有效技能写入技能库.system/.curated/.experimental分级 install-skill-from-github.py技能路由按任务检索并调用技能frontmatter description 触发 渐进式披露三级加载三、SOTA 数字背后的代价、局限与可复现性讨论情报显示OpenSkill 在多项基准上刷出了新的 SOTA36Kr 将其定性为Agent 自进化新范式同期谷歌 SkillOS 亦宣称不靠堆参数让智能体真正学会自我进化。方向上的热度毋庸置疑但作为技术观察者应该冷静拆解这些数字背后的代价与边界。代价一上下文预算的再分配。技能自进化的每一步都在消耗推理资源生成技能要跑任务复盘评估技能要跑验证入库后每次路由还要在更大的技能库里做选择。本仓库 skill-creator/SKILL.md 反复强调每段信息都要论证其 token 成本正是对这一代价的清醒认识。SOTA 数字不能只看任务成功率还要看达成该成功率所消耗的总推理预算——自进化系统把一部分预算从推理转移到了元能力写技能、评技能上这笔账在论文的算分表里往往被模糊处理。代价二评估器的评估器问题。OpenSkill 的评估环节依赖评估器判断技能是否有效而评估器本身的准确率、召回率、偏差会直接传导到技能库的质量。本仓库对此提供了一个诚实的注脚quick_validate.py只校验结构合法性不校验行为正确性。一个 frontmatter 完全合规、命名完全规范、但指令内容一塌糊涂的技能也能通过校验。结构校验可以自动化语义评估目前仍然依赖真实任务反馈——这意味着自进化闭环的质量上限仍然卡在谁来判断技能真的有用这个开放问题上。代价三路由的脆弱性。自进化生成的技能再多如果 description 写得含糊技能就永远不会被触发——等于没入库。skill-creator/SKILL.md 为此设置了显式约束description 必须覆盖触发场景且只能在 1024 字符内完成。这暴露了一个深层矛盾技能的表达能力与可路由性互相拉扯描述写得太细则触发面窄写得太泛则路由噪音大。OpenSkill 论文中的技能检索同样要面对这个 trade-off。可复现性技能自进化最大的隐性红利。但也要看到相比堆参数式的模型进化技能自进化有一个结构性优势技能是文件夹纯文本加脚本天然可版本化、可审计、可回滚。本仓库本身就是证据——41 个 curated 技能全部以目录形式沉淀在 git 仓库中每一次技能变更都是一次显式 diffREADME.md 明确说明每个技能的许可证存放在其目录内的LICENSE.txt技能的归属、来源、演化历史全程可追溯。模型权重更新是黑盒技能库更新是白盒——这正是不靠堆参数叙事背后的实质能力增长的载体从不可解释的参数空间迁移到了可解释、可复现的文本与代码空间。回到标题的问题OpenSkill 的原理玄吗不玄。拆到底它就是把技能从静态资产变成运行时产物让 Agent 具备四种元能力——生成技能、评估技能、管理技能、路由技能。论文贡献的是把这四条链路组织成闭环的理论框架而工程侧Codex 的技能仓库已经在用最朴素的方式验证着每一条链路init_skill.py生成、quick_validate.py把关、.system/.curated分级入库、frontmatter description 路由触发。SOTA 数字值得关注但更值得关注的是这条链路本身——它让 Agent 的能力增长第一次拥有了可读、可审查、可继承的载体。技术叙事常常玄在话术上而工程真相永远藏在最朴素的代码里。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考