Google Cloud发布了生物技术智能体的参考架构，将规划智能体、需要大量GPU资源的科学计算，以及围绕两者的控制分开。10月16日的设计文章介绍了药物发现团队如何在Google Cloud上协调蛋白质折叠、分子生成和先导化合物审查。它提出一种模式和示例技术栈，没有提供经过测量的客户部署、吞吐量结果或经过验证的候选药物。

对评估科研智能体系统的团队来说，这一区别很重要。语言模型可以分派工作和汇总结果，但蛋白质结构或分子对接轨迹的数据量太大，无法当作普通聊天上下文处理。科学计算也有自己的运行环境、队列和访问控制。Google的提案在这些部分之间划出明确边界，让团队在依赖整合工作流程之前能够逐一检查。

三层架构，各有不同任务

第一层是运行在Agent Runtime上的主编排智能体。Google的示例为其配置两个专业子智能体，一个负责先导化合物优化，另一个进行安全性筛查。主智能体分解请求、分派工作并整合答案。在这项设计提案中，内部智能体之间的交接发生在同一个进程内。Agent Runtime是托管部署环境；Google文档描述了项目设置、Agent Platform SDK for Python、智能体开发和部署等步骤，完成后才能调用智能体。容器化智能体必须满足其运行时契约。

第二层运行成本高昂的科学计算任务。Google的示例将NVIDIA的ESMFold和GenMol推理微服务放在Google Kubernetes Engine上，使用搭载RTX PRO 6000 Blackwell GPU的G4虚拟机。蛋白质折叠和分子生成，是编排智能体会请求执行的工作，而不是由通用语言模型完成的计算。文章建议至少保留一个GKE节点处于活跃状态，并在pod启动时加载模型权重，以减少冷启动延迟。保持预热节点和已加载的权重都会消耗资源；文章没有提供这一选择的延迟、利用率或成本比较。

第三层负责访问治理。Agent Identity为智能体分配SPIFFE身份和托管的X.509证书，可与IAM权限和审计日志配合使用。Agent Gateway可以在支持的入站和出站路径上执行访问规则。Agent Registry则为智能体、MCP服务器、工具和端点建立目录。Google也提出使用Model Armor检查，并对有重大后果的步骤采用人工批准。这些控制需要部署和策略配置；它们出现在架构图上，并不能证明某条数据路径是私有的，也不能证明每项决策都经过审计。

通过存储传递文件，而不是通过提示词

这项设计最容易应用到其他场景的部分，是处理大规模科学数据的方式。提议的流程将PDB文件、对接构象和轨迹日志写入Cloud Storage。智能体交换对象引用和简短摘要，在工具需要时再取回底层数据。这避免了将坐标数组塞进LLM上下文窗口，也为团队提供单独的位置来控制文件访问和保留期限。

Google在这一模式中描述了用于对象的签名URI。签名URL本身就是在其声明范围和有效期内的访问凭证，因此团队仍须为实际工作流程设置过期时间、权限和日志记录。设计文章没有列出生产环境生物技术流水线的完整存储策略、数据驻留配置或威胁模型。声称私有托管的计算容器能将专有结构保留在企业边界内，取决于每一个接收或转发这些结构的组件，包括存储、模型调用、日志和出站端点。

文章还建议将长串模拟链封装在清晰的工具接口后，并在各阶段完成时报告进度。这些设计选择必须结合实际后端队列评估。如果科学服务在内部将请求串行处理，并行发送更多请求也无济于事。文章没有给出基准测试，证明其提议配置具有确定性的吞吐量。

人工决策应该放在哪里

Google的提案让智能体处理可逆的准备工作，例如查找结构或解析化学名称，但要求人员批准高成本或后果重大的动作。例子包括多GPU对接运行、将先导化合物推进到湿实验室合成，以及将研究项目归档。研究机构需要定义这些审批关卡、批准人和各关卡呈现的证据。文章没有报告经过验证的安全性筛查结果，也没有证明模型能在缺少专家审查的情况下作出药理学判断。

治理文档限定了博客中一些宽泛说法的范围。Gateway与Agent Runtime配合时支持入站和出站，但对Gemini Enterprise只支持出站。如果明确的IAM策略以未注册目标的URL为对象，仍然可以访问该目标；因此，注册本身并不是对未知工具的通用封锁。Model Armor检查是团队可以配置的防护措施之一。Agent Identity文档列出的限制包括无法向智能体主体授予旧版Cloud Storage存储桶角色；删除智能体时，还需要手动清理IAM绑定。

在验证方面，Google Cloud另一篇关于智能体插件评估的四条经验的文章提供了有用背景，尽管那个插件是另一套系统。团队发现，只评判智能体最后的答案，会漏掉工具调用日志中可见的动作。它建议保留并发调用结构，比较实际运行与仅规划的运行，并保留由专家整理的基准任务。应用到生物技术提案中，这意味着要检查实际存储写入、模型端点、权限决策、队列行为和人工批准。BIG CHANGE没有构建或测试这套架构。

我们此前介绍的Google Antigravity抗菌肽初步筛选涉及不同的科学智能体任务，不能证明这里提出的基础设施已经构建或验证。

访问、成本和发布状态

团队需要Google Cloud项目、相关API和IAM设置、Agent Runtime部署、GKE GPU容量、存储空间，以及配置完毕的治理组件。可用性和限制取决于所选区域、配额和产品配置。Agent Runtime文档指向区域和配额清单，并表示提供免费层级。Agent Platform定价页面针对运行时计算和内存收费，并说明Gateway出站流量的计费；模型使用、GPU基础设施和Cloud Storage各有额外成本。Google的定价计算器可帮助估算所选配置。持续保持预热状态的GPU资源池也应计入估算。

组件文档描述了可以使用的服务，但这并不会让整合的生物技术模式变成正式可用且经过测量的产品。Registry的独立技能被明确标为Preview，而本文查阅的页面并没有为提议技术栈中的所有组件提供一个统一的发布阶段标签。特定模型容器、网络控制和研究应用之间的兼容性，必须针对预定区域和部署进行检查。本文是依据文档审视10月16日的提案，不是设置指南，也不是对运行中安装实例的报道。

大变化

Google提出了将生物技术智能体工作流程划分为规划、专用科学计算和受治理访问的方法：大型结构通过引用传递，高成本或后果重大的动作则保留人工批准。设计为科研基础设施团队提供了可供评估的具体边界。速度、隔离性、科学可靠性和运营成本，仍有待通过配置后的部署和测量测试回答。

来源与延伸阅读

来源核查于2026年10月18日。BIG CHANGE没有部署提议的生物技术系统，也没有为其进行基准测试。