AI Infra 全景图：Agent 系统的分层解剖

## 引子：那个"跑起来了"的 Demo，为什么上不了生产？ 几乎每个做过 Agent 的工程师都经历过同一个魔幻时刻：周五下午，你用 LangChain 拼了个能查数据库、能调工具、还能多轮对话的 Agent，在本地跑得行云流水，demo 惊艳全场，仿佛下一秒就要融资上市。到了周一，产品经理轻描淡写地说了一句“上线吧”，于是灾难正式开机——任务跑到一半进程重启，状态当场失忆；两个并发请求就把 API 额度烧穿，钱包开始冒烟；一个死循环的 Agent 勤勤恳恳干了一整晚，顺手花掉四位数；线上出了错，你翻遍日志，最后只知道它来过、跑过、贵过，但完全不知道它到底卡在哪一步、基于什么判断、以及当时脑子里到底在想什么。 问题并不在于代码质量，而在于**一个 Agent Demo 与一个可生产化的 Agent 系统之间，隔着一整套完整的基础设施能力**。Demo 只需要验证“能力”是否跑通；而真正的系统，需要在能力之上构建调度、隔离、记忆、可观测性与编排机制。恰恰是这些框架默认封装起来的部分，往往会在规模化落地时最先成为瓶颈。 更关键的是，当前市面上的大多数教程，要么聚焦于“如何用 LangChain 写一个 Agent”这类能力层实践，要么讨论“如何优化 vLLM”这类底座层问题。而位于两者之间、真正决定系统能否支撑生产环境的关键架构层，反而很少被系统性地拆解。 这篇文章的目标，是将 Agent 系统自上而下**拆解为七个层次**，并逐层说明：每一层解决的正交问题是什么、底层机制如何运作、可选的技术路线有哪些，以及在真实生产环境中最容易引发严重故障的关键风险点。 为了避免停留在抽象讨论，全文将以一个足够复杂且约束严苛的场景贯穿分析——**慢病管理 Agent（医生工作台辅助方向）**。选择这一场景，是因为医疗业务会将 Agent 系统各层能力的要求推到极限：记忆不能出错，因为它可能直接影响诊疗安全；编排不能失控，因为系统行为需要可解释、可追责；可观测性也不再只是调试手段，而是合规审计与法律证据链的一部分。能够支撑医疗场景的架构，通常也足以覆盖大多数高要求的企业级应用。 读完这篇文章，你应该能够在脑中建立一张可复用的 Agent 系统分层心智图，并形成一套判断框架：每一层应该如何选型、如何解耦，以及应当按照什么顺序推进生产化落地。我们开始。 --- ## 一、先建立心智模型：Agent Infra 的七层栈 在钻进任何细节前,你需要先有一张全局地图。否则你会像大多数团队一样,被某个"全家桶"框架牵着走,直到有一天发现每加一个需求都在跟框架对抗。 我把 Agent 系统抽象成**七层栈**,从上到下,每一层解决一个**正交**的问题——所谓正交,意思是这些问题彼此独立,理论上可以单独评估、单独替换。真实系统里它们常被某个大框架(LangGraph、Dify、Coze)打包在一起,但**架构师的核心能力,恰恰是能把它们拆开来看**。  用一句话记住这七层的分工:**L7 决定"能接谁",L6 决定"怎么写",L5 决定"怎么流转",L4 决定"怎么扛量",L3 决定"怎么不炸",L2 决定"记不记得",L1 横切"看不看得见",L0 是"跑得多快"。** 这里有个关键认知要先建立:**这七层的重要性不是固定的,它随场景剧烈变化**。通用 Agent 里被过度追捧的"自主性"(L5)和"记忆"(L2),在不同场景里权重完全不同。慢病管理场景就是一个极端例子——它把 L5 的权重从"追求自主"翻转成"追求可控",把 L2 从"可选个性化"翻转成"产品核心"。这一点,我们在后面每一层都会具体看到。 下面开始逐层解剖。我会按 **职责 → 机制 → 选型(区分 Research 结论 / Industry 实践 / 场景取舍)→ 工程现实(真正的坑)** 的结构展开每一层。 --- ## 二、L6 Agent Framework：它是抽象层,不是能力层 我们从大多数人第一个接触的层开始——框架。这一层最容易产生一个致命误解:**以为选框架就是选能力**。 不是的。框架不提供任何能力,它只提供**组织能力的方式**——一种心智模型和一套 API。选错框架的代价,不是"某个功能实现不了",而是"框架的心智模型和你的业务控制流不匹配",于是你后期每加一个需求,都在跟框架的抽象对抗。这种痛苦是慢性的、累积的,等你意识到时,重构成本已经高到无法承受。 ### 框架的真正分水岭:控制流写在哪里 主流框架的分歧,本质是**"控制流(下一步做什么)由谁决定"**的分歧: | 范式 | 代表 | 心智模型 | 适合场景 | |---|---|---|---| | **图 / 状态机** | LangGraph | 显式节点 + 边 + 全局 State,可持久化、可回放、可人工介入 | 生产级、需精确控制流转 | | **对话 / 角色** | AutoGen · CrewAI | 多 Agent 通过"对话"协作,行为涌现 | 原型、研究、探索性任务 | | **轻量 SDK** | OpenAI Agents SDK · Pydantic-AI | 极薄封装 tool-loop + handoff | 单/少 Agent,逻辑自己控 | | **检索中心** | LlamaIndex | 以索引/检索为一等公民 | RAG 重、Agent 轻 | 这里要区分三层认知: - **Research 视角:** 学术论文里"多 Agent 辩论""角色扮演协作"效果亮眼,但那是在特定 benchmark 上的结论。 - **Industry 现实:** 规模化生产中,**"多个 Agent 自由对话、行为涌现"是最难调试、最不可控的形态**。真正跑在生产环境的,绝大多数是"看起来像 workflow、只在关键节点让 LLM 做决策"的**受控图**。这就是 LangGraph 及各家自研 state-machine 在企业侧占比最高的原因。 - **架构师取舍:** 一个极其实用的判据——**你的核心控制逻辑,是写在框架 API 里,还是写在 prompt 里?** 前者可测试、可回放、可 diff;后者是一颗定时炸弹,因为你无法对一段自然语言做单元测试。 ### 慢病管理场景的选择 对于我们的慢病医生工作台,答案是明确的:**用 LangGraph 类的显式状态图,避开 CrewAI/AutoGen 的自由对话范式**。 原因很简单:医疗场景绝不能接受不可复现的行为。医生今天问同一个患者,和明天问,系统的推理路径必须一致、可解释、可审计。自由对话式多 Agent 的"涌现"特性,在这里从优点变成了不可接受的风险。而 LangGraph 提供的三个特性——**显式状态、可持久化 checkpoint、human-in-the-loop 中断**——恰恰是医疗场景的刚需。 ### 工程现实:框架最大的隐性成本是锁定 框架真正的坑,不是功能,而是**升级与锁定**。LangChain 生态的 API 迭代极其激烈,你今天吃透的高阶抽象,半年后可能就被废弃或重构。 顶级团队的通用做法是:**在框架之上,再包一层你自己的 domain interface**。也就是说,你的业务代码不直接调 LangGraph 的 API,而是调你自己定义的"临床流程 DSL",这个 DSL 底层用 LangGraph 实现。这样,当框架升级、甚至你决定整个换掉框架时,受影响的只是薄薄的适配层,而不是你所有的业务逻辑。这是"每一层都要能被单独替换"这条原则的第一次体现,后面还会反复出现。 --- ## 三、L5 编排:控制流本身,Agent 质量的第一决定因素 如果说 L6 是"用什么工具写",那 L5 就是"到底写成什么样"。**这一层是 Agent 系统质量的第一决定因素,比模型选型更重要。** 我见过太多团队执着于"换个更强的模型",却对着一个糟糕的控制流设计束手无策——那是在错误的层解决问题。 ### 编排的机制光谱:从确定到自主 编排的本质,是决定"下一步做什么"。所有编排模式都可以放在一条从"完全确定"到"完全自主"的光谱上:  - **Workflow(编排式):** 步骤由**代码**决定,LLM 只负责填充内容。可预测、可测试、成本可控。 - **Agentic(自主式):** 步骤由 **LLM** 决定(ReAct / Plan-Execute / Reflexion)。灵活,但每一步都可能失控,成本和延迟的方差极大。 这里有一条行业共识,来自 Anthropic 那篇被反复引用的《Building Effective Agents》,我认为它是整个 Agent 工程最重要的一句话: > **能用 Workflow 就别用 Agent。** 只有当任务的步骤数、路径无法预先枚举时,你才应该付出 Autonomous 那份不可控的代价。 ### 慢病管理:临床路径即状态机 现在把这个原则套到医疗场景,你会得到一个非常清晰的结论:**慢病管理的控制流,不该由 LLM 决定,而应由临床路径(Clinical Pathway)决定。** 糖尿病管理有明确的指南:血糖如何分层、随访周期多长、并发症何时筛查——这些是**确定性的医学知识**,是几十年循证医学的沉淀。让 LLM 去"自主推理"这些,不仅没必要,而且是在赌人命。正确的做法是把它们写成规则引擎,LLM 只负责它真正擅长的事:**把规则的结论,翻译成医生或患者听得懂的话**。 下面是慢病医生工作台的编排状态图。注意它的核心特征:**这是一个受控图,LLM 只出现在特定的、低风险的节点上,而所有涉及医学判断的节点都是确定性规则。**  这张图里藏着几个关键设计,值得逐一强调: **第一,高危信号检测是独立的、优先级最高的旁路。** 任何输入都要先过这一关,命中就直接中断正常流程。这一层必须是**确定性规则 + 高召回**——宁可误报十次,不可漏报一次。你不能把"这个症状危不危险"交给一个有幻觉概率的 LLM 去判断。 **第二,指标解读走规则,不走生成。** 血糖 15 mmol/L 意味着什么,是查表加规则,LLM 只负责把"这个数值偏高,建议……"翻译成温和、专业的话术。让 LLM 判断危险等级,是把方向盘交给一个偶尔会走神的副驾。 **第三,自主 loop 只允许出现在最低风险的分支**,比如健康教育的多轮追问,而且必须带硬熔断。 ### 工程现实:自主 loop 的三道保险 只要你的系统里存在任何自主 loop(哪怕只在科普问答分支),就必须上三道保险,缺一不可: 1. **硬熔断:** 最大步数 / 最大 token 上限,到了强制停。 2. **成本预算:** 每一步累加成本,超预算中断。 3. **循环检测:** 检测到重复的 tool call 模式就打断——这是防止死循环烧钱的关键。 没有这三样,一个陷入死循环的 Agent,真的能在一夜之间烧光你一个月的 API 预算。这不是危言耸听,是无数团队交过的学费。 --- ## 四、L4 调度:从"能跑"到"扛量",以及慢病特有的"主动触发" 单机 Demo 阶段,调度层根本不存在——你同步调用、串行执行,一切安好。但上生产的第一天,它就会变成你最大的瓶颈。 ### 通用调度要解决的问题 Agent 任务有个和传统 Web 请求截然不同的特征:**它慢,而且慢得不确定**。一次多步 Agent 任务动辄几十秒到几分钟,同步阻塞的架构必死。所以调度层要解决: 1. **异步与并发** —— task queue + 持久化状态,把"提交"和"执行"解耦。 2. **长任务持久化** —— Agent 跑到一半进程挂了怎么办?这是 **Durable Execution** 的战场。 3. **预算调度** —— per-user / per-tenant 的 token 配额、rate limit、优先级队列。 4. **资源调度** —— 与 L0 的连续批处理协同。 关于长任务持久化,这里给个明确的选型判断: - **秒级、可重跑的任务** → 消息队列(Celery / 自研)就够了。 - **分钟级、状态昂贵、不能重跑的任务** → 上 **Durable Execution**。当前企业侧最稳的答案是 **Temporal**(工作流即代码,自动重放恢复),轻量版可以用 LangGraph 自带的 Postgres checkpointer。 ### 慢病场景的调度反转:从"被动扛并发"到"主动触发" 这里出现了慢病管理与通用 Agent 在调度层最大的差异。通用 Agent 的调度是**被动的**——等请求来了再处理。而慢病管理有一个独特维度:**系统要主动按临床节奏去找患者**,而不是等患者/医生来问。 这意味着什么?意味着**一个患者,就是一个可能跑一整年、可暂停、可恢复的 durable workflow**。  这张图的核心价值在于:**患者的管理状态被持久化在工作流引擎里,而不是在某个进程的内存里**。系统升级、服务重启、机器宕机,患者的随访节奏都不会丢。这是慢病场景对 L4 的硬要求,也是 Temporal 这类 durable execution 引擎在这里价值极高的原因。 ### 工程现实:第一天就要解耦提交与执行 90% 的团队在这一层踩的坑高度一致:**把长任务塞进 HTTP 请求的生命周期里**。用户点一下,后端同步跑三分钟,前端转圈圈,超时、重试、状态混乱接踵而至。 正确的做法从第一天就要立好:**"提交任务"立即返回 task_id,"执行任务"在后台异步进行,前端轮询或回调获取结果**。这个架构上线后再改,成本是指数级的,因为它渗透到你所有的接口设计里。 --- ## 五、L3 执行与沙箱:在医疗场景里,它的定义变了 在通用 Agent 里,L3 讲的是"如何隔离运行 LLM 生成的不可信代码"。只要你的 Agent 会跑 code interpreter、shell 命令,这层就是安全底线。 ### 通用沙箱:隔离强度光谱 | 方案 | 隔离机制 | 强度 | 启动 | 适用 | |---|---|---|---|---| | **Docker** | namespace + cgroup | 弱(共享内核) | 快 | 内部可信 | | **gVisor** | 用户态内核拦截 syscall | 中 | 快 | 多租户平衡型 | | **Firecracker** | 硬件虚拟化,独立内核 | 强 | ~125ms | 多租户不可信代码 | | **WASM** | 语言级沙箱 | 中强 | 极快 | 轻量、边缘 | 托管方案里,**E2B**(基于 Firecracker)几乎是当前 Agent code sandbox 的事实标准。判据很简单:隔离等级由**"代码来源可信度 × 多租户程度"**决定。对外产品跑用户代码,必须 microVM 级。 ### 慢病场景:沙箱边界从"进程隔离"变成"数据边界 + 内容边界" 慢病医生工作台通常不跑用户代码,所以传统沙箱不是重点。但**这层在医疗被重新定义为两件更重要的事**:  **内容边界(输出侧):** 每一条输出前都要过一道分类器——它是否构成诊断结论?是否修改了用药剂量?命中就改写。涉及具体医学事实的回答,强制 RAG 溯源,无可靠来源就不作答。医疗是**零幻觉容忍**的场景。 **数据边界(存储/传输侧):** 患者身份信息(PII)与健康数据(PHI)分离存储;传给第三方 LLM API 前必须脱敏,或者干脆用私有化模型规避外传;中国医疗数据不得出境,这直接约束了 L0 的部署选型。 **架构师判断:** 医疗 Agent 的红队,第一个打的不是 SSRF,而是两件事——"能不能诱导 AI 给出诊断/改药建议"和"能不能套出别的患者的数据"。你的 L3 设计,就是为了堵死这两条路。 --- ## 六、L2 记忆:在通用场景被高估,在慢病场景是护城河 这是全文权重反转最剧烈的一层。在通用 Agent 里,我通常会劝你"别过度工程记忆"——大多数工具型 Agent 的"记忆",一个对话摘要加 RAG 就够了。但在慢病管理里,**记忆就是产品价值本身**。系统的核心竞争力,是"它记得你三个月来的血糖趋势、你上周说的药物副作用、你不爱运动的习惯"。 ### 记忆分型:混谈是灾难 首先必须把记忆分型讲清楚,因为混谈不同类型的记忆,是这一层最大的架构错误来源:  这张图里有两个**用红色标注的、关乎人命的架构判断**,我必须重点讲: **判断一:医疗指标数据绝不能只靠向量检索。** 血糖趋势是结构化的时序数据,必须存在关系库或时序库里,做精确的聚合运算(7 日均值、达标率、趋势斜率)。向量库只用于"回忆患者曾经说过什么"这类语义检索,绝不能用于"患者的血糖是多少"这类精确查询。**混淆这两者,是医疗 Agent 最危险的架构错误**——你不能用相似度匹配去回答一个需要精确数值的临床问题。 **判断二:记忆污染在医疗里是安全事故。** 一条错误的"患者对青霉素过敏 = 否"被写入长期记忆,然后被反复检索、自我强化,可能是致命的。因此长期记忆的写入必须:①区分"患者自述"与"医生确认"两个可信度等级;②关键医疗事实(过敏史、诊断、用药方案)**只允许医生侧写入或确认,AI 不能自主固化**。 ### 选型判断:别一上来就上 Mem0/Zep 市面上有 Mem0、Zep、Letta(MemGPT)这些专门的记忆框架,它们的价值在于做了记忆的 extraction、consolidation、冲突解决——因为"写入什么、何时写、如何去重更新遗忘",比"检索"难十倍。 但对慢病场景,我的建议是:**医疗事实层必须自控,不要外包给通用记忆框架**。稳妥的起点是"**结构化健康档案(自建 schema + Postgres/时序库)+ 对话摘要 + RAG 科普库**"。个性化的语义画像层,可以在产品成熟后再引入 Mem0 类方案,但那是锦上添花,不是地基。 **判据:记忆是不是你产品差异化的一部分?** 慢病管理里,答案是"是,但仅限于对话/画像层;医疗事实层是安全刚需,必须自建强 schema"。 --- ## 七、L1 可观测:在医疗里,它从调试工具升级为法律证据链 在通用 Agent 里,Tracing 是调试和迭代的工具。而在医疗场景,它的性质彻底变了——**它是出医疗纠纷时的举证材料,是法律要求,不是可选项**。 ### 可观测的三个层次:别只做第一件 很多团队的"可观测"只做了 trace,这远远不够。完整的可观测是三件事: 1. **Trace 追踪:** 一次请求的完整调用树——哪个 tool 慢、哪一步出错、token 花在哪。 2. **Eval 评估:** 离线数据集回归 + 在线质量打分。 3. **Monitoring 监控:** 成本/延迟/错误率的时序告警 + 数据漂移检测。  **架构师的关键判断:从第一天就基于 OpenTelemetry GenAI 语义约定埋点。** 原因是 Agent 可观测的标准正在向 OTel 收敛,绑死某家私有 SDK 后期迁移极痛。Langfuse、Arize Phoenix 都兼容 OTel——**埋点走 OTel,后端可换**,这是不被锁定的正确姿势。 **选型:对医疗,Langfuse(自托管)优于任何 SaaS**,因为医疗数据不能进外部 SaaS 后端。埋点走 OTel 标准,后端自托管,兼顾标准化与合规。 ### 工程现实:没有 trace+eval 闭环,Agent 项目必败 我要把这句话说得重一点:**Tracing 不是"上线后再加"的东西,它决定你的迭代速度。** 没有 trace+eval 闭环,你的 prompt 和流程改动全靠"感觉好像变好了",无法回归、无法量化。这是 Agent 项目失败的头号原因——不是模型不行,是团队根本不知道自己每次改动是变好了还是变坏了,在黑暗中反复横跳。 --- ## 八、L0 模型服务:合规底座与 Agent 特有的省钱之道 最底层是推理服务。Agent 系统的延迟方差主要来自这里——多步意味着延迟累乘,一步 2 秒,十步就是 20 秒。 ### 主流选型 - **vLLM** —— PagedAttention + 连续批处理,通用吞吐标杆,生态最广。 - **SGLang** —— RadixAttention,核心是 **prefix cache 复用**。 - **TGI / TensorRT-LLM** —— HF 生态 / NVIDIA 极致优化。 ### Agent 工作负载的特征决定了优化方向 这里有个关键洞察:**Agent 的工作负载特征是"长 prompt + 高 prefix 重复 + 短输出 + 多轮"**。你的 system prompt(临床指南、护栏规则、工具定义)在多步之间高度重复。 因此,**prefix caching(KV cache 复用)是 Agent serving 的头等优化**,比单纯堆吞吐更省钱。这就是 SGLang 的 RadixAttention 在 Agent 场景特别值钱的原因。即使你用的是 OpenAI/Anthropic 的 API,把稳定内容放在 prompt 前面以命中厂商的 prompt cache,也是同样道理的省钱手段。 ### 慢病场景:合规是第一约束 对慢病医疗,L0 的第一约束不是性能而是合规:**数据不出境是硬线**。所以选型是——**私有化部署开源模型(Qwen、DeepSeek 等)配 vLLM/SGLang**,或使用通过等保/医疗合规认证的国内云。 --- ## 九、把七层拼起来:慢病医生工作台的完整数据流 拆完七层,现在我们把它们拼回一个完整系统,看数据是怎么在层与层之间流动的。记住这个系统的本质,我用一句话概括: > **它是一台"患者数据聚合器 + 临床决策建议引擎",把医生原本要花 20 分钟翻档案才能管理的患者,压缩成 2 分钟看一屏 AI 整理好的摘要与建议,然后一键确认或修改。**  这张端到端图,把七层的协作关系一次性讲清楚了。你可以看到每一层各司其职:L2 聚合数据、L5 编排流程、规则引擎+RAG 生成内容、L0 提供推理、L4 管理长周期、L1 全程记录。而**贯穿始终的主线是那四个动作:聚合数据 → 生成建议 → 医生裁决 → 随访闭环**。技术为这四步服务,而不是反过来。 这里必须点出一个 To B 医生工作台相比患者端 Agent 的**架构红利**:因为**医生在环(human-in-the-loop)**,责任主体是持证医生,AI 只是建议者。这意味着你的 L5 反而可以做得比患者端"更激进"——可以直接生成用药调整建议草稿、诊断倾向提示,因为最终由医生裁决。**患者端系统梦寐以求却不敢做的事,你可以做。这是定位选择带来的最大架构优势,一定要用足。** --- ## 结语:分层的意义,是让复杂系统变得可推理 回到开头那个“跑起来了却上不了生产”的 Demo。到这里你应该已经清楚，它与一个真正可用于生产的 Agent 系统之间，差的并不是某个神奇技巧，而是对这**七个层次分别进行系统化工程建设**。 分层的核心价值不在于展示复杂度，而在于**将一个难以整体掌控的复杂系统，拆解为可以逐层推理、逐层验证、逐层替换的工程结构**。当 Agent 出现问题时，分层能帮助你快速判断：问题究竟来自编排逻辑错误（L5）、记忆污染（L2），还是调度过程中状态丢失（L4）。当系统需要演进时，分层也能让你在不牵动整体架构的前提下，替换或升级其中某一层。这正是架构师与“调包工程师”的根本区别——前者脑中有完整的系统结构图，后者手里只有某个框架的 API 文档。 慢病管理这个例子进一步说明了一个更深层的事实：**架构没有放之四海而皆准的标准答案，只有面向具体场景的权重取舍**。同样是七层架构，在通用 Agent 与医疗 Agent 中，各层的重要性排序、设计重点和工程要求都可能完全不同，甚至出现相反的优先级。真正的架构能力，不是机械记忆所谓“最佳实践”，而是**能够基于场景约束，重新推导每一层应该如何设计、如何落地、如何演进**。