夜雨聆风我们现在发现AI很火，想给自己做一个科研AI助手。然后呢再给它一份详细的科研工作手册。
开始还不错，但遇到手册没覆盖的新情况就犯错——而且每次犯的都是同一个错。你只能不断手动更新手册。
慢慢地你会觉得很烦躁，在想有没有办法让他学会自己学习呢？
于是你又在每天每夜，呕心沥血地改手册，想不断地给他补充学习Skill。
但是清华团队说，no！这是很低效率的。
他们其实也遇到过这种情况。
而他们竟然都同时给出了相同的答案：
别写手册了，让Agent自己写，自己改，自己进化。
他们都分别写了个skill，让agent自己进化，
最后的结果出人意料——Agent自己写的Skill技能说明书，比人类精心整理的还好13.3个百分点。
他们是怎么做的？
这两个团队都在从不同角度攻克同一个问题：让agent通过skill自进化。
第一个团队的核心思想是，给AI做一个Emboiskill。
EmbodiSkill是什么？
它是聚焦具身智能场景，设计了一套技能感知反思机制。
说白了，它的作用是让Agent学会区分我到底哪里出了问题。
EmbodiSkill 的核心创新是四种技能感知反思类型：
Discovery Reflection：任务成功了，但发现了一个新技能的苗头——记下来
Optimization Reflection：任务成功了，但效率不高——优化已有技能
SkillDefect Reflection：任务失败了，是技能本身有缺陷——改技能
ExecutionLapse Reflection：任务失败了，但技能没问题，是执行环节出了岔子——不改技能，下次执行注意
它个技能最关键的是教会Agent 失败后不是无脑改技能，而是先判断"是手册写错了，还是我没按手册做"。消融实验证明，去掉任何一种反思都会导致性能明显下降。
技能被组织成结构——S_body 是核心操作步骤，S_appendix 是踩坑记录和注意事项。
每次反思后，Agent 更新技能的对应部分，进入下一轮"执行→反思→更新"螺旋。
第二个团队核心思想是，给AI做一个SkillEvoler。
从这个翻译可以看出，这是一个管理其他技能进化的技能。
它有两个核心：分别是策略多样化探索和对比技能更新。
策略多样化探索：每次迭代不只有一个方案，而是生成 K=4 个不同执行策略的并行试验。有的激进，有的保守，有的走不同路径。这样避免 Agent 陷入"每次都用同一个方式失败"的困境。
对比技能更新：把成功轨迹和失败轨迹摆在一起对比，从差异中提炼改进点。然后交给一个独立 Auditor，执行 9 项机械检查，拦截了 17% 的有害更新。
重要的是，SkillEvolver 更新的是技能的文字和代码，不是模型权重。这意味着不需要 GPU 训练，任何 Agent 都能装上用。
https://github.com/THU-AICosmos/skillevolver
我们也是在github上找到了这个技能。大家可以直接将链接复制给agent，让他学会自己进化。
那怎么实操到我们科研当中呢？
这两篇论文应用到科研场景，核心可以拆成四个实操方向。
实验设计的自进化
科研实验的失败率很高，但大部分人对待失败的方式是模糊的——"这次不太行，换个参数再跑一次"。EmbodiSkill 的四类反思提供了一个精确的归因框架。
Discovery Reflection，实验跑出了预期之外的结果。某个消融实验里去掉了一个你以为不重要的模块，结果某个冷门指标暴涨。
这个信号不能看过就算了，要当成一个新技能的苗头记录下来——下次做类似任务时主动测试这个模块。
SkillDefect Reflection，实验失败是因为方案本身有问题。比如你假设加注意力机制能提升性能，但三轮实验下来没有任何提升。这时候不是去调学习率，是回去检查假设本身是否成立。
ExecutionLapse Reflection，实验失败但方向没问题——数据预处理脚本有个 bug，或者 GPU 显存不够导致 batch size 被迫改小影响了收敛。这种情况不改实验设计，修执行环节就行。
大多数实验室里，这三种情况被混在一起处理，反复在错误的方向上浪费时间。EmbodiSkill 的消融实验已经证明了：去掉任何一种反思类型，整体性能都会明显下降。科研同理。
技能的结构化存储
EmbodiSkill 把技能存成格式。S_body 是标准操作步骤，S_appendix 是踩坑记录。这个结构可以平移到一个实验小组的共享知识库里。
比如"训练一个图像分类模型"这条技能，S_body 是标准流程：数据加载、预处理、模型初始化、训练循环、验证评估。
S_appendix 是这个实验室积累的隐性经验：ImageNet 上某些类别的标注错误需要手动修、ResNet 在某个版本的 PyTorch 上 batch norm 行为异常、分布式训练时某个 NCCL 版本会导致偶发性死锁。
这种隐性知识通常靠师兄口口相传，人一走就丢了。结构化存下来之后，每跑一轮实验就往 S_appendix 追加一条，新人接手项目不需要从头踩所有坑。
并行策略搜索
SkillEvolver 的策略多样化探索非常匹配科研里的方案筛选——每次不是只试一个方向，而是同时跑 K=4 个不同策略。
科研里最容易犯的错误就是盯住一个方向猛做，做到第三个月发现走不通，但已经回不了头了。
这个思路的应用方式：拿到一个新问题后，同时设计 3-4 套差异足够大的方案。不是说每个方案都要写到代码级别，但实验路线图要并行画出来。一套激进——直接上最复杂的方法。
一套保守——在最简单 baseline 上做增量修改。一套走不同路线——换个建模视角。然后通过快速实验淘汰明显不行的，把资源集中在有信号的方案上。
自动化审计
SkillEvolver 里独立的 Auditor 角色执行 9 项机械检查，拦截了 17% 的有害更新。这个比例在科研里只会更高。
科研里的"有害更新"是什么？实验结论和实验数据不匹配。论文里声称性能提升了 10%，但看原始日志发现提升来自一个已经被后续实验推翻了的设置。
审稿人捕获这种问题靠经验和时间，但一个机械审计系统可以自动检查：论文里引用的所有数字在实验记录中是否存在、每个 claim 是否有对应的消融实验或统计检验支撑、对比 baseline 的设置是否在附录里有完整文档。
这不是替代审稿人，而是在投稿前先做一轮机械核查，把可以自动发现的错误挡在投稿系统外面。