从 Blocklet Server 到 ARC：为什么拥有比生成更难

AI 让做软件这件事变得很不一样。过去，一个人想要自己的博客、店铺，或者某个只服务于自己生活的小工具，首先想到的通常不是功能，而是要不要找开发者、怎么买服务器、以后谁来维护。现在，越来越多需求可以直接说给 Agent 听。这里的 Agent 指能理解需求、协助生成、运行或维护软件的 AI 助手。软件看上去一下子变得不那么遥远。

但软件能被生成，不等于它已经属于你。

一个应用在演示环境里跑起来很容易让人兴奋。可如果它开始承载你的数据、关系、历史和日常工作，问题才刚刚开始：数据放在哪里，谁能访问，换一台设备怎么办，服务坏了以后能不能恢复，想分享给朋友时到底是在分享一个链接，还是把自己重新绑回一个平台。真正麻烦的部分，过去一直被藏在“部署”“运维”“账户系统”这些词后面。说得直白一点，它们就是把软件放到能长期访问的地方、让它持续可用，以及管理谁能登录和使用。

这也是我们正在构建 ARC 的原因。ARC 是 Agentic Realm Computer。它不是再给 Agent 一台传统电脑，让它替用户去管 Linux、补补丁、看日志。我们想做的是另一种计算基础：用户可以借助 Agent 获得需要的软件，但身份、数据和长期控制权不必因此交给某个单一平台。

软件能被生成，不等于它已经属于你

ArcBlock 是一家从区块链、去中心化身份和应用基础设施一路走来的公司。过去一直在解决一个很实际的问题：开发和部署去中心化应用太难。Blocklet Server 和早期 Blocklet 的工作，不只是把应用部署到一个机器上，而是把身份、用户管理、域名和应用部署这些公共部分先做好，让开发者把注意力留给自己的业务。

Direction of architecture, not a claim that every layer is finished.

DID 体系、不同区块链的接入和使用、支付支持，以及 PageKit、DiscussKit 这类组件，都是那套平台的重要部分。它们让用户或开发者可以在 Web 界面上处理身份、安装和组合站点、讨论或支付相关能力，而不必每一次都从零搭建一套服务。

这些能力在 ARC 里都有对应的基础，但不会以同一种完成度或同一种模型出现。身份、现有账本和支付层能力可以延续；链侧 AFS 接入、链上结算，以及它们在 ARC 中的统一承载方式仍在建设。我们不该把它说成旧能力被清零，再用一个纯粹的未来概念替换；它们仍然是 ARC 能否有用的基线。

这个判断在当时没有错。我们过去把自己明确地看成开发者平台：只要有足够多的开发者做出足够多的应用和组件，普通用户就能安装、组合并使用它们。Blocklet Store 和一批 Kit 就是在这个判断下出现的。今天也仍然有很多开发者需要这样的工具。

后来我们不得不承认一个很实际的事实：即使组件已经有了，安装、配置、维护这些事仍把绝大多数普通用户挡在外面。软件包并不会自动变成一个人能长期拥有的应用。这也是 SaaS 能流行的原因，它把许多这类麻烦尽量替用户藏起来了。

变化在于，AI 已经把“谁能做出软件”这件事往外推了一大步。一个人不必先成为专业开发者，才有资格提出“我想要一个自己的站点”“我想收集和整理这些资料”“我想做一个只给家人用的小应用”。可就算 Agent 帮他写出了应用，如果数据、部署和后续运行仍是一团只有专业人员才看得懂的东西，他得到的更像一次漂亮演示，而不是自己的软件。

有人会说，直接用托管式在线服务，也就是 SaaS，就好了。这个看法很合理。平台替你运行和维护应用，解决了即时可用、共享运维和许多人的日常便利，也会一直适合大量场景。ARC 不是要让每个人重新学习当系统管理员，更不是要求每个人把所有服务搬回家里。买一部手机时，没人会先问它是不是“自托管”，只会觉得它本来就是自己的。我们想改变的是另一件事：当一个应用真的成为你生活的一部分时，拥有它不该因为技术门槛而变得不可能。

ARC 不想再给 Agent 一台传统电脑

传统服务器、虚拟机和隔离运行环境都可以让 Agent 做事。但它们带着传统计算机的包袱：版本更新、访问权限、故障维护，以及一大堆彼此独立的管理界面。让 Agent 去操作它们当然比让普通用户自己操作好一些，可复杂性只是换了一个人去背，并没有消失。

ARC 从 AFS 开始。AFS 是 Agentic File System，它不是把传统文件系统换个名字，而是用“文件系统”作为统一抽象，让人和 Agent 都能理解和操作数据、可使用的服务与当前上下文。可以把它想成一个共同的工作台：只有在用户明确授权、有关数据或服务已经接入之后，应用才能找到资料、理解权限并使用被允许的服务。普通用户不需要看见这层抽象，但它决定了系统能不能把不同环境中的东西放到一个可理解的表面上。

在 AFS 之上是 AOS，Agentic Operating System。两者一起构成 ARC 的运行时，也就是让应用实际跑起来的底层环境。ARC 已经在本地和云端运行环境中验证 Blocklet 的运行与数据接入；未来还会继续向更多环境延伸。不同环境只是 ARC 的底层落点，不是用户要自己管理的一台台机器。这里真正重要的不是支持多少种平台，而是 Agent 面对的系统不再是一堆彼此陌生的盒子。

说白了，我们不想把“帮用户拥有软件”理解成“替用户管好一台服务器”。用户真正关心的是自己的东西还在不在、能不能继续用、出了问题能不能恢复。机器本身应该越来越像可替换的器具，而不是用户必须亲自伺候的对象。

重要的东西，不应该和一次运行绑在一起

这也是 ARC 和 ArcBlock 过去积累能够接上的地方。

身份这一层是 DID，Decentralized Identifier。可以把它理解为一种可持续沿用、可被验证的身份标识。ArcBlock 长期把身份看成系统的基础，而不是某个平台临时发给你的一个账号。人和设备等需要被识别的实体，都可以有自己的 DID。ARC 正在延续这套基础，我们的目标是让已有用户不必因为架构升级重新建立身份。这种连续性很重要。换了一个系统，如果“你是谁”都得重新开始，所谓升级其实很可疑。

数据这一层是 DID Spaces。它不是一个让用户去维护的网盘，而是个人数据应有的归属地。我们的设计目标是让 ARC 的运行时可被重建、应用可以被换掉，而真正长期重要的数据、历史和授权关系拥有独立的延续性。换掉应用或设备后，笔记、授权和历史不应跟着某次安装一起消失。这样说并不意味着数据从此不会丢失，也不意味着用户再也不用备份。它意味着系统应该把持久数据和一次具体运行分开，让同步、备份和恢复有清楚的对象。

区块链也没有被放弃，只是不再被拿来当口号。它仍是 ARC 架构中可验证记录、资产相关场景，以及未来支付能力的重要连续性。对用户而言，重要的不是先听到“区块链”，而是我们的目标是在需要核验的场景中，减少对单一平台日志的依赖。具体哪些行为可验证，必须由已经接入的身份与账本能力决定。链侧的 AFS 接入和链上结算还在建设中，不能因为方向清楚，就假装它们已经交付。

这几层放在一起，才是我们所说的“拥有”。用户拥有的不是某一台机器或一次部署，而是身份、数据、授权关系，以及在运行出现问题后继续恢复和迁移的可能。它不是一句“数据归你”的广告话术，而是一种架构上的分工：运行时的可替换性是这套架构要实现的目标，身份要连续，数据要有归属，重要行为要有可验证的记录。至于每一项在不同产品里会怎么落地，还要由真实产品慢慢证明。

Blocklet 的变化，要在真实产品里接受考验

Blocklet 是 ArcBlock 很早就创造的名字。旧 Blocklet 更像带着完整运行环境一起安装的软件包。它的价值一直很明确：把应用做成可以安装、复用、组合的部件。

在 ARC 里，这个想法没有丢掉，但实现模型正在变化。ARC 时代的 Blocklet 正朝描述性的应用定义演进：应用说清自己需要什么能力，ARC 提供通用的运行、身份、数据和交互基础。过去常被打包在 Blocklet Server 或某个 Kit 里的 DID、链、支付和站点、讨论能力，在 ARC 里仍要被承接，只是它们不再必然以原来的安装模型出现。这里常用“Blocklet 2.0”来指代这代模型，但最终对外命名仍会随产品而定。

这是一种有意的取舍，也有真实代价。旧模型里，复杂应用可以带着自己的完整运行环境；在这代模型的方向中，应用描述不承担任意可执行程序，常用能力由 ARC 统一提供。少见的特殊需求则需要由相应 Provider 单独实现并显式挂载。技术读者可以把这条边界理解为 AFS Provider。也就是说，我们放弃了一部分“什么都能塞进一个软件包里”的自由度，换取更清楚的安全边界，以及更少要由每个应用自己背的运行负担。

界面也是同样的思路。AUP，Agentic UI Protocol，让界面的含义和关键操作可以被描述出来，而不只藏在某个特定前端实现里。它不是“Agent 已经可以操作任何界面”的承诺，而是在为人、应用和 Agent 建立一层更清楚的共同语言。

技术读者可以把这看成抽象边界的重新划分。普通用户不必记住这些词。我们希望用户最终感受到：当数据、授权和应用能力具备迁移条件时，换设备或运行环境不必把应用突然变成另一个陌生的东西。

如果用户必须先上完一堂 ARC 课，才能用一个应用，那我们大概把事情做反了。

这套架构最终要在真实应用里接受检验，但不需要靠提前预告一批产品名来成立。用户只会在意自己能不能建立一个站点、组织一场讨论、管理身份、处理支付，或者安全地保存自己的资料。ARC 应该在后台承担身份、数据、运行和 Agent 协作的复杂性，而不是变成每个用户都必须理解的品牌负担。

恰恰因为旧平台已经做过这些具体能力，ARC 更不能拿一张漂亮的架构图来替代它们。新的模型应该让这些事情以更适合 Agent 与用户协作的方式发生，而不是让用户重新面对安装、配置和运维。

这也是为什么我们不想只画一张更复杂的架构图。过去我们常用面向开发者的架构图解释这些组件，它们仍有价值；但未来的 ArcBlock 不应把普通用户挡在组件名称外面。ARC 是新的主线，Blocklet、DID 和 Blockchain 是没有丢掉的根基。真正的测试不在图上，而在用户能不能自然地拥有自己需要的软件。

这件事还没有完成。ARC 也不会因为一篇文章就自动成立。我们接下来需要用产品、内容和公开的建设过程，把这套架构一层层证明出来。但我们想把方向先说清楚：AI 让软件更容易出现之后，下一步不该只是让更多软件被生成，而是让更多人真的拥有它。

附：文中术语速览

这不是 ArcBlock 的完整术语库，只是为这篇文章准备的阅读地图。正式战略与产品边界还会继续演进，因此表中的“正在建设”不是回避，而是刻意区分已经可用的基础和仍待验证的部分。