从通用代码 Agent 到生命科学工作流：一次多 Agent 架构草案

2026 年 3 月，我尝试把一个面向软件开发的多 Agent 协作思路改造成生命科学研究工作流，重点回答三个问题：每个角色接收什么、交付什么、由谁验证。

当前阶段为架构原型，核心产出包括角色划分、交付契约、验证门与迁移指南。

为什么不能只把“程序员”改名成“生信分析师”

软件开发工作流通常围绕代码、测试、提交和部署组织。生命科学任务还需要处理：

文献证据与引用；
数据来源、版本和许可；
样本与实验设计；
统计假设与混杂因素；
分析参数和中间结果；
图表、报告与可复现记录。

如果只是替换角色名称，Agent 仍然可能在没有数据字典的情况下分析、在没有引用的情况下写结论，或者把一次运行成功误认为生物学结果可靠。

一组更实用的角色

我把角色压缩为八类职责：

角色	主要职责	典型交付物
Coordinator	拆解任务、管理依赖和状态	任务图、决策记录
Method Reviewer	审查设计、统计与结论边界	风险清单、审核意见
Explorer	定位代码、数据和上下文	文件地图、候选入口
Evidence Librarian	检索文献与官方文档	证据表、可核验引用
Pipeline Builder	实现可重复分析流程	代码、配置、测试
Data Connector	获取外部数据并校验	manifest、校验值、下载日志
Omics Specialist	执行领域分析与解释	结果表、图、方法说明
Provenance Tracker	记录数据血缘和版本	运行记录、产物索引

一个真实系统不一定需要八个独立模型。多个职责可以由同一 Agent 在不同阶段承担，但职责和交付物不能混在一起。

用交付契约连接角色

Agent 之间不应只传递一句“分析完成”。每个任务至少需要声明：

task: differential_expression
inputs:
  expression_matrix: data/processed/counts.tsv
  sample_sheet: config/samples.tsv
constraints:
  organism: human
  design_formula: "~ batch + group"
outputs:
  result_table: results/tables/de.tsv
  qc_report: results/reports/de_qc.html
validation:
  - sample IDs match
  - design matrix is full rank
  - output contains adjusted p values

这样的契约让执行者知道边界，也让审核者拥有可以检查的对象。

一个科研任务如何流转

以 RNA-seq 公共数据分析为例：

Coordinator 定义问题与依赖
→ Evidence Librarian 核对数据集与研究设计
→ Data Connector 下载并生成 manifest
→ Explorer 定位已有流程和配置
→ Pipeline Builder 运行质控、定量与统计
→ Omics Specialist 检查结果与生物学解释
→ Method Reviewer 审查混杂、统计和结论强度
→ Provenance Tracker 固化版本、日志和产物

任何一步发现输入不满足条件，都应该回退到上游，而不是让下游继续生成看似完整的报告。

三个必须存在的验证门

数据门

下载文件是否通过校验；
样本编号和元数据是否一致；
是否含个人或临床敏感信息；
数据版本和获取日期是否记录。

方法门

分组是否存在混杂；
参数是否有依据；
统计设计是否与实验匹配；
是否出现数据泄漏或重复使用测试集。

结论门

每条关键结论是否能回指结果；
结果是否只是探索性发现；
引用是否真正支持对应论述；
是否遗漏负结果、失败样本和限制。

验证门应产生结构化状态，例如 passed、needs_review 或 blocked，而不是让模型自行宣布“任务完成”。

文献工作流也需要分工

文献综述可以拆成：

检索策略设计；
多数据库检索；
去重和筛选；
全文读取；
证据抽取；
引用核验；
结构化写作；
结论强度校准。

检索 Agent 找到一篇文章，并不代表写作 Agent 可以直接引用其中任何观点。中间需要保存 DOI、原文位置、证据类型和支持方向。

权限与秘密管理

多 Agent 系统经常同时连接数据库、文件系统和外部 API，这也扩大了风险面。

我会把安全边界设为：

Agent 只获得任务需要的最小权限；
访问令牌通过环境或凭据管理提供，不写入 Markdown 和配置示例；
下载、发送、删除和发布等动作单独授权；
患者数据与公共数据使用不同的执行环境；
日志保存操作结果，但不保存令牌或原始敏感字段。

因此，笔记进入发布流程前还需要执行凭据与敏感信息扫描。

如何判断多 Agent 是否真的更好

角色更多并不自动带来质量提升。评估时应比较：

完整任务耗时和失败率；
需要人工返工的次数；
引用错误和参数错误数量；
结果能否从 manifest、配置和日志复现；
单 Agent 与多 Agent 在同一任务上的成本差异；
任务中断后能否从结构化状态继续。

如果任务很小、输入清晰，一个 Agent 加一份检查清单往往更简单。只有当任务存在多个专业边界、可以并行或需要独立审核时，角色拆分才真正有价值。

当前状态与下一步

目前已经形成角色划分、提示词草案和迁移指南，下一阶段进入真实任务验证。

下一步应先选择一个边界明确的公开数据任务，固定输入和验收标准，分别用单 Agent 与多 Agent 执行，再比较错误、时间、成本和可复现性。架构图和角色故事只能解释设计，真实任务结果才能证明它是否有效。