当智能像水一样流动，软件的价值会流向哪里？
date
Nov 12, 2026
status
Published
slug
intelligence-as-water-future-of-software
tags
AI
产品笔记
创业
summary
从固定应用到按需调用的能力服务，软件的变化不止于界面。真正值得重建的是可理解、可调用、可验证的业务能力，以及围绕结果交付的商业模式。
type
Post
URL
我越来越倾向于这样理解未来的软件：大模型提供通用智能，Agent 组织执行，业务系统提供数据与能力。智能像水一样流动，哪里需要，就在哪里被调用。
这不意味着所有软件都会变成聊天框。更值得关注的是，软件的组织方式可能从“用户操作功能”，转向“系统围绕目标完成任务”。
一、从打开应用，到表达意图
传统软件的路径是：找到应用，学习界面，操作功能，获得结果。
Agent 原生软件所追求的路径则是：表达目标，理解上下文，调度工具，检查结果，必要时请人决策。
以项目管理为例。今天，我们需要在任务列表、文档和沟通工具之间来回切换。未来，一个可能的交互是：
检查项目最近三天的进展，找出阻塞任务，提出下一步安排，并把需要我决策的事情列出来。
系统读取记录、关联依赖，生成进度看板与待决策清单。涉及分派任务、修改排期或通知团队时，再依据授权边界执行。
这是产品方向，而不是一句指令就能可靠完成一切的保证。能否读懂业务、拿到正确数据、处理异常，决定了体验与演示之间的距离。
软件的价值，也会越来越多地体现在：它能替用户完成多少事情，以及完成得是否可靠。
二、智能成为基础设施，软件成为能力节点
“智能像水”这个比喻，可以拆成几个层次：
- 大模型是水源：提供通用语言理解与推理能力。
- Agent 是调度系统：结合任务与约束，组织工具调用和执行步骤。
- API、MCP 与 Skills 构成连接层：API 暴露能力，MCP 提供工具与上下文连接方式，Skills 封装可复用的任务方法。三者作用不同，并非同一种技术。
- 业务数据提供上下文：让通用能力理解具体对象、状态和规则。
- 软件是能力节点：在需要时使用智能，也把自己的能力提供给其他系统。
这个比喻也有边界。水的性质相对稳定，模型输出却可能出错；连接打通，也不代表权限、数据质量和业务责任已经解决。
因此，很多软件公司未必需要训练自己的基础模型，但需要重新审视：自己的能力，能否被外部智能系统安全、准确地使用？
三、界面会按需生成，但稳定交互仍然重要
如果任务成为中心，界面就可以围绕任务变化：
看进度时生成看板，分析数据时生成图表，比较方案时生成对照视图，执行后台任务时只保留状态与异常提醒。
固定界面不再是唯一入口，却不会因此消失。金融交易、医疗设备、工业控制以及高频专业操作，都需要稳定、可预测的交互。即使是普通办公任务，用户也需要知道系统准备做什么、已经做了什么，以及如何撤销。
真正值得追求的，是让交互适应任务，同时保留人的理解与控制。动态界面解决表达问题，稳定的权限、确认和审计机制解决信任问题。
四、SaaS 面临的变化，是用户关系与定价权
当用户通过自己的 Agent 使用某个系统，而不再直接打开它，传统软件公司的竞争基础就可能发生变化。
功能数量之外，要比较任务完成率；使用时长之外，要衡量节省的时间；界面体验之外，要考察执行可靠性。席位订阅也可能与调用量、服务量或结果计费并存。
这些变化不会在所有行业同时发生。按结果收费尤其需要明确：结果如何验收，哪些因素由供应商控制，失败由谁承担成本。
更关键的问题是：
当用户通过别人的入口调用你的能力，你还能掌握多少客户关系和定价权？
入口平台可能掌握需求分发，业务系统可能掌握关键数据与执行能力。谁更有价值，取决于谁难以被替代，而不只是交互入口属于谁。
五、软件竞争力的三个基础：可理解、可调用、可验证
“没有内置 Agent 的软件就没有机会”，这个判断过于绝对。
数据库、操作系统服务和实时控制系统，即使不直接包含大模型，也能持续创造价值。对需要参与智能协作的软件来说，更值得建设的是三个基础：
可理解：能力描述清楚，输入、输出、适用范围与业务约束明确，避免让模型猜测。
可调用：提供稳定接口与权限控制，让系统能够操作，而不必依赖脆弱的界面模拟。
可验证：执行有状态、有记录、有验收标准；失败能被发现，必要时能够回滚或交给人处理。
一个没有内置 AI、却开放且可靠的系统，完全可能比一个封闭、难以验证的“AI 软件”更有竞争力。
六、下一代软件公司的壁垒在哪里？
如果通用智能越来越容易获得，模型能力本身就未必是每家软件公司的主要壁垒。
更难复制的，可能是长期积累的行业知识、合法可用且高质量的数据、关键业务资源，以及稳定交付结果的能力。
大模型提供智能的可能性，Agent 组织智能的执行，真实业务场景决定智能的经济价值。行业公司要做的，是把这些环节连接成客户愿意付费、出了问题也能负责的服务。
对今天的产品团队，我会先问四个问题：
- 客户真正想完成的任务是什么，而不只是想使用什么功能？
- 哪些数据与业务规则，是完成任务不可缺少的上下文？
- 哪些动作可以自动执行，哪些必须由人确认？
- 如何证明结果有效，并计算交付成本？
先把一条真实任务链路跑通，比急着给所有功能加上 AI 更有意义。
软件不会消失，但产品边界会改变
未来的“软件产品”，可能越来越像三种能力的组合：有使用权与质量保障的数据资产、可被调用的业务能力，以及可验证的执行服务。
它们仍然需要被设计、组织、定价和交付，只是不一定装在一个固定的 App 界面里。
过去，我们把工作流程固化成程序，让人学习如何操作。未来，软件有机会更多地围绕人的目标组织能力。
当智能像水一样流动，真正值得建设的，是让它在具体场景里可靠地产生价值的系统。