深度洞察（精选转摘）丨当“系统”开始失去边界：从固定架构到契约组织化架构

最近 DeepSeek Harness 提出的“一切皆插件”，是一个很值得我们关注的信号。插件当然不是什么新概念。从操作系统、浏览器到 IDE，再到各种企业级软件，插件架构已经存在了几十年。真正值得注意的不是“插件”是否创新，或者是否会流行，而是今天我们正在把什么东西变成插件：模型可以替换，工具可以替换，Skill 可以组合，Memory、Sandbox、Storage、Session 乃至 Agent 的部分运行机制，都越来越倾向于从一个完整程序中剥离出来，成为独立的能力单元。

如果把时间拉长一些看，这并不是一个孤立的技术潮流。从软件四十年发展看回去，前二十年，我们从简单应用走向了巨石系统（Monolith）。但是后二十多年，软件工程似乎一直在做同一件事情：不断把原本高度集中而庞大的，属于“系统内部”的东西，从系统中拆出来。我们从 Monolith 走向 SOA，从 SOA 走向 Microservices，从固定服务器走向 Cloud Native、Container 和 Serverless；我们把数据库变成服务，把身份变成服务，把消息变成服务，把计算变成服务。到了今天的 Agentic 时代，我们又开始把模型、工具、知识、记忆和执行环境拆成可以动态组合的能力。

这让我开始重新思考一个看起来很基础的问题：我们今天所说的“系统”，究竟是什么？

过去，这个问题其实很好回答。一个软件系统通常有明确的边界。它有自己的代码、数据库、服务、用户体系、部署环境和权限体系。即使一个大型互联网应用已经分布在数千台服务器、数百个微服务和多个数据中心之上，我们仍然能够画出一个框，然后说：这个框里面，是我们的系统（System）。

这个框背后实际上隐藏着几个长期重合的边界：Ownership Boundary、Deployment Boundary、Trust Boundary、Governance Boundary 和 System Boundary。但是，其本质是在为某个主体持续加固边界。系统属于某个组织，运行在这个组织能够控制的基础设施上，遵守这个组织制定的规则，也由这个组织定义什么属于系统、什么属于外部世界。

因此，传统架构设计在很大程度上是在做一件事情：

先定义结构，再定义系统。（Define the structure, then build the system）

但今天的问题是，这个“框”正在越来越难画。

01

软件工程其实早已开始主动拆解结构

大型集中式系统发展到一定规模后，复杂度会产生一种很有意思的反作用：继续强化中心控制，反而可能产生更多协调成本。一个巨型系统拥有越来越多模块、越来越复杂的依赖、越来越漫长的发布周期以及越来越庞大的组织协作关系。最终，工程团队开始主动寻找边界，把不需要紧密耦合的部分拆出去。SOA 是一次这样的尝试，Microservices 又向前走了一步。Cloud Native 则进一步把服务的生命周期、部署位置和基础设施解耦。从这个角度看，Microservices 的意义不仅仅是“把大程序拆成小程序”。它实际上开始改变系统内部能力的存在方式。一个 Capability 不再必须和另一个 Capability 编译在同一个程序里，不需要运行在同一台服务器上，甚至不需要共享同一种语言和运行环境。只要双方遵守接口契约，它们就可以协作。但是 Microservices 仍然保留了一个重要前提：这些服务通常仍然属于同一个制度控制域。他是一个很好的尝试，结果是系统突破了原来的协作瓶颈，让它的体量变得更加强大（庞大）。服务看似被拆开了，组织并没有拆开。为了做好对其所有组件的管理，治理开销越来越大，投入也越来越大，治理成本甚至超过了对 microservice 开发的投入开销。

但最近5年，事情开始逐渐发生趋势性变化。

02

当网络本身开始改变“模块”的含义

在早期软件工程中，本地调用和远程调用几乎属于两个不同世界。访问一个内存中的函数，与通过网络访问另一台机器上的服务，在延迟、可靠性、编程模型和失败语义上存在巨大差异。这个差异当然不会消失。分布式系统中的网络分区、延迟、重试、一致性和部分失败，也不会因为带宽增加而突然不存在。但从更高层的能力组织角度来看，本地能力和远程能力之间的距离确实在不断缩小。高速网络、成熟 RPC、API 基础设施、CDN、云计算、边缘计算、服务发现和标准化序列化协议，使开发者越来越习惯把“远程能力”当成应用的一部分。

过去我们写：Application = Module A + Module B + Module C

后来逐渐变成：Application = Service A + Service B + Service C

而今天，一个应用越来越可能调用模型服务、身份服务、数据库服务、支付服务、搜索服务、第三方 API 和各种 Agent Tool。这些能力甚至根本不属于应用的开发者。于是一个过去不太需要回答的问题出现了：

如果一个 Capability 不属于我、不运行在我的服务器上、甚至由另一个独立组织治理，但我的应用长期依赖它完成核心功能——它究竟算不算这个 System 的一部分？

一旦提出这个问题，传统 System Boundary 就已经开始松动。过去我们倾向于用“所有权”判断系统边界，未来我们可能越来越需要用“关系”判断系统边界。而 LLM 和 Agent 的出现，又把这个问题向前推了一大步。过去网络中的 Service，本质上仍然是一个相对被动的 Endpoint。A 调用 B，是因为 A 的程序逻辑事先规定了应该调用 B。即使存在服务发现和动态路由，真正的行为逻辑仍然主要由系统设计者预先确定。

而 Agent 的出现，正在让这些原来坚固的设计基石开始松动。

一个具备模型、Context、Memory、Tools 和执行能力的 Agent，可以理解目标、判断当前环境、寻找可用能力、选择工具、执行任务，并根据执行结果决定下一步行动。这意味着网络中的一个节点，第一次有可能从传统意义上的“被动组件”（Passive Component），逐渐接近一个“自主能力主体”（Autonomous Capability Entity）。

变化并不只是「A 调用 B」而可能变成：A 发现 B → 理解和发现 B → 选择 B → 委派任务 给 B → 评估结果 → 动态重组然后继续行动

如果未来 Agent 与 Agent 之间进一步形成标准化的发现、身份、权限、协商和协作机制，那么这种关系就更加值得关注。因为软件系统内部发生的事情已经越来越不像“组件调用”，而开始接近：

自主主体间协同

当 Node 从组件逐渐变成 Actor，我们对“架构”的理解，也必然开始接近于“组织”。这可能是 Agent 对软件架构最深刻的长期影响之一。今天行业大量注意力仍然集中在模型能力、Token 成本、Context Window、Tool Calling 和 Agent Framework 上，但从更长时间尺度看，真正重要的变化可能是：软件系统的基本组成单元正在获得越来越强的自主性。而一个由自主主体组成的系统，与一个由被动组件组成的系统，在组织方式上不会完全相同。这也是为什么我越来越倾向于认为，未来某些软件系统的核心问题将不再只是结构（Structure），而是组织（Organization）。

传统架构可以粗略表达为：架构 → 组件 → 功能 → 能力（Architecture → Components → Functions → Capability）：架构决定组件的位置，组件实现功能，功能共同形成系统能力。

但另一种正在出现的可能性是：契约 → 关系 → 组织 → 能力（Contract → Relationship → Organization → Capability）

我们首先定义参与者之间能够以什么方式建立关系，再让这些关系形成一个可以工作的组织结构。这里的契约（Contract）并不特指区块链智能合约。它是一个更广义的概念，包括 Protocol、Interface、Identity、Permission、Capability Description、Service Agreement、Governance Rule，以及未来越来越多可以被机器理解和执行的关系规则。这样理解以后，“系统”的定义就会发生一个非常重要的变化。我把这种变化概括为：

系统的一致性基础，可能从中心控制下预先定义、紧密耦合且相对固化的结构基座，逐渐转变为参与者共同遵守的关系契约；系统也因此可能从“预先设计并固化结构”，走向“在共同契约约束下持续组织、动态形成和演化结构”。

换句话说：

结构可变，契约不变。（Structure becomes variable. Contract becomes invariant）

这里说的并不是系统从“有结构”变成“没有结构”。恰恰相反，它仍然需要组织。真正的变化是：固化结构向动态组织化结构演变（Fixed Structure → Organized Dynamic Structure）。结构不再必须全部由一个架构师事先规定。节点可以加入，能力可以退出，关系可以重新组合，局部组织可以产生甚至消失。只要参与者仍然遵守足以维持系统一致性的基本契约，这个 System 就可以继续存在。从这个角度看，架构师的工作也可能发生变化。过去我们设计 Structure。未来某些场景中，我们可能需要更多地设计出“能够产生结构的规则”（the rules from which structures can emerge）。

03

为什么这种变化现在值得讨论？

一些长期独立发展的技术，正在第一次在 Agentic 时代汇合。第一股力量来自软件自身的持续解耦。大型集中式系统正在因为复杂度而主动寻找边界。从 Monolith 到 Microservices，本质上都是在不断回答：什么东西真的必须属于系统内部？第二股力量来自网络。随着远程能力调用成本下降，Capability 不再必须和 Application 共处于一个部署边界。我们已经完成了计算和部署层面的第一次解耦，下一步值得关注的可能是“能力所有权”与“系统所有权”的解耦。第三股力量则来自 Agent。过去被拆出去的是被动服务，而现在被拆出去的能力开始拥有越来越强的自主判断和执行能力。三条路径汇合之后，我们得到的就不再只是一个更加模块化的软件系统，而可能是：“软件解耦 + 能力网络化 + 自主智能体 → 动态组织的能力网络”。而到了这里，“网络”开始不只是系统之间传输数据的基础设施。网络本身可能开始承载系统结构。我把这种可能性称为：

Network as a System.

它不是说“所有网络都是系统”，更不是说未来所有软件都应该去中心化。它在表达另一件事情：

一个 System 可能不再必须对应一个固定的部署实例、代码仓库或者组织边界，而可以由一组具有自主性的能力节点，以及这些节点之间持续有效的关系共同构成。

换句话说，系统开始存在于关系之中！

04

这会解决什么问题？

我认为最值得关注的是跨 Ownership Boundary 的系统协作。今天的软件工程已经非常擅长构建一个企业内部的大型系统。但如果企业 A、个人开发者 B、智能体 C 和组织 D 希望长期共同组成一个数字业务系统，我们通常仍然需要一个中心平台。平台建立统一账户、统一 API、统一权限、统一规则和统一治理，然后把所有参与者吸收到平台内部。这种模式非常成功，也会长期存在。但它并不是唯一可能的组织方式。如果身份可以独立验证，Capability 可以标准描述，关系可以机器化建立，权限可以跨主体表达，可信状态可以共享，参与者之间又能够建立可执行的契约，那么另一种结构就可能出现：

不是所有参与者都连接到 Platform，而是参与者直接建立关系。此时：

System 将确实存在于 Relationships 之中，而不一定存在于某一个 Platform 里面。

从过去很长一段时间来看，企业为什么存在？平台为什么如此强大？一个重要原因就是中心协调能够降低交易成本。比如：统一身份降低验证成本，统一组织降低沟通成本，管理层级降低决策成本，平台规则降低谈判成本，统一支付和结算降低交易成本。这个思路的推演结果是，如果以网络组织形态的彼此协作的成熟度到可以充分降低组织的交易成本，放大组织间执行效率的时候，Network as a System将成为可能。问题是：“协议协商”（Protocol Coordination）在什么条件下能够比“中心协商”（Central Coordination）更有效率？

如果协议化身份降低了验证成本，标准化能力描述降低了搜索成本，机器可读契约降低了协商成本，共享可信状态降低了监督成本，而 Agent 又进一步降低了发现、匹配和执行这些关系的人力成本，那么过去必须依靠企业或者平台内部化的一部分协调活动，就有可能重新回到网络。这时候一个非常重要的边界开始发生变化：系统边界（System Boundary）不再必须与企业边界重合（Firm Boundary）。这个逻辑应该不难理解：过去，一个系统通常属于一家企业。未来，一个系统可能跨越多家企业、个人、机器和 Agent 存在。它既不完全是 Firm，也不完全是 Market，更不一定是今天意义上的 Platform。它可能是一种建立在持续协议关系上的数字组织。从组织经济学的角度看，这也许比“去中心化应用”本身更值得研究。因为它真正发生变化的不是数据放在哪里，而是：经济主体之间的协调机制能否被软件重新表达？

传统企业经过多年运行，会积累大量组织资本：流程、制度、知识、信誉、合同模板、管理经验和协作习惯。这些东西使一群人能够以远低于临时市场交易的成本长期合作。如果越来越多的身份规则、能力标准、权利表达、协作方式和治理程序能够沉淀到开放协议中，那么未来网络可能也会积累一种类似的协调能力。我暂且把它称为：

协议资本 - Protocol Capital

协议资本这并不是一个成熟的经济学术语，我临时做了命名，是否值得更深入研究，这是经济学范畴的课题。但它提供了一个值得观察的角度：一个数字网络的价值，未来也许不只取决于它拥有多少节点，而取决于它能让多少原本互不隶属的主体，以多低的成本形成有效关系。这时候衡量网络的指标可能就不仅是 TPS、Latency 或 Node Count，还包括关系建立成本、契约可组合性、协调效率与组织能力。

假设：关系建立成本下降 → 契约可组合性提高 → 协调效率提高 → 组织能力扩大。

那么由“网络”进化为“组织化系统”将会有充足的理由。

05

对 Network as a System 的实践探索

过去几年，我与好友兼同事德信一直在探索能支撑这类新组织范式的技术架构。在一个 DX Mesh 的项目中做过多种设计尝试。走过多次弯路，DX Mesh 项目最初是一项关于去中心化应用网络的工程探索。但随着设计深入，我们逐渐发现，真正困难的并不是“怎样把一个传统应用放到区块链上”，而是另一个更加基础的问题：

如果多个独立节点本来就拥有自己的身份、能力、生命周期和治理主体，我们应该怎样让它们在不被重新吸收到一个中心平台的情况下，仍然彼此间能形成一个可以工作的系统（System）？

在很长一段时间里，这都是超出我们设计想象的远方。Network as a System 它很难被工程化落地，还有一个根本的原因，就是我们很难从根深蒂固的中心化系统设计中忘掉这些技术的条条框框，以至于做着做着就回到了中心化的要件设计之中，最终系统变得复杂而不稳定。但，后来我们明白了：

Network as a system，并不是要去设计System，而是要去设计Meta Protocol（宏观法则）。当宏观法则建立起来了，个体间自然会趋于形成组织。所以，实现Network as a System 设计哲学的根本，在于对现有的系统设计做减法。同时，要定义宏观法则，而不是去设计系统。

因此，我们逐渐把 DX Mesh 理解（设计收缩）为对宏观法则层（Meta-Protocol Layer）的探索。设计一个“动态的组织化系统”，它不是要成为所有上层组织的最高治理者，也不应该规定参与者必须形成什么商业模式。它更希望提供一组基础规则，使节点能够识别彼此、描述能力、建立通信、表达关系、获得可信状态，然后让不同的组织结构在这些基础能力之上形成。从这个意义上说，我越来越不愿意简单地把 DX Mesh 项目本身称为“这个系统”。因为 DX Mesh 项目本身就不定义系统是什么样子，但它正在为 Network as a System 制定了一套宏观法则（Meta Protocol）。在这套规范（Meta Protocol）之下，System 在 Network 中将形态各异。因此，DX Mesh项目更接近是一个：

一个用于形成系统的基础架构（A system for forming systems）

或者更准确地说：

一个可供不同系统形成并持续演化的网络基础架构（A network substrate on which different systems can form and evolve）

这也是我所谓 Network as a System 的工程出发点。

06

探索新系统结构

软件工程过去几十年的核心任务，是不断寻找更好的方式去构造系统。我们改进编程语言，改进数据库，改进网络，改进服务架构，改进部署方式，再改进云基础设施。但随着系统被持续解耦，Capability 开始脱离本地，Agent 开始成为具有自主能力的节点，我们也许正在接近另一个问题：未来的 System 是否仍然必须首先被“构造”？还是说，至少有一部分系统会越来越像现实世界中的组织：参与者拥有独立身份和能力，在共同规则下建立关系，通过关系形成结构，并随着环境变化不断重新组织？如果后一种可能性成立，那么软件架构将出现一个很有意思的变化。我们过去主要设计的是：System Structure。未来可能还需要设计：System Formation。

也就是说，真正需要被架构师重新设计的，也许不再只是一个 System 应该长什么样。而是一个 System，在什么规则下得以形成。

版权声明: 本文为 InfoQ 作者【黄嵩】的原创文章。

原文链接:【https://xie.infoq.cn/article/15d4303a3459677e0f48c4fc8】。

本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。