--- title: "企业软件的未来：AI、系统工程与可验证性" canonical: https://wavect.io/zh/blog/future-of-enterprise-software/ language: zh description: "Alexandre Kotcherguine 与 Kevin Riedl 论述 AI 如何让系统工程重回企业软件，以及去中心化如何使架构保证变得可验证。" image: "https://wavect.io/img/general/bak/open_graph_preview.jpg" --- [**返回**](/zh/blog/overview/) ![Alexandre Kotcherguine](/img/team/alexandre-kotcherguine.jpeg) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) Alexandre Kotcherguine [Kevin Riedl](/zh/team/kevin-riedl/) 14 min 阅读 · 2026 年 7 月 14 日 [**下一篇**](/zh/blog/the-factory-returns/) 要点速览 当团队把整个系统，而不是单个服务或 SaaS 工具，作为设计对象时，企业软件才能重新获得一致性。AI 可以降低持续维护规格、接口、测试和架构检查的成本。去中心化验证能够加强少数高风险保证，但不能取代合同、审计或可靠的内部控制。只有当可验证性带来的价值高于新增复杂度时，才值得采用这种机制。 # 企业软件的未来 **AI 如何让系统工程纪律回归，而去中心化如何让它变得可证明** **Polity 发布 | 2026 年 7 月** **作者：Alexandre Kotcherguine，Polity Vision Officer & Investor； Kevin Riedl，Wavect GmbH Managing Partner** *本文讨论企业软件架构与工程方法论，依据公开资料，包括同行评审与预印本研究、行业调查，以及截至 2026 年年中的供应商和从业者报道。文中讨论的若干技术仍处于成熟曲线的早期阶段，相关论断也据此加以说明。来自快速变化领域的数字只是时点快照，可能被修订。本文不构成任何专业、法律或投资建议。* ## 执行摘要 二十年来，企业软件一直通过拆分来追求敏捷。单体被分解为微服务；套件被拆散成蔓生的 SaaS；交付不断加速，直到把一切维系在一起的架构悄然消解。承诺中的敏捷往往以它的反面到来，*分布式单体*：它保留了旧世界的全部耦合，却失去了旧世界的整体一致性；没有人拥有全局，每一次变更都变成协调练习。在碎片化中失去的是系统工程：把整体视为设计对象的纪律，以明确的需求、受治理的接口、架构完整性，以及针对意图的验证为基础。本文认为，下一阶段将同时在两个方向上逆转这一趋势。首先，AI 让系统工程方法再次能够以可负担的成本规模化。它把受治理、规格说明优先的「软件工厂」从代码扩展到全系统架构，使意图能够再次被捕获、建模与执行，而不是任其侵蚀。其次，也是影响更深的一点，去中心化会*加固*结果：它把系统的保证从*受信任*转向*可验证*，从记录在纸面上、由组织信誉背书的合约，转向由密码学证明、链上证明和分布式控制执行的合约，任何单一方都无法悄然覆盖。工厂构建系统；链证明它的行为。本文也完整陈述坦率的限制：可验证计算仍远比执行昂贵；它首先出现在高风险、低流量场景，而不会同时遍及所有地方；对企业内部的大部分区域而言，现有的制度性信任仍是正确工具。本文的主张并不是密码学证明取代审计和合同，而是它把保障延伸到那些工具无法跨越的边界之外。但方向已经清楚，而且落在熟悉的领域：Polity 所从事的受监管链上金融，正是可证明架构最先被要求、也最早被采用的地方。 ## 碎片化时代 2010 年代占主导地位的企业架构运动有着清晰且大体合理的动机。单体已经长成「大泥球」；高度耦合、难以更改、部署缓慢；而微服务承诺提供出口：围绕业务能力分解应用，让每个服务独立部署，让团队并行推进。对许多组织来说，它起初确实有效。但这一模式被广泛当作默认答案，而不是经过权衡的取舍；整个行业反复出现一种具有代表性的失败模式，从业者最终为它起了一个精确的名字。按照一个被广泛引用的描述，「分布式单体」拥有微服务的运维复杂度，却没有架构独立性：服务在物理上分离、在逻辑上耦合；彼此依赖数据库 schema；要求同步部署；通过很长的调用链相互调用；因此一个服务的变化会破坏另外三个，每次发布都成为协调练习 (1)。组织得到了更多 repository、更多 pipeline、更多日志、更多故障模式和更多治理开销；却没有得到更快行动的能力。 到本十年中期，这种纠偏已经出现在数据中，而不只是在行业媒体里。Cloud Native Computing Foundation 的 2024 Cloud Native Survey 调查了 689 位技术决策者，发现已经采用微服务的组织中有 42% 正在把服务重新整合为更大的可部署单元，而 service mesh；让微服务能够在规模化环境中被管理的基础设施；采用率从 18% 降至 8% (2)。这并不是对分布式架构的全面否定；cloud-native 的总体采用率仍接近 90%。它是在纠正过早采用，整合中的团队转向模块化单体；在单一部署中保持严格的内部边界；并报告成本和部署时间显著下降。Amazon 的 Prime Video 团队早已给出范例：它把一条微服务监控 pipeline 收拢回单体，为某项监控 workload 将基础设施成本降低约 90%；该公司的 chief technology officer 直接点明其中教训：构建可演进系统是一种策略，不是一种宗教。结论并不是分布式是错的，而是它是目的地，不是起点；只有维持其所要求纪律的团队，才能获得它的收益：明确归属的接口、版本化的合约、得到执行的边界。那句限定；只有维持纪律的团队；就是整个故事。碎片化失败，并不是因为分解本身是坏主意；它失败，是因为没有系统工程的分解不过是多加了几个步骤的熵。 ## 失去的东西：系统工程 系统工程是被碎片化挤走的、更古老的纪律。它把系统整体，而不是一组各自独立优化的部件，视为首要设计对象。它的工具包括：在构建之前捕获意图的需求、治理部件交互方式的接口合约、使整体变得可读的架构模型，以及把构建出的系统与规格说明进行核验的验证过程。这些实践并不光鲜，而碎片化时代的 move-fast 文化把它们视为官僚阻力，要以速度之名摆脱。这里的讽刺，与企业 Agile 更早的历史一样：放弃纪律并没有带来持久的速度；它制造了越来越缓慢、越来越脆弱的系统，原因正是再没有人照看整体。 这项纪律之所以被放弃，而不仅仅是被忽视，是有原因的：以现代软件的规模与节奏，手工进行系统工程确实无法负担。持续维护一个大型系统准确、最新的模型，包括组件、依赖、合约与约束，是一项劳动密集型任务，它过时的速度比人类维护它的速度更快。基于模型的系统工程，是构建并推理这类模型的正式学科，长期以来一直被认为很强大，同时又被认为过于沉重，绝大多数组织无法持续采用。全系统视角是一种奢侈品。于是团队不再购买它，架构则退化成运行中的服务碰巧呈现的样子。 ## 为什么 AI 让这项纪律回归 [本系列上一篇文章](/zh/blog/the-factory-returns/) 的论点是：AI 并不废除工程纪律，而是把它沿着技术栈向上迁移，从敲击键盘迁移到规格说明，而且受治理的「软件工厂」只有在手艺被嵌入 pipeline、而不是被排除时才会真正运转 (3)。再向上扩展一层，同样的逻辑也适用于架构。系统工程之所以负担不起，在于构建与维护全系统模型、并让意图、规格说明和实现保持一致所需的人力成本。AI 恰好压低了这种成本。大型模型如今可以解析庞大的 legacy codebase，把其中隐含的业务规则和意图提取成人类可读的需求，让现代化从一场高风险的打捞行动，变成可以处理的设计问题。系统工程社区也已经开始为基于模型的系统工程本身构建 AI copilot，以降低过去使这项纪律遥不可及的门槛 (4)。 结果是，全系统视角不再是一种奢侈品。一份持续演进、版本化的规格说明，正是约束 agentic code factory 的同一项工件，成为架构的 source of truth，由不知疲倦的智能体不断与运行中的系统进行核对。接口可以从合约生成，并自动对照合约进行检查；架构漂移可以在发生时被发现，而不是在事故中才被发现；模型能够保持最新，因为维护它不再主要是人类工作。这就是系统工程的回归，不是对 waterfall 的怀旧，而是一项终于在经济上可行的纪律。企业系统可以再次作为整体被设计，因为现在又能以可接受的成本把整体保持在视野之中。 ## 只有 AI 的边界：受信任不等于已证明 但仅凭 AI 恢复的系统工程，会以一种更微妙的形式重新引入它所解决的问题。由智能体核对的规格说明仍是一份文档；由 pipeline 执行的接口合约仍由控制 pipeline 的人执行；由系统写入的审计日志，其可信程度仍取决于能够改写它的一方。整个装置都建立在委托信任上，用户相信部署组织正确地完成了规格说明、诚实地执行了验证，并且没有篡改记录。在单个企业内部，这也许可以接受。但跨越定义现代系统的边界，公司之间、机构与监管者之间、网络与参与者之间，这恰好是无法成立的假设。而在 agentic 时代，风险进一步上升：当代码乃至架构变更的生成速度超过任何人独立审查的速度，「相信我们，系统会按照规格说明运行」就成了一项任何交易对手都不应凭信念接受的主张。 近期文献把这里的区别清晰地概括为 *trusted* 与 *verifiable*。受信任系统依靠中心化声誉、制度性审计与内部治理：可靠性由法律协议和企业监督保障，内部计算则隐藏在供应商关于其正确运行的保证背后。可验证系统遵循相反原则，*以验证代替信任*，用任何人都能检查的保证，取代对中心化一方的盲目信任。它对系统提出的是另一种主张：不是「我们证明它运行正确」，而是「这是它确实如此运行的证明」(5)。恢复系统工程会告诉你架构已经被规格化；但仅凭这一点，并不能告诉规格制定组织之外的任何人，这套架构是真实的。 ## 去中心化如何加固它 去中心化正是在这里发挥作用，而且它在本文论证中的首要角色不是拓扑性的，而是证据性的。去中心化底层为企业系统提供的最重要能力，不是让系统运行在许多地方，而是让系统的保证可以被证明，而不只是被宣称。密码学验证把架构合约从纸面政策转化为可执行、可独立检查的事实。一项计算可以为了速度在链下运行，同时附带一份紧凑证明，在链上以较低成本验证它确实按照已承诺的模型或规格说明正确执行，而无须暴露底层数据或逻辑。2026 年的行业实践越来越把链视为 AI 驱动系统的问责与来源层：一个用于模型证明、决策记录和审计日志的共享底层，任何人都无法悄然改写。正如一项调查所说，问题从系统能否产生输出，转变为你能否证明输出如何产生、谁对此负责，以及它能否经受审查。 使这一点变得可行的是一种不对称：计算可以昂贵，而验证可以便宜。模型可以在 cluster 上运行一个小时，然后返回一份密码学收据，交易对手只需数毫秒就能检查，无需重新运行计算，也无需看到输入，便能确认究竟计算了什么。基础设施已经不再是假设，其中三类已经投入生产。通用 [零知识虚拟机](/zh/blog/zero-knowledge-proofs-production-2026/) ，例如 RISC Zero，把普通程序编译到一个得到证明的指令集，并生成任何一方都能针对公链合约验证的收据；Lagrange 和 Axiom 等协处理器证明链上状态的事实；而面向 machine learning 的专用 framework，例如 Starknet 上的 Giza，使自主智能体能够证明它的每项决定确实来自它所承诺的模型，同时权重与策略保持私密。让风险变得具体的是受监管 use case：借贷决定不再是「相信银行的风险模型」，而可以附带一份证明，说明这个特定模型使用这些冻结参数评估了这位申请人的数据。关于系统的主张不再取决于运营方的信誉，而成为监管者、交易对手或 smart contract 能自行检查的事实。 还有两个方向加强了证据性这一点。从拓扑上说，把系统分布在独立节点之间，可以消除单点故障，更重要的是消除单点控制，一方能够悄然改变行为、压下记录或覆盖合约的位置。从制度构造上说，去中心化治理为工厂本身提供了一层权威：规格说明如何修改、智能体如何授权、变更如何获准，都可以由明确、分布式而且本身可审计的规则决定，而不是掌握在持有密钥的人手中。三个方向合在一起，把恢复后的架构从一项工程良好的私有主张，转变为其完整性能够从外部被读取和执行的系统。以这种方式加固的工厂，不只是把系统构建得好；它让系统能持续向那些从未被要求信任它的各方，证明自己确实如其所称。 ## 反对意见：成熟度，以及是否真的需要 对此最有力的反对意见不是哲学性的，而是实践性的；它值得以最强形式被陈述，因为就今天而言它是正确的。可验证计算很昂贵。按照目前的估计，为一项计算生成密码学证明，要比执行计算本身沉重若干个数量级，对大型模型而言，据报告证明速度可能比普通 inference 慢数千倍。该领域坦率的评估明确指出：证明小型到中型模型的 inference 是可行的；大型模型的 inference 只能部分证明；完整训练的证明仍是愿景 (6)。怀疑者有理由得出结论：对 2026 年的大多数企业 workload 来说，「可证明架构」是一项研究计划，而不是可以部署的现实；他们也有理由指出，许多以 verifiable AI 名义营销的东西，比起已交付能力，更接近愿景。 这项反对意见对现状判断正确，对趋势判断错误，而答案的形状很有启发。随着证明系统、硬件加速和 circuit design 改进，证明的 overhead 已经大幅下降，并仍在继续下降；更轻量的证明方案也正是为了应对成本而出现。更重要的是，这项技术不必普及到所有场景，也能发挥决定性作用。一贯的判断是，可验证方法会首先抵达最需要它的地方：高风险、低流量环境，受监管决策、金融结算、内容来源，它们可以承担证明成本，因为独立可检查保证的价值在这些场景中最高。这不是论证的弱点；这就是论证本身。可证明架构不会同时抵达所有地方。它会首先抵达那些值得为证明系统行为付费的领域，也就是说，先到受监管金融，再到消费应用；先到跨机构结算，再到内部工具。如今的前沿很窄，但正在拓宽，而且正是从本文最关心的那片领域开始拓宽。 还有一项更深层的反对意见，它与成本无关。事实上，大多数企业根本不需要密码学验证，因为它们所依赖的信任是制度性的，而且一直如此：合同、声誉、监管机构，以及四大等公司的经审计保证。按照这种观点，一份 SOC 2 报告或可信执行环境已经提供「足够好」的验证；监管机构如今接受这些工具；用更难构建的密码学家与 prover 技术栈，取代有效运作的律师与审计师技术栈，是一个寻找问题的解决方案。这是对本文论点最严肃的挑战，而坦率的回答会承认其中很大一部分。制度性信任不会消失；对组织庞大的内部区域而言，各方已经相互信任，它仍是正确而且更便宜的工具；该领域自己的评估也坦率承认，密码学验证还不能直接取代传统审计，两者目前是互补关系。但这一让步恰好定位了新层真正发挥价值的地方。制度性信任只在存在可以信任的机构、存在可以诉诸的共同权威时有效。在边界处，彼此不在对方审计范围内的公司之间、网络与无法检查其运营方的参与者之间、自主智能体与它以机器速度交易的交易对手之间，「相信这家公司」找不到可以指向的公司。可验证架构不是审计的替代品；它把保障延伸到审计无法覆盖的接缝之外，而一个去中心化、多方参与的金融系统恰恰就是由这些接缝构成。 ## 结论：为被证明而工程化 企业软件的未来，不是单体与微服务、中心化与分布式之间又一次钟摆摆动。它是对系统更古老、更严肃态度的恢复：一种技术让它重新可负担，另一种技术让它变得可信。AI 让碎片化曾经丢弃的系统工程纪律回归，整体被保持在视野中，意图被捕获并核对，架构被设计而不是自然堆积，因为 AI 压低了曾使这项纪律成为奢侈品的人力成本。去中心化随后完成文档和良好意愿都无法做到的事：让最终系统携带自己的证据，使它的保证不只是被规格化，而且能够被证明；不只是受到信任，而且能够被验证；不只是由持有密钥的人执行，而且对所有依赖它的人都清晰可读。 这两场运动相互补充，各自回答了另一方的弱点。没有验证的系统工程，给你的是一项设计良好的私有主张，比碎片化更好，但仍然依赖某一方的信誉。没有系统工程的验证，给你的是一套不连贯架构的密码学证明，对一个从未被作为整体设计的系统，作出数学上确定的陈述。两者结合，描述的是一种为被证明而工程化的企业系统：以纪律进行规格化，由受治理的工厂构建，并由一种能把合约转化为任何人都能检查之事实的底层加固。对软件行业的大部分领域来说，这会随着证明层成熟，逐个 workload 渐进到来。对受监管链上金融而言，可证明行为的要求不是偏好，而是运营条件，它正在此刻到来。这正是企业软件未来最先被构建的地基，也是 Polity 工作所在的地基。 *碎片化时代问的是软件能够以多快的速度移动。正在开始的新时代提出一个更难、也更持久的问题：不是系统能够多快变化，而是在任何时刻，你能否证明它是什么。最终胜出的组织，会把这个问题视为设计问题，而不是 compliance 负担，并从第一份规格说明开始，构建为被证明而工程化的系统。* --- ## 关于 Polity 本文是 Polity 治理模型内持续推进的治理与思想领导力出版计划的一部分。Polity 的核心论点是，持久结果由治理架构塑造：工作、价值与义务通过规则、激励和制度形成。本文描述的融合，由 AI 恢复的系统工程，经可验证、去中心化底层加固，正是在这个意义上的治理问题：它是一套要求被信任的系统，与一套可以被检查的系统之间的区别。Polity 为受监管数字金融构建基础设施，通过治理 framework 连接去中心化系统与机构级 compliance 要求；如何让自主、高吞吐的软件生产在保障是运营条件的环境中，不仅快速而且可证明，正是它直接面对的问题。 ## 关于 Wavect Wavect GmbH 是一家奥地利软件工程公司，为初创企业、成长型企业和大型企业构建产品导向的软件，涵盖 [全栈开发](/zh/services/software-development/) 、 [兼职工程与产品领导](/zh/services/fractional-ctpo/) 、 [软件质量保证](/zh/services/software-quality-assurance/) ，以及 [人工智能](/zh/services/artificial-intelligence/) 、 [区块链](/zh/services/blockchain/) 和 [零知识系统](/zh/services/zero-knowledge/) 的应用工作。Wavect 曾为 Polity 项目提供软件开发与质量保证服务，共同作者 Kevin Riedl 是该公司的 Managing Partner。更多信息见 [https://wavect.io](https://wavect.io) 。 **免责声明：**本文仅供信息与教育用途，不构成专业、法律、金融或工程建议，也不代表对任何方法论、产品、协议、服务或组织的背书。文中提及具名研究人员、研究、工具、标准与公司，仅用于分析与评论。所讨论的若干技术，尤其是可验证计算和模型执行的零知识证明，仍处于成熟早期，其能力与成本仍在演进；相关限制已在正文中加以说明。所有第三方来源均为参考而引用；收录并不意味着 Polity 的背书或关联。共同作者 Kevin Riedl 是 Wavect GmbH 的 Managing Partner；Wavect 为 Polity 项目提供软件开发与质量保证服务（见上文「关于 Wavect」）。为透明起见，本文披露此商业关系；它不影响分析的独立性。文中观点仅代表作者本人。 ## 参考文献 1. vFunction (2026) *Distributed Monolith Architecture: What It Is, Why It Happens, and How to Fix It.* Available at: [https://vfunction.com/blog/distributed-monolith-architecture/](https://vfunction.com/blog/distributed-monolith-architecture/) (Accessed: 23 June 2026). 2. Cloud Native Computing Foundation (CNCF) (2025) *2024 Cloud Native Survey.* (689 respondents; 42% consolidating microservices; service-mesh decline 18%→8%.) Available at: [https://www.cncf.io/reports/the-cncf-annual-cloud-native-survey/](https://www.cncf.io/reports/the-cncf-annual-cloud-native-survey/) (Accessed: 23 June 2026). 3. McIlroy, M.D. (1968) ‘Mass-produced software components’, in Naur, P. and Randell, B. (eds.) *Software Engineering: Report on a Conference Sponsored by the NATO Science Committee.* Brussels: NATO Scientific Affairs Division, pp. 138–155. Available at: [https://www.cs.dartmouth.edu/~doug/components.txt](https://www.cs.dartmouth.edu/~doug/components.txt) (Accessed: 23 June 2026). 4. Zhang, W., Cockburn, C., Henshaw, M. et al. (2026) ‘MBSE Co-Pilot: A Research Roadmap’, *Systems Engineering*, 29(1), pp. 20–33. INCOSE / Wiley. doi:10.1002/sys.70011. Available at: [https://doi.org/10.1002/sys.70011](https://doi.org/10.1002/sys.70011) (Accessed: 23 June 2026). 5. Chainlink (2026) *Verifiable AI vs Trusted AI: Key Differences.* (Delegated-trust vs cryptographic-trust distinction; relevance to financial services.) Available at: [https://chain.link/article/verifiable-ai-vs-trusted-ai](https://chain.link/article/verifiable-ai-vs-trusted-ai) (Accessed: 23 June 2026). 6. Everstake (2026) *Blockchain and Verifiable AI: Can AI Be Blindly Trusted?* (Feasibility of proving small/mid vs large-model inference; staged 2026–2028 adoption; high-stakes-first pattern.) Available at: [https://everstake.one/resources/blog/verifiable-ai-onchain-trust-layer](https://everstake.one/resources/blog/verifiable-ai-onchain-trust-layer) (Accessed: 23 June 2026). ## 新闻与网络来源（编号供事实核查） 正文把具体发现归于某项具名研究时，其一手来源列于上方「参考文献」。以下条目记录本文采用的二手报道，以及各自支持的论点。 - vFunction (2026). ‘Distributed monolith architecture.’ Operational complexity of microservices without architectural independence; logical coupling; synchronised deployments. [vfunction.com](https://vfunction.com) - Pietschsoft / C. Pietschmann (2026). ‘Disposable software is the future.’ Distributed-monolith failure modes; interfaces needing ownership and versioned contracts; change-flow as the real measure of architecture. [pietschsoft.com](https://pietschsoft.com) - XYZBytes (2025). ‘From microservices hell to monolith heaven: the great architecture reversal of 2025.’ Consolidation back toward (modular) monoliths; reported cost and deploy-time reductions. [xyzbytes.com](https://xyzbytes.com) - SoftwareSeni (2026). ‘From microservices consolidation to modular monoliths.’ Modular monolith as enforced internal boundaries; CNCF 2024 Cloud Native Survey consolidation signal. [softwareseni.com](https://softwareseni.com) - Engenia Technologies (2026). ‘AI software modernization: the 2026 enterprise guide.’ LLMs extracting business rules/intent into human-readable requirements; engineers shifting to constraints and architectural trade-offs; ~75% of enterprises on legacy systems. [engeniatech.com](https://engeniatech.com) - Wishtree (2026). ‘Microservices architecture for enterprise.’ Clean versioned APIs as agent-callable skills; agentic orchestration of services; distributed-monolith risk without disciplined design. [wishtreetech.com](https://wishtreetech.com) - Blockchain Council (2026). ‘Verifiable AI inference using blockchain.’ Off-chain inference plus on-chain ZK proof; chain as accountability/provenance layer; ‘prove how the output was produced.’ [blockchain-council.org](https://www.blockchain-council.org) - Chainlink (2026). ‘Verifiable AI vs trusted AI.’ Delegated-trust vs cryptographic-trust; ‘verification over trust’; suitability for high-stakes financial environments. [chain.link](https://chain.link) - Everstake (2026). ‘Blockchain and verifiable AI.’ Proving cost/latency limits; small/mid feasible, large partial, training aspirational; high-stakes-low-volume-first adoption across 2026–2028. [everstake.one](https://everstake.one) - Phemex Academy (2026). ‘What is verifiable AI?’ TEEs, ZK proofs, provenance standards (C2PA); why smart contracts cannot rely on opaque off-chain AI without a trust-minimising layer. [phemex.com](https://phemex.com) - INCOSE / Wiley (2026). ‘MBSE Co-Pilot: a research roadmap.’ AI-driven model-based systems engineering to lower the adoption barrier for digital engineering. [incose.onlinelibrary.wiley.com](https://incose.onlinelibrary.wiley.com) - CNCF (2025). 2024 Cloud Native Survey. 689 respondents (±3.8% at 95% confidence); 42% of microservices adopters consolidating to larger units; service-mesh adoption 18%→8%; cloud-native adoption ~89%. Reported via SoftwareSeni / byteiota. [cncf.io](https://www.cncf.io) - RISC Zero (2026). zkVM documentation and overview. General-purpose zkVM; Rust → RISC-V; STARK receipt with on-chain SNARK verifier; Bonsai proving service; Q1 2026 latency/throughput figures. (Also: Eco / degen0x explainers on RISC Zero, Lagrange, Axiom.) [risczero.com](https://risczero.com) - ICME Labs (2026). ‘The definitive guide to zkML.’ Compute-expensive / verification-cheap asymmetry; Giza LuminAIR verifiable DeFi agents; loan-decision proof example; overhead trajectory (1,000,000×→10,000×); zkPyTorch and Lagrange DeepProve. [blog.icme.io](https://blog.icme.io) 架构与平台 ## 继续浏览此集群 对长期交付产生影响的框架、平台与系统设计选择。 [从核心文章开始**智慧城市软件架构：MQTT、LoRaWAN、Kubernetes 与 Terraform**](/zh/blog/smart-city-architecture-best-practices-2026/) - [Cursor Origin 与 GitHub 对比：团队该迁移吗？](/zh/blog/cursor-origin-vs-github-code-hosting/) - [MoneyPrinterTurbo 评测 2026：免费 AI 视频与真实成本](/zh/blog/moneyprinterturbo-review-2026/) - [Odoo API 集成：决定架构的五条限制](/zh/blog/odoo-erp-api-integration-limits-2026/) - [食品零售 AI：MPREIS 机会地图](/zh/blog/mpreis-ai-grocery-retail-opportunity-map/) - [有状态 LLM 平台的生产架构](/zh/blog/stateful-llm-platform-production-architecture/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) ![Alexandre Kotcherguine](/img/team/alexandre-kotcherguine.jpeg) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) Alexandre Kotcherguine [Kevin Riedl](/zh/team/kevin-riedl/) 14 min 阅读 · 2026 年 7 月 14 日 [**下一篇**](/zh/blog/the-factory-returns/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/future-of-enterprise-software/#webpage", "@type": "WebPage", "dateModified": "2026-07-14", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-14", "url": "https://wavect.io/zh/blog/future-of-enterprise-software/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "当团队把整个系统，而不是单个服务或 SaaS 工具，作为设计对象时，企业软件才能重新获得一致性。AI 可以降低持续维护规格、接口、测试和架构检查的成本。去中心化验证能够加强少数高风险保证，但不能取代合同、审计或可靠的内部控制。只有当可验证性带来的价值高于新增复杂度时，才值得采用这种机制。", "articleBody": " 博客概览/交付与 QA/架构与平台 要点速览 当团队把整个系统，而不是单个服务或 SaaS 工具，作为设计对象时，企业软件才能重新获得一致性。AI 可以降低持续维护规格、接口、测试和架构检查的成本。去中心化验证能够加强少数高风险保证，但不能取代合同、审计或可靠的内部控制。只有当可验证性带来的价值高于新增复杂度时，才值得采用这种机制。 企业软件的未来 AI 如何让系统工程纪律回归，而去中心化如何让它变得可证明 Polity 发布 | 2026 年 7 月 作者：Alexandre Kotcherguine，Polity Vision Officer & Investor； Kevin Riedl，Wavect GmbH Managing Partner 本文讨论企业软件架构与工程方法论，依据公开资料，包括同行评审与预印本研究、行业调查，以及截至 2026 年年中的供应商和从业者报道。文中讨论的若干技术仍处于成熟曲线的早期阶段，相关论断也据此加以说明。来自快速变化领域的数字只是时点快照，可能被修订。本文不构成任何专业、法律或投资建议。 执行摘要 二十年来，企业软件一直通过拆分来追求敏捷。单体被分解为微服务；套件被拆散成蔓生的 SaaS；交付不断加速，直到把一切维系在一起的架构悄然消解。承诺中的敏捷往往以它的反面到来，分布式单体：它保留了旧世界的全部耦合，却失去了旧世界的整体一致性；没有人拥有全局，每一次变更都变成协调练习。在碎片化中失去的是系统工程：把整体视为设计对象的纪律，以明确的需求、受治理的接口、架构完整性，以及针对意图的验证为基础。本文认为，下一阶段将同时在两个方向上逆转这一趋势。首先，AI 让系统工程方法再次能够以可负担的成本规模化。它把受治理、规格说明优先的「软件工厂」从代码扩展到全系统架构，使意图能够再次被捕获、建模与执行，而不是任其侵蚀。其次，也是影响更深的一点，去中心化会加固结果：它把系统的保证从受信任转向可验证，从记录在纸面上、由组织信誉背书的合约，转向由密码学证明、链上证明和分布式控制执行的合约，任何单一方都无法悄然覆盖。工厂构建系统；链证明它的行为。本文也完整陈述坦率的限制：可验证计算仍远比执行昂贵；它首先出现在高风险、低流量场景，而不会同时遍及所有地方；对企业内部的大部分区域而言，现有的制度性信任仍是正确工具。本文的主张并不是密码学证明取代审计和合同，而是它把保障延伸到那些工具无法跨越的边界之外。但方向已经清楚，而且落在熟悉的领域：Polity 所从事的受监管链上金融，正是可证明架构最先被要求、也最早被采用的地方。 碎片化时代 2010 年代占主导地位的企业架构运动有着清晰且大体合理的动机。单体已经长成「大泥球」；高度耦合、难以更改、部署缓慢；而微服务承诺提供出口：围绕业务能力分解应用，让每个服务独立部署，让团队并行推进。对许多组织来说，它起初确实有效。但这一模式被广泛当作默认答案，而不是经过权衡的取舍；整个行业反复出现一种具有代表性的失败模式，从业者最终为它起了一个精确的名字。按照一个被广泛引用的描述，「分布式单体」拥有微服务的运维复杂度，却没有架构独立性：服务在物理上分离、在逻辑上耦合；彼此依赖数据库 schema；要求同步部署；通过很长的调用链相互调用；因此一个服务的变化会破坏另外三个，每次发布都成为协调练习 (1)。组织得到了更多 repository、更多 pipeline、更多日志、更多故障模式和更多治理开销；却没有得到更快行动的能力。 到本十年中期，这种纠偏已经出现在数据中，而不只是在行业媒体里。Cloud Native Computing Foundation 的 2024 Cloud Native Survey 调查了 689 位技术决策者，发现已经采用微服务的组织中有 42% 正在把服务重新整合为更大的可部署单元，而 service mesh；让微服务能够在规模化环境中被管理的基础设施；采用率从 18% 降至 8% (2)。这并不是对分布式架构的全面否定；cloud-native 的总体采用率仍接近 90%。它是在纠正过早采用，整合中的团队转向模块化单体；在单一部署中保持严格的内部边界；并报告成本和部署时间显著下降。Amazon 的 Prime Video 团队早已给出范例：它把一条微服务监控 pipeline 收拢回单体，为某项监控 workload 将基础设施成本降低约 90%；该公司的 chief technology officer 直接点明其中教训：构建可演进系统是一种策略，不是一种宗教。结论并不是分布式是错的，而是它是目的地，不是起点；只有维持其所要求纪律的团队，才能获得它的收益：明确归属的接口、版本化的合约、得到执行的边界。那句限定；只有维持纪律的团队；就是整个故事。碎片化失败，并不是因为分解本身是坏主意；它失败，是因为没有系统工程的分解不过是多加了几个步骤的熵。 失去的东西：系统工程 系统工程是被碎片化挤走的、更古老的纪律。它把系统整体，而不是一组各自独立优化的部件，视为首要设计对象。它的工具包括：在构建之前捕获意图的需求、治理部件交互方式的接口合约、使整体变得可读的架构模型，以及把构建出的系统与规格说明进行核验的验证过程。这些实践并不光鲜，而碎片化时代的 move-fast 文化把它们视为官僚阻力，要以速度之名摆脱。这里的讽刺，与企业 Agile 更早的历史一样：放弃纪律并没有带来持久的速度；它制造了越来越缓慢、越来越脆弱的系统，原因正是再没有人照看整体。 这项纪律之所以被放弃，而不仅仅是被忽视，是有原因的：以现代软件的规模与节奏，手工进行系统工程确实无法负担。持续维护一个大型系统准确、最新的模型，包括组件、依赖、合约与约束，是一项劳动密集型任务，它过时的速度比人类维护它的速度更快。基于模型的系统工程，是构建并推理这类模型的正式学科，长期以来一直被认为很强大，同时又被认为过于沉重，绝大多数组织无法持续采用。全系统视角是一种奢侈品。于是团队不再购买它，架构则退化成运行中的服务碰巧呈现的样子。 为什么 AI 让这项纪律回归 本系列上一篇文章的论点是：AI 并不废除工程纪律，而是把它沿着技术栈向上迁移，从敲击键盘迁移到规格说明，而且受治理的「软件工厂」只有在手艺被嵌入 pipeline、而不是被排除时才会真正运转 (3)。再向上扩展一层，同样的逻辑也适用于架构。系统工程之所以负担不起，在于构建与维护全系统模型、并让意图、规格说明和实现保持一致所需的人力成本。AI 恰好压低了这种成本。大型模型如今可以解析庞大的 legacy codebase，把其中隐含的业务规则和意图提取成人类可读的需求，让现代化从一场高风险的打捞行动，变成可以处理的设计问题。系统工程社区也已经开始为基于模型的系统工程本身构建 AI copilot，以降低过去使这项纪律遥不可及的门槛 (4)。 结果是，全系统视角不再是一种奢侈品。一份持续演进、版本化的规格说明，正是约束 agentic code factory 的同一项工件，成为架构的 source of truth，由不知疲倦的智能体不断与运行中的系统进行核对。接口可以从合约生成，并自动对照合约进行检查；架构漂移可以在发生时被发现，而不是在事故中才被发现；模型能够保持最新，因为维护它不再主要是人类工作。这就是系统工程的回归，不是对 waterfall 的怀旧，而是一项终于在经济上可行的纪律。企业系统可以再次作为整体被设计，因为现在又能以可接受的成本把整体保持在视野之中。 只有 AI 的边界：受信任不等于已证明 但仅凭 AI 恢复的系统工程，会以一种更微妙的形式重新引入它所解决的问题。由智能体核对的规格说明仍是一份文档；由 pipeline 执行的接口合约仍由控制 pipeline 的人执行；由系统写入的审计日志，其可信程度仍取决于能够改写它的一方。整个装置都建立在委托信任上，用户相信部署组织正确地完成了规格说明、诚实地执行了验证，并且没有篡改记录。在单个企业内部，这也许可以接受。但跨越定义现代系统的边界，公司之间、机构与监管者之间、网络与参与者之间，这恰好是无法成立的假设。而在 agentic 时代，风险进一步上升：当代码乃至架构变更的生成速度超过任何人独立审查的速度，「相信我们，系统会按照规格说明运行」就成了一项任何交易对手都不应凭信念接受的主张。 近期文献把这里的区别清晰地概括为 trusted 与 verifiable。受信任系统依靠中心化声誉、制度性审计与内部治理：可靠性由法律协议和企业监督保障，内部计算则隐藏在供应商关于其正确运行的保证背后。可验证系统遵循相反原则，以验证代替信任，用任何人都能检查的保证，取代对中心化一方的盲目信任。它对系统提出的是另一种主张：不是「我们证明它运行正确」，而是「这是它确实如此运行的证明」(5)。恢复系统工程会告诉你架构已经被规格化；但仅凭这一点，并不能告诉规格制定组织之外的任何人，这套架构是真实的。 去中心化如何加固它 去中心化正是在这里发挥作用，而且它在本文论证中的首要角色不是拓扑性的，而是证据性的。去中心化底层为企业系统提供的最重要能力，不是让系统运行在许多地方，而是让系统的保证可以被证明，而不只是被宣称。密码学验证把架构合约从纸面政策转化为可执行、可独立检查的事实。一项计算可以为了速度在链下运行，同时附带一份紧凑证明，在链上以较低成本验证它确实按照已承诺的模型或规格说明正确执行，而无须暴露底层数据或逻辑。2026 年的行业实践越来越把链视为 AI 驱动系统的问责与来源层：一个用于模型证明、决策记录和审计日志的共享底层，任何人都无法悄然改写。正如一项调查所说，问题从系统能否产生输出，转变为你能否证明输出如何产生、谁对此负责，以及它能否经受审查。 使这一点变得可行的是一种不对称：计算可以昂贵，而验证可以便宜。模型可以在 cluster 上运行一个小时，然后返回一份密码学收据，交易对手只需数毫秒就能检查，无需重新运行计算，也无需看到输入，便能确认究竟计算了什么。基础设施已经不再是假设，其中三类已经投入生产。通用零知识虚拟机，例如 RISC Zero，把普通程序编译到一个得到证明的指令集，并生成任何一方都能针对公链合约验证的收据；Lagrange 和 Axiom 等协处理器证明链上状态的事实；而面向 machine learning 的专用 framework，例如 Starknet 上的 Giza，使自主智能体能够证明它的每项决定确实来自它所承诺的模型，同时权重与策略保持私密。让风险变得具体的是受监管 use case：借贷决定不再是「相信银行的风险模型」，而可以附带一份证明，说明这个特定模型使用这些冻结参数评估了这位申请人的数据。关于系统的主张不再取决于运营方的信誉，而成为监管者、交易对手或 smart contract 能自行检查的事实。 还有两个方向加强了证据性这一点。从拓扑上说，把系统分布在独立节点之间，可以消除单点故障，更重要的是消除单点控制，一方能够悄然改变行为、压下记录或覆盖合约的位置。从制度构造上说，去中心化治理为工厂本身提供了一层权威：规格说明如何修改、智能体如何授权、变更如何获准，都可以由明确、分布式而且本身可审计的规则决定，而不是掌握在持有密钥的人手中。三个方向合在一起，把恢复后的架构从一项工程良好的私有主张，转变为其完整性能够从外部被读取和执行的系统。以这种方式加固的工厂，不只是把系统构建得好；它让系统能持续向那些从未被要求信任它的各方，证明自己确实如其所称。 反对意见：成熟度，以及是否真的需要 对此最有力的反对意见不是哲学性的，而是实践性的；它值得以最强形式被陈述，因为就今天而言它是正确的。可验证计算很昂贵。按照目前的估计，为一项计算生成密码学证明，要比执行计算本身沉重若干个数量级，对大型模型而言，据报告证明速度可能比普通 inference 慢数千倍。该领域坦率的评估明确指出：证明小型到中型模型的 inference 是可行的；大型模型的 inference 只能部", "articleSection": "客座文章", "author": [ { "@type": "Person", "name": "Alexandre Kotcherguine" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" } ], "dateModified": "2026-07-14", "datePublished": "2026-07-14", "description": "当团队把整个系统，而不是单个服务或 SaaS 工具，作为设计对象时，企业软件才能重新获得一致性。AI 可以降低持续维护规格、接口、测试和架构检查的成本。去中心化验证能够加强少数高风险保证，但不能取代合同、审计或可靠的内部控制。只有当可验证性带来的价值高于新增复杂度时，才值得采用这种机制。", "headline": "企业软件的未来", "image": "https://wavect.io/img/blog/headers/header_future-of-enterprise-software.svg", "inLanguage": "zh", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/future-of-enterprise-software/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/future-of-enterprise-software/", "wordCount": 823 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/delivery-qa/", "name": "交付与 QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/architecture-platforms/", "name": "架构与平台", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/future-of-enterprise-software/", "name": "企业软件的未来：AI、系统工程与可验证性 | ", "position": 5 } ] } ```