MCP、Skills与SubAgent：构建稳定可控的AI Agent系统

从标题里其实能闻到一股很实在的需求：很多人手里已经有了一个能跑通的单Agent，但一上复杂任务就崩——上下文越塞越乱、工具越挂越多、改一个功能牵一发动全身。MCP和Skills同时冒出来之后，不少人以为它们是同一个东西的两种叫法，实际上这俩解决的是完全不同层面的问题，只有把它们和SubAgent架构放一起用，才能真正缓解那个“Agent越做越重、越做越傻”的困境。

这篇不打算复述一遍官方文档，单纯从我自己落地多智能体系统的实际经验出发，把MCP、Skills和SubAgent这三件事怎么组合、怎么分工、有哪些坑，尽量一次讲透。不管你是刚接触Agent开发的新手，还是已经开始改自己那套单体Agent的老手，应该都能从这里找到能直接抄作业的部分。

1. 先拆清楚SubAgent架构到底在解决什么问题

1.1 单体Agent的失控点在哪

单体Agent用起来其实很顺手，因为逻辑都在一个循环里：接收用户输入、带上全部上下文、决定调用哪个工具、拿到结果、继续推理。小范围Demo完全够用。可一旦任务变复杂，问题就原形毕露：上下文窗口是有限的，而Agent为了不“失忆”，会把之前的对话摘要、中间结果、工具返回都堆进上下文，越堆越厚，最后模型要么注意力被无关内容冲散，要么干脆触发窗口上限。原来写好的System Prompt被淹没，工具描述太长又占预算，效果断崖式下跌。

另一个隐性问题是职责混乱。一个Agent里既装日历查询，又装代码搜索，还挂了十几个文档工具，模型面对这么多工具描述时选择成本陡增，甚至频繁挑错工具。这种“工具很多但不好使”的情况，不是模型变笨了，而是我们给它的选择空间过载了。

1.2 拆分不是为了让架构好看，是为了隔离复杂度

SubAgent架构的核心思路，是让一个“主控Agent”只负责拆解目标、分发任务、汇总结果，把具体干活这件事交给不同类型的“子Agent”。每个子Agent拥有自己独立的上下文、专属的工具集、精简的System Prompt，任务完成之后把结果压缩成一段精炼摘要交回给主控，随即销毁自己那段上下文。

这个模式带来的直接收益是：主控的上下文长度基本稳定，不会随任务量线性膨胀；每个子Agent只需要理解和它自己相关的很少一部分工具描述，选错工具的几率大幅下降；并行能力也天然出来了，互不依赖的子任务可以同时跑。

但从另一个角度看，拆分的代价是额外的调度开销，以及子任务之间的信息衔接需要设计。所以SubAgent架构不是任何时候都该上，而是当你发现单体Agent在复杂多步任务上频繁出错、上下文告警、工具冲突的时候，才值得动手改。

1.3 我建议你考虑SubAgent架构的五个信号

根据我自己的经验，下面这五个信号只要中了三个，就可以认真考虑迁移到SubAgent架构：

• 单次任务需要调用的工具类型超过五类，而且每类之间的对象类型不一样。
• 用户在单轮对话中给出的目标往往包含多个隐含子任务，比如“帮我查一下下周三会议安排，然后订个餐厅，最后把议程发给参会人”。
• 子任务之间存在结果依赖，例如前一步的查询结果要作为下一步工具的入参。
• 你希望加入质量校验或人工审批节点，比如抽查AI生成内容再决定是否继续。
• 你很在意上下文成本，希望把长对话拆成短周期的“任务上下文”而不是永久累积。

这些信号背后的本质，都是“单一线性上下文”难以再承载多目标、长链条的复杂工作流。SubAgent架构剪断了这条线性增长链，让每个环节各司其职。

2. MCP在架构里的正确位置：它是工具面，不是大脑

2.1 MCP本质上解决的是“工具插拔”标准化问题

MCP的全称是Model Context Protocol，它做的核心事情是给Agent定义统一接口，去连接外部数据、工具和交互上下文。如果你把它理解成一套USB-C接口规范，就很好懂：之前每给Agent加一个工具，开发者就得针对特定框架写一套适配代码；现在只要目标方实现MCP接口，Agent端就能直接识别并调用。

在SubAgent架构里，MCP解决的是“子Agent的工具从哪里来”的标准化问题。不同的子Agent按需挂不同的MCP Server，而不是把所有工具都堆在主控上。例如，负责日程管理的子Agent只需要连接自己的日历MCP Server，财务子Agent连接财务系统MCP Server。这避免了大量工具描述集中在同一个Agent里导致的上下文污染。

一个MCP Server通常暴露以下三类能力：

• 工具（Tools）：可执行的动作，比如查天气、发邮件、读取数据库。
• 资源（Resources）：可读取的数据对象，比如某个项目的配置文件、日志文件。
• 提示模板（Prompt Templates）：可复用的提示片段，比如固定格式的周报生成提示。

实际开发中，我大部分时间只用到Tools这一类，Resources偶尔用，Prompt Templates用得最少，因为后来发现这个能力跟Skills非常重叠，反而容易造成“两头都要维护”的混乱。

2.2 一个MCP Server的落地细节

这里给一个最小化的MCP Server示例，演示工具注册的思路。下面的代码用Python的FastMCP风格来写，核心是注册一个给子Agent用的“查询订单状态”工具：

python复制from fastmcp import FastMCP

mcp = FastMCP("OrderServer")

@mcp.tool()
def get_order_status(order_id: str) -> dict:
    """
    根据订单号查询订单当前状态。
    Args:
        order_id: 订单唯一编号，如 ORD-2025-001。
    Returns:
        包含状态、预计送达时间、物流公司等信息的字典。
    """
    # 这里实际会去调后端订单服务，略
    return {
        "order_id": order_id,
        "status": "shipped",
        "eta": "2025-03-18",
        "carrier": "Express"
    }

mcp.run(transport="stdio")

这类工具被挂到子Agent后，主控不需要知道订单接口怎么调，它只知道“要查订单就找订单子Agent”，订单子Agent再通过MCP Server完成具体动作。调用链从原来的“主控Agent直连所有后端”变成“主控Agent调度子Agent，子Agent连接自己的工具面”，每层职责都清楚了一圈。

2.3 用MCP时的几个经验原则

先说结论，再解释。

第一，MCP Server的工具粒度要“中性化”。不要写那种为了特定任务定制的超长工具，尽量拆成可复用的基础能力。比如“获取用户信息”“更新用户标签”这种粒度就好于“为市场部分析用户并打上高质量标签”。因为粒度太大，另一个子Agent想复用就难了。

第二，工具描述别写成论文。模型读取工具描述是要消耗上下文的，描述越长占用越高，而且会干扰模型的判断。一个好的工具描述应该像电梯演讲，说明“这个工具干什么、什么时候用、要传什么参数”，不要写实现细节。

第三，宁可多挂几个标准MCP Server，也不要做一个超级大而全的Server。把不相关的能力揉进同一个Server里，虽然管理起来少几个进程，但每个子Agent一接入就会引入大量无关工具描述，前功尽弃。

第四，用MCP来封装“稳定接口”，但不要指望它来维护“流程状态”。MCP适合做无状态的服务调用，流程状态应该由上层SubAgent架构来管理。比如“先查订单再发起退款”这个流程，最好放在子Agent的提示逻辑里，而不是硬编码在MCP工具里，否则就退化成写死的工作流了。

3. Skills的本质与设计：它们是SubAgent的岗位说明书

3.1 不要把Skills理解成另一种工具

很多人第一次接触Skills这个名字，会下意识觉得它跟工具差不多。其实差别很大。工具是一段可以执行的代码/外部动作，而Skills更像是“教模型怎么干活的操作手册”。它是一份结构化的指令集，通常由Markdown、YAML或两者混合组成，里面写清楚某个任务的处理流程、决策规则、输出格式。

你完全可以这么理解：MCP工具是“手”，Skills是“脑内的工作流规范”。同一个工具，不同Skills会教会模型以不同方式去使用。比如“查天气”是一个工具，但“组织一次户外活动之前的天气评估Skill”会教模型该怎么查天气、看哪些指标、如何判断适合出行。后者不是新功能，而是经验沉淀。

在SubAgent架构里，Skills的价值更加明显。因为每个子Agent本质上就是“一组工具 + 一份专属于自己的工作方法”，那份工作方法就是Skills。子Agent不需要来自主控的复杂指挥，只要被给定目标，它自己就能根据Skills里的方法论拆解动作。

3.2 一个皮肤科问诊Skills的设计范例

我用一个偏业务的例子来说明：假设要做一个“非医疗建议的日常护肤品推荐子Agent”。它的工具可能是查成分表、查肤质类型、查产品评测。但光有这些工具远远不够，因为模型可能上来就直接推荐某产品，完全没按标准流程走。这时候Skills就该登场了。

一份典型的Skills文件结构会像下面这样：

markdown复制---
name: skincare_routine
description: 根据用户肤质与预算，生成日常护肤品搭配方案的执行指南
---

# 执行流程

1. 询问用户的核心肤质状态：干性、油性、混合、敏感，以及是否存在明显问题如泛红、粉刺、干燥脱屑。
2. 查询成分数据，判断目标成分是否适合该肤质的耐受度。
3. 根据用户提供的预算档位，从高性价比、中端、高端三档中各推荐一个方案。
4. 输出必须包含“使用顺序建议”和“注意避免的叠加组合”。

# 硬性规则

- 如果我无法确认用户的真实肤质，必须先追问，不得自行假设。
- 含有高浓度酸类成分的产品，除非用户明确表示耐受，否则一律标注低频率使用。
- 所有输出结尾必须附上“这不是医疗建议，严重问题请就医”的提示。

这份Skills其实不会给模型增加任何新能力，它只改变模型“思考”这个任务的顺序和决策边界。这就是Skills最大的作用——让Agent在遇到某个任务时有章法，而不是纯靠大模型临场发挥。

3.3 Skills在SubAgent里的三种组织形式

根据我的实践经验，Skills在SubAgent体系里通常有三种组织方式。

一是“绑定式”。每个子Agent在创建时就直接挂载对应的Skills。比如财务分析子Agent只挂财务报表解读类Skills，绝不给它挂内容写作Skills。这种方式隔离性最好，但缺点是知识复用率低。

二是“共享库式”。把通用Skills放在一个共享目录里，子Agent按需引用。比如“客户沟通语气指南”“隐私信息处理规范”这种几乎每个子Agent都需要的Skills，适合放共享库。参考时可以通过MCP的资源能力读到，也可以预先注入上下文。

三是“按任务动态装配式”。主控Agent拆解出任务之后，根据任务类型临时为子Agent组合一套Skills。比如一个“客户回访内容生成”任务，需要“客户背景读取Skill + 话术风格Skill + 敏感词校验Skill”三个Skills叠加。这种方式最灵活，但需要主控本身对Skills有一定认知，对主控的模型能力要求更高。

我在实际项目中初期用的是绑定式，后期逐步过渡到共享库式。动态装配式看起来很美，但主控选择Skills本身会消耗额外token，而且一旦选错反而会导致子Agent执行混乱。如果没有很强的信息检索能力，不建议新手直接上这套。

3.4 Skills文件自己的工程化管理

Skills文件写出来之后，管理也很关键。要做到几点：命名规范、版本化、目录清晰、描述自洽。

我一般把Skills放在这样的目录结构下：

text复制skills/
  shared/
    tone_of_voice.md
    privacy_guard.md
  agents/
    scheduler/
      meeting_prep.md
      calendar_triage.md
    finance/
      expense_review.md
      report_draft.md

每个Skills文件里的description字段，是主控判断“该给子Agent装配哪个Skill”的核心依据。description写得太模糊，主控就会乱选。我踩过一个很具体的坑：某次一个“会议纪要生成”任务的Skills被主控错误挂到了一个“会议决策追踪”子Agent身上，导致输出格式完全错位。查了半天，原因就是两个Skills文件的description都写了“会议相关”，但没有区分是“总结过去”还是“追踪后续”。

所以我的建议是，description里必须写明“当用户需要处理什么类型的目标、输入是什么、输出交付形态是什么”这三要素。这是Skills工程化管理里最容易被忽略的一环。

4. SubAgent的编排模式：扇出、串联与上下文物联网

4.1 从主控到子Agent的三种典型关系

SubAgent架构的编排，按我的经验可以归成三类基础模式。

第一类叫“扇出模式”。主控拿到一个目标后拆成多个独立子任务，同时派给多个子Agent去执行，最后汇总。适合用于那些子任务之间没有强依赖的场景，比如“为一个新品做一句话定位、写三条卖点、画一张宣传草图”，这三件事可以同时进行。扇出模式最考验的是主控的任务拆解能力，拆得好并行效率极高。

第二类叫“串联模式”。子任务之间有严格顺序，比如“先查库存再定补货计划”，前面没有结果后面无法开始。这时候主控不能一把扇出去，只能等前一个子Agent返回后再派下一个。这个模式很考验主控的结果维护能力，因为前序结果要传递给后一个子Agent，不能只汇总一次Summary就扔掉关键信息。

第三类叫“审查模式”。主控先让一个子Agent产出内容，再交给另一个专门做质量审查的子Agent去校验。我通常会把“生成者”和“审查者”拆成两个独立子Agent，有时审查者甚至用不同参数的模型，因为同一个模型自己检查自己的输出，容易形成惯性盲区。

实际项目里，以上三类会组合使用。比如先扇出两个调研子Agent，各自结果汇总后进入串联模式做方案草拟，最后再由审查子Agent做一轮质检。这种组合我已经跑得很熟了。

4.2 一个不依赖具体框架的编排骨架

这里给出一个不绑定具体框架的伪代码骨架，用于展示主控Agent与SubAgent之间如何拆任务、如何分配结果。假设主控拿到的任务是“根据最近三个月的销售数据，生成月度运营分析报告并发送邮件”。

text复制function main_task(user_request):
    # 1. 主控规划：从请求中识别子任务节点
    plan = plan_subtasks(user_request)
    # plan = [
    #   {task_id: "data_pull", agent_type: "data_agent", desc: "拉取近三月销售数据"},
    #   {task_id: "analysis", agent_type: "analyst_agent", desc: "生成运营分析结论", depends_on: ["data_pull"]},
    #   {task_id: "email", agent_type: "notify_agent", desc: "发送报告邮件", depends_on: ["analysis"]}
    # ]

    results = {}
    for subtask in topo_sort(plan):
        if subtask.depends_on:
            # 如果依赖前置结果，从临时上下文获取
            context = package_context(results, subtask.depends_on)
        else:
            context = {}
        agent_output = dispatch_agent(subtask.agent_type, subtask.desc, context)
        results[subtask.task_id] = agent_output

    return final_summary(results)

这份骨架最核心的地方，是每个子Agent的输出不是一股脑全塞回主控上下文，而是按task_id存到results里。当下一个子Agent需要某份结果时，再由主控决定把哪些关键片段提取出来并打包传给它。这避免了所有中间结果无差别堆叠在主控上下文里，也避免了一个子Agent的输出干扰另一个子Agent的执行。

4.3 管理子Agent上下文的四板斧

子Agent上下文的治理，我总结下来主要靠四招。

第一招是“摘要压缩”。子Agent完成工作后，不只返回原始结果，还要返回一个“面向主控的摘要”，里面只包含主控需要知道的结论和可用于继续推理的关键数据。这招看着朴素，但能把主控上下文体积削减百分之六七十。

第二招是“关键数据透传”。有时候摘要里光有结论不够，后续子Agent需要结构化数据。比如分析完销售数据之后，邮件生成子Agent需要具体的数字。我会让分析子Agent返回一个JSON字段，包括平均值、峰值日期、变动率，而不是让它自然语言概括。

第三招是“剥离过程日志”。子Agent内部的思考过程、中间尝试、工具的临时输出，默认不进主控上下文，只有调试模式才打开。调试时可以把日志单独存储，任务结束后再人工抽查。

第四招是“临时租借上下文”。如果某个子任务特别重，需要外部长文档或大段代码作为输入，我会让子Agent直接从外部存储读取，而不是把这个大段内容塞给主控再转发。相当于子Agent自己负责把大脑“撑开”，干完活就缩回去。

4.4 主控Agent的“轻”与子Agent的“专”

这套架构跑出来的一个共同体会是：主控Agent要尽量“轻”。所谓轻，是指主控不挂太具体的业务工具，也不塞太长的行业知识。主控更像一个项目经理，知道哪些环节找谁、需要什么输入、交付物长什么样就足够。具体知识放在子Agent的Skills里，具体动作放在子Agent的MCP工具里。这样改一个业务细节时，只动对应的子Agent，主控完全不用碰。

相反，如果主控很“重”，集成了所有工具和知识，那它本质上还是单体Agent，只是披了一层SubAgent的外壳。这种伪SubAgent架构比完整单体Agent更差，因为它多了调度损耗，却没有换来上下文隔离的收益。

5. 一套完整Demo：多角色运营报告工作站

5.1 要解决的问题

为了把前面这些概念串起来，我抽一个自己跑过的模拟场景来演示：做一个“多角色运营报告工作站”。用户丢进一堆原始运营素材，比如流量数据、用户反馈、竞价报表，系统自动完成四件事：

• 数据清洗与异常值标记
• 流量趋势解读
• 用户反馈与活动效果关联分析
• 生成给业务负责人阅读的整合报告

这个任务如果用一个单体Agent去做，要么上下文会被三份原始数据表塞爆，要么模型在分析途中断章取义。我用SubAgent架构把它拆成了三个子Agent加一个主控。

5.2 角色定义与Skills挂载

系统里共四个角色：主控Coordinator、数据清洗Agent、分析Agent、写作Agent。

• 主控Coordinator：负责接收原始文件，拆任务，串联结果，决定何时启用清洗后的数据。它不直接处理表格内容。
• 数据清洗Agent：挂载两个MCP Server，一个读取xlsx数据，一个做定时任务无关的基础统计，同时挂一个“数据异常识别”Skills文件，告诉它哪些值需要标记。
• 分析Agent：挂载数据库查询MCP Server和用户反馈读取MCP Server，Skills文件里有“指标关联分析法”，规定必须结合用户反馈来解释流量波动。
• 写作Agent：只挂一个文档生成MCP Server，Skills文件里是“结构化经营报告写作规范”，要求按“结论先行、数据支撑、风险提示”三层结构输出。

这里的关键是，每个子Agent看到的工具和规范完全不同，它们之间互不干扰。主控只负责结果流转，不会去理解数据的具体含义。

5.3 执行链路与特征

整个执行链大致是这样走：主控收到三份原始文件，先调用数据清洗Agent，要求它输出“清洗后的结构化数据 + 异常标记表”。清洗Agent拿到文件，套用异常识别Skill，返回两个东西：一份标准结构数据，一份异常说明摘要。

接下来主控同步调用分析Agent，把清洗后的数据和异常标记表作为入参。分析Agent会根据自己的Skills，先做趋势计算，再去用户反馈库找关联证据，最后输出几个核心洞察。每个洞察都会附上关联数据片段，而不是凭空下结论。

最后主控把分析Agent的输出交给写作Agent。写作Agent不看原始表格，只看分析Agent输出的洞察列表，按照写作规范生成报告正文。最终报告包括开篇结论、核心数据拆解、风险预警，以及下一步建议。整件事跑下来，主控上下文的峰值大概只有完整读取一份报告的量，远小于把三份原始数据表全部塞进上下文的做法。

5.4 这个Demo暴露出来的效果差异

我自己把同一个任务用单体Agent和SubAgent架构各跑过一遍，单体Agent在数据读取阶段就容易遗忘之前的口径要求，比如连续分析几个数据表后会忘记“同环比要用周度而不是日度”的指令；而SubAgent架构下，清洗Agent自始至终只处理口径问题，不会因为其他任务干扰而偏离标准。写作Agent也稳定很多，因为输入已经是被归纳过的洞察，它不会擅自引入原始数据中的噪音。

这就是把MCP、Skills和SubAgent组合在一起的真实收益。MCP管理外部能力接入，Skills管理内部工作方法，SubAgent管理流程和上下文边界。三者各司其职之后，Agent系统的可维护性和稳定性都会上一个台阶。

6. 实测过程中高频踩到的坑与排查速查表

6.1 MCP工具描述与Skills规则“打架”

这是我很早期就遇到的一个问题。某个MCP Server工具的描述要求调用者传入“原始时间字符串”，但Skills里却写着“先把时间字符串格式化为标准时间对象再传给工具”。模型有时候按Skills做，有时候按MCP描述做，输出极不稳定。

排查的方法很直接：把所有子Agent的上下文做个转储，人工核对MCP工具描述和Skills规则之间是否存在冲突语句。我后来形成的规范是，MCP Server里只写工具的技术约束（该传什么类型、什么格式），Skills里只写业务规则（这个任务应该怎么思考、决策边界），两边尽量不要交叉描述。如果Skills要求先做格式化，那就在调用工具前先处理，而不是让工具去兼容业务规则。

6.2 子Agent返回的摘要信息不够用

很多时候子Agent返回给主控的摘要过于精简，主控报错说“信息不足，无法继续”。这种情况通常是因为摘要压缩时只保留了结论，丢掉了后续任务真正需要的明细值。

后来我在子Agent的输出模板里增加了一个“关键数据结构段”，用JSON强制承载某些必填字段。例如数据分析Agent的返回模板必须包含period、metric_total、anomaly_count等字段。只要字段齐全，主控哪怕少读几行自然语言，也能拿到足够的信息做决策。

6.3 Skill挂载过多导致主控选择困难

动态装配Skill是好办法，但Skill数量一大，主控就会出现“选错”或“漏选”的情况。我在一次项目中给主控开放了十几个Skill，结果主控给该做会议纪要的子Agent装配了一个“幽默内容生成Skill”，整个调性全歪了。

我的纠正办法是分两层：第一层用轻量规则做粗筛。比如任务目标里出现“纪要、总结、记录”，就机械地指向meeting_notes Skill，不过模型自由发挥。第二层才让模型在粗筛后的候选里做细选。这等于用规则给模型划了一道护栏，大大降低了选择成本。

6.4 性能与成本问题排查表

这份速查表是我在多个项目里反复用到的，未必全面，但对于新手老手都能节省大量排查时间：

6.5 一个关于“调试体验”的训练心得

SubAgent架构调试起来最大的痛苦在于链路长、问题可能出在任何一层。为此我习惯很早就在系统里埋一个“透明模式”：开启后，每次调度都会把主控传给子Agent的入参、子Agent返回的摘要、主控最终输出全部记录到本地日志。虽然这个模式会拖慢运行速度，但排查问题时是救命级的工具。

另外，我建议每个子Agent单独做“单元测试”，不要等全链路拼完才联调。比如某个分析子Agent，我会直接用三四组固定输入去测它，看输出是否遵守了Skills里的规则。如果这一步没过，后面串联起来毛病只会更重。

7. 根据自己的实际经验再做一次总结

要我说，MCP、Skills和SubAgent这三样东西，分别对应了“接入外部能力”“沉淀内部方法论”“组织任务生命周期”三层需求。很多人在这三样上栽跟头，多半是因为搞混了它们的边界：用Skills去做接入，用MCP去做流程控制，用SubAgent去做智能决策，最后架构越做越别扭。

我在自己项目里摸索出来的最稳妥路径是：先从单体Agent开始，把工具选中率、上下文占用、任务成功率三个指标跑出来作为基线；然后把重复出现的稳定任务拆成第一个子Agent，配上它专属的MCP Server和Skills；接着再拆第二个子Agent；直到主控的职责收敛为“拆任务、传结果、做最终合并”。这个过程不是一次重构完成的，更像逐步演化。

一个特别强烈的个人感受是：Skills的质量决定了子Agent的专业上限，MCP Server的粒度决定了子Agent能走多远，而SubAgent架构的调度逻辑决定了整个系统能不能稳定地规模化。三个环节里最容易被低估的是Skills，因为它不产生代码级的功能，却是让模型行为稳定的关键。很多人把精力全花在工具接入上，结果发现工具越多模型越乱，根子就在于没有给模型配套足够清晰的工作规范。

如果你正准备改造手上的Agent系统，我的建议是先把“主控轻量化”这件事落实，再逐项引入子Agent，同时用一套简单但完整的日志记录每次调度行为。等这三个动作都跑顺了，MCP、Skills和SubAgent这套组合才算真正在你系统里长出了根。