软件的主要用户将是Agent：AI时代软件开发的范式转变

一场无人谈论的范式转变

五十年来，软件设计始终围绕一个核心假设：人类会使用它。我们的一切优化都服务于人类认知——易读的标签、直观的导航、友好的错误提示。每一次界面决策，都以”人类在场”为前提。

然后，AI Agent 出现了。他们不需要按钮。不阅读工具提示。不在乎下拉菜单或新手引导流程。他们只需要API。

当一个 AI Agent 需要预订机票时，它不会打开浏览器，而是直接调用航空公司 API。当它需要写代码时，它不会阅读教程，而是调用 GitHub API。当它需要回答问题时，它不会搜索 Google，而是调用搜索 API。

数据已经非常惊人。OpenAI API 每天处理数亿次调用，其中绝大部分由 Agent 而非人类发起。GitHub API 每年处理数十亿次请求，主要来自 CI/CD 管道和 AI 编程助手。到 2026 年，分析师预计超过 60% 的 API 流量将是机器发起的，而非人类。

Karpathy 的”LLM OS”：转变的蓝图

Andrej Karpathy——OpenAI 创始成员、特斯拉前 AI 总监——以异常的清晰度阐述了这个转变。在红杉资本 2024 年 AI Ascent 峰会上，他描述了自己正在构建的方向：

“每个人都在努力构建我所说的 LLM OS——一个以 LLM 为 CPU、以外部工具（数据库、API、代码仓库）为外设的操作系统。我们正在构建这个操作系统，并将其作为免费、快速的 API 平台提供给经济领域的各个角落。”

在 Karpathy 的愿景中，人类负责构建基础设施——API 平台、工具集成、数据管道。Agent 才是用户。人类写代码，Agent 执行。人类设定目标，Agent 追求目标。

这并非科幻。想想你今天如何使用 AI。你描述一个任务（”写一个 Python 脚本来处理这个 CSV”），Agent 编写代码、测试代码、提交代码。你没有写代码，是 Agent 写的。Agent 才是你代码库的使用者。

MCP：AI 工具的”USB 时刻”

如果说 LLM OS 是架构，那么 MCP（Model Context Protocol）就是让它成为现实的连接器。

Anthropic 于 2024 年 11 月发布了 MCP，作为一个开放协议，标准化 LLM 如何连接外部工具和数据源。可以把它想象成 AI 领域的 USB：USB 出现之前，打印机、鼠标、硬盘各有专有接口；USB 出现之后，任何设备都可以插入任何端口。

MCP 对 AI Agent 做了同样的事。在 MCP 出现之前，将 AI 连接到数据库需要定制代码；连接到 GitHub 又需要另一套定制集成。MCP 出现之后，Agent 可以无缝访问各种工具，仿佛它们本来就是为协同工作而设计的——因为现在，它们确实是了。

采用速度令人瞩目：

• Anthropic 将 MCP 集成到 Claude
• OpenAI 在 Agents SDK 中添加了 MCP 支持
• Google 将 MCP 集成到 Vertex AI
• Microsoft 在 Copilot Studio 中添加了 MCP
• Cloudflare 推出了 MCP 网关产品
• Gitee（中国版 GitHub）发布了开源 MCP 服务器

当所有主要 AI 玩家在协议发布后数月内纷纷采用同一个协议时，你就知道它触动了某种本质需求。MCP 正在成为 Agent 与软件对话的事实标准。

这对今天的每个开发者意味着什么

API 设计：从”人类友好”到”Agent 优化”

大多数 API 设计建议都聚焦于人类：可读的字段名、友好的错误提示、可预测的响应结构。这些仍然有效——但还不够。

面向 Agent 的 API 需要：

• Token 高效的数据格式：TOON 比 JSON 减少 30–60% 的 Token 消耗，直接降低 API 成本
• 精确的 Schema 定义：Agent 需要明确的字段约束，不只是”name 是字符串”——用 JSON Schema 或 Pydantic 模型
• 批量操作：处理 1000 条记录的 Agent 不想做 1000 次 API 调用——设计支持批量请求的端点
• 幂等性：Agent 会重试，你的 API 应该优雅处理重复请求
• 结构化输出：Agent 更擅长处理 {"result": "..."} 而不是 "Here is your result: ..."

软件架构：从前后端分离到 Agent 直连后端

传统架构——前端服务人类，后端处理逻辑——正在被新模式取代：

传统模式：
人类 → 前端界面 → API → 后端 → 数据库

Agent 时代：
AI Agent → MCP Server → 后端 API → 数据库
               ↑
         （人类仅在异常/审批时介入）

在这个模型中，MCP Server 充当翻译层。它以标准化格式将你现有的后端暴露给 Agent。你不需要重建后端，只需要一个包装它的 MCP Server。

安全：从防止人类失误到管理 Agent 行为

传统 API 安全假设人类在做出深思熟虑的调用。Agent 安全需要考虑：

• 数量：Agent 可能在 10 秒内发起 10000 次调用。Rate Limiting 必须针对 Agent 行为模式设计
• 身份：是哪个 Agent 在调用？是否被授权？追踪 Agent ID，而非仅仅追踪 API Key
• Agent 与人类的区分：你是否允许 Agent 删除记录？可能不应该，除非有人类批准
• 审计追踪：如果 Agent 做出错误决策，你需要精确追溯：哪个 Agent、哪个提示词、哪段上下文导致了它

诚实的反驳

批评者会说：”人类仍然在使用软件。人类界面不会消失。”这是对的——但他们没有抓住要点。转变不在于取代人类用户，而在于比例的变化。

考虑一个现代 SaaS 产品。它有 1000 个偶尔登录的人类用户。但这 1000 个用户背后，是几十个 AI 助手、RAG 管道和自动化工作流，每小时调用 API 数千次。该软件的主要用户——与它互动最频繁的实体——是 Agent。

而且这个比例还在加速增长。每当有人部署一个阅读文档、调用 API、自动化工作流的 AI 助手，Agent 与人类的比例就上升一点。

如何准备：一份实用清单

你不需要重建一切。从今天开始，你可以做这些事情：

• 采用 MCP：如果你有工具或数据源，通过 MCP 将其暴露出来。这只需要几天，而非几个月
• API 优先设计：在构建（或与 UI 一起构建）UI 之前，先构建 API。API 是产品，UI 是可选的
• 为 Agent 优化：使用高效的数据格式、精确的 Schema、批量端点。你的 Agent 用户会感谢你（间接地，通过更低的 API 成本）
• 添加 Agent 身份认证：区分 Agent 调用和人类调用。追踪 Agent ID。记录 Agent 行为
• 思考”无界面”：问自己：”一个称职的 Agent，仅使用我们的 API，能完成人类能完成的一切吗？”如果不是，还缺什么？
• 构建 MCP Server：如果你有数据或工具，总会有人想要它们的 MCP Server。做那个构建它的人——或者别人会替你做

未来属于 Agent-Ready 的人

软件一直在做一件事：减少摩擦——人与人之间的、系统与系统之间的、意图与结果之间的。AI Agent 是这波减少摩擦的最新浪潮。他们是不眠的用户、永不遗忘的用户、无限扩展的用户。

早早认识到这一转变的开发者，将构建 Agent 运行其上的平台、协议和工具。未能认识到的开发者，将在他们软件已被 Agent 超越之后，还在为人类维护界面。

你不需要在服务人类和服务 Agent 之间做选择。但你应该问自己：如果 AI Agent 是你的主要用户，你的软件能通过考验吗？

常见问题