第 8 章 — 架构部署形态
LLM Primer IV: Designing AI Cognition with MCP 章节走读的第八篇。两个编排逻辑一样的系统在生产里表现可能差很大,因为 "模型到底跑在哪里" 这个问题有三种不同的回答,每一种设了不同的延迟、成本、安全上限。
这一章为什么存在
第 6、7 章规定了 agent 怎么协调。它们对一个决定系统真实表现同等多的问题保持沉默:每一个 agent 跑在哪里、语言模型、MCP server、工具怎么在网络上摆?这一章的架构决策碰每一个请求、每一块钱。MCP 生态在 2025 年到 2026 年里浮现出三种大体上不同的形态,而这三种都不是普世正确的。每一种针对一组不同的约束做了优化,选择的后果是工程师该能在做之前讲清楚的。
8.1 可复用 AI agent:模型跟 server 打包在一起
第一种形态把一个语言模型跟一个 MCP server 打包成一个黑盒能力。Client 调 "review 这个 pull request" 就像调一个工具;在底下,一个完整的 agentic 循环在 server 侧跑,调模型、调内部工具、只把最终输出还回来。这种模式出现是因为一些组织建了专精 agent — 研究、code review、财务分析 — 想暴露给很多 host 应用用,而不让每一个 host 都得搞懂内部。
强项是实的。封装让 agent 作者换模型或调编排都对 client 不可见。跨 host 应用的复用意味着同一个 agent 通过同一个接口服务 Claude Code、企业应用、面客 chatbot。代价同等是实的。不透明让 debug 难:agent 做了错决定时,client 看不到为什么。延迟堆起来,因为 server 侧循环每次都跑。还有结构性的双重预算:agent 运营方为它的模型调用付费,client 为自己的付费,单次交互总成本可能比任何一边一开始意识到的都高。
多租户变体 — 一个 agent 进程服务多家 client 组织 — 因为分摊固定成本而大幅改善运维经济。它也把跨租户数据泄漏作为头等故障模式带进来。2025 年公开的几起事故就是这个,运营方应该在 runtime 里设计租户化,而不是靠 code review 来抓请求间的泄漏。
8.2 严格 MCP 纯净:模型在 client 里
第二种形态把语言模型严格放在 client 里。MCP server 只暴露数据和工具 — 不做推理。Host 跑模型、做编排决策、调 server 取上下文和执行动作。动机是协议最初的设计逻辑:MCP 是为了通过在模型和工具之间提供一致接口来解决 N 乘 M 集成问题;那些自己跑模型的 server 把协议本来要解决的问题又带了回来。
强项是控制和透明。每一次模型调用都对 client 的仪表盘可观测。Client 按请求挑模型、能跨提供商回退、直接承担所有模型成本 — 没有双重预算因为链上没有第二个模型。对那些审计日志必须在 client 处捕捉到完整推理链的受监管行业,严格纯净没歧义地满足要求。
代价同样清楚。每一份智能都要被每一个 client 重新实现,对有很多 host 应用的组织是实实在在的负担。有些能力 — 多步研究、迭代精修 — 拆成单次调用工具很别扭,暴露这种能力要么把复杂编排推进 client,要么悄悄违反纯净性让 server 跑自己的模型。Client 也得有能力跑编排,实践中就是靠 Strands、LangChain、Semantic Kernel、Microsoft Agent Framework 而不是从头写循环。
8.3 混合:client 侧编排加 server 侧执行
第三种形态走中间。Client 编排、跑主推理;某些 MCP server 跑自己的模型调用做专精子任务。最清楚的例子是长跑型深度研究工具。一个需要把研究结果整合进更大工作流的 client 不想自己管研究的每一步;它想调 "研究 X,告诉我你发现了什么",收到一份综合。研究是多步、多来源的,得益于自己内部的编排。
混合模式在边界画在有意义的接缝上时有效 — 一个有清楚输入输出的子任务,自包含到 server 侧智能能不靠 client 协调完成它,专精到把它当黑盒跑比通过通用编排器跑更好。研究、代码分析、文档综合契合这个画像。一般对话不契合。
代价是架构复杂度。现在智能在两个地方跑,可观测性要跨边界,成本归属位于两种纯模式之间。一个有用的纪律是限制智能 server 的数量,让每一个聚焦在一个良定的能力上。两三个能运维;十二个就变成一个没团队搞得懂的联邦。混合部署也倾向于随时间往任一纯端漂,架构师应该对自己的混合是稳定设计还是过渡态保持诚实。
第 8 章接下去会怎么走
第三部分的三章从机制视角走了多 agent 系统的设计空间。它们还没覆盖的是底下的衬底:每一次模型调用收到的上下文,以及跨调用持续存在的记忆。一个 agent 的有效性取决于它动手时能看到什么、能回忆起它之前做了什么。上下文窗口是有限的。记忆架构得设计。注意力预算管理、scratchpad 使用、情景与语义记忆这一套模式,是把一群协调好的 agent 变成 "一个跨小时、跨天、跨更长时间做有用工作的系统" 的那一层衬底。
明天 — 第 9 章:管理注意力预算。百万 token 窗口为什么是天花板值而不是工作点,什么在吃预算,以及 MCP、RAG、微调各自契合的是哪一种缺口形状。
