开学第一周不管是研究生新生还是准备转做 AI 工程的老人最焦虑的事往往不是模型不会跑而是读不完的 reading。尤其是一门编号 CS329Z 的课程第一讲就把三篇材料摆到你面前领头的还是那篇《Compound AI Systems》。刚开始读很多人会误以为它是一篇纯科普或者觉得“复合式 AI 系统”不就是把几个模型串在一起吗有什么可讲的。等你真的把这套材料读完再回头看自己手头那些 demo 和项目才会意识到过去我们一直默认的“一个模型解决一件事”的思维方式恰恰是现在系统工程里最大的瓶颈。这篇文章我想站在一个真正按这套材料做过事、踩过坑的从业者角度把第一讲的阅读材料彻底拆开讲透。除了逐段精讲《Compound AI Systems》的核心框架另外两篇材料也会一起梳理。文章里不只是复述观点还会说明这套阅读材料在课程里的位置、每篇论文各自的“为什么”、它们互相之间的逻辑关系以及你应该用怎样的顺序和笔记方法来消化它们。哪怕你并没有选修这门课只要你正在做多模型编排、Agent 流程设计或者 RAG 这类工程这套阅读材料也值得按文中的方法精读一遍。1. 材料布局为什么第一讲偏偏是这三篇1.1 第一讲不是教你跑模型而是重建你脑子里对“系统”的定义很多第一次接触 CS329Z 的人预期是上来先讲分布式训练、推理优化、GPU 利用率这类底层话题。但第一讲没有这么做它让你先读三篇关于 AI 系统的“元层面”材料。这个安排本身就是一种表态这门课关心的不是单个模型又快又准而是当多个模型、多个工具、多段逻辑组成一个完整系统的时候系统层面怎么设计、怎么评估、怎么迭代。这三篇材料的分工很明显第一篇是定调子的综述明确给出“Compound AI Systems”这个核心概念第二篇聚焦智能体系统的工程评估告诉你一个复杂系统怎么才算好用第三篇偏向开发方法和管线抽象解决的是“这种系统用什么思路去搭”的问题。三篇加在一起正好覆盖了“是什么、怎么评、怎么做”三段闭环。你如果只读第一篇就停下那就只学到了一个名词把三篇连起来读才算建立起一个完整的设计坐标系。在我自己带项目的经验里这个闭环极其重要。很多团队在 2024 年下半年开始做多 Agent 协作系统大家说起“编排”“工作流”头头是道但一落到评估就傻眼不知道拿什么指标说自己的系统比单模型好。另一些团队相反评估指标想了一大堆但系统架构完全是临时拼凑的改一个环节就要重写半边代码。CS329Z 第一讲把三篇材料放在一起本质上就是在强迫你同时思考这三个问题你的复合系统边界在哪里、它的质量怎么度量、它的构建过程有没有可复用的模式。1.2 三篇材料的互补关系一篇定概念一篇给评估一篇给构建方法如果把这三篇材料比作装修房子《Compound AI Systems》是设计图纸告诉你一套 AI 系统应该由哪些空间组成、水电怎么走第二篇材料是验收标准告诉你每一间屋子住起来什么感受才算达标第三篇材料则是施工工艺手册教你砌墙、布线、刷漆的具体工序。三者缺一不可而且阅读顺序最好不要打乱。我见过不少同学上手先翻第三篇因为里面有代码、有工具、看起来实操性最强。结果读到一半就频繁卡壳因为材料里反复出现“模块化”“路由”“工作流状态”这些概念而这些概念的定义恰恰是从第一篇来的。这就像还没看设计图纸就开始抹水泥不是不能干但每一铲子都得猜效率极低。我自己试过各种顺序最省力的永远是先花一小时把第一篇的结构骨架划出来再读第二篇建立度量思维最后才去啃第三篇的工程细节。还有一个值得注意的点这三篇材料的作者群背后其实是同一个学术社区也就是说它们彼此引用、互为背景。你会在第一篇里看到的某些评估指标在第二篇里会被展开成实验方法论你在第三篇里看到的编排抽象又在第一篇的分类框架中有对应位置。读的时候如果能把三份材料的交叉引用关系标出来你对这一整个领域的地图感会强很多后续再读新的论文就不容易迷路。1.3 为什么选这些新材料而不是经典老论文CS329Z 这类前沿课程选 reading 有一个默认原则优先选那些能定义当下问题域的新材料而不是已经进教科书的经典模型论文。比如你肯定不会在第一讲里去读 Transformer 原文因为那是底层的必要知识但不是现在的争论焦点。现在争论焦点是当 AI 能力逐渐商品化怎么把这些能力组织成真正可用的产品。这才是系统课该回答的问题。三篇材料的“新鲜感”也是故意设计的。读新论文你会感觉作者和自己一样站在泥地里很多结论还没固化很多坑还没填平。这种未完成感其实是很好的学习状态——它让你意识到这个领域没有标准答案逼着你从第一性原理去判断作者说得对不对。相比之下读十年前的老论文你往往只能接受它“对”很难产生批判性的距离感。第一讲选这些材料恰恰是要在第一周就把你的阅读姿态调成“对话模式”而不是“膜拜模式”。2. 第一篇精讲Compound AI Systems 到底在说什么2.1 它解决的核心问题模型强了为什么系统还是不行《Compound AI Systems》这篇文章最有价值的地方是它明确提出一个悖论过去几十年 AI 研究的默认单位是“模型”自然语言处理靠一个模型计算机视觉靠一个模型语音识别靠一个模型。但到了大语言模型时代真正稳定上线、真正让用户觉得“好用”的 AI 应用几乎没有一个是单模型独立完成的。大家在做的是检索增强生成是多模型投票是工具调用加记忆管理是各种模型与外部系统连接起来的组合体。这个组合体作者命名为“Compound AI System”。这个命名的力量在哪里它把讨论的焦点从“模型能力”挪到了“系统性质”。模型能力关注的是参数、训练数据、推理效率系统性质关注的是模块之间怎么通信、失败怎么处理、状态怎么维护、成本怎么控制。文章给了一个很宽的操作性定义一个 AI 系统如果它由多个交互组件构成包括模型、检索器、数据库、外部工具并且这些组件通过某种控制逻辑协作完成任务那它就是复合式 AI 系统。我读第二遍的时候才真正领会到这个定义其实把很多散落的概念统一了。原来我以为 RAG 是 RAG、Agent 是 Agent、多模型辩论是多模型辩论它们是三个方向。但用“Compound AI System”的视角看它们全是同一个大的设计空间里不同的点RAG 是检索组件和生成组件的复合Agent 是模型和工具调用的复合多模型辩论是多个模型并行加聚合逻辑的复合。一旦有了这个统一视角很多论文和项目就不再是孤岛而是同一张地图上的地标。2.2 文章的核心方法论从模块、控制、数据三个维度拆解系统《Compound AI Systems》如果只是提出一个名词不会有这么大影响力。它真正有用的部分是给出了一套分析维度。你可以用这套维度去拆解任何一个已有的 AI 系统找出它可能出问题的地方。文章重点讨论了几个维度我在实际读的时候会再补一个自己的理解。第一个维度是模块的粒度与异质性。你的系统里有哪些组件它们各自负责什么是模型还是非模型组件这里很容易被忽略的是非模型组件比如搜索引擎、代码解释器、数据库往往决定了系统的上限。模型再聪明如果检索回来的文档是错的最后生成的结果照样是错的。所以模块设计不只是“选哪个模型”还包括“选哪些工具、怎么让它们配合”。第二个维度是控制流的组织方式。文章把常见的控制流归纳为几种模式顺序流水线、路由分支、循环迭代、以及更复杂的图结构。我当时看到这里就用自己手头的案例去套我们做的项目用了一个路由模型先判断用户意图再决定走检索流程还是走计算流程这其实就是“路由分支”模式后来我们又加入了一个校验模块发现结果不对就重新生成这就是“循环迭代”模式。用文章里的术语去描述自己熟悉的系统你会发现自己对它的理解瞬间清晰了不少。第三个维度是组件间的数据接口和状态管理。多个模型协作时中间数据用什么格式传递系统有没有记忆模块还是每个请求都独立处理这个维度在工程上最痛苦因为模型输入输出的自由度太高一旦组件多了接口对齐就会变成一场灾难。文章虽然没有给出银弹方案但至少把这个问题摆到了台面上。2.3 这篇文章与 Agent、Pipeline、工作流的关系澄清读这篇材料时最常见的困惑就是Compound AI System 和我理解的 Agent、Pipeline 有什么区别这个问题我反复被组里的同事问过自己也查过很多讨论。一个比较准确的理解是Compound AI System 是一个上位概念Pipeline 和 Agent 都是它的具体实例化方式。Pipeline 强调“确定性流程”比如先检索、再构造上下文、再生成、再后处理每一步做什么都是预先定义好的控制流简单可预测性强。Agent 则强调“模型自主决策”系统里的模型可以根据当前状态选择调用什么工具、生成什么中间步骤控制流更动态。这两者其实处于同一设计光谱的左右两端固定流程在左完全自主在右绝大多数真实系统落在中间。用一篇课程材料来回答这个问题会更强调一点不要陷入术语之争而要问自己的系统在什么位置、需要什么性质。如果你的任务步骤明确用 Pipeline 就够了强行套 Agent 只会增加不可预测性和成本。如果你的任务开放性强那固定流程根本走不通必须有自主决策。Compound AI System 这个框架的好处是它允许你在同一个大图里讨论这两者而不是把它们对立起来。这篇文章读到最后你应该带走的是“设计空间”的思维而不是“某种架构最优”的结论。3. 另外两篇阅读材料它们各自补上了哪块拼图3.1 第二篇材料的核心内容从证据走向评估框架第二篇材料切入的是 AI 系统评估这一环。它指出一个很扎心的现状很多团队在构建复杂系统时评估方式还停留在“看几个 demo 效果不错”的层面。模型一换、提示词一改、组件一加效果到底变好还是变坏完全靠感觉。这篇文章的贡献是它把智能体系统的评估拆解成可操作的任务类型和指标体系强调要在“任务级别”而不是“整体系统级别”去追踪性能。我读这篇材料时最大的收获是“细粒度评估”这个观念。以前我们会给整个 RAG 系统一个总体准确率但这样发现问题时根本定位不到是哪一环坏了。这篇文章的思路是你先列清楚系统里有哪些原子子任务检索、推理、工具选择、格式遵循等然后分别评估每一类子任务的表现最后再看子任务错误是如何传导到最终答案上的。这套思路放到我们自己的系统上直接改变了我们的调试方式以前是模型输出错了就调提示词现在是先看错误发生在哪个子任务、是检索不到信息还是信息被模型忽略再对症下药。另一个值得借鉴的概念是环境交互的评估。智能体系统是动态的它会调用工具、产生中间动作这些动作链条比单个模型的输出难评估得多。文章提供了一些评估动作链的方法比如把完整轨迹和中间状态都记录下来再用规则或模型去评判每一步的合理性。这个方法论价值很大因为它把“可观察性”提到了评估的核心位置。你不可能评估一个你看不见状态变化过程的系统所以做好日志和追踪不只是工程需求也是评估需求。3.2 第三篇材料的核心内容用工程抽象管理复杂性第三篇材料偏工程关注的是怎么用编程抽象和开发管线来治理复合 AI 系统的复杂性。它不像第一篇那样讲概念地图也不像第二篇那样讲评估指标而是给出了一系列具体的构建手段把 AI 组件封装成有输入输出定义的模块用声明式的方式描述组件之间的依赖关系通过可视化界面或 DSL 让非研究者也能搭建工作流。这里面最触动我的是“复杂性管理”这件事。三篇材料里另外两篇都在讲高层面的事只有第三篇真正把手弄脏了。它明确告诉你多个模型组件凑在一起会出现依赖爆炸组件 A 的输出格式变了组件 B、C、D 全要跟着改某个 API 的延迟一高整条链路就超时。文章给出的应对方式是强化接口契约、显式的数据模式定义、以及组件可独立测试和替换。这套思想其实是从软件工程里搬过来的但能搬到 AI 系统上并且落地本身就是一种贡献。我读第三篇的时候一直在对照自己的项目经验我们最早做多模型工作流时每个模型之间直接传字符串后端函数你调我我调你三个模块以上就开始失控。后来做了分层抽象把每个功能封装成标准接口中间数据统一为结构化格式整个系统瞬间清爽了很多。第三篇材料所说的就是你在被复杂度反噬之前最好主动去做的那层设计。它不是让你写更多代码而是让你写更少、更耦合度低的代码。3.3 把三篇拼起来一套完整的系统思维闭环这三篇材料如果你分开读每篇都能给你一些启发但效果有限拼起来才是完整的系统方法。第一篇负责建立统一词汇让你知道复合系统长什么样第二篇负责建立度量意识让你知道好系统怎么验证第三篇负责建立工程抓手让你知道复杂系统怎么落地。这三者对应到实际项目的生命周期就是概念设计、指标定义、工程实现三个阶段。我会建议你在读完第一篇后画一张概念图把系统里的组件、控制流、数据接口标出来读完第二篇后针对这张图列一份评估清单想想每一环怎么测读完第三篇后把这张图转为模块边界图确定接口、状态和部署模式。三篇的顺序正好是一个从粗到细、从思想到代码的漏斗过程这个阅读过程本身就是一个项目从 idea 到系统的缩影。很多人在社群里问这门课值不值得跟我的回答是即便后面的内容你不全读这三篇就足以改变你做 AI 工程的基本姿势。4. 实操精读策略三天读完并真正化为己用4.1 一份可抄的阅读顺序与时间分配拿到三篇材料你不需要每篇都逐字读但也别只泛读摘要。我的建议是用三天时间按“框架、细节、关系”三层递进来读。第一天三篇全部读第一遍每篇控制在 45 分钟左右只做一件事找出作者的核心主张和章节结构在开头、图表、每节的结论处做标记。第二天精读第一篇把每个论证环节拆开尤其注意那些定义性句式和分类列表然后用你自己的项目或复现实验去套用这套框架。第三天精读第二篇和第三篇重点放在评估方法和工作流抽象上把第一篇里的概念名词在另外两篇中的具体形态找出来做笔记。这样安排的核心思路是第一遍以量取胜先建立全文地图第二遍以深度取胜把第一篇嚼透第三遍以联系取胜让三篇交叉印证。比时间分配更重要的是节奏原则不要试图一遍读懂所有东西。我自己踩过的坑就是第一天死磕第一篇的某个论证环节一个半小时后头脑发胀后面两篇只能囫囵吞枣。后来我改成先通读三遍把所有难懂处标记下来第二遍再集中攻克效率和吸收率都高得多。4.2 一套针对性很强的论文笔记模板做阅读材料笔记我强烈建议你用“问题驱动”而不是“摘抄驱动”。同样读一篇文章如果你的笔记只是把作者的话换个说法抄下来那读完之后你还是原来的你但如果你带着问题去读笔记就会变成属于你的东西。针对这套材料我用的笔记模板是固定六栏你可以直接复制使用。表格论文精读笔记六问问题对应阅读关注点这篇材料想解决什么痛点开头的 problem statement 部分作者给出的核心主张是什么摘要末尾、引言最后一段、结论支持主张的关键证据有哪些实验章节、图表、案例分析这套方法/框架应用边界在哪限制条款、实验失败案例我可以立刻用到自己项目的哪一点任何让你有“这说的不就是我”感受的段落哪里我不同意或觉得没说清论证薄弱处、受限于时效性的观点这套模板的妙处在于最后一栏“哪里我不同意”是最有价值的。因为它逼着你不要把论文当真理而是当成一个对话对象。比如我读《Compound AI Systems》时就有不同意见文章对成本的分析相对乐观实际上多模型编排的 token 消耗经常会失控这对中小团队是非常现实的问题。这个不同意见后来成了我设计项目时重要的一条约束原则不管系统多优雅先给成本加个上限。4.3 最小可行侧的复现实验怎么做三个小时的论文读得再爽也不如两小时的代码实验来得真实。CS329Z 的作业里给了基础环境但如果你想在课程之外自己吃透这些阅读材料我非常推荐你做一个最小复现实验规模不用大目的是验证论文中的观点是否能帮助你改进一个实际系统。你可以拿一个自己手里已有的小任务比如本地文档问答做一次“单模型 vs 复合系统”的对比。先搭一个最简单的单模型 prompt 系统想一个评估指标回答准确率即可记下得分和失败案例然后按照《Compound AI Systems》里的思路加入一个检索模块和一个校验模块组成一个三段的复合流水线用同样的测试集评估。然后你仔细分析两个结果差异的来源提升到底是来自检索提供的额外信息还是来自校验模块纠正了错误这个归因过程比你复制任何 benchmark 实验都有教育意义因为你在亲手拆解“为什么系统会更好”。我用过一套很简单的伪代码来搭建这种最小验证系统结构清晰到团队成员都能直接看懂# 一个最小 Compound AI System 的伪码示意 def run_compound_qa(query: str) - str: # 模块1查询理解 intent classify_intent(query) # 模块2检索路由 if intent factoid: docs retrieve(query, top_k3) context format_docs(docs) else: context 不需要外部资料 # 模块3生成 answer llm_generate(query, system_prompt, context) # 模块4校验与重试 if validate(answer, context) failure: answer llm_generate(query, system_prompt RETRY_SUFFIX, context) return answer写完这个小系统后你要有意识地把评估表格和测量日志加上。这不仅帮你判断复合系统是否更优也直接呼应第二篇材料里“细粒度评估”的思想。哪怕只是给每个模块加一行日志、给每次调用记录 token 消耗你都会立刻获得一种全新的“系统视角”。很多人读完这篇材料觉得很对但不知道怎么用问题往往就差在这一步没把框架映射到一个哪怕很小的具体系统上去验证。4.4 读这套材料时可以顺手建立的知识索引既然这是第一讲后面肯定还有更多阅读材料和技术栈要学。建议你从第一讲开始就建立一个“知识索引”文档。这不是笔记而是一个持续更新的表格记录每个新概念第一次出现在哪篇材料、它与哪个已有概念冲突或互补、你在哪个项目里实践过它。我自己的索引文档会用三列概念名、来源篇目、我的应用案例。例如“Compound AI System来源第一篇应用在文档问答项目中搭建三段流水线”“细粒度评估来源第二篇应用为问答流程的检索、生成、校验分别统计准确度”。这个索引看起来简单但积累到第十讲后你会得到一张完全属于自己的领域地图。到那时你再看新论文定位它的速度会快很多因为你不再是从零开始理解概念而是把新概念挂到已有的知识网络上。5. 常见问题与排查技巧实录5.1 读完后混淆 Compound、Agent、Pipeline 三个词怎么办这个困惑太典型了几乎每次交流会都有人问。我的破局方法是扔掉定义改画具体例子。拿自动写周报的小助手举例如果系统是固定“收集数据 → 调用模型生成 → 人工确认”流程那它是 Pipeline如果系统内部有一个模型能自主判断“这周数据不完整我要先调用接口补数据再写报告”那它是 Agent而不管你管它叫 Pipeline 还是 Agent只要你把数据处理模块、模型模块、确认模块组装在一起协同工作它同时也是一个 Compound AI System。所以你会看到三个词并不在同一层Compound 是系统结构的描述Pipeline 和 Agent 是控制流风格的描述一个 Compound 系统内部可以既有固定流水线段也有自主决策段。如果你读材料时把这个层次关系理清了后面看到什么“Agentic RAG”“Compound Agent”之类的混合词就不会再晕。5.2 复现评估实验时得分比论文低是系统问题还是评估问题经常有人照着论文搭完系统发现自己在自己的场景里跑分低于论文报告第一反应是系统没搭对。根据我的经验更要先怀疑的是评估口径不一致。论文里的测试集可能和你的业务数据分布不一样论文的评估代码可能对某些输出格式有隐式假设这些都会导致分数差异。排查顺序建议是先检查输入输出格式是否完全对齐再检查评估指标计算代码的细节比如字符串匹配是精确匹配还是包含匹配、是否大小写归一化然后用量化对比看看你的用例里到底哪类 case 显著拉低了分数。很多时候你会发现不是系统没做对而是评估条件没做对。另外如果论文附带了官方评估代码一定要直接用别自己另写一套自写评估脚本的坑我踩过太多次了。5.3 理论看懂了但设计不出系统结构怎么办这是从阅读走向实践最常见的一道坎。你懂了概念但真要你给一个需求设计复合系统时脑子里一片空白。我的经验是强制给自己加一道“组件三步题”第一步把任务拆成不可再分的子步骤并标出每一步是人做的还是机器做的第二步为每个机器步骤选一个实现方式可以是模型、规则、检索器或外部工具第三步确定这些步骤之间是固定顺序、条件分支还是循环关系。三步走完一个系统骨架就出来了。比如“帮我总结一份合同里的风险条款”这个任务。子步骤包括读取文件、提取条款、对照风险库匹配、生成总结。实现上读取文件可以走规则提取条款可以用模型匹配风险库可以用检索或规则生成总结用模型。控制流则是读文件 → 提取 → 匹配 → 生成其中匹配失败时可能触发重新提取这就是一个循环。这样拆完架构图自动就在脑子里了。所谓“会设计系统”其实就是这个三步拆解的熟练工。5.4 材料读了就忘两周后跟没读一样遗忘不是你的问题是阅读方式的问题。对抗遗忘最有效的办法是主动提取练习也就是读完每个章节后合上材料用自己的话把这一章的核心观点和关键证据写出来。不要用作者的原词用你能讲给同事听的大白话。写不出来就回去再翻翻完再写这个过程重复两次以后这些内容基本会变成长期记忆。还有一个技巧是刻意把读到的概念用在平时讨论中。如果你正在参加任何技术讨论或 code review试着用《Compound AI Systems》里学到的“控制流模式”“组件接口”来聊问题。概念只要被你在真实对话中使用过就很难再忘。我自己带项目时会有意让成员在每周例会用这节课的框架描述自己负责的模块。用不了三周大家讲系统结构时的表达能力都会明显变好。5.5 关于工具选型读这套材料需要用到哪些辅助工具阅读本身不需要复杂工具一套顺手 PDF 阅读器、一个笔记软件就足够。我个人的偏好是长期使用支持双栏同步滚动的 PDF 阅读器左侧论文、右侧笔记这样既能做标记又能随时把想法打到对应位置。收藏和标注统一放在一个可检索的标签体系里按“概念/方法/实验/工程”四个大类归类之后写总结时会非常省力。如果你愿意也可以在通读完三篇后用本地知识库工具把三篇材料丢进去做一个问答方便快速定位某段观点出自哪篇。但我不建议第一次阅读就依赖问答工具那会跳过你大脑自己建立知识结构的过程。工具是帮你在读完之后快速检索用的不能替你完成第一次深度思考。这个原则适用于任何领域的前沿阅读材料——先苦读再上工具。至于代码复现环境你只要有一个能跑 Python 和主流大模型 API 的环境就够。不要一开始就上复杂的 Agent 框架用最简单的方式把一个模块功能跑通并记录日志即可。最小可行实验的价值在于让你亲手感受“复合系统设计的复杂度从哪里来”而不是让你搭出一个漂亮的玩具系统。越简单你越能看清问题本质。6. 一点个人的后续动作建议把三篇材料消化完如果你和我一样是带着项目来读的接下来最该做的事不是立刻开新项目而是拿手头一个现有系统做一次“体检”。用《Compound AI Systems》的问法画一遍它的组件增量图标出控制流和接口用第二篇的清单给这套系统补上细粒度评估指标和日志再把第三篇的抽象思想当尺子量一量你目前的代码边界是否清晰。哪怕只完成其中一项也会有立竿见影的感受以前你只知道自己系统能跑现在你能说出它为什么好、为什么差、改哪里会变好。这套材料最妙的地方在于它不是给你灌输一套标准答案而是给你一套审视 AI 工程的 x 光机。我当初也是被那些“编排”“RAG 演进”的漂亮词汇蛊惑过的人直到按这三篇的思路真正拆了一个自己的系统才搞清楚原来之前很多时间都花在了不是一个系统级别的优化上。这门课之后的阅读只会越来越深但如果你第一讲就把这套思维模式真正内化了后面的路会顺畅很多。