夜雨聆风Coding agent 先跑出来，是因为代码有 compiler；而企业工作流没有 compiler，所以 AI 真正要改造的，是那些从来没被好好软件化的脏活累活。
过去一年，AI 行业最明确的变化，不是「所有工作都被 agent 改造了」，而是一个更具体的事实：
coding agent 真的跑出来了。
Benedict Evans 在 a16z 这期访谈里说得很直接：过去一年，AI 的焦点从「大家都很兴奋，但不知道到底怎么用」，收窄到了一个已经有明确 product-market fit 的场景，软件开发。他用了一个很形象的说法，agentic coding 从「有点用」变成了「彻底改变一切」，而且客户是「从你手里把它抢走」。
这不是偶然。开发者最早接触 LLM，也最有能力把 LLM 接进自己的工作流。更重要的是，代码世界天然有结构：文件、函数、测试、版本控制、编译器、错误反馈、CI/CD。AI 生成代码之后，系统能比较快地告诉你：能不能跑，哪里报错，哪里需要修。Benedict 甚至打了个比方，LLM 本身某种意义上就是「计算机」，所以人们拿到它做的第一件事，就是拿它来「造更多计算」，就像当年 PC 出来后第一件事是用来「造计算机」。
所以 coding agent 先跑出来，不代表企业所有工作流都会立刻被 agent 改造。相反，它暴露了另一个更大的问题：
企业工作流比代码难得多，因为企业没有 compiler。
一个销售线索没人跟，不会像代码一样报错。
一个经销商没有及时反馈，不会自动 throw exception。
一个广告预算被错误分配，不会在系统里显示红色错误提示。
一个跨部门流程长年靠 Excel、邮件、会议和人的记忆维持，也不会有人明确告诉你「这里的 workflow 是坏的」。
这就是为什么 AI 不会简单杀死 SaaS。AI 真正要改造的，是企业里那些原本没有被好好软件化的脏活累活。
Benedict 的判断很清楚：现在 AI 最明确跑通的场景是 coding。原因不只是「程序员更懂 AI」，更深层原因是，软件开发本来就是一个高度结构化的工作环境。代码是可读的，依赖是可追踪的，错误是可反馈的，版本是可回滚的，测试是可自动运行的，系统知道什么叫「成功」，也知道什么叫「失败」。
这给 agent 提供了一个非常珍贵的东西：反馈闭环。
AI 写一段代码，不是写完就结束，它可以运行、报错、修改、再运行。这个闭环越短，agent 越容易变得有用。Benedict 也提醒，这种确定性并不代表别的领域会自动跟上，他反复说，大多数三年前就该问的根本问题至今没有答案，唯一可以确定的是 coding 现在有了 product-market fit，其他场景还没有同等量级的 PMF。
而企业工作流不是这样。企业里的很多流程不是写在代码里的，而是长在组织里的。它们分散在：
CRM 记录；
邮件沟通；
Excel 表格；
Slack / 飞书消息；
会议纪要；
主管口头判断；
销售个人习惯；
部门之间的默认边界；
KPI 和奖金制度；
以及很多没人愿意承认但每天都在发生的例外处理。
这些东西没有天然的 compiler。所以 workflow agent 比 coding agent 难，不是因为模型不够聪明，而是因为企业现实没有被整理成模型可以工作的结构。
很多人喜欢说「AI 会杀死 SaaS」。这个说法听起来很有冲击力，但太粗糙。Benedict 的判断更细，也更反共识：
"What does this do to software? The answer is more software, way more software."
AI 会让软件更容易被创建，结果未必是 SaaS 消失，而可能是软件变得更多。
他还原了企业软件本来的样子，根本不是一个整齐的世界。Benedict 把一家典型大公司的软件分成几桶：最上面是 SAP、Workday、CRM、薪资管理这类 big iron 横向系统；然后是垂直 SaaS，一家典型美国大公司装着三四百个 SaaS app，外加上千个自建或买来在内网跑的工具；中间还有一大片由 Excel、邮件和共享文件系统构成的「即兴地带」，事情在这几层之间来回流动。他举了个很具体的例子：PwC 每年招几千个毕业生，多半有一套自己定制、还可能很难用的招聘软件；而一年只招五个毕业生的公司，就是用邮件加一张共享 Google sheet 搞定，因为「干嘛要为这个买软件」。
AI 进入之后，不会简单替代其中某一类，它会让企业重新面对一个问题：
这件事到底应该变成软件，还是继续靠人补洞？
过去很多流程不值得被软件化，因为成本太高、定制太重、需求太碎、变化太快，于是它们就留在 Excel、邮件和人工判断里。但当 AI 让软件生成、流程编排、文本理解、数据总结、自动建议变得便宜之后，那些原来「不值得做成软件」的工作，会重新进入软件化范围。所以 AI 不会让软件变少，它会把一大批原本藏在公司夹缝里的脏活，重新推到软件边界之内。
软件的本质是什么？Benedict 在和 Ben Thompson 的对谈里有一个很好的说法：
"Software is someone sat down and designed a workflow and said this is the right way of doing this from now on."
软件，其实就是有人坐下来设计一个 workflow，然后说，从现在开始，这件事就该这么做。
这句话非常关键。
软件不是功能列表，软件是流程的固化。
一个 CRM 不是一堆字段，而是公司对「客户关系应该如何被记录、推进和管理」的流程定义；一个招聘系统不是一个数据库，而是公司对「候选人应该如何被筛选、沟通、评估和录用」的流程定义；一个广告自动化系统不是一个 dashboard，而是公司对「预算、线索、创意、销售反馈应该如何形成闭环」的流程定义。
所以真正困难的地方不是「把 AI 接进 SaaS」，而是：谁来定义 workflow？Benedict 同时点出另一面，组织里很多流程并不是被设计出来的，而是「长」出来的。一个部门为了方便自己建了一个表，另一个部门为了追数据复制了一份，销售为了省事用自己的方式记客户，老板每个月复盘时再让所有人解释为什么数字对不上，久而久之，这些临时做法就变成了事实流程。
但事实流程不等于好流程。AI 如果直接接进去，只会把原本的混乱自动化。这也是为什么「人人都可以 agentic」是一个危险的说法。个人可以用 agent 提效，但企业不能让每个部门随便搭自己的 agent，然后各自接数据、各自写回、各自定义流程、各自解释结果。那不是 agentic transformation，那是 shadow IT 的下一代。
现在很多人谈 agent，默认想象是：每个人、每个部门都可以自己搭一个 agent，自动完成自己的工作。听起来很民主化，但企业里真正的问题恰恰在这里。企业工作流不是个人 productivity。一旦 agent 进入企业，它就会触碰真实系统、真实客户、真实预算、真实责任。所以 agent 必须分层。
第一层 工具层
Agent 可以读数据、查资料、生成内容、总结会议、写邮件、分析报表。这一层风险相对低，更多是 productivity。
第二层 流程层
Agent 什么时候被触发？先做什么？后做什么？失败怎么办？重复触发怎么办？谁接收结果？这已经不是单人效率，而是组织流程。
第三层 权限层
哪些 agent 只能读？哪些可以写？哪些只能建议？哪些动作可以自动执行？哪些必须审批？
第四层 决策层
谁有权说「从现在开始，这件事就按这个流程做」？谁有权改 routing rule、调预算审批逻辑、决定某个销售状态是否进入下一阶段？
第五层 治理层
所有建议、审批、执行、失败、回滚、结果，都要留下记录。否则出了问题，组织只会回到熟悉的甩锅模式。
所以，真正的 agentic system 不是「多几个 agent」。真正的 agentic system 是：对象被定义清楚，流程被拆清楚，权限被分清楚，拍板人被写清楚，动作被记录清楚。没有这几层，agent 越多，公司越乱。
什么叫企业里的脏活累活？不是简单的体力活，也不是低价值工作，而是那些每天都重要、但没人愿意系统性整理的事情：
数据从一个系统导出，再手动复制到另一个系统；
销售跟进状态靠人自己更新；
广告线索进来后，没人知道到底分给谁；
经销商有没有跟进，总部只能问；
CRM 里字段很多，但真正决策靠微信群、飞书和会议；
客户异议散落在销售通话里，没有回流到营销内容；
广告报告说 CPL 下降了，但业务端没有更多成交；
每个月复盘时，所有人都在解释为什么数字不一致；
预算调整靠经验，但没有记录谁建议、谁批准、结果如何；
某个关键员工离职后，大家才发现流程其实在他脑子里。
Benedict 对此还有一个很锋利的观察：组织里有大量做法是 implicit 的，没有被写下来，不在任何训练数据里，甚至公司里没有任何人能坐下来给你画出一张准确的流程图。这正是 workflow 难做的根源。这些不是普通 SaaS 功能能完全解决的问题，因为它们不是单点功能问题，而是跨系统、跨部门、跨责任边界的 workflow 问题。
AI 的价值也不只是「自动做这些事」。AI 的价值是帮助企业把这些隐性流程显性化，把散落的判断整理成 workflow，把重复性的判断和记录交给系统，把真正需要人拍板的地方暴露出来。也就是说，AI 改造企业的第一步不是自治，而是整理：先整理对象，再整理流程，再整理权限，再整理审批，再整理反馈，最后才谈自动化。
Benedict 在访谈里反复讲一个判断：
"I don't think foundation models are a product. I don't think a chatbot is a product. I think the value will be further up."
模型很可能不是最终产品，chatbot 也不是最终产品，价值会往上走。
他用了一连串历史类比来支撑这个判断：芯片公司没有捕获价值，ISP 没有捕获价值，移动运营商更是典型，过去这些年移动数据流量涨了大约一千五到两千倍，运营商每年合计花约 2000 亿美元 capex，营收接近一万亿美元，却几乎没赚到钱，所有「酷的东西」都被上层的人建走了，价值全部上移。模型很可能会落到类似的位置，变成像云、通信网络、芯片一样的基础设施，非常重要，但价值不一定主要停留在模型层。他甚至给了个量级，未来大概只有三到六家公司能做 frontier model，每年烧的钱在 2000 亿到 2 万亿美元之间，而当模型们都用相似的芯片、做相似的事，凭什么它们会拥有 pricing power？
原因其实很简单：企业买的不是「一个更强的模型」。企业买的是我的销售流程能不能更快、客户支持能不能更准、财务预测能不能更可靠、广告预算能不能更有依据、跨部门流程能不能少一点扯皮、决策能不能留下证据链。这些都不是裸模型能直接交付的，它需要数据接入、权限设计、流程设计、业务对象、例外处理、审批机制、结果记录，以及一个人或一组人定义「这件事从现在开始应该怎么做」。
未来的产品机会不在「我有一个 AI」，而在：我把某个行业里最麻烦、最隐性、最容易漏钱的 workflow，重新做成了可执行的软件。
这也是为什么垂直 AI 比通用 chatbot 更值得关注。通用模型提供能力，垂直 workflow 定义价值。
过去 SaaS 卖的是功能：CRM 管客户，ERP 管资源，HR 系统管员工，project management 管任务，marketing automation 管邮件和 campaign。但 AI 时代的企业软件，会越来越多地触碰一个更难的问题：谁来拍板？
谁来决定某个 lead 应该被分给哪个销售？谁来决定一条广告是否应该暂停？谁来决定某个客户是否应该进入 high-risk list？谁来决定某个 follow-up delay 是否应该触发 escalation？谁来决定某个 AI 建议可以直接执行，还是必须审批？过去，这些事情很多是默认发生的：老板拍板，主管拍板，销售自己拍板，运营临时拍板，或者根本没人拍板，只是事情自然滑过去了。
AI 介入后，这些模糊地带会被迫显性化。因为系统必须知道：什么时候触发，用什么数据判断，推荐什么动作，谁有权批准，执行后写回哪里，失败如何处理，结果如何复盘。这就是 AI 改造 SaaS 的真正方式：不是把每个软件加一个聊天框，而是把原来藏在组织里的拍板机制，变成系统的一部分。Benedict 也补了一句很现实的话，把每一次按钮点击对应到 P&L 几乎不可能，所以连未来软件该怎么定价，本身都还是个未解的问题。
从 SimoDigital 的视角看，这篇文章最重要的启发是：
企业不是缺 AI agent，而是缺一个提纲挈领的 workflow architecture。
现在很多公司对 AI 的想象还是工具化的：市场部想要一个写广告的 agent，销售部想要一个写邮件的 agent，客服部想要一个总结工单的 agent，老板想要一个自动看报表的 agent，运营想要一个自动填表的 agent。这些都可以做，也都可能有用，但如果没有统一的 workflow architecture，它们会很快变成一堆新的孤岛。每个 agent 都在局部优化，每个部门都觉得自己提高了效率，但公司层面仍然不知道：钱从哪里漏掉，谁应该负责，哪个流程应该改，哪个动作真的产生了结果。
这和过去 SaaS 的问题很像。公司买了 CRM，买了广告平台，买了自动化工具，买了 BI dashboard，但真正的流程还是靠人脑连接。AI 不应该重复这个错误。真正的方向应该是：
1 先定义业务对象
Lead、Campaign、Dealer、Opportunity、Follow-up、Approval、Budget Change。
2 再定义状态
new、assigned、contacted、qualified、stuck、approved、rejected、converted。
3 再定义动作
route、pause、approve、escalate、notify、rollback、reassign。
4 再定义权限
谁可以建议，谁可以批准，谁可以执行，谁只能查看。
5 再定义证据链
为什么建议、谁批准、执行结果、下游影响。
6 最后才把 agent 放进去
在一个被定义清楚的系统里，agent 才有真正的工作位置。
Agent 不是起点，workflow architecture 才是起点。
1 Coding agent 先跑出来 ≠ 所有工作流自动跑出来
代码有结构、有测试、有 compiler；企业流程大多是隐性的、跨部门的、靠人补洞的。
2 AI 不会杀死 SaaS，而会让更多脏活进入软件化
AI 降低了生成、理解和编排成本，过去不值得做成软件的流程会重新变成产品机会。
3 模型不是产品，chatbot 也不是终局
真正的价值会长在具体行业、具体 workflow、具体场景里。
4 不是人人都可以随便 agentic
个人可以用 agent 提效，但企业 agent 必须有对象、流程、权限、审批、记录和责任边界。
5 企业最难的不是自动化，而是「定义谁来拍板」
谁来拍板，谁来审批，谁来负责，才是 workflow transformation 的第一步。
6 AI-native SaaS 的机会是重做工作流
不是给旧软件加聊天框，特别是那些长期靠 Excel、邮件、会议和人工判断维持的流程。
7 未来竞争是 workflow architecture 竞争
谁能把隐性流程变成可执行、可追踪、可治理的系统，谁才真正把 AI 带进企业。
AI 不会杀死 SaaS。它会先逼企业面对一个更难的问题：
你公司里那些靠 Excel、邮件、会议、人工判断和跨部门默契维持的脏活累活，到底有没有人能把它们重新定义成一个可执行、可审批、可追踪的 workflow？
真正的 agentic transformation，不是每个部门都搭自己的 agent，而是有人站出来，把流程、权限、拍板机制和责任边界设计清楚，然后让 AI 在这个被治理过的系统里工作。
a16z / Benedict Evans，《The Economics of AI Usage and What's Next For SaaS》
https://www.youtube.com/watch?v=ktl8mNiWqMM
如果你关注 AI、SaaS、enterprise software 和 agentic workflow，这期值得完整听一遍。它表面在聊模型经济学和软件股，真正在讲的是：AI 不会消灭软件，它会逼企业重新面对那些一直没人愿意整理的隐性流程。
企业的瓶颈从来不是缺一个更聪明的模型，而是缺一套把脏活累活变成可治理 operating layer 的 workflow architecture。
