夜雨聆风系列：《企业AI 应用的第一性原理》第一篇
引言：我们还需要打开多少个系统？
想象一个越来越接近现实的工作日早晨。
你对自己的Agent 说：“帮我看看客户A 最近的报价、合同和回款情况。根据上次谈判结果，准备一版新的报价，交期改成两周；如果折扣需要审批，也一并告诉我。”
它先查到客户资料和历史订单，读出合同里关于交付和付款的约定，核对当前价格，形成报价草稿，再把需要确认的事项交回给你。你不需要先想清楚该打开CRM、合同系统、财务系统还是报价系统，也不需要在几个页面之间反复复制粘贴。你表达的是一个工作目标，系统背后的能力则被组织起来，为这个目标服务。
这并不是给几个旧系统加了一个聊天窗口，而是企业软件入口正在发生变化。
在可以预见的未来，Codex、WorkBuddy、Pi 以及其他Agent 客户端，可能成为PC、手机、平板乃至操作系统中的基本智能入口。人们开始工作的方式，未必再是“打开哪个App”，而会越来越多地变成“我现在要把什么事情做完”。对于员工而言，软件不再首先表现为一组菜单、表单和按钮，而更像一个能够理解任务、调用能力、交还结果的工作伙伴。
那么，一个问题就绕不过去：当Agent 成为企业软件的入口，SaaS 还剩下什么？
我的判断是，SaaS 不会消失，但它会被重新分层。页面不再是软件价值的全部，也未必还是日常工作的主要入口。模型、客户端和对话都可以变化；真正不能被替代的，是企业对事实、身份、权限、责任和状态的共同确认。谁说过什么，谁承诺过什么，事情现在进行到哪里，谁有权作出下一步动作——这些不能只存在于某一次对话或某个模型的记忆里。
这正是Oryh.ai 所探索的方向：让Agent 负责理解和行动，让记录系统把行动固化为可验证、可追溯的企业事实。
页面曾经是企业软件的秩序
要理解这种变化，先要承认传统SaaS 的页面并不落后。恰恰相反，它曾经是企业软件得以普及的必要条件。
过去几十年，企业软件的基本结构很稳定：用户登录一个系统，找到对应模块，填写字段，点击按钮，系统按照预设的规则保存数据并推动下一步。页面既是操作入口，也是业务语言。它告诉用户系统里有什么对象、哪些字段必须填写、哪些人可以看见哪些内容，以及一个任务要按什么顺序完成。
在计算机还不能理解自然语言的时候，人只能学习系统的语言。想提交报销，就要知道报销入口在哪里、费用类别怎么选、附件上传到哪里；想创建报价，就要知道客户、产品、价格、税率和交期分别对应哪一个字段。企业通过表单把复杂业务拆成一系列可填写、可点击、可校验的动作。页面把人的意图翻译成了机器能够处理的结构化数据。
因此，传统SaaS 通常把交互界面、业务数据、流程、权限、通知和业务规则紧紧包在同一个产品里。它的好处很明显：边界清楚，使用路径稳定，管理员容易通过配置和培训让组织运转起来。但代价也很明显。员工需要记住每个系统的入口和操作习惯；数据散落在不同应用中；一个看似简单的任务，常常意味着在若干系统之间切换。企业选择了某套系统，也往往同时接受了它对流程、角色和协同方式的表达。
这种模式背后的默认假设是：只有用户进入系统，系统才知道用户要做什么。
Agent改变的，正是这个假设。
当工作从“操作系统”变成“表达任务”
很多企业谈Agent，首先想到的是在原有SaaS 中增加一个智能助手：用户仍然打开原来的系统，只是页面右下角多了一个可以对话的窗口。这当然有价值，也是很多组织最容易开始的一步。但它没有真正改变软件的重心。用户依然要先知道问题属于哪个系统、从哪个页面进入；Agent 只是页面里的一个功能。
更深的变化在于，用户不一定需要先知道哪个系统拥有这项能力。
传统模式大致是这样的：
用户→ 选择业务系统→ 打开页面→ 填写表单→ 获得结果
而以Agent 为入口的模式更接近：
用户→ 表达任务意图→ Agent理解上下文并选择能力→ 写入或读取企业记录→ 交还结果
看上去只是顺序调换了，实际影响却很大。员工不必先学习系统的菜单结构，可以从业务目标出发说话：“把这周的工作整理后提交工时”“客户确认了，按那版报价创建订单”“这张发票能不能报销”“把王总上次提到的风险列出来，准备明天的沟通材料”。这些表达未必符合任何一个系统的表单结构，但Agent 可以先理解它们，再把任务转化为一系列受约束的操作。
这也意味着，业务能力有机会从页面中被拆出来。创建报价、提交工时、核验报销材料、查询待办，不再只能通过某个产品中固定的页面完成。它们可以被封装为Skills：既说明要完成什么，也说明输入需要什么、可以调用哪些工具、哪些环节必须确认、输出应当留下什么记录。只要一个Agent 客户端能够理解并执行这类Skill，它就能成为业务的工作入口，而不必让用户被锁在某一个产品的界面里。
这并不意味着页面会消失。管理员配置权限、查看高密度报表、处理批量数据、做数据治理时，视觉化控制台依然不可替代。对于许多人来说，表格、图表和看板也仍然比一段对话更适合判断问题。变化不在于“有页面”还是“没有页面”，而在于页面不再必须是每个员工每天进入业务的唯一入口。日常、重复、边界清楚的工作，会越来越自然地从“操作软件”转向“把任务交给自己的Agent”。
如果说传统SaaS 是围绕页面组织的应用，那么下一阶段的企业软件，更像是围绕任务、能力与记录组织的服务。
SaaS重新分层后，真正该留下来的是什么
过去，一个SaaS 产品往往同时拥有入口、模型、业务能力和数据。用户在产品提供的界面里工作，使用产品指定的方式完成流程，也通常使用产品集成的智能能力。这种一体化在早期很有效，但在Agent 时代，它会带来新的绑定：入口被绑定到某个客户端，推理被绑定到某个模型，企业事实也被绑定在某个应用的内部逻辑里。
更合理的结构，是把这些层次逐渐解开。Agent 客户端负责与人交互、理解任务和组织上下文；模型负责语言理解、分析和生成；Skills 负责说明某一类业务能力的边界与执行契约；企业记录系统负责保存经得起复核的事实、关系、状态和审计；支付、邮件、物流、知识库等外部能力，则通过标准接口接入。每一层都重要，但它们不必由同一个产品独占。
Oryh.ai的定位，正是在这个结构中成为面向Agent 的企业记录SaaS。它不是要做一个替所有人思考的企业大脑，也不是要把每一条业务规则重新写成封闭的应用代码。它要保存的是企业共同承认的东西：一条记录属于哪个租户，谁创建了它，原始输入是什么，结构化字段是什么，它处于什么状态，与哪些客户、产品、订单或其他对象有关，谁批准过、退回过或需要处理下一步。
因此，Oryh.ai 所谓“纯粹的数据记录”，并不是一个没有约束的数据库。它不替企业拥有业务判断，也不应把业务流转的判断藏在平台里；这些判断可以由承担相应职责的Agent，依据企业的Skill、规则和上下文来分析和执行。但记录系统必须守住底线：身份是否真实、调用者是否有权操作、状态变更是否允许、不同企业的数据是否隔离、发生过的动作能否审计。这些不是可有可无的“后台功能”，而是企业愿意让Agent 参与真实业务的前提。
可以把这种边界概括为一句话：Agent 可以推理，但不能拥有隐含的权力；Oryh.ai 不替人判断，却必须验证行动进入企业事实之前是否正当。
这也是Oryh.ai 与许多“AI 功能型SaaS”最根本的区别。后者常常是把模型嵌入一个应用，用更快的方式帮助用户完成原有页面里的动作；Oryh.ai 更关注在多种Agent、模型和客户端都可能变化的条件下，怎样为企业保留一个稳定的事实层。用户不必被固定到一个浏览器页面或某个单一生态中。日常任务可以在个人习惯的Agent 客户端中完成；浏览器则回到更适合它的场景，例如首次设备授权、管理员配置与需要集中查看的数据工作。
这也给企业更多选择。深度推理未必都要发生在SaaS 平台提供的大模型中。企业可以结合任务敏感度、成本和内部要求，选择本地或私有环境中的模型，也可以选用经过批准的云端模型；有些推理在客户端完成，只把必要的结构化结果写回记录系统。这里不能简单地说“本地就一定安全”或“云端就一定不合规”——数据是否离开设备、工具能访问什么、日志保存在哪里、服务商如何处理数据，都仍然需要治理。真正的价值在于，企业不必被迫把模型、推理入口和业务事实绑定在同一个平台上。
模型会迭代，客户端会更替，Skill 也会不断调整；企业对报价、订单、合同、审批、库存和服务的事实，不应该随着其中任何一层的变化而失去连续性。
Agent越自由，企业越需要一个记录系统
有人会问：既然Agent 已经能够记忆上下文、读取文档、调用工具，为什么还要专门强调“记录系统”？把资料放进知识库，或者让Agent 保留长期记忆，难道不够吗？
不够。因为记忆和事实不是同一回事。
Agent可以记住“客户A 通常很在意交期”“张经理不喜欢太长的邮件”“上次谈判的气氛不错”。这些信息对于理解语境很有帮助，但它们带有概率性，也会随着模型、提示词、上下文窗口和客户端的变化而变化。它们更像一个人工作时形成的经验与印象。
企业真正需要保存的，则是另一类东西：某份合同约定的交付周期是什么，哪一次报价承诺了怎样的价格和税率，谁批准了超出标准的折扣，客户什么时候确认，后来是否变更过交期，变更由谁提出、谁接受。这些不是“我好像记得”，而是需要在三个月、三年之后仍能被查验的事实。
可以用一句简单的话来区分：
Memory belongs to the Agent. Facts belong to the Organization.
记录系统的价值，不在于替Agent 再保存一份答案，而在于把一次次行动放进一条连续的业务现实里。一份报价不是一段生成出来的文本，而应该包含当时的客户、产品、价格、税率、交期、附件和原始需求；即使产品目录后来改价，过去那份报价也不能被重新解释。一张报销单不是“已处理”四个字，而要能够看到发起人、票据、金额、审批意见、退回原因和最终状态。一笔库存也不应只是某个随时会被覆盖的数字，而应有入库、出库、盘点和调整留下的变动依据。
更重要的是，企业业务不是一问一答，而是不断推进又可能回退的过程。报价会从草稿进入审批、发送、成交或失效；采购会从需求进入询价、审批、下单和收货；一个任务可能因为材料不完整被退回，又在补齐后重新提交。系统既要知道结果，也要知道事情此刻在哪里，哪些变化是合法的，下一步应该由谁负责。没有状态，Agent 只能每次从零理解上下文；没有责任，自动化越多，出了问题越难说明。
关系同样不能省略。客户、报价、订单、采购、库存、合同和服务记录，看似分散，实际构成一张企业的事实网络。销售人员创建的报价，为什么可以转成订单；采购的某一条明细，为什么与某个销售承诺有关；库存变化为什么影响某项交付——这些关系如果只存在于对话里，换一个Agent 或换一个人就会断裂。把它们明确记录下来，组织才拥有一个可以持续协同的共同上下文。
因此，记录系统并不只是一个数据仓库。它是企业现实的固定点。Agent 可以围绕它解释、建议、计划和行动，但不能以自己的临时记忆取代它。Agent 负责理解世界，记录系统负责固定已经被组织确认的世界。
从一句“给客户报个价”开始的一条事实链
这种分工听起来抽象，放进一个普通的业务场景里就很直观。
销售人员说：“给客户A 做一版新报价，沿用上次的产品范围，但交期改成两周。”这是一句自然语言，但背后不只是一张报价单。销售Agent 需要先弄清“上次”指哪一份报价，客户是否仍在合作期内，产品是否还能供货，当前价格与上次价格的差异在哪里，新的交期是否会影响成本和承诺。
它可以去查询这些信息，也可以据此生成草稿；但当草稿进入企业事实层时，Oryh.ai 记录的不是一句“已经报价”，而是客户名称、产品快照、目录价格、实际报价、税率、交期、备注、相关附件以及销售人员最初的表达。若价格没有确认，系统不必为了让表单完整而虚构一个数字；“待核价”同样可以是一种被明确记录的状态。真实的企业工作本来就包含不确定性，好的记录不是假装所有事情已经完整，而是把已知、未知和待确认的部分分开。
如果这次折扣超过企业设定的范围，销售Agent 不应凭一句“我认为合理”就直接放行。它根据可读取的规则提交审批；审批人的Agent 则只代表审批人完成自己的审核，把同意、退回或补充材料的事实记录下来。它不能因为结果看上去顺理成章，就越过身份和权限把后续环节一起完成。客户接受报价后，销售Agent 可以创建订单，并保留订单与报价之间的关系；采购或履约相关的Agent 再根据自己的职责处理下一段工作。货物入库、发货和盘点发生变化时，库存的变动理由也应留下，而不是让某个Agent 直接覆盖一个最终数字。
从员工视角看，这一切可能只是一次很自然的对话；从企业视角看，它是一条逐步增长的事实链。对话可以被压缩，模型可以更换，今天负责销售的Agent 也可能换成明天更合适的客户端，但报价为何产生、谁承担了承诺、订单如何形成、库存为什么变化，仍然有据可查。
这就是为什么未来的企业应用不应只追求“回答得更聪明”。更重要的是，能否把每一次足以改变业务现实的行动，变成准确、合法且能被后人理解的记录。
每个人带着自己的Agent工作，协同仍然可以清楚
当人们第一次听到多个Agent 参与企业工作，很容易联想到一个不断互相对话、自动分工的复杂multi-agent 系统：一个超级Agent 统筹所有角色，其他Agent 像虚拟员工一样被调度。它在演示里很吸引人，但在真实组织中往往会带来更难的问题——谁真正拥有决定权，谁对一次错误负责，系统如何解释为什么跳过了某个环节。
Oryh.ai更接近另一种想象：分布式的单主体Agent。每个人有自己的Agent，它有明确的主人、角色、可使用的Skill 和行动边界。销售人员的Agent 服务于销售人员，审批人的Agent 服务于审批人，采购人员的Agent 服务于采购人员。它们不需要为了完成协同而不断“聊天”，而是在同一组共享事实和明确状态的周围接力工作。
这其实更接近现实中的组织。人并不是靠无限沟通完成所有协同，而是依靠合同、报价、订单、任务、审批和交付物这些共同对象协作。一个人完成自己负责的部分，形成可见的状态变化；下一个人基于这一状态开始自己的工作。Agent 进入企业后，也没有理由把本来清楚的责任边界重新模糊成一个中心化的智能黑箱。
这里的“分布式”并不等于把企业数据随意分散，更不意味着不要统一的安全边界。恰恰相反，主体可以分布，企业共同认可的事实、权限验证和审计要求必须稳定。Oryh.ai 所承担的，正是这个共同层：让不同人、不同客户端、不同模型所驱动的行动，最终落在同一套可验证的记录上。去中心化的是行动与智能的入口，不是对责任和事实的放弃。
这也使企业进入Agent 原生应用时不必从宏大的“全自动化”开始。可以先选一个边界清楚、反复发生又需要留痕的任务，例如工时、报销、采购申请、报价草稿或服务记录。先明确哪些信息一旦形成就属于组织资产，哪些动作必须由本人确认，哪些状态只能由特定角色推进。让一个人的Agent 把一件事做好，再让记录自然成为下一个人开始工作的依据。这样，复杂协同会被拆回每个人清晰的单一任务，而不是被堆成一套难以治理的超级编排。
结语：SaaS会从应用，变成企业事实基础设施
Agent的出现，不会让企业软件消失；它会让企业重新思考软件应该把什么放在中心。
未来，用户也许不再每天打开多个业务系统。模型可以替换，客户端可以替换，Skills 可以重新编排，网页会更多地留给配置、治理和视觉化工作。但企业仍然需要一个可靠的地方，保存真正发生过的事情：谁以什么身份提出了什么，谁被授权做了什么，什么状态因此改变，谁承担下一步责任。
这也是Oryh.ai 的第一性原理：不把企业锁进一个超级Agent，也不把企业事实交给某次不可复现的推理。让智能保持可替换、让行动尽可能靠近每个具体的人，同时让共同事实始终可验证。
当SaaS 不再只是用户每天操作的一组页面，它就有机会成为更底层的企业事实基础设施。
Agent负责理解和行动，Oryh.ai 负责把行动固化为可验证的企业事实。
本系列的第二篇《Agent 可以推理，但不能拥有隐含的权力》，将讨论这个边界中最关键的问题：在企业环境里，身份、授权、规则、状态和责任，为什么必须从隐含配置变成显式结构。
第三篇《不需要超级Agent：分布式单主体如何完成企业协同？》将回到组织协作本身，讨论当每个人带着自己的Agent 工作时，复杂任务如何通过共享事实、清晰责任与状态变化自然接力，而不是被塞进一个难以治理的超级编排系统。
