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

当 78% 的组织已经在至少一个业务环节使用 AI62% 的组织开始试验 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-aiSalesforce, 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.aspxMicrosoft 官方相关发布与博客材料关键词包括 Microsoft 365 Copilot Tuning、multi-agent orchestration、Entra Agent ID、MCP