# 关于我跟 AI 一起搓了个给它用的 Safe 客户端这件事

By [zhixian](https://paragraph.com/@zhixian) · 2025-04-02

---

     好久不见！最近深度使用 AI 有一段时间了，也不止一次地经历了不亚于初识 Bitcoin 时的激动和畅想。兴奋褪去之后，我开始重新思考 Crypto 和 AI 这一对原生于信息时代的基础设施能够有什么火花，而最近的一些工程实践让我初步闪现出了一些设想，于是就想着记录下来，也方便分享和讨论。这篇文章会比较长，主要分三个部分：

*   引子 —— 简单介绍一下我用 Cursor + 3.7 Sonnet 写的开源小工具：Safer（[GitHub](https://github.com/safer-sh/safer)），一个以最小化依赖为原则的本地 Safe 客户端，支持 CLI（for devs）和 MCP（for AI agents）两种界面。Safer 还不是一个严肃的项目，有很多需要完善的地方，更有价值的其实是 build 它的过程，可以说这段经历是我最近对 AI 和 Crypto 结合的思考源泉。
    
*   交互安全，AI 和 Crypto UX —— 对交互安全的介绍，以及我对与 AI 如何提升 Crypto UX 的一些思考和脑洞。
    
*   区块链原生的 AI 接口层的设计草稿 —— 一种从第一性原理出发的 Crypto 交互方案设计，目标是「没有中间商赚差价转信息」，让用户在 AI 的辅助下更简单也更安全地跟区块链直接交互。
    

观前提醒：本文虽然主要讨论 dApp 交互安全，但是读者并不需要技术背景（有些面向 dev 的内容很好识别，看不懂当没看见就好）。

### 1\. Safer 简介

     Safer 是我对于提升交互安全性的粗浅理解和实践：它在本地运行，只通过 RPC 跟去中心化设施通信，避免了访问网站可能出现的各种攻击（Bybit safe hack 的根本原因）——不出门就不会淋雨；最小化依赖，除了官方包基本只有 ethers 这一个外部工具库，尽可能降低供应链攻击风险——能自己做饭就不点外卖；支持 AI agent + MCP 的使用方式，用自然语言完成复杂操作，自带答疑和风险提示——靠谱“技术老哥”在线保驾护航。

*   CLI 模式：`npm i -g @safer-sh/cli` ，技术老哥们应该都会用，我就不多说了。
    
*   MCP 模式：command 设置为 `npx`，args 设置为 `@safer-sh/mcp`，然后直接跟 AI 说”_我想用 safer 管理钱包_”之类的就可以看到引导了。注意，高级的推理模型效果反而可能不好，比如我用下来 3.5 调用效果比 3.7 好，因为 3.7 总是“自作主张”地不看 prompts，而是按自己理解来 🤷。下图展示了让 AI 从 IPFS 导入一笔多签交易，然后用本地 Ledger 钱包签名并执行的过程：
    

![Safer MCP - Import TX from IPFS and Execute with Ledger](https://storage.googleapis.com/papyrus_images/05f8ff22ada211355f340dd5183270dbfa73aeac558338097bda68bfc91ec4a6.png)

Safer MCP - Import TX from IPFS and Execute with Ledger

这时候，如果对方发给我的实际上是类似 Bybit hack 里的危险交易，那么 agent 就会在它查看交易详情时提示我执行的是 delegateCall，而这是一种风险很高的操作：

![Safer MCP - Alert on Delegate Call](https://storage.googleapis.com/papyrus_images/3ddfdaf9fcb211545545d1cfd6e17a13f2d15f7c35e73a971ba5b91d22fb0047.png)

Safer MCP - Alert on Delegate Call

     另外，core 模块可以单独用，signer 也抽象了接口，可以增加比如对 Trezor 的支持。如果你对 safer 的实现感兴趣，欢迎 clone（ [repo](https://github.com/safer-sh/safer) ）一份到本地玩一玩，调教一下 MCP 的 prompts，以 safer 为基础继续探索。最后，虽然 safer 不能用浏览器访问，但是我仍然认为它符合传统 dApp 的定义：不依赖后端和域名，任何人都可以用它直接跟智能合约交互。

     最后说说心路历程：其实最开始我只是想做一个 core lib + cli 验证一下最小化依赖的可行性，顺带也测试一下当时新出的 3.7 看看有多大提升。不过开始后没多久，我就发现事情好像没那么简单：每当我完成一个命令的开发，就会让 agent 自动调用它来完成一些测试，有时候 cli 命令非常长，还跟上下文有关（比如“请重新执行一下刚才失败的交易”），但是 agent 总是能够瞬间生成非常完美的命令来完成功能，甚至会补足一些我没提供的信息（比如 token 在当前链上的 contract address）。这种交互体验给了我启发：AI agent 不就是一个现成的 \*\*crypto “懂哥”\*\*吗！虽然这些 general purpose 的模型做不到 100% 精确，但是其专业度已经超过绝大多数用户甚至从业者了。恰逢当时刚刚了解到 mcp，于是马上增加了一个 mcp 模块，试了一下果然效果拔群，虽然还有很多可以优化的点，但是这种模式让我看到了解决 Crypto UX 里交互安全的一种可能的方向。

### 2\. 交互安全，AI 和 Crypto UX

     就在不到一个月前，可能是史上金额最大的黑客盗窃事件发生了：黑客接管了 Bybit 的一个存有 50万枚 ETH 的 Safe 多签钱包，并立即进行了资金的转移和清洗。经过几天的调查，事情的原因浮出水面：黑客掌控了 Safe 团队的某个工程师的前端发布权限，在 Safe Web App 中注入了一段恶意代码。这段代码只针对 Bybit 多签的几个管理人的钱包生效，在他们发起转账交易时替换了实际签署的交易逻辑，于是即便页面上展示的是正常的转账交易，但是他们实际签署的是把 Safe 钱包的逻辑切换成黑客版本的授权交易。因此，即便他们转账的金额并不大，黑客还是能够把整个钱包的资金席卷一空，而不只是拿走他们要转的钱。

     这件事情给一些朋友带来了恐慌——这可是托管着几百亿美元资产、那么多年都没出过问题的 Safe 啊，莫非我在 Safe 里的资产也得赶紧转出来？有这种担心很正常，因为即便用上一段那样朴素的语言去解释，大多数人还是很难理解交互层的风险能够影响的范围，而**无法理解的危险是很难防护的**：不出问题时会过于乐观，出问题时又会陷入恐慌。相比之下，「私钥泄漏的话钱会被转走」和「合约漏洞会让你身无分文」就好理解多了，大众认知和基础设施在这些方面的提升也是有目共睹的。为了方便叙述，我们把这些介于私钥到合约之间的流程中所涉及的安全问题叫做**交互安全**。我们来列几个常见的交互安全问题：

1.  **钓鱼**。这可能是 dApp 交互的“事故多发路段”了。所谓钓鱼，简单来说就是在假的网页上被引导做了一些操作，比如签了授权或者导入了私钥，从而导致了资产损失等后果。我们都知道，网站的入口是域名，而域名是很难记清楚的，尤其是一些很长的链接，我们就更容易忽略对域名的检查了。还有一些特定场景下，用户会对钓鱼链接放下防备，比如 X 上一些高仿账号在官方账号下回复的钓鱼链接，以及在群里伪装官方人员发送的链接等。
    
2.  **供应链攻击**。这是个专业用语，简单点说就是 dApp 用到的一些工具里出现了恶意代码，在用户提交交易的时候修改了交易的内容。比如 XXSwap 的网站使用了某个格式化时间的工具，而这个工具在某次更新时被加入了一个「劫持并替换交易为授权代币给黑客」的隐藏逻辑，那么如果 XXSwap 在某次更新网站时更新了依赖，那么这段恶意代码就同样被用户下载到了浏览器中。用户在签名时可能因为没注意，一直确认点下去，导致大量资产被黑客转走。
    
3.  **恶意插件**。每次我看到有朋友的 Chrome 安装了「勋章」一样密密麻麻的插件时，总是会忍不住提醒他们“钱包最好单独装在一个 Profile 里”。这是因为 Chrome 插件的权限是非常高的，最基础的插件也会默认拥有对所有网页的查看和修改权限（所以说把私钥放在页面存储里的项目都是在裸奔）。前面说的两种攻击看上去实施起来没那么容易，但是如果一个恶意插件想完成这些攻击就易如反掌了，因为它们的权限比网页本身还高，想对页面做什么修改的话，页面没有任何知觉和抵抗能力。前两天一个老牌插件 SwitchyOmega 就被曝出有偷窃用户私钥的风险，而有趣的是，它本身也是上面提到的「供应链攻击」的受害者，同样受到影响到插件有三十多个。
    

上面介绍的这些风险只是冰山一角，如果大家有兴趣深入了解安全问题，还是推荐去看慢雾出品的《[黑手册](https://github.com/slowmist/Blockchain-dark-forest-selfguard-handbook/blob/main/README_CN.md)》，相信你会有很大收获。另外，插件钱包如果做得好，其实可以解决一部分交互安全问题，比如某个《疯狂动物城》主角 logo 的 EVM 钱包；当然也有反面案例，比如另一个《疯狂动物城》主角 logo 的 EVM 钱包。当然，前提是你每次都能做到认真查看和理解钱包给出的的提示，做好数据比对，按捺住「一脚射门」的躁动的心。

     那么有没有办法减少甚至消除交互安全问题呢？我们从最极端的方式起步来讨论：让用户直接“手拼”交易给钱包签名。这确实是理论上能够消除交互安全隐患的最好方法，但是几乎没有可行性，因为门槛太高了——用户必须完全掌握区块链对应的交易格式和目标合约逻辑，并且能够克服各种数据格式转换带来的问题，最后还不能在关键数据上出错。即便有人能够克服这些问题，那么他手写交易所花费的时间和精力也肯定是无法接受的。

     但是如果这个“人”他不是真的人呢？想想看，最近这种能够帮人快速解决复杂专业问题的工具是不是在突飞猛进地发展？而且相比于「用吉卜力画风重画照片」这种接近创作的高级任务，上面提到的难题反而显得非常简单了不是吗？

     没错，这就是我看到的 Crypto UX 进化的可能性——**利用 AI agent 替代 dApp 的交互层，协助用户直接跟区块链交互**。当然，这个想法可能还有些“前瞻”，毕竟 AI 的普及度跟 Web 还无法相比。不过，作为深度使用 AI 之后的 early adopter，我相信未来人们的交互可能会经历一次不亚于从 PC 互联网到移动互联网迁移的巨变。那时候很多开发面向的可能真的不是人类而是 AI 了，各种各样的 MCP 类似的协议可能会大行其道，AI 能够帮人类完成的任务也会越来越复杂和精确。

     除了 MCP、RAG 这些外挂，Crypto 专用的小模型也是一个可能的探索方向。作为一个技术专业性强、安全等级高的细分领域，Crypto 跟 AI 的相性非常好。一个精通各种 Crypto 概念和操作，熟知各种安全风险的「加密懂哥」型的小模型很可能可以在 1b 以内的参数量内达到，毕竟 QwQ 这种推理模型都已经可以蒸馏到 32b 了。如果这个能够实现，那么我们的本地钱包应用就可以内置一个小模型，彻底杜绝外部注入恶意逻辑的可能。

     我们可以想见，有了 AI 的帮助，不管是跨链还是调仓，原来可能需要专门做一系列产品才能实现的操作，现在只需要让 AI 了解你的需求，然后自己就能按步骤完成了——这才是终极的「 **intent based** 」啊！

### 3\. MCP Node：区块链原生的 AI 接口层

     如果说前面讲的是 AI 这边可以怎么“努力” 去改善 Crypto UX 的话，下面讲的则是 Crypto 这边可以作出的“努力”。首先我们要讲一下之前没有展开的一个概念——MCP。

\*\*     M\*\*odel **C**ontext **P**rotocol 是 Claude 的开发商 Anthropic [提出的协议](https://docs.anthropic.com/en/docs/agents-and-tools/mcp)，官方给出的解释非常清晰易懂：把 AI 比做电脑的话，MCP 就是 USB 协议；电脑用 USB 连接各种外部设备，AI 则用 MCP 连接各种外部服务。这个类比虽然易于理解，但是没有把 MCP 的潜力说出来，因为两者的关键区别是 AI 调用 MCP 的自主性非常强，可以根据用户的意愿自动寻找工具，甚至自主做一些测试来评判不同工具的优劣。

![MCP Workflow: https://modelcontextprotocol.io/introduction](https://storage.googleapis.com/papyrus_images/9af9af10f62d9ab8e274294b7e6d2f220dc7562987a31bb89240eb94be7b6210.png)

MCP Workflow: https://modelcontextprotocol.io/introduction

     从官方的流程图中可以看到，MCP server 是现阶段打通各种外部服务的桥梁，比如咱们的 `@safer-sh/mcp` 模块就是一个 MCP server for Safe wallet，它给了 AI 一系列资源（resources）、工具（tools）和使用说明（prompts），让它知道该怎么拼装交易，调用钱包，以及操作流程等等。这时候如果你回到文章开头的截图那里，应该就可以看懂 `Called MCP tool safer_transaction` 的意思了——AI 根据 prompts 得知发送一笔交易需要调用 safer\_transaction 这个工具，并且逐次进行导入、查看、签名和执行等动作，最后还要等交易上链后才能确认成功。

     说到这里，了解 EVM 合约调用的朋友们有没有一种似曾相识的感觉？「根据说明拼装交易」，这不就像是根据 ABI 和文档拼交易吗？继续往下想，AI 是不是自己也能看懂 ABI 和文档，自己拼交易？再结合 static call 的查询信息和逻辑验证能力，RPC Node 不就变成 **MCP Node** 了吗！我当时也是这么想的，于是就有了下面的对话：

![Initial Thoughts about MCP Node](https://storage.googleapis.com/papyrus_images/7d170a11f262493d3d68932b7bb7a5d8383c88bdec4af0eadbafb48b6215cffa.png)

Initial Thoughts about MCP Node

     说句题外话，从这段对话里可以看出目前 AI 的一个问题，就是默认会倾向于赞同用户的想法（各种🌈 P），但是会忽略一些风险和障碍。从这个层面上说，掌控 AI 需要锻炼的技能还真就是当老板的一些能力，比如派活和验收，还有甄别对方是不是真心赞同一件事情。

     除了思考方向，还要评估可行性。AI 给出的答复显然没有考虑一些现实问题，比如已经部署好的合约改动代价很大，甚至无法升级；用户意愿很难直接对应到某个具体的合约调用上，需要有一个注册表来给 AI 指出基本的方向等等。于是在琢磨了几天之后，我大概有了一些粗略的点：

*   **“外挂”的 MCP 合约**。给每**一套**合约部署一个提供 static call 的 MCP 合约。这样的好处有很多：
    
    *   可以兼容现在所有的已经在运行的合约
        
    *   可以按照业务逻辑而非单个合约本身来组织流程
        
    *   MCP 合约可以单独升级，与时俱进
        
    *   可以在比较经济的链上部署 MCP 合约
        
*   **统一的注册表**。这个设计主要解决两个问题：
    
    *   认证：因为 MCP 合约会指导 AI 的操作，因此也有注入恶意信息的风险，所以最好能够由官方或者比较权威的主体来给出，甚至审计。我们可以借助 ENS 或者 DNS 给出相应的认证，以及通过跨链或者 zk 来认证原合约的部署者。
        
    *   “指路”：现在的 AI 受限于 context window 大小，无法持续保存全量的上下文。为了让 AI 快速了解到一件事情有哪些可用的工具，用注册表分门别类地组织这些 MCP 合约是必要的。
        
*   **极简的 MCP 桥接 Server**。用户真正安装的最好是个“壳”，甚至有点像个钱包应用。它从注册表和 MCP 合约获取信息，并且利用 MCP 的动态加载能力在自己的 context 里注入成对应业务逻辑的 resources、prompts 甚至 tools。所以它主要包含的逻辑是链上交互 SOP 以及钱包交互 SOP，类似一个抽象出来的接口或者说抽象类。
    

这些设计的目标是一致的，就是让 AI 能够通过 mcp 这个桥梁跟区块链「直接对话」，进一步压缩交互安全问题能够滋生的土壤空间，也让智能合约的可用性上一个台阶——以后就不用担心项目方前端下了怎么办的问题了。

     OK，再不刹车就陷入细节了，这次就先说到这里吧。总结一下的话，我觉得 AI 对 Crypto UX 的提升是非常符合 Crypto 特性和宗旨的：Crypto 要求它的用户是足够专业的，而 AI 能够帮助普通用户提升专业性。另外，AI 对链上数据确实有一些普通人没有的 insight，所以给用户一些操作建议的方向也是很值得探索的。

---

*Originally published on [zhixian](https://paragraph.com/@zhixian/ai-safe)*