Valhalla静态工程审阅｜源码尽调｜162 个科学 Agent Skills 值不值得用？从源码静态证据拆解 scientific-agent-skills 的工程结构与风险边界【Agent Sk

TunerT_TQ 2026-08-19 0 阅读22分钟

Valhalla静态工程审阅｜源码尽调｜162 个科学 Agent Skills 值不值得用？从源码静态证据拆解 scientific-agent-skills 的工程结构与风险边界【Agent Skill 特辑 #017】

本文基于 K-Dense-AI/scientific-agent-skills 指定提交的可复现源码快照，进行只读静态工程审阅。

• 仓库：https://github.com/K-Dense-AI/scientific-agent-skills
• 快照提交：4d265d04b3bd86b384d8e8f10920dafa38634ab9
• 分析方式：源码目录、配置文件、测试线索、CI 工作流、抽样 AST 结构和静态风险模式
• 适用读者：科研 AI 平台负责人、算法工程师、Agent 开发者、研究数据治理人员

**重要声明：**本文没有执行安装、脚本、测试、依赖扫描或真实科研任务。所有结论仅描述当前源码快照中可定位的静态证据，不构成安全审计、性能测评、科研结论、合规认证或生产上线建议。

---

一、先说结论：它不是单一 Skill，而是一个“科学工作流能力集合”

如果把普通 Agent Skill 理解为“教模型完成一项任务的说明书”，那么 scientific-agent-skills 更接近一个面向科研场景的技能库。

根据仓库公开定位，该项目希望让通用 AI Agent 获得更多科学研究任务能力。基于指定源码快照，可以确认：

• 仓库包含 682 个受支持源文件；
• 其中 Python 文件有 679 个，Python 是绝对主导语言；
• 可识别到 162 个 SKILL.md / 技能条目；
• 存在 100 项测试文件线索；
• 存在 5 个 CI 工作流线索；
• 存在 pyproject.toml 作为 Python 工程配置入口；
• 存在多个许可证文件；
• 静态规则扫描命中 Shell 调用、路径处理、动态执行和疑似敏感字面量等模式，共 98 条，需要人工复核。

因此，更准确的判断是：

scientific-agent-skills 具备较广的科学任务 Skill 表面、Python 脚本化执行能力、测试与 CI 工程线索，适合进入隔离环境 PoC；但其 Skill 数量多、外部工具和文件处理场景广，不能仅凭“有很多 Skill”就直接投入生产科研数据或高敏感研究环境。

---

二、为什么科学 Agent Skill 不能只看 Prompt？

科研类 Agent 的难点不只是“生成一段解释”。

一个真正进入科研工作流的 Agent，可能涉及：

研究资料检索
→ 数据读取与清洗
→ 统计分析
→ 模型训练
→ 结果可视化
→ 图表、报告或论文生成
→ 实验记录和结果复核
→ 最终研究材料归档

一旦涉及文件、脚本、外部命令、数据格式和科研结论，工程风险会迅速增加。

例如，一个“看似正常”的科学自动化任务，实际可能隐含以下问题：

• Agent 是否读取了工作区外的文件？
• 分析脚本是否执行了未受控命令？
• 研究结论能否回溯到原始数据和计算过程？
• 使用的第三方包、标准和数据库版本是否一致？
• 生成的图表是否误用了输入数据？
• 论文或报告中是否混入模型虚构的引用？
• 涉及病原体、临床、药物或实验室数据时，权限边界是否明确？

所以，审阅这类项目必须同时看四个层面：

1. Skill 覆盖范围：能做什么；
2. 工程实现结构：如何执行；
3. 测试与自动化：是否有可验证入口；
4. 风险边界：文件、路径、命令和动态执行是否可控。

---

三、项目规模：682 个源文件，Python 占比超过 99%

当前快照中的语言分布如下。

语言	文件数量	占比参考
Python	679	约 99.6%
Shell	3	约 0.4%
合计	682	100%

这说明该项目的主体实现是 Python 脚本和 Python 工具链。

对于科学计算、数据分析和研究自动化而言，这种技术结构并不意外。Python 生态通常覆盖：

• 数据分析；
• 统计计算；
• 生物信息学；
• 化学信息学；
• 医学影像；
• 机器学习；
• 科学绘图；
• 文档处理；
• 表格处理；
• PDF、PPT、Word 等科研文档生成；
• 与命令行工具、Jupyter、科研数据库的集成。

但需要注意：

Python 文件数量多，只能说明项目以 Python 实现；不能证明每个 Skill 都能稳定运行，也不能证明科学计算结果正确。

科研场景中的正确性必须通过数据集、计算方法、参考实现、实验设计和人工专家审阅共同验证。

---

四、核心资产：162 个 Skill 条目意味着“广覆盖”，也意味着验证成本高

本次静态评测识别到 162 个 SKILL.md / 技能条目，且主要集中在 skills 目录。

skills/
├── analytical-method-validation/
├── pathogen-variant-surveillance/
├── lab-hardware-cad/
├── iso-standards-readiness/
├── scikit-survival/
├── qiskit/
├── pymc/
├── pkpd-modeling/
├── research-lookup/
├── shap/
├── geopandas/
├── deeptools/
├── pydicom/
├── xlsx/
├── pptx-posters/
└── ...

从部分目录名可以看到，该技能库覆盖的方向可能包括：

科研方向	代表性 Skill 线索
分析方法验证	analytical-method-validation
ç— åŽŸä½“å˜å¼‚ç›‘æµ‹	pathogen-variant-surveillance
实验室硬件与 CAD	lab-hardware-cad
ISO 标准准备度	iso-standards-readiness
生存分析	scikit-survival
量子计算	qiskit
贝叶斯建模	pymc
PK/PD 建模	pkpd-modeling
科研资料检索	research-lookup
可解释机器学ä¹	shap
地理空间分析	geopandas
生物数据处理	deeptools
DICOM 医学影像	pydicom
è¡¨æ ¼å’ŒåŠžå ¬æ–‡æ¡£	xlsx、pptx-posters

这种规模意味着其 Skill 表面可以被评价为“广泛（broad）”。

但广泛并不等于成熟度一致。

一个很关键的工程判断

对于 162 个 Skill 的项目，不能简单问：

“这个仓库好不好用？”

更合理的问题是：

我要使用的具体 Skill 是什么？
它依赖哪些本地工具和 Python 包？
它会读取哪些文件？
它会写入哪些目录？
它是否执行 Shell 或第三方命令？
它能否被测试覆盖？
它的结果是否需要领域专家审核？

也就是说，应该从“仓库级评估”转向“具体 Skill + 具体场景”的分层评估。

---

五、顶层结构：项目表面集中，但能力主体在 skills 目录

当前快照识别到 4 个一级模块根：

scan_pr_skills.py
scan_skills.py
skills
tests

可按以下方式理解：

模块或文件	é™æ€é˜ è¯»æ–¹å‘
skills	各科学领域 Skill 的定义、脚本和任务说明
tests	Skill 行为、脚本执行、目录结构和契约检查
scan_skills.py	Skill æ‰«æã€è§„åˆ™æ£€æŸ¥ã€å† å®¹è¯†åˆ«æˆ–éªŒè¯é€»è¾‘
scan_pr_skills.py	PR 级别的 Skill 变更扫描或阻断逻辑

从架构上看，这不是一个传统的大型 Python 应用，而更像一个“科学 Skill 仓库 + 扫描验证工具 + 测试体系”。

flowchart TB
    A[skills/<领域>/SKILL.md] --> B[领域脚本与工具]
    B --> C[本地文件、数据或科研工具]
    
    D[scan_skills.py] --> A
    E[scan_pr_skills.py] --> A
    
    F[tests] --> B
    F --> D
    F --> E
    
    G[GitHub Actions] --> F

图仅用于理解模块级阅读关系，不代表完整运行时调用图、权限模型或部署架构。

---

六、从代码结构看：复杂度主要来自校验、遍历和规则分派

本次抽样阅读了 12 个非测试源码文件，全部使用 Python AST 解析。

结构统计结果如下：

结构项	观测数量
声明	115
分支	418
循环	254
异常路径	37
异步线索	0

这些数字不能被当作代码质量评分，但可以说明：抽样代码中存在较多的条件判断、循环遍历和异常处理。

这类结构对于科学任务工具并不意外，因为它们往往需要处理：

• 多种输入文件格式；
• 多种参数组合；
• 不同领域的规则；
• 批量数据；
• 目录扫描；
• 校验失败；
• 输出格式差异；
• 工具依赖缺失；
• 不同版本的配置兼容。

更实用的理解方式是：

对该项目进行源码阅读时，应优先关注输入来源、路径边界、规则分支、外部命令调用、异常处理和输出产物，而不是只阅读 Skill 文案。

---

七、重点入口一：scan_skills.py，Skill 质量闸门的重要线索

在 scan_skills.py 中，静态分析识别到以下声明：

• scanner_version
• llm_model_id
• content_hash
• build_scanner
• severity_badge

该文件的抽样结构包括：

指标	数量
分支	55
循环	26
异常路径	13

从这些符号可以推断，该文件可能承担 Skill 扫描、内容识别、风险分级或规则构建等职责。

其中值得继续审阅的线索包括：

1. content_hash

内容哈希通常与文件完整性、内容变更识别或扫描结果关联有关。

对于 Skill 仓库而言，哈希机制可能帮助回答：

• Skill 文档是否被修改；
• 扫描对象是否一致；
• PR 中是否引入了新内容；
• 规则检查是否针对同一版本运行；
• 结果是否能对应到具体文件内容。

不过，需要结合实现确认哈希是用于缓存、校验、审计还是其他目的。

---

2. llm_model_id

该符号提示扫描或评估逻辑可能涉及模型标识。

如果某些 Skill 的验证依赖模型行为，建议重点确认：

• 是否固定了模型版本；
• 是否允许模型漂移；
• 是否记录模型配置；
• 是否将模型输出误当作确定性规则结果；
• 是否存在同一 Skill 在不同模型下结果不一致的问题。

对于 Agent Skill 来说，Prompt 一致并不意味着输出一致。模型版本、系统提示词、上下文窗口和工具权限都可能改变最终行为。

---

3. severity_badge

风险严重级别的展示逻辑通常意味着项目有一定的质量或风险标识机制。

但在实际使用时，仍应确认：

• 严重级别如何计算；
• 是否存在人工审核；
• 是否会误把提示性问题标记为高风险；
• 是否会漏掉真实的执行风险；
• 是否覆盖 Skill 的外部依赖和文件权限。

---

八、重点入口二：scan_pr_skills.py，面向变更的质量控制线索

scan_pr_skills.py 中识别到的声明包括：

• _sev_str
• scan_skill_dirs
• _loc
• format_comment
• _should_block

其结构统计为：

指标	数量
分支	30
循环	12
异常路径	5

从命名看，该文件可能用于对 Pull Request 中变更的 Skill 内容进行扫描，并生成评论或阻断判断。

其中 _should_block 是值得重点关注的入口。

如果项目确实将某些扫描结果作为合并门禁，那么应进一步验证：

• 哪些规则会阻断 PR；
• 是否允许人工豁免；
• 是否区分文档问题与真实执行风险；
• 是否存在误报导致开发效率下降；
• 是否存在漏报导致高风险 Skill 被合并；
• 是否记录扫描版本和扫描结果；
• 是否对新增依赖、Shell 命令、文件权限做专项检查。

对于拥有大量 Skill 的仓库，PR 级自动扫描是必要能力之一，但它不能完全替代领域专家审阅。

---

九、重点案例：分析方法验证 Skill 的代码结构值得优先复核

抽样中，skills/analytical-method-validation/ 目录下的文件出现较多控制流和计算逻辑。

1. _common.py

识别到的声明包括：

• _betacf
• betainc
• gammainc_lower
• _bisect_ppf
• t_cdf

该文件抽样结构为：

指标	数量
分支	119
循环	80
异常路径	11

从函数名可以看出，这里可能包含与概率分布、累计分布函数、数值逼近和统计计算相关的实现。

这类代码的工程风险并不主要是“会不会报错”，而是：

• 数学实现是否正确；
• 边界值是否稳定；
• 浮点数误差是否可接受；
• 极端样本量下是否收敛；
• 是否与权威统计库结果一致；
• 是否覆盖异常输入；
• 是否经过独立验证。

对于分析方法验证、药物分析、化学分析或质量控制相关场景，任何统计计算逻辑都不应只因“代码可运行”就直接用于正式结论。

建议使用以下方式验证：

内部实现结果
vs.
SciPy / R / SAS / 参考标准实现
vs.
已知标准测试数据集
vs.
人工计算样例

---

2. check_accuracy_precision.py

该文件中识别到：

• main
• precision_block
• as_rsd

结构统计包括：

指标	数量
分支	31
循环	26
异常路径	2

从命名看，该 Skill 可能涉及准确度、精密度和相对标准偏差等分析方法验证指标。

这类能力适合用于辅助检查、材料准备或结果复核，但需要特别避免以下误用：

• 将 Agent 输出直接作为实验放行结论；
• 将脚本计算结果直接当作法规或注册申报结论；
• 未核对原始实验数据、仪器记录和方法学要求；
• 未确认适用标准版本；
• 忽略不同实验室、不同仪器、不同批次间的条件差异。

---

3. check_bioanalytical_run.py

该文件中识别到：

• calibrator_tolerance
• check_run
• check_isr
• check_total_error
• main

结构统计包括：

指标	数量
分支	28
循环	16
异常路径	0

从名称看，它与生物分析运行检查、校准品容忍度、ISR 和总误差检查有关。

这类功能具有较强的专业领域属性。即使脚本逻辑正确，实际使用时仍需由具备相应资质的研究人员或质量人员确认：

• 适用方法学；
• 数据来源；
• 阈值依据；
• 法规或行业规范版本；
• 例外情形；
• 审批与留痕机制。

---

十、测试证据：100 项测试线索是积极信号，但不能直接推导覆盖率

当前快照中可定位到 100 项测试文件线索。

代表性文件包括：

tests/conftest.py
tests/run_all.py
tests/pathogen-variant-surveillance/test_scripts.py
tests/lab-hardware-cad/test_scripts.py
tests/iso-standards-readiness/test_scripts.py
tests/scikit-survival/test_scripts.py
tests/qiskit/test_scripts.py
tests/scientific-brainstorming/test_scripts.py
tests/pymc/test_scripts.py
tests/pkpd-modeling/test_scripts.py
tests/research-lookup/test_research_lookup.py
tests/shap/test_scripts.py

从路径命名看，测试覆盖方向比较广：

测试方向	对应线索
ç— åŽŸä½“ç›‘æµ‹	pathogen-variant-surveillance
实验室 CAD	lab-hardware-cad
ISO 标准准备度	iso-standards-readiness
生存分析	scikit-survival
量子计算	qiskit
科学头脑风暴	scientific-brainstorming
贝叶斯分析	pymc
PK/PD 建模	pkpd-modeling
科研资料查询	research-lookup
模型解释	shap

这说明项目至少具备“按 Skill 或领域组织测试”的工程意图。

但不能因此得出：

• 所有测试均通过；
• 所有 Skill 均有同等深度测试；
• 所有依赖工具已安装；
• 所有外部接口可用；
• 所有测试覆盖真实科研数据；
• 所有领域结论均经过专家验证。

推荐的正确验证方法

对计划使用的具体 Skill，应至少执行：

1. 官方最小测试；
2. 对应 Skill 的专项测试；
3. 真实但脱敏的数据样例测试；
4. 错误输入与边界输入测试；
5. 输出结果与权威工具或人工结果比对；
6. 版本和依赖环境记录。

---

十一、CI 与交付证据：存在五类工作流入口

当前快照可定位到以下 GitHub Actions 工作流：

.github/workflows/release.yml
.github/workflows/skill-spec-validation.yml
.github/workflows/pr-skill-scan.yml
.github/workflows/security-scan.yml
.github/workflows/skill-tests.yml

从名称可推断其关注点包括：

工作流	å¯èƒ½å ³æ³¨æ–¹å‘
release.yml	版本发布与交付
skill-spec-validation.yml	Skill 规范检查
pr-skill-scan.yml	Pull Request 中的 Skill 扫描
security-scan.yml	å®‰å ¨ç›¸å ³æ£€æŸ¥
skill-tests.yml	Skill 测试执行

这类工作流对于 Skill 仓库很有价值，因为 Skill 的变化不仅是文案变化，还可能影响：

• 命令执行；
• 文件读写；
• 外部依赖；
• 权限声明；
• 工具调用；
• 科研计算逻辑；
• 输出文件格式。

不过仍要明确：

CI 工作流文件存在，只能证明自动化入口可定位；不能证明当前工作流是绿色的，也不能证明发布产物已经过完整验证。

---

十二、静态风险命中 98 条，应该如何正确理解？

静态规则扫描共命中 98 条风险模式：

风险标签	数量	静态含义
RISK-SHELL-INVOCATION	62	存在 Shell æˆ–å‘½ä»¤è°ƒç”¨ç›¸å ³æ¨¡å¼
RISK-PATH-TRAVERSAL	16	存在路径处理、文件定位或目录访问模式
RISK-SECRET-LITERAL	16	存在疑似密钥、Token 或敏感字面量模式
RISK-DYNAMIC-EXECUTION	4	å­˜åœ¨åŠ¨æ€æ‰§è¡Œæˆ–åŠ¨æ€åŠ è½½ç›¸å ³æ¨¡å¼

最重要的是：

静态命中不等于确认漏洞，也不等于该项目“不安全”。

原因是很多命中发生在测试文件、契约测试或工具验证代码中。例如：

• 测试 Shell 调用，本身可能是为了验证 CLI；
• 路径处理逻辑可能是防御目录穿越；
• 敏感字面量可能只是占位符或测试 Token；
• 动态执行可能用于特定格式检查或受控加载。

正确做法是从“规则命中”继续走向“调用链和输入可达性审阅”。

---

十三、风险复核应该优先看什么？

1. Shell 调用：优先检查 Agent 输出是否进入命令行

典型命中路径包括：

tests/run_all.py
tests/lab-hardware-cad/test_scripts.py
tests/pkpd-modeling/test_scripts.py
tests/shap/test_scripts.py
tests/scientific-schematics/test_scripts.py
tests/geopandas/test_scripts.py
tests/pydicom/test_scripts.py

应重点核查：

• 是否使用 subprocess.run()、os.system()、shell=True 等方式；
• 命令字符串是否由外部输入、模型输出或文档内容拼接；
• 是否采用参数数组而不是字符串拼接；
• 是否限制可执行命令集合；
• 是否控制工作目录；
• 是否设置超时；
• 是否保留退出码和标准错误；
• 是否禁止调用危险系统命令。

对于科学 Agent 而言，模型输出不应被直接信任为可执行命令。

一个较安全的模式是：

subprocess.run(
    ["python", "analysis.py", "--input", safe_path],
    check=True,
    timeout=60,
    cwd=workspace_dir,
)

而不是：

subprocess.run(f"python analysis.py --input {user_input}", shell=True)

后者如果输入缺乏验证，就可能引入命令注入风险。

---

2. 路径遍历：科研文件和本地环境必须隔离

涉及路径处理的代表性测试线索包括：

tests/iso-standards-readiness/test_scripts.py
tests/get-available-resources/test_scripts.py
tests/exploratory-data-analysis/test_scripts.py
tests/deeptools/test_scripts.py
tests/fluidsim/test_scripts.py
tests/pytdc/test_scripts.py
tests/_contract/office.py

应重点确认：

• 是否限制文件读取范围；
• 是否限制输出目录；
• 是否拒绝 ../ 目录穿越；
• 是否解析真实路径；
• 是否防御软链接绕过；
• 是否禁止访问用户主目录、SSH 配置、云凭证目录；
• 是否会覆盖已有论文、实验记录或原始数据文件。

建议为 Agent 分配明确工作区，例如：

workspace/
├── inputs/
├── outputs/
├── temp/
└── logs/

并确保所有文件操作都被限制在该工作区下。

---

3. 动态执行：确认代码、表达式或插件是否可被外部控制

静态分析中，动态执行相关命中例如：

tests/imaging-data-commons/test_check_version.py

需要人工确认是否涉及：

• eval()；
• exec()；
• 动态导入；
• 根据文件内容加载 Python 模块；
• 根据用户参数选择执行对象；
• 不受限制的插件机制。

对于医疗影像、科研数据和实验自动化场景，动态执行必须明确：

• 输入来源；
• 白名单；
• 沙箱；
• 审计日志；
• 权限边界；
• 异常回滚。

---

4. 疑似敏感字面量：测试样例与真实密钥必须严格隔离

代表性路径包括：

tests/_contract/schematic.py

需要确认：

• 是否仅为测试用占位 Token；
• 是否混入真实 API Key、密码或私钥；
• 是否有历史泄漏风险；
• 是否存在 .env 文件被误提交；
• 是否在日志中打印认证信息；
• 是否建立密钥轮换机制。

建议接入独立的 secret scanning 流程，而不是只依赖代码审阅。

---

十四、对科研团队而言，最重要的不是“全量启用”，而是分级启用

162 个 Skill 的价值很大，但不应一次性赋予它们相同权限。

建议根据任务风险分成三类。

A 类：低风险辅助任务，可优先 PoC

例如：

• 科学写作提纲；
• 文献摘要整理；
• 图表说明草拟；
• Markdown、表格、PPT 排版辅助；
• 研究问题头脑风暴；
• 非敏感公开数据的初步探索。

特点是：主要输出文本、结构化建议或低风险文件。

---

B 类：需要人工复核的科研分析任务

例如：

• 生存分析；
• 贝叶斯模型；
• SHAP 可解释性；
• 地理空间分析；
• PK/PD 建模；
• 统计检验；
• 实验方法验证。

特点是：可能生成数值、结论、图表或模型解释，必须由领域专家复核。

---

C 类：高敏感或高影响任务，必须严格隔离

例如：

• 病原体变异监测；
• 医疗影像处理；
• 临床或患者数据分析；
• 药物研发；
• 实验室硬件控制；
• 标准或法规准备度判断；
• 涉及受限数据或商业机密的研究任务。

这类任务不适合直接在本地全权限环境中运行。应具备：

数据脱敏
权限隔离
日志审计
工作区限制
依赖锁定
人工审批
结果复核
版本可追溯

---

十五、建议的 PoC 验证方案

如果团队准备引入该项目，建议采用“小范围、可回滚、可审计”的方式。

第一步：固定版本和隔离环境

固定以下信息：

Git Commit SHA
Python 版本
操作系统版本
依赖安装命令
虚拟环境配置
模型版本
Skill 版本
输入数据版本
输出目录

不要直接使用默认分支的浮动版本，也不要让 Agent 直接读取整个研发目录。

---

第二步：只选择 1～3 个目标 Skill

例如，先验证：

research-lookup
scientific-brainstorming
xlsx
shap

不要一开始就尝试所有 162 个 Skill。

每个 Skill 都应该建立独立验证清单：

检查项	示例问题
è¾“å ¥	支持哪些文件、数据格式和参数？
输出	生成什么文件，是否覆盖已有产物？
依赖	是否需要外部命令、数据库或 API？
权限	是否访问网络、文件系统或系统命令？
可复现性	ç›¸åŒè¾“å ¥æ˜¯å¦è¾“å‡ºç¨³å®šï¼Ÿ
正确性	èƒ½å¦ä¸Žå‚è€ƒå·¥å ·æˆ–äººå·¥ç»“æžœæ¯”å¯¹ï¼Ÿ
失败处理	ç¼ºä¾èµ–ã€åæ•°æ®ã€è¶ æ—¶å¦‚ä½•è¡¨çŽ°ï¼Ÿ

---

第三步：执行最小测试和专项测试

建议先从项目声明的测试入口开始，再运行目标 Skill 对应测试。

应完整记录：

安装日志
测试命令
环境变量
测试结果
失败日志
依赖版本
测试数据来源

注意：本文未实际执行测试，因此不对测试通过率作出判断。

---

第四步：做真实任务对照实验

对于科学计算类 Skill，应建立对照组：

Agent / Skill 结果
vs.
人工分析结果
vs.
权威工具结果
vs.
公开基准数据结果

例如：

• 用 SciPy、R、SAS 或已验证脚本对照统计结果；
• 用人工标注文献集对照检索和摘要质量；
• 用固定影像样例对照 DICOM 处理结果；
• 用已知模型解释案例验证 SHAP 输出；
• 用标准实验数据验证方法学检查结果。

---

第五步：对 Shell、路径和动态执行单独安全审阅

这是最容易被忽视、但最重要的一步。

建议对所有目标 Skill 检查：

是否执行命令？
是否调用 shell=True？
是否将模型输出拼入命令？
是否访问任意路径？
是否允许软链接跳转？
是否加载外部脚本？
是否自动下载依赖？
是否输出或记录敏感数据？

---

十六、最终评价

基于提交 4d265d04b3bd86b384d8e8f10920dafa38634ab9 的静态源码证据，可以形成以下稳妥结论：

scientific-agent-skills 是一个 Python 主导、Skill 数量较多、科学领域覆盖广泛的 Agent Skill 仓库。项目存在 Skill 扫描、PR 检查、测试、CI、依赖配置和许可证等工程治理线索。其设计适合用作科研 Agent 能力库和科学工作流自动化的 PoC 候选，但每个 Skill 的依赖、输入输出、权限范围、科学正确性和安全边界都需要独立验证。

对于技术负责人，最值得记住的是：

• 162 个 Skill 是覆盖广度，不是质量保证；
• 100 项测试线索是积极工程信号，不是测试通过证明；
• Shell、路径和动态执行静态命中需要人工复核，不应直接定性为漏洞；
• 科学计算结果必须与权威工具、基准数据和专家判断交叉验证；
• 涉及医疗、病原体、药物、实验室和受限数据时，必须采用隔离、审计和审批机制。

---

十七、评测边界说明

本文只基于指定提交快照中的静态证据进行整理，包括：

• 目录结构；
• 文件语言分布；
• Skill 条目数量；
• 构建配置；
• 测试文件线索；
• CI 工作流；
• 许可证文件；
• 抽样 AST 结构；
• 静态风险规则命中。

本文未执行：

• 项目安装；
• 官方测试；
• 覆盖率统计；
• 依赖漏洞扫描；
• 性能压测；
• 网络调用验证；
• 外部工具验证；
• 科学计算正确性审计；
• 医疗、药物或法规合规审查；
• 生产部署验证。

因此，本文适合作为技术尽调、科研 Agent 选型和 PoC 前的阅读材料，不应作为安全、科研、法规或生产上线放行依据。

---

参考信息

• 项目仓库：https://github.com/K-Dense-AI/scientific-agent-skills
• 审阅快照：4d265d04b3bd86b384d8e8f10920dafa38634ab9
• 构建配置：pyproject.toml
• 核心扫描入口：
  • scan_skills.py
  • scan_pr_skills.py
• 代表性测试入口：
  • tests/run_all.py
  • tests/conftest.py
• CI 工作流：
  • .github/workflows/skill-tests.yml
  • .github/workflows/skill-spec-validation.yml
  • .github/workflows/pr-skill-scan.yml
  • .github/workflows/security-scan.yml

---

关键词： AI Agent、Agent Skills、科学智能体、科研自动化、Python、科研工作流、科学计算、数据分析、医学影像、生物信息学、PKPD、SHAP、Qiskit、静态代码审阅、AI 科研助手、科研数据治理