智能体技术选型指南：什么情况下用Skill、Agent还是MCP？

2次阅读

共计 2717 个字符，预计需要花费 7 分钟才能阅读完成。

最近团队在开发客服机器人时，就遇到了一个典型的技术选型问题：当用户询问 ” 查询订单状态并推荐相似商品 ” 时，应该拆解成独立的 Skill 模块，还是设计成具备决策能力的 Agent？同样在自动化流程中，一个需要协调多个子任务（如库存检查、支付验证、物流分配）的场景，是否该直接引入 MCP(Multi-agent Coordination Platform/ 多智能体协作平台)？

这类问题背后，其实是对三种技术本质的理解差异。下面通过对比分析帮大家理清思路。

Skill 的本质是 标准化功能模块，就像乐高积木中的基础砖块。它的核心特征包括：

无状态性：每次调用独立处理请求，不保留上下文
输入输出明确：如订单查询 Skill 的输入是订单号，输出是结构化状态数据
高内聚低耦合：修改商品推荐算法不应影响支付模块

典型的 Python 实现结构如下（含异常处理）：

class OrderStatusSkill:
    """ 订单状态查询 Skill 示例
    核心特性：1. 仅依赖订单 ID 输入
    2. 返回固定结构数据
    3. 包含业务异常处理 """

    def execute(self, order_id: str) -> dict:
        try:
            # 模拟数据库查询
            db_result = self._query_database(order_id)

            # 标准化输出结构
            return {
                'success': True,
                'data': {
                    'order_id': order_id,
                    'status': db_result.get('status'),
                    'last_update': db_result.get('timestamp')
                }
            }
        except DatabaseError as e:
            # 明确捕获特定异常
            return {
                'success': False,
                'error_code': 'DB_QUERY_FAILED',
                'message': str(e)
            }

Agent 的核心在于 自主决策能力 和状态管理。与 Skill 的关键差异体现在：

上下文感知：能记住对话历史或业务流程状态
目标导向：根据当前状态决定下一步动作
可组合 Skill：通过调用多个 Skill 完成复杂任务

以下是一个简单的有限状态机 (Finite State Machine/FSM) 实现示例：

class RefundAgent:
    """ 退货流程 Agent 示例
    状态机包含：1. INIT: 初始状态
    2. VALIDATING: 验证退货资格
    3. APPROVING: 人工审核
    4. COMPLETED: 流程结束 """

    def __init__(self):
        self.state = 'INIT'
        self.context = {}

    def handle_event(self, event):
        if self.state == 'INIT':
            if event == 'start_refund':
                self.state = 'VALIDATING'
                return self._validate_order()

        elif self.state == 'VALIDATING':
            if event == 'validation_passed':
                self.state = 'APPROVING'
                return self._request_human_review()
            elif event == 'validation_failed':
                self.state = 'COMPLETED'
                return {'result': '拒绝退货'}

        # 其他状态处理...

当系统需要 跨 Agent 协调 时，就需要 MCP 登场。典型场景包括：

任务分解与分配：如将物流拆分为运输、仓储等子任务
冲突解决：当多个 Agent 竞争资源时仲裁
全局状态监控：追踪所有 Agent 的进度

消息路由的伪代码示例：

def message_router(sender, receiver_type, content):
    """MCP 核心路由逻辑
    关键功能：1. 根据接收方类型选择 Agent 集群
    2. 实现负载均衡
    3. 处理超时重试 """

    candidates = get_available_agents(receiver_type)

    # 基于负载均衡算法选择目标
    selected_agent = load_balancer.select(candidates)

    try:
        # 带超时控制的转发
        response = selected_agent.send(
            message=content,
            timeout=config.MESSAGE_TIMEOUT
        )

        # 记录通信日志
        log_interaction(sender, selected_agent, response.status)
        return response
    except TimeoutError:
        # 触发重试机制
        return retry_policy.execute()

在初期设计中，我们曾将所有逻辑都塞进单个 Agent，导致：

内存占用飙升：因为长期维护对话历史
响应延迟增加：决策逻辑过于复杂
难以调试：状态转移路径不清晰

解决方案：

将超过 3 个状态转移的复杂逻辑拆分为子 Agent
对长期不用的上下文数据实现自动卸载
使用可视化工具监控状态机运行

当 Skill 接口变更时，可能会引发级联故障。我们通过以下方案解决：

接口版本控制：

# 在请求头中指定版本
headers = {'X-Skill-Version': '2.1'}

灰度发布机制：
新老版本 Skill 并行运行
通过流量比例控制逐步迁移
自动化契约测试：
使用 Pact 等工具验证接口兼容性

跨 Agent 操作可能遇到部分失败的情况。我们采用 Saga 模式处理：

将大事务拆分为多个可补偿的子任务
每个子任务提供补偿操作
通过事件溯源 (Event Sourcing) 跟踪执行链

示例补偿逻辑：

def compensate_payment(order_id):
    """支付操作的补偿逻辑"""
    try:
        payment_service.reverse(order_id)
        return {'status': 'rolled_back'}
    except Exception as e:
        # 标记为需人工干预
        alert_manual_review(order_id, str(e))

当系统需要动态组合能力时（如同时需要精确控制和高扩展性），可以考虑：