很多团队做 RAG，第一版都长得差不多：文档切块，塞向量库，用户提问，检索几段上下文，交给大模型总结。
Demo 很快能跑。
但一进企业生产环境，尤其是医药、金融、法务这种高风险场景，事情立刻变复杂：数据源分散，结构化和非结构化信息混在一起，用户问题带领域歧义，模型回答必须能追溯，系统失败不能让用户从头再来。
Martin Fowler 网站最近发布的 Bayer PRINCE 案例，真正有价值的地方就在这里。它不是又讲一个“RAG 如何接入 PDF”的教程，而是把一个生产级 Agentic RAG 系统拆开给你看：LangGraph 编排、RAG + Text-to-SQL、过程反思、数据充分性反思、引用验证、状态持久化、重试、模型 fallback、每日线上评测。
这才是很多企业 AI 系统真正缺的东西。
不是更长的 prompt，而是一套能让 Agent 可靠工作的工程骨架。
Bayer 遇到的不是搜索问题，而是知识迷宫问题
PRINCE 面向的是 Bayer 的临床前研究数据。
这类数据有几个典型麻烦：
所以它一开始不是奔着“做一个聊天机器人”去的，而是从 Search 走到 Ask，再走到 Do。
这条演进很值得看。
很多 RAG 项目失败，不是因为向量库不够好，而是团队把“搜索增强问答”误当成了“可靠业务助手”。前者只要能回答，后者必须能解释、能恢复、能评测、能被专家审。
生产级 Agentic RAG，核心不是一个大 Agent
PRINCE 没有把所有事都交给一个万能 Agent。
它把工作拆成多个阶段：
这里的关键不是“用了几个 Agent”，而是每个 Agent 拿到的上下文不同。
PRINCE 的经验很明确：上下文窗口变大，不代表可以把所有东西都塞进去。
早期把太多信息放进上下文，系统反而更难控制、更难评测。后来他们把上下文分层：
这就是现在常说的 context engineering。
不是拼命扩大 prompt，而是让每一步只看到它该看的东西。
两个反思别混用：一个看流程，一个看证据
PRINCE 里最值得抄的设计，是把反思拆成两种。
第一种是过程反思，也就是 Think & Plan。
它问的是：
我现在走的路径对不对？下一步该调用哪个工具？当前轨迹离用户目标近了还是远了？
这对多步骤 Agent 很重要。尤其当工具越来越多，多个工具名字相似、领域重叠时，模型很容易选错工具、查错数据源、线性执行一堆没用步骤。
第二种是数据反思，也就是 Reflection Agent。
它问的是：
我收集到的证据够不够？有没有缺失信息？这些证据能不能支撑最终回答？
这两个问题看起来都叫“反思”，实际上完全不同。
很多 Agent 系统只有“最后让模型自检一下”，这太粗了。
更靠谱的做法，是把不同类型的检查放到不同位置。流程跑偏，要早点纠正；证据不够，要回去补查；答案没写全，才交给写作层修。
可靠性不是口号：状态、重试、fallback 一个都不能少
企业里的 Agentic 系统最怕什么？
不是一次失败，而是失败以后要用户重来。
PRINCE 用 LangGraph 做编排，并把工作流状态持久化到 PostgreSQL。每个逻辑节点执行后，状态会被保存下来。更广义的应用状态、日志、中间步骤和引用信息，则放在 DynamoDB。
这带来一个很实际的好处：某一步失败后，可以从失败节点恢复，而不是整条链路重跑。
这就是 harness engineering。
模型负责生成和推理，harness 负责边界、状态、恢复、观察和控制。
如果没有这些东西，Agent 看起来再聪明，也只是一个长链路脚本。一旦中间任意环节出错，用户体验和成本都会一起崩。
可信回答靠引用，不靠“语气像专家”
PRINCE 所在场景是临床前研究，回答不能只“看起来合理”。
它必须能追溯到原始材料。
系统设计里，Writer Agent 不能凭空发挥，必须基于 Researcher 收集的证据生成回答，并附上准确引用。用户可以看到引用来自哪个文档、哪一页、哪段原文。
这件事在公众号读者自己的系统里也一样重要。
如果你做的是内部知识库、法务问答、客服质检、研发文档助手，最终答案至少要做到：
AI 系统越进入业务核心，越不能靠“说得像真的”过关。
要能查。
评测也分层：别只测最终答案
PRINCE 使用 Langfuse 做生产流量观测和评测数据管理，并结合 RAGAS 做评测。它有两类评测：
更关键的是，它不是只测最终答案。
Agentic 系统应该像测试金字塔一样分层看：
如果只看最后回答好不好，你很难定位问题出在哪。
到底是检索没召回？SQL 查错？反思没发现缺口？还是 Writer 自己发挥过头？这些必须拆开看。
这套经验怎么迁移到普通团队
不是每个团队都在做医药研究系统，也不是每个团队都需要这么重的架构。
但 PRINCE 给出的原则很通用：
如果你的 RAG 系统现在还是“检索几段上下文 + 总结”，可以先从三件事改：
这三步不花哨，但能明显降低瞎答和误答。
最后说句实在的：Agent 进生产，拼的是工程，不是神奇 prompt
Bayer 这个案例最有启发的地方，是它没有把可靠性寄托在“模型更聪明”上。
模型当然重要，但真正让系统能进生产的是外层工程：
上下文怎么流动，工具怎么选，状态怎么存，失败怎么恢复，证据怎么验证，线上怎么监控，专家怎么复核。
这也是很多 Agent 项目从 Demo 到生产会卡住的原因。
Demo 看模型能力，生产看系统纪律。
别再把 RAG 当搜索框了。真正的企业级 Agentic RAG，是一个有边界、有状态、有证据、有评测、有恢复能力的工作流系统。
模型只是其中一部分。
可靠性，得靠工程焊上去。
