第五章架构与编排

LLM 应用并非没有架构可言。当复杂度超过一定阈值，就必须做结构设计。问题在于：哪些架构模式是这个领域真正需要的，哪些是从传统软件工程中生搬硬套的；当这些结构需要动态执行时，编排该放在哪一层，由谁来控制。

前一章讨论的是单次 LLM 调用层面的约束。本章视角放到系统层面：当一个应用包含多个 LLM 调用、外部工具、数据存储和业务逻辑时，如何组织它们之间的关系（架构），以及如何让这些组件按照正确的逻辑运行起来（编排）。

文章

RAG 的本质 -- RAG 被过度包装了。剥开框架的外衣，核心操作不过是"在调用 LLM 之前，把相关信息塞进上下文"。理解这个本质，才能判断何时需要 RAG、何时不需要，以及检索质量为什么是系统的真正瓶颈。
Agent 的结构分解 -- Agent 不是一个神秘的概念。它是"LLM + 工具调用 + 循环控制"的组合。本文拆解 Agent 的最小结构，讨论工具绑定原则、终止条件设计和状态机形式化。
胶水层与核心引擎 -- 两种根本不同的架构定位。前者意味着 LLM 负责连接和转换，核心逻辑仍由确定性代码承载；后者意味着 LLM 本身就是业务逻辑。定位决定了测试策略和可靠性模型。
隐式编排与显式编排 -- 两种根本不同的编排范式。隐式编排靠数据结构驱动推理流程，显式编排靠代码定义执行图。隐式编排被严重低估了。以及为什么大多数场景下，Python 本身就是最好的编排语言。
错误传播与补偿机制 -- LLM 调用的四种失败方式（硬失败、格式失败、语义偏离、幻觉），多步工作流中错误传播的级联效应，以及验证点和补偿策略的设计。
编排框架的过度设计 -- 一篇观点文章。抽象层级膨胀、概念过载和不必要的间接性。框架的正当使用场景，以及"无框架编排"的替代方案。

前三篇是架构的静态维度：RAG（数据从哪来）、Agent（怎么和外部世界交互）、胶水层 vs 核心引擎（LLM 在系统中扮演什么角色）。后三篇是执行的动态维度：编排范式、错误传播、以及对编排框架过度设计的批判。