Agent开发第35课：LangChain、LangGraph、MCP、Skill、Harness五层架构对比复习

1. 为什么第 35 课要停下来做架构对比

做 Agent 开发的人大概都有过这种体验：前二十课学得挺爽，LangChain 的 Chain 会拼了，Tool 会挂了，Memory 会接了，感觉自己已经能造出一个"智能体"了。结果到了三十几课，突然发现手里的东西越堆越多——一会儿是 LangChain 的 AgentExecutor，一会儿是 LangGraph 的 StateGraph，一会儿又冒出个 MCP 协议要接，再刷两眼社区，满屏都是 Skill、Harness、Deep Agents 这些新词。这时候人是懵的：我到底在学什么？这些东西是同一层的东西吗？还是说它们其实各管一段？

第 35 课安排"架构对比复习"，本质上就是踩一脚刹车。前面三十多课是横向铺开，把 Agent 生态里能碰到的组件几乎都摸了一遍；到了这个节点，如果不做一次纵向的梳理，很容易陷入"工具会用了但不知道什么时候该用哪个"的状态。这种状态在真实项目里是要命的——你可能会用 LangChain 的 AgentExecutor 去硬扛一个本该用 LangGraph 做状态机的复杂流程，也可能在一个只需要单次工具调用的场景里上 MCP 这种重协议，最后把自己绕进去。

所以这一课的核心不是教新东西，而是把已经学过的东西重新摆到一张桌子上，按"层次"和"职责"重新归类。我个人的经验是，Agent 领域最容易让人混乱的地方，恰恰是不同抽象层级的概念被混在一起讲。LangChain 是框架层，LangGraph 是编排层，MCP 是协议层，Skill 是能力封装层，Harness 是运行支撑层——它们不在一个维度上，硬比"哪个好"是没有意义的。

这篇复习我打算按"分层"的思路来写，而不是按"时间顺序"或者"功能列表"。因为分层能解释一个关键问题：为什么这些技术会同时存在，而不是互相替代。理解了这一点，你在选型时就不会再纠结"LangChain 和 LangGraph 哪个强"，而是会问"我这个任务需要状态编排吗，需要跨进程调用吗，需要能力复用吗"。

提示：架构对比复习最容易犯的错，是把不同层的东西放在同一张表里比"优劣"。正确的做法是先分层，再在层内比。

2. 把 Agent 生态拆成五层来看

2.1 框架层：LangChain 解决的是"怎么快速拼出一个 Agent"

LangChain 的定位其实一直很清晰：它是一套"积木"。LLM 调用、Prompt 模板、输出解析、工具定义、记忆存储，这些基础件它都给你封装好了，你按它的接口拼起来，就能跑出一个能调用工具的 Agent。它的价值在于降低起步门槛——你不用自己写 HTTP 请求去调模型，不用自己设计 Tool 的 schema，不用自己实现对话历史的裁剪逻辑。

但 LangChain 的边界也很明显。它的 AgentExecutor 本质上是一个"循环执行器"：模型输出动作，执行工具，把结果塞回去，再让模型输出，直到模型说"我完成了"。这个循环是隐式的，状态藏在执行器内部，你很难在中途插入一个"人工审批"节点，也很难做条件分支。一旦你的业务流程需要"先查 A，根据 A 的结果决定查 B 还是查 C，查完再汇总"，用 AgentExecutor 写出来的代码会变得非常别扭。

我在实际项目里踩过这个坑。早期做一个客服工单分类的 Agent，流程是"读工单 → 判断类型 → 按类型走不同处理 → 汇总回复"。用 LangChain 的 Agent 硬写，最后变成了一堆 if-else 包在 Tool 里面，模型其实只负责了最外层的调度，真正的逻辑全在 Python 代码里。这时候 LangChain 的"智能"其实没发挥多少，反而多了一层不确定的模型调用。

2.2 编排层：LangGraph 把"隐式循环"变成"显式状态机"

LangGraph 要解决的就是上面那个问题。它把 Agent 的执行过程建模成一张图：节点是处理步骤，边是流转条件，整个图共享一个 State。这个 State 是显式的，你可以在任何节点读写它，也可以在图外面观察它。这就意味着"人工审批""条件分支""循环重试""多 Agent 协作"这些在 AgentExecutor 里很难表达的东西，在 LangGraph 里变成了第一等公民。

举个具体的对比。同样是"判断类型后走不同处理"，LangGraph 里就是一个条件边：从"判断"节点出发，根据 State 里的 type 字段，路由到不同的处理节点。代码结构和你脑子里的流程图是一一对应的，可读性和可维护性完全不是一个量级。而且因为 State 是显式的，你可以做 checkpoint——把中间状态存下来，中断后恢复，这对长流程任务特别重要。

但 LangGraph 也不是没有代价。它的抽象层级比 LangChain 高，意味着你要先理解"图""状态""节点""边"这套概念，才能开始写。对于"调个模型查个天气"这种简单任务，上 LangGraph 就是杀鸡用牛刀。我一般的判断标准是：如果流程里出现了"根据上一步结果决定下一步"或者"需要中断恢复"，就上 LangGraph；如果只是"模型自己决定调哪个工具"，LangChain 的 Agent 就够了。

2.3 协议层：MCP 管的是"能力怎么跨进程暴露"

MCP 这个词这两年出现频率极高，但很多人对它的定位是模糊的。简单说，MCP 是一套协议，规定了"一个能力提供方"和"一个能力使用方"之间怎么通信。它的价值不在于让单个 Agent 变强，而在于让能力可以复用——你写好的一个工具服务，通过 MCP 暴露出去，任何支持 MCP 的客户端都能调用，不用为每个框架重写一遍适配层。

这解决的是一个工程问题，不是智能问题。在没有 MCP 之前，你给 LangChain 写的 Tool，想给另一个框架用，基本要重写。MCP 把"工具的定义和调用"标准化了，工具提供方只管实现能力，使用方只管按协议调用，两边解耦。这在多 Agent、多框架混用的场景里价值很大。

但要注意，MCP 是协议层的东西，它不负责编排，也不负责决策。一个 Agent 用不用 MCP，和它聪不聪明没关系。我见过有人把 MCP 当成"更高级的 Agent 框架"来理解，这是典型的层次混淆。MCP 更像是"工具界的 USB 接口"——它规定插头形状，不规定你插上去的是键盘还是鼠标。

2.4 能力封装层：Skill 是把"一套做法"打包成可复用单元

Skill 这个概念在不同语境下含义不太一样，但在 Agent 生态里，它通常指"把完成某类任务所需的知识、工具、流程打包成一个可复用的单元"。比如一个"数据分析 Skill"，可能包含读数据的工具、清洗的步骤、画图的模板、以及一些领域知识。Agent 遇到相关任务时，加载这个 Skill，就相当于临时获得了这方面的能力。

Skill 和 Tool 的区别在于粒度。Tool 是单个动作，Skill 是一套做法。Tool 是"查数据库"，Skill 是"做一份销售周报"。Skill 内部可能调用多个 Tool，也可能包含 Prompt 模板和决策逻辑。它的价值在于把领域经验固化下来，让通用 Agent 能快速具备专业能力，而不用每次从零教起。

这里有个实操心得：Skill 的设计最忌讳"大而全"。我见过有人把整个业务流程塞进一个 Skill，结果这个 Skill 内部逻辑复杂到没法维护，Agent 调用时也经常因为上下文太长而跑偏。好的 Skill 应该是"高内聚、边界清晰"的——它解决一类明确的问题，输入输出定义清楚，内部实现可以复杂，但对外接口要简单。

2.5 运行支撑层：Harness 是让 Agent"跑得稳"的那套基础设施

Harness 这个词直译是"马具"，在 Agent 语境里指的是让 Agent 稳定运行的那套支撑设施。它管的东西包括：上下文怎么管理、工具调用怎么重试、错误怎么处理、并发怎么控制、日志怎么记录、成本怎么统计。这些东西不直接决定 Agent 聪不聪明，但决定了它能不能在生产环境里活下来。

很多人做 Demo 时觉得 Harness 不重要，因为 Demo 里模型调用一次就成功，工具从来不超时。但一上生产，模型会抽风、工具会挂、上下文会爆、并发会打满，这时候没有 Harness 的 Agent 就是一个随时会崩的黑盒。我个人的经验是，Harness 的投入应该和 Agent 的复杂度成正比——越复杂的 Agent，越需要一套靠谱的 Harness 来兜底。

把 Harness 和 Agent 本体分开理解很重要。Agent 本体是"决策逻辑"，Harness 是"运行环境"。同一个 Agent 逻辑，配上不同的 Harness，稳定性和成本可能差好几倍。这也是为什么有些团队会用同一套 Agent 逻辑，但在不同场景下换不同的 Harness 配置。

3. 五层之间的关系：不是替代，是叠加

3.1 一张表看清各层的职责边界

这张表的关键信息是最后一列——每一层都明确"不负责什么"。理解一个技术"不做什么"，往往比理解它"做什么"更重要，因为边界清晰了，你才知道什么时候该引入它，什么时候不该。

3.2 为什么它们会同时存在而不是互相吞并

有人会问：既然 LangGraph 能编排，为什么还要 LangChain？既然 MCP 能标准化工具，为什么还要 Skill？答案在于"关注点分离"。每一层解决的是不同维度的问题，强行合并只会让某一层变得臃肿。

LangChain 如果去做 LangGraph 的事，它的 AgentExecutor 就会变成一个复杂的图引擎，简单场景用起来会变重。LangGraph 如果去做 MCP 的事，它就要处理跨进程通信，这跟它的核心价值（状态编排）没关系。MCP 如果去做 Skill 的事，它就要理解领域知识，而协议层应该保持"无知"——它只管传数据，不管数据是什么意思。

这种分层在软件工程里是常态。就像 Web 开发里有 HTTP 协议、有 Web 框架、有 ORM、有业务逻辑层，它们各管一段，谁也没想着吞并谁。Agent 生态现在正在经历类似的分层过程，第 35 课做这个复习，其实是在帮你建立这种"分层直觉"。

3.3 一个真实项目的分层落地示例

假设你要做一个"自动处理客户邮件"的 Agent。按分层思路，可以这样拆：

• 框架层：用 LangChain 封装模型调用和基础 Tool（读邮件、写草稿、发邮件）。
• 编排层：用 LangGraph 定义流程——读邮件 → 分类 → 按类别走不同处理 → 生成回复 → 人工确认 → 发送。
• 协议层：把"读邮件"和"发邮件"做成 MCP 服务，这样其他 Agent 也能复用。
• 能力封装层：把"处理退款邮件"打包成一个 Skill，包含退款政策知识、相关 Tool、回复模板。
• 运行支撑层：用 Harness 管理上下文长度、工具重试、并发限流、成本统计。

这样拆下来，每一层都只做自己该做的事，改起来也方便。比如要换模型，只动框架层；要改流程，只动编排层；要让别的 Agent 也能读邮件，协议层已经准备好了。

注意：分层不是目的，是手段。如果你的项目很简单，硬套五层只会增加复杂度。分层的价值在于"当复杂度上来时，你知道该往哪加东西"。

4. 选型时最容易踩的三个坑

4.1 坑一：用框架层的思维去解决编排层的问题

这是最常见的坑。表现是：流程一复杂，就往 Tool 里塞逻辑，或者用 Prompt 硬控流程。比如"如果用户问的是退款，就走退款流程；如果是咨询，就走咨询流程"，有人会写一个巨大的 Prompt 让模型自己判断，然后在 Tool 里用 if-else 分流。

这种做法的短期成本低，长期成本极高。因为流程逻辑散落在 Prompt 和 Tool 里，没有统一的地方能看到全貌，改一个分支可能影响另一个分支，测试也很难覆盖。正确的做法是：一旦流程出现分支，就把它提到编排层，用 LangGraph 显式表达。模型只负责"判断类型"这一步，路由交给图来做。

我踩过这个坑之后总结了一个判断标准：如果一段逻辑用自然语言描述超过三句话，或者包含"如果……就……否则……"，它就不应该待在 Prompt 里，应该提到编排层。

4.2 坑二：把 MCP 当成"更高级的 Agent"

MCP 火起来之后，很多人第一反应是"我要用 MCP 做 Agent"。这是层次混淆。MCP 是协议，它不产生智能，也不做决策。一个 Agent 用不用 MCP，取决于它的工具是否需要跨进程、跨框架复用，而不是取决于它想不想变"高级"。

我见过一个项目，单机单进程的小工具，硬要套 MCP，结果多了一层网络通信，调试复杂度翻倍，收益几乎为零。MCP 的价值在"多客户端复用同一套能力"的场景才体现得出来。如果你的工具只给自己用，而且就在同一个进程里，直接函数调用比 MCP 简单得多。

判断要不要上 MCP，问三个问题：这个能力会被多个 Agent 用吗？这些 Agent 可能在不同进程或不同框架里吗？这个能力需要独立部署和升级吗？三个都是"是"，才值得上 MCP。

4.3 坑三：忽视 Harness，Demo 很爽生产很惨

这个坑我在不止一个项目里见过。Demo 阶段模型调用稳定、工具响应快、上下文不超限，一切都很美好。一上生产，模型开始超时、工具开始报错、上下文开始爆、并发开始打满，整个 Agent 变成一个随机崩溃的黑盒。

Harness 要提前设计，不能等出问题再补。至少要覆盖这几块：工具调用的超时和重试策略、上下文长度的监控和裁剪、模型调用的降级方案、并发控制、成本统计、关键路径的日志。这些东西在 Demo 阶段看起来是"过度设计"，但在生产阶段是"救命稻草"。

我的经验是，Harness 的投入应该在项目早期就规划，哪怕先做最简版本。比如先加一个工具调用的超时和重试，先加一个上下文长度的日志，这些成本很低，但能让你在问题出现时快速定位。

5. 复习之后，怎么把这些串成自己的知识体系

5.1 用"问题驱动"代替"技术驱动"来记忆

学完这么多技术，如果按"技术清单"来记，很容易忘，也容易混。更好的方式是按"问题"来记：遇到什么问题，该用哪一层的东西。比如：

• 流程有分支、要中断恢复 → 编排层（LangGraph）
• 工具要跨框架复用 → 协议层（MCP）
• 领域能力要打包 → 能力封装层（Skill）
• 要快速拼一个简单 Agent → 框架层（LangChain）
• 要上生产、要稳定 → 运行支撑层（Harness）

这样记的好处是，你记住的是"映射关系"，而不是"技术名词"。真实项目里你面对的是问题，不是技术清单，问题驱动的方式更贴近实战。

5.2 每个层次至少动手做过一次

光看对比表是不够的，每个层次至少要亲手做过一次，才能建立"手感"。我的建议是：

• 框架层：用 LangChain 写一个能调用两三个工具的 Agent，跑通。
• 编排层：用 LangGraph 写一个带条件分支和人工确认的流程，跑通。
• 协议层：把一个简单工具做成 MCP 服务，用客户端调一次。
• 能力封装层：设计一个 Skill，包含知识、工具、模板，让 Agent 加载后完成任务。
• 运行支撑层：给上面任意一个 Agent 加上超时、重试、日志、成本统计。

每个都做过一次之后，再回头看对比表，感受完全不一样。你会发现之前觉得"差不多"的东西，其实手感和适用场景差很远。

5.3 保持对"新词"的警惕，先问它在哪一层

Agent 领域新词层出不穷，今天 Skill，明天 Harness，后天可能又冒出一个。面对新词，第一反应不应该是"我要学"，而应该是"它在哪一层"。大部分新词要么是已有层次的重新包装，要么是层次之间的新组合。先定位层次，再决定要不要深入，能省下大量时间。

比如"Deep Agents"这个词，拆开看其实是"编排层 + 能力封装层"的组合，强调 Agent 能做多步深度任务。理解了层次，这个词就不神秘了。"Agent Skill"也是类似，本质是能力封装层的东西，只是换了个说法。

这种"先定位层次"的习惯，能让你在信息过载的环境里保持清醒，不会被新词牵着走。

6. 我在复习阶段最想分享的两条经验

第一条是关于"什么时候该停下来复习"。我的经验是，当你开始觉得"工具都会用但不知道怎么选"的时候，就是该复习的时候。这个信号说明你已经积累了足够的素材，但缺少一个组织框架。这时候停下来做一次分层梳理，比继续往前学新东西的收益大得多。第 35 课安排这个复习，时机是合理的。

第二条是关于"对比的正确姿势"。对比不是为了分出高下，而是为了搞清楚"各自适合什么场景"。我见过太多人把架构对比做成"排行榜"，最后除了记住几个名词，什么也没学到。真正有用的对比，是能回答"我遇到 X 问题时该用 Y"这种问题的对比。如果你做完对比，能对每个技术说出"它最适合什么、最不适合什么"，那这次复习就到位了。

最后分享一个小技巧：把这篇复习里的五层结构画成一张自己的图，贴在工位上或者存在笔记里。每次遇到新技术或者新问题，先往这张图上放一放，看看它属于哪一层，和已有的东西是什么关系。坚持一段时间，你会发现自己对 Agent 生态的理解会从"一堆名词"变成"一张网"，选型和排错都会快很多。