当大多数企业在讨论"AI Agent 落地"还停留在 Demo 阶段时，拜耳制药（Bayer AG）已经将一个名为 PRINCE 的生产级 Agentic RAG 系统稳定运行了一年多。2026 年 6 月，Martin Fowler 网站发表了由 Thoughtworks 工程师 Sarang Sanjay Kulkarni 主笔的深度案例研究，首次系统披露了这个平台从 Search → Ask → Do 的完整演进路径——这可能是迄今为止关于"在受监管行业构建可靠 Agentic AI"最详实的一手工程文档。
为什么是制药行业？
临床前药物研发是一个数据密集型场景，同时也是 AI 落地的"硬模式"。拜耳的科研人员需要查询数十年积累的超过 18,000 项非临床研究的数据——这些数据分散在多个彼此隔离的系统中，既有高度结构化的实验数据集，也有大量以扫描 PDF 形式存在的非结构化研究报告。由于历史上多次系统迁移，部分结构化元数据已不完整甚至错误，但"黄金标准"信息始终存在于经过审批的 PDF 研究报告中。
传统的基于关键词和布尔逻辑的搜索工具在面对这些复杂、充满术语变体的科研问题时力不从心。研究人员往往需要耗费大量时间手动翻阅报告、交叉比对数据，才能回答一个看似简单的问题——比如"某化合物在特定剂量下是否出现某种临床观察症状"。
这正是 PRINCE（Preclinical Information Center）的起点。
三阶段演进：从搜索工具到科研助手
PRINCE 的演进路径清晰反映了企业对 AI 能力逐步建立信任的过程：
Search 阶段（2021 年起）：最初，PRINCE 只是一个统一的数据网关，将分散在多个内部系统中的结构化研究元数据整合到一个可搜索的界面中。用户可以通过高级筛选器查找研究，但核心能力仍局限于结构化元数据的匹配。
Ask 阶段（2024 年 3 月）：随着大语言模型和 RAG 技术的成熟，PRINCE 引入了基于自然语言的问答能力。系统不再只是返回匹配的元数据，而是能够直接"阅读"PDF 研究报告的内容，理解科研人员的自然语言问题，并给出基于原文证据的回答。这一阶段的关键突破在于：系统能够进行语义级别的理解——例如，当用户查询"piloerection"（竖毛）时，系统能自动识别报告中"Fur erected"（毛发竖立）等同义表述。
Do 阶段（2024 年 11 月）：PRINCE 进入了当前最成熟的形态——一个由多 Agent 协作驱动的主动型科研助手。系统不仅能回答问题，还能执行复杂的多步骤任务：分解复杂查询、跨多个研究并行检索、综合信息生成结构化回答，甚至辅助起草符合监管要求的 IND（Investigational New Drug）申报文件。
多 Agent 架构：五个角色，三层反思
PRINCE 的核心工作流由 LangGraph 编排，包含五个关键环节：
Clarify（澄清意图）：系统不会盲目地在所有数据源上执行昂贵的检索。当用户查询模糊时——这在毒理学、药理学等跨领域场景中频繁发生——系统会主动提出澄清性问题，锁定具体的领域和数据类型。这既是用户体验的优化，也是上下文工程的第一道决策：在检索开始之前就限定范围，确保下游 Agent 拿到的是聚焦的问题而非开放式的模糊指令。
Think & Plan（思考与规划）：这一步是整个系统最独特的设计之一，灵感来自 Anthropic 的 Think Tool。它提供了一个专门的"思考空间"，让系统在执行任何工具调用之前，先进行流程反思（Process Reflection）——当前路径是否正确？是否在朝着目标前进？工具选择是否恰当？
随着 PRINCE 接入的数据源越来越多，工具数量急剧膨胀，不同工具之间出现了功能重叠和边界模糊。例如，多个工具可能在处理"研究"相关的查询，但分别指向结构化元数据、非结构化报告或汇总数据。Think & Plan 使系统能够显式地推理哪个工具最匹配用户意图，拜耳团队报告称这一步"显著提高了工具选择的准确性"。
Researcher（研究员）：这是系统的信息获取主力，采用双轨策略——RAG 处理非结构化 PDF 报告，Text-to-SQL 查询 Amazon Athena 中的结构化数据。RAG 管线尤为精细：关键词提取、元数据过滤生成、查询扩展（n=5 个语义变体）、加权混合检索（语义搜索权重 0.7，关键词搜索 0.3）、跨编码器重排序（bge-reranker-large，从约 20 个候选块中选出前 7 个），最终由推理模型生成带引用的回答。
随着领域扩展，拜耳正在将 Researcher 从单一 Agent 演进为领域子 Agent 的层级结构——毒理学、药理学等各自拥有定制化的工具集和提示指令，顶层 Researcher 仅作为协调者进行路由。
Reflection（反思）：这是第二层反思——数据反思（Data Reflection）。Reflection Agent 评估已收集的证据是否充分、相关，是否足以回答用户的问题。如果发现信息缺口，它会生成具体的后续问题，交还给 Think & Plan 发起新一轮检索。这解决了多步 Agent 工作流中的一个核心问题：流程正确不代表数据充分，反之亦然。
Writer（撰写）：Writer Agent 负责将检索到的原始证据合成为最终答案。它有几条硬性规则：每一条断言必须基于提供的上下文，并附带精确的引用（链接到源文档、页码和原文摘录）。用户可以在回答中悬停任何句子，看到对应的出处。对于更复杂的输出——如多章节摘要或监管文件草稿——Writer 还支持一个轻量级的内部审查循环，即草稿反思（Draft Reflection）：检查遗漏的章节、不一致的表格或合成缺口。
三层反思循环构成了 PRINCE 质量保障的核心框架：流程反思确保"做对的事"，数据反思确保"证据够用"，草稿反思确保"输出完整"。
上下文工程：不是塞得越多越好
PRINCE 团队在实践中发现了一个关键洞见：更大的上下文窗口并没有消除"选择性"的必要性。在早期迭代中，将过多信息塞入上下文反而让系统更难操控、更难评估。
他们的解决方案是上下文工程（Context Engineering）——不把 prompt 当成一个装所有信息的容器，而是根据阶段精确分发不同类型的上下文：
- Think & Plan 获得规划上下文（当前目标、可用工具、历史轨迹）
- Researcher 获得检索上下文（用户意图、领域约束、工具描述）
- Reflection Agent 获得证据上下文（原始问题 + 已收集数据，而非完整工作流历史）
- Writer Agent 获得合成上下文（精选后的 chunk + 引用约束，而非原始检索输出）
这种"上下文纪律"在多个具体决策中体现：Text-to-SQL 步骤只注入与当前查询相关的 schema 组件，而非完整数据库 schema；Reflection Agent 看不到完整的工作流历史，只看到问题和证据的对比。从单体 Agent 到结构化工作流，每个 Agent 可以独立评估、调试和改进。
工程可靠性：生产环境不是实验室
在受监管的制药行业，"差不多"是不够的。PRINCE 的工程可靠性设计值得任何构建生产级 LLM 应用的团队参考：
多供应商 LLM Fallback：系统通过内部 GenAI 平台接入 OpenAI、Anthropic、Google 以及开源模型，所有模型通过统一的 OpenAI 兼容端点暴露。当某个 LLM 调用失败后，系统自动重试数次，然后切换到备用模型或平台，确保服务连续性。
双层重试机制：重试在 LLM 调用级和逻辑节点级（即工作流中的一个完整步骤）同时实现。这意味着不仅是单个 API 调用的瞬时故障可以恢复，整个步骤的失败也能被捕获并重试——而且 Agent 会收到错误上下文，能够据此调整策略。
状态持久化与断点续跑：Agent 状态通过 LangGraph checkpointer 持久化到 PostgreSQL，应用级状态（日志、中间步骤、引用）存储在 DynamoDB。这意味着即使工作流在第 47 步失败，用户也可以从失败点精确恢复，而非从头开始。用户甚至可以手动触发重试，系统会自动跳过已成功完成的步骤。
可观测性与评估：CloudWatch 追踪系统健康指标，Langfuse 提供全链路生产流量追踪。系统使用 RAGAS 框架进行双轨评估：数据集评估（由领域专家标注的参考回答）在核心工作流、提示或模型变更时触发；线上流量评估每天以批处理方式运行，监控真实世界的 Faithfulness、Answer Relevancy 等指标。
信任构建：透明性即产品特性
在临床前药物研发中，AI 输出的可信度直接影响决策质量。PRINCE 将透明性作为一级产品特性来设计：
中间步骤对用户完全可见——系统展示了每一步执行了什么操作、使用了什么工具、检索了哪些文档。用户可以悬停在回答的任意句子上，查看对应的源文档链接、页码和原文摘录。这种细粒度的引用机制让"验证"从负担变成了直觉操作。
用户反馈数据也印证了这种设计理念的价值：平均易用性评分达到 4/5，75% 的用户报告信息搜索时间显著减少。多 Agent 系统上线后，复杂查询的响应时间平均提升了 30%。但团队也坦承，聊天机器人在"完全满足用户需求"方面仅获得 3.1/5，说明在受监管行业中，AI 助手离"完美"还有相当距离。
制药行业的启示：一个可迁移的蓝图
PRINCE 的经验之所以重要，不仅因为它是制药行业的成功案例，更因为它解决了一类"硬场景"的通用问题：受监管、高精度要求、数据碎片化严重、错误代价高昂。这些特征同样适用于金融合规、法律文书、医疗诊断等场景。
拜耳团队通过 PRINCE 验证了几条可迁移的工程原则：先从 Search 做起，积累用户信任和数据基础，再引入 Ask 和 Do；不要试图用一个超级 Agent 解决所有问题，而是用结构化工作流和角色分工来控制复杂度；上下文不是越多越好，精确分发比大窗口更重要；生产环境的可靠性需要从 LLM fallback、双层重试到状态持久化的系统工程来保障，而非依赖单个模型的鲁棒性。
用 Kulkarni 在文中的话说，PRINCE 的工程实践可以归结为两个关键词：上下文工程（Context Engineering）——决定每个模型看到什么、不看到什么，以及上下文如何在专业化步骤之间流动；约束工程（Harness Engineering）——在模型周围构建编排、工具边界、状态持久化、重试、fallback、验证、反思循环、可观测性和人工审查的脚手架。这套方法论正在被提炼为可在其他行业复用的模式。
PRINCE 的故事还在继续。团队正在将 Researcher 能力演进为领域子 Agent 层级结构，同时通过 NER 技术从 PDF 报告中自动提取和修正元数据，以持续提升数据质量。在一个 FDA 开始接受 AI 辅助审评、监管框架仍在演变的时代，拜耳用 PRINCE 证明了一点：在受监管行业中构建可靠的 Agentic AI，不仅是可能的，而且已经有了可复现的工程方法论。
