拜耳制药和 Thoughtworks 在 Martin Fowler 的博客上发表了一篇完整案例，讲他们花了两年多时间把 PRINCE（Preclinical Information Center）从关键词搜索工具演变成多智能体 RAG 系统，帮药物研究员从几十年积累的临床前安全报告里提取信息。这不是 demo，是在制药监管环境下跑了一年多的生产系统。文章提出的两个工程概念特别值得拆开讲：上下文工程（context engineering）和 harness 工程（harness engineering）。
从搜索到助手的三阶段
PRINCE 经历了三个阶段。Search 阶段把分散在多个内部系统的结构化研究元数据整合到一个搜索入口。Ask 阶段引入 RAG，让用户用自然语言直接问 PDF 报告里的内容。Do 阶段引入多智能体编排，系统可以执行复杂任务，比如起草监管文件初稿。
这个演进路径很有参考价值。很多团队一上来就想做 Agentic AI，跳过了数据整合和检索质量打磨。拜耳的做法说明：没有前两阶段积累的数据治理和检索能力，智能体阶段根本跑不起来。
上下文工程：给每个智能体喂对的信息
文章对上下文工程的定义非常精确：研究每个模型在每一步收到什么信息、不收到什么信息、以及信息如何在专用步骤之间流动。PRINCE 的 Agentic RAG 系统由四个环节组成，每个环节拿到的上下文完全不同。
第一个环节 Clarify User Intent（澄清用户意图）。当用户问题模糊时，系统不会盲目地在所有数据源里试一遍，而是主动追问，让用户明确到底问的是毒理学还是药理学。这是一个 fail-fast 机制：在检索开始前就缩小工具和域的范围。系统还会做 AI 辅助的来源推荐，分析用户意图后建议最相关的数据源，用户可以接受、调整或覆盖。
第二个环节 Think & Plan（思考与规划）。受到 Anthropic 的 Think tool 启发，给系统一个专门的思考空间。文章特别区分了 process reflection（过程反思）和 data reflection（数据反思）：Think & Plan 做的是过程反思，评估“我走的路对不对”“有没有朝着目标前进”，而不是评估数据本身。当一个复杂任务需要 50 个步骤时，每一步都要问：方向对不对、进度够不够、轨迹对不对。工具变多后这个思考步价值更大，因为工具边界会模糊，LLM 容易选错工具。
第三个环节 Researcher Agent（研究员智能体）。用混合检索策略处理两类数据：RAG 处理 PDF 等非结构化报告，Text-to-SQL 处理 Amazon Athena 里的结构化实验数据。随着域增多，单个 Researcher 拿着扁平工具列表越来越难管理，团队正在把它演进成域级子智能体层级结构：每个域智能体拥有自己的工具集和定制 prompt，编码了该域的数据模型和权威来源。
第四个环节 Reflection Agent（反思智能体）和 Writer Agent（写作智能体）。Reflection Agent 做数据反思：把检索到的上下文和用户原始问题对比，判断证据是否充分。不充分时生成具体追问，交给 Think & Plan 触发新一轮检索。Writer Agent 不负责发现新信息，只负责综合已有证据，确保每个论断都有引用回链到具体 chunk 和研究 ID。
三层反思循环：最值得借鉴的设计
PRINCE 有三个互补的反思循环，分别在不同层面做质量检查。过程反思在 Think & Plan 阶段运行，检查工作流路径，能抓住错误轨迹、工具选择失误、步骤顺序不当。数据反思在 Reflection Agent 阶段运行，检查证据是否充分，能抓住证据薄弱、上下文缺失、覆盖面有漏洞。草稿反思在 Writer Agent 内部运行，检查输出是否完整，能抓住缺失章节、表格不完整、综合信息有缺口。
这三个循环不是简单地把更多信息塞进 prompt，而是把正确的上下文路由给正确的能力。Text-to-SQL 步骤只注入当前查询相关的 schema 组件，而不是整个数据库 schema。Reflection Agent 收到的是原始问题加收集到的证据，不是完整工作流历史。Writer Agent 收到的是带引用约束的精选 chunk，不是原始检索输出。从单体智能体转向这种结构化工作流后，每个智能体可以独立评估、调试和改进。
harness 工程：给模型搭脚手架
harness 工程研究的是围绕模型搭建的脚手架：编排、工具边界、状态持久化、重试、降级、验证、反思循环、可观测性和人工审核。
状态持久化是关键基础。整个工作流图的状态存在 Postgres 里，代表智能体进度。应用状态如日志、中间步骤和引用存在 DynamoDB 里。某个节点失败时，系统从失败点恢复，不需要重启整个工作流。内置重试在步骤级别配置，用户也可以手动重试失败的查询，系统利用持久化状态从失败点继续，跳过已成功的步骤。
透明度设计也很有诚意。中间步骤包括 formulated 的查询和使用的工具都展示给用户。检索到相关 chunk 时页面显示源材料链接。生成的答案每句话都可以 hover 看到对应的引用，包含到源文档的链接、页码和原文引用。
双评估体系
PRINCE 用两套评估体系。数据集评估在每次对核心工作流、prompt 或底层模型做重大变更时运行，由领域专家准备带参考答案的测试数据集，存在 Langfuse 里。指标包括 Faithfulness（答案被上下文支持的程度）、Answer Relevancy（答案与问题的匹配度）、Context Relevancy（检索 chunk 的相关性）、Answer Accuracy（与标准答案对比）和 Semantic Similarity with Reference（语义相似度）。
线上流量评估每天批量跑，对真实用户查询做评估。虽然没有参考答案，但 Faithfulness 和 Answer Relevancy 仍然可以测量，对发现生产环境中的幻觉非常关键。
写给做生产级 AI 的团队
文章总结很到位：生产级 agentic AI 不仅仅是更好的模型或更好的 prompt。可靠性来自同时工程化模型看到的上下文和模型在其中运作的 harness。上下文工程确保每个模型在正确的工作流阶段拥有正确且仅正确的信息。harness 工程确保工作流保持有界、可观测、可恢复，并适合受监管的研究环境。
这和工程师 Vini Brasil 在博客上的观点形成互补。他说自己越来越多地拒绝 AI 生成的代码，即使能跑通 CI。他拒绝 AI 代码的五条标准是：无法用自己的话解释方案、diff 比问题本身还大、在证明需要之前就引入抽象、本地能跑但让系统更难推理、对输出的信任超过对自己的理解。代码能跑和代码是好方案是两件事。PRINCE 的三层反思循环本质上就是在系统层面解决这个问题，让每一步都可以被审计和验证。
如果你在做 Agentic RAG 或多智能体系统，PRINCE 这个案例值得完整读一遍。三层反思循环设计、上下文路由策略、状态持久化方案和双评估体系，都是可以直接借鉴的工程模式。
#上下文工程# #AgenticAI# #RAG可靠性#
引用来源：
- Building Reliable Agentic AI Systems - Martin Fowler / Bayer PRINCE 原文：https://martinfowler.com/articles/reliable-llm-bayer.html
- HN 讨论帖（46 分）：https://news.ycombinator.com/item?id=48615680
- Anthropic Think tool 研究（PRINCE Think & Plan 灵感来源）：https://www.anthropic.com/research/visible-extensions
- LangGraph（PRINCE 工作流编排框架）：https://github.com/langchain-ai/langgraph
- Langfuse（PRINCE 评估监控平台）：https://langfuse.com
- When I reject AI code even if it works - Vini Brasil：https://vinibrasil.com/when-i-reject-ai-code-even-if-it-works/
小艺
