Agent架构选型指南：LangChain、LangGraph、Skills、MCP与Harness分层对比

1. 为什么要在第35课做一次架构对比复习

走到Agent学习系列的第35课，其实已经过了“能跑通一个Demo就兴奋半天”的阶段了。这个阶段最大的问题不是不会写代码，而是脑子里塞了太多名词：LangChain、LangGraph、Skills、MCP、Harness，每一个单独拎出来都能讲半小时，但真到要动手搭一个能上线的Agent系统时，反而不知道该把哪个放在哪一层。我自己就经历过这个阶段，手里同时开着四五个项目，每个用的架构都不一样，结果维护起来一团乱麻，改一个工具调用逻辑要在三个地方同步改。

所以这一课的核心目的很明确：把目前主流的Agent架构模式拉到一个平面上，横向对比它们的定位、边界和适用场景，搞清楚什么情况下该用LangChain的Chain，什么情况下必须上LangGraph的状态机，Skills到底解决的是哪一层的问题，MCP在整个链路里扮演什么角色，以及Harness这种偏工程化的概念到底值不值得投入时间学。

这篇文章适合已经写过至少一个能跑的Agent Demo、但对架构选型还比较模糊的开发者。如果你还在纠结“Agent是什么”或者“怎么调API”，建议先补前面的基础课。但如果你已经能写出一个带工具调用的Agent，只是不确定下一步该往哪个方向深入，那这篇对比复习应该能帮你省下不少试错时间。

我个人的判断是：Agent开发正在从“框架驱动”转向“架构驱动”。早期大家比的是谁用的框架新，现在比的是谁能把不同层的东西组合得最合理。LangChain、LangGraph、Skills、MCP、Harness这五个概念，其实分别对应了Agent系统的不同层次，把它们的关系理清楚，比单纯学某一个框架的API重要得多。

2. 五个核心概念的分层定位

2.1 先搞清楚每个概念到底解决什么问题

在展开对比之前，有必要先把这五个概念各自的核心职责说清楚。我见过太多人把MCP和LangChain混为一谈，或者以为Skills就是LangGraph的替代品，这种认知偏差会直接导致架构设计出问题。

LangChain本质上是一个LLM应用开发的“标准库集合”。它提供的是最基础的抽象：Prompt模板、LLM封装、输出解析器、工具定义、记忆组件。你可以把它理解成Agent开发的“螺丝刀套装”，什么都有，但需要你自己组装。它的优势是生态成熟、文档多、社区大，缺点是抽象层次偏低，复杂流程写起来容易变成“回调地狱”。

LangGraph是在LangChain基础上发展出来的状态图编排框架。它把Agent的执行流程建模成一张有向图，节点是计算步骤，边是状态转移条件。这个抽象层次比LangChain高一层，解决的是“多步骤、有分支、需要循环”的复杂Agent流程编排问题。我个人的经验是：单轮工具调用用LangChain就够了，但一旦涉及多轮反思、条件分支、人工介入，LangGraph的优势就非常明显。

Skills这个概念最近被Claude带火了，但它的本质其实很朴素：把特定领域的知识和操作封装成可复用的能力单元。一个Skill可以是一段Prompt、一组工具定义、一套处理流程，甚至是一个完整的子Agent。它的核心价值在于“可组合性”和“可发现性”——让Agent能够根据当前任务动态加载所需的能力，而不是把所有工具都塞进上下文里。

MCP（Model Context Protocol）解决的是另一个维度的问题：标准化Agent与外部资源之间的通信协议。在没有MCP之前，每个工具集成都要写一套适配代码；有了MCP之后，只要外部服务实现了MCP Server，任何支持MCP的Agent都能直接调用。它相当于给Agent世界定了一个“USB接口标准”，让工具和Agent之间的连接变得即插即用。

Harness这个词在Agent语境下有点特殊。它原本是测试领域的概念，指的是“测试夹具”——包裹被测对象的外壳。在Agent开发中，Harness通常指代的是Agent的运行环境和工程化封装层，包括：执行循环、错误处理、日志追踪、状态持久化、并发控制、安全沙箱等。如果说LangGraph是Agent的“大脑”，那Harness就是Agent的“身体”——负责让大脑的决策能够稳定、安全、可观测地执行。

2.2 一张表看清五者的层次关系

这张表是我自己在做架构选型时经常拿出来对照的。关键是要理解：这五个概念不是互斥的，而是可以叠加使用的。一个生产级的Agent系统，很可能同时用到LangGraph做流程编排、Skills做能力封装、MCP做工具连接、Harness做工程保障，而LangChain作为底层组件库贯穿其中。

2.3 为什么容易混淆：抽象层次错位的典型表现

最常见的混淆是把LangChain和LangGraph当成竞品。实际上LangGraph是构建在LangChain之上的，它复用了LangChain的LLM封装和工具定义，只是在上层增加了图编排能力。我见过有人为了“用LangGraph”而把原本简单的Chain逻辑硬改成图结构，结果代码量翻了三倍，可维护性反而下降。

另一个常见误区是把MCP当成Agent框架。MCP只是一个协议，它不负责决策、不负责编排、不负责执行。你可以把MCP理解成“工具调用的HTTP协议”，它让工具提供方和工具使用方解耦，但Agent的核心逻辑仍然需要LangGraph或类似框架来编排。

Skills和Harness的混淆则更多出现在工程实践中。Skills关注的是“Agent能做什么”，Harness关注的是“Agent怎么稳定地做”。一个Skill可以在不同的Harness中运行，一个Harness也可以加载不同的Skills。它们的关系更像是“插件”和“运行时”的关系。

3. LangChain与LangGraph的选型边界

3.1 LangChain的适用场景与隐性成本

LangChain最大的优势是上手快。定义工具、绑定LLM、创建AgentExecutor，三行代码就能跑起来一个带工具调用的Agent。对于验证想法、做Demo、写教程来说，它几乎是最优选择。

但LangChain的隐性成本在于：当流程变复杂时，它的抽象会开始“漏水”。比如你想在工具调用失败后重试三次，然后根据重试结果决定是继续还是回退到上一步，这种逻辑用LangChain的AgentExecutor写起来就非常别扭。你需要自定义Callback、重写AgentExecutor的_should_continue方法，甚至直接操作中间步骤的返回结果。代码会变得非常“框架特定”，换一个框架就要重写。

我自己的经验法则是：如果Agent的执行流程可以用“LLM决策→调用工具→返回结果→LLM再决策”这个循环完全描述，且循环次数不超过3次，用LangChain就够了。一旦出现“根据工具返回的不同结果走不同分支”或者“需要人工确认后再继续”这类需求，就应该考虑LangGraph。

3.2 LangGraph的状态图模型到底强在哪

LangGraph的核心抽象是StateGraph。你定义一个状态结构（通常是一个TypedDict），然后添加节点（函数）和边（条件转移），最后编译成一个可执行图。这个模型最强大的地方在于：它把Agent的执行流程显式化了。

显式化的好处有三个。第一是可调试性：你可以清楚地看到当前执行到哪个节点、状态是什么、下一步会走哪条边。第二是可干预性：你可以在任意节点之间插入人工审核节点，或者设置断点。第三是可恢复性：配合Checkpointer，你可以把图的状态持久化，实现断点续跑。

我做过一个对比实验：同一个多轮反思Agent，用LangChain的AgentExecutor实现，代码大约120行，但调试时很难定位问题出在哪一轮；用LangGraph实现，代码大约180行，但每个节点的输入输出都清晰可见，加日志和断点非常方便。多出来的60行代码换来的是可维护性的质变。

3.3 混合使用：LangChain做组件，LangGraph做编排

实际项目中，我很少二选一，而是混合使用。LangChain提供LLM封装、工具定义、输出解析这些基础组件，LangGraph负责把这些组件编排成有状态的执行流程。这样既享受了LangChain生态的便利，又获得了LangGraph的流程控制能力。

具体做法是：用LangChain的@tool装饰器定义工具，用ChatOpenAI或类似类封装LLM，然后在LangGraph的节点函数中调用这些组件。状态结构用TypedDict定义，包含消息历史、中间结果、控制标志等字段。条件边根据状态中的标志决定下一步走向。

这种混合模式的一个关键点是：不要把LangChain的AgentExecutor嵌套在LangGraph节点里。那样做会引入两层执行循环，导致状态管理混乱。正确的做法是在LangGraph节点中直接调用LLM和工具，把决策逻辑放在图的边条件中。

4. Skills与MCP：能力封装与协议标准化

4.1 Skills的本质：可发现、可组合的能力单元

Skills这个概念被Claude的Agent Skills功能带火之后，很多人以为是什么新技术。其实它的核心思想很朴素：把Agent需要的能力封装成独立的、自描述的模块，让Agent能够根据任务动态发现和加载。

一个典型的Skill包含三部分：元数据（名称、描述、触发条件）、指令（告诉LLM如何使用这个Skill）、资源（工具定义、参考文档、示例）。当Agent启动时，它不需要把所有Skill都加载到上下文中，而是先加载元数据列表，根据当前任务匹配到相关Skill后再加载完整内容。

这种设计解决了一个很实际的问题：上下文窗口是有限的。如果你有50个工具，全部塞进System Prompt会占用大量Token，而且会干扰LLM的决策。用Skills的方式，Agent可以先“看到”50个能力的简要描述，然后只加载当前需要的3-5个，上下文利用率大幅提升。

我实测下来，Skills模式在工具数量超过20个时优势非常明显。工具数量少的时候，直接全量加载反而更简单直接。所以是否引入Skills，取决于你的Agent需要管理多少能力。

4.2 MCP协议：让工具集成不再重复造轮子

MCP要解决的问题更底层：Agent和工具之间的通信标准化。在没有MCP之前，每接入一个新工具，就要写一套适配代码：定义输入Schema、处理认证、解析返回结果、处理错误。如果同一个工具要被多个Agent使用，这套适配代码就要重复写多遍。

MCP的做法是：工具提供方实现一个MCP Server，暴露标准化的接口；Agent侧实现一个MCP Client，通过标准协议与Server通信。这样工具只需要实现一次MCP Server，任何支持MCP的Agent都能直接使用。

从架构角度看，MCP把“工具集成”从Agent代码中剥离出来了。Agent不再关心工具的具体实现，只关心工具的能力描述和调用接口。这带来的好处是：工具可以独立部署、独立升级、独立扩缩容，Agent和工具之间实现了真正的解耦。

但MCP也不是银弹。它的主要开销在于：需要维护MCP Server的生命周期，增加了网络通信环节，对于简单的本地工具来说可能过度设计。我的建议是：如果工具需要跨Agent复用、或者工具本身是独立服务，用MCP；如果只是Agent内部的简单函数调用，直接用LangChain的tool装饰器更轻量。

4.3 Skills和MCP的配合方式

Skills和MCP不是竞争关系，而是互补关系。Skills解决的是“Agent知道有哪些能力可用”，MCP解决的是“Agent如何调用这些能力”。一个Skill可以引用多个MCP工具，一个MCP工具也可以被多个Skill使用。

实际架构中，我通常这样组织：Skill的元数据中声明它依赖哪些MCP工具，当Agent加载Skill时，同时建立对应的MCP连接。Skill的指令部分告诉LLM在什么情况下使用这些工具、如何组合调用。这样既保持了能力的可发现性，又保持了工具调用的标准化。

需要注意的是，MCP连接是有状态的，建立和断开都需要时间。如果每次加载Skill都重新建立MCP连接，延迟会很高。实践中我会维护一个MCP连接池，Skill加载时从池中获取已有连接，Skill卸载时不立即断开，而是保留一段时间以备复用。

5. Harness：被低估的工程化层

5.1 Harness到底包含什么

Harness这个词在Agent社区里用法比较混乱，有人用它指代Agent的执行循环，有人用它指代整个运行环境。我倾向于把它定义为：Agent核心逻辑之外的所有工程化支撑代码。具体包括：

• 执行循环：驱动Agent一步步执行的主循环，处理LLM调用、工具执行、结果回传
• 错误处理：LLM调用失败重试、工具执行异常捕获、超时控制、降级策略
• 状态管理：对话历史持久化、中间状态存储、断点恢复
• 可观测性：日志记录、链路追踪、Token消耗统计、性能指标采集
• 安全控制：输入输出过滤、工具调用权限控制、资源限制、沙箱隔离
• 并发处理：多请求并行、限流、队列管理

这些内容在Demo阶段经常被忽略，但到了生产环境，每一个都是必须解决的。我见过太多Agent在本地跑得好好的，一上线就各种问题：并发一高就崩溃、LLM超时没有重试、工具调用失败导致整个流程卡死、出了问题查不到日志。

5.2 为什么Harness值得单独投入

很多开发者把Harness当成“基础设施”，觉得随便写写就行，重点应该放在Agent的智能逻辑上。但我的实际经验恰恰相反：Agent的智能逻辑决定了上限，Harness决定了能不能稳定达到这个上限。

一个具体的例子：我做过一个客服Agent，核心逻辑就是意图识别加知识库检索加回复生成，用LangGraph编排大概200行代码。但为了让它在生产环境稳定运行，Harness部分写了将近800行：包括LLM调用的指数退避重试、工具调用的超时熔断、对话状态的Redis持久化、每次调用的Token和延迟埋点、敏感词过滤、并发限流。没有这800行，那200行的核心逻辑根本跑不稳。

另一个容易被低估的点是Harness对调试效率的影响。好的Harness会记录每一步的输入输出、耗时、Token消耗，出问题时能快速定位是LLM决策错了、工具返回错了、还是状态传递错了。没有这些记录，调试Agent就像盲人摸象。

5.3 自建Harness还是用现成方案

目前市面上有一些Agent工程化框架，比如LangSmith提供追踪和评估，LangServe提供部署能力。但这些方案通常和特定框架绑定，如果你用的是LangGraph，LangSmith集成得很好；如果你用的是自研框架，就需要自己搭。

我的建议是：早期用现成方案快速起步，但核心的Harness逻辑要掌握在自己手里。具体来说，可观测性可以用LangSmith或类似服务，但执行循环、错误处理、状态管理这些核心逻辑建议自己实现。原因很简单：这些逻辑和你的业务场景强相关，通用方案很难完全匹配。

自建Harness的起点可以很低：一个带重试的LLM调用封装、一个带超时的工具执行器、一个基于Redis的状态存储、一个结构化日志记录器。这四样东西加起来可能不到300行代码，但能解决80%的工程问题。

6. 常见架构组合与选型建议

6.1 四种典型架构组合

根据项目复杂度和团队情况，我总结出四种常见的架构组合：

组合A：LangChain单框架

• 适用：原型验证、简单单轮Agent、个人项目
• 优点：上手最快，代码量最少
• 缺点：复杂流程难维护，工程化能力弱

组合B：LangChain + LangGraph

• 适用：多步骤Agent、需要流程控制的场景
• 优点：流程显式化，可调试可干预
• 缺点：学习曲线较陡，简单场景过度设计

组合C：LangGraph + Skills + MCP

• 适用：多领域Agent、工具生态丰富的场景
• 优点：能力可发现可组合，工具集成标准化
• 缺点：架构复杂度高，需要维护MCP Server

组合D：全栈方案（上述全部 + 自建Harness）

• 适用：生产环境、高并发、多租户
• 优点：稳定可控，可观测性强
• 缺点：开发成本高，需要工程能力支撑

6.2 选型决策树

我通常用下面这个决策流程来选型：

1. 先问：Agent需要多轮决策吗？不需要→LangChain单框架；需要→进入下一步
2. 再问：流程中有条件分支或人工介入吗？没有→LangChain + 简单循环；有→LangGraph
3. 再问：工具数量超过15个吗？没超过→直接定义工具；超过→引入Skills
4. 再问：工具需要跨Agent复用吗？不需要→本地工具；需要→MCP
5. 最后问：要上生产环境吗？不上→到此为止；上→加Harness

这个决策树不是绝对的，但能帮你快速定位到合适的起点。关键是不要过度设计：一个简单的问答Agent不需要LangGraph，一个内部工具不需要MCP，一个日活个位数的应用不需要复杂的Harness。

6.3 从简单到复杂的演进路径

我建议的演进路径是：先用LangChain跑通核心逻辑，验证Agent的智能水平是否达标。达标后，如果流程复杂就引入LangGraph，如果工具多就引入Skills，如果需要跨系统就引入MCP，最后上生产前补齐Harness。

这个顺序的好处是：每一步都解决当前最痛的问题，而不是一开始就搭一个大而全的架构。我见过太多项目一开始就上全套架构，结果核心逻辑还没跑通，就被工程复杂度拖垮了。

7. 实操中的踩坑记录与排查技巧

7.1 LangGraph状态管理的三个坑

第一个坑是状态可变性。LangGraph的节点函数返回的状态更新默认是合并到现有状态的，但如果你在节点中直接修改了状态对象的可变字段（比如往列表里append），可能会导致意外的状态污染。我的做法是：节点函数中始终返回新的状态片段，不直接修改传入的状态。

第二个坑是条件边的返回值。条件边函数必须返回一个明确的节点名称或节点名称列表，返回None或未定义的节点名会导致运行时错误。我习惯在条件边函数中加一个默认分支，确保任何情况下都有明确的下一步。

第三个坑是Checkpointer的序列化。如果你用Redis或Postgres做Checkpointer，状态中的自定义对象需要可序列化。我遇到过把LLM的Response对象直接放进状态导致序列化失败的情况，解决方案是只存必要的字段，或者自定义序列化器。

7.2 MCP集成的常见问题

MCP Server启动失败是最常见的问题。排查顺序是：先确认Server进程是否正常启动，再确认端口是否可访问，再确认协议版本是否匹配。我遇到过Server启动了但Agent连不上的情况，最后发现是Server绑定的是localhost而Agent在容器中访问不到。

另一个问题是工具描述不清晰导致LLM调用错误。MCP工具的输入Schema需要写得非常明确，包括每个参数的类型、是否必填、示例值。我习惯在Schema的description中写清楚“什么时候用这个工具”和“参数格式示例”，这样LLM的调用准确率会高很多。

7.3 Harness层的排查速查表

这张表是我在实际运维中慢慢积累的，每次遇到新问题就加一行。建议你也维护一份自己的排查表，比临时翻文档高效得多。

7.4 几个反直觉的经验

第一个反直觉经验：LLM调用重试不一定能提高成功率。对于某些类型的错误（比如内容过滤、参数错误），重试只会浪费Token。我的做法是区分错误类型：网络超时和限流错误重试，内容错误和参数错误直接失败。

第二个反直觉经验：工具调用并行化不一定更快。如果多个工具调用之间有依赖关系，或者LLM的决策依赖于前一个工具的结果，强行并行会导致逻辑错误。只有确认独立的工具调用才适合并行。

第三个反直觉经验：更长的上下文不一定更好。我做过对比实验，把完整对话历史传给LLM和只传最近5轮加摘要，后者的决策准确率反而更高。原因是过长的上下文会引入噪声，干扰LLM的注意力。所以上下文裁剪不是妥协，而是优化。

8. 后续深入方向与个人建议

架构对比复习到这个程度，基本能覆盖大部分Agent项目的选型需求了。如果还要继续深入，我建议从两个方向切入：一是Harness的工程化实践，包括高并发下的状态管理、分布式追踪、成本控制；二是Agent的评估体系，包括如何量化Agent的决策质量、如何做A/B测试、如何建立回归测试集。

这两个方向都比学一个新框架更有长期价值。框架会过时，但工程能力和评估方法论是通用的。我自己最近在花时间研究的是Agent的并发架构，特别是多租户场景下如何隔离状态、如何做资源配额、如何保证公平调度。这块的实践资料还比较少，等有成熟经验了再单独写一篇。

最后分享一个我自己的习惯：每学一个新概念，就把它放到已有的架构分层图中，问自己“它解决的是哪一层的问题”。如果放不进去，说明要么这个概念是伪需求，要么我的分层模型需要更新。这个习惯帮我避免了很多“为了用而用”的无效学习。架构对比复习的价值不在于记住每个框架的API，而在于建立起自己的分层判断力，遇到新东西时能快速定位它的位置和价值。