每个搞过生物信息学的人都经历过那种绝望时刻。你兴冲冲地打开一个基因组组装工具，以为自己的MacBook Pro能扛得住，结果风扇转得跟直升机起飞似的，屏幕开始卡顿，最后弹出那个让人心碎的提示："内存不足"。这时候你才意识到，自己试图用一台办公电脑去处理需要几百GB内存的任务，就像试图用自行车拉火车车厢一样荒谬。
Biomni智能体的设计团队早就看透了这一幕。他们知道，真正的生物医学研究不是在做PPT，而是在跟海量数据搏斗。一个典型的结构生物学任务可能需要同时调用AlphaFold、ChimeraX和GROMACS，这些工具不仅需要GPU加速，还要加载TB级别的参考数据库。把这些东西塞进一台笔记本电脑，相当于试图把一头大象塞进冰箱，而且还不关门。
所以Biomni做了一个关键决策：给智能体配一个"外挂大脑"。这个外挂不是简单的云存储，而是一整套高性能计算基础设施，专门用来处理那些能让普通电脑崩溃的任务。当智能体遇到算力瓶颈时，它可以无缝切换到这套系统，获得数千倍的计算能力提升。这就像给赛车手配了一个氮气加速装置，平时不用，关键时刻一按按钮就能起飞。
为什么要造这个"算力外挂"
Biomni智能体平时运行在一个沙盒环境里，这个环境大概跟一台普通笔记本电脑差不多强，预装了很多常用的生物信息学工具。对于大部分日常任务，这个配置完全够用。但生物信息学的残酷之处在于，你永远不知道下一个任务会不会是个"怪兽"。
有些基因组组装器需要几百GB内存，有些结构生物学工作流需要一整队GPU协同作战。如果给每个智能体会话都预配这些资源，那成本会高到离谱，而且99%的时间这些资源都在闲置。这就像为了应对每年一次的搬家，平时每天都开着一辆大货车上下班，显然不现实。
Biomni的解决方案是"按需租用"。智能体只在需要时才调用HPC资源，用完即释放。这种弹性架构让资源利用率大幅提升，同时也让智能体具备了处理极端任务的能力。更重要的是，这种设计隔离了那些难搞的生物信息学软件。有些生物信息学工具没法通过pip或conda安装，环境依赖还经常冲突。与其在一个环境里硬塞所有东西，不如给每个工具配一个独立的"公寓"，互不打扰。
参考数据库：那些让硬盘哭泣的TB级文件
生物信息学领域有个特殊的存在叫"参考数据库"。这些文件是计算生物学工具分析数据时的必备参考资料。有些工具，比如AlphaFold，需要TB级别的参考数据库才能运行。做AI的朋友可以把它理解为模型权重，但比模型权重更麻烦的是，这些文件不是训练出来的，而是从各种生物数据库下载的。
下载这些文件是个噩梦。有时候需要几天时间，中间网络一断就得重来。Biomni为了解决这个问题，提前把常用的参考数据库预置在一个高速共享文件系统上。这就像在图书馆里把常用参考书放在柜台旁边，而不是让读者每次都要去地下室仓库找。
这个预置策略极大地加速了HPC的响应速度。智能体不需要等待下载，可以直接开始计算。对于研究人员来说，这意味着从提出假设到获得结果的时间大幅缩短。原本可能需要等一周的数据准备，现在几分钟就能搞定。这种体验提升是质的飞跃，让研究者可以专注于科学问题本身，而不是跟下载进度条较劲。
智能体如何跟HPC"对话"
Biomni智能体可以在任务执行的任何阶段调用HPC资源，它知道哪些计算生物学工具已经在HPC里配好了环境。但它不需要记住每个工具的细节，那会把上下文撑爆。相反，它只记住基础信息：工具名称，以及如何获取更多细节。这种分层记忆策略让智能体能把注意力集中在当前任务上，而不是被海量工具文档淹没。
当智能体需要某个工具时，它可以按名称或类别搜索。比如搜索"结构生物学"，系统会返回AlphaFold、ChimeraX、GROMACS、OpenFold等工具的详细信息。这些详细信息就像给人类看的操作手册，包含使用示例、命令行参数说明、调试注意事项。这种设计几乎总能激发前沿大模型产生合理的使用方式，即使这个计算生物学工具根本没出现在模型的训练数据里。
一旦智能体理解了工具用法，它就会通过HPC启动工具。跟标准生物信息学API不同，智能体自己编写完整的命令行参数，并且能看到命令运行的完整输出。这两点对模型适应意外故障或特殊用法至关重要。如果命令失败了，智能体可以看到错误日志，分析问题，然后调整参数重试。这种反馈循环让系统具备了强大的自我纠错能力。
异步架构：让智能体学会"多线程思考"
当HPC任务提交后，它在后台异步运行，系统会调度一个"通知智能体"的回调函数。任务完成时，这个回调自动触发，告知智能体任务状态。如果智能体正在活跃状态，通知直接注入当前会话；如果智能体处于空闲，系统会唤醒它，然后从断点继续工作。
Biomni还建了一个HPC任务监控面板，让研究人员能实时查看运行中的任务。可以查看实时状态、随时检查日志、取消异常任务。如果任务被取消，回调机制立即通知智能体，智能体据此调整后续工作流。
这种异步设计解决了两个关键问题。首先，智能体不需要阻塞等待HPC任务完成，可以继续处理其他事情或跟用户交互。其次，长时间运行的任务不会因为智能体沙盒超时而中断。有些HPC任务要跑几小时甚至几天，如果智能体一直守着，可能会因为会话超时而前功尽弃。异步架构让任务和智能体生命周期解耦，实现了真正的"后台计算"。
架构选择的哲学：灵活 versus rigid
Biomni团队面临的最有趣决策是：给智能体多大程度的灵活性。具体有三个选项。选项A是刚性抽象，LLM调用预实现和验证好的生物信息学包API。选项B是灵活抽象，LLM在预配置环境里运行任意命令，但只能访问一组受限环境和使用说明。选项C是无抽象，LLM完全自管理基础设施，相当于给智能体一个独立的AWS账户。
团队最终选择了灵活抽象。这意味着有一个预配置和测试好的生物信息学工具列表，但智能体自己编写在环境里运行的shell命令。为了帮助智能体写对命令，每个环境都有详细的使用指南。
在这种模式下，如果智能体选择链式执行，可以在同一个HPC环境里运行多个命令。比如Kraken2的输出经常被Bracken立即分析。因为智能体自己写命令，它可以这样调用：kraken2 [...] && bracken [...]。这种灵活性是刚性API无法比拟的。
灵活抽象的韧性体现在它能处理失败情况，甚至是超出其范围的问题，比如内存不足错误。它支持长尾用例的能力也让它比刚性API更有用。随着LLM能力不断提升，这种灵活抽象的价值会持续增加，直到智能体能有效自管理更复杂的基础设施和环境。
从API设计到基础设施实现
确定抽象层级后，团队开始构建API。他们设计了六个程序化工具：工具搜索、提交HPC任务、检查任务状态、查看任务日志、获取任务结果、取消活跃任务。这里重点介绍工具搜索和提交HPC任务。
工具搜索底层调用一个API，搜索已测试工具的注册表。当Biomni搜索工具时，向HPC API的/v1/tools发送GET请求。收到结果后，Biomni知道要渐进式解析，因为usage字段可能特别消耗token。
提交HPC任务时，智能体发送POST请求到HPC API的/v1/jobs来启动作业。请求中的command值由智能体根据使用指南编写。这种灵活性胜过刚性API：如果作业失败，智能体可以检查日志并重写命令来修复问题或调试环境。
当然这种API也有缺点。无效参数需要更长时间才能失败，智能体可能使用一组完全不合理的参数组合。但总体上，它仍然比刚性API工作得更好，因为它的故障韧性和对特殊工具用法的支持，这些在刚性API里默认会被阻止。
应对规模化挑战：从阻塞到异步
随着工具使用量开始规模化，团队构建了两个功能来保持HPC的响应性和可靠性。驱动这两个功能的两个反复出现的问题：智能体停下来等待HPC任务完成，阻塞了会话进度；有些HPC任务运行数小时或数天，这些长任务带来了新的故障模式。
智能体可能在数小时的用户交互和上下文压缩后，忘记正在运行的HPC任务的存在。HPC任务可能超出智能体沙盒超时限制，扰乱HPC生命周期。
为了解决这些问题，团队重新设计了HPC系统为异步优先，并引入了智能体通知回调机制。这种架构下，智能体在HPC任务完成时收到通知。这消除了智能体执行循环中的阻塞行为，并在需要时自动重新激活智能体沙盒。因为HPC任务不再阻塞会话，研究人员可以在计算工作负载后台运行时继续与Biomni交互，甚至可以离开会话而不中断任何正在进行的任务。
这种向异步事件驱动模型的转变帮助团队在规模化时保持HPC的响应性和可靠性，用户体验也与真实世界研究工作流更契合。
AWS基础设施的四支柱
在基于AWS的HPC执行器上，有四个关键组件。第一是经过测试的容器镜像，提供可复现的软件环境。第二是预下载的参考数据库。第三是输入输出文件的暂存区。第四是HPC沙盒的基础设施。
每个通过Biomni HPC可用的生物信息学软件都有一个对应的镜像，经过测试确保可用。这些镜像存储在AWS Elastic Container Registry。这些镜像比典型Web应用镜像大得多，从几百MB到几十GB不等。有些镜像是团队自己构建的，其他则从Biocontainers或BioContainers等社区资源移植并测试。
为了支持不同镜像的最大兼容性，镜像内部没有依赖要求，不需要包含aws、wget、curl等命令行工具。相反，团队有独立的Phylo管理的I/O容器，负责在环境和外部之间移动输入输出数据。
许多计算生物学工具需要参考数据库。小参考数据库（比如小于1GB）可以包含在工具镜像里，但大参考数据库（比如6TB）远超合理包含在镜像里的阈值，单独下载镜像就要花半天时间。
为了解决这个问题，团队使用了一个共享只读文件系统来存储参考数据库。他们选择使用Lustre文件系统，这是一种常用于超级计算机的分布式文件系统。重要的是，Lustre是POSIX兼容的，许多替代品在用于各种生物信息学工具时会出问题，因为有些工具需要只有POSIX兼容文件系统才提供的操作。
这种模式让他们能在共享只读仓库里存储海量参考数据库。许多HPC沙盒可以同时从文件系统读取，这是Lustre良好支持的通路。随着文件系统变大，吞吐量通过添加更多服务器线性增加。
输入输出文件通过引用（比如S3 URI）或请求中的base64编码字符串与Biomni HPC共享。当Biomni HPC完成作业后，它把输出暂时存在S3桶里，供API和智能体检索。
团队使用AWS ECS管理容器生命周期，容器本身部署在他们管理的EC2实例上。当Biomni提交作业到HPC时，内部API把请求匹配到资源合适的沙盒。有时这意味着基于GPU的实例，其他时候可能是带几百GB内存的大型基于CPU的实例。
如果HPC需求突然增加，请求会被放入队列，同时Biomni HPC配置更多资源。他们按需动态配置更多服务器，不像学术HPC里典型的固定服务器集群。
未来展望：当智能体学会自己租服务器
Biomni使用HPC工具来访问与研究人员相同的计算资源：强大的硬件、专业软件、海量参考数据库。通过使用灵活抽象，让智能体在预配置环境中编写shell命令而非调用刚性API，团队找到了与当前前沿LLM良好配合的平衡点，同时为模型改进留出了成长空间。
随着模型能力不断提升，这种架构会展现出更强的适应性。现在的Opus 4.6或GPT 5.3在获得一定灵活性时能完成更多任务，一年前的模型还在跟灵活性挣扎、需要刚性API。可以预见，未来的智能体将能够自管理更复杂的基础设施，甚至自己决定何时需要租用更多服务器、选择什么配置、如何优化成本。
Biomni团队正在继续开发Biomni及其生态系统以扩展能力。这种将AI智能体与高性能计算深度融合的范式，正在重新定义生物医学研究的可能性边界。从笔记本电脑到超级计算机，从手动配置到智能调度，从刚性流程到灵活交互，这场静悄悄的革命正在让科学研究变得更加高效、更加智能、更加人性化。
最终，技术的价值不在于它有多复杂，而在于它能让研究者多专注于科学本身。当智能体学会了"租服务器"，人类就可以更专注于提出好问题，而不是跟命令行参数搏斗。这或许就是AI时代科学研究该有的样子：人负责思考，机器负责计算，各司其职，各尽其能。