企业官网建设流程全解析

最近在梳理某高校 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 到复合系统。

不必非得用到多贵的模型，中小参数模型配合良好的检索和记忆，也能给你带来很惊人的效果提升。关键在于把每一条反馈回路做扎实，把每个组件之间的数据格式定义干净。框架是骨架，接口是血脉，反馈才是灵魂，这大概就是三篇材料浓缩下来的核心道理吧。