从 API 到 Agent:AI 时代的软件为什么都在不断做 Wrap?

最近在研究如何让 Agent 自动使用 Google Analytics 做增长分析时，我发现一个有趣的问题：如果想让 Agent 查询 GA 数据，到底应该使用什么？API？Python SDK？CLI？MCP？Skill？

这些概念经常被混在一起，但如果从软件发展的角度看，会发现它们其实都在解决同一个问题：

软件工程一直在做一件事情：不断 Wrap，不断抽象。

从机器语言到高级语言，从 Library 到 Framework，再到 SDK、API，本质都是隐藏底层复杂性，让使用者关注更高价值的问题。

© 图 1｜从 System 到 Human：复杂能力是被一层层 Wrap 出来的

API 是系统提供能力的标准入口。

例如 Google Analytics API 提供查询用户、渠道、页面等数据的能力。API 很强大，但也比较底层，需要调用者理解参数、认证、请求格式。

SDK（Software Development Kit）本质是 API 的封装。

它帮助开发者处理认证、参数转换、请求细节，让调用变得简单。

CLI（Command Line Interface）进一步包装 API。

例如：

ga users --days 7

背后可能调用 Google Analytics API，但对于人和 Agent 来说，它变成了一个明确的执行动作。

Python Script 不是连接方式，而是业务逻辑编排。

例如增长分析流程：查询用户趋势 → 判断异常 → 查询渠道变化 → 检查页面表现 → 输出分析报告。

这就是 Workflow 的雏形。

© 图 2｜API、SDK、CLI、Python Script：同一个能力的四种使用界面

Skill 不只是工具封装，它包含能力定义、使用规则、领域知识和最佳实践。

CLI 告诉 Agent 怎么执行，Skill 告诉 Agent 什么时候执行、为什么执行。

© 图 3｜Tool 提供能力，Skill 组织能力：为什么 Agent 需要 Skill

当工具越来越多：Google Analytics、GitHub、Slack、Notion、CRM，需要一个标准方式让 Agent 发现和调用工具，于是 MCP 出现。

MCP 类似 AI 工具世界的 USB-C。

Human
 ↓
Agent
 ↓
Skill
 ↓
Workflow
 ↓
CLI / Function / MCP
 ↓
API
 ↓
System

对个人和小团队来说

并不是一开始就需要 MCP。

很多场景下：

Agent
 ↓
Skill
 ↓
CLI / Python Script
 ↓
API
 ↓
Google Analytics

已经足够强大。

真正重要的不是选择哪个技术名词，而是理解：

未来优秀的 Agent Builder，本质越来越像 FDE（Forward Deployed Engineer）：连接业务、系统和 AI，把复杂流程变成可执行能力。