BioSymphony
为生物学研究构建AI代理工具套件的完整图谱

🌐BioSymphony全景：一个组织，九个仓库

2026年的AI4Science领域正在经历一个范式转移：从"用一个LLM回答一个科学问题"转向"让一个代理团队驱动一个完整的研究战役"。前者是问答，后者是工作流。前者消耗token，后者消耗GPU时间、实验耗材和研究者数周的注意力。这个转移提出了一个新问题：谁来为代理团队提供可信赖的操作轨道？

BioSymphony是一个正在系统性回答这个问题的开源组织。它的使命声明只有一句话："AI agent tools for biological research." 但这句话背后的工程量是巨大的——生物学研究有多个截然不同的子领域，每个子领域有自己的工具链、数据格式、计算需求和claim标准。BioSymphony的策略是为每个子领域构建一个独立的、可fork的技能仓库，同时用一套统一的设计哲学保证它们可以组合使用。

这9个仓库不是独立开发的孤岛。它们共享一套设计模式：每个仓库都包含一个SKILL.md作为代理入口点、一个AGENTS.md定义工作规范、JSON Schema契约约束输入输出、本地demo使用synthetic fixture、云升级路径通过provider profile守卫、以及一个NON_CLAIMS.md显式声明仓库不声称什么。这种一致性意味着一个学会了使用BioProspector的研究者可以在30分钟内开始使用CryoCore——因为操作范式是相同的。

本文将逐一深度拆解这9个仓库的架构、核心抽象和设计决策，最后提炼出对AI4Science领域的启示。

🧬BioProspector：生物合成路径的代理战役

BioProspector解决的是一个经典合成生物学问题：给定一个目标分子和宿主，找到从宿主代谢物到目标分子的生物合成路径——包括哪些酶催化哪些步骤、这些酶的基因来自哪里、哪些步骤是已知的、哪些是"暗步骤"（dark steps，未知化学或未知基因）。

这个问题之所以适合代理化，是因为它本质上是一个长期、多阶段、需要跨多个数据库推理的探索任务。一个人类研究者可能需要数周来完成的路径空间展开、酶候选挖掘、暗步骤假设生成和construct设计，一个有合适工具的代理可以在数小时内完成规划阶段——但前提是代理不会在过程中丢失上下文、不会跳过关键约束、不会把规划输出伪装成实验验证。

核心抽象：campaign contract

BioProspector的核心是一个campaign contract——一个持久化的JSON文档，记录目标分子、宿主、约束、可用计算、工作道（work lanes）、已完成的搜索和已生成的工件。这个contract是所有代理协作的单一真相源（single source of truth）：无论你用Claude Code、Codex还是Symphony with Linear，无论你在笔记本上还是在RunPod上，contract保持一致。

关键设计决策：checkout小，数据外置

BioProspector做了一个关键架构决策：checkout保持小、可fork、可审计。仓库只包含技能、提示词、schema、验证器和campaign产生的紧凑摘要与排名。重数据（原始reads、数据库快照、模型权重、完整搜索输出）留在研究者拥有的存储中，checkout只持有指向它们的指针和校验和。

这个决策有三个后果：(1) 仓库可以快速clone和fork，不会因为数据膨胀而变得难以管理；(2) 敏感数据永远不会进入git历史；(3) 一个campaign可以在不同机器之间迁移——只需要迁移checkout和指向外部数据的指针。

三个公开示例战役

BioProspector内置三个target-swappable的示例战役：vanillin（香草醛，经典风味分子）、nootkatone（诺卡酮，葡萄柚香气）和Huperzine A（石杉碱甲，乙酰胆碱酯酶抑制剂）。这三个例子覆盖了不同复杂度的生物合成场景，所有都是planning-only——它们在validated claim之前停止，因为没有真实搜索运行过。

🏗️Structure Factory：结构生物学多代理战役工厂

Structure Factory是BioSymphony中工程量最大的仓库。它处理的是结构生物学的完整战役：从生物目标到binder设计、结构预测、候选筛选、排名、渲染和云运行规划。如果说BioProspector是"一个目标→多条路径"，Structure Factory就是"一个目标→多条agent lane并行→收敛为ranked report"。

核心抽象：agent lane fan-out

Structure Factory的核心模式是lane fan-out：一个战役目标被分解为并行的agent lane——design（设计）、fold/cofold（折叠/共折叠）、score/triage（评分/分诊）、render（渲染）、screen（筛选）。每条lane调用各自的工具，然后所有lane的结果收敛为一个ranked、checked的report，包含候选、置信度、失败行、图和provenance。

时间维度：从5分钟到operator-gated运行

Structure Factory显式定义了时间维度，让研究者知道每个阶段能得到什么：

计算后端：从笔记本到neocloud

Structure Factory支持多种计算后端：本地工作站（规划不需要GPU）、RunPod pods、Lambda Cloud GPU VM、Modal serverless GPU、AWS Batch和EC2 GPU、通用云VM、SSH/HPC。每个provider有一个profile，携带预算、清理、license-gate和closeout要求。这意味着同一个campaign可以在本地规划、在RunPod上运行生成lane、在AWS Batch上运行筛选lane——而不需要改变contract。

💊Small Molecules：小分子设计的路由技能

Small Molecules是BioSymphony中最轻量但可能最实用的仓库。它不是一个执行引擎，而是一个路由技能——帮助代理在小分子设计的130+个工具中做出正确选择，同时保持license和数据约束可见。

这个仓库解决的是一个被低估的问题：当代理被要求"为这个靶点设计一个hit的类似物"时，它面前有数十条路径——生成可合成类似物、投影到可合成空间、规划逆合成路线、docking、co-folding、结合亲和力预测、QSAR、ADMET、口袋条件生成——每条路径有多个工具选择，每个工具有不同的license条款。一个没有路由技能的代理要么(1)默认使用它最熟悉的工具（不管是否合适），要么(2)试图加载所有工具的上下文（context爆炸），要么(3)忽略license约束（法律风险）。

两层设计循环

Small Molecules定义了一个两层循环：

靶点层：结构/docking/co-folding/亲和力 → QSAR/ADMET/selectivity → 候选集

合成层：候选集 → 可合成投影和类似物 → 逆合成和路线检查 → 可合成候选 → 回到靶点层

这个循环的关键洞察是：靶点评分和可合成性不是两个独立问题，而是一个闭环。一个docking score极好的分子如果无法合成，就是无用的；一个容易合成的分子如果docking score很差，也是无用的。代理需要在两个层之间迭代，而Small Molecules的路由表让代理知道每一步应该用哪个工具。

License审查作为一等公民

Small Molecules做了一件大多数类似工具忽略的事：把license审查作为一等公民。它的licensing-and-data.md参考文件区分了四种不同的license条款——源代码license、模型权重license、数据license和base-model license——因为这些条款经常不同。一个工具可能源代码是MIT（开放），但模型权重是CC-BY-NC（非商业），或者数据是公开的但base-model有使用限制。代理在推荐工具之前必须检查所有四个层面。

仓库内置一个KRAS分子胶（molecular glue）的紧凑示例，使用PDB 9BG6的公开数据，展示如何将两层循环应用到一个真实靶点。

🔍GeneCluster：天然产物基因组挖掘的长期战役

GeneCluster处理的是天然产物发现中最耗时的环节：在公共基因组和转录组数据中搜索生物合成基因簇（BGC），比较候选簇，规划follow-up工作。一个典型的请求像这样：

"在毛茛目中表征苯甲基异喹啉生物碱（BIA）基因簇。以Coptis chinensis（黄连）作为canonical producer，然后在Berberis vulgaris（小檗）和另外两个小檗科物种中寻找相关簇。告诉我哪些酶是保守的，哪些看起来是物种特异的，以及簇边界落在哪里。"

这个请求涉及多个物种的基因组搜索、同源性分析、BGC调用、共线性分析、功能评分和比较——每一步都可能需要不同的工具和不同的计算资源。GeneCluster为这种长期任务提供了可重复的操作轨道。

路由与声明上限

GeneCluster的一个关键创新是route-claim ceiling：可用数据的状态决定了路由选择，每条路由携带一个明确的声明上限。例如，一个transcript-first运行可以提名候选基因，但物理簇边界需要基因组坐标——如果只有转录组数据，代理就不能声称簇边界，只能声称候选基因。

累积目录模式

GeneCluster引入了一个累积目录模式：每个完成的campaign可以将物种行、novelty窗口和簇置信度注释添加回data/pathway-species-catalog.tsv，这样后续campaign就可以从更好的上下文开始。这个模式承认了一个现实：比较基因组学是一个累积过程，不是一个一次性任务。每次campaign的产出不仅是当前问题的答案，还有对未来campaign的上下文贡献。

🧪Ferm DoE：发酵工艺实验设计的完整闭环

Ferm DoE是BioSymphony中我们已经深度拆解过的仓库（参见专文分析），这里做一个简要回顾。

Ferm DoE处理的是发酵工艺优化中最昂贵、最不可逆的环节：实验设计（DoE）。一次2L生物反应器批次可能耗时5-7天，耗材成本数千元，而一次错误的实验设计意味着整周产能被浪费。Ferm DoE为代理提供了一个完整的DoE技能：9个profile（screening、optimization_rsm、mixture、split_plot_fed_batch、scale_up_bridge、scale_down_qualification、confirmation、sequential_augmentation、custom）、14个DoE家族、47个BO/DoE工具注册表、9个readiness gate（RED/YELLOW/GREEN三态决策）、scale-bridge资格认证（kLa/P/V/tip-speed/mix_time/DO/OUR/RQ/VVM）、五层成本诚实栈（simulator/bulk reagent/fully-loaded COGS/CMO/range）、Scientific Swarm cumulative dossier、设计锦标赛裁决。

全部状态锚定在一个durable的campaign_manifest.json上，可暂停、可恢复、可在笔记本/CI/AWS Lambda/Modal之间无缝切换。核心哲学：LLM做开放式推理，一切可验证的判断由确定性代码执行，每个输出带claim level自我标注。

❄️CryoCore：冷冻电镜的代理操作层

CryoCore为冷冻电镜（cryo-EM）工作提供了一个完整的代理操作层。冷冻电镜是结构生物学中最复杂的工作流之一——从原始电影（raw movies）到校正显微图（corrected micrographs）、粒子（particles）、map、model、figure和state-review——每一步都需要不同的工具和不同的计算资源。

核心抽象：lane module

CryoCore的核心抽象是lane module——JSON Schema定义的流水线阶段，每个阶段描述输入、输出、工具和验证要求。三个核心lane module：

• raw-to-map.v1.json：原始电影→校正显微图→粒子→map
• map-to-model.v1.json：map→原子模型→验证
• figure-dossier.v1.json：模型→figure→比较→review

工具姿态文档

CryoCore做了一件在科学软件中罕见的事：它维护一个工具姿态文档（tool posture doc），明确记录每个冷冻电镜工具适合哪条lane、在什么license条款下可用。工具被分为三条lane：

代理从这catalog中选择工具，而不是猜测。这解决了冷冻电镜领域的一个实际问题：工具众多，license条款复杂，代理容易推荐一个它无权使用的工具。

Provider profile统一

CryoCore为RunPod、AWS Batch、AWS EC2、SSH/HPC Slurm、neocloud GPU pod、通用云GPU VM和本地工作站都提供了provider profile。每个profile携带预算和清理gate。用户可以用相同的schema编写自己的profile。这意味着一个冷冻电镜workflow可以在本地规划、在RunPod上运行粒子拾取、在AWS Batch上运行map refinement——而不需要改变contract。

☁️NeoCloud Bridge：云执行的守卫层

NeoCloud Bridge是BioSymphony生态中的基础设施层。它解决的是一个被普遍低估的问题：代理可以写workload，但云provider仍然需要一个操作员。代理知道要运行什么，但不知道是否被允许启动这个pod、预算是否合理、source是否安全、artifact是否到位、清理是否完成。

NeoCloud Bridge给代理提供了这个操作员层：选择正确的计算、检查启动是否被允许、安全准备source、运行provider workflow、带回artifact、记录成本、证明清理。

核心工作流

NeoCloud Bridge的工作流是线性的，但每一步都有守卫：

Linear issue → Symphony Codex worker → local preflight → provider workflow → startup workload → logs/artifacts/hashes → cleanup → Linear symphony-outcome

不可协商的原则

自学习循环

NeoCloud Bridge有一个独特的自学习循环：代理可以记录它们在某个provider上遇到的问题，并稍后搜索这些笔记，这样同一个问题不会被解决两次（cloud-bridge learnings）。这解决了一个代理工作中的常见问题：每次遇到相同的provider gotcha都要重新调试。通过将学习记录外部化到可搜索的笔记中，后续代理可以直接复用。

Provider覆盖

NeoCloud Bridge覆盖了四类云surface：

• Pod和VM租赁：RunPod、Lambda Cloud、AWS、Beam
• Function和batch计算：Hugging Face Jobs、Modal、Kaggle、GCP/Vertex
• Managed inference API：Boltz、ESM、NVIDIA NIM、Replicate、fal、Together
• Cloud glue：S3/object-store egress、secret引用、launch lock、cleanup backstop

🐍Proteus：结构生物学终端自动化

Proteus是BioSymphony伴侣工具中最实用的一个。它是一个结构生物学代理技能和stdlib-only helper工具包，教代理如何从终端做AI蛋白质结构分析：解析蛋白质、获取结构、检查AlphaFold置信度、渲染PyMOL图、自动化ChimeraX分析、比较模型、验证实验结构、推理蛋白质设计工具。

23个文档化的gotcha

Proteus最有价值的资产可能是它的23个文档化的gotcha——PyMOL、ChimeraX、AlphaFold DB、渲染和冷冻电镜map的hard-won调试经验。这些gotcha来自真实调试，否则会浪费研究者数小时。例如：

• PyMOL headless渲染的0-byte-PNG竞争条件
• ChimeraX REST渲染的GUI session管理和清理
• AlphaFold DB的pLDDT/PAE解释陷阱
• CA-only backbone（RFdiffusion/Genie设计）需要HELIX-record注入才能正确渲染cartoon
• MRC/CCP4 map的sigma-based contour level建议

优雅降级

Proteus的一个核心设计原则是优雅降级：pdb_info.py和AlphaFold metadata fetch在零本地工具下工作。当PyMOL或ChimeraX可用时，代理可以渲染publication-quality图或运行SASA、H-bond、alignment和冷冻电镜workflow。这意味着代理可以在任何环境下开始工作——即使是在一个刚安装Python的CI runner上——然后随着工具的可用性增加而扩展能力。

能力矩阵

🎤BioVoice：语音驱动的分子可视化

BioVoice是BioSymphony生态中最独特的仓库。它不是一个代理技能，而是一个语音控制接口——用plain English控制PyMOL和ChimeraX，基于OpenAI Realtime API构建。虽然它被定位为研究原型，但它展示了一个有趣的交互范式：结构生物学家可以口头描述他们想看到的分子场景，而不需要记忆命令语法。

双受众设计

BioVoice明确服务于两个受众：

对结构生物学家：说plain English，模型调用结构化工具直接驱动PyMOL和ChimeraX。不需要记忆命令语法，不需要在session之间查找selector，不需要第二个显示器放cheat sheet。AlphaFold置信度review、Rosetta scaffold-versus-design比较、冷冻电镜handoff和ligand-pocket walkthrough都作为命名workflow运行。

对开发者和AI工程师：BioVoice是一个OpenAI Realtime API tool calling应用于真实科学软件的工作参考——不是玩具。你得到，在一个可读的TypeScript repo中：9个Realtime function tool、9个task-level AlphaFold和Rosetta workflow、database-backed structure resolution、production-grade JSON Schema selector、two-adapter pattern（PyMOL over XML-RPC和ChimeraX over REST）、get_target_state grounding和offline rehearsal mode。

9个Realtime function tool

隐私设计

BioVoice的隐私设计值得注意：分子文件留在本地，只有语音音频通过WebRTC发送到OpenAI。tool-call文本（残基名称、链ID、文件路径引用）作为live voice操作的一部分发送。这解决了结构生物学领域的一个敏感问题：研究中的未发表结构不能上传到云端，但语音接口的便利性又很有吸引力。BioVoice通过将文件留在本地、只发送音频和命令文本来平衡这个矛盾。

🧭统一设计哲学：九个共享原则

虽然BioSymphony的9个仓库覆盖截然不同的领域，它们共享一套统一的设计哲学。这套哲学不是事后总结的，而是从一开始就贯穿在每个仓库的架构决策中。理解这套哲学比理解任何一个仓库的细节更重要，因为它定义了BioSymphony对"AI4Science代理工具应该是什么"的整体立场。

这九个原则构成了一个连贯的立场：代理是研究者的放大器，不是替代品。代理可以处理繁琐的上下文收集、文件准备、例行检查和早期发现总结，但科学判断——设定问题、选择输入、解释输出、决定下一步分析或实验——始终属于研究者。这个立场在AI4Science领域尤为重要，因为科学的可信度建立在人类研究者的判断责任之上。

🔗技能组合：跨仓库协作的真实场景

BioSymphony的9个仓库不是孤立使用的。它们的统一设计哲学使得跨仓库协作成为可能。以下是几个真实的跨仓库协作场景：

场景1：从基因组挖掘到结构验证

一个研究者用GeneCluster在公共基因组中找到一个候选BGC，用BioProspector将BGC的酶映射到生物合成路径，然后用Structure Factory为路径中的关键酶设计binder或预测结构。最后用Proteus渲染publication-quality图。整个流程中，NeoCloud Bridge守卫云升级——当BLAST搜索需要在RunPod上运行时，它检查预算、准备source、记录成本、证明清理。

场景2：从小分子hit到发酵工艺

一个研究者用Small Molecules为一个靶点设计hit类似物，路由到正确的docking和ADMET工具。选定候选后，用BioProspector设计生物合成路径（如果分子是天然产物衍生物），然后用Ferm DoE规划发酵工艺优化——从screening到scale-up bridge。整个流程中，campaign_manifest.json（Ferm DoE）和campaign contract（BioProspector）保持状态持久化。

场景3：冷冻电镜结构解析全流程

一个研究者用CryoCore规划从raw movies到map到model的完整冷冻电镜workflow。NeoCloud Bridge守卫RunPod上的RELION运行。Structure Factory接管map-to-model后的binder设计和候选筛选。Proteus渲染最终图。BioVoice让研究者在演示时用语音控制分子可视化——"显示这个binder与target的interface，突出热点残基"。

场景4：教学与演示

一个教育者用BioVoice在课堂上用语音控制PyMOL和ChimeraX，让学生看到分子结构如何响应plain English命令。课后，学生用Proteus在本地练习结构分析，用Structure Factory的公开示例学习binder设计workflow。所有demo使用synthetic fixture，不涉及真实实验数据。

🛡️声明边界与科学诚信

BioSymphony对声明边界的执着是它最值得学习的特征之一。每个仓库都有一个NON_CLAIMS.md文件，显式声明仓库不声称什么。这不是法律免责条款，而是科学诚信的工程化表达。

这种声明边界的工程化体现在几个层面：

• Claim level自我标注：每个输出带一个claim level标签，明确这是planning、execution、search output、controls还是claim record
• Readiness gate：Ferm DoE的RED/YELLOW/GREEN三态决策确保不完整的campaign不会被推进到执行
• Route-claim ceiling：GeneCluster的每条路由携带明确的声明上限
• Tool posture doc：CryoCore的工具姿态文档区分open/watch/gated，防止代理推荐无权使用的工具
• Public safety audit：每个仓库有public_audit.py扫描本地路径、密钥和链接

💡对AI4Science的启示

BioSymphony的9个仓库 collectively 提供了几个对AI4Science领域的深刻启示：

启示1：技能比应用更重要

BioSymphony没有构建一个"万能科学代理应用"，而是为每个子领域构建了一个可fork的技能仓库。这个选择反映了一个洞察：科学研究的多样性意味着一个统一应用无法服务所有领域。一个冷冻电镜workflow和一个发酵DoE workflow的工具链、数据格式、计算需求和claim标准完全不同。技能仓库模式允许每个领域有自己的工具路由、契约和验证器，同时共享一套操作范式。

启示2：durable artifact是长期任务的基础

所有BioSymphony仓库都依赖某种形式的durable artifact——campaign contract（BioProspector）、campaign manifest（Ferm DoE）、stage contract（CryoCore）、launch manifest（NeoCloud Bridge）。这些artifact是长期任务的基础：它们让任务可以跨session、跨代理、跨机器继续。没有durable artifact，代理工作就是一次性的——每次session结束后上下文丢失，下次必须从头开始。

启示3：local-first降低门槛和风险

BioSymphony的local-first原则有两个好处：(1) 降低使用门槛——研究者可以在本地开始，不需要先配置云账号；(2) 降低风险——敏感数据不离开本地，云升级是opt-in的。这个原则对于科学领域尤为重要，因为研究数据经常涉及未发表结果、知识产权和合规约束。

启示4：声明边界是科学诚信的工程化

BioSymphony对声明边界的执着——NON_CLAIMS.md、claim level自我标注、readiness gate、route-claim ceiling、tool posture doc——是科学诚信的工程化表达。它不是法律免责，而是承认一个现实：代理输出的可信度取决于它声称什么和不声称什么。一个不区分planning和execution的代理输出是危险的，因为它可能被误读为实验验证。

启示5：license作为一等公民

Small Molecules和CryoCore把license作为一等公民——区分code/weights/data/base-model四层，区分open/watch/gated三条lane。这在AI4Science领域尤为重要，因为科学工具的license条款经常比通用软件更复杂（学术vs商业、开源vs付费、数据vs模型）。一个不检查license的代理可能推荐一个研究者在商业项目中无权使用的工具，造成法律风险。

启示6：代理是放大器，不是替代品

BioSymphony的立场声明——"科学判断属于研究者"——是AI4Science领域最重要的立场之一。代理可以处理繁琐的上下文收集、文件准备、例行检查和早期发现总结，但科学判断始终属于人类研究者。这个立场不是谦虚，而是科学方法论的要求：科学的可信度建立在人类研究者的判断责任之上。一个声称可以替代研究者判断的代理系统，要么是过度承诺，要么是对科学方法论的不理解。

启示7：跨仓库协作需要统一哲学

BioSymphony的9个仓库可以协作，不是因为它们共享代码，而是因为它们共享设计哲学。一个学会了使用BioProspector的研究者可以在30分钟内开始使用CryoCore——因为操作范式相同：读SKILL.md、运行doctor、启动local demo、给代理一个mission。这种一致性不是偶然的，而是从一开始就贯穿在每个仓库的架构决策中。对于构建AI4Science工具生态的团队，这是一个重要启示：生态一致性比单个仓库的完美更重要。

📄项目信息

注：本文基于BioSymphony组织网站及9个仓库的公开README、AGENTS.md、SKILL.md和源码分析撰写。所有引用的设计声明均锚定于仓库实际文件。仓库状态为pre-alpha或早期阶段，所有公开demo均为synthetic planning fixture，不构成lab-validation或production-readiness声明。Ferm DoE部分引用了本站专文分析。