第 13 章 — 框架与云集成
LLM Primer IV: Designing AI Cognition with MCP 章节走读的第十三篇。没人从裸协议搭生产 MCP;2025 到 2026 年那个老实的问题变成了 "标准化在哪个框架上";而答案最后取决于框架特性的程度,不如取决于剩下系统住在哪朵云上。
这一章为什么存在
等到一个团队把认证、传输、会话状态、错误重试、结构化日志,加上把 demo 跟一个可运维服务区分开的那十几件小事都接好,本来 "我们就用 HTTP 直接说 MCP" 的东西已经变成了一个自家小框架 — 通常比已有的那几个公开框架更差。工程问题是标准化在哪个公开框架上、它们各自做对了什么、它们怎么跟存状态的云服务衔接。这一章按部就班走这片地:配 Amazon Bedrock 的 Strands;围着它的那些 AWS 状态和检索服务;Microsoft Agent Framework、LangChain、Semantic Kernel 作为其他生产选项;还有参考架构收敛到的集成模式。目的不是加冕赢家,而是描述每个框架到底是干嘛的。
13.1 Strands Agents 和 Amazon Bedrock
Strands 是 AWS 2025 年开源的 agent 框架,现在跑在 Amazon Q、AWS Support 和 AWS Glue 助手里。命名是有意的:Strands 是 模型驱动 的,意思是 "决定下一步做什么" 那个循环是模型自己的工具调用循环,而不是框架在上面套的 planner-graph。框架的工作是让那个循环在生产里可靠 — 处理工具调用、管会话状态、把 MCP server 当成头等工具源接进来(通过 MCPClient)、把所有东西路由经过 Bedrock 的托管模型目录。模型层是可插拔的 — Anthropic API、OpenAI、Ollama、LiteLLM — 但 Bedrock 是默认和审计故事。
多 agent 这件事是 Strands 赢得生产口碑的地方。三种组合模式干净地映射到前面几章的编排形状:Agents-as-Tools(最简单形状,一个 agent 被包成另一个 agent 能调的工具);Swarm(对等带共享工作记忆);Graph(确定性拓扑,模型填每个节点)。生产里这些模式嵌套用。运维税体现在可观测性上,Strands 通过给每次 agent 调用、每次工具调用、每次模型调用都发 OpenTelemetry span 来付这份税 — 这样一个四层组合可以从日志重建,不必每层都仪表化。Bedrock 加上访问边界故事:IAM 控制一个 agent 能调哪些模型;CloudTrail 记录使用。Bedrock Guardrails 在网关层做内容过滤,Knowledge Bases 提供托管检索,AgentCore — AWS 2025 年的那套原语 — 把记忆、身份、运行时这些事正式化,供想要完全托管 runtime 而不是自托管的团队用。
13.2 AWS 作为状态层
一个跑几小时、记得昨天发生什么的 agent 需要比进程更长寿的存储。沉淀到生产的模式:运行时状态(当前会话、任务台账、在飞工具调用)放 DynamoDB,按键快取;物件状态(产出的文档、中间产物)放 S3,用按会话前缀的 key 结构 — 天然给 IAM 边界,又免费拿到版本管理;语义状态(长期记忆、过去对话)放向量库 — 热工作记忆用 OpenSearch Service,冷或归档记忆用更新的 S3 Vectors。S3 跟 DynamoDB 之间的二层分离不是早优化。它让 DynamoDB item 维持在 400 KB 以下、避免每步的读放大,还让每层独立扩。
状态层的选择决定了整个系统的故障模式。一个状态只在进程内存里的 agent 重启就丢光。一个记忆耐久但索引不同步的 agent,会回忆起指向自己再也找不到的文档的引用。生产部署把这些当成不同的一致性合同来处理:DynamoDB 事务保状态原子性、S3 strong-read-after-write 保物件合同、一条索引流水线先把文档发到 S3 再把向量 upsert 进去,这样检索不会指向一个还不存在的东西。安全边界值得同样的小心。AWS 自己的 Strands 指南建议通过 STS 用按会话的凭据,而不是把 runtime 角色复用给操作终端用户数据的工具调用 — AgentCore Identity 把这件事自动化 — 这样在破坏性动作背后那个 AWS 层身份是实际的终端用户,而不是一个共享 agent 角色。在受监管环境里这是唯一可接受的答案。
13.3 Microsoft Agent Framework、LangChain、Semantic Kernel
Microsoft 和开源那一侧的格局沉淀得不一样。Microsoft Agent Framework 2025 年末出现,作为 Semantic Kernel 和 AutoGen 的显式合并 — SK 的 plugin 模型和 .NET 集成,加 AutoGen 的多 agent 模式和 Python 优先的开发体验。MCP 集成通过 MCPStdioTool 和 MCPStreamableHTTPTool 内建;Azure AI Foundry 是托管之家,对应 AWS 世界里的 Bedrock。跟 Strands 的区别性特征是 agent 之间的对话图是一个显式、可重放的对象 — 这对评估极其重要,因为一段失败对话能用改过的 prompt 重跑、逐轮对比。代价是结构比 Strands 强 — 成熟部署里是对的权衡,探索性工作里是错的权衡。
2026 年的 LangChain 跟 2023 年的 LangChain 已经是两种生物。原始的 chain 抽象成了次要;主表面是做编排的 LangGraph 和做可观测性与评估的 LangSmith。强项是广 — 每个模型、数据库、工具好像都有适配器 — 还有 LangSmith 的评估成熟度。从业者老实命名的弱点是表面积:框架的高层抽象在前 90% 的工作上很好,最后 10% 通常是 "把层一层层剥开直到团队懂每一层在做什么" 完成的。预先计划这种过渡的团队出货比对抗抽象的团队更快。Semantic Kernel 仍然是 .NET 团队的框架;[KernelFunction] plugin 模型干净契合 .NET 服务宿主。三个框架里都浮现出一个模式:薄 agent,厚 MCP — 能力住在协议边界后面,框架变成薄代理,同一个 MCP server 在 AWS 上被 Strands、Azure 上被 Microsoft Agent Framework、本地被 LangChain 消费,不需要任何移植工作。这正是协议设计想要的轨迹。
13.4 生产里的集成模式
2025 到 2026 年参考架构沉淀出三种模式。网关 + 状态层模式在模型层前面放一个托管模型网关(Bedrock、AI Foundry、LiteLLM),后面放一个单独的耐久状态层。网关是认证、限流、内容过滤、审计住的地方;状态层是耐久性住的地方。这是生产默认;新部署除非有具体理由,否则应该采用,因为跳过网关直接调模型提供方的团队一个季度内就后悔了。MCP service mesh模式把 MCP server 当微服务,通过一个处理 mTLS、重试、熔断的 mesh 暴露 — 只在规模上(超过十个 server)或要求网络层背书的受监管环境里值得这个代价。全托管模式把 runtime、记忆、身份、工具注册表交给一个云托管 agent 服务(Bedrock AgentCore、Azure AI Foundry Agent Service、Vertex AI Agent Builder);在 agent 不是主产品的内部自动化和 copilot 里赢,在 agent 就是产品、运维杠杆很要紧的团队里输。两种没赢的模式值得作为反例命名:一切都在 LLM 上下文里(agent 的记忆是一段不断长大的 system prompt)和框架当编排器(一个僵硬的 DAG,模型填节点参数)。两种都因为第 9 章走过的原因在生产里死,而行业吸收的教训是:模型变强,框架结构和模型自由之间的对的平衡就再往模型一侧偏一点。
第 13 章接下去会怎么走
框架和云服务让团队不必每次都重写协议栈就能出货基于 MCP 的 agent。它们本身没告诉团队的是,得出的系统是不是真的 能跑 — agent 是不是解决了它该解决的任务、它在负载下怎么表现、性能悬崖在哪、怎么老老实实对比两种竞争架构。第 14 章正面接这个问题:走 MCP-Universe Benchmark、benchmark 发现的两种系统性故障(长上下文退化和未知工具探索),以及吞吐量那一面 — 共享会话池跟每请求一会话之间差不多十倍的差距。
明天 — 第 14 章:基准测试、测试与性能。真 server 上的 MCP-Universe、起作用的长上下文和未知工具缓解、每请求一会话跟共享会话池之间的十倍吞吐差距、以及系列下一步走向哪里。
