原文：Building Reliable Agentic AI Systems
作者：Sarang Sanjay Kulkarni（Thoughtworks 首席顾问）
发表于 martinfowler.com，2026 年 6 月 16 日
一句话核心摘要
Bayer 与 Thoughtworks 联合打造的 PRINCE（Preclinical Information Center）平台，用 Agentic RAG + Text-to-SQL 将数十年的临床前安全研究报告变成了可对话、可推理的智能研究助手。全文的核心洞见是：构建生产级 AI 系统，可靠性不来自更好的模型或更聪明的 prompt，而来自两个工程范式------上下文工程（Context Engineering）和脚手架工程（Harness Engineering）。上下文工程决定每个模型"看到什么"，脚手架工程决定模型"在什么约束下行动"。
1. 背景：临床前药物研发的数据困境
临床前药物研发是一个数据极度密集的领域。Bayer 面临的挑战非常典型：
- 数据孤岛：信息散落在数十个互不相通的系统和仓库中。
- 搜索能力薄弱：传统基于关键词和布尔逻辑的搜索引擎，面对复杂的科学术语和长尾问题束手无策。
- 人工分析耗时巨大：研究人员被迫花费大量时间手动翻阅 PDF 报告，而非专注于核心科研工作。
更具讽刺意味的是：由于历史系统迁移，结构化元数据经常不完整甚至错误，而真正权威的"金标准"信息却一直静静地躺在那些经过审批的 PDF 报告里------只是从未被有效利用。
PRINCE 的诞生，正是为了打破这个僵局。
2. PRINCE 的三阶段演进：Search → Ask → Do
PRINCE 的进化不是一步到位的，而是经历了三个清晰的阶段：
| 阶段 | 能力 | 核心变化 |
|---|---|---|
| Search | 统一搜索门户 | 整合多个数据孤岛，基于结构化元数据提供可检索的统一入口 |
| Ask | AI 问答系统 | 引入 RAG，让研究人员用自然语言提问，从非结构化 PDF 中直接获取答案 |
| Do | 主动研究助手 | 引入多智能体系统，能编排复杂工作流，甚至辅助起草监管文件 |
这个演进路径反映了一个重要的产品哲学：不要等完美再交付，先交付价值，再根据真实反馈迭代。PRINCE 从 2024 年初就面向终端用户开放，Agentic 能力在当年晚些时候才引入------真实用户的反馈一直是驱动改进的核心动力。
3. 系统架构全景
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1emKO3EB-1782131567705)(https://martinfowler.com/articles/reliable-llm-bayer/system-container-view.png)
图 1：系统上下文与支撑平台（来源：原文 Figure 1）
PRINCE 的技术栈可以概括为以下几个方面：
前端
- React 构建的对话式 UI
编排层
- LangGraph 负责多智能体工作流编排
- FastAPI 作为服务框架
数据层
- Amazon OpenSearch：存储研究报告的向量表示
- Amazon Athena：存储经过 ETL 和标准化处理的结构化数据
- PostgreSQL：LangGraph 的检查点存储，持久化 Agent 执行状态
- DynamoDB：应用级状态管理
模型层
- 内部 GenAI 平台，统一托管 OpenAI、Anthropic、Google 及开源模型
- 所有模型通过统一的 OpenAI 兼容接口暴露
可观测性
- CloudWatch：系统健康监控
- Langfuse：生产流量追踪、评估数据集存储
- RAGAS：评估框架
有一条设计原则贯穿始终：上下文纪律（Context Discipline）。团队明确指出------"更大的上下文窗口并没有消除对每个 Agent 看到什么内容进行精挑细选的必要性"。不同阶段注入不同上下文：
- Think & Plan → 规划上下文
- Researcher Agent → 检索上下文
- Reflection Agent → 证据上下文
- Writer Agent → 合成上下文
这样做的好处是：减少上下文污染、便于独立调试、方便独立评估、也方便独立改进。
4. 核心工作流：五步协同
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sfZ60mfg-1782131567706)(https://martinfowler.com/articles/reliable-llm-bayer/new-research-workflow.png)
图 2：研究工作流（来源：原文 Figure 2）。从用户请求出发，经过 Clarify、Think & Plan、Researcher（含 RAG 和 Text-to-SQL 两条路径）、Reflection 的数据验证循环，再到 Writer 的最终响应生成，各步骤之间包含反馈回路和暂停点。
PRINCE 的工作流由五个关键步骤组成，每一步都有明确的职责边界。
4.1 Clarify User Intent（澄清用户意图）
第一道防线，防止模糊查询浪费执行资源。
随着系统扩展到毒理学、药理学等多个领域，用户的简短查询很容易产生歧义。与其让 Agent 猜错方向后重来，不如在第一步就主动向用户提问澄清。
这一步还提供了 AI 辅助的数据源推荐：当用户没有选择数据源或选择了过多数据源时，模型会分析意图并推荐最相关的来源，用户可以接受、调整或推翻。
从上下文工程的角度看，这一步在检索开始之前就约束了工具、领域和数据源的范围，让后续 Agent 拿到的是一个聚焦的问题。
4.2 Think & Plan（思考与规划）
给系统一个专门的空间来"想清楚再动手"。
这一步的灵感来自 Anthropic 的 Think 工具，执行的是一种流程反思（Process Reflection）------不是反思数据够不够，而是反思"我们走的路对吗？方向对吗？"。
当工具数量大幅增长后，不同工具之间的功能边界变得模糊，LLM 有时会选错工具。专门的思考步骤让模型能够显式地推理"哪个工具最匹配用户的意图"，显著提升了工具选择准确率。
在需要多步串联的场景中，这一步更是不可或缺------没有流程反思，Agent 就会机械地线性执行，而不是在每个节点上评估进展。
4.3 Researcher Agent（研究员）
系统的信息搜集引擎，采用 RAG + Text-to-SQL 双通道策略。
Researcher Agent 是全文最重头的技术部分。随着 PRINCE 扩展到多个临床前领域，单一 Researcher 加扁平工具列表的方式越来越难以维护。团队正在将其演进为层级化的领域子 Agent 架构：
- 顶层 Researcher Agent 作为协调者，根据用户意图和领域选择路由到对应的子 Agent
- 每个领域子 Agent 拥有自己的工具集和适配该领域数据模型的 prompt 指令
- 对用户来说，仍然是"一个研究员"的简洁体验
RAG 通道（处理非结构化数据）
离线索引阶段：
数十年的 PDF 研究报告（含扫描件，表格复杂）→ S3 数据湖 → 提取管道 → 文本标准化为结构化 JSON → 按科学上下文分块 → 从 Athena 注入研究级和章节级元数据 → 嵌入 → 存入 OpenSearch 向量库。
在线查询阶段（以"研究 T123456-2 中是否观察到竖毛、共济失调、眼睛半闭、稀便？"为例）：
- 关键词提取：LLM 提取核心关键词（piloerection, ataxia 等）
- 元数据过滤生成 ：LLM 同时生成过滤条件（如
eq(study_id, T123456-2)），使用 few-shot prompting - 查询扩展：用一个小型快速模型生成 5 个语义相近的变体查询
- 混合检索：对 5 个扩展查询各执行一次混合搜索（语义搜索权重 0.7 + 关键词搜索权重 0.3），5 路并行，聚合去重后约 20 个 chunk
- 重排序：用 bge-reranker-large 交叉编码器精排，取前 7 个最相关 chunk
- 最终生成：7 个 chunk + 原始问题 → reasoning 模型生成带引用的回答
- 全链路监控：Langfuse 持续追踪
Text-to-SQL 通道（处理结构化数据）
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jciGJk7W-1782131567707)(https://martinfowler.com/articles/reliable-llm-bayer/text-to-sql.png)
图 3：Text-to-SQL 工具流程（来源：原文 Figure 3）。展示自然语言查询如何经过意图分析、Schema 理解、动态 Few-Shot Prompting、SQL 生成与验证、查询执行与错误处理，最终转换为可执行的 SQL 并返回结构化数据。
对于需要精确过滤、聚合或对比的查询，走 Text-to-SQL：
- 分析查询意图，识别数据点和过滤条件
- 动态注入相关 schema（只注入必要的部分，不塞全量 schema）
- 从向量库中检索相似查询示例，做动态 few-shot
- 强代码模型生成 SQL，强制只允许 SELECT
- 在 Athena 上执行，限制 50 条
- 失败则把错误信息喂回同一模型重试，最多 3 次
- 团队曾尝试加一层 LLM 审查，但审查 LLM 有时会错误地否定有效 SQL，所以去掉了
4.4 Reflection Agent（数据反思）
评估检索到的数据是否足够、是否相关。
这里区分两种反思：
| 类型 | 执行者 | 关注点 |
|---|---|---|
| 流程反思 | Think & Plan | 步骤对吗？方向对吗？工具选对了吗？ |
| 数据反思 | Reflection Agent | 数据够吗？和问题相关吗？缺什么？ |
一个 Agent 可能走了完美的流程却拿到了不足的数据，也可能拿到了足够的数据却卡在执行流程上。两者缺一不可。
Reflection Agent 的职责是：对比检索到的上下文和原始问题，识别缺口，生成具体的追问，交还给 Think & Plan 做进一步检索。如果数据充分，就放行到 Writer。
4.5 Writer Agent（撰写）
把收集到的证据变成最终答案，任务是合成而非发现。
Writer Agent 的核心约束：
- 每一条论断都必须有上下文支撑
- 必须附带精确引用（在受监管环境中，可验证性是底线）
- 遵循用户层面的格式要求和领域特定的回答标准
对于复杂回答，Writer 支持一个内部审阅循环 ：草稿 → 审阅检查缺失 → 定向修订指令 → 修订。这是第三种反思------草稿反思（Draft Reflection），关注输出完整性和呈现质量。
三种反思形成闭环：
- 流程反思 → 检查工作流轨迹和工具选择
- 数据反思 → 检查证据充分性
- 草稿反思 → 检查输出完整性
5. 信任机制：透明、可验证、持续评估
在临床前药物研发这种受监管领域，用户信任是 AI 系统能否被采用的关键。
透明性
- 查询处理的中间步骤、检索过程、反思过程全部展示给用户
- 用户能看到系统"在想什么"，而不只是最终答案
引用可验证
- 每句话都可以悬停查看对应引用
- 引用包含源文档链接、页码和原文摘录
- 这种句子级引用极大降低了人工审查的成本
双轨评估
| 评估类型 | 频率 | 方式 |
|---|---|---|
| 数据集评估 | 核心工作流/prompt/模型变更时 | 领域专家标注的参考数据集，评估 Faithfulness、Answer Relevancy、Context Relevancy、Answer Accuracy、语义相似度 |
| 生产流量评估 | 每天 | 对真实用户查询做批量评估，不依赖参考答案，监控幻觉和性能漂移 |
持续监控
Langfuse 持续监控，识别潜在偏差、错误和改进空间。
6. 工程可靠性：失败不是会不会发生，而是何时发生
多步工作流中，失败是必然的。PRINCE 的应对策略：
- 状态持久化：整个工作流图的状态持久存储（PostgreSQL + DynamoDB），支持从失败节点精确恢复，而不是从头开始
- 内置重试：每个步骤都有自动重试机制
- 用户手动重试：用户可以重试失败的查询，系统利用持久化状态跳过已完成的步骤，省时省钱
- LLM 降级：主模型失败后自动切换到另一供应商的备选模型
- LangGraph 框架支持：原生提供工作流状态管理和错误处理
这就是脚手架工程的具体体现：LangGraph 工作流就是 Agent 周围的控制层，定义谁能做什么、用什么工具、在哪里暂停、如何重试、状态如何持久化、何时进入下一阶段。
7. 数据质量：NER 自动补全元数据
结构化元数据的质量直接影响 Text-to-SQL 的效果。由于历史迁移和标注差异，Athena 中的元数据可能不完整或错误。
团队开发了一个基于 命名实体识别（NER） 的辅助系统：
- 从 PDF 中提取研究 ID、化合物名称、物种、给药途径、剂量、临床发现等实体
- 生成结构化标注
- 高置信度字段自动更新 Athena；低置信度字段隔离后标记给人工审核
这形成了一个持续改善数据质量的飞轮。
8. 核心洞察：上下文工程 × 脚手架工程
这是全文最重要的方法论贡献。作者回顾整个过程，提炼出两个概念：
上下文工程（Context Engineering）
决定每个模型接收什么信息，屏蔽什么信息，以及信息如何在专门化的步骤之间流转。
PRINCE 中的体现：
- 不同 Agent 看到不同的上下文切片
- Text-to-SQL 只注入相关 schema，不塞全量
- Reflection Agent 拿到原始问题 + 收集到的证据
- Writer Agent 拿到精选 chunk + 引用约束
- Clarify 步骤在检索前就收窄了上下文范围
效果：从单体 Agent 到结构化工作流，每个 Agent 都可以独立评估、调试和改进。
脚手架工程（Harness Engineering）
决定模型周围的支撑结构：编排、工具边界、状态持久化、重试、降级、验证、反思循环、可观测性、人工审核。
PRINCE 中的体现：
- LangGraph 工作流作为控制层
- 多级重试和 LLM 降级
- 状态持久化支持精确恢复
- 三种反思循环（流程、数据、草稿）
- 句子级引用和人工审核节点
两者的关系
作者指出，随着模型能力提升，脚手架中的某些部分可能变薄或内化为模型的原生能力。但在企业级研究系统中，只要信任、可追溯性和可审查性仍然重要，对上下文、工作流状态、恢复、反思和验证的显式控制就不可或缺。
9. 总结：构建可靠 Agentic AI 的关键原则
从 PRINCE 的实践中可以提炼出几条通用原则：
- 上下文纪律比上下文大小更重要------更大的窗口不等于更好的检索，精挑细选上下文才是正道
- 分离关注点，让每个 Agent 只做一件事------Clarify → Think → Research → Reflect → Write，每个步骤可独立评估和改进
- 反思不是锦上添花，是必需品------流程反思、数据反思、草稿反思三个层次缺一不可
- 先保证效果，再优化成本------过早优化成本会损害效果和用户采纳，等效果和性能达标后再做成本优化
- 信任来自透明和可验证------句子级引用、中间步骤可见、持续评估监控，比任何"信任AI"的口号都有说服力
- 失败是必然的，设计时要假设一切都会坏------重试、降级、状态持久化、精确恢复，这些不是附加功能，而是系统的基础能力
- 可靠性来自工程，不来自模型------更好的模型能提升上限，但工程化的上下文和脚手架决定了下限
本文是对 Martin Fowler 博客上 Bayer PRINCE 案例的深度梳理，旨在提炼其中的工程方法论和架构思想。