AI与Agent时代的软件生死线

这两年，几乎所有软件圈的争论都会收束到一句话：在 AI、Agents 与 Skill 的新时代里，所有现存软件只有把自己演变成 Open API，才能继续存活。

这句话很有煽动性，也很像一个时代判断。但它到底是洞察，还是口号？

我的结论是：方向对，但表达错；趋势真，但结论过度。

真正到来的，不是“所有软件都会只剩 API”，而是一个更深层的变化：软件的主界面，正在从“人类点击界面”转向“人类界面 + 机器界面并存”；软件的主竞争力，也正在从“功能堆砌”转向“能否被 agent 安全发现、准确理解、可靠调用、可审计执行、可持续结算”。

一、为什么这句话突然变得流行？

原因很简单：AI 正在把“软件使用方式”改写成“软件调用方式”。

过去二十年，大多数软件默认假设是：

• 用户打开一个 App 或网页；
• 在图形界面里点击、填写、拖拽、确认；
• 软件在自己的封闭流程中完成任务。

但在 agent 时代，这个假设正在松动。越来越多任务，不再由人一层层点按钮，而是由 agent 代为完成：检索资料、编排工作流、查询系统、调起工具、跨系统执行流程。

这也是为什么 OpenAI 在 2025 年 3 月推出新一代“构建 agents 的工具”时，把 Responses API 定位为“构建 agentic applications 的更灵活基础”，并提供 web search、file search、computer use 等内置工具：平台本身已经把“调用工具完成任务”放到了中心位置。[1]

微软在 Build 2025 上进一步把这个方向表述为 open agentic web：一个由 AI agents 代表个人与组织作出决策、执行任务的开放网络环境。[2]

Google 则在 2025 年 4 月正式发布 A2A（Agent2Agent），强调不同 agent 之间要能够安全交换信息、协调动作、跨企业系统协同；随后又在 2025 年 6 月把 A2A 捐赠给 Linux Foundation，推动其成为更中立的开放协作项目。[3][4]

Anthropic 推动的 MCP（Model Context Protocol）则瞄准另一个关键问题：让模型和 agent 能以标准方式连接工具、数据与应用，减少每接一个系统就做一套定制集成的成本；到了 2025 年末，Anthropic 进一步将 MCP 捐赠给 Linux Foundation 下的 Agentic AI Foundation，推动其成为中立治理的开放基础设施。[5][6]

从这些动作可以看到，头部平台在做的，并不是“取消软件”，而是把软件重新组织为：

1. 可被模型理解的能力；
2. 可被 agent 调用的接口；
3. 可在多 agent 生态中流转的上下文；
4. 可被治理、审计和付费的执行单元。

也因此，“软件必须 API 化”这句判断才会迅速流行。因为它抓住了一个真的趋势：未来不会被调用的软件，会越来越边缘。

但问题也在于，它把一个“必要能力”说成了“唯一出路”。

二、先给结论：API 会成为必要能力，但不会成为软件唯一形态

如果把那句流行判断拆开看，它其实包含了三个层次：

第一层：软件必须变得更开放、更可调用、更机器可读

这一层，基本成立。

在 agent 时代，软件若仍然只服务“人类手工操作”，却没有任何机器可理解、可调用、可验证的外部能力层，就会越来越难进入新的流量入口。因为未来大量任务分发，不是来自用户打开首页，而是来自 agent 的任务编排、系统的自动推荐、模型的工具选择。

第二层：软件必须拥有 API

这一层，大体也成立，但要注意，这里的 API 已不只是传统 REST API。

新的“机器接口”包括但不限于：

• 传统 Open API / REST / GraphQL；
• MCP server 这类面向模型与 agent 的工具暴露方式；
• A2A 这类 agent 间协作协议；
• 结构化网页与 Markdown，让 agent 能更稳定理解内容；
• AGENTS.md 这类为 agent 提供项目级规则与上下文的约定；
• 支持 agent 身份、签名、权限和审计的认证机制。

换句话说，未来软件必须有“机器接口层”，但未必只等于传统 public API 文档。

第三层：谁不变成 open API，谁就会死

这一层，明显过度。

因为软件能不能活下去，取决于的不只是“能否被调用”，还取决于：

• 是否拥有独特数据；
• 是否掌握高价值工作流；
• 是否沉淀行业 know-how；
• 是否建立信任、权限与合规壁垒；
• 是否掌控结算、分发或网络效应；
• 是否具备优秀的人机协同体验。

API 化只是入场券，不是免死金牌。

三、为什么“Open API 万能论”会误导很多人？

因为它低估了软件的三种真实护城河。

1. 不是“接口”本身值钱，而是“接口后面的能力”值钱

任何团队都可以在几周内把一套基础 CRUD 服务封装成 API。真正难的是：

• 这个 API 连接的是不是稀缺数据？
• 它触发的是不是关键流程？
• 它输出的结果是否高可靠？
• 它是否能在复杂权限和合规要求下运行？
• 它是不是已经嵌入客户核心业务？

很多创业者听到“API-first”就觉得自己找到了未来方向，于是急着把产品“接口化”。但没有高价值能力做支撑，API 只是把平庸功能更快地暴露出去。

2. 在 agent 时代，接口数量不是壁垒，默认入口才是

过去是“谁的功能强，谁赢”；

未来更可能是“谁最容易被 agent 选中，谁赢”。

这意味着竞争焦点会从：

• 功能列表 转向：
• 能否被模型正确理解；
• 能否被 agent 稳定选择；
• 能否在多工具编排中表现可靠；
• 能否提供清晰、低歧义、低失败率的执行反馈。

一个 API 再开放，如果描述不清、权限复杂、错误码混乱、成功率不稳定，agent 也不会优先调用它。

3. 很多软件的核心价值，并不是“被调用”，而是“承载责任”

例如 ERP、核心财务系统、医疗系统、政府系统、工业控制系统。它们的价值，不只是让外部工具接进来，而是：

• 确保流程合规；
• 保证数据正确；
• 维护责任边界；
• 控制审批和审计链路；
• 防止高风险自动化误操作。

因此，这类系统不会简单走向“完全开放”。它们更可能走向的是：受控开放、分层开放、可审计开放。

也就是说，未来真正重要的不是“open API 越多越好”，而是“在什么权限范围、以什么责任模型、让什么 agent、调用什么能力、留下什么审计痕迹”。

四、头部公司到底在推动什么？从最新官方动作看真实方向

1. OpenAI：不是在推动“所有软件 API 化”，而是在推动“软件能力 agent 化”

OpenAI 2025 年 3 月发布的官方文章里，最值得注意的一句话不是“API”，而是 building agents。[1] Responses API 的意义在于，它把模型调用、工具使用、任务状态和多步骤执行放到一个更统一的框架里。它不是单纯替代旧接口，而是在定义一种新的应用范式：应用不再只是响应请求，而是让模型在上下文中持续调用工具，逐步完成任务。

这意味着，未来的软件若想融入 OpenAI 生态，确实需要让自己的能力可被调用；但它更要考虑的是：

• 如何把业务能力抽象成 agent 可理解的 action；
• 如何提供稳定、结构化的输入输出；
• 如何给模型提供边界、权限和异常处理。

这已经超出传统“开放个 API 文档”的范畴。

2. Anthropic 与 MCP：重点不是“开放给所有人”，而是“标准化连接工具与上下文”

MCP 的流行，本质上击中了一个现实问题：过去每个平台都要为每个工具做一套私有集成，成本高、碎片化严重。MCP 希望用通用协议把模型、工具、数据源连接起来，让 agent 能更稳定地调用外部能力。[5][6]

这说明真正关键的不是“API 开没开放”，而是：你的软件能否进入标准协议生态，被更低成本地接入。

未来一个软件即便没有面向公众开放的传统 Open API，只要它能通过 MCP 暴露关键能力，同样可能成为 agent 生态中的重要节点。

3. Google 与 A2A：问题不只是“能不能调工具”，而是“多个 agent 怎么协同”

A2A 的意义在于，它把问题从“模型调用工具”推进到“agent 与 agent 的协作”。Google 发布 A2A 时就强调，其目标是让不同平台上的 agent 能安全交换信息并协调行动；Linux Foundation 接手后，则把它放到更中立的产业共建框架里。[3][4]

这预示着下一阶段的竞争，不只是单个软件把功能暴露出来，而是：

• 一个采购 agent 如何与 CRM agent、财务 agent、法务 agent 协同；
• 一个企业内 agent 如何与外部供应商 agent 通信；
• 谁来认证 agent 身份；
• 谁来追踪执行责任；
• 谁来定义消息结构、任务状态和失败恢复。

这也说明，“把自己变成 open API”只是第一步，真正更高阶的是：把自己变成一个合格的 agent 节点。

4. Microsoft：不是 API-first，而是“开放 agentic web”

微软在 Build 2025 的官方表述非常值得玩味。它不是说“未来所有软件都是 API”，而是说，互联网正在走向一个 open agentic web，agent 将代表用户和组织跨越应用与站点执行任务。[2]

这说明微软看到的是入口迁移：

• 搜索入口在变；
• 办公入口在变；
• 浏览入口在变；
• 应用间流量分发机制也在变。

对于软件厂商而言，这意味着未来争夺的不只是用户点击，而是 agent attention，也就是：你的服务会不会被 agent 发现、信任、推荐与执行。

五、所以，“所有软件都得变成 Open API”这句话，哪些地方说对了？

1. 它说对了一个大趋势：软件必须拥有机器可调用层

这是最重要的判断。

未来不具备机器可调用层的软件，会越来越像“没有移动端的网站”——不是立刻消失，但会逐步失去增长机会，尤其会失去新入口带来的自然流量。

2. 它说对了一个权力转移：前台 UI 的支配力正在下降

今天的软件仍然离不开界面，但界面不再是唯一入口。越来越多高频任务会绕过 UI，直接由 agent 调用底层能力完成。

这会让很多软件公司重新思考产品设计：

• 哪些能力要给人看？
• 哪些能力要给 agent 调？
• 哪些结果要让人审批？
• 哪些任务可以自动闭环？

3. 它说对了一个残酷现实：封闭系统会越来越难被纳入主流工作流

如果软件完全封闭，不支持任何标准化对接，那么在企业环境里，它会越来越像一个“孤岛”。孤岛不是不能生存，但生存成本会上升：

• 集成成本高；
• 迁移风险高；
• 自动化能力弱；
• 上下游协同差；
• 被替代概率高。

六、但这句话最危险的误区，也恰恰在这里

误区一：把“Open API”当成全部，而忽视“协议、上下文与治理”

在 agent 时代，机器调用的成功率不只取决于有没有 API，还取决于：

• 描述是否清晰；
• schema 是否稳定；
• 权限是否细粒度；
• 结果是否结构化；
• 错误是否可恢复；
• 是否支持身份与审计；
• 是否能与 MCP、A2A、网页结构化内容等生态衔接。

Cloudflare 在 2025 年明确提出“Markdown for Agents”的思路，强调开放网络内容如果想被 agent 正确消费，就需要更适合机器理解的内容表达方式。[7]

这说明，机器接口不止是 API endpoint，它还包括内容格式、上下文文档与执行约定。

误区二：把“开放”理解成“免费开放”或“无门槛开放”

真正成功的软件，不会因为 agent 时代来临，就把核心能力无差别公开。相反，越高价值的能力，越会：

• 分级开放；
• 按身份开放；
• 按场景开放；
• 按配额与结算开放；
• 在审计和合规条件下开放。

未来的默认状态不是“大家都裸奔开放”，而是“大家都变成 programmable，但带着更强的权限控制与策略执行”。

误区三：误以为接口开放后，流量自然会来

这几乎是最大幻觉。

在 agent 世界里，调用不是民主投票，而更像算法分发。谁被调用，取决于：

• 模型是否认识你；
• 协议是否兼容；
• 任务成功率是否高；
• 历史反馈是否好；
• 成本是否合理；
• 调用后是否容易审计和追责。

所以未来的竞争，并不是“开了 API 就完事”，而是谁能成为 agent 的默认供应商。

七、哪些软件会最先被迫“API 化 / Agent-ready 化”？

第一类：本来就处在工作流中枢的软件

例如 CRM、ERP、协同办公、客服、营销自动化、财务流程、开发工具链。

这些软件天然位于企业工作流核心，一旦 agent 大规模进入组织，这些系统就必须成为可调用节点，否则无法融入自动化链条。

第二类：高频、标准化、结果明确的软件能力

例如：

• 搜索与检索；
• 文档处理；
• 数据查询；
• 报表生成；
• 工单流转；
• 预约与调度；
• 支付与对账；
• 消息触达。

这类能力最适合被 agent 编排，因此最先需要标准接口化。

第三类：被用户“顺手调用”而不是“沉浸使用”的软件

如果一个产品的价值本来就不是让用户在界面里待很久，而是快速完成某个动作，那它就更容易在 agent 时代被重构为能力层。

例如订票、查价、库存同步、审批触发、发票开具、基础设计生成等。

八、哪些软件不会简单沦为 API？

1. 强体验型产品

游戏、社交、内容社区、创作工具、专业设计工具、娱乐产品，它们的价值不仅是完成功能，更是体验本身。

这类产品当然也会增加机器接口，但不会因为 agent 时代到来就“退化成后台能力层”。

2. 高责任、高风险、高合规系统

在金融、医疗、政务、工业等领域，自动化不是唯一目标，责任控制更重要。因此这些软件会引入 agent，但通常是“有人类监督的 agent”“分级授权的 agent”“可追责的 agent”。

3. 依赖复杂协作与判断的人机系统

许多产品的核心价值，来自复杂协作，而不是简单执行。例如企业战略工具、复杂项目管理、投行工作流、临床决策支持等。它们不会消失成 API，而会演化成agent + 专家 + 系统的混合体。

九、真正的生死线是什么？

如果不是“有没有 open API”，那未来软件真正的生死线是什么？

我认为有六条。

1. 能否被 agent 发现

你的能力有没有标准描述？有没有足够清晰的文档、schema、元数据、权限说明？

2. 能否被 agent 理解

输入输出是否结构化？结果是否低歧义？失败场景是否定义清楚？

3. 能否被 agent 可靠调用

调用成功率、延迟、幂等性、异常恢复、速率限制，这些会直接决定你是否进入 agent 默认工具箱。

4. 能否在组织中被放心使用

是否支持身份认证、权限隔离、审计日志、策略控制、合规边界？

5. 能否在多 agent 生态中协同

是否支持标准协议与上下文交换？能否与 MCP、A2A、企业内部代理层协同？

6. 能否建立可持续商业模式

即便被 agent 调用，也要回答：

• 如何计费？
• 如何防止被中间层抽象掉价值？
• 如何维护品牌与客户关系？
• 如何保留议价权？

未来不是“谁开放谁赢”，而是“谁既开放又不被商品化，谁赢”。

十、软件公司接下来最该做的，不是盲目开放，而是重构产品栈

第一，补上机器接口层

不管采用 REST、GraphQL、MCP，还是私有 agent adapter，首先都要让核心能力可编程、可调用、可观测。

第二，把产品能力改写成 agent 能理解的动作

不要只是暴露数据库字段，而要暴露“任务单元”。例如不是提供 17 个低层接口，而是提供：

• 创建采购申请；
• 审核合同状态；
• 生成对账报告；
• 发起客户续约流程。

第三，重做权限与治理体系

未来调用者不只是人，还有 agent。因此权限模型、审计日志、责任链条都要重构。

第四，建设可被发现的描述层

包括：

• 标准化文档；
• 清晰 schema；
• 示例调用；
• 机器可读说明；
• 对 agent 的约束说明。

第五，重新定义商业模式

过去按 seat 收费的产品，未来可能要增加：

• usage-based 收费；
• 按任务收费；
• 按调用层级收费；
• 按 agent 成功结果收费；
• 按企业治理能力收费。

十一、对中国软件公司而言，这个判断尤其值得警惕

中国市场过去很长时间偏重“项目制、定制化、重交付”，不少软件公司的核心优势是关系、实施与本地化，而不是标准化产品能力。

但在 agent 时代，如果一个软件无法把关键能力抽象成标准动作、无法被接入主流模型与 agent 平台，它会面临一个新问题：

你可能仍然有客户，但你会逐渐失去成为“默认能力节点”的机会。

这意味着未来的软件竞争，不只是卖给谁，而是看：

• 你是否能进入客户的 AI 工作流；
• 你是否能成为平台默认调用能力；
• 你是否在新一代协议和工具链里有席位。

对很多企业软件厂商来说，真正危险的不是今天收入下滑，而是明天在 agent 生态中“不可见”。

十二、最后的判断：未来活下去的软件，不一定都变成 Open API，但一定会变成 Agent-ready

所以，回到最初那句话：

“在 AI 与 Agents/Skill 的新时代里，所有现存软件只有把自己演变为 open api 才能存活下去。”

我的判断是： 这句话抓住了趋势，但说错了终局。

更准确的表述应该是：

在 AI 与 agent 时代，所有软件都必须拥有可被机器理解和调用的能力层；但真正决定其生死的，不是是否提供 open API，而是能否成为一个被 agent 安全发现、标准接入、可靠执行、持续结算的能力节点。

也就是说：

• 不是所有软件都会变成 API 公司；
• 但所有软件都会被迫思考自己的“机器接口”；
• 不是所有产品都会失去 UI；
• 但 UI 不再是唯一入口；
• 不是开放就能赢；
• 但封闭到无法接入，几乎一定会输。

未来十年，软件行业真正的大分化，不会发生在“做不做 AI”之间，而会发生在两类公司之间：

1. 仍把软件理解为“给人点的界面”；
2. 已把软件重构为“给人使用、也给 agent 调用的能力网络”。

前者还能活一段时间；后者，才更有可能活进下一个时代。

参考资料

[1] OpenAI, New tools for building agents, 2025-03-11. https://openai.com/index/new-tools-for-building-agents/^[1]

[2] Microsoft, Microsoft Build 2025: The age of AI agents and building the open agentic web, 2025-05-19. https://blogs.microsoft.com/blog/2025/05/19/microsoft-build-2025-the-age-of-ai-agents-and-building-the-open-agentic-web/^[2]

[3] Google Developers Blog, Announcing the Agent2Agent Protocol (A2A), 2025-04-09. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/^[3]

[4] Google Developers Blog, Google Cloud donates A2A to Linux Foundation, 2025-06-23. https://developers.googleblog.com/en/google-cloud-donates-a2a-to-linux-foundation/^[4]

[5] Anthropic, Introducing the Model Context Protocol, https://modelcontextprotocol.io/^[5]

[6] Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation, 2025-12-09. https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation^[6]

[7] Cloudflare, Markdown for Agents, 2025. https://blog.cloudflare.com/markdown-for-agents/^[7]

[8] Linux Foundation, Linux Foundation launches the Agent2Agent Protocol Project, 2025-06-23. https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents^[8]

[9] Linux Foundation, Linux Foundation announces the formation of the Agentic AI Foundation, 2025. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation^[9]

引用链接