Agent 时代，软件正在改变形态
最近我在公司里观察到一个很有意思的现象。
一些业务能力比较强的用户，开始使用 WorkBuddy 获取内部信息系统和 BI 里的数据，然后按照自己的需要做分析、整理，甚至完成一些过去需要专门开发功能才能完成的事情。
表面上看，这只是 AI 帮用户查数据、做分析。
但继续往下想，我觉得这件事背后可能隐藏着一个更大的变化：
软件本身的形态，正在发生改变。
过去，我们先开发软件，再让用户按照软件设计好的方式工作。
未来，越来越多时候可能会反过来：
用户先告诉 Agent 自己想做什么，再由 Agent 根据数据、权限和已有能力，临时组织出一种适合当前任务的工作方式。
这意味着，我们过去一直在做的“开发功能”，其中一部分可能会逐渐变成：
按需生成工作流。
软件，其实一直在提前定义用户怎么工作
我们平时看到的软件，有菜单、页面、按钮、表单、报表和各种流程。
但如果把这些表象拿掉，会发现很多软件功能本质上都在做同一件事情：
提前规定用户应该怎样完成一件事。
业务提出一个需求。
产品经理理解这个需求。
开发人员把它做成功能。
用户再按照这个功能去操作。
所以传统软件实际上是在不断把业务需求固化下来。
业务需要一种新的工作方式，就增加一个新功能。
需要一张新的报表，就开发一张新的报表。
需要一个新的流程，就重新设计和开发。
时间久了以后，一个软件就会拥有越来越多的菜单、页面和功能。
这在过去是很自然的。
因为用户本身并没有能力直接操作复杂的数据和系统。
必须由软件开发人员提前把这些能力包装好。
但 Agent 正在改变这件事。
Agent 改变的，不只是“怎么使用软件”
现在很多人讨论 AI，通常想到的是：
让 AI 帮我查数据。
让 AI 帮我填表。
让 AI 帮我总结信息。
让 AI 帮我操作现有软件。
这些当然都很有价值。
但我觉得更重要的一点是：
Agent 开始让一些原本需要提前开发的工作流，变得可以临时生成。
比如一个业务人员突然想知道：
最近哪些产品表现异常？原因可能是什么？
过去，如果系统里没有对应的报表，他往往只能提需求。
然后等待数据人员、产品人员或者开发人员来处理。
但现在，只要 Agent 能够在权限范围内访问相关数据，并理解这些数据之间的关系，它就可以直接帮助用户完成分析。
明天用户的问题变了，也不一定需要重新开发一个功能。
Agent 可以重新组合已有的数据和能力。
这时候发生的变化就不是：
AI 帮助用户更方便地使用软件。
而是：
软件不再需要提前穷举用户所有可能的需求。
软件的重点，可能会从“功能”转向“基础能力”
过去，我们经常用“功能多不多”来评价一个软件。
因为功能越多，意味着这个软件提前覆盖了越多场景。
但如果很多工作流都能够由 Agent 动态组合，那么“有多少功能”本身可能就没有以前那么重要了。
未来更重要的可能是：
数据是否可靠。
业务规则是否清楚。
系统能提供哪些能力。
用户拥有什么权限。
哪些操作可以直接执行。
哪些操作必须经过审批。
也就是说，软件真正需要长期建设的东西，可能会从一个个具体功能，逐渐转向更底层的东西：
可靠的数据、清晰的业务语义、稳定的业务能力，以及明确的权限和治理。
至于最上面的页面、报表、分析方式和部分工作流，则可以越来越灵活。
未来的软件，可能会分成“稳定的底座”和“动态的使用方式”
我觉得这是 Agent 时代一个很重要的变化。
过去，我们花大量精力让页面稳定、菜单稳定、流程稳定。
以后真正需要长期稳定的，可能更多是：
- 什么数据是真实的；
- 数据代表什么；
- 业务规则是什么；
- 用户能做什么；
- 哪些操作需要审批；
- 所有重要操作能不能被追踪。
这些东西不能随意变化。
但在这些基础之上：
用户怎么看数据。
怎么组织信息。
怎么做分析。
怎么组合自己的工作方式。
这些东西则可以变得更加动态。
可以简单理解为：
底层越来越稳定，上层越来越灵活。
这并不意味着传统软件会消失
当然，并不是所有软件都会变成临时生成的。
越重要、风险越高的事情，越需要确定性。
例如付款、审批、财务处理、生产指令、质量放行等核心业务操作，依然需要明确的规则、严格的权限和完整的审计。
这些地方不能让 Agent 自由发挥。
但另外一些工作：
查询。
报表。
数据整理。
信息汇总。
临时分析。
辅助决策。
个人工作流。
内部小工具。
它们很可能会最先发生变化。
因为这些东西过去之所以必须被开发成一个个功能，很大程度上只是因为：
用户自己没有能力直接组织数据和系统能力。
现在 Agent 开始承担这个中间层。
“软件”可能不再等于那个固定的界面
沿着这个方向继续想，会出现一个很有意思的问题：
我们今天所说的 CRM、PDM、BI、采购系统，未来一定还必须是一个个彼此独立、功能固定的软件吗？
也许不一定。
未来更可能存在一个稳定的业务基础。
里面有数据、有规则、有权限，也有各种可以调用的业务能力。
然后不同的人根据自己的职责和任务，看到不同的东西。
销售人员看到的是销售工作台。
工程人员看到的是产品和图纸。
管理者看到的是经营分析。
但这些东西未必一定需要像今天一样，被提前开发成几套完全固定的软件。
它们也可以是：
同一个业务世界，在不同角色和不同任务下的不同呈现。
从这个角度看，我很喜欢这样一句话：
Application is becoming a projection, not the system itself.
软件界面本身，可能不再等同于系统。
它更像是底层数据、业务规则和能力，在某个具体需求下的一次呈现。
真正越来越重要的，反而是业务本身
这也让我重新思考一个问题：
Agent 时代，软件真正有价值的东西到底是什么？
过去我们很容易认为：
一个系统功能很多，所以它很有价值。
但随着 Agent 越来越强，很多通用功能的开发成本都会下降。
一个页面。
一个报表。
一个简单的数据查询。
一个内部小工具。
这些东西会越来越容易被生成。
真正难以复制的，反而是：
这个业务到底是怎么运转的。
不同对象之间是什么关系。
哪些规则不能违反。
什么数据才是可信的。
什么状态意味着什么。
什么情况下可以执行什么操作。
这些东西并不是 Agent 可以凭空创造出来的。
它们来自一个企业、一个行业长期积累的业务认知。
所以我越来越觉得：
当软件实现越来越便宜，业务认知会变得越来越昂贵。
未来企业真正需要积累的，也许不只是代码和功能。
而是：
对自己业务世界的理解。
我们可能需要重新思考“开发软件”这件事
过去做软件时，我们首先会问：
这个系统应该有哪些功能？
未来，这个问题可能会逐渐变成：
我们需要为 Agent 提供哪些可靠的数据、业务规则、能力和权限，才能让用户安全地完成自己的工作？
这其实是两种完全不同的软件设计方式。
过去，我们试图：
提前把用户未来需要的功能都开发出来。
未来，我们可能更多是在：
建设一个足够稳定的基础，让新的工作方式可以不断产生。
我们不再试图猜中用户未来所有需求。
而是把真正需要长期维护的东西做好：
数据。
业务规则。
能力。
权限。
治理。
然后把一部分“怎么使用这些东西”的选择权重新交给用户。
用户不再只能问：
这个软件有没有这个功能？
而可以直接说：
我现在想这样工作。
Agent 再根据现有的数据、能力和权限，把这件事情组织出来。
我觉得这可能才是 Agent 真正开始改变软件的地方。
它不是简单地给现有软件增加一个聊天窗口。
也不只是让用户少点几个按钮。
更深层的变化是：
过去由开发者提前定义的软件形态，正在变得越来越动态。
软件不会消失。
但我们对“软件应该是什么”的理解，可能正在改变。
