AI Agent开发必懂：Skill、MCP、子Agent的区别与组合

最近很多人在群里聊 AI Agent 开发时都会遇到一个共同的困惑今天看文档说要给 Claude 写一个 Skill明天看到某个项目在提 MCP Server 的配置后天又听人说复杂任务要拆成子 Agent 去跑。这三个词听起来都跟“让模型更聪明”有关但真到自己动手的时候却完全不知道先做哪个、怎么做、边界在哪里。我见过不少人一开始就把 Skill 当成 MCP 的替代品也有人把子 Agent 理解成“更高级的 Skill”。结果就是花了很长时间去写一个 Skill发现根本调不到外部数据或者辛辛苦苦搭好 MCP Server却发现模型只是多了一个工具并没有真正学会一套完整的做事流程。这篇文章想把三者之间的关系彻底讲清楚。先说结论Skill、MCP、子 Agent 不是同一个赛道上的三个选手而是 AI Agent 系统里三个不同层级的组件。Skill 解决的是“模型会不会做这件事”MCP 解决的是“模型能不能连到外部世界”子 Agent 解决的是“这件事要不要拆出去单独做”。三者可以独立存在也可以在真实项目里组合使用。搞清楚它们的定位比你多写十个 Skill 都重要。1. 为什么这三个概念会让你分不清Skill、MCP、子 Agent 被混为一谈不能全怪开发者。这几个词在传播过程中都经历过“定义漂移”模型厂商、开源项目、技术博主各说各话同一个词在不同文章里指的东西可能完全不一样。1.1 混乱的根源它们都在“让模型做事”如果只看表面行为三者确实很像。模型调用一个 Skill 是做事通过 MCP 调用一个工具也是做事把一个任务交给子 Agent 还是做事。对使用者来说差别只是“模型多做了一步”但在系统架构里这三步发生在完全不同的层次。打个比方。如果你是一家公司的老板Skill 相当于给员工一本《标准作业手册》告诉他“遇到这种客户应该怎么接待”。MCP 相当于给员工配了一部电话和通讯录让他能联系到外部供应商。子 Agent 相当于你把一个项目整体分包出去让一个小团队全权负责。这三件事都在提升公司效率但它们是不同层面的管理动作。1.2 各家的产品包装加剧了混乱另一个原因是商业产品在宣传时会刻意模糊边界。某些 Agent 产品把内置流程框架命名为“Skill”有些 MCP Server 也提供着类似工作流的“技能包”还有一些平台把子 Agent 包装成“Skill 的一种高级形态”。这导致出现了大量类似“Agent Skill 和 MCP 有什么区别”“Skill 和 Agent 的区别”这样的搜索问题——用户的困惑是真的而且这种困惑在每一轮新工具出来后都会重复。1.3 一个不严谨但很实用的二分法如果你不想深究每一家产品的实现细节可以先建立一个粗框架Skill 是“往里装知识”MCP 是“往外接世界”子 Agent 是“往旁边拆任务”。这句话不一定能覆盖所有边界情况但能帮你在绝大多数选择场景里快速定位。后面每个概念我们都会展开讲最后再给出真正的组合方法。2. Skill 到底解决什么问题Skill 是三者中最容易被误解的一个。很多人以为 Skill 就是“给模型加一个插件”让它能调用某个 API。这种理解把 Skill 和 MCP 搅在了一起。实际上Skill 的核心并不在“连接外部”而在“教会模型一套做事的流程和规范”。2.1 Skill 的本质把做事方法固化成可复用资产你可以把 Skill 理解成一个“打包好的专项能力包”里面通常包含提示词文本、使用说明有时候还会附带脚本或参考数据。它解决的核心问题是大模型虽然拥有海量知识但在面对一个专业任务时不一定会“按照你想要的方式”去完成。举一个常见场景。你希望模型帮你审查代码中的安全问题普通对话模式下模型会泛泛地列出几个安全风险。但如果你把团队沉淀的安全审查清单、漏洞分级标准、报告格式要求写进一个 Skill模型就会严格按照这套规范执行先看输入输出校验再看权限控制接着查敏感信息暴露最后按固定模板输出风险等级和修复建议。这就是 Skill 的价值——它把一次性的提示词工程变成了可以积累、可以复用、可以团队共享的资产。从实现上看很多 Skill 就是一个文件夹加一个 Markdown 说明文件比如 Claude Code 中的 SKILL.md。模型在执行任务时会根据用户指令主动读取这个文件然后按照里面的指示行动。2.2 Skill 和普通 Prompt 有什么不一样Skill 本质上也是一种提示词但和普通的用户 Prompt 有三个重要区别。第一Skill 是结构化的。它不是用户在某次对话里临时输入的一句话而是提前组织好的、带固定文件结构的说明文档。它有自己的名称、描述、使用步骤和注意事项。第二Skill 可以包含可执行脚本。有些 Skill 不只是“读文档”还可以挂载脚本去完成重复性操作比如格式化代码、解析日志、生成测试数据。这让 Skill 具备了一定的自动化能力而不仅仅是“说给模型听”。第三Skill 是可发现、可选择的。系统会通过 Skill 的元信息名称、描述来决定什么场景下应该启用它。模型不是随机调用一个 Skill而是先判断当前任务匹配哪个 Skill再按需加载。2.3 新手最容易踩的两个 Skill 坑第一个坑把 Skill 当成万能工具库。你写了一个“文件整理 Skill”就期望它能直接操作你磁盘上的所有文件。但 Skill 本身并不天然具备文件系统访问能力它只是告诉模型“你应该怎么整理”真正去读文件或移动文件仍然需要模型具备对应的工具调用能力。这类能力在本地 CLI 工具里可能由 Agent 框架提供但在纯 API 对话环境里并不存在。第二个坑把 Skill 当成 MCP 的替代方案。Skill 不能帮模型调用未接入的外部 API也不能让模型访问一个全新的数据源。数据连接是 MCP 的职责Skill 的职责是“用好已经能用的东西”。如果你发现模型连数据都拿不到那不是 Skill 写得不够好而是缺少一个 MCP Server。3. MCP 到底解决什么问题如果说 Skill 是“教模型怎么做”那 MCP 就是“让模型够得到”。MCP 的全称是 Model Context Protocol它要解决的是一个更基础也更容易被轻视的问题如何让模型标准化地连接外部工具和数据源。3.1 MCP 出现之前的世界在 MCP 出现之前模型要调用一个外部工具每一种工具都需要单独开发一套对接方式。比如让模型查询数据库你需要写一个 Python 函数把 SQL 执行结果转成文本再丢给模型让模型控制浏览器你需要再写一套 Playwright 的封装让模型操作设计软件你又要用另一套 API。每个工具一套集成方案每套方案都要自己维护认证、超时和错误处理。这种模式下每接入一个新工具成本都高得离谱。而且不同的 Agent 框架对接工具的方式还不一样给 Claude 写了一套工具调用逻辑到了别的 Agent 平台又要重写。3.2 MCP 的标准化思路MCP 的提出就是为了解决这种碎片化。它定义了一套统一的协议让 AI 应用MCP Client可以连接外部能力MCP Server。Server 通过标准接口暴露自己的工具和资源Client 负责发现这些工具并让模型在合适的时机调用它们。可以这样理解MCP 之于 AI Agent就像 USB-C 接口之于电子设备。没有 USB-C 之前每个设备都要专属线缆有了统一标准之后一个接口能通用于显示器、硬盘、手机。MCP 做的是同样的事情它让“模型具备某种外部能力”这件事从“定制开发”变成了“标准接入”。在实际工程里你经常会听到“MCP Server”这个词。一个 MCP Server 通常运行在独立进程中通过 JSON-RPC 与 Client 通信。它内部可以封装任意逻辑调用 GitHub API、读写本地文件、操作浏览器、查询数据库都可以。对外暴露的就是统一的 MCP 接口。业界也已经出现了大量现成 Server比如文件系统 MCP、浏览器 MCP、设计工具 MCP这也是为什么搜索平台上“免费联网 MCP”“MCP 服务 Java”这类词热度一直很高——大家确实在到处找好用的现成接入方案。3.3 MCP 和 Skill 的本质区别这里要特别强调一个容易被忽略的点MCP 的核心是“协议”Skill 的核心是“内容”。MCP 不关心你的工具内部做了什么它只提供一套标准化的通信方式。它改变的是模型与外部世界的“连接方式”。Skill 则是在“模型已经有了能力”的基础上告诉模型“怎么把这件事做得更专业”。它改变的是模型的“做事方式”。用一句话总结模型通过 MCP 获得“手”通过 Skill 获得“大脑里的操作手册”。光有 MCP模型能调工具但不知道调完之后按什么流程检查、按什么标准汇报光有 Skill模型知道流程但伸手出去发现什么都够不到。真实项目里两者经常一起出现但它们的职责边界必须分清。4. 子 Agent 到底解决什么问题子 Agent 是三个概念中层级最复杂的一个。它可以很小也可以很庞大它既可以被看作一种“执行单元”又可以被看作一种“架构设计模式”。但不管怎么定义它的核心价值都指向同一件事把复杂的任务拆出去让不同的执行单元各管一段降低单次对话的认知负担。4.1 子 Agent 的本质一条独立的执行线程如果用一个不太严谨但好理解的类比主 Agent 和子 Agent 的关系类似于一个进程和它派生的子线程。主 Agent 负责理解用户的总体意图、拆解任务、调度资源子 Agent 接收一个被明确界定的子任务在独立的上下文窗口里执行执行完再把结果交回主 Agent。为什么需要这种独立上下文因为大模型的上下文窗口是有限的。如果你在一个对话里同时处理“项目代码审查”“编写测试用例”“整理发布说明”三项任务很快就会把上下文撑满而且前面的信息可能干扰后面的判断。更好的做法是主 Agent 把“代码审查”这个任务交给子 Agent 去完成子 Agent 只加载代码相关的信息执行完毕后返回一份精简的审查报告主 Agent 继续处理其他任务。这种设计在 OpenAI 开源的 Swarm 思路里体现得很清楚每个 Agent 拥有自己独立的 System Prompt 和工具集Agent 之间可以互相传递任务执行完后把控制权交回。这个设计理念现在已经成了 Agent 工程的主流做法只不过有的产品叫 Workflow有的叫 Task有的叫子 Agent。4.2 子 Agent 解决的核心问题子 Agent 在实际项目里主要解决三类问题。第一上下文隔离。长任务执行过程中不同阶段的信息互不干扰。做调研的子 Agent 不需要关心主 Agent 之前的对话历史它只需要拿到调研目标和相关材料然后输出结构化的结果。第二职责单一。一个子 Agent 只做一类事情System Prompt 可以写得非常聚焦。这让它的行为更可控、更可预测也更容易测试。相比之下如果让主 Agent 一个人身兼数职它的 Prompt 越长越容易在各种任务之间摇摆。第三并行和路由。在一些 Agent 框架里你可以同时派出多个子 Agent分别处理不同方向的调研最后汇总结果。这能显著缩短整体任务时间也符合“用多个小模型/多个上下文窗口组合成一个大系统”的思路。4.3 子 Agent 与 Skill、MCP 的关系纠葛很多人会把子 Agent 和 Skill 搞混原因是它们都像“让模型用另一种方式做事”。但两者的本质区别是Skill 改变的是“模型做事的方法”子 Agent 改变的是“执行任务的主体”。同样的道理子 Agent 和 MCP 的边界也要分清。MCP 是你给 Agent 配的工具子 Agent 是使用工具的“另一个大脑”。一个子 Agent 内部可以调用多个 MCP 工具也可以在逻辑里嵌入 Skill 的使用流程。它们不在同一个层级不存在“非此即彼”的选择关系。5. 三者对比从四个维度彻底分清前面分别解释了每个概念是什么这一节用一个统一框架把它们放到同一张表里对比。掌握了这张表你就掌握了三者关系的核心。对比维度SkillMCP子 Agent定位层级能力层连接层执行层核心问题模型会不会按规范做事模型能否连到外部工具/数据任务是否要拆给独立单元执行改变的对象做事的方法与流程连接的方式与范围执行任务的主体与上下文是否需要协议不需要统一协议依赖统一协议MCP/JSON-RPC取决于框架设计无强制协议主要组成文档、提示词、可选脚本Server、Client、工具清单System Prompt、工具集、独立上下文典型产物SKILL.md 文件、技能包MCP Server、Client 配置子 Agent 类、Task 定义失败时表现模型按错流程做事模型无法调工具或工具报错子任务结果不完整或上下文丢失这张表可以帮助你做快速判断当你在设计一个 Agent 功能时先问自己想解决的是“怎么做得更好”还是“怎么连得上”还是“谁来负责这一段”。答案不同对应的技术选择完全不同。5.1 补充一个更贴近开发的视角从开发者的实际操作来看三者还可以用“文件、进程、实例”来重新映射Skill 通常表现为项目里的一个文件或文件夹它随项目走可以提交到 Git可以评审可以复用。它强调“规范性”和“可沉淀”。MCP 通常表现为一个独立进程Server它有自己的生命周期需要启动、连接、鉴权。它强调“标准协议”和“外部系统集成”。子 Agent 通常表现为框架里的一个类或一个实例它在程序运行时被创建、调用、销毁。它强调“任务路由”和“上下文管理”。这种映射能帮你更准确地判断自己在当前阶段真正缺的是哪一种能力。如果你的问题是“模型输出的代码风格不符合团队规范”你应该写 Skill如果你的问题是“模型无法读取数据库里的订单数据”你应该配 MCP Server如果你的问题是“一次对话做太多事越到后面越乱”你应该拆子 Agent。6. 真实项目里如何组合使用概念讲清楚了还要解决一个更实际的问题在一个真实项目里三者到底怎么配合这里给出一个典型的组合决策链路以及一个最小示例代码。6.1 组合决策链路假设你要设计一个“代码仓库助手”它需要完成代码审查、生成测试用例、提交 PR 三步任务。在设计系统时你可以按下面的顺序做决策第一步确定主 Agent 的职责。主 Agent 负责接收用户请求、理解意图、规划任务。它是整个系统的调度中心。第二步确定需要哪些 MCP Server。代码助手必须连接 Git 仓库所以你需要一个 GitHub MCP Server 或 Git 工具 MCP如果要读本地代码再挂一个文件系统 MCP。这一步解决的是“模型怎么访问数据”的问题。第三步确定哪些环节需要 Skill。“代码审查”这一步对输出格式和检查标准有严格要求这时候给它挂一个“安全审查 Skill”“生成测试用例”需要遵循团队的测试规范给它挂一个“单元测试规范 Skill”。Skill 在这里负责让每一步的执行质量符合预期。第四步确定哪些任务要拆给子 Agent。“代码审查”如果涉及多个模块可以让一个子 Agent 审查前端代码、另一个子 Agent 审查后端代码同时执行。每个子 Agent 内部再使用对应的 Skill并通过 MCP 读取对应目录的代码。这个链路嵌套了三个层级主 Agent 调度子 Agent子 Agent 使用 Skill 规范行为Agent 通过 MCP 获取外部数据。三者各司其职而不是互相替代。6.2 最小组合示例代码下面用一段 Python 风格的伪代码来说明这个组合思路。这里不绑定任何具体 Agent 框架重点是展示“哪些代码对应 Skill哪些代码对应 MCP哪些代码对应子 Agent”。如果读者需要跑通真实版本可以把它映射到自己正在用的框架上。# 文件路径: agent_system_demo.py # 说明演示 Skill、MCP、子 Agent 在同一个 Agent 系统中的组合方式 # 这不是某个框架的完整实现而是概念示意代码 from dataclasses import dataclass # ---------- MCP 层负责连接外部工具 ---------- class McpClient: 模拟一个 MCP Client负责发现和调用 MCP Server 上的工具 def __init__(self, server_url: str): self.server_url server_url self.tools self.list_tools() def list_tools(self): # 实际项目中这里会调用 MCP 协议接口从 Server 拉取工具清单 return [ {name: read_file, description: 读取本地文件}, {name: search_code, description: 在代码仓库中搜索关键字}, {name: create_pr, description: 创建 GitHub Pull Request}, ] def call_tool(self, tool_name: str, args: dict): # 实际项目中这里会把参数序列化后发给 MCP Server print(f[MCP] 调用工具: {tool_name}, 参数: {args}) if tool_name search_code: return {matches: [main.py, utils/parser.py]} if tool_name read_file: return {content: def hello():\n print(hi)\n} return {ok: True, pr_url: https://github.com/demo/repo/pull/42} # ---------- Skill 层负责固化做事流程 ---------- class ReviewSkill: 模拟一个 Skill代码安全审查技能 def __init__(self, rules_file: str): self.rules_file rules_file def apply(self, code_content: str) - dict: # 实际项目中Skill 的文本会被注入到模型上下文中 # 模型再按照规则生成审查结果。这里用简单的规则引擎模拟。 risk_keywords [eval(, exec(, SELECT *] risks [kw for kw in risk_keywords if kw in code_content] return { skill: code-security-review, rule_file: self.rules_file, risks: risks if risks else [未发现明显风险], status: reviewed, } # ---------- 子 Agent 层负责执行独立子任务 ---------- dataclass class SubAgentResult: task_name: str result: dict status: str class CodeReviewSubAgent: 子 Agent只负责代码安全审查拥有独立上下文和工具集 def __init__(self, mcp_client: McpClient, review_skill: ReviewSkill): self.mcp_client mcp_client self.review_skill review_skill def run(self, module_name: str) - SubAgentResult: print(f[子Agent] 开始审查模块: {module_name}) # 子 Agent 通过 MCP 读取代码 files self.mcp_client.call_tool(search_code, {keyword: module_name}) latest_file files[matches][0] code self.mcp_client.call_tool(read_file, {path: latest_file}) # 子 Agent 使用 Skill 规范审查流程 review self.review_skill.apply(code[content]) return SubAgentResult( task_namefreview:{module_name}, resultreview, statusdone, ) # ---------- 主 Agent 层负责调度 ---------- class MainAgent: def __init__(self, mcp_client: McpClient): self.mcp_client mcp_client self.review_skill ReviewSkill(rules_filesecurity/rules.md) self.review_sub_agent CodeReviewSubAgent(mcp_client, self.review_skill) def handle(self, user_request: str) - None: print(f[主Agent] 收到请求: {user_request}) # 主 Agent 规划任务先审查后提交 PR modules [main, parser] for module in modules: result self.review_sub_agent.run(module) print(f[主Agent] 子任务完成: {result}) # 审查通过后主 Agent 通过 MCP 创建 PR self.mcp_client.call_tool(create_pr, {title: security review}) print([主Agent] 全部流程结束) if __name__ __main__: mcp McpClient(server_urlhttp://localhost:3000/mcp) agent MainAgent(mcp_clientmcp) agent.handle(帮我审查代码并提交 PR)这段代码虽然是示意但它把三者分工展示得很直白MCP 层管理“读文件”“搜代码”“提 PR”的工具调用Skill 层管理“代码审查”的规则与流程子 Agent 层拥有独立的执行入口负责把某个模块的审查任务跑完主 Agent 只做调度和汇总。6.3 运行与验证建议如果你把上面的代码保存为agent_system_demo.py直接用 Python 3.9 及以上版本运行可以看到终端输出里出现了[MCP]、[子Agent]、[主Agent]三类日志分别对应三层组件。这样就能直观验证子 Agent 通过 MCP 拿到代码再通过 Skill 产出审查结果主 Agent 拿到结果后继续处理后续动作。实际项目里验证标准应该再提高一层不仅要看流程能跑通还要看每一个环节是否“按协议工作”。MCP 层要确认 Server 工具清单能被正常发现Skill 层要确认模型输出确实遵循了规则文件里的格式要求子 Agent 层要确认它的输出没有污染主 Agent 的上下文。7. 常见误区与排查建议这一节把搜索热词里频繁出现的问题整理成一份误区清单。很多困惑不是因为你理解能力不够而是因为这些坑太常见。误区表述背后的问题排查方式正确方向“Skill 就是 Agent 插件”把能力规范和工具连接混为一谈检查这个“Skill”是否需要访问外部 API需要访问外部 API 时优先考虑 MCP Server“写一个 MCP Server 就能让模型学会做事”把连接能力当成业务流程能力检查模型是否清楚使用工具的步骤和输出规范用 Skill 补充流程规范“子 Agent 就是把 Prompt 写长一点”忽略上下文隔离的设计价值观察长任务中是否出现上下文互相污染拆出独立上下文窗口的子 Agent“三者选一个就行”把不同层级的组件当成并列选项画一下任务的数据流和执行流按数据连接、流程规范、任务拆分三个维度分别设计“模型调不到数据就再写一个更长的 Prompt”没意识到数据源连接需要协议层支持查看工具调用日志是否有报错接入 MCP Server 并检查工具发现结果“子 Agent 越多越好”盲目拆分导致调度开销过大统计每个子 Agent 是否承担独立任务任务复杂度低时不拆统一放在主 Agent 执行7.1 一个典型的排错路径如果你在实际配置中遇到了“MCP 工具注册不上”这类问题比如在一些代码 Agent 工具里接入 Figma MCP 时提示注册失败可以按下面的顺序排查第一步确认 MCP Server 进程是否正常启动。很多注册失败不是协议问题而是 Server 根本没有跑起来。第二步确认 Client 能拿到工具清单。MCP 的一个关键机制是工具发现Client 启动时会主动拉取 Server 暴露的工具列表。如果清单为空模型就没有任何工具可以调用。第三步确认环境变量和认证信息是否完整。一些 Server 需要 API Token 才能工作配置缺失会导致调用报错。第四步检查 Client 的配置项里是否启用了对应的 MCP Server。有些框架默认不加载所有 Server需要手动启用。这个排错路径对任何 MCP 接入问题都适用建议收藏备用。8. 工程落地建议与最佳实践最后这部分写给真正要上生产环境的开发者。前面已经解决了“是什么”和“怎么选”的问题这里重点讲“怎么落地不翻车”。8.1 在项目里引入这三个概念时的优先级如果团队从零开始构建一个 Agent 系统不要一开始就追求大而全。更推荐的推进顺序是第一先用 MCP 解决“数据可达性”。这是所有上层能力的基础。模型连数据都读不到写再多 Skill 也是纸上谈兵。先把项目需要的外部工具和数据源接入进来用最小 MCP Server 验证通一条链路。第二再沉淀 Skill。在业务流跑通之后把重复出现的操作流程固化成 Skill。比如你发现每次生成周报模型都会漏掉上线的风险记录那就写一个“周报生成 Skill”把章节结构、风险项模板、数据来源写清楚。Skill 应该来自真实业务中的重复问题而不是从网上抄一个模板。第三最后拆子 Agent。只有当任务复杂度真正超过单上下文承受能力时再把任务拆出去。拆分的标准是子任务是否有明确的输入和输出是否可以被独立验证。不确定的情况下先不拆。8.2 命名、版本与团队协作规范Skill 和子 Agent 都应该像代码一样纳入版本管理。Skill 文件建议用有意义的前缀命名例如code-review-security.md、release-note-generator.md并在文件头部写明适用场景和已知限制。子 Agent 的职责边界要写进文档否则后期很容易出现两个子 Agent 功能重叠的情况。MCP Server 的配置信息地址、Token、超时时间必须放在环境变量或配置中心管理禁止硬编码在代码里。8.3 安全边界必须前置任何涉及数据库操作、文件写入、远端仓库修改的功能都必须在 MCP 层做好权限控制。MCP Server 暴露给 Agent 的工具清单要遵循最小权限原则只暴露当前任务必需的工具不需要的工具不要注册。对于“删除文件”“执行 SQL”“推送代码”这类高风险操作应该在 Server 内部增加二次确认机制或者要求必须传入人工审批后的令牌。另外调用第三方 MCP Server 时要检查它的数据流向。不要随便在 Server 配置里填入高权限 Token最好为 Agent 单独创建低权限账号防止模型在意外情况下执行越权操作。这一点在生产环境里怎么强调都不过分。8.4 可观测性设计三个概念引入之后系统的复杂度会明显上升。建议在每一层都打日志MCP 层记录工具名、参数和返回状态Skill 层记录命中的技能名称和规则版本子 Agent 层记录任务名称、开始时间、结束时间和结果状态。这样一旦出问题你可以快速定位是哪一层出了问题而不是在一堆对话记录里大海捞针。9. 写在最后Skill、MCP、子 Agent 这三个概念本质上代表着 AI Agent 工程化过程中三个不可互相替代的抽象层级。Skill 让你把流程沉淀下来MCP 让你把外部世界连进来子 Agent 让你把复杂任务拆出去。真正的高手不会纠结于“哪一个更重要”而是会像搭积木一样根据任务的数据流和执行流把三者组合成一套系统。对于正在学习 Agent 开发的读者建议下一步找一个真实的小任务比如“读取一份本地日志并生成分析报告”亲手把流程拆一遍需要哪个 MCP Server、需要哪些 Skill 规则、要不要拆子 Agent。把这个最小系统跑通你对三者关系的理解就会超过大多数停留在概念层面的人。