大模型提供了推理核心，但“模型能回答”与“系统能交付”之间，仍然隔着一整套 Agent Engineering。
在最近的 Agent 产品中，MCP、Skills、Computer Use 经常同时出现。它们不是同一层的技术，也不应该被当成三选一。
一张表看懂职责
| 层级 | 解决的问题 | 更接近什么 |
|---|---|---|
| Skills | 如何完成特定任务 | 可执行 SOP |
| MCP | 如何连接外部能力 | 工具协议与能力注册表 |
| Computer Use | 如何操作没有接口的系统 | GUI 兼容层 |
| Agent Runtime | 如何组织整个执行过程 | 状态机与调度器 |
Skills：把领域方法从 Prompt 中解耦
一个 Skill 不应该只是更长的系统提示词。它至少需要提供：
- 触发条件；
- 输入和输出契约；
- 任务步骤；
- 工具依赖；
- 禁止事项；
- 验收规则；
- 失败分支。
把这些内容独立出来的好处，是能够版本化、复用、评审和针对具体场景迭代，而不是把所有逻辑塞进一条不断膨胀的 Prompt。
MCP：能力发现与标准化调用
MCP 将外部能力描述为 Agent 可以发现和调用的工具或资源。Runtime 可以先读取工具 Schema，再由模型选择调用并生成参数。
MCP 主要降低连接成本，但它不自动提供：
- 跨步骤状态管理；
- 幂等性；
- 重试与补偿；
- 权限审批；
- 结果验证；
- 长任务恢复。
这些仍然需要业务代码或 Agent Runtime 实现。
Computer Use：覆盖长尾系统的降级路径
当目标系统没有 API，或者 API 无法覆盖关键步骤时，可以进入 Computer Use：
Screenshot / DOM / Accessibility Tree
↓
Action Decision
↓
Click / Type / Scroll / Upload
↓
New Page State
↺
GUI 路径的主要风险不是模型不会点，而是环境不稳定：
- 页面结构变化；
- 异步加载；
- 弹窗遮挡；
- 焦点漂移；
- 验证码与登录过期；
- 操作完成但业务状态未更新。
所以它应该是明确标记的 fallback，而不是默认工具。
推荐路由策略
type Route = 'mcp' | 'computer-use' | 'human'
function chooseRoute(step: Step): Route {
if (toolRegistry.has(step.capability)) return 'mcp'
if (step.risk === 'high') return 'human'
if (uiAdapter.supports(step.target)) return 'computer-use'
return 'human'
}
真实实现还要增加：
- 每个写操作的幂等键；
- 执行前后的状态快照；
- 可恢复的 checkpoint；
- 可观察的 action trace；
- 基于交付物而非页面提示的验证；
- 高风险动作的人机确认。
一个可落地的任务循环
Goal
↓
Skill 生成步骤与验收标准
↓
优先 MCP / API
↓ 无接口
Computer Use
↓
Verifier 检查产物与业务状态
↓ 失败
Recovery 重新规划或回滚
↓
Human Confirm
↓
Deliver
这里最关键的一层往往不是 Planner，而是 Verifier。
如果系统只会执行动作，却无法判断动作是否真正成功，那么它仍然只是更复杂的自动化脚本。
2026 年产品趋势
Google 的 Managed Agents 已经把后台运行、远程 MCP、函数调用和凭证刷新组合起来；OpenAI 的工作型 Agent 强调跨连接应用和文件生成最终产物；Anthropic 的行业 Agent 模板则把 Skills、Connectors 和 Subagents 放进同一架构。
方向非常一致：Agent 正在从模型包装层，变成包含连接、执行、状态、验证与权限的运行系统。
总结
- Skills 提供专业方法；
- MCP 提供结构化工具连接；
- Computer Use 处理 GUI 长尾；
- Runtime 负责规划、路由、恢复和状态；
- Verifier 与 Human Confirm 决定系统能否安全交付。
模型决定能力上限，工程系统决定可用下限。
