如果你平时拿大模型去处理文献、写实验方案、整理数据很快就会有一个感受它能聊但在真实的科研问题上经常假装工作。让它设计一个对照实验它交出一份看起来完整、但连样本量和重复次数都没交代的方案让它做统计分析它把p值挂在嘴边却不告诉你用的是什么检验、数据满不满足检验前提。这种差距的本质是模型有大把的陈述性知识却缺少可验证的程序性技能。最近我在调研 AI Agent 做科研的落地路线时看到一个很有意思的评测体系K-Dense · Scientific Agent Skills。它的做法很直接——把科研活动拆成 163 个可执行、可打分、可以反哺进 Agent 工作流的技能单元相当于给 AI 发一张科研上岗证。这套体系背后的 SSP 评测思路对一个正在做 AI 辅助科研、AI4Science 或者 AI 编程助手的人来说都值得花时间看一看。这篇文章我会从为什么需要技能化评测讲起再把 163 个技能的拆解逻辑、评测实现方式、还有我自己跑这类评测时踩过的坑一次说完。1. 先说清楚为什么科研能力不能靠聊天评测1.1 大模型聊天很强但科研链路是另一回事聊天评测和科研能力评测看起来都在考模型会不会回答问题实际考的根本不是一件事。一个科研任务往往不是一句话能描述完的它是文献阅读、假设提出、实验设计、数据采集、结果解读、论文写作、审稿反馈的链条。在这个链条里模型不只是给出最终答案还要在中间环节调用工具、读取数据、验证假设、承认不确定性。我举一个最典型的例子。你让模型帮我分析这批细胞活力数据聊天模型通常能流畅地给出用t检验p0.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 或者盲目做大模型微调要扎实得多。