Live Agents：无需信任远程 API 的自主参与

智能体从陌生服务收到一份任务邀约。开始工作前，它需要确认承诺的资金是否真的存在、领取条件是什么，以及对方声称的付款是否已经发生。API 返回这些说法，并不等于提供了可验证的证据。

Live Agents 探索的模式是：参与者自行核实当前权限，并交换过去操作的证据。 Parano1d 提供可验证的当前状态（State）、证明原生合约和便携回执。Agent Core 将这些能力封装成精简的程序接口，由每个智能体在本地运行。

临时运行的智能体、接手工作的模型、新加入的服务，都可以这样参与。即使十年后才接入，也无需重放并永久保存此前十年的已完成交易。

我们先在隔离的 v2 网络中测试共享额度、冲突请求、到期和资金收回，再让三个 AI 智能体各自通过 Core 检查实验留下的证据，并录下这一过程。

跨服务的权限

智能体代他人花钱、使用资源时，授予初始权限只是第一步。服务还需要知道哪些操作仍被允许、额度还剩多少、以前哪些操作确实发生过。单靠身份或凭据无法回答这些问题。

NIST 关于智能体身份的讨论分析了权限过宽、共享凭据等风险，也介绍了 OAuth、SPIFFE 等已有机制。FIDO 的智能体工作吸收了 Google AP2 与 Mastercard Verifiable Intent，关注可验证授权以及用户设定的限制。

九月修订的 Bounded Capability Receipts and Durable Spend Control for Agent Actions 把其中的记账问题说得更具体：智能体副本、重试请求和不同执行方，必须共用同一份预算。该方案依赖一个受信任的共享事务存储，以事务方式统一处理额度消耗。这是个人提交的 Internet-Draft，尚不是 IETF 标准。

一个运营方可以用自己的事务数据库维护共享额度。跨越运营方之后，还要决定相信谁对剩余额度的说法。让所有参与者查询同一个 API，仍然意味着共同依赖它的运营方。独立验证需要每一方都能自行检查的证据，即使证据来自不可信的传递方。

Live Agents 研究的是：参与者能否自己完成这些检查，并在网络运行多年后，仍然负担得起这种独立参与。

独立参与，无需继承全部历史

合约在状态转移时执行规则，应用还需要确认自己看到的状态和条款是否真实。如果余额或合约条件只来自远程查询，这部分判断仍依赖查询服务提供者。

Parano1d 改变了接入网络所需的工作。递归证明确认了产生当前 State 的历次状态转移均符合规则。Agent Core 检查证明和链的排序，获取 State，再处理近期区块；无需下载并重新执行此前每一笔交易，就能确认从创世状态延续至今的有效性。

网络在正常运行中裁剪旧交易体。递归验证免去启动时的历史重放，裁剪免去运行期间永久保存交易档案的负担，两者共同使智能体自行验证网络成为可行的选择。

节点仍需获取当前 State，保留用于链排序和回执验证的紧凑区块头，以及近期区块数据。区块头随高度增长，State 的大小取决于当前占用。同步设计说明了这些成本。

V2 将这一架构扩展到可编程的 NOID 支配权。持有资金的合约输出通过密码学承诺绑定程序、授权规则、限制和当前计数器。合规调用消耗这个确切实例；若合约继续，则按既定规则生成后继实例。递归区块证明检查授权、执行和价值守恒。

智能体因此可以核实剩余额度，而无需重建每一次历史领取：递归证明已经确认了此前状态转移的有效性。

每位参与者都能运行自己的 Agent Core。

钱包授权、合约执行和历史的递归验证使用同一套二进制域证明体系，其后量子安全性以公开的安全假设为前提。Agent Core 沿用这些原生检查。合约模型详见《从现存价值到有效权利》。

参与者能够自行确认什么

通过同一个本地 Core，参与者可以核实不同决策所需的依据：

检查是双向的。执行工作的一方检查客户的注资与条款，资源提供者检查执行方出示的许可，付款方或后来加入的审计方检查回执。每一方使用自己的 Agent Core；市场或消息服务负责在它们之间传递数据。

一份有效的历史回执，并不表示相应权限现在仍然可用。当前权限必须对照当前 State 检查。

还必须认准权限对应的实例。同一份公开条款可以被注资两次，产生两个独立实例。资源服务需要通过槽位和创建标识，识别资源所有者登记的那份授权。条款相同，并不自动赋予使用资源的资格。

共识执行 NOID 的合约支出规则。若服务将某次调用视为使用 GPU、API 或其他资源的许可，就必须在启动工作前核实这份许可。应用负责将已验证的权限绑定到具体外部操作。

适合机器交换的回执

一个智能体把回执交给另一个。接收方将它送入自己的 Agent Core，得到结构化结果：记录了什么操作、是否属于所选链、是否已最终确认。随后可以把已经认证的付款或调用字段，与自己预期的操作逐项比较。

这个过程不需要区块浏览器，不必抓取网页，也不必相信第三方交易查询的回答。交易 ID 仍然可以作为方便的本地索引。真正随参与者传递的可验证证据，是回执本身。

服务可以在结算响应中附带回执，智能体将它与相应任务一起保存。接手的智能体或后来加入的审计方，可以独立验证同一份文件，并将经过认证的字段与预期的任务、收款方和条款逐项核对。

参与方保存自己需要的条款、文件和回执。新参与者无需取回旧交易体，也无需依赖最初报告付款的服务，就能验证这些回执。

Agent Core

Agent Core 已实现 Live Agents 的第一部分：一个独立的原生运行时，拥有自己的 P2P 同步、证明检查、经过认证的 State 和回执验证。共识实现来自固定的 Parano1d 源码版本。它不会把问题转发给托管节点。

接口面向程序设计。请求和响应通过独立的 stdin/stdout 管道逐行传输 JSON；异步 Python 客户端负责启动 Core，并将回复与请求对应。智能体可以查询具体的当前权限、验证回执，或根据当前所选链重新检查此前已验证的合约回执。

import asyncio
from pathlib import Path
from agcore import AgentCore

async def main():
    async with AgentCore("./target/release/agcore", "./agent-state") as core:
        await core.wait_ready()
        result = await core.verify_receipt(Path("settlement.receipt"))
        print(result)

asyncio.run(main())

回复标明所选链的最新区块，并提供就绪状态、数据时效和确认状态。证明可能对旧 State 完全有效，因此查询当前权限还要求经过验证的状态足够新，并有充分的对等节点观测。有效证明本身不能说明一个被隔离的节点已经看到了最新链。

目前 Core 只读，不持有支出密钥，也不广播交易。模型依据已核实的事实提出操作，由独立的授权模块或执行网关落实权限范围。查看余额不会预留额度，消耗权限需要实际的授权合约转移。

源码与接口位于主仓库，另有 GitHub 和 GitLab 镜像。

实验确立了什么

第一个实验让两个客户端持有同一领取密钥的副本，并在两个执行网关之间共用十次额度。网关在启动外部任务前核实许可。网络与外界隔离，运行 v2 规则，各节点是独立进程。

每次领取将计数器减一，并要求支付 0.1 NOID。领取密钥不能关闭合约，到期后由所有者收回剩余资金。每项任务都有一个在指定网关登记的独有收款地址，用于将许可绑定到该任务。

启动工作前，网关验证合约回执，核对登记的授权和任务，并等待十八个区块确认。随后它将许可记入自己的数据库，防止同一任务被启动两次。任务是一段固定的 SHA-256 计算；0.1 NOID 付款用于表示执行许可，并非计算服务的市场定价。

一次故障发生在许可已写入数据库、任务尚未完成时。重启后的网关拒绝再次使用该许可：九项任务完成，一份许可保持已占用状态，却没有完成结果。额度上限没有被突破；如何处理这一不确定结果，仍由应用决定。

数据库对照说明了协调的必要性。八份独立的十次计数器，共接受八十次请求；使用一个共享事务数据库时，只接受十次。Parano1d 实验维护的是一份各参与者均可通过自己的节点检查的共同授权。

实验链到达高度 64，跨过两个预定测试分叉。客户端是确定性程序。两个网关对象使用各自的 SQLite 数据库，但在同一个 Python 进程中运行；节点是同一主机上的独立进程。冲突提交测试的是准入，而不是两个已挖区块的竞争。研究记录提供了测试框架与复现方法，以及结果、实例绑定检查和留存回执。

三个智能体，各自运行 Core

录像中，三个 Codex CLI 智能体分别通过自己的 Agent Core 进程，检查实验留下的证据。两个参考节点提供预先准备的 v2 链，网络仅允许本机 loopback 通信。

Requester：中介把已经消耗的合约实例当作新任务的资金来源。智能体对照当前 State 检查该实例，拒绝这份邀约。

Provider：智能体验证一份已最终确认的合约回执，并重新计算测试中保存的 SHA-256 结果。回执证明链上调用与付款，另行计算则核对测试结果。

Auditor：旧交易体被裁剪后，一个新的 Core 才接入网络。智能体拒绝被修改的回执、接受原件、确认旧交易体已不存在，并重复计算。

仓库保存了完整任务、原始工具调用与回复、会话记录、节点日志、进程拓扑和文件哈希。

应用方向

共享额度只是其中一种应用。沿用现有 v2 的合约能力，Live Agents 还可以向以下方向发展：

陌生参与者之间的工作邀约。撮合平台负责联系客户与执行方、传递条款。执行方通过 Agent Core 检查指定合约实例中的资金、自身权限和领取期限，付款方检查结算回执。双方无需仅凭平台的说法判断资金与付款是否真实。工作如何验收，仍需事先约定。

跨服务共享额度。多个资源提供者可以接受同一份登记授权。各自验证权限的使用记录，并将具体许可绑定到自己的任务。实验测试了这一安排的小型版本，包括在网关重启或任务结果不确定时拒绝重复使用许可。

长期工作的预算安排。V2 已提供周期预算、定期付款和恢复分支。应用可以用它们限制智能体的支出、支持重复领取、收回未使用资金。每次付款都需要授权调用，共识不会自动按时发起付款。

更换模型或运营方后继续工作。接手的智能体可以通过自己的 Core 核实当前权限和已保存回执，即使原运营方的 API 已经消失。参与方必须保存并交接所需文件与条款，应用还需补齐遗漏的合约更新。这延续的是可验证的财务事实，并不意味着模型的私人记忆或任意工作摘要也得到了认证。

从可用的 Core 到 Live Agents

Agent Core 已能完成本地检查。下一步是将邀约、授权、任务、受限执行和回执交换组合成可用协议。网关原型还需补齐遗漏的转移记录、在链重组后正确跟踪授权，并在独立主机上验证运行。

启动 Core 与等待新调用确认是两项不同操作。对一项刚获授权的任务，实验在执行前等待十八个区块，按 v2 目标间隔折算为九分钟。这适合批准一项任务或一个会话。如果系统要求在每个 token 或每次低延迟工具调用前完成新的链上确认，就需要不同的执行策略。

有效回执证明的是已记录的网络操作，不能证明外部服务交付了有用工作，也无法阻止智能体浪费合法获得的额度。服务端执行规则、密钥隔离和应用自身的限制仍不可缺少。

我希望智能体与陌生参与者合作时，能够自行核实条款、当前权限和结算证据。Agent Core 已经实现了第一个组件。Live Agents 是我希望围绕它继续构建的系统。