企业软件的未来

AI 如何辅助系统工程，以及密码学如何验证选定声明

Polity 发布 | 2026 年 7 月
作者：Alexandre Kotcherguine，Polity Vision Officer & Investor；
Kevin Riedl，Wavect GmbH Managing Partner

本文已于 2026 年 9 月 2 日根据公开研究、官方文档、行业调查和从业者资料完成全面复核。若干技术仍处于早期阶段。供应商的性能与采用率说法均明确标示；数字只是时点快照，不是保证。本文不构成专业、法律或投资建议。

执行摘要

企业软件在拆分过程中可能失去整体一致性，并形成分布式单体。AI 辅助分析可以减少维护全系统视角的部分工作，但当前 MBSE 研究仍要求人工监督，也没有证明企业规模的自主系统建模已经实现。密码学证明和防篡改账本可以让选定的计算与记录接受独立检查，却不能证明整套架构、输入真实性、模型适用性或合规性。它们可以在特定跨组织边界补充审计和合同，但经济性与采用顺序取决于具体 workload。

碎片化时代

2010 年代占主导地位的企业架构运动有着清晰且大体合理的动机。单体已经长成「大泥球」；高度耦合、难以更改、部署缓慢；而微服务承诺提供出口：围绕业务能力分解应用，让每个服务独立部署，让团队并行推进。对许多组织来说，它起初确实有效。但这一模式被广泛当作默认答案，而不是经过权衡的取舍；整个行业反复出现一种具有代表性的失败模式，从业者最终为它起了一个精确的名字。按照一个被广泛引用的描述，「分布式单体」拥有微服务的运维复杂度，却没有架构独立性：服务在物理上分离、在逻辑上耦合；彼此依赖数据库 schema；要求同步部署；通过很长的调用链相互调用；因此一个服务的变化会破坏另外三个，每次发布都成为协调练习 (1)。组织得到了更多 repository、更多 pipeline、更多日志、更多故障模式和更多治理开销；却没有得到更快行动的能力。

CNCF 官方调查并不支持整个行业从微服务退回单体的说法。其 2024 年结果显示 cloud-native 采用率为 89%；service mesh 采用率因运维复杂性问题，从 2023 年的 50% 降至 2024 年的 42% (2)。这说明 cloud-native 持续使用的同时出现选择性简化，而不是本文此前所称 42% 的微服务采用者正在整合，或采用率从 18% 降至 8%。Prime Video 曾报告，单个监控 workload 在合并为单体后，基础设施成本降低 90%。Werner Vogels 据此强调，不存在适合所有场景的架构，构建可演进系统是一种策略，而不是宗教 (3)。

失去的东西：系统工程

系统工程是被碎片化挤走的、更古老的纪律。它把系统整体，而不是一组各自独立优化的部件，视为首要设计对象。它的工具包括：在构建之前捕获意图的需求、治理部件交互方式的接口合约、使整体变得可读的架构模型，以及把构建出的系统与规格说明进行核验的验证过程。这些实践并不光鲜，而碎片化时代的 move-fast 文化把它们视为官僚阻力，要以速度之名摆脱。这里的讽刺，与企业 Agile 更早的历史一样：放弃纪律并没有带来持久的速度；它制造了越来越缓慢、越来越脆弱的系统，原因正是再没有人照看整体。

维护大型系统的准确模型，包括组件、依赖、合约和约束，可能需要大量工作并产生 drift。但这不能证明系统工程被普遍放弃或无法负担。2026 年一份 MBSE 研究路线图指出了实际采用障碍、基础设施成本，以及大型建模环境中完全自动化、可扩展方案的证据有限 (4)。

为什么 AI 让这项纪律回归

本系列上一篇文章认为，AI 会把部分工程工作从实现移向规格说明。模型可以辅助代码映射、摘要、可追溯性和一致性检查，却不能可靠恢复未表达的业务意图。2026 年的 MBSE Co-Pilot 论文明确是一份研究路线图：当前工具往往仍需大量人工干预，即使其最高辅助级别也把设计权保留给人类 (4)。

因此，一份持续演进、版本化并与运行系统核对的规格说明，是设计目标，而不是采用 AI 后的自动结果。智能体可以提出接口、标记疑似 drift 并更新模型草稿，负责的工程师则验证需求、上下文与安全后果。能否降低总成本取决于模型质量、tooling、复核成本和组织实践。

只有 AI 的边界：受信任不等于已证明

但仅凭 AI 恢复的系统工程，会以一种更微妙的形式重新引入它所解决的问题。由智能体核对的规格说明仍是一份文档；由 pipeline 执行的接口合约仍由控制 pipeline 的人执行；由系统写入的审计日志，其可信程度仍取决于能够改写它的一方。整个装置都建立在委托信任上，用户相信部署组织正确地完成了规格说明、诚实地执行了验证，并且没有篡改记录。在单个企业内部，这也许可以接受。但跨越定义现代系统的边界，公司之间、机构与监管者之间、网络与参与者之间，这恰好是无法成立的假设。而在 agentic 时代，风险进一步上升：当代码乃至架构变更的生成速度超过任何人独立审查的速度，「相信我们，系统会按照规格说明运行」就成了一项任何交易对手都不应凭信念接受的主张。

制度性保障与密码学验证提出的是不同类型的主张。合同、审计和治理围绕组织及其控制建立问责；密码学证明则让验证方在不完全依赖运营方声明的情况下，检查一项编码声明。但它的效力只覆盖该声明及其假设。系统工程可以让架构更明确；无论规格说明还是计算证明，都不能让整套架构变成「真实」。

去中心化如何加固它

密码学验证可以让精确定义的计算接受独立检查。如果一项声明绑定了预期程序或模型以及已承诺输入，收据可以证明编码计算产生了所称输出 (5)。只有在证明系统与声明为此设计时，zero knowledge 才能隐藏私有 witness。这不能证明输入真实、模型适当或公平，也不能证明整个业务流程合规。NIST 把 blockchain 描述为在验证、共识和治理假设下可显示篡改并抵抗篡改的账本，而不是无条件不可变或完全无须信任 (8)。

开发工具确实存在，但成熟度和范围不一。RISC Zero 文档说明了验证指定程序执行的收据 (5)。Axiom 当前提供仅限邀请的 OpenVM 托管 proving API (6)。Lagrange 已将 DeepProve 开源，并报告完整 LLM inference 证明；其性能和生产量数据来自供应商，且依赖具体 benchmark (7)。这些系统都不能证明整套企业架构。以信贷决定为例，身份、数据质量、模型治理与法律合规仍在计算证明之外。

分布式可以减少部分单点故障或单点控制，但不会自动消除它们。结果取决于节点独立性、共识、治理、密钥管理、升级权限和外部数据源。去中心化治理可以让规则更透明，同时仍可能把有效控制集中在 token 持有人、运营方、multisig 签署者或管理员手中。架构必须明确哪项保证已去中心化，哪些主体与依赖仍须信任。

反对意见：成熟度，以及是否真的需要

生成证明会增加计算与运营成本，但 overhead 会随 workload、证明系统、硬件和安全目标大幅变化。本文此前所称大型模型证明慢数千倍且只能部分证明，已不是可靠的当前概述。Lagrange 现已报告一套开源、端到端的 LLM inference 证明构造 (7)。这并不能证明任意模型的生产经济性或训练，也不能让不同供应商 benchmark 直接可比。

当独立验证的价值高于成本时，高风险、低流量场景是一种合理优先选择，但这不是已经测量或必然发生的采用顺序。受监管决策、金融结算和内容来源各有不同的延迟、隐私、法律与 threat model 要求。团队应评估确切声明、验证方、证明资源，以及证明之外的失败模式。

SOC 2 报告、可信执行环境和密码学证明回答不同问题。证明可以确认编码计算，却不能确认治理控制有效、输入收集合规、模型适用或整体 compliance。审计也不会独立重放每项计算。制度性保障仍然必要；密码学证据只有在具体 threat model 与验证方足以证明新增系统合理时，才能在边界处提供补充。

结论：为被证明而工程化

AI 辅助可以减少系统映射、规格维护和不一致检测的部分工作，同时由负责的工程师保留设计权。密码学系统可以为选定计算与记录附加可独立检查的证据，却不能让整套架构变得可证明，也不能替代对输入、治理、依赖和 compliance 的评估。

这两种方法描述的是一种设计方向，而不是已经确定的未来。系统工程提供上下文，用来决定哪项不变量值得证明；验证只为实际编码的声明提供证据。在受监管 on-chain 金融中，开发工具和试点已经存在，但法律适用性、运营控制与生产经济性仍取决于具体实现。

持久的设计问题不只是系统能多快变化，还包括另一方必须验证哪项重要声明。稳健的组织会精确定义该声明，标明剩余信任假设，并选择与风险相称的证据。

关于 Polity

本文属于 Polity 治理模型下的持续出版计划。Polity 的核心观点是，持久结果由规则、激励和制度塑造。AI 辅助系统工程与选定计算的证据相结合，在这个意义上是治理问题：每项证明都有明确范围、验证方和剩余信任假设。Polity 为受监管数字金融构建基础设施，治理 framework 旨在连接去中心化系统与机构级 compliance 要求。

关于 Wavect

Wavect GmbH 是一家奥地利软件工程公司，为初创企业、成长型企业和大型企业构建产品导向的软件，涵盖全栈开发、兼职工程与产品领导、软件质量保证，以及人工智能、区块链和零知识系统的应用工作。Wavect 曾为 Polity 项目提供软件开发与质量保证服务，共同作者 Kevin Riedl 是该公司的 Managing Partner。更多信息见 https://wavect.io。

免责声明：本文仅供信息与教育用途，不构成专业、法律、金融或工程建议，也不代表对任何方法论、产品、协议、服务或组织的背书。文中提及具名研究人员、研究、工具、标准与公司，仅用于分析与评论。所讨论的若干技术，尤其是可验证计算和模型执行的零知识证明，仍处于成熟早期，其能力与成本仍在演进；相关限制已在正文中加以说明。所有第三方来源均为参考而引用；收录并不意味着 Polity 的背书或关联。共同作者 Kevin Riedl 是 Wavect GmbH 的 Managing Partner；Wavect 为 Polity 项目提供软件开发与质量保证服务（见上文「关于 Wavect」）。为透明起见，本文披露此商业关系；它不影响分析的独立性。文中观点仅代表作者本人。

参考文献与核查说明

已于 2026 年 9 月 2 日完成全面复核。供应商的性能和采用率说法按供应商声明处理。

1. vFunction (2026), Distributed Monolith Architecture: What It Is, Why It Happens, and How to Fix It. Practitioner definition of the distributed-monolith failure mode. vfunction.com (Accessed: 2 September 2026).
2. Cloud Native Computing Foundation (2025), CNCF Research Reveals How Cloud Native Technology is Reshaping Global Business and Innovation. Official 2024 survey summary: 89% cloud-native adoption and service-mesh adoption moving from 50% in 2023 to 42% in 2024. cncf.io (Accessed: 2 September 2026).
3. Vogels, W. (2023), Monoliths are not dinosaurs. Official discussion of the Prime Video monitoring-workload case, including the reported 90% infrastructure-cost reduction and the linked archived team post. allthingsdistributed.com (Accessed: 2 September 2026).
4. Zhang, W., Cockburn, C., Henshaw, M. et al. (2026), ‘MBSE Co-Pilot: A Research Roadmap’, Systems Engineering, 29(1), 20–33. Current limitations, human oversight and the proposed assistance levels. doi.org/10.1002/sys.70011 (Accessed: 2 September 2026).
5. RISC Zero, Developer Documentation. Receipts certify that a specific program produced a specific output without revealing private inputs when the proof is configured accordingly. dev.risczero.com (Accessed: 2 September 2026).
6. Axiom, OpenVM Proving API Documentation. The current hosted proving API is invite-only. docs.axiom.xyz (Accessed: 2 September 2026).
7. Lagrange (2026), Inside DeepProve: Proving an LLM End-to-End. Official engineering update and vendor-reported end-to-end LLM-inference proof results. lagrange.dev (Accessed: 2 September 2026).
8. NIST (2018, current resource), Blockchain Technology Overview, NISTIR 8202. Blockchain as a shared, tamper-evident and tamper-resistant ledger whose guarantees depend on validation and consensus. csrc.nist.gov (Accessed: 2 September 2026).