智能体管钱，信任从哪来？AI身份协议ALMA解析

如果让一个 AI 智能体去处理资金转账，你如何确认它的身份？它凭什么证明自己靠谱？

目前的答案完全取决于托管这个 Agent 的平台。它的身份不过是一串 API Key，权限配置在后台设置面板里，历史记录存放在中心化数据库中。一旦 Agent 切换底层大模型、更换钱包提供商或迁移区块链，之前积累的一切信用全部归零。

开源协议 ALMA 就是为了解决这个断层而设计的。

什么是 ALMA？

ALMA 旨在为任何实体（人、机构或自主智能体）提供持久的独立身份，并让外界能够随时验证关于它的五个核心问题：

你是谁？ 一个脱离具体钱包、底层大模型或公链绑定的持久身份。
你代表谁？ 智能体与幕后控制人或机构之间存在可验证的加密关联。
你能做什么？ 具备明确范围和额度的委托授权，例如「单笔支付上限 1,000 USDT」。
你能证明什么？ 可公开、可私密，甚至可通过零知识证明验证的凭证。
你做过什么？ 一段任何人都能独立核验的经济履约历史。

一个 ALMA 标识符的形式类似：alma:main:agent:treasury。

只要拥有这个标识，Agent 从 Claude 切换到 GPT，从云服务器迁至私有节点，或者更换底层充值钱包，它依然是同一个主体，保留着原本的授权和历史声誉。

需要强调的是，ALMA 本身不是钱包，不是代币，也不是一个打分系统。它从不给 Agent 下定义说「该智能体信誉分 87 分」，而是负责暴露客观且可验证的证据链，交由各个具体应用按自己的风控规则去判断。

最难的部分：无法被伪造的声誉

给 Agent 分配一个 ID 很简单，难的是让它的历史记录具备公信力。

如果一个智能体自称「我之前成功完成过 500 笔付款从未出错」，这毫无说服力。即便是托管它的平台出具证明，依然不够可靠——平台可能出现技术故障，也可能人为篡改数据库。ALMA 通过三层机制来解决「履约真实性」的问题：

1. 对手方确认的收据（Receipts）

当 Agent A 向 Agent B 付款时，系统会生成一张收据。收款方确认资金已到账，付款方确认承诺的货物或服务已交付。每一份确认都只能为「对方」累积信用，永远不能为自己背书。此外，属于同一家公司的两个 Agent 之间发生的内部交易不会生成有效收据，直接杜绝了自刷交易量制造信誉的可能。

2. 签发者签名（Issuer Signature）

每张收据与确认凭据均带有 Ed25519 签名。只有被签名确认的数据才会被纳入声誉计算。如果有人试图在数据库里偷偷篡改一条记录，签名校验就会失败，该收据即刻失效。

3. 透明日志（Transparency Log）

签名能防止数据被篡改，但防不住数据被「删除」——如果平台删掉了一条违规投诉记录，外界很难察觉。因此，所有签名收据都会被存入一个只增不减（Append-only）的透明日志中。该机制参考了保护 HTTPS 证书安全的 Certificate Transparency 标准，基于 Merkle 树（RFC 9162）构建。哪怕一条差评记录被悄悄移除，Merkle 树路径也无法自洽，直接暴露篡改行为。

为了防止拥有签名密钥的平台方彻底重写整棵树，团队定期将 Merkle 树的根哈希写入隐私公链 Midnight 的智能合约中。该合约部署在 Midnight 的测试网络上，逻辑极其简单：只接受持续生长的树，绝不覆盖已有树根。自此，外界任何人都能独立验证当前的交易日志是否与链上锚定的历史完全连续。

这意味着，Agent 的声誉体系无需建立在对任何单一公司的盲目信任之上，外部机构可以完全自主验证。

系统拼图：开源仓库详解

ALMA 是底层协议，而团队开发的 AdaSouls 则是基于该协议落地的执行产品，用于在既定策略下执行受控的经济动作。目前全套代码已基于 MIT 协议完全开源，并在 npm 上发布了 @adasouls 包。

alma：核心协议仓库。
- spec/alma-v1：协议规范，涵盖身份模型、授权与信任、撤销机制与跨平台互操作。
- @adasouls/alma-core：处理标识符、授权委托、收据、数字签名与透明日志证明。纯逻辑运行，不依赖特定网络或数据库，任何人都能在本地离线校验收据有效性。
- @adasouls/alma-manifest：基于 YAML 格式的 Agent 声明文件，集中定义其策略与委托规则。
- @adasouls/alma-credentials：可验证凭证（Verifiable Credentials）的底层骨架。
adasouls-engine：将 Agent 意图转化为受控操作的执行引擎，包含三个模块：
- economic-core：经济行为的状态模型与审计链路。
- policy-engine：规则校验引擎，实时决定该笔操作是直接放行、阻断拦截，还是需要唤醒人工审批（Human-in-the-loop）。
- provider-adapters：统一支付接口抽象。当前包含一个 Mock 实现以及对 Base Sepolia 测试网上 Safe 多签钱包的适配器。
adasouls-sdk-typescript：面向开发者的 SDK。Agent 代码中只需调用 agent.execute({ capability: 'pay', ... })，完全无需直接与底层复杂的支付通道耦合。
adasouls-mcp：基于模型上下文协议（Model Context Protocol）的服务器。任何兼容 MCP 的智能体（如 Claude）都能在不侵入业务代码的前提下，快速读取自身权限策略并执行支付。
reference-agents：参考实现用例。首个用例为一个财务 Agent，它严格受限于预算额度，并且只在供应商拥有可验证的履约记录时才会执行付款。