Scientific Research Agents — AI 架构

问题所在

科研工作被一小组可重复但在认知上 代价高昂的工作流所主导:跨付费墙文献的语料检索、从异构 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 级别的截图。

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