封面图

Agent 项目最常见的误区之一,是把“模型能推理”“系统能调用工具”和“产品能完成任务”看成同一件事。

实际上,一个可交付的 Agent 至少要回答三个问题:

  1. 任务应该按什么方法执行?
  2. 能访问哪些数据与工具?
  3. 没有 API 时,如何操作现有软件?

这三个问题分别对应 Skill、MCP 和 Computer Use。

三层能力对比图

1. 三者的职责边界

能力 主要职责 输入 输出 常见失败
Skill 固化方法、规则和领域知识 目标与上下文 执行策略、步骤和标准 方法过泛、约束冲突
MCP 标准化连接工具和数据 工具名与结构化参数 结构化结果或错误 鉴权、超时、参数错误
Computer Use 操作没有合适 API 的 GUI 截图、DOM、历史动作 点击、输入、滚动后的新状态 页面改版、弹窗、焦点漂移

一句话概括:

  • Skill 决定“怎么做”;
  • MCP 决定“调用什么”;
  • Computer Use 决定“界面上怎么落地”。

2. Skill 不是一段万能 Prompt

Prompt 往往服务于一次对话,Skill 更接近可复用、可维护的工作模块。

一个合格的 Skill 至少应包含:

  • 适用场景与触发条件;
  • 明确的输入和交付物;
  • 分步工作流程;
  • 必须遵守的限制;
  • 需要调用的工具;
  • 失败后的替代路径;
  • 验证标准。

例如“生成技术文章”不应该只写成“请写一篇专业文章”,而应该约束事实来源、代码可运行性、标题结构、读者水平和审校步骤。

Skill 的价值,是把团队里原本依赖个人经验的 SOP,变成 Agent 可以重复执行的上下文资产。

3. MCP 解决的是连接标准化

MCP 标准化了 Agent 发现和调用外部能力的方式。一个 MCP Server 可以暴露工具、资源或提示模板,Agent 作为客户端读取能力描述,再发起结构化调用。

它解决的是过去 Agent 集成中的 N×M 问题:每个模型产品不必为每个业务系统都重新设计一套专属接口。

但 MCP 并不负责完整业务闭环。下面这些能力仍然需要 Agent Runtime 提供:

  • 任务规划;
  • 工具路由;
  • 状态保存;
  • 超时与重试;
  • 权限控制;
  • 结果验证;
  • 人工确认。

因此,“接入了 MCP”只能说明 Agent 获得了工具,不代表它已经具备稳定交付能力。

可靠 Agent 工作链

4. Computer Use 是兼容层,不应默认成为第一选择

Computer Use 通常采用观察—行动循环:

目标 + 当前截图/页面状态
        ↓
模型判断下一步动作
        ↓
点击 / 输入 / 滚动
        ↓
读取新的页面状态
        ↺

它适合以下场景:

  • 目标系统没有开放 API;
  • API 缺少某些关键操作;
  • 必须经过登录后的图形界面;
  • 需要兼容已有内部软件。

但如果已有稳定 API 或 MCP 工具,应优先使用结构化接口。GUI 自动化的页面结构、焦点、弹窗和加载状态都更容易变化,维护成本通常高于 API 调用。

比较稳妥的原则是:MCP/API 优先,Computer Use 兜底。

5. 推荐的 Agent 执行架构

async function runAgent(goal: Goal) {
  const plan = await skill.plan(goal)

  for (const step of plan.steps) {
    const result = toolRegistry.has(step.capability)
      ? await mcp.call(step.capability, step.args)
      : await computerUse.execute(step.uiAction)

    const verification = await verify(step.expected, result)
    if (!verification.ok) {
      await recover(step, verification)
    }
  }

  await requireHumanConfirmationForCriticalActions()
  return collectArtifacts()
}

代码不是完整实现,但表达了几个关键原则:

  1. Skill 先定义方法和验收条件;
  2. 工具注册表负责能力发现;
  3. 优先走结构化调用;
  4. GUI 操作只是降级路径;
  5. 每一步都要验证;
  6. 高风险写操作必须确认。

6. 2026 年代表产品路线

  • OpenAI 的 Apps 与工作型 Agent,重点是连接应用、文件和最终产物;
  • Anthropic 在 Claude Code、Cowork 和行业 Agent 中组合 Skills、Connectors 与 Subagents;
  • Google Managed Agents 把后台任务、远程 MCP、函数调用和凭证刷新放进统一 API;
  • Computer Use 类产品继续解决没有结构化接口的最后一公里。

这些路线正在趋同:模型只是决策核心,外围的连接、执行、恢复、验证和权限才决定产品是否可用。

7. 选型清单

做 Agent 项目之前,建议先回答:

  • 这是知识问题,还是执行问题?
  • 有没有稳定 API 或 MCP Server?
  • 哪些流程值得沉淀为 Skill?
  • 哪些步骤只能通过 GUI 完成?
  • 如何判断每一步真的成功?
  • 哪些操作必须由用户确认?
  • 页面变化或工具失败后,系统如何恢复?

如果这些问题没有答案,即使模型能力再强,产品也很容易停留在 Demo 阶段。

参考资料

建议标签

Agent、MCP、大模型、人工智能、Computer Use

Logo

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地,聚焦技能开发、插件实践与部署教程,为开发者提供可直接落地的方案、工具与交流平台,助力高效构建与落地 AI 应用

更多推荐