如果你平时拿大模型去处理文献、写实验方案、整理数据，很快就会有一个感受：它能聊，但在真实的科研问题上经常"假装工作"。让它设计一个对照实验，它交出一份看起来完整、但连样本量和重复次数都没交代的方案；让它做统计分析，它把p值挂在嘴边，却不告诉你用的是什么检验、数据满不满足检验前提。这种差距的本质，是模型有大把的陈述性知识，却缺少可验证的程序性技能。
最近我在调研 AI Agent 做科研的落地路线时，看到一个很有意思的评测体系：K-Dense · Scientific Agent Skills。它的做法很直接——把科研活动拆成 163 个可执行、可打分、可以反哺进 Agent 工作流的技能单元，相当于给 AI 发一张"科研上岗证"。这套体系背后的 SSP 评测思路，对一个正在做 AI 辅助科研、AI4Science 或者 AI 编程助手的人来说，都值得花时间看一看。这篇文章我会从"为什么需要技能化评测"讲起，再把 163 个技能的拆解逻辑、评测实现方式、还有我自己跑这类评测时踩过的坑一次说完。
1. 先说清楚：为什么科研能力不能靠"聊天评测"
1.1 大模型聊天很强，但科研链路是另一回事
聊天评测和科研能力评测，看起来都在考"模型会不会回答问题"，实际考的根本不是一件事。一个科研任务往往不是一句话能描述完的，它是文献阅读、假设提出、实验设计、数据采集、结果解读、论文写作、审稿反馈的链条。在这个链条里，模型不只是给出最终答案，还要在中间环节调用工具、读取数据、验证假设、承认不确定性。
我举一个最典型的例子。你让模型"帮我分析这批细胞活力数据"，聊天模型通常能流畅地给出"用t检验，p<0.05 认为显著"。可真实科研场景不是这样的，你首先要判断这批数据符不符合正态分布，方差不方差齐，要不要考虑多重比较，还要看样本是不是独立。一个技能型 Agent 应该把这个流程拆成几个动作：先做分布检验，再决定检验方法，最后输出带可视化图表的报告。如果你只是拿一个聊天分数去衡量它，它永远不需要做这些动作，也就永远不会暴露出它在"中间步骤"里的缺陷。
这就解释了为什么业界开始转向技能化、任务化、Agent化的评测。K-Dense 这套体系把科研技能锁得非常细，看的不是"模型能不能答对"，而是**"模型能不能完成一个完整、严谨、可复现的科研子任务"**。你可以把它理解成驾考里的科目二：不是考你知不知道交通规则，而是考你能不能完成倒车入库、侧方停车这些单项操作。只有单项操作都合格，才谈得上下一个环节。
1.2 这张"科研上岗证"本质是能力边界图
"上岗证"这个说法很容易被理解成发证书、搞排名，我更愿意把它理解为一张能力边界地图。163 个技能不是用来给模型贴一个"科学家"的标签，而是用来告诉你：这个模型在文献总结上很强，但在实验设计上很弱；它很懂数据分析，但在"质疑自己的方法"上几乎为零。
我自己的经验是，做 Agent 项目最怕的就是能力边界不明。你以为模型能处理终端输出，结果它连退出码都没看就告诉你"运行成功"；你以为它能写论文，结果它自己编了一个不存在的引用。如果有一张技能清单，把每个可验证的动作都列出来，你就可以在集成 Agent 之前先做一次摸底，而不是等到它跑完一整条科研流程才在最后一步崩掉。
这也正是 K-Dense 这类体系真正的价值：它不是把"AI 科学家"当营销词，而是把"科学家需要什么技能"当成一个工程问题，拆成可以单测、集成测试、回归测试的模块。这个思路对做 AI 应用开发的人其实非常熟悉，它就是把传统软件工程里的测试文化搬到科研 Agent 里来。
2. 核心机制拆解：K-Dense、SSP 与 163 个技能到底是怎么设计的
2.1 K-Dense 这个名字透露了什么信息
先说 K-Dense。从公开发布材料里的描述来理解，它强调的是知识密集型评测，不是泛泛的闲聊，也不是教科书级别的知识点问答。科研场景有一个特点：知识密度高、专业符号多、推理链长。一个任务文档里往往包含大量专业术语、实验条件、数值约束，普通的问答评测根本“喂不饱”模型，也“考不深”模型。
K-Dense 给我的感觉更像是一种评测数据设计取向：每个任务单元都尽量用最短的文本承载最密集的专业信息，迫使模型必须调动多步推理、约束满足、以及一定的领域常识，而不是靠记忆检索。这就像同样是考英语，一个是考"这段对话表达了什么"，一个是考"这句话里的专业术语在特定临床情境下如何理解"，后者的信息密度和推理深度完全不同。
2.2 SSP 是一种"代理指标"，不是一套具体的软件
标题里出现了 SSP 三个字母。我查到的公开资料里，它多被描述为这套评测体系的代号，强调的是用一组可执行的技能代理（Surrogate / Skill Proxy）来评估科学推理能力。为什么要用"代理"这个词？因为在真实科研中，我们很难直接评判一个模型的长期研究能力——让模型去跑半年湿实验不现实，让模型真的去领导一个课题更不可能。于是人们设计一些短期、可验证、有标准答案的任务来代理评估长期能力的表现，这就是"S Proxy"的意义。
这种思路和软件测试里的覆盖率很像，你不可能测试所有代码路径，所以用行覆盖率、分支覆盖率这些代理指标来衡量测试充分性。SSP 的取舍就是默认：如果模型能在 163 个高密度的科研技能任务里稳定通过，那么它在真实科研流程里的可靠性大概率会高于一个只靠聊天评测拿高分的模型。它不等于真实科研能力，但比凭空聊能力要可操作得多。
2.3 163 个技能按什么逻辑分类
从公开材料透露出来的分类框架看，163 个技能不只是随手列的任务清单，它们在逻辑上覆盖了一条完整的科研流水线。按我看到的材料，大致可以分为几个方向：
- 文献处理类：从 заданий 里检索关键信息、总结方法、对比不同论文的结论、识别引用的合理性。
- 假设与实验设计类：将模糊的科学问题转化为可检验的假设；设计对照组；估算样本量；识别混淆变量。
- 数据处理与统计分析类：数据清洗；选择统计模型；验证模型前提条件；对异常值做处理。
- 结果解释与科学推理类：区分相关与因果；评估效应量；处理不确定性和负面结果。
- 科学写作与沟通类：按期刊结构写作；回复审稿人意见；把复杂结果翻译给非专业读者。
- 工具调用与代码类：编写脚本处理表格数据；调用数据分析库；检查运行结果；修复报错。
这里我特别注意的是，它不是把"论文里的一段结论"直接拿出来做问答题，而是把任务包装成一个需要动脑加动手的流程。比如文献处理，不是问你"这篇文章的结论是什么"，而是给你三篇相关论文，让你判断其中哪一篇的统计方法更适合用来支撑一个新的假设。这样任务才有密度，才能测出模型真正的科研判断力。
2.4 一套技能体系最怕"会背答案"
163 个技能听起来很多，但一套技能体系真正要面对的挑战不是数量，而是泛化性。如果评测任务都是固定的模板，模型训练一段时间后很容易记住套路。好比学生刷题，如果题库几年不换，你会发现学生成绩涨得很快，但一到新题就不会了。
K-Dense 这种设计在一定程度上缓解了这个问题。它不依赖单一的问答对，而是用结构化的技能描述配合动态生成的具体任务场景。也就是说，技能是固定的，但每个技能的考核实例可以持续扩充。这有点像编程里的单元测试框架——用例可以不断添加，但被测能力是明确的。评测系统真正测的，是模型在变化的数据下能不能稳定复现同一套科研行为，而不是死记硬背某个具体题目。
我挺认同这个方向。任何想要长期复用的 Agent 能力评测，都应该把"技能定义"和"测试实例"剥离开。技能定义描述行为规范，测试实例负责注入真实场景。这样技能清单才能持续演进，不至于做成一锤子买卖。
3. 上手实操：把 163 个技能真正跑起来
3.1 说在前面：多数人不需要复现全套
在第 2 部分我聊了不少机制，但说实话，你如果真要去复现整整 163 个技能的全套评测，工作量并不小，而且对很多团队来说没必要。我更建议你用"技能化评测"的思路，先拿一个子集跑通闭环，再按需扩展。
在我自己的实际项目里，我通常会做下面几个事情：
- 选定一个科研场景，比如"单细胞转录组数据分析中的质控环节"。
- 从技能清单里找 10~20 个与此场景相关的技能。
- 为每个技能写一个自动打分脚本或规则。
- 让 Agent 在沙箱环境里真正执行代码并返回结构化结果。
- 把评测结果记录到一张表里，形成回归基线。
这套方法并不依赖官方发布的完整数据集，你可以基于自己领域的真实任务去构建。关键是行为和结果都可验证，不要让模型"空口回答"。
3.2 用一份技能描述文件约束 Agent 行为
我在跑 Agent 时发现，一个很大的问题不是模型能力不够，而是 Agent 的提示词里从来没有告诉过它"你有哪几项技能"。我们给 Agent 的一般命令是"做数据分析""写报告"，这太抽象了。技能化思维要求你把任务描述改写成具体的技能调用接口。
下面是一个我在实际项目中用过的技能描述示例，你可以参考这种写法：
skill: id: stats_check_normality name: 正态性检验与分布判断 description: > 在决定使用参数检验之前，必须对连续型数据做正态性判断。 如果样本量小于50，默认使用 Shapiro-Wilk 检验； 如果样本量大于等于50，辅助使用 Kolmogorov-Smirnov 检验并结合直方图/Q-Q图。 required_inputs: - data_path - target_column expected_outputs: - normality_conclusion - test_used - p_value validation_rules: - "不能直接跳过分步检验给出t检验结论" - "必须报告具体检验名称和p值"这份描述文件看起来简单，但作用很大。当你把 Agent 的提示词从"帮我做一下统计分析"改成"请先查一下你的技能列表里有哪项技能和数据分析相关，然后严格按技能描述执行"，Agent 的行为会有明显变化。
更关键的是，评测判分不再依赖模糊的整体印象。你只要核对 validation_rules 即可：有没有报告检验名称，有没有报告 p 值，有没有先做分布判断。这些都是硬性规则，可以交给一个很小的打分模型或代码脚本去判断，不需要大模型参与。这就是技能化的好处：把"科研能力"翻译成了"有没有按科研规范执行操作"。
3.3 沙箱环境的搭建思路
科学 Agent 评测里，代码执行是绕不开的一环。你不能只在文本层面评估，因为很多科研技能涉及真实的数据处理。这里我建议你搭一个轻量级的代码执行沙箱。
我自己的做法是用 Docker 起一个带 Python 环境的容器，装好 pandas、numpy、scipy、scikit-learn、matplotlib 这些主流库，然后通过接口把 Agent 生成的代码传入容器执行。容器要限制网络访问和磁盘容量，防止模型生成的代码做超出预期的事情。
docker run -d --name science-sandbox \ --network none \ --memory 4g \ --cpus 2 \ -v /tmp/agent_data:/data \ python:3.11-slim \ sleep infinity上面的参数要注意几点。--network none是把网络掐掉，避免 Agent 在评测过程中偷偷访问外部资源；--memory和--cpus限制资源消耗；-v是挂载一个数据目录，让 Agent 能读取测试数据。这样执行环境是干净、可控、可回滚的。评测完直接把容器删掉重建，就能保证每一次测试环境一致。
4. 我在跑科研技能评测时踩过的坑
4.1 过拟合评测集：分数涨了，能力没涨
这是所有评测体系都会遇到的问题，K-Dense 也不能免疫。我在自己的子集测试里发现，同一个技能描述配合同一批测试数据跑三次，到第三次模型已经“记住”了正确输出，哪怕我们换了数据源，只要问题模板一样，模型的回答质量也会显著提升。乍看是好事，但要警惕：模型可能是在过拟合问题模板，而不是真正理解了科学推理。
解决这个问题，我的经验有两条。第一，每次评测都要尽量在技能描述基础上做数据扰动：换变量名、换样本量、换小组数量，让模型没办法靠模板匹配来混分。第二，定期人工抽检。自动打分只能覆盖 validation_rules 里的显式规则，但科研能力里还有很多隐性的东西，比如"它是不是在结果不确定时伪装确定性"，这类需要人工看输出才能判断。
4.2 上下文长度和技能切换的冲突
科学任务特别吃上下文。一篇论文的附件可能几十页，一份单细胞数据集的 metadata 里几千行；而 Agent 在执行时还可能需要同时记住"任务目标、技能描述、当前中间结果"三份信息。如果上下文窗口不够，Agent 就会在技能切换时丢三落四——做完数据清洗忘了为什么要做；开始画图时忘了实验分组是什么。
我在压测时发现，上下文一长，模型就特别容易把前面的指令忘得一干二净，尤其在执行"数据预处理 -> 统计分析 -> 可视化 -> 结论"这种多步骤任务时。我的建议是把大任务拆开，每个子任务重新注入相关信息。不要指望 Agent 在长上下文里保持完美的注意力。你可以设计一个 MEMO 机制，让 Agent 在每完成一个子任务后，把关键结论写成一个短 memo，下一步再把这个 memo 读进去。这样既降低上下文压力，又提升了整体推理的稳定度。
4.3 模型总是"假装严谨"，但其实就是个空壳
我在评测结果里发现一个很讽刺的现象：有些模型虽然能输出完整的分析流程，却在非常基础的地方翻车。比如它会说"使用 Shapiro-Wilk 检验进行正态性判断"，但根本没有检查数据里有没有缺失值；它会在 p 值大于 0.05 的时候写出"差异不显著"，却不考虑样本量是不是小到根本检验不出效应。
这种"流程正确但实质空洞"的输出最危险，因为它看起来太专业了，不仔细看根本发现不了内在的不严谨。我的应对办法是在 auto-grader 里加入强制性中间检查点。比如，凡是设计到统计检验的任务，就要求 Agent 必须输出一条JSON记录，明确写清楚样本量、缺失值数量、分布检验结论、检验方法、p值、效应量。任何一步没有输出，整个任务就算失败。规则化、显式化、JSON化，这三个词可以解决很多科研评测里"文字流畅但缺少严谨性"的问题。
4.4 评测分数不可比：环境差异比模型差异还大
如果你们团队有多个人在并行评测不同模型，我强烈建议你们建立一个标准的运行清单，把 Python 版本、库的版本、随机数种子、模型 temperature、top_p 全部固定下来。我吃过一次亏：两个不同模型分别用不同库版本评测，pandas 的某个排序函数行为在不同版本里不一样，导致一个模型的数据结果跟另一个不一致，最后对比时花了一整天排查，根因居然只是版本差异。
所以说，评测环境就是评测的一部分。真正可复现的科研 Agent 评测，最少要包含一份 requirements.txt、一个固定的随机种子、一个固定的评测脚本版本号。没有这些，你得到的分数只是一堆不可复现的数字。
5. 把 163 个技能用到自己的 Agent 项目里
5.1 从"全量照搬"到"挑子集"
看到 163 这个数字，很多人的第一反应是"全都要"。但在实践中，我认为直接照着全部技能去搭建 Agent 是个陷阱。原因很简单：你给 Agent 装太多技能，它反而不知道当前任务该调用哪个，在技能选择上频繁出错。好比给一个刚入行的研究助理发了本实验室 SOP 大全，他翻手册的时间比干活时间还长。
我建议的做法是每次只选一个任务域的 10 到 20 个核心技能，让 Agent 深度掌握，再通过任务规划器决定手动扩展。比如你是做化学合成方向的，那你的 Agent 先掌握"反应路线检索""条件筛选""产率计算"这 20 个技能就够了，等它稳定落地，再往里加安全审核、专利分析、文献自动综述等技能。技能不是越多越好，是覆盖当前主链路、又能验证即可。
5.2 把评测技能变成 Agent 的"岗前训练"
最后说一个我很喜欢的用法：把 163 个技能里的评测实例直接当训练集，用来微调或做 few-shot 示例。
传统做法是研究团队辛辛苦苦总结 prompt，告诉 Agent"你要先做正态性检验，你不能乱编引用"。但这类自然语言劝诫的效果，远不如给模型看几个具体的技能评测问答对。比如你发现模型老是跳过效应量报告，那就挑几个效应量相关的技能示例，在 prompt 里固定塞进去，让模型照着这个格式输出。几次迭代之后，模型输出的规范性能有明显提升。
我测过一种更狠的做法：先把某个技能定义写清楚，然后把评测判分规则也暴露给 Agent，让它在生成时就自觉匹配判分项。这听起来有点作弊，但实际效果很好——让 Agent 知道"答案将按什么清单被检查"，等于把隐性要求显性化了，模型的输出会自然贴向那些要求的格式。这就和面试前把评分标准给你看一样，你自然会围绕得分点来组织回答。
5.3 后续扩展空间
我在完整跑完一轮技能化评测之后，最大的感受是：这个领域还远没到定型的时候。将来大概率会看到几类延伸——第一，技能库会不会从"科学通用技能"扩展到"学科专用技能"，比如生物信息学、材料计算、临床医学里的细分技能；第二，评测形态会不会从单轮任务演化成多轮长周期课题制，让 Agent 在更真实的项目节奏里被考察；第三，AI Agent 自己会不会反过来参与技能库的建设，通过反思自己实测中的不足来生成新的技能描述。如果你想做这块的应用开发，这几条路都是可以提前布局的方向。
我自己在跑完这套评测思路后，最大的体会不是"AI终于能当科学家了"，而是**"科学家的工作被拆到这么细之后，反而让我们更清楚AI离真正的科学家还有多远"。** 163 个技能考的是执行力，但真实的科研还要靠品味、判断力和对未知的好奇心，这些暂时还是考不出来的部分。不过没关系，先把能考的都考好，AI 辅助科研的可靠性就足够上一个台阶了。做 Agent 应用的人，如果能把"技能化评测"这套思路用在自己负责的领域里，我相信会比单纯堆 Prompt 或者盲目做大模型微调要扎实得多。
