软件正在退到后台
过去很长一段时间里，我们谈产品，其实谈的主要是人怎样使用软件。一个产品经理要想用户从哪里进来，看见什么页面，点哪一个按钮，填哪一个表单，在哪里犹豫，在哪里付费，出了错又怎样回来；一个所谓好的产品，也就往往意味着信息架构清楚，交互顺滑，功能稳定，用户对过程有一种可以理解和掌控的感觉。这个前提在移动互联网时代几乎没有人怀疑，因为软件就是入口，App 就是场所，用户要完成一件事，便必须亲自走进那个场所。
当 AI 还只是回答问题时，它只是软件里的一个功能，至多是一个聪明一点的搜索框；但当它开始理解目标、读写数据、调用工具、执行流程，软件的价值分配也就跟着动了。用户要整理上个月的客户沟通记录，生成一份销售进展报告，再把重点风险标出来，这个任务背后可能牵涉邮件、CRM、日历、文档、表格和聊天记录，过去用户必须在这些软件之间来回切换，今天则可以只把目标说出来。至于导出、筛选、比对、归类、生成、回填，原本显得很有产品存在感的那一串操作，未必还需要由人亲手完成。
所以我说，软件不会消失，但很多操作型软件的前台会被压缩。过去软件是目的地，用户为了完成任务必须进入它；以后相当多的软件会退成能力供应商，在 Agent 认为合适的时候被调用。用户感知到的，不再是我打开了十个软件，而是我交代了一件事，系统替我跑完了一段流程。这个变化看似只是入口移动，实际上牵涉产品定义的根基，因为过去我们默认产品首先服务于人的手和眼，以后却要同时服务于人的判断和 Agent 的调用。
不过，人也并不会因此退出产品。只要结果还要服务于人，只要费用还要由人或组织承担，只要错误还会落到真实世界里，人就不可能把自己降格为旁观者。变化只在于，过去人是操作者，要知道点哪里、填什么、怎么导出、怎么排错；以后人更像目标设定者、授权者、偏好提供者、异常处理者和结果验收者。财务审批、合同审查、医疗建议、招聘筛选、企业采购、重要客户沟通这些场景里，Agent 固然可以替人完成大量过程；但它调用了哪些数据，花了多少钱，为什么这么判断，哪里可能有风险，最后应不应该确认执行，仍然要有人看得懂、拦得住、追得回。
界面于是也不会简单死掉，只是它的重心要从操作界面转向控制界面。过去界面解决的是用户怎样一步步完成任务，以后界面更要解决用户怎样表达目标，怎样授权 Agent，怎样理解过程，怎样检查结果，怎样干预异常，怎样追责和回滚。这样的界面未必还是传统 App，它可能是聊天窗口、任务面板、审批流、工作台、日志系统、结果预览、权限中心、预算控制台，或者自然语言和结构化控件混在一起的新东西。点击会少一些，确认、修正、授权、验收会多一些。这很正常。
我倾向于把未来产品看成三层。最上面一层仍然面向人，负责理解、控制和信任，它让用户知道系统正在做什么，代价是什么，风险在哪里，出了问题有没有暂停和回退的入口；中间一层是 Agent 编排，它把人的目标拆成可执行的任务，决定调用哪些工具，处理任务之间的依赖，并在必要时回来找人确认；下面一层则是各种能力服务，API、数据库、模型、自动化流程、业务系统都在这里，它们不一定需要漂亮的人类界面，却必须有稳定的输入输出、权限机制、计费方式、错误处理、审计日志和服务质量保证。
这三层说起来像新名词，其实不过是把过去混在一个软件里的东西拆开了。过去我们做产品，重点往往放在人如何使用软件；以后做产品，至少要同时问三件事，人如何理解和控制它，Agent 如何发现和调用它，组织或市场如何为它付费并承担责任。一个只面向人的产品，入口可能被 Agent 抽象掉；一个只面向 Agent 的工具，若没有用户信任、品牌心智和商业控制力，又很容易变成无名的零件。有价值的产品，多半要有两种表达方式，对人是可信的工作空间，对 Agent 是稳定的能力接口。
商业模式也会随之挪动。Agent 本身并无经济主体资格，它只是代表某个人、某个团队、某个组织去消费和执行，真正付费的还是人或组织；但计费单位会从软件使用权，慢慢转向能力调用、任务完成和结果交付。过去 SaaS 最常见的是按席位、套餐、功能权限收费，用户买的是使用一个软件的权利；以后调用一次数据清洗服务、识别一份合同风险、查询一次行业数据库、处理一张发票、完成一次客服质检，都可能成为更自然的计费单位。若平台替用户订阅一组 Agent，再由 Agent 调用第三方服务结算，那么所谓 Agent 能力市场也就不奇怪了，类似 App Store、API 市场和企业软件采购平台的杂交物罢了。
但是这里的麻烦处在谁允许它花钱，收钱倒在其次。Agent 代表谁，谁授权它使用服务，谁承担费用，什么情况下必须二次确认，出了错谁负责，这些问题会把商业设计和身份、权限、预算、审计紧紧绑在一起。一个企业员工让 Agent 处理客户资料，它能不能访问 CRM，能不能导出客户名单，能不能发送邮件，能不能修改报价，能不能提交合同，能不能购买外部数据，表面看都是技术权限，实际上都是产品边界。过去产品经理设计用户路径；以后还要设计 Agent 的权限路径。
也正因为如此，Agent 不会把所有服务都自己实现掉。简单格式转换、基础数据清洗、普通文案生成、一次性脚本、轻量自动化流程，这些只有通用功能、没有数据壁垒、没有流程沉淀、没有信任体系的小工具，确实很容易被 Agent 临时生成或直接完成；但有价值的产品，从来不止某段功能代码。Agent 可以写一个报表脚本，却不能凭空拥有企业内部多年的销售数据；可以生成一套合同审查逻辑，却不能自动获得法律责任和专业背书；可以模拟任务管理工具，却不能凭空复制团队沉淀下来的项目记录、协作关系和组织流程；可以调用支付流程，却不能绕过真实世界里的账户体系、风控系统和合规要求。
功能型产品会被压缩，基础设施型、数据型、流程型、信任型产品反而会被放大。这里面的分水岭大概很冷酷。你的产品若只是让用户点几下，把 A 变成 B，Agent 迟早会替用户点完；你的产品若掌握了独特数据，嵌入了关键流程，承接了多人协作，提供了稳定交付，并愿意对结果承担某种责任，Agent 反而需要你。它越能干，越需要可调用、可授权、可审计、可计费的外部能力。
产品经理的工作也就跟着变了。过去要问用户是谁，路径是什么，核心功能是什么，页面怎样组织，如何提升转化率和留存；以后还要问 Agent 为什么要调用我们，我们的能力边界在哪里，输入输出怎样定义，哪些动作需要人确认，调用失败怎样处理，费用怎样限制，日志怎样留存，审计怎样交代。UI、交互、体验当然还重要，只是它们不再只是让人完成操作，也要让人理解系统、控制风险、表达偏好、确认结果。用户停留时间最长的产品，未必就是好产品；能被 Agent 正确调用，同时让人放心交付任务的产品，可能反而更有价值。
我觉得 Agent 时代真正改变的，与其说是软件还在不在，不如说是软件站在哪里。过去产品站在用户面前，要求用户进入它、学习它、操作它；以后许多产品会退到任务背后，在人和 Agent 之间，在 Agent 和真实世界之间，提供一块稳定的能力。人负责目标、判断和责任，Agent 负责理解、编排和执行，产品负责提供可信、可计费、可组合的能力。
夜雨聆风
