有个朋友问了个挺有意思的问题："到底是模型重要，还是架构重要？"

        我当时随口说了一句："这就像问是大脑重要还是四肢重要。"

        说完大家笑了一下，话题也就过去了。但回去后我越想越不对劲——这个类比其实不太准确。因为它把"模型"和"架构"对立起来了，但实际上，它们不是对立关系，而是协同关系。

        真正的类比应该是这样的：模型是大脑，架构是让大脑能够控制四肢的神经系统。

        所以今天想借这个机会，把我每天在用的四个概念——LLM、Agent、MCP、SKILL——系统地梳理一遍。不只是定义它们是什么，更重要的是搞清楚它们之间的关系。

        这不是一篇学术论文，而是一个实践者的思考总结。

一、概念解析：四个角色，各司其职

        先说清楚这四个概念到底是什么。如果你已经有了解，可以快速跳过这一部分。

LLM：大脑

        LLM（Large Language Model，大语言模型），你肯定不陌生。GPT、Claude、通义千问、DeepSeek，这些都是LLM。

        它的核心能力是什么？ 三件事：语义理解、逻辑推理、内容生成。

但LLM有两个根本性的局限：

        1. 知识在训练时就冻结了，它不知道昨天发生了什么

        2. 无法直接和外部世界交互，它不能查数据库，不能发邮件，不能控制任何东西

这就像一个绝顶聪明的人，但他被关在一个房间里，只有一张纸一支笔。 他可以思考，可以推理，可以写文章，但他看不到外面的世界，也做不了任何事。

技术人体对照

所以LLM需要一个"身体"，让它能够感知和行动。这就是Agent存在的意义。

Agent：神经系统

Agent（智能体），是整合LLM、SKILL、MCP、Tool的智能主体。

它做什么？ 四件事：

        1. 组件管理：它知道有哪些SKILL可用，知道怎么调用MCP

        2. 流程控制：它知道第一步做什么，第二步做什么，什么时候可以并行

        3. 异常兜底：当某个SKILL调用失败时，它知道该怎么处理

         4. 记忆能力：它记得之前的对话，记得之前做了什么

打个比方：

        LLM是大脑的决策中枢，Agent就是整个神经系统。它负责把大脑的决策传递到四肢，把四肢的感知反馈给大脑，同时负责协调各个部分的配合。

        没有Agent，LLM只是一个能聊天的模型。有了Agent，LLM就成了能做事的系统。

MCP：运动神经

        MCP（Model Context Protocol，模型上下文协议），这是Anthropic在2024年11月开源的一个标准协议。

        它是什么？简单说，就是AI领域的USB-C接口。

为什么需要MCP？

        在MCP出现之前，如果你想让LLM调用外部工具，你需要为每个工具写一个自定义的适配器。你有10个工具，就要写10个适配器；有100个工具，就要写100个适配器。

        这就是所谓的"N×M问题"：N个LLM，M个工具，需要N×M个适配器。这个数据还挺猛的，我之前看到一个统计，企业平均要耗费30%的开发资源在接口适配上。

MCP的做法是什么？

        它定义了一套标准的接口。工具开发者只需要按MCP的标准来实现，任何支持MCP的LLM/Agent就能直接调用。

        就像USB-C接口一样：设备厂商只需要按USB-C标准来做，任何支持USB-C的设备都能直接连接。

技术人体对照

MCP的核心架构有三个部分：

        • Host（主机）：包含LLM的AI应用（Claude Desktop、IDE、聊天界面）

        • Client（客户端）：Host内部的协议客户端，负责和Server通信

        • Server（服务器）：提供具体工具和数据的服务

MCP定义了三大核心原语：

        1. Resources（资源）：数据源（文件、数据库、API）

        2. Prompts（提示词）：可复用的Prompt模板

        3. Tools（工具）：LLM可以调用的函数

这些概念我后面会详细展开，这里先有个印象就行。

SKILL：肌肉记忆

        SKILL（技能模块），这个概念可能有些人不太熟悉。

        它是什么？SKILL是对Tool的封装。它把Tool的调用逻辑、参数适配、异常处理都封装起来，给LLM提供一个标准化的接口。

为什么需要SKILL？

        我之前做项目时遇到过这个问题。假设你有一个"数据库查询工具"，它的API长这样：

def query_database(sql: str, connection_string: str, timeout: int) -> List[Dict]:
    ...

        如果你让LLM直接调用这个Tool，它需要知道：

                • SQL怎么写

                • connection_string是什么

                • timeout设置多少合适

                • 如果查询失败了怎么办

        这对LLM来说，太复杂了。

SKILL的做法是什么？

         它把这个Tool封装成一个"数据库查询SKILL"：

SKILL: 数据库查询
输入：你想查什么（自然语言描述）
输出：查询结果（结构化数据）

LLM只需要说"查询上个月的销售额"，SKILL内部会自动：

        1. 理解"上个月"是什么时间范围

        2. 生成合适的SQL语句

        3. 调用数据库Tool

        4. 处理可能的异常

        5. 格式化返回结果

这就像肌肉记忆：当你要喝水时，你不需要思考"如何控制手臂的肌肉收缩"，你的身体自动就完成了。SKILL就是让Agent"自动"完成复杂的工具调用。

SKILL的渐进式披露机制（这是Anthropic官方的设计）：

        • Layer 1：Metadata（name + description），Agent启动时就加载，知道这 个SKILL什么时候用

        • Layer 2：完整的SKILL.md指令，Agent判断相关时才加载

        • Layer 3：附加的脚本和参考资料，只在特定场景才加载

        这个设计还挺巧妙的。既保证了Agent知道"有什么SKILL可用"，又不会把所有SKILL的细节都塞进上下文里。

二、关系架构：从底层到顶层

现在说清楚了四个概念，接下来就是重点了：它们之间是什么关系？

最关键的一点是：它们不是并列关系，而是层级关系。

        从底层到顶层，顺序是这样的：

Tool（底层能力）
  ↑
SKILL（封装层）
  ↑
LLM（决策层）
  ↑
Agent（整合层）
  ↑
MCP（连接层，横跨所有层）

        核心原则：下层为上层提供服务，上层整合下层能力。

        之前我也困惑过这个问题。到底是平行的关系，还是层级的关系？用了一段时间后，我的结论是：必须是层级关系，否则系统会乱掉。

        为什么？因为每层解决不同的问题。Tool解决"怎么连"，SKILL解决"怎么做"，LLM解决"做什么"，Agent解决"整体协调"，MCP解决"统一标准"。把它们混在一起，什么都做不好。

LLM如何作为Agent的核心认知引擎

        LLM不是Agent的全部，但它是Agent的核心。

LLM在Agent中的角色是什么？ 决策中枢。

具体怎么做？

        举个实际的例子。用户问："分析一下张三的病历，判断血糖是否异常。"

        Agent把这个任务交给LLM，并告诉它："你可以调用这些SKILL：病历查询SKILL、血糖解析SKILL、报告生成SKILL。"

        LLM的推理过程是这样的：

                1. 理解用户意图：需要分析病历，判断血糖

                2. 决策第一步：先调用"病历查询SKILL"获取数据

                3. 等待结果...

                4. 拿到病历数据，发现血糖值是7.8 mmol/L

                5. 决策第二步：调用"血糖解析SKILL"判断是否异常

                6. 等待结果...

                7. 拿到判断结果：7.8属于异常范围

                8. 决策第三步：调用"报告生成SKILL"生成报告

                9. 整合所有结果，生成最终回复

LLMAgent流程

关键点：LLM不需要知道SKILL内部怎么实现Tool调用，它只需要知道"哪个SKILL能做什么"。SKILL封装了所有细节。

MCP在多Agent系统中的协调与管理作用

        刚才说的是单个Agent内部的工作流程。那如果有多个Agent呢？

多Agent系统的典型场景：

        • 一个电商公司，有"风控Agent"、"推荐Agent"、"客服Agent"

        • 它们需要共享数据（用户信息、商品信息、订单信息）

        • 它们需要协调任务（用户投诉时，可能需要风控、推荐、客服协同）

如果没有MCP：

        • 每个Agent需要自己连接数据源

        • 数据重复存储，容易出现不一致

        • Agent之间没有统一的通信协议

有了MCP之后：

        • 所有数据源通过MCP Server暴露

        • Agent通过MCP协议访问数据

        • Agent之间也可以通过MCP协议通信

MCP多Agent协调

MCP在多Agent系统中的核心价值：

        1. 统一的数据访问：一个MCP Server可以被多个Agent使用

        2. 统一的工具注册：新工具只需要实现MCP协议，所有Agent都能用

        3. 统一的通信协议：Agent之间通过MCP协议通信，不需要自定义协议

        4. 统一的权限管理：MCP协议支持OAuth 2.0，可以细粒度控制权限

类比现实世界：

        MCP就像城市的"政务服务中心"。市民（Agent）需要办理业务时，不需要自己跑各个部门（数据源），只需要到政务服务中心（MCP Server）统一办理。政务服务中心会协调各个部门，完成业务。

SKILL作为Agent能力扩展的模块化组件如何与LLM结合

这个前面已经说了一部分，但这里再深入一点。

SKILL和LLM的协作机制：

        当你给Agent添加一个新的SKILL时，会发生什么？

        Step 1：注册

                Agent把SKILL的Metadata（name + description）保存到SKILL列表中。

        Step 2：发现

                当LLM处理用户任务时，它会先扫描SKILL列表，判断哪些SKILL可能相关。 判断依据是SKILL的description。

        Step 3：加载

                LLM选择了某个SKILL后，Agent会加载这个SKILL的完整指令（SKILL.md）。

        Step 4：调用

                LLM按照SKILL的指令，生成调用参数。Agent执行SKILL，SKILL内部调用 Tool。

        Step 5：反馈

                Tool的执行结果返回给SKILL，SKILL处理后返回给LLM。LLM基于结果继续推 理。\

SKILL的设计哲学：

        • 封装复杂性：Tool的细节对LLM透明

        • 标准化接口：所有SKILL有统一的输入输出格式

        • 组合能力：一个SKILL可以组合多个Tool

        • 错误处理：SKILL内部处理异常，LLM不需要关心

四者协同工作的典型流程与数据流向

现在把所有内容串起来，看一个完整的协同流程。

场景：智能助手帮助用户"预订周末亲子游"

参与者：

        • LLM（认知引擎）

        • Agent（整合者）

        • SKILL（工具封装：酒店预订SKILL、门票购买SKILL、路线规划SKILL）

        • MCP（连接器：酒店API、门票API、地图API）

        • Tool（外部接口：酒店预订API、门票购买API、地图API）

智能预订流程

完整流程：

        1. 用户发出请求

用户："帮我订这个周末的亲子游，主题乐园+亲子酒店。"

        2. Agent接收任务

Agent把请求传递给LLM，并告知可用的SKILL列表。

        3. LLM推理并决策

LLM分析："需要预定酒店、购买门票、规划路线。"

LLM决策："先调用酒店预订SKILL。"

        4. Agent执行SKILL

Agent加载"酒店预订SKILL"的完整指令，传递给LLM。

        5. LLM生成SKILL调用参数

LLM基于SKILL指令和用户需求，生成参数：

• 时间：这个周末（LLM需要计算具体日期）

• 地点：主题乐园附近

• 房型：亲子房

• 数量：1间

        6. SKILL调用MCP

SKILL内部通过MCP协议，调用"酒店预订MCP Server"。

        7. MCP调用Tool

MCP Server把请求转发给"酒店预订API"（Tool）。

        8. Tool执行并返回结果

酒店预订API返回：预订成功，订单号12345，酒店名称XXX。

        9. 结果逐层返回

Tool → MCP → SKILL → Agent → LLM

        10. LLM继续推理

LLM拿到酒店预订结果，继续决策："下一步调用门票购买SKILL。"

        11-15. 重复上述流程

预订门票、规划路线...

        16. LLM整合所有结果

LLM把酒店预订、门票购买、路线规划的结果整合，生成最终回复：

"已经帮您完成了预订：

• 酒店：XXX亲子酒店，订单号12345

        • 门票：主题乐园家庭套票，订单号67890

        • 路线：已规划好，预计车程1小时

祝您周末愉快！"

        17. Agent响应用户

Agent把LLM的回复返回给用户。

关键点：

• 整个过程中，LLM只做决策，不直接调用Tool

• SKILL封装了Tool的调用细节

• MCP提供了统一的接口，让SKILL可以方便地调用各种Tool

• Agent负责整体协调，管理SKILL列表和上下文

三、技术案例：两个实际场景

案例一：智能编程助手

场景描述：

        一个智能编程助手，能够：

• 阅读代码并理解功能

• 发现bug并提出修复建议

• 根据需求自动生成代码

• 运行测试并验证结果

架构设计：

MCP架构分层图

组件拆解：

        LLM：负责理解代码、生成代码、推理bug原因

        Agent：管理整个开发流程，协调各个步骤

        SKILL：

• "代码阅读SKILL"：封装文件读取、语法解析

• "Bug分析SKILL"：封装静态分析工具

• "代码生成SKILL"：封装代码生成策略

• "测试运行SKILL"：封装测试框架

        MCP：

• "文件系统MCP Server"：访问项目文件

• "Git MCP Server"：访问版本控制

• "测试框架MCP Server"：运行测试

        Tool：

• 文件系统API

• Git API

• 测试框架API

典型流程：

用户："帮我分析这个项目的代码，找出潜在的bug。"

        1. Agent接收任务，交给LLM

        2. LLM决策："先调用代码阅读SKILL，了解项目结构"

        3. Agent执行代码阅读SKILL → MCP → 文件系统API → 返回代码

        4. LLM拿到代码，继续决策："调用Bug分析SKILL"

        5. Agent执行Bug分析SKILL → MCP → 静态分析工具 → 返回bug列表

        6. LLM分析bug，继续决策："调用代码生成SKILL，生成修复代码"

        7. Agent执行代码生成SKILL → LLM生成修复代码 → MCP → Git API → 提交patch

        8. LLM决策："调用测试运行SKILL，验证修复"

        9. Agent执行测试运行SKILL → MCP → 测试框架 → 返回测试结果

        10. LLM整合结果，生成最终回复

这个案例展示了什么？

        • LLM负责"理解"和"决策"

        • SKILL封装了开发流程的各个步骤

        • MCP提供了统一的工具访问接口

        • Agent协调整个流程，从代码阅读到bug修复

案例二：金融风控系统

场景描述：

一个金融风控系统，需要：

• 实时监控交易行为

• 自动识别可疑交易

• 触发风控规则

• 生成风控报告

架构设计：

金融风控Agent协作

多Agent协作：

        • "交易监控Agent"：实时监控交易流

        • "规则引擎Agent"：应用风控规则

        • "风险评估Agent"：评估风险等级

        • "报告生成Agent"：生成风控报告

组件拆解：

        LLM：负责理解风险模式、推理规则适用性

        Agent：每个Agent有自己的LLM实例，负责各自的决策

        SKILL：

• "交易监控SKILL"：封装流式数据处理

• "规则应用SKILL"：封装规则引擎

• "风险评估SKILL"：封装风险评分模型

• "报告生成SKILL"：封装报告模板

        MCP：

• "交易数据MCP Server"：访问交易流

• "规则库MCP Server"：访问风控规则

• "风险数据库MCP Server"：读写风控记录

        Tool：

• 交易流API

• 规则引擎API

• 数据库API

典型流程：

        一笔可疑交易发生：

1. "交易监控Agent"检测到异常交易

2. LLM推理："金额异常、地域异常、时间异常，需要触发风控"

3. Agent决策："调用规则应用SKILL"

4. SKILL通过MCP访问规则库，匹配风控规则

5. 匹配到3条高风险规则

6. LLM推理："需要进一步评估风险等级"

7. Agent决策："调用风险评估SKILL"

8. SKILL通过MCP访问风险模型，计算风险评分

9. 风险评分95分，属于极高风险

10. LLM推理："需要冻结交易并生成报告"

11. Agent协调"报告生成Agent"和"规则引擎Agent"：

▪ 规则引擎Agent执行冻结操作

▪ 报告生成Agent生成风控报告

12. 所有Agent通过MCP共享数据，确保信息一致

这个案例展示了什么？

        • 多Agent协作，每个Agent负责不同的职责

        • MCP作为统一的协调层，管理数据共享

        • SKILL封装了风控流程的各个步骤

        • LLM负责智能决策，不是简单的规则匹配

四、发展趋势与挑战

发展趋势

趋势一：从"单一智能体"到"智能体生态"

        现在大家都在谈Agent，但我觉得真正的趋势不是单个Agent有多强，而是Agent生态。

        就像软件生态一样：

• 不是比谁的应用最多

• 而是比谁的生态最丰富、最开放、最有活力

        未来的Agent生态可能是这样的：

• 市场上有成千上万的SKILL可供选择

• 你可以像组装乐高一样，把不同的SKILL组合成你需要的Agent

• MCP成为SKILL的标准化协议，任何SKILL都可以在任何Agent中使 用

        这其实已经在发生了。MCP开源才几个月，就已经有200+预置的MCP Server。这个增长速度比我想象的快多了。

趋势二：从"人工设计"到"自动发现"

现在SKILL都是人写的。但未来呢？

        学术界已经在研究"自动技能发现"（Automatic Skill Discovery）。基本思路是这样的：

                • Agent在解决问题的过程中，会尝试调用不同的Tool

                • 如果某个调用序列成功了，Agent会把它固化成一个SKILL

                • 下次遇到类似问题，直接调用这个SKILL，而不是重新推理

        这就像人类学习的过程：

                • 第一次做某件事，需要仔细思考每一步

                • 成功后，这件事就成了"技能"

                • 下次再做，不需要思考，直接调用这个技能

趋势三：从"通用智能"到"垂直专家"

        现在大家都在追求"通用智能"（AGI）。但我觉得，在商业应用中，"垂直专家"可能更有价值。

        一个财务分析Agent，可能比通用的LLM更懂财报；

        一个医疗诊断Agent，可能比通用的LLM更懂病历；

        一个法律咨询Agent，可能比通用的LLM更懂法规。

        这些垂直Agent的核心是什么？不是更大的模型，而是更专业的SKILL。

趋势四：从"单模型"到"多模型"

        现在的Agent通常只用一个LLM。但未来可能是多模型协同：

                • 复杂的推理任务用Opus

                • 简单的问答用Haiku

                • 代码生成用专门的Code LLM

                • 数学计算用专门的Math LLM

        Agent会根据任务类型，自动选择最合适的模型。

MCP协议已经支持这种"采样"能力：MCP Server可以主动请求LLM进行推理。

面临的挑战

挑战一：系统复杂性

        当你的系统有几十个Agent、几百个SKILL、上千个Tool时，复杂性会爆炸。

        你面临的问题是：

                • 如何保证系统的稳定性？

                • 如何调试和排查问题？

                • 如何监控系统的性能？

                • 如何管理版本和升级？

        这不是技术问题，而是工程问题。

挑战二：SKILL标准化

        现在SKILL还没有统一的标准。每个团队都有自己的SKILL格式、命名规范、组织方式。

这会导致什么问题？

        • SKILL无法跨系统复用

        • 社区无法共享SKILL

        • 开发者需要反复造轮子

未来可能需要一个"SKILL标准"，定义SKILL的格式、接口、元数据规范。

挑战三：安全和隐私

Agent可以调用Tool，Tool可以访问数据。这意味着什么？Agent有能力做"坏事"。

比如：

        • 恶意SKILL可能窃取用户数据

        • Agent可能被诱导执行危险操作

        • 多Agent协作可能导致权限冲突

MCP协议已经考虑了这些问题：

        • 用户同意和授权

        • 细粒度的权限控制

        • 完整的审计日志

但这只是第一步。真正的挑战在于：

        • 如何设计安全的SKILL？

        • 如何验证SKILL的可靠性？

        • 如何防止Agent的滥用？

挑战四：性能和成本

Agent系统天然是复杂的：

        • LLM推理需要时间

        • MCP通信有延迟

        • Tool执行有开销

        • 多Agent协作会乘数放大这些延迟

如何优化性能？

        • 缓存：缓存LLM的推理结果、Tool的执行结果

        • 并行：可以并行的任务尽量并行执行

        • 批处理：把多个小任务合并成一个大任务

        • 模型选择：简单任务用小模型，复杂任务用大模型

成本也是一个问题：

        • LLM的Token消耗

        • MCP Server的运行成本

        • Tool调用的资源消耗

如何控制成本？

        • 精简Prompt，减少Token消耗

        • 选择性价比高的模型

        • 优化SKILL设计，减少不必要的Tool调用

挑战五：可解释性

当Agent做出一个决策时，你能不能解释它为什么这么做？

比如：

        • Agent拒绝了某笔交易，为什么？

        • Agent选择了这个SKILL而不是那个，为什么？

        • Agent给出了这个建议，理由是什么？

现在这些问题很难回答，因为LLM的决策过程是不透明的。

未来的方向可能是：

        • 显式化LLM的推理过程（Chain of Thought）

        • 记录Agent的决策历史

        • 提供调试和审计工具

五、最后的话

        写到这里，我想回到开头那个问题："到底是模型重要，还是架构重要？"

现在我的答案更清晰了：

模型是基础，架构是放大器。

没有模型，架构再好也跑不起来。但没有架构，模型的能力无法发挥。

就像一个人：

        • 大脑（LLM）是基础，没有大脑什么都做不了

        • 神经系统（Agent）是放大器，它让大脑能够控制四肢

        • 运动神经（MCP）是连接器，它让四肢能够响应大脑的指令

        • 肌肉记忆（SKILL）是效率提升器，它让动作变得自动化

四者缺一不可，它们共同构成了一个完整的智能体系统。

这也是为什么我看好Agent这个方向。

不是因为模型变大了，而是因为架构变得更聪明了。

LLM给了我们"智能"，而Agent把"智能"变成了"能力"。

未来十年，最重要的不是"更大的模型"，而是"更聪明的架构"。