情境图的自动形式化：企业软件护城河的移动方向
做一个简单的思想实验：如果你能用“共振式编码”来构建一个 ERP，会怎样？
用普通英语描述你想要的。几小时内就能得到可用系统，而不是几个季度。无需征求建议书。无需大批顾问。无需数月配置才能达到上线的第一天。
如果这成为现实，变化并非仅仅是企业软件变得更便宜，而是价值单位发生了转移。你可以用多种方式描述这种转变。一个有用的视角是，竞争轴线从覆盖面积 × 嵌入逻辑，转向情境覆盖 × 可执行性。但核心观点很简单：系统能做的越多，就越削弱旧有的“固定应用”范式的价值。
最后的时代：模块 × 业务逻辑
观察过去 20 年另一种方式是，企业软件在捆绑（ERP/CRM/HRIS 等横向套件）与拆分（在特定工作流中更深入的垂直 SaaS）之间来回摆动。人类在这些模块间穿梭。他们点击完成工作流。他们调和异常。他们就是执行引擎。胜出的厂商构建了大的表面：更多席位、更多对象、更多内置于产品中的最佳实践。竞争本质上沿着两条轴线展开：
- 模块广度（x 轴）： 覆盖了多少功能（财务、人力、采购、销售等）
- 嵌入逻辑深度（y 轴）： 产品编码了多少特定领域的流程和政策
下一个时代：上下文覆盖 × 可执行性
在一个以智能体为核心的世界里，用户不再“在应用中工作”，而是开始与智能体协作。智能体进行规划、编排、征求批准并跨系统执行。用户界面变得更为短暂——只是必要时进入的一处入口，而非工作的常驻场所。
因此轴线发生了转移：
- 上下文覆盖（x 轴）：智能体对以前仅由人类完成的工作理解到何种程度——该做什么、如何做出决策、该向谁询问、去哪里获取数据并如何正确解读、在具体情境中如何考虑先例等。
- 可操作性 / 自主性（纵轴）： 它在多大程度上能够可靠地按照用户意图端到端地完成工作，并具备审批与安全防护
新兴的企业技术栈
在以代理为本的企业中，技术栈开始转变为：
1）共享基底
这不仅仅是事后查询的仓库，而是在写入路径上可以信赖的系统。如果代理要执行操作，就需要一个状态一致且经过验证的规范位置。数据所在之处——先前的记录系统——变得不那么相关
2）业务的语义模型（上下文图）
“上下文图”最好被理解为决策与执行的表征，不仅是知识图谱，还包括按场景定义、异常模式、升级规范和先例。今天的问题在于，大多数公司对此只有极为薄弱的版本，只有几个结构化系统（ERP/CRM/HRIS）加上一个数据湖。其余的则是部落式的知识。要构建一个面向代理的企业，你需要绘制出如何做到这一点。
3）控制平面
控制平面是工作流、审批、权限、异常处理、可观察性和审计追踪所在的地方。它在执行者同时跨多个系统并行执行时，特别成为协调行动的操作系统。
4) 代理 + 即时 UI
与其让用户学习如何使用复杂软件，不如让他们用简明的英语表达意图，并且仅在能产生杠杆效应时才呈现界面：一个用于审查、批准、纠正和协作的轻量化表层。少一些仪表盘，更多出现后完成任务即消失的面向任务的微型应用。CRUD 也会进化。
底层业务逻辑的上下文图
大多数企业像冰山，只有一小部分“公司”以数字化的形式存在（表格、文档、工单）。大多数内容存在于隐性运营语境中：我们为什么那样做、哪些边缘情形重要、顾客暗示了什么、CxO 能容忍什么、当规则冲突时我们如何权衡取舍。这就是为什么把应用连接起来并摄取文档会失败，也说明了检索可以找到事实却无法可靠再现判决的原因。
要理解工作的底层结构，就要理解实体、关系和约束，涵盖以下方面：
- 顾客和合同。根据顾客/供应商的规模、对你业务的重要性等差异甚大。
- 产品和定价
- 对立的定义（“什么算作收入？”取决于具体情境）
- 因地区、细分市场和交易类型而异的正式与非正式审批政策
- 存在于实践而非文档中的例外与覆盖规则
- 驱动该公司/团队“如何开展工作”的文化规范（先问许可还是先求原谅、集权化等）
上下文要求把基础结构从实体、关系、约束和权限中形式化。Foundation Capital 关于上下文图的文章讨论了捕捉这些决策轨迹（行动背后的“原因”）的重要性，以及它们如何累积成新的记录系统。但上下文需要的不仅仅是与工作流关联的指令 + 工具 + 目标，它还需要另一层。 对该底层上下文进行自动形式化的层，是实现自治的前提。
自动形式化是开启自治的钥匙
人类以模糊的方式传达意图。企业依靠隐含规则运行。
我们说话时用速记。省略范围，假定共享定义，依赖未成文的先例，比如如何处理这家供应商、清理账目、使其合规等。那些不是命令，而是模糊的提示，需由人工操作者根据系统通常并不具备的上下文来解读。
在企业环境中，一次错误的动作可能抹除自动化带来的全部价值。因此目标不是执行更多，而是在意图被充分指定以确保安全时才执行，将零散的请求转化为可审查的规范（将会发生什么变化、适用哪些策略和约束、谁必须批准、可能出什么问题以及如何回滚）。然后通过人工反馈和先例随时间改进该规范。
把它想象成地图（上下文图）与编译器（自动形式化）之别 。 上下文图就是地图 ，展示实体、定义、关系、约束、权限和既有决策。 自动形式化就是编译器 ，将任务转化为受治理的提案（预期结果、受影响的利益相关者、所作权衡、必须通过的检查以及所需审批）。 它是可审查的人类审议层。
更进一步：模糊性是特性，而非缺陷。 人并不是一致性的优化器。我们会改变优先级、以不同方式权衡利益相关者，并在社会和政治约束中运作——顾客暗示的意图、团队的预期、CxO 能容忍的范围。这就是为什么判断会被外包——不是因为我们无法检索信息，而是因为我们不信任自己（或某个模型）在没有共同框架的情况下能够正确地权衡利弊。
所以“拥有上下文”还不够。系统必须决定什么重要以及为什么重要 ，并以人类能够理解的方式呈现。护城河在于那些跨越评价、纠正、升级和先例捕捉的学习循环——越容易运行，护城河就越强。
可组合开始失去意义
当用户体验是由人在不同工具间拼接而成时，可组合软件是有意义的。当界面不再需要在复杂的表面上导航 UI/UX，会发生什么？
当代理成为界面时，可组合性不再是关于组装用户界面 ，而更多是关于组装可靠的执行 。
UI/UX 开始演化为更接近 Apple 的 App Clips 的东西 ：小型、即时调用的任务片段软件。随着交互模型的改变，应用层变得不那么具有防御性。其含义微妙但重要：应用层的护城河变薄，护城河下移到工作流层和数据/上下文层。交互媒介可以根据任务而改变
因此这可能就是电子表格迎来第二生命的原因 ：它们是我们最好的便捷记录工具。它们是一种黑客式的办法，允许人类将混乱的、半结构化的现实假装成结构化到可以行动的程度。在以智能代理为本的企业中，电子表格将成为它本应成为的样子——位于有治理的模式、工作流和审批之上的灵活便捷记录界面，而不是一个平行的真相宇宙。
设计是基础性工作
随着界面变得更加短暂，设计并不会变得不重要……它变得更为基础。设计成为混乱的人类意图与可执行行动之间的翻译层。设计是直观的。它成为生成最终用户体验的基底的一部分。
10× 代理：我们看到的投资回报示例
在上一个时代，企业软件向用户出售功能 。在下一个时代，它向企业出售成果 。你可以已见早期轮廓／下面分享一些真实案例：
- 财务运营压缩为异常处理。一名会计即可支持一个年运行率超过1.5亿美元的组织。月末结账从10个工作日缩短为1天。
- 一个 10 人规模的 SDR 团队变为由一名运营人员监督的代理组，这些代理负责调研、排序、路由和预约；人类只在最需要建立关系的地方投入时间——终端客户
- 内部工具变为自动生成的任务专用微应用
- 80%的支持工单实现端到端解决
- PM 的杠杆效应更高。代理起草规格说明、质量保证计划、发布说明、实验分析和客户汇总。CPO 收回超过 30%的时间
未来护城河聚集之处，以及介于两者之间的阶段
我们正处于介于两者之间的阶段。
在上下文图上，公司大部分仍以部落式/默会知识的形式存在于人们脑中。只有一小部分以结构化或非结构化的产物存在（系统、文档、电子表格）。而在数据基底和控制平面上，我们仍然缺乏一种被广泛采纳的方式来表示工作 （实体、状态转换、不变量与权限）。
这种差距在实践中立刻显现出来。即便你用“完美”的提示，附上逐步指引、截图、流程图、系统规范，你仍然可能得到错误的结果。不是因为代理无法阅读，而是因为意图表述不足、策略隐含，系统没有一种形式化的方法在事情发生之前证明应该发生什么。
在上一个时代，软件对工作流程进行编码。下一个时代的胜者则将在可审计的执行中编码判决。因此，这一机会是多维的，公司正沿着两个轴线构建：context coverage（语境覆盖）和 actionability（可执行性）。这创造了一个持久优势可以复合增长的窗口：
代理（插入到现有系统模块中）
最快的路径是坐在 ERP/CRM/HRIS 之上而非替代它们——掌控写入路径：权限、审批、审计日志、重试、回滚。示例包括 Spellbook、Basis、Harvey、PolyAI
纵向劳动力自治（按角色提供服务） 这一类别将焦点从管理软件转向执行专门职业。这些代理不仅仅作为遗留系统的“执行层”，还从零开始产出新的数字产物（例如代码、拉取请求、技术规格）。示例包括 Cognition 的 Devin 等
受控自治（对现有系统的全面编排）
在短期内，“代理”靠被控制而非变聪明来取胜。护城河是一个能够安全编排遗留系统的执行层，涵盖差异、审批、可追溯性、回滚等功能。示例：类似 ServiceNow 的工作流/编排层、下一代 RPA。其他例子包括 Distyl AI（跨系统的编排 + 运营模式重构）
语义锁定（掌控定义）
持久资产不是文档，而是公司的内部语义：定义、例外和先例。这确实像一座冰山，关于已固化在某种数字载体中的公司数据很少。大多数仍停留在部落式/默会知识。示例包括 Glean 的“知识/企业图谱”以及 Palantir AIP / Agent Studio 的框架
批量替换（取代现有系统）
据说你可以迁移大约 75%的模式，但最后 25%决定替换能否成功。域特定的上下文无法一一映射（派生字段、隐式转换、自定义定义），必须依赖人工验证。有少数领域适合整体替换，但前提是范围受限、迁移可处理且价值立竿见影（例如，缩短周期、加强控制和合规）。例子包括明确出售次日迁移服务的 DualEntry
以服务为先的方法
因为难点不在模型，而在将现实映射进来。服务层成为把凌乱工作变成产品的工厂。现有的 ERP 之所以依然存在，是因为迁移痛苦且风险不对称。实施和维护负担不仅仅是成本，它也是锁定的一部分。“面向世界的 AI 服务”成为了一个真实的类别：AI 不只是对软件预算施压；它还对行政与管理（G&A）以及因软件脆弱而需要人工黏合的咨询开支施压。有些人称之为企业的“Palantir 化”；更简单地说， 服务与软件正在融合 。例如 Pace、Crosby、Klarity AI。还有整合并购。
Adrian
特别感谢 Vinod Khosla、Hari 和 Nicole、Scott Woody、Andrew Antos、Noah Brown、Vishnu Srinivasan 的宝贵意见！
