Agent 时代，企业软件的 9 个变化
从Claude Cowork 看到的未来
放假这几天，深度体验了下 Claude Cowork，切身感受到了 Agent 时代的冲击，也预示着未来企业软件的工作范式。
以最典型的“差旅申请及报销”场景为例：
核心洞察： 以前是“人驱动流程”，现在变成了“意图驱动执行”。
比如，一个数字化基础较弱的企业，现在想要构建一个端到端的 PLM（产品生命周期管理）平台，也面临同样的灵魂拷问：还要像 10 年前那样，堆砌几百个表单页面让工程师去填吗？还是应该用 AI-Native 的方式设计整套系统？
当软件的使用者从单纯的“人”，变成了“人 + Agent”，企业软件的构建逻辑有以下 9 个关键转变。
企业软件：看得见的变化
1.用户结构变了：从“只服务人”，到“同时服务人和 Agent”
以前我们做系统，眼里只有“人”，拼命优化 UI、字号、按钮位置。 现在，企业系统的用户多了一类：Agent。Agent 不看 UI，它看的是 API。
典型场景：贷后预警
- 过去：客户经理每天登录系统，手工筛选异常数据，导出 Excel，再发工单。
- 现在：Agent 在后台自动跑批，命中规则后直接生成调查任务，通过接口推送到经理面前。经理只需要审阅证据、做决策。
思考： 如果系统没有良好的接口能力，Agent 就只能像人一样去读屏（视觉识别），效率低且极不稳定。 因此，“易用性”的定义变了：不仅要界面对人友好（Readable），更要接口对 Agent 友好（Callable）。
2.产品形态变了：从“固定 UI”，到“场景化动态 UI”
以前软件开发像盖房子，交付时界面长什么样，用户就得怎样用。 现在Agent 能够理解上下文，甚至可以借助 Coding Agent 在运行时即时生成最适合当前任务的界面。
典型场景：报销单据填写
- 常规场景：界面只显示行程简报和金额，用户点“确认”即可。
- 超标场景：Agent 自动高亮超标项，动态插入“政策依据”提示，并展开“特批理由”输入框。
- 缺票场景：界面自动切换为“补证据模式”，优先展示替代凭证上传入口。
思考： 交互不再是死板的“千人一面”，而是“千事千面”。前端设计的重心，正在从“让人完成录入”，转向“让人更高效地完成监督、确认和审计”。
3.交付单位变了：从“模块上线”，到“场景闭环”
以前我们习惯按模块交付：需求管理上线了、BOM 管理上线了，项目就算里程碑完成。 但对 Agent 来说，如果不能把事办完，价值就是 0。跨模块的断点，是 Agent 的死穴。
典型场景：PLM工程变更
- 过去（交付模块）：需求、BOM、变更管理模块分别上线。模块间的信息同步，还得靠工程师手动搬运，审批还得靠人工催。
- 现在（交付闭环）：交付的是“需求变更 -> 工程生效”的全链路。Agent 自动抽取变更意图、分析 BOM 影响、发起 ECR/ECO 流程、回写状态。人只处理冲突和高风险审批。
思考： 交付标准变了：不看“功能全不全”，看“场景通不通”。 核心指标转向：端到端直通率、全链路总时长、异常处理效率。
4.迭代方式变了：从“版本发布”，到“持续校准”
以前软件上线是终点，运维只负责修 Bug。 现在引入 AI 后，由于概率性的存在，上线只是“调教”的起点。
典型场景：智能审批
- 过去：V1.0 发布后，等着收集几个月的需求，再发 V2.0。
- 现在：系统上线后，每周复盘“误判样本”，持续微调 Prompt 阈值和规则策略，像教徒弟一样，通过灰度发布不断修正 Agent 的行为。
思考： 在 AI 时代，“监控—复盘—调优—验证”将成为比“开发—测试—发布”更高频的日常机制。
5.价值模型变了：从“用户增长”，到“单位经济性”
过去做 SaaS 或内部系统，逻辑是：用的人越多，边际成本越低，价值越大。 现在，Agent 的每一次思考和执行（Token/算力）都是有真实成本的。用户规模扩大，成本也在指数级扩大。
典型场景：价值汇报
- 过去：系统覆盖了 5000 人，日活提升了 20%。
- 现在：Agent 处理单笔任务成本 0.5 元，人工处理成本 10 元，单任务净收益 9.5 元。随着调用量从 1 万涨到 10 万，净收益持续为正。
思考： 从追求“规模用户增长”，转向追求“规模化正收益”。只有当“单位任务净收益”跑通时，Agent 的规模化才有意义。
企业软件：隐含的变化
6.架构模式变了：从“一体化应用”，到“Agent 编排+核心底座”
过去我们将交互、流程、规则、数据都封装在一个应用系统里。 现在，架构正在走向“两层协同”：前台灵活编排，后台严守底线。
典型场景：复杂业务协同
-
过去：所有逻辑写死在代码里。跨部门协同靠人开会、发邮件。
-
现在：
-
- 前台 (Agent)：理解业务意图（如“把这个需求同步变更到 BOM”），自动拆解并编排任务。
-
- 后台 (Core System)：提供权威数据、事务一致性保障、合规审计能力。
思考：
- 交互外移：自然语言成为新入口。
- 流程外移：僵化的流程引擎部分被 Agent 动态编排取代。
- 规则重分：策略性的归 AI（Prompt），红线性的规则归系统（Code）。
7.数据存储变了：从“字段记录”，到“业务语义”
只存字段（Field），Agent 是看不懂的。 字段只能告诉系统“是什么”，但 Agent 执行任务需要知道“为什么”和“能不能”。
典型场景：订单状态流转
- 过去：数据库里存 status=3，只有开发人员查文档才知道这是“已审核”。
- 现在：除了字段，还必须定义语义层——“当订单状态为已审核，且合规校验通过时，才允许触发付款动作”。
思考： 业务语义层将成为企业软件的核心资产。没有这层“说明书”，Agent 就是在黑盒里瞎操作。过去系统假设重心是业务逻辑层的代码实现，现在则是业务语义层的梳理构建。
8.治理对象变了：从“访问控制”，到“行动治理”
过去安全治理的重点是防人：“谁能看数据？谁能改字段？” 现在风险更多来自 Agent：“它做了什么动作？在什么条件下做的？会不会造成灾难性后果？”
典型场景：高风险操作
- 过去：限制张三不能访问“财务审批页面”。
- 现在：监控 Agent 的行为——“当连续触发大额审批时，自动熔断并降级为人工确认”；“所有高风险动作必须双重校验并留痕”。
思考： 治理重心从“权限”延伸到“后果”。核心能力是：动作有边界、过程可追溯、异常可中断、结果可回滚。
9.竞争壁垒变了：从“功能堆叠”，到“语义资产 + 执行闭环”
过去比谁功能全、谁界面好看。 在 Agent 时代，功能很容易被复制，界面甚至不再重要。
典型场景：竞品对比
- 过去：功能清单对比，看谁的模块多。
- 现在：看谁的 Agent 能真的把活干完（闭环），看谁的系统更懂行业潜规则（语义），看谁跑得更稳（治理）。
思考： 真正的壁垒变成了三件事的组合：
- 1.语义资产：对行业 Know-how 的数字化沉淀。
- 2.执行闭环：搞定“最后一公里”碎片化操作的能力。
- 3.治理体系：敢放手让 Agent 跑的安全底座。
思考：对于企业软件产品经理，意味着什么？
梳理完这 9 个变化，我最大的感受是：企业软件的游戏规则，真的变了。
面对未来，作为企业软件产品经理，或许需要重新审视自己的定位：
- 关于技能： 以前我们抠原型、抠交互。如果未来的“交互”变成了 API 定义和 Prompt 策略，我们是不是该补上业务建模和系统设计这块短板？
- 关于角色： 上线不再是终点，而是起点。我们是不是正在从“功能设计者”，变成 Agent 的训练师和运营者？
- 关于价值： 当功能容易被 AI 生成，我们最不可替代的价值是什么？也许是那种将模糊的行业经验，翻译成系统可执行、可治理规则的翻译能力和判断力？
期待和大家有更多的交流碰撞～
注：文中配图为Gemini生成。
#AI-Native企业软件 #AI转型 #AI企业产品设计 #企业软件产品经理
