最近在梳理某高校 AI 系统方向的一门课程第一讲就抛出了三篇阅读材料其中核心的一篇就是Compound AI Systems。如果你是做 AI 应用落地或者系统设计的那么这几天应该已经感受到风向变了——大家讨论的不再是单一模型有多强而是怎么把模型、工具、数据、推理流程组合成一套能真正干活的系统。这篇博文就是我对这三篇材料的精讲拆解不光说概念还会把材料背后的技术脉络、它们之间的逻辑关系、以及我读完后踩过的一些坑一次讲清楚。先说适合谁看如果你是刚接触大模型应用开发的工程师或者正在研究 Agent、RAG、多模态系统怎么设计的同学这篇文章能帮你把三篇材料的核心论点串起来如果你已经做过一些相关项目那我的阅读笔记和实操建议可能会给你一些新的角度。不建议那种只想要结论的读者看因为这套材料本身就要求你跟着思考我尽量把思考过程也还原出来。1. 为什么 Compound AI Systems 概念值得认真对待第一讲把 Compound AI Systems 放在最前面不是没有道理的。过去两年我们经历了从模型即产品到系统即产品的转变只靠一个巨大的语言模型跑推理很难搞定复杂的现实任务——它要么缺外部知识要么无法调用工具要么在长链条任务中稳定性崩塌。于是大家不约而同地把目光移向由多个组件组成的AI系统让模型作为核心决策器外围挂载检索、计算、工具调用、记忆管理等模块。这个概念从哪来的三篇材料里第一篇就是专门讲这个的。它给出的正式定义很直白一个复合AI系统是多个模块包括模型、检索器、计算器、规划器等等相互作用来解决任务的整体而不是单独的一个模型。这跟传统理解的区别在于它不是下一个token预测的简单循环而是有明确的数据流和控制流甚至像软件架构一样需要设计接口、通信协议、容错机制。为什么这个词突然流行起来我个人的判断是行业被现实教育了。早期大家以为把模型做得足够大什么都能解决后来发现幻觉问题、长尾知识缺失问题、算力成本问题都不是单靠scale能收拾干净的。把问题拆解成子任务针对每个子任务选择合适的组件让模型担任协调者的角色这条路在落地工程中反而更容易收敛。第一篇材料用大量案例论证了这个趋势比如复杂推理任务、代码生成任务、多跳问答任务单模型方案的准确率和可靠性都被复合系统甩开一条街。如果你还没读这篇材料先记住三个关键词模块化、交互、环境反馈。模块化帮助你把大问题切小交互意味着组件之间不是简单的管道而是有往返消息环境反馈则是系统能在运行中动态调整策略。这三件事构成了复合系统的基本骨架。1.1 从单体模型到模块化组合的必然性为什么非要走模块化的路直接用一个全能模型不好吗材料里给出了很实在的理由。首先是可诊断性一个单体模型出错你几乎无从下手去定位到底哪一步偏离了预期但复合系统如果跑挂了你可以检查是检索模块给的材料不对、是规划模块分解步骤有问题、还是执行模块输出格式出错。这个排查链路很有吸引力在大规模生产环境里尤其宝贵。其次是可扩展性想给系统增加一种能力单体模型意味着要重新训练或者微调一整个庞然大物而复合系统只需要新增一个组件、注册好接口数据流和控制流就跟以前一样跑。哪怕你用的模型本身没有太大提升外围模块的增强也会在任务效果上直接体现。第三是资源效率不用所有请求都打给最贵的大模型。简单的子任务交给轻量模型完成只有复杂推理才调用旗舰模型。这听起来像软件工程里的分层架构实际上就是AI版的分层架构单位成本下降非常明显。1.2 复合系统不等于微服务全景但架构范式高度相似做过后端服务的人应该会对复合AI系统的架构图有一种似曾相识的感觉。组件之间通过明确的请求和响应协议通信有一个核心协调者统筹全局外围服务提供各自擅长的能力。材料里虽然没有直接说这是微服务架构但在讨论系统设计时引用了不少软件工程原则比如耦合度、接口隔离、状态管理。这也侧面说明了一件事AI系统设计正在向传统软件工程靠拢。我觉得这对行业是好事。过去两年AI应用项目之所以大量失败一个重要原因就是大家把写提示词当成了全部忽略了对数据流、任务分解、异常处理的设计。复合系统的视角能把工程从业者过去的优势带进来。第一周就让精读这篇明显是想一开始就把这种工程思维扎根到大家的认知里。2. 阅读材料一拆解Compound AI Systems 的核心论点第一篇材料的篇幅不长但信息密度很高。它的主线是论证为什么现在比以往任何时候更需要复合系统以及复合系统有哪些潜在的设计维度。读完一遍之后我的感觉是它更像一篇开题综述不是为了给你一个现成的系统框架而是在帮你建立一套看问题的坐标系。下面按我拆解的要点来梳理。2.1 材料给出的系统架构分层材料里没有画那种标准的架构图但是按功能角色可以分成三类层次感知与输入处理层、推理与决策层、工具与执行层。感知层处理多样化的输入包括文本、图像、数据库记录把它们统一成内部表示推理与决策层负责理解任务、拆解步骤、选择策略语言模型在这一层扮演核心协调者工具与执行层则真的跟外部世界打交道比如跑代码、调API、更新数据库。这个划分我认为很有价值因为它能帮你做能力规划你应该在哪个层次投入资源比如你已经有一个很擅长推理的模型那决策层可以少花心思重点去打磨感知层的数据清洗、以及执行层工具的稳定性和权限控制。反之如果你的模型不太会拆解任务那就要在规划算法上多下功夫。系统设计的出发点不是追求每个组件都最强而是追求整体短板最小化。2.2 设计与评估的四大维度材料里最精华的部分我认为是提出了四个需要重点权衡的设计与评估维度输入多样性系统能接收多少种不同的输入类型每种类型都需要单独的适配器还是可以统一表示。实际项目里文本、表格、图像混着来是常态。任务复杂度任务是单一封闭式的还是需要多步推理并且中途可能引入新的上下文。这决定了你选择什么样的规划策略。系统输出形式最终输出是一个文本答案、一段可运行代码还是直接触发闭环操作。输出形式不同评估标准和容错策略完全不同。执行环境交互系统是否需要在运行中感知环境反馈。比如代码运行报错后能不能自我修正网页结构变了能不能重新爬取这些都是环境交互的范畴。这四个维度基本就是面试里常见的用复合系统解决XX问题的思考模板。你拿到一个项目需求先用这四个维度给它打标很快就能判断系统该设计成什么样子用多大的模型需不需要记忆模块。2.3 与单体模型的对比分析材料用了整节篇幅做对比我总结了一张印象很深的对照视角单体模型像一个全能实习生看起来什么都会一点但你没法把它的工作过程拆开来检查也没法单独替换某个技能复合系统像一支专业团队每个成员各司其职有明确的沟通路径和交接机制团队水平由配合质量决定而配合质量又取决于设计功力。在效果实测上多个研究团队的实验结果都在支撑这个方向同样的基座模型做成复合系统之后在多跳问答、数学推理、代码生成上的提升幅度通常超过10个百分点有些任务甚至能翻倍。更关键的是稳定性上的提升——单体模型一次推理中一个token出错就可能导致全盘崩溃复合系统中单模块的失误可以被其他模块兜住系统的健壮性高得多。我个人在实操中最注意的一个对比点是延迟与成本。复合系统不是免费午餐它把多个组件串起来调用次数增加端到端延迟比单次推理高出不少。材料的立场很坚决准确性优先延迟可以通过并行化、缓存和模型替换来优化。这个权衡你必须自己根据业务场景来定不能照搬。3. 阅读材料二拆解AI Agent 的兴起与自治边界第二篇材料主要讲 AI Agent也就是智能体。它跟第一篇形成紧密互补Compound AI Systems 讲系统的结构和组件Agent 则把重点放在系统内部那个大脑的自主行为上。读的时候我明显感觉这篇材料的写作时间点正处在 Agent 概念高速演进的阶段所以它更多是在概念盘点而非严格定义。3.1 Agent 的核心能力:感知、规划、记忆、行动材料把 Agent 的能力框架拆成四块感知、规划、记忆、行动。感知是获取外部信息规划是把大任务拆解成有序的子任务记忆是保存长期知识和短期交互状态行动则是调用工具、生成回复、与环境交互。这四块跟第一篇文章里的系统模块其实是打通的Agent 其实就是复合系统的一种具体形态重点是这个形态里的决策逻辑更加主动。看到这里你应该明白两篇材料的定位差异了第一篇是从外部观察系统怎么组合组件第二篇是从内部视角看智能体怎么做出选择。前者偏系统架构后者偏智能算法。放到实际项目里你就是既要搭好骨架又得让骨架里的决策器拥有足够好的策略。3.2 自主程度的光谱:从工具调用到全自动决策这篇里我印象最深的一个观点是Agent 不应该是全知全能的全自动机器。材料把自主性描述为一条光谱最左边是单纯的工具调用模型只做指令跟随中间是带规划的工具使用模型能自己决定调什么、按什么顺序调最右边才是完全无人干预的自主规划与执行。为什么说这是一条光谱而非一个类别因为在实际业务中完全自主并不可控。材料举了很多失败案例——Agent 在开放环境中做了意料之外的动作导致不可逆的后果。所以设计 Agent 时你真正应该决定的是自主到哪一层而不是要不要做 Agent。比如一个客服 Agent可以先让它自主收集用户信息、判断意向但发优惠券、改订单这类有风险操作必须回退到人类审批。3.3 经典实验案例的模式归纳:策划、尝试、纠错材料有一个章节专门分析几种知名的 Agent 实验归纳出一个统一模式先由主模型产出初步计划然后给定一个外部环境代码解释器、浏览器、命令行Agent 不断尝试操作、观察结果、对比预期、做出调整。这其实就是第一篇里环境反馈维度的具体化。这个模式的工程含义是你的 Agent 系统必须保留足够的环境信息供模型回看和推理。一个常见错误是让 Agent 多次调用同一工具而不把历史结果注入上下文导致模型无法理解之前发生了什么。实践中我用过的方案是维护一个结构化的轨迹记录每次工具调用后追加输入输出和状态标记并且设置截断策略避免上下文过长。材料里虽然没有给出具体代码但这条思路跟它强调的反馈回路完全一致。3.4 Agent 的评估从难度分级到综合指标Agent 的评估比普通 QA 系统复杂得多。材料给出的做法很务实把任务按难度分级从单步操作到多轮探索再到开放目标对每个级别分别测评成功率和效率同时关注鲁棒性稍微改变环境设置以后再跑测试看系统还能不能稳定完成。这种分级评估思路让 Agent 项目有了可迭代的抓手。我自己做 Agent 评估时还会补充两个容易忽略的指标一是token 消耗密度单位任务消耗了多少上下文二是人类介入频率平均每个任务需要人工插手几次。这两个数字直接决定 Agent 方案的长期运行成本。材料没有明说但对于想上生产的团队憋说了真的是血泪教训。4. 阅读材料三拆解检索增强生成与知识融合第三篇材料自然是谈检索增强生成即RAG。这篇读起来舒服不少因为它有相对具体的流程框架示范、检索、记忆、生成、整合。核心思路是把参数化知识模型预训练中学到的与非参数化知识外部数据库、文档、工具结果结合让生成过程有据可依。4.1 RAG 不是简单的搜到拼进去很多初学 RAG 的人会把它想象成把关键词搜出来的网页拼进提示词里。第三篇材料明确反驳了这个简化认知。RAG 的真正难点在于什么时候需要检索、检索什么内容、检索到多相关的内容才值得插入、插入之后如何防止生成偏离问题。每一个环节都需要单独设计和调优。材料里提出的“示范,检索,记忆,生成,整合”五步法值得逐个讲讲。示范是让模型理解任务的格式和边界检索是寻找外部知识记忆是将检索结果与当前上下文压缩并暂存生成是基于记忆和输入产出回答整合是把多次生成的中间结果进行融合输出最终答案。4.2 检索质量对生成效果的线性影响一个直接来源于实验的结论是生成效果几乎随检索质量线性变化。如果检索到的材料相关性差、噪音大再好的生成模型也救不回来。这跟很多团队的主观感受完全吻合项目做不好先别骂模型看看召回和排序结果到底行不行。提升检索质量的做法材料提到了几种比如改用稠密检索而不是关键词匹配、使用混合检索策略、增加重排模块。但我认为这里最该吸取的经验是检索任务与检索目标的分离你不能直接拿用户输入的原始问题去检索而是要经过一次查询改写把用户口语化的表达转换成适合索引格式的查询语句甚至拆解成多个子查询去检索再合并。这个技巧在复杂的知识库系统里几乎决定了上限。4.3 长文本处理与记忆压缩策略RAG 被广泛讨论的一个场景是长文本问答。材料里对长文本处理给出一个很有启发的原则不追求把所有内容塞进上下文而是让模型只关注对当前问题最相关的片段。记忆模块需要做摘要、裁剪、结构化提取。这里就引出了压缩的问题——如何在不丢失关键信息的前提下缩小传递给生成模型的token数。我读完这篇后立刻对比了自己项目里的上下文管理方案发现之前确实太粗放了。简单地把全文塞进去不仅成本高还干扰注意力。后来我调整成先做篇章级粗筛再做段落级精排最后做摘要压缩的三级流程效果提升非常明显。材料里虽没有写这么细但它强调的记忆压缩概念就是这套做法背后最重要的理论依据。4.4 评估:RAG 系统的多环节指标RAG 的评估不像标准问答那样只有一个准确率。材料的观点是把流程拆开分别评估检索环节和生成环节。检索环节看召回精度、排序质量生成环节看回答的忠实度、完整性、相关性。忠实度尤其关键——生成不能忠实于检索内容的回答效果多好都没用。在实操上我常用一套简单的二元判断法先把模型回答里的每个断言标注出来然后去检索文本里找是否有对应出处。没有出处的断言先标记为可疑最后集中检查到底是模型幻觉还是合理推论。这个办法来自某个离线评测工具的思路很简单但能快速定位 RAG 系统的漏洞出在检索还是生成。5. 三篇材料交叉阅读的核心脉络单独拆完三篇你会觉得它们内容上有重叠又不完全一致。确实它们本来就是经过筛选放到一起的目的不是让你看它们重复强调了什么而是让你理解一个完整 AI 系统的三个切面系统工程面、智能决策面、知识处理面。这三块缺一块系统都转不起来。5.1 一条主线:从静态流水线到动态自治三篇合起来读主线其实非常清楚。第一篇给你静态的系统骨架——组件怎么组合数据怎么流转第二篇帮你理解这个骨架中的大脑如何动态做规划第三篇告诉你大脑做规划时需要的外部知识从何而来以及怎么整合进上下文。可以说第一篇讲形第二篇讲神第三篇讲养分。一个健康的 AI 系统既要有清晰稳健的架构又要有灵活聪明的决策机制更要有源源不断的高质量知识供给。三篇材料虽然各自独立但放在第一讲里就是在教你用整体论的眼光看一切 AI 应用。5.2 共同的技术基础:反馈循环与动态调用不管讲系统、讲 Agent、还是讲 RAG三篇都反复出现同一个概念——反馈循环。复合系统通过环境反馈调整策略Agent 通过观察结果修正行动计划RAG 通过检索结果指导生成内容。你把这根线抽出来再看三篇材料就是对同一个核心原则在不同层次上的展开。动态调用则是另一个共同地基。究竟是预先编排好所有组件的调用顺序还是让系统运行过程中根据当前上下文动态决定下一个调用谁三篇材料都倾向于后者。这也解释了为什么现在大家都在做能力编排、路由选择、模型路由之类的事情。静态流程适合规则明确的场景动态调用适合陌生变化多端的场景而 AI 落地的主要阵地恰恰是后者。5.3 三篇材料对应的实际工程决策清单如果你看完三篇还觉得抽象那我帮你把它们翻译成三个工程决策问题根据第一篇你要设计哪些组件、它们的接口如何定义、数据流如何控制这是系统架构决策。根据第二篇你希望 Agent 自主到什么程度、需要维护哪些记忆、反馈回路怎么闭环这是行为控制决策。根据第三篇知识从哪来、怎么检索、怎么压缩、怎么验证忠实度这是数据与知识策略决策。这三个决策清单就是第一讲阅读材料试图在你大脑里建立的基本框架。放到真实项目里你解决一个问题时下意识就能把问题归类到这三个层面中的某一个并且马上知道该用哪篇材料的思路去找突破口。6. 我的阅读笔记与实操建议作为已经做过一些相关项目的人我想最后聊聊这套材料怎么读才高效以及我在实际应用中的一些体会。6.1 怎么高效读这类学术范材料不要上来就逐字精读。我建议先看梗概再画概念图第三遍才精读关键章节。第一篇材料提的模块化、交互、环境反馈这三个词你先把它们用箭头串起来然后看第二篇把感知、规划、记忆、行动挂在画好的架构图上最后看第三篇把检索、记忆、生成接到已有的知识链路上。这样三篇材料就内化成了你自己的系统框架。还有一个技巧边读边记可操作点。也就是材料里哪些句子你读完能直接想出一个落地方案。比如第一篇的四个维度就是你做项目立项时的风险评估模板第二篇的自主性光谱就是你决定哪些环节上线、哪些环节留人的依据第三篇的忠实度评估就是你布置评测任务时的检查清单。读书读成清单比读成划线笔记有用得多。6.2 我在项目里踩过的坑这里分享两个真实踩过的坑。第一个是过度设计。刚读完第一篇那阵子我遇到什么需求都想搭一个复杂的复合系统结果维护成本爆炸很多模块根本没有必要。后来我总结出一条原则先让单一模型方案跑通再用数据找出它到底在哪类任务上崩针对性强地增加模块。复合系统应该是长出来的不是图纸上画出来的。第二个坑是不重视反馈信号的质量。Agent 和 RAG 都依赖环境反馈但我一开始只给模型返回成功/失败之类的粗粒度消息模型根本不知道失败原因。后来改成结构化的反馈信息带上错误类型、中间产物、日志片段系统自我纠错能力立刻提升了一大截。材聊内容里虽然没有直接给这个细节但它的环境反馈论述完全覆盖了这个方向。6.3 给刚入门者的行动路线如果你刚接触这些概念我建议按这个顺序动手验证先拿一套简单的问答系统直接从第三篇入手做检索生成然后拆开流程把检索当成一个独立组件手动控制是否把检索结果交给生成接着加一层规划让系统自己决定是否要检索、检索什么最后引入工具调用和环境反馈让系统能执行代码并观察结果。这套路线刚好就是三篇材料从后往前串起来的过程RAG 到 Agent 到复合系统。不必非得用到多贵的模型中小参数模型配合良好的检索和记忆也能给你带来很惊人的效果提升。关键在于把每一条反馈回路做扎实把每个组件之间的数据格式定义干净。框架是骨架接口是血脉反馈才是灵魂这大概就是三篇材料浓缩下来的核心道理吧。
