31-模块五-AI系统架构设计 第31讲-LLM 应用架构模式全景 - RAG Agent Chain Tool Calling 的架构选型

本讲目标：建立 LLM 应用架构的「分类学」与选型框架；理解 Simple Chain、RAG、Agent、Tool Calling、Agentic RAG 的边界与组合方式；对照 CodeSentinel 贯穿项目，说明为何采用 Agentic RAG；用 LangChain（LCEL + Tool + Agent）给出每种模式的可运行最小示例；从延迟、成本、准确率、复杂度四维度做架构对比表。读完你应能向团队清晰陈述：何时不必上 Agent，何时必须混合检索与工具。开场：别让「Agent 万能论」毁掉你的架构过去两年，业界对 LLM 应用有一个常见误区：凡是智能助手都要做成 Agent，凡是企业知识都要做成 RAG，凡是集成外部系统都要上 Tool Calling。结果是：简单问答被拖进多轮循环，成本与延迟失控；本该结构化的规则审核被向量检索「猜答案」；本该一次函数调用的集成被模型反复试错。架构模式的本质是约束求解：在给定任务类型、数据形态、合规要求与 SLA 下，选择最少的 moving parts 完成任务。Simple Chain 不是「落后」，而是许多场景的最优解；RAG 不是「搜索」，而是把外部知识以可控方式注入上下文；Agent 不是「更聪明」，而是把规划与执行显式化并承担失败代价；Tool Calling 是结构化 I/O 的契约层；Agentic RAG 则是当「知识密集 + 多步推理 + 外部动作」同时出现时，才值得支付的复杂度税。CodeSentinel 作为 AI 驱动的代码审核与架构治理平台，典型输入是 PR diff、仓库元数据、策略规则与历史评审记录；典型输出是可定位的 finding、风险等级与可执行的整改建议。它既需要检索相似代码与历史案例（RAG），又需要按文件类型与变更范围选择不同分析工具（Tool Calling），还需要在多轮观察后决定是否扩大检索范围或请求更多上下文（Agent）。因此本讲将其定位为Agentic RAG：不是名词堆砌，而是职责分离后的组合架构。下面先给出模式分类的全局视图与对比流程图，再深入原理，最后用 LangChain 可运行代码把五种模式落到同一套接口风格上，便于你在团队内做 POC 与评审。为了把抽象模式落到工程语言，你可以先回答三个问题：第一，事实从哪里来？若事实应来自「当前仓库与历史变更」，就必须有检索或工具，而不是指望模型背诵。第二，决策是否需要分支？若同一类 PR 在不同目录、不同语言、不同依赖版本下需要不同分析路径，就意味着存在动态策略，Agent 或「有限状态机 + Tool Calling」会优于单段提示词。第三，失败时如何降级？线上系统必须定义：向量库不可用怎么办、工具超时会怎样、模型输出无法解析又如何。把降级路径画清楚，你会发现很多「看起来很酷」的 Agent 图，在真实故障场景里并没有退路，这正是架构评审要拦截的风险。本讲刻意把Tool Calling与Agent分开讲解，因为在企业落地时它们对应不同的治理强度：Tool Calling 更像「带 schema 的函数分发」，适合放进严格的白名单与审计；Agent 更像「可循环的控制流」，需要更强的运行时约束。CodeSentinel 的推荐路径是：先用可观测的 Tool Calling 打通分析链路，再引入小步 Agent 做检索扩缩与策略选择，最后才把 RAG 与 Agent 合并为 Agentic RAG 的主形态。跳跃式建设往往导致你同时调试索引质量、工具稳定性与循环停止条件，排障成本呈乘法增长。全局视角：五种模式在输入输出上的差异（Mermaid）Agentic RAG复杂任务RAG 注入知识Agent 循环工具调用可执行结论Tool Callingtool_calls用户请求LLM 决策工具执行LLM 汇总结构化结果Agent 循环任务目标规划/推理行动观察环境反馈最终结果RAG用户查询Retriever 检索上下文拼装LLM 生成带引用输出