很多团队做 RAG，第一版都长得差不多：文档切块，塞向量库，用户提问，检索几段上下文，交给大模型总结。
Demo 很快能跑。
但一进企业生产环境，尤其是医药、金融、法务这种高风险场景，事情立刻变复杂：数据源分散，结构化和非结构化信息混在一起，用户问题带领域歧义，模型回答必须能追溯，系统失败不能让用户从头再来。
Martin Fowler 网站最近发布的 Bayer PRINCE 案例，真正有价值的地方就在这里。它不是又讲一个“RAG 如何接入 PDF”的教程，而是把一个生产级 Agentic RAG 系统拆开给你看：LangGraph 编排、RAG + Text-to-SQL、过程反思、数据充分性反思、引用验证、状态持久化、重试、模型 fallback、每日线上评测。
这才是很多企业 AI 系统真正缺的东西。
不是更长的 prompt，而是一套能让 Agent 可靠工作的工程骨架。
PRINCE 面向的是 Bayer 的临床前研究数据。
这类数据有几个典型麻烦：
| |
|---|
| 研究报告、结构化元数据、历史系统、监管材料分散在不同地方 |
| |
| 结构化元数据可能缺失或错误，最终权威信息常常藏在批准后的 PDF 报告里 |
| |
所以它一开始不是奔着“做一个聊天机器人”去的，而是从 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 做评测。它有两类评测：
| | |
|---|
| | |
| | 监控真实使用中的 faithfulness、relevancy |
更关键的是，它不是只测最终答案。
Agentic 系统应该像测试金字塔一样分层看：
如果只看最后回答好不好，你很难定位问题出在哪。
到底是检索没召回？SQL 查错？反思没发现缺口？还是 Writer 自己发挥过头？这些必须拆开看。
不是每个团队都在做医药研究系统，也不是每个团队都需要这么重的架构。
但 PRINCE 给出的原则很通用：
如果你的 RAG 系统现在还是“检索几段上下文 + 总结”，可以先从三件事改：
这三步不花哨，但能明显降低瞎答和误答。
最后说句实在的：Agent 进生产，拼的是工程，不是神奇 prompt
Bayer 这个案例最有启发的地方，是它没有把可靠性寄托在“模型更聪明”上。
模型当然重要，但真正让系统能进生产的是外层工程：
上下文怎么流动，工具怎么选，状态怎么存，失败怎么恢复，证据怎么验证，线上怎么监控，专家怎么复核。
这也是很多 Agent 项目从 Demo 到生产会卡住的原因。
Demo 看模型能力，生产看系统纪律。
别再把 RAG 当搜索框了。真正的企业级 Agentic RAG，是一个有边界、有状态、有证据、有评测、有恢复能力的工作流系统。
模型只是其中一部分。
可靠性，得靠工程焊上去。
粤ICP备14082021号
免费POC，
零成本试错
