AI Agent 正在改变软件采购模式

前言

2025年底，Cognition Labs 的 Devin 拿下了第一批企业订单——不是卖 License，而是按“完成任务数”收费。几乎同一时间，OpenAI 把 ChatGPT Enterprise 的定价模型从“按席位”改成了“按消耗”混合计费。这两件事放在一起看，指向同一个趋势：AI Agent 正在从根本上改变企业购买软件的方式。

过去三十年，软件采购的核心逻辑没怎么变过——选型、比价、签合同、部署、培训、续费。但当软件从“被人操作的工具”变成“自己干活的 Agent”，这套逻辑就开始松动了。本文从技术架构和产业实践两个维度，聊聊这件正在发生的事。

目录

一、传统软件采购：一个正在过时的流程

二、Agent 原生架构：软件形态的根本变化

三、新采购模式：从“买工具”到“雇能力”

四、技术实现：Agent 驱动采购的核心架构

五、企业落地的真实挑战

六、写在最后

一、传统软件采购：一个正在过时的流程

企业买一套 CRM 要多久？Gartner 2024 年的数据是平均 7.2 个月。这还不算后续的实施周期。一个典型的 SaaS 采购流程大概长这样：业务部门提需求 → IT 部门出选型报告 → 采购部门走招标 → 法务审合同 → 财务批预算 → 上线部署 → 员工培训。

这套流程的底层假设是：软件是一个需要人来操作的工具，所以要确保买对了、人会用。

但问题是，当 Agent 能自己完成任务时，“人会用”这个前提就不存在了。你不需要培训员工使用一个 Agent，就像你不需要培训一个外包团队怎么用他们自己的工具一样。

2025 年发生了几件标志性的事：

• Salesforce 推出 Agentforce，企业不再购买 CRM 席位，而是购买“自动处理客户工单的能力”，按解决的工单数量计费。
• ServiceNow 的 Now Assist Agent 开始按“成功关闭的 IT 事件”收费，而不是按 ITSM 平台的用户数。
• GitHub Copilot 从代码补全工具演变为 Copilot Workspace，2026年进一步升级为可以自主完成 Issue 到 Pull Request 全流程的 Agent，定价逻辑从“开发者席位”转向“完成的开发任务”。

这不是渐进式变化，是底层逻辑的切换。

二、Agent 原生架构：软件形态的根本变化

要理解采购模式为什么会变，得先看清楚 Agent 在技术上跟传统 SaaS 有什么本质区别。

传统 SaaS 的架构可以简化为：用户 → UI → 业务逻辑 → 数据库。用户是驱动者，软件是被动响应的。

Agent 原生架构则完全不同。核心变化有三点：

第一，决策循环内置了。Agent 有自己的 Perception-Reasoning-Action 循环，能感知环境、做出判断、执行动作，不需要人在中间拨一下动一下。

第二，工具调用是动态的。一个 Agent 不绑定单一软件，它通过 MCP（Model Context Protocol）或 Function Calling 动态调用多个工具和 API。今天用 Slack 发消息，明天切到飞书，对 Agent 来说只是换个 API endpoint。

第三，能力是可编排的。多个 Agent 可以组成协作网络，就像一个虚拟团队。2026 年，OpenAI 的 Swarm 框架和 Anthropic 的 Claude Agent SDK 都已经在生产环境中支持多 Agent 编排。

下面这张图展示了 Agent 原生架构与传统 SaaS 架构的对比：

这张架构对比解释了为什么采购逻辑必须变：当 Agent 能动态调用任意工具时，“买一套固定软件”这件事本身就失去了意义。

三、新采购模式：从“买工具”到“雇能力”

传统模式下，CIO 的问题是“我们需要买什么软件”。Agent 时代，问题变成了“我们需要什么能力”。

这个转变催生了三种新的采购模式：

模式一：按结果付费（Outcome-based）。Salesforce Agentforce 每解决一个客户问题收 2 美元，不管它调用了多少内部服务。企业不再为“拥有 CRM”付费，而是为“客户问题被解决”付费。

模式二：能力市场（Capability Marketplace）。类似 OpenAI 的 GPT Store 和 Anthropic 的 Tool Use 生态，企业在一个市场里按需订阅各种 Agent 能力——数据分析、合同审核、代码审查、客户外呼——随用随取，不满意就切换。

模式三：自建 + 编排（Build & Orchestrate）。技术能力强的企业直接用 Claude Agent SDK、LangGraph 或 CrewAI 搭建自己的 Agent 网络，把各家的模型和工具 API 编排起来，完全掌控决策链路。2026 年，字节跳动的 Coze 平台和阿里的百炼平台已经在为中国企业提供这类编排基础设施。

三种模式的核心共同点是：软件供应商的护城河从“功能完整性”变成了“被 Agent 调用的便利性”。你的 API 好不好用、MCP 适配做得到不到位、响应速度快不快，比你的 UI 漂不漂亮重要一百倍。

四、技术实现：Agent 驱动采购的核心架构

具体到技术实现，一个 Agent 驱动的企业软件采购和使用体系，大致包含四层：

几个值得展开的技术细节：

MCP 协议（Model Context Protocol） 是 Anthropic 在 2024 年底提出、2025 年被行业广泛采纳的开放协议。它解决的核心问题是：让 Agent 能用统一的方式连接任意外部工具和数据源。到 2026 年中，主流企业软件厂商基本都提供了 MCP Server 适配，这意味着 Agent 能像调用函数一样调用 Salesforce、SAP、飞书等系统的能力。

人机协作断点（Human-in-the-Loop）是生产环境的刚需。Agent 不是无限制自主运行的——涉及金额超过阈值的采购审批、涉及敏感数据的操作、首次执行的新任务类型，都会触发人工确认。这个机制的实现依赖 Agent 框架的中断和恢复能力，Claude Agent SDK 和 LangGraph 都原生支持。

可观测性 在 Agent 架构下变得格外重要。传统软件出了 bug 看日志就行，但 Agent 的决策过程是个黑箱。2026 年的做法是通过 OpenTelemetry + LLM 专用的 Trace 方案（如 LangSmith、Arize Phoenix）记录每一步推理和工具调用，出问题能回溯完整的决策链。

五、企业落地的真实挑战

说了这么多好处，也得讲讲落地时的坑。

第一个坑：成本不可预测。按结果付费听起来很美，但 Agent 的 Token 消耗波动很大。同样是“处理一张发票”，简单的可能花 0.02 美元，遇到异常情况可能花 2 美元——差了 100 倍。企业财务部门很难做预算。目前的应对办法是设置 Token 预算上限 + 任务级别的成本阈值告警，但这个问题还没有完美解。

第二个坑：供应商评估体系失效。传统的 RFP（Request for Proposal）流程完全不适用于 Agent 采购。你没法在 RFP 里写“要求 Agent 解决问题的准确率达到 95%”——因为“准确”的定义在不同场景下完全不同。一些先行企业的做法是搞 “Agent 试用期”：先用小规模真实任务跑两周，拿真实数据说话。

第三个坑：安全边界模糊。Agent 需要调用多个系统的 API，权限怎么给？传统的 RBAC（基于角色的访问控制）是给人设计的，Agent 的权限应该是动态的、基于任务的、有时效的。2026 年的最佳实践是采用 “最小权限 + 即时授权 + 操作审计” 的三层机制，但各厂商的实现还很碎片化。

第四个坑：组织架构跟不上。当 Agent 能自己完成 80% 的 IT 支持工单时，IT 支持团队的角色就得转型——从“解决问题的人”变成“监督 Agent 解决问题的人”。这个转变涉及岗位重新定义、KPI 调整、甚至部门重组，技术层面反而是最简单的。

六、写在最后

回过头看，软件行业每次大的采购模式变革，都伴随着软件形态的根本变化：

• 大型机时代 → 买硬件 + 定制开发
• PC 时代 → 买 License
• 云时代 → 订阅 SaaS
• Agent 时代 → 购买能力/结果

我们正处在第三到第四阶段的过渡期。2026年的现状是：大部分企业还在用传统方式采购，但领先企业已经开始把 Agent 作为独立品类来评估和采购。IDC 预计到 2028 年，全球 30% 的企业软件支出将以“按结果付费”的方式结算。

对于 CIO 们来说，现在要做的不是急着把所有软件都换成 Agent，而是：先在 1-2 个高 ROI 场景跑通 Agent 采购的全流程——从需求定义、能力匹配、试用评估到成本核算——积累组织经验。

技术已经就绪，剩下的是组织和流程的适配。这件事，宜早不宜迟。