# Scientific Research Agents — AI 架构

在一家美国生物科技客户团队中担任 Senior AI Engineer,参与构建用于科研自动化的自主 AI 系统。自定义 MCP server、面向科研语料的 RAG 流水线,以及一套 held-out 的评估套件。

- **Author:** Fedor Chishchin
- **Role:** Senior AI Engineer
- **Period:** 2025-03 → 至今
- **Stack:** Python · FastAPI · Claude Opus · MCP · pgvector
- **Source:** https://fedorthinks.com/zh/work/scientific-research-agents

---

## 问题所在

科研工作被一小组可重复但在认知上
代价高昂的工作流所主导:跨付费墙文献的语料检索、从异构 PDF 中做结构化
数据抽取、从既有结果生成假设、对实验设计做批判。这每一项都完全在
现代 LLM 的能力范围之内——但前提是你把周边的架构搭对。

一个朴素的单 prompt 方案会很快崩溃:语料对 context
window 来说太大,合适的工具是领域特定的(懂化学的
文献检索不是 Google),而任何最终会进入研究
笔记的答案都必须是可审计的。

## 我架构了什么

**带分层 planner–executor 拆分的多 agent 编排。** 一个
planner agent 把一个研究请求分解成带类型的子任务;executor
agent 处理实际的工具调用(文献检索、数据抽取、
假设排序)。planner 待在一个紧凑的 context 预算之内;executor
则可以扇出而不污染它。

**自定义 MCP server 作为唯一的工具界面。** 生产中有三种 transport
(本地开发用 Stdio,流式返回结果用 SSE,生产集群用 Streamable HTTP)
——全是我端到端构建的 server。工具是
带版本且可发现的,agent 永远看不到原始 HTTP,而同一套 MCP
契约同时驱动内部 eval 和线上运行。

**一套在开发期间 agent 永远看不到的评估框架。**
用于跨系统对比的公开 agent benchmark,加上一套更大的、取自真实生物学
工作流的自定义场景套件,在开发期间被 held out,这样改进是被
度量出来的,而不是被宣称的。

**Specification-driven development。** 每个 agent 都有一份写下来的 spec——system
prompt、工具清单、guardrail、期望的输出 schema——都签入
repo。reviewer 批准的 artifact 是 spec,而不是 prompt。新
行为通过 spec PR 落地。

## 日常的现实

我不亲手敲实现。我把 coding agent(跑在 Opus 上的
Claude Code)当作实现层来指挥,同时自己掌控架构、spec
纪律和评估纪律。二十年的生产判断
被投入到决定什么该被构建上;agent 实践则给出真正
把它交付出去的速度。Spec 质量是新的瓶颈。

## 成果

一个可工作、经过评估、面向生产的多 agent 系统,它自动化了
此前靠手工完成的研究工作流——并在 held-out 的 benchmark 集上有可度量的
改进,而不只是 demo 级别的截图。

这里记录的架构决策,是我当下正在构建的其他一切的
基础。