用 ARC 做区块链浏览器：界面来自 AFS

Robert2026年10月24日

Chain Explorer 首页，展示实体统计、最近交易与 Token 列表

Chain Explorer 线上首页，2026 年 10 月 24 日。截图聚焦数据浏览区域。

我们现在的 Block Explorer 已经用 ARC 实现了。打开它，你看到的是一个正常的区块链浏览器：查交易、打开账户、查看某个 Token，再沿着它的关联记录继续浏览。拆开源码，应用本身却主要是 AUP 的声明。

这里最值得讲的，是这件事为什么能变简单。ARC 把 ArcBlock 链数据接成 AFS 中可寻址的资源，Explorer 再用 AUP 描述这些资源怎样呈现、怎样被浏览。 查询适配和通用界面能力由底层承担，应用不必把它们再做一遍。

这也回答了一个经常被问到的问题：我们做 ARC，是不是就把 blockchain 放到一边了？链已经是 ARC 内置支持的一类系统资源，Explorer 是使用它的一个完整应用。

先把链放进文件系统

AFS，Agentic File System，给不同来源的资源提供统一的路径与操作接口。“文件系统”在这里不意味着把整条链下载成一堆磁盘文件。数据仍由链的服务提供，ARC 里的 OCAP provider 负责把查询结果转换成 AFS 条目。

默认的 main、beta 网络分别位于 /dev/chain/main 和 /dev/chain/beta。围绕其中一个网络，可以看到这样的资源关系，以下是与本文有关的部分：

/dev/chain/main/
  transactions/{hash}
  accounts/{address}/
    transactions/
    tokens/
  tokens/{address}/
    transactions/
    holders/
  assets/
  factories/
  stakes/
  bridges/

列出一个集合，用 list；读取一笔交易，用 read。账户下的交易、Token 下的持有者，也沿路径访问。应用使用统一接口，怎样把分页和查询条件翻译成 OCAP GraphQL 请求，则由 provider 处理。

这个区分很重要。当前实现是对 provider 所暴露实体与查询的只读视图，不能由此推导出任意底层链数据、签名或广播都已经变成可用的 AFS 操作。但对于 Explorer 要做的数据浏览，这个表面已经覆盖了相当多的内容。

它还是 host 级别的系统挂载，这里的 host 指运行应用的 ARC 实例。Explorer 不需要在自己的 manifest 里另外声明一份链连接；同一 host 中的其他应用也能使用这组路径。链的接入能力因此可以被复用。

Explorer 描述的是“看哪里”

AUP，Agentic UI Protocol，用结构化声明描述界面。节点声明组件类型、数据来源、属性和事件，通用运行时负责把它们呈现给用户。

Explorer 页面中最能说明问题的是下面这段。它摘自主页面定义，只保留理解所需的字段：

{
  "id": "primary-surface",
  "type": "surface",
  "src": "/dev/chain/main",
  "props": {
    "variant": "data-browser",
    "mountRoot": "/dev/chain/main",
    "urlSync": "loc",
    "urlSelect": "loc",
    "urlSyncMode": "push"
  }
}

这段没有写“怎样请求一笔交易，再怎样创建一个交易详情组件”。它指向一棵数据树，声明在这个范围内浏览，并让当前浏览位置与 URL 同步。页面外壳再提供导航、搜索和网络选择器。

浏览器里的 /main/tokens/某个地址，通过站点绑定对应到 /dev/chain/main/tokens/某个地址。切换 beta 网络，就是把浏览位置换到另一棵同形状的数据树。两个网络共用界面描述。

所以，眼前这个有独立网址、有导航和详情页的应用，可以由声明式 blocklet 组成。运行时和 provider 当然仍有实现代码；被省下的是 Explorer 自己重复维护的那一层。

从一笔交易，走到它的 Token

打开首页最近交易中的一条，就进入交易详情。下面这笔是 Transfer V3。Hash 标识这笔交易；类型说明它执行什么操作；状态表示执行结果；Sender 和 Receiver 表明参与方。

Transfer V3 详情，展示交易状态、发送者、接收者与执行回执

线上交易详情，2026 年 10 月 24 日。Receipts 展示这笔交易造成的具体变更。

Receipts 比“成功”两个字更具体。在这个例子中，它列出了两个账户对应的 Token 数量变更；Raw 标签页则提供原始数据，供需要进一步核对的人查看。界面把一条记录展开成了可追查的关系。

点击回执中的 AIGNEP，还能继续进入它的 Token 页面。Token 是有独立地址和状态的实体。这里能看到标识、发行者、显示精度和权限；Transactions 与 Top Holders 标签页分别进入相关交易和持有者集合。

AIGNEP Token 详情，展示 Token 标识、发行者、精度与权限

线上 Token 详情，2026 年 10 月 24 日。截图中的数量是当时的状态快照。

精度也属于展示需要理解的数据。链上的整数数量，要结合 Token 的 decimal 才能显示成人读的单位。这个规则由字段格式声明表达，不需要每张表自己实现一次。

数据旁边，带着怎样展示它的描述

主页面只说“浏览这棵树”，为什么运行时知道 Token 应该显示哪些字段？因为 OCAP provider 除了数据适配，还随包提供了 AUP recipes，也就是针对不同实体的展示模板。

运行时可以通过挂载树中的 .aup 入口读取这些模板。集合有集合视图，单个实体有详情视图。Explorer 进入某个位置时，可以沿用 provider 提供的描述。链上的数据与 ARC 中的展示描述各有来源：recipes 随 provider 分发，并没有写到区块链上。

例如，Token 详情模板中，持有者列表的关键部分如下。这里同样省略了部分列和属性：

{
  "id": "tok-tab-holders-list",
  "type": "afs-list",
  "src": "${_parentPath}/holders",
  "props": {
    "layout": "table",
    "columns": [
      { "key": "content.address", "label": "Address", "format": "did" },
      { "key": "content._tokenBalance", "label": "Balance",
        "format": "bignum:@{content._tokenDecimal}",
        "symbol": "@{content._tokenSymbol}" }
    ],
    "pageSize": 10,
    "pagination": "manual"
  }
}

_parentPath 是当前 Token 的路径，在后面接 /holders，就得到该 Token 的持有者集合。剩下的声明告诉运行时用表格显示地址和余额，按该 Token 的精度格式化数量，并分页读取。

这就是“描述性”的具体含义。数据取自哪里、如何组合成视图、字段如何显示，都是可读的声明。provider 仍需完成查询和必要的数据整理，通用 renderer 仍需实现表格与交互。应用简单，是因为这些工作已经有了归属。

动态应用，比生成静态页面多了什么

我们的网站大量使用 Web Device 生成适合发布和索引的页面。Explorer 展示了 ARC 的另一种使用方式：浏览位置不断变化，查询条件会变化，用户打开的也是正在变化的链数据。

点击一个 Hash，运行时读取对应实体并呈现详情；切换标签页，读取关联集合；翻到下一页，provider 请求下一批记录。这些内容不需要等一次网站构建才出现。首屏可以先由服务端渲染，后续交互继续在 AUP 会话中发生。

交易事件还有一条实时更新通道：OCAP provider 在支持订阅的数据源上监听 tx.create，把新交易转成指向 transactions/{hash} 的 AFS append 事件。界面的列表消费这些事件，具体刷新由通用运行时处理。

这条通道有运行条件：数据源和部署适配器要支持订阅；不能建立订阅时，读取仍然可用。实时交易通知也不意味着所有统计字段都逐条推送，当前 provider 的链级聚合查询有 30 秒缓存。因此，“动态读取”“交易事件更新”和“每个字段立即变化”，需要分清楚。

对应用开发者来说，关键是不用在 Explorer 里另写一套链专用的事件传输和 DOM 更新逻辑。AUP 的描述并不把应用限制在静态内容上。

人看网页，agent 读同一组资源

Explorer 还把 AFS 应用的一个核心原则摆到了眼前：人和 agent 都是头等公民。 人适合通过网页理解交易，agent 适合通过规整的路径和结构化字段理解交易。两者面对的是同一组链资源。

比如刚才那笔 Transfer V3，人打开详情页看状态、参与方和回执；agent 则可以直接读取对应的 AFS 条目：

arc afs read /dev/chain/main/transactions/D892B951049B2FA859769D56F236682E3F700830ACE002A44615DD1D321F1274

这条路径对应的条目把交易数据放在 content 中，provider 再提供统一的实体信息。agent 可以按字段读取 Hash、类型、时间和参与方，也可以继续读取 Token，或列出它的持有者、交易集合。访问范围仍以 provider 暴露的能力为准。

网页的表格怎样排版、长地址怎样缩写、某个标签页当前是否展开，都不影响这些资源的寻址。agent 不需要先下载网页、解析复杂的 DOM，再从视觉结构里猜哪一列是发送者。界面调整后，它仍然沿着数据路径工作。

同样，人也不用为了理解数据去读 JSON。AUP 把这些资源变成可浏览的页面，展示合适的字段和关联入口。人得到好读的界面，agent 得到好用的数据接口，这两种使用方式在 AFS 上对应起来。同一个应用，同时把人和 agent 当作头等公民。

从哪里开始做一个类似的界面

可以直接打开 main 或 beta 体验。原来的 main.abtnetwork.io、beta.abtnetwork.io 浏览器入口，也已经分别重定向到这里。

想从代码理解，可以先看 chain-explorer blocklet：manifest 定义站点与路径绑定，.aup 定义应用外壳和浏览 surface。然后去看 OCAP provider 的数据路由和 aup/ 模板，两部分对应起来，整个实现就容易读了。

在已安装 ARC、具备默认链设备的本地环境里，也可以先绕过界面看数据：

arc afs list /dev/chain
arc afs list /dev/chain/main/tokens
arc afs read /dev/chain/main/tokens/z35nQNyuhz8wXi9uZkmLw9HYJLk4DSaJV3hoC

第一条命令可用于确认默认网络：应能列出 main 和 beta。自定义网络的配置见 Explorer README。

做类似应用时，先确认需要的数据是否已经被 provider 暴露，再决定哪些集合用列表、哪些实体用详情，以及点击后要浏览到哪个路径。有现成 provider 时，可以集中精力写视图；数据源尚未接入时，适配工作仍然要做。涉及签名、交易提交等写操作，还需要另行处理授权和执行。

简单的是应用定义

这次 Explorer 最能说明的，是区块链支持怎样成为 ARC 的基础能力。链数据有稳定的路径，provider 把实体和关联查询整理好，AUP 再把它们呈现为可以连续浏览的应用。

用户看到的仍然是一个正常的 Block Explorer。工程上改变的，是我们定义它的方式：不用围绕每个页面重复搭一套数据访问和界面逻辑，而是把已有资源组合成视图。Blockchain 在 ARC 里有了具体的位置，AUP 也有了一个每天面对真实链数据的动态应用。人沿着网页浏览，agent 沿着 AFS 路径读取；同一个应用，把两者都当作直接使用这些资源的头等公民。