版权申明：本站为公益科普网站，版权归原作者所有，如有侵权，请联系我们
发布时间：2026-07-31 来源：中移科协
AI Agent正逐步成为软件的核心使用主体。当下，自动化网络流量占比已过半，软件行业正在经历继大型机、PC、移动互联网之后的第四次“用户迁移”。本文围绕 AI Agent 成为 “一等用户（即与人类用户拥有同等系统地位，可被识别、交互、审计与追责的系统参与者）”这一核心，从身份、交互、权限、安全四大维度解读产品设计的全新内涵，分析此次变革带来的开发者角色、商业模式、委托代理风险等连锁影响，并对比 CLI、MCP 等主流技术路线，探讨面向 AI Agent 的产品基础设施建设方向。
1、软件行业正在经历第四次用户迁移
当下，软件行业正发生一场关乎用户主体的根本性变革。据Imperva相关报告统计，自动化流量在全网流量中的占比已达51%，十余年来首次超越人类产生的流量，AI Agent正在成为软件的主要使用者。想要透彻理解这场变革，需要结合软件行业发展的历史脉络来看，如今行业正迎来第四次 “用户迁移”。
第一次是大型机时代，软件使用者以专业机房操作员为主，交互载体为打孔卡与命令行；第二次是 PC 时代，用户群体拓展至办公人群，图形窗口、鼠标成为主流交互方式；第三次是移动时代，智能手机普及让软件走向全体大众，触屏交互成为主流。每一次迁移的共性规律，即旧时代的行业巨头，往往因深耕原有交互模式形成路径依赖，难以适配新的用户形态与交互逻辑。诺基亚凭借实体键盘打造出极致体验，却在触屏时代沦为发展桎梏；众多 SaaS 厂商深耕数十年，打磨出适配人类操作的界面与流程，而这套成熟体系，对于 AI Agent 而言反倒成了运行阻碍。
第四次用户迁移的核心变化，是使用主体变为AI Agent，交互形态也从图形用户界面（GUI）逐步转向 API 与命令行界面（CLI）。这并非CLI的复古回潮——该交互形式自诞生以来始终存在，真正的核心转变在于AI Agent无须依附专为人类打造的视觉翻译层。GUI 的本质，是将底层 API、命令行指令转化为按钮、菜单、拖拽控件等人类易理解的视觉形态；但 AI Agent 原生适配 API 指令，视觉界面反而会增加其操作成本：Agent 需要先解析页面结构、定位交互控件、模拟人为操作、等待页面加载，最后再解析返回数据，整套流程效率低下。
基于以上变化，本文提出核心议题：当软件用户从单一人类群体拓展至人类与AI Agent 双重主体后，产品开发需要做出哪些根本性调整？这场变革并非简单的功能迭代，而是需要围绕身份、交互、权限和安全完成架构重构，同时也会推动开发者角色、商业模式、组织形态发生系统性转变。
2、产品需从四个维度为“一等用户”重新设计
“一等用户” 借鉴编程领域概念，指某类实体在系统中享有与核心主体对等的权利、义务与身份地位。将 AI Agent 定义为一等用户，意味着它不再是隐匿于 API 调用背后的匿名脚本，而是拥有独立身份、可被系统识别审计、支持协同交互、行为可追溯追责的正式系统参与者。
结合 Anthropic 多款产品的工程实践、Linear 业务系统落地案例，以及钉钉、飞书对 CLI 架构的改造经验，可将 “AI Agent成为一等用户” 拆解为四个相互支撑、环环相扣的产品设计维度。
①身份层
系统需为 AI Agent 配置持久化、可独立引用的专属身份标识。该身份区别于临时 API 调用凭证，是和人类用户平级的系统实体。以 Linear 为例，平台将 AI Agent 纳入人员管理体系，支持对其进行启用、运维、行为追踪等全流程操作。
在此模式下，AI Agent 成为团队协作网络中的独立节点，可被团队成员 @提及、分配任务，相关行为与工作内容也会同步展示在项目看板中。身份层是所有后续能力的基础：若 AI Agent 缺少独立身份，权限分配、行为审计、责任界定等工作都将无从开展。
②交互层
面向 AI Agent 的产品交互，不应仅提供零散的 API 接口，而需搭建一套完整、规范的交互协议。这套协议明确 AI Agent 接入系统、传递执行意图、接收结果反馈的全流程规则，同时具备双向属性：一端对接下达指令的人类使用者，另一端连通 Agent 需要调用的外部工具与服务，二者共同构成面向智能体的产品接口体系。
人机协同下发指令的场景看似简单，实则暗藏安全风险。复杂的 GUI 界面会扩大提示注入的攻击范围，攻击者可利用多样化 UI 元素植入隐藏指令，诱导 Agent 执行恶意操作。而 CLI因为交互逻辑简洁纯粹，将成为人与 AI Agent 之间稳定性最强、信任边界最清晰的交互方式。2026 年 3 月，钉钉、飞书相继推出 CLI 工具：钉钉完成全产品 CLI 改造，开放 12 大服务模块的命令行接口，支持 AI Agent 像调用本地系统指令一样使用平台能力；飞书采用 “快捷命令 - API 命令 - 原生 API” 三层架构，顶层通过专属前缀简化参数配置，降低 AI Agent 的调用门槛。
如果说 CLI 打通了人与 Agent的交互通道，那么 MCP（模型上下文协议）则实现了Agent 与外部工具的互联互通。AI Agent 想要发挥实际价值，必须具备调用各类第三方工具的能力，而 MCP 作为标准化通用协议，相当于统一的接入规范，让 Agent 能够快速发现、调用外部服务。对产品开发者而言，标准化协议省去了为不同工具单独适配接口的重复工作，真正实现 “即插即用”。
综合两类交互形态，交互层的完整逻辑得以明确：CLI 负责人与 Agent 的协同通信，MCP 负责 Agent 与外部生态的连接。这套设计秉持接口优先的核心理念，产品不再只是供人类浏览、点击的可视化载体，而是兼顾人类与AI Agent读写、调用、协同作业的综合任务环境。适配 Agent 的使用文档，也从传统图文教程转变为标准化接口说明。
③权限层
必须为 AI Agent 划定清晰、可审计、可动态管控的权限边界。权限设计需要在两大目标之间寻求平衡：既要保证 Agent 拥有足够权限完成业务动作，又要严格约束权限范围，规避误操作和越权操作带来的风险，这既是安全管控的要求，也是产品架构设计的核心要点。
国内办公产品已形成成熟实践：钉钉采用无感认证机制，让 AI Agent 合理继承企业组织权限，同时搭配批量操作熔断、安全沙箱能力，防范 Agent 批量执行任务时失控；飞书支持按业务域精细化申请权限，例如仅开放日历、任务模块权限，无须授予全平台权限，实现最小权限管控。
权限设计中有一个极易被忽视的核心议题，即AI Agent 的权限体系该如何与人类用户绑定。目前主要分为两种模式：一是直接继承所属人类用户的全部权限，优势是Agent可无缝承接人工常规工作，短板在于风险集中，一旦遭遇提示注入攻击，攻击者将间接获取完整用户权限；二是为Agent配置独立权限体系，安全性显著提升，但也会增加权限配置、日常管理的复杂度。两种模式各有优劣，产品设计需结合业务场景灵活选择。
④安全层
安全层是身份、交互、权限三层架构的最终兜底防线。当 Agent 身份被伪造、接口被恶意滥用、权限被非法绕过时，环境隔离机制将阻断风险扩散。Anthropic 在 Claude Code 迭代过程中积累了典型经验：产品早期出现高危漏洞，在用户手动确认 “信任文件夹” 前，代码就已提前执行。攻击者仅需在代码仓库植入带钩子的配置文件，即可在 Claude Code 启动时触发恶意指令。
这类漏洞的根源在于传统软件基于“人类确认在先、操作在后”的交互逻辑，而AI Agent可自主读取文件、执行代码、发起网络请求，彻底打破了原有的操作时序规则。基于多次安全事件总结，Anthropic确立设计原则：优先通过环境层构建硬隔离，再依托模型层规范 Agent 行为。沙箱、虚拟机、网络出口管控等物理隔离手段是安全底线，即便 Agent 本身被攻破，也能将风险锁定在有限范围内。
身份、交互、权限、安全四层架构相辅相成，共同定义了 AI Agent 作为一等用户的产品形态，任意一环缺失，都会导致 Agent 无法正常融入系统，或是引发不可控的安全风险。
3、“一等用户”将引发三重连锁反应
当软件用户从单一人类群体拓展至 AI Agent，围绕传统用户搭建的整套产品开发生态都会产生连锁变革，主要集中在开发者角色、商业模式、委托代理风险三大方向。
①开发者角色的变化
当Agent成为软件的主要用户，开发者的工作对象和工作方式也随之改变。最直接的变化：开发者需要为“两类用户”设计产品。这意味着传统的“用户研究”不再只关注人类行为。开发者需要理解 Agent 如何“感知”系统——它会调用哪些接口、需要什么样的数据结构、在什么情况下会出错、如何从错误中恢复。这些问题的答案，无法从传统的 UI/UX 方法中获得，而是需要开发者以 Agent 的视角重新审视自己的产品。
更深层的变化体现在工作流程上。在Linear，开发者需要设计“Agent 可以被 @”的功能流程；在钉钉和飞书，开发者需要将整个产品 CLI 化，让 Agent 能像调用系统命令一样调用办公软件；在任何 SaaS 产品中，开发者都需要检查和改造 API 的每一个细节——从认证流程到返回格式，从限流策略到错误码设计——因为 Agent 不会像人类一样“绕过”不友好的接口，它只会直接失败，然后转向下一个竞品。
这一变化的连锁反应正在显现。Every公司的CEO Dan Shipper将这类新型开发者称为“前置部署工程师”——他们的工作不是从零编写功能，而是理解业务需求将 Agent 接入系统、持续观察 Agent 的行为，并在出错时介入修正。这意味着开发者的角色不是被弱化，而是被重新定义。从“为人类用户编写功能”转向“为 Agent 用户设计系统”，从“实现需求”转向“定义 Agent 的能力边界和交互协议”。
②商业模式的潜在重构
AI 将颠覆甚至淘汰 SaaS 行业” 是当下流行的论调，该观点认为用户可借助 AI Agent 直接完成业务，不再需要订阅各类 SaaS 工具。但Dan Shipper提出了相反观点，即SaaS 行业不会消亡，反而会迎来新的增长空间。核心逻辑在于每一位付费人类用户背后，都会配套使用至少一个AI Agent，软件的实际使用主体数量因此被大幅扩充。这一判断也在Every公司内部得到验证：该团队全面落地AI工具后，SaaS 采购支出不降反增，原因并非单品涨价，而是 AI Agent 带来了大量新增使用主体。
与此同时，传统商业模式面临挑战。目前主流的按人类席位收费模式，已无法适配新场景，基于Agent 调用次数、任务完成量、资源消耗量等指标的按量计费模式，有望成为行业新选择。
③委托代理问题
委托代理问题源自经济学理论，核心是当受托方代替委托方做出决策时，如何保障双方利益、诉求保持一致。延伸至软件领域，当 AI Agent 代替人类选择 SaaS 产品、调用 API 服务、采购云资源时，其决策逻辑是否能完全贴合人类诉求，成为新的难题。例如：若某厂商的技术文档更适配 AI 读取，Agent 是否会产生无意识的选择偏向；若某类 API 对 Agent 调用友好，但对人类极不透明，Agent 是否会擅自选择该类服务。本质上，当 AI Agent 成为主流用户后，软件消费的决策权被移交至透明度较低的中间层。
目前行业尚未形成标准化解决方案，现有探索主要分为两个方向：一是决策可审计，即完整记录Agent 每一次选择行为，实现全流程可回溯、可解释；二是偏好对齐，在初始化阶段明确人类使用者的偏好与优先级，让 Agent 按照预设规则执行决策。两种方案都需要产品在架构层面预留配套接口与能力。
4、产品范式向基础设施的延伸仍存断层
前文主要聚焦单一产品的改造设计，而放眼整个数字生态，当 AI Agent 成为全行业通用参与者，配套的底层基础设施建设成为新命题。该问题无法依靠单一产品或单一协议独立解决，目前行业已演化出三类主流技术路线，且仍处于竞争探索阶段。
第一类是以钉钉、飞书为代表的产品全量 CLI 化，让 AI Agent 以原生命令行方式调用产品能力；第二类是以 Anthropic 为代表的托管 Agent 架构，将会话管理、控制框架、安全沙箱解耦，依靠稳定接口支撑 Agent 长期自主运行；第三类则是MCP 标准化协议，致力于打造统一的 Agent 与工具通信标准。结合 ScaleKit 的实测数据来看，CLI 在运行效率、稳定性上优势突出，而 MCP 的核心价值体现在跨生态标准化接入层面。可以形象理解为：MCP 是面向陌生外部生态的通用接入规范，CLI 则是适配内部协同场景的轻量化工具。行业大概率将形成分工格局：CLI 成为 AI Agent 操作独立软件的主流方式，MCP 则定位为开放生态的跨平台接入协议。
除此之外，审计与可观测性成为基础设施建设的另一重点。AI Agent 自主执行任务时，企业需要实时掌握行为主体、操作内容、执行原因等全量信息。这就要求产品不仅要内置日志记录、操作回滚能力，还要支持日志以标准化格式对外输出。这里也存在设计矛盾：Anthropic 在 Cowork产品中发现，虚拟机等强隔离安全方案，会同时屏蔽外部安全监控工具。如何在安全隔离与行为监控之间做好平衡，也是基础设施设计必须攻克的难点。
5、结语
本次产品范式迁移的核心可以概括为现代产品需要同时服务人类与AI Agent两类用户。这句话看似平实，却会引发一系列深度变革：AI Agent 不需要可视化 UI，但需要高适配性的机器接口；不需要传统登录页面，但需要独立持久的身份体系；不需要人工确认弹窗，但需要清晰可控的权限边界；它不会主动发起恶意破坏，但提示注入、环境漏洞等问题，可能诱导其做出高危操作。
对于产品开发者与企业决策者而言，当下的核心问题并非“是否要适配 AI Agent”，而是 “如何有序落地”。本文给出四点落地建议：第一，从接口优化切入，迭代 API 能力，保证接口机器友好、数据模型便于 Agent 识别调用；第二，从内部场景试点，先让 AI Agent 融入企业内部协作，完成场景验证；第三，从小闭环起步，选取高频、低风险的细分场景落地，在实践中积累经验；第四，预留扩展空间，优先保障接口的稳定性与开放性，而非一味堆砌功能，为未来AI能力迭代留出余地。
发布时间：2026-07-31 来源：中移科协
AI Agent正逐步成为软件的核心使用主体。当下，自动化网络流量占比已过半，软件行业正在经历继大型机、PC、移动互联网之后的第四次“用户迁移”。本文围绕 AI Agent 成为 “一等用户（即与人类用户拥有同等系统地位，可被识别、交互、审计与追责的系统参与者）”这一核心，从身份、交互、权限、安全四大维度解读产品设计的全新内涵，分析此次变革带来的开发者角色、商业模式、委托代理风险等连锁影响，并对比 CLI、MCP 等主流技术路线，探讨面向 AI Agent 的产品基础设施建设方向。
1、软件行业正在经历第四次用户迁移
当下，软件行业正发生一场关乎用户主体的根本性变革。据Imperva相关报告统计，自动化流量在全网流量中的占比已达51%，十余年来首次超越人类产生的流量，AI Agent正在成为软件的主要使用者。想要透彻理解这场变革，需要结合软件行业发展的历史脉络来看，如今行业正迎来第四次 “用户迁移”。
第一次是大型机时代，软件使用者以专业机房操作员为主，交互载体为打孔卡与命令行；第二次是 PC 时代，用户群体拓展至办公人群，图形窗口、鼠标成为主流交互方式；第三次是移动时代，智能手机普及让软件走向全体大众，触屏交互成为主流。每一次迁移的共性规律，即旧时代的行业巨头，往往因深耕原有交互模式形成路径依赖，难以适配新的用户形态与交互逻辑。诺基亚凭借实体键盘打造出极致体验，却在触屏时代沦为发展桎梏；众多 SaaS 厂商深耕数十年，打磨出适配人类操作的界面与流程，而这套成熟体系，对于 AI Agent 而言反倒成了运行阻碍。
第四次用户迁移的核心变化，是使用主体变为AI Agent，交互形态也从图形用户界面（GUI）逐步转向 API 与命令行界面（CLI）。这并非CLI的复古回潮——该交互形式自诞生以来始终存在，真正的核心转变在于AI Agent无须依附专为人类打造的视觉翻译层。GUI 的本质，是将底层 API、命令行指令转化为按钮、菜单、拖拽控件等人类易理解的视觉形态；但 AI Agent 原生适配 API 指令，视觉界面反而会增加其操作成本：Agent 需要先解析页面结构、定位交互控件、模拟人为操作、等待页面加载，最后再解析返回数据，整套流程效率低下。
基于以上变化，本文提出核心议题：当软件用户从单一人类群体拓展至人类与AI Agent 双重主体后，产品开发需要做出哪些根本性调整？这场变革并非简单的功能迭代，而是需要围绕身份、交互、权限和安全完成架构重构，同时也会推动开发者角色、商业模式、组织形态发生系统性转变。
2、产品需从四个维度为“一等用户”重新设计
“一等用户” 借鉴编程领域概念，指某类实体在系统中享有与核心主体对等的权利、义务与身份地位。将 AI Agent 定义为一等用户，意味着它不再是隐匿于 API 调用背后的匿名脚本，而是拥有独立身份、可被系统识别审计、支持协同交互、行为可追溯追责的正式系统参与者。
结合 Anthropic 多款产品的工程实践、Linear 业务系统落地案例，以及钉钉、飞书对 CLI 架构的改造经验，可将 “AI Agent成为一等用户” 拆解为四个相互支撑、环环相扣的产品设计维度。
①身份层
系统需为 AI Agent 配置持久化、可独立引用的专属身份标识。该身份区别于临时 API 调用凭证，是和人类用户平级的系统实体。以 Linear 为例，平台将 AI Agent 纳入人员管理体系，支持对其进行启用、运维、行为追踪等全流程操作。
在此模式下，AI Agent 成为团队协作网络中的独立节点，可被团队成员 @提及、分配任务，相关行为与工作内容也会同步展示在项目看板中。身份层是所有后续能力的基础：若 AI Agent 缺少独立身份，权限分配、行为审计、责任界定等工作都将无从开展。
②交互层
面向 AI Agent 的产品交互，不应仅提供零散的 API 接口，而需搭建一套完整、规范的交互协议。这套协议明确 AI Agent 接入系统、传递执行意图、接收结果反馈的全流程规则，同时具备双向属性：一端对接下达指令的人类使用者，另一端连通 Agent 需要调用的外部工具与服务，二者共同构成面向智能体的产品接口体系。
人机协同下发指令的场景看似简单，实则暗藏安全风险。复杂的 GUI 界面会扩大提示注入的攻击范围，攻击者可利用多样化 UI 元素植入隐藏指令，诱导 Agent 执行恶意操作。而 CLI因为交互逻辑简洁纯粹，将成为人与 AI Agent 之间稳定性最强、信任边界最清晰的交互方式。2026 年 3 月，钉钉、飞书相继推出 CLI 工具：钉钉完成全产品 CLI 改造，开放 12 大服务模块的命令行接口，支持 AI Agent 像调用本地系统指令一样使用平台能力；飞书采用 “快捷命令 - API 命令 - 原生 API” 三层架构，顶层通过专属前缀简化参数配置，降低 AI Agent 的调用门槛。
如果说 CLI 打通了人与 Agent的交互通道，那么 MCP（模型上下文协议）则实现了Agent 与外部工具的互联互通。AI Agent 想要发挥实际价值，必须具备调用各类第三方工具的能力，而 MCP 作为标准化通用协议，相当于统一的接入规范，让 Agent 能够快速发现、调用外部服务。对产品开发者而言，标准化协议省去了为不同工具单独适配接口的重复工作，真正实现 “即插即用”。
综合两类交互形态，交互层的完整逻辑得以明确：CLI 负责人与 Agent 的协同通信，MCP 负责 Agent 与外部生态的连接。这套设计秉持接口优先的核心理念，产品不再只是供人类浏览、点击的可视化载体，而是兼顾人类与AI Agent读写、调用、协同作业的综合任务环境。适配 Agent 的使用文档，也从传统图文教程转变为标准化接口说明。
③权限层
必须为 AI Agent 划定清晰、可审计、可动态管控的权限边界。权限设计需要在两大目标之间寻求平衡：既要保证 Agent 拥有足够权限完成业务动作，又要严格约束权限范围，规避误操作和越权操作带来的风险，这既是安全管控的要求，也是产品架构设计的核心要点。
国内办公产品已形成成熟实践：钉钉采用无感认证机制，让 AI Agent 合理继承企业组织权限，同时搭配批量操作熔断、安全沙箱能力，防范 Agent 批量执行任务时失控；飞书支持按业务域精细化申请权限，例如仅开放日历、任务模块权限，无须授予全平台权限，实现最小权限管控。
权限设计中有一个极易被忽视的核心议题，即AI Agent 的权限体系该如何与人类用户绑定。目前主要分为两种模式：一是直接继承所属人类用户的全部权限，优势是Agent可无缝承接人工常规工作，短板在于风险集中，一旦遭遇提示注入攻击，攻击者将间接获取完整用户权限；二是为Agent配置独立权限体系，安全性显著提升，但也会增加权限配置、日常管理的复杂度。两种模式各有优劣，产品设计需结合业务场景灵活选择。
④安全层
安全层是身份、交互、权限三层架构的最终兜底防线。当 Agent 身份被伪造、接口被恶意滥用、权限被非法绕过时，环境隔离机制将阻断风险扩散。Anthropic 在 Claude Code 迭代过程中积累了典型经验：产品早期出现高危漏洞，在用户手动确认 “信任文件夹” 前，代码就已提前执行。攻击者仅需在代码仓库植入带钩子的配置文件，即可在 Claude Code 启动时触发恶意指令。
这类漏洞的根源在于传统软件基于“人类确认在先、操作在后”的交互逻辑，而AI Agent可自主读取文件、执行代码、发起网络请求，彻底打破了原有的操作时序规则。基于多次安全事件总结，Anthropic确立设计原则：优先通过环境层构建硬隔离，再依托模型层规范 Agent 行为。沙箱、虚拟机、网络出口管控等物理隔离手段是安全底线，即便 Agent 本身被攻破，也能将风险锁定在有限范围内。
身份、交互、权限、安全四层架构相辅相成，共同定义了 AI Agent 作为一等用户的产品形态，任意一环缺失，都会导致 Agent 无法正常融入系统，或是引发不可控的安全风险。
3、“一等用户”将引发三重连锁反应
当软件用户从单一人类群体拓展至 AI Agent，围绕传统用户搭建的整套产品开发生态都会产生连锁变革，主要集中在开发者角色、商业模式、委托代理风险三大方向。
①开发者角色的变化
当Agent成为软件的主要用户，开发者的工作对象和工作方式也随之改变。最直接的变化：开发者需要为“两类用户”设计产品。这意味着传统的“用户研究”不再只关注人类行为。开发者需要理解 Agent 如何“感知”系统——它会调用哪些接口、需要什么样的数据结构、在什么情况下会出错、如何从错误中恢复。这些问题的答案，无法从传统的 UI/UX 方法中获得，而是需要开发者以 Agent 的视角重新审视自己的产品。
更深层的变化体现在工作流程上。在Linear，开发者需要设计“Agent 可以被 @”的功能流程；在钉钉和飞书，开发者需要将整个产品 CLI 化，让 Agent 能像调用系统命令一样调用办公软件；在任何 SaaS 产品中，开发者都需要检查和改造 API 的每一个细节——从认证流程到返回格式，从限流策略到错误码设计——因为 Agent 不会像人类一样“绕过”不友好的接口，它只会直接失败，然后转向下一个竞品。
这一变化的连锁反应正在显现。Every公司的CEO Dan Shipper将这类新型开发者称为“前置部署工程师”——他们的工作不是从零编写功能，而是理解业务需求将 Agent 接入系统、持续观察 Agent 的行为，并在出错时介入修正。这意味着开发者的角色不是被弱化，而是被重新定义。从“为人类用户编写功能”转向“为 Agent 用户设计系统”，从“实现需求”转向“定义 Agent 的能力边界和交互协议”。
②商业模式的潜在重构
AI 将颠覆甚至淘汰 SaaS 行业” 是当下流行的论调，该观点认为用户可借助 AI Agent 直接完成业务，不再需要订阅各类 SaaS 工具。但Dan Shipper提出了相反观点，即SaaS 行业不会消亡，反而会迎来新的增长空间。核心逻辑在于每一位付费人类用户背后，都会配套使用至少一个AI Agent，软件的实际使用主体数量因此被大幅扩充。这一判断也在Every公司内部得到验证：该团队全面落地AI工具后，SaaS 采购支出不降反增，原因并非单品涨价，而是 AI Agent 带来了大量新增使用主体。
与此同时，传统商业模式面临挑战。目前主流的按人类席位收费模式，已无法适配新场景，基于Agent 调用次数、任务完成量、资源消耗量等指标的按量计费模式，有望成为行业新选择。
③委托代理问题
委托代理问题源自经济学理论，核心是当受托方代替委托方做出决策时，如何保障双方利益、诉求保持一致。延伸至软件领域，当 AI Agent 代替人类选择 SaaS 产品、调用 API 服务、采购云资源时，其决策逻辑是否能完全贴合人类诉求，成为新的难题。例如：若某厂商的技术文档更适配 AI 读取，Agent 是否会产生无意识的选择偏向；若某类 API 对 Agent 调用友好，但对人类极不透明，Agent 是否会擅自选择该类服务。本质上，当 AI Agent 成为主流用户后，软件消费的决策权被移交至透明度较低的中间层。
目前行业尚未形成标准化解决方案，现有探索主要分为两个方向：一是决策可审计，即完整记录Agent 每一次选择行为，实现全流程可回溯、可解释；二是偏好对齐，在初始化阶段明确人类使用者的偏好与优先级，让 Agent 按照预设规则执行决策。两种方案都需要产品在架构层面预留配套接口与能力。
4、产品范式向基础设施的延伸仍存断层
前文主要聚焦单一产品的改造设计，而放眼整个数字生态，当 AI Agent 成为全行业通用参与者，配套的底层基础设施建设成为新命题。该问题无法依靠单一产品或单一协议独立解决，目前行业已演化出三类主流技术路线，且仍处于竞争探索阶段。
第一类是以钉钉、飞书为代表的产品全量 CLI 化，让 AI Agent 以原生命令行方式调用产品能力；第二类是以 Anthropic 为代表的托管 Agent 架构，将会话管理、控制框架、安全沙箱解耦，依靠稳定接口支撑 Agent 长期自主运行；第三类则是MCP 标准化协议，致力于打造统一的 Agent 与工具通信标准。结合 ScaleKit 的实测数据来看，CLI 在运行效率、稳定性上优势突出，而 MCP 的核心价值体现在跨生态标准化接入层面。可以形象理解为：MCP 是面向陌生外部生态的通用接入规范，CLI 则是适配内部协同场景的轻量化工具。行业大概率将形成分工格局：CLI 成为 AI Agent 操作独立软件的主流方式，MCP 则定位为开放生态的跨平台接入协议。
除此之外，审计与可观测性成为基础设施建设的另一重点。AI Agent 自主执行任务时，企业需要实时掌握行为主体、操作内容、执行原因等全量信息。这就要求产品不仅要内置日志记录、操作回滚能力，还要支持日志以标准化格式对外输出。这里也存在设计矛盾：Anthropic 在 Cowork产品中发现，虚拟机等强隔离安全方案，会同时屏蔽外部安全监控工具。如何在安全隔离与行为监控之间做好平衡，也是基础设施设计必须攻克的难点。
5、结语
本次产品范式迁移的核心可以概括为现代产品需要同时服务人类与AI Agent两类用户。这句话看似平实，却会引发一系列深度变革：AI Agent 不需要可视化 UI，但需要高适配性的机器接口；不需要传统登录页面，但需要独立持久的身份体系；不需要人工确认弹窗，但需要清晰可控的权限边界；它不会主动发起恶意破坏，但提示注入、环境漏洞等问题，可能诱导其做出高危操作。
对于产品开发者与企业决策者而言，当下的核心问题并非“是否要适配 AI Agent”，而是 “如何有序落地”。本文给出四点落地建议：第一，从接口优化切入，迭代 API 能力，保证接口机器友好、数据模型便于 Agent 识别调用；第二，从内部场景试点，先让 AI Agent 融入企业内部协作，完成场景验证；第三，从小闭环起步，选取高频、低风险的细分场景落地，在实践中积累经验；第四，预留扩展空间，优先保障接口的稳定性与开放性，而非一味堆砌功能，为未来AI能力迭代留出余地。
