AI 时代下，传统软件该如何重构？不是加个聊天框，而是重写产品底座

当 78% 的组织已经在至少一个业务环节使用 AI，62% 的组织开始试验 AI agents，传统软件真正要面对的问题就不再是“要不要接 AI”，而是“你的产品，是否还能作为未来工作的主入口”。

开篇引入：今天最危险的软件，不是没有 AI，而是只有 AI 功能

过去一年，很多传统软件团队都在做一件事：给产品加一个 AI 助手、一个侧边栏、一个总结按钮，或者一套“智能推荐”。这些动作当然有价值，但它们往往只是把 AI 贴在旧界面上，而不是把产品真正改造成 AI 时代的工作系统。

问题就在这里。

AI 时代改变的，不只是“功能怎么实现”，而是“工作是如何被完成的”。原来的软件逻辑是：人打开页面，查找信息，点按钮，提交流程。新的逻辑正在变成：人描述目标，系统调动上下文，agent 代替人跨模块执行，再把结果交回来。

这意味着，传统软件的竞争对象已经不只是同行，而是所有能够更快理解任务、更低成本执行流程、更自然承接上下文的 AI-native 产品。

McKinsey 的官方摘要给了一个很直观的背景：组织在至少一个业务职能中使用 AI 的比例已达到 78%，而 62% 的组织已经开始尝试 AI agents。问题并不在“有没有需求”，而在于绝大多数公司仍然卡在试点、插件化、碎片化阶段，离真正的规模化改造还很远。

AI 时代最先被淘汰的，不是没有模型的软件，而是仍然要求人类自己搬运信息、拼接流程、手工触发每一步的软件。

第一层重构：从“功能菜单”转向“任务执行”

很多传统软件的产品结构，本质上是功能目录。

• CRM 提供线索页、客户页、报表页
• ERP 提供采购、库存、财务、审批模块
• 设计软件提供图层、面板、滤镜、导出工具
• 项目管理软件提供任务列表、看板、时间线

这一套逻辑建立在一个默认前提上：软件只负责提供能力，真正把能力串起来的是人。

但 agent 出现之后，这个前提开始失效。用户要的不是“我能不能在五个模块里完成一件事”，而是“你能不能帮我把这件事直接做完”。

比如销售团队并不真正想“打开 CRM 更新记录”，他们想要的是：识别高意向线索、补全客户背景、生成跟进建议、安排下一步动作。营销团队也不想在十个页面中切来切去，他们想直接得到一个结果：哪些人群值得投放、哪套文案更可能转化、活动上线后哪里需要调整。

Adobe 在 2025 年推出 Experience Platform Agent Orchestrator，本质上就在做这件事。它不再只是给企业一个“营销工具集合”，而是试图把客户数据、品牌内容、决策逻辑和多个 AI agents 串成一个可执行系统。这个动作非常典型：传统软件开始从“工具箱”转向“任务编排层”。

这对传统软件团队的第一条要求是：先别急着想“加哪个大模型”，先想清楚你的用户到底想完成哪些高频任务，这些任务是否能被拆成清晰的输入、决策、执行、反馈四步闭环。

如果不能闭环，你加再多 AI 入口，都只是更花哨的功能页。

第二层重构：从 CRUD 数据库转向“上下文系统”

传统软件最擅长的是存数据。

它们围绕表结构、权限、字段、状态机、审批流构建了极强的 system of record 能力。这个能力不会过时，反而仍然是护城河。但只靠它已经不够了。因为 agent 并不只是读取一条记录，它需要理解：

• 当前用户是谁，权限到哪里
• 这次任务发生在什么业务上下文里
• 历史交互、知识库、合同、政策、附件之间是什么关系
• 哪些信息是可信的，哪些只是参考
• 什么情况下应该自动执行，什么情况下必须回到人工确认

这就是为什么 Salesforce 在 2026 年的官方文章里反复强调：今天企业 agent 的关键，已经从 prompt engineering 转向 context engineering。你给模型多一句提示，远不如你把数据、知识、流程和权限组织好更重要。

很多传统软件团队在这里会犯一个致命错误：把 AI 理解为“读取数据库再生成一段自然语言”。这太浅了。真正可用的产品，需要把数据库升级成可被检索、可被引用、可被解释、可被审计的上下文系统。

具体来说，至少要补四类能力：

• 结构化业务数据：订单、用户、合同、库存、工单等
• 非结构化知识资产：文档、FAQ、操作手册、邮件、聊天记录
• 动态任务状态：当前任务做到哪一步，卡在哪个环节，谁拥有处理权
• 可信元数据：来源、更新时间、适用范围、审批状态、风险等级

AI 时代的数据层不只回答“存了什么”，还要回答“现在该相信什么、该调用什么、该执行什么”。

当你的产品能够把这些上下文清晰组织出来，agent 才不是一个会聊天的外壳，而是一个真正能干活的执行入口。

第三层重构：把产品改造成 Agent Harness，而不是只接一个模型

2026 年企业软件里最重要的一个词，可能不是 agent，而是 harness。

Salesforce 官方把它定义得很直接：一个 agent 能否可靠工作，关键不在模型本身，而在围绕模型搭起来的那一圈架构。包括它能看见什么数据、继承谁的权限、允许调用哪些工具、被什么规则约束、出了问题怎么追踪。

这正是传统软件最该重构的地方。

过去产品团队习惯做的是：页面、接口、字段、报表。未来还必须多做五件事：

• 护栏：哪些步骤必须按顺序执行，哪些动作不能跳过
• 授权：agent 代表谁行动，权限是否按人、按部门、按任务动态继承
• 工具编排：外部系统、内部服务、API、MCP 工具如何安全调用
• 观测：每一步推理依据、调用链路、失败原因是否可追踪
• 回退：出错后能否中断、重试、交给人工接管

Salesforce 甚至公开提到，他们为了降低 agent 的延迟，对 Agentforce runtime 进行了底层重建，通过减少 LLM 调用次数、用确定性规则替换部分模型判断等方式，把平台延迟降低了 70%。这件事给传统软件团队一个非常现实的提醒：AI 产品不是把推理塞进去就行，执行层的工程化质量才决定用户是否愿意长期使用。

换句话说，未来的软件形态会更像“一个受控执行环境”，而不是“一个被动响应点击的页面集合”。

第四层重构：让 UI 退居二线，让 API 与无头能力站到前台

这听上去有点反直觉，但它会越来越真实：很多传统软件未来最重要的能力，未必会首先体现在 UI 上。

因为 AI agent 并不总是在你的网页里工作。

它可能在企业聊天工具里、在办公套件里、在浏览器插件里、在客户服务台里、在手机端语音入口里，甚至在另一个厂商的 agent 体系里完成对你系统的调用。也就是说，未来的软件不仅要“给人用”，还要“给 agent 用”。

Salesforce 在官方文章里提到 Headless 360，本质上就是把 CRM 能力从浏览器标签页里释放出来，变成可被 API 和 CLI 调用的服务层。微软也在持续把 Copilot、Copilot Studio、多 agent orchestration、MCP 支持和身份治理整合在一起，方向同样明确：产品的核心不再是单一界面，而是可组合、可托管、可被外部代理调用的能力网络。

这会带来三个直接变化：

• 前端从“主舞台”变成“解释层与确认层”
• API 从开发者能力变成产品主能力
• 权限与身份系统从后台配置项变成 AI 时代的生死线

对于很多传统软件公司来说，这一步甚至比接模型更难。因为它意味着产品团队、后端团队、平台团队、安全团队都要重新协作，才能把系统从“一个页面应用”变成“一个能被编排的执行平台”。

第五层重构：重新设计定价，不然 AI 会把你的毛利结构打穿

传统 SaaS 最舒服的定价方式，是按席位收费。

逻辑很清楚：一个账号对应一个人，一个人对应一个工作量区间，成本和收入都比较可预测。但 AI 时代，这个模型正在被迅速侵蚀。

原因不复杂。agent 不是“一个多花 20 美元的高级用户”，它更像一台持续消耗推理、检索、调用、生成资源的半自动劳动力。它的成本不是线性的，往往还会随着调用频率、上下文长度、工具链复杂度和质量要求快速上升。

因此，越来越多厂商会走向混合定价：

• 基础订阅费
• 使用量计费
• 任务量计费
• 结果导向计费

这不是财务细节，而是产品设计问题。因为一旦你的产品开始替用户执行任务，你就必须回答：到底该为“谁在用”收费，还是该为“完成了多少工作”收费。

如果这个问题不提前设计，后果通常有两个。

• 对外，客户会觉得价格失控，不敢把试点推向全量
• 对内，模型和算力成本会悄悄吞掉本来健康的 SaaS 毛利

所以传统软件重构的第五层，其实是 unit economics。你必须把 token、检索、外部 API、人工兜底、人工审核、任务成功率这些变量引入产品经营模型。否则产品看上去越智能，财务上可能越危险。

AI 时代的定价，不是营销部门的包装动作，而是对产品真实价值链和成本链的一次重新定义。

第六层重构：从 DevOps 走向 AI Ops，组织结构也要跟着改

很多团队低估了一件事：AI 产品上线之后，真正复杂的工作才刚开始。

传统软件出 bug，通常是确定性的。你查日志、复现、修复，问题就结束了。agent 不是这样。它可能给出一个语法完全正确、语气非常自信、但业务判断完全错误的答案；也可能偶发偏航、语义漂移、权限误用、调用链超时，或者在边界条件下做出“看起来合理、实际上危险”的动作。

这也是为什么 Salesforce 在 2026 年明确把 observability 和 ADLC 放到很高的位置。谁拥有这个 agent？异常由谁接手？更新后怎么回归测试？什么指标代表它偏航了？这些问题，如果没有明确答案，AI 功能一旦进入核心业务，就会迅速失控。

微软最近也在把 Entra Agent ID、治理、评估和风险参数纳入平台能力。它背后的管理学逻辑很清楚：AI 不能只被当作一个功能模块，它已经接近一种新的数字劳动力，因此必须被纳入身份管理、责任划分、评估体系和运维机制。

所以，传统软件团队真正需要新增的，不只是提示词工程师，而是下面这些角色能力：

• 负责指标和回归的 AI QA
• 负责观测与告警的 AI Ops
• 负责权限和审计的安全治理负责人
• 负责业务闭环设计的产品架构师

如果组织仍然沿用“产品提需求，研发做页面，测试点按钮”的协作方式，那么 AI 能力只会停留在 demo 层面，很难沉到主流程。

给传统软件团队的 180 天重构路线图

说了这么多，如果你今天就在一家传统软件公司，应该从哪里开始？我建议按 180 天拆三段，不要上来就做大而全改造。

第一步：先挑 1 到 2 条高价值闭环任务

不要先做“万能助手”。

优先选这些任务：

• 频率高
• 规则相对稳定
• 结果容易验证
• 涉及多个模块，但流程清晰

例如：销售跟进建议、客服工单分流、合同初审、SOP 生成、营销素材组合、网站优化建议、库存异常提醒。

第二步：补四块底座，不补这个一切都是空中楼阁

• 做上下文层：把结构化数据、知识库、状态流和可信元数据打通
• 做能力层：把关键动作 API 化、服务化、可回滚化
• 做治理层：明确权限继承、敏感动作审批、工具白名单和审计日志
• 做观测层：定义成功率、升级率、人工接管率、平均耗时、单位成本

第三步：把 UI 改成“确认与协作界面”，而不是“全部都要手工点”

用户界面不会消失，但它的职责会改变。

未来更好的界面，应该帮助用户：

• 描述目标
• 查看 agent 的计划与依据
• 对关键动作做确认
• 在失败时快速接管
• 追踪整个任务链路

也就是说，UI 不再只是操作面板，而是人和 agent 之间的协作面。

如果这三步能走通，你的产品就已经从“加了 AI 功能的传统软件”，迈向“可以承接 AI 工作流的新一代软件”。

写在最后

在 AI 时代，传统软件当然不会一夜之间消失。真正会消失的，是那种默认人类必须自己搬运信息、切换系统、手工推进流程的软件交互方式。

未来真正有生命力的产品，不是“会回答问题”的软件，而是能在可信边界内理解目标、调动上下文、调用工具、交付结果的软件。

所以，传统软件到底该如何重构？答案并不是一句“全面 AI 化”。更准确的说法应该是：

把产品从功能集合，重构成任务系统；把数据库，重构成上下文系统；把页面应用，重构成可被 agent 调用的执行平台；把运维体系，重构成能够持续评估和治理 AI 的生产系统。

这场重构不会轻松，但它比“加一个聊天框”诚实得多，也更接近未来三年的真实竞争。

如果你正在做传统软件产品，我建议你现在就问团队三个问题：

• 用户最想完成的那件事，今天是不是还要自己点很多次按钮？
• 你的核心能力，能不能被 agent 安全调用，而不依赖页面操作？
• 你的系统里，到底有数据，还是有可执行的上下文？

这三个问题，基本就决定了你是在做“上一代软件的 AI 皮肤”，还是在做“下一代软件的底座”。

参考来源

• McKinsey, The State of AI: https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
• Salesforce, 8 Ways AI Agents Are Evolving in 2026: https://www.salesforce.com/blog/ai-agent-trends-2026/
• Adobe, Adobe Launches Adobe Experience Platform Agent Orchestrator: https://news.adobe.com/news/news-details/2025/Adobe-Launches-Adobe-Experience-Platform-Agent-Orchestrator-for-Businesses-to-Activate-AI-Agents-in-Customer-Experiences-and-Marketing-Workflows/default.aspx
• Microsoft 官方相关发布与博客材料，关键词包括 Microsoft 365 Copilot Tuning、multi-agent orchestration、Entra Agent ID、MCP