23 Agent × Web3 · 我,Agent

为什么 hackathon 上 Agent 盖过了链

先给你当初那个问题一个结构化的答案。区块链技术本身已经相当成熟——发币、写合约、搭 DApp 的路子(《上链》整本讲的就是这个)都有成熟工具链,不再是「新」的东西。评委看腻了「又一个 DeFi/NFT」。真正还有大片空白、还能让人眼前一亮的,是「让链变得好用、变得自动」的那层智能——而那正是 Agent。

于是范式变成了:链提供「可信的结算与状态」这块积木,Agent 提供「理解意图、自主行动」这层大脑。链负责「记账不可赖、执行不可拦」,Agent 负责「听懂人话、把复杂操作自己跑完」。MCP(第七章)则是把两者焊在一起的接口——难怪你满眼都是它。所以你的直觉没错:在这类 hackathon,你的 Agent 功力,往往比你的 Solidity 功力更能决定名次。

要点

把它记成一个分工:链是 Agent 的「可信执行层」,Agent 是链的「自然语言前端 + 自动驾驶」。区块链天生适合当 Agent 的后端——它的状态是客观可验证的(第十三章说的「客观验证器」链上全都有:余额、交易回执、合约状态都不可抵赖),这正好治 Agent 的过度自信(第十八章)。反过来,链最大的痛点是难用(私钥、gas、报文),而这正是 Agent 最擅长抹平的。两者是互补的,不是竞争的。

结合方式一:链上数据的「只读 MCP」(最安全,先做这个)

最容易做、也最安全的一类:把「读链上数据」包成 MCP 工具(第八章你已经会写 MCP server 了),让 Agent 能查而不能动。比如给它 get_balance(address)、get_token_price(symbol)、get_nft_holders(contract)、read_contract(addr, method) 这些只读工具。

这样你就能做出「用大白话查链上」的 Agent:「帮我看看这个地址最近有没有大额转出」「这个合约的持有人前十都是谁」。它把 JSON-RPC 报文(《上链》第 7 章讲的那套)藏在工具背后,用户只管说人话。只读 = 没有副作用 = 打破了致命三要素的第③条,即使被注入也顶多读到公开数据,风险极低。hackathon 建议从这里起步,一天就能做出能演示的东西。

结合方式二:Agent 自主签名与交易(高价值,高风险)

再进一步,就是让 Agent 不只读、还能写——发起交易、和合约交互、动钱包里的钱。这才是最吸引眼球、也最危险的方向。技术上,它是「给 Agent 一个能签名的工具」:

send_transaction(to, value)、swap(tokenA, tokenB, amount)、approve(spender, amount) 这类会改链上状态的工具。
签名这一步(私钥怎么管、怎么连钱包)本身是门大学问——请直接看《上链》里第 19 章连接与签名、第 23 章移动端私钥安全。这本书不重复,但那两章是你接这类工具前的必读。

典型场景:自动化的 DeFi 助手(「当 ETH 跌破 X 就帮我买入」)、Agent 管理的金库、按条件自动分账。想象空间很大,但——

✋ 最高危场景

一个能签名交易的 Agent,是致命三要素(第十九章)天生齐全的最坏情况:它握着私钥(①敏感)、要读链上/外部行情等不可信数据(②)、能广播交易(③对外且不可逆)。一次提示注入 → 一笔把你钱包掏空的交易,而且链上交易没有撤销键、没有客服、没有 chargeback。这不是理论风险,是这个方向的头号杀手。给 Agent 接签名权限,以下防线一条都不能省:额度上限(写在代码/合约里,不是提示里)、地址白名单、每笔交易人工二次确认、用受限的会话密钥而非主私钥、模拟执行后再签。

结合方式三:Agent 原生支付(新前沿)

一个正在兴起、hackathon 很爱的方向:让 Agent 之间、Agent 与服务之间直接用加密货币/稳定币结算。传统支付(信用卡)是为人设计的,要账户、要人工授权,Agent 用起来很别扭;而链上转账天生是「程序化、无需许可、可编程」的,反倒更适合机器自动付款。

由此催生了一批「Agent 原生支付」协议(如基于 HTTP 402 的 x402、以及各家的 agent payment 尝试):让 Agent 在调用一个付费 API 或服务时,能自动完成一笔小额链上支付再拿到结果——机器给机器付钱,无人参与。设想「我的研究 Agent 自动为它调用的每个数据源付费」,这在传统支付里几乎无法做,链上却顺理成章。这也是「稳定币 + Agent」被看好的核心叙事之一。前沿归前沿,上面那条安全铁律同样适用:自动支付必须有额度和白名单封顶。

▸ Android 类比

Agent 原生支付,有点像你 App 里的 IAP(应用内购买)从「每次弹窗让用户按指纹」变成了「预授权的自动扣费」——但扣费方从你信任的 Google Play 换成了一个会自己做决定的 Agent。你立刻能嗅到风险:自动扣费必须有额度封顶、有异常熔断、有对账。链上 Agent 支付是同一种警觉:方便的代价是你让渡了「每一笔都点确认」,所以护栏必须前置到代码和合约里。

⚠ 坑

hackathon 选题的现实建议:别一上来就做「全自主签名交易的 Agent」——技术上炫,但只要评委里有懂安全的,第一个问题就是「你怎么防注入盗签」,答不好全盘皆输;而且现场真金白银翻车的风险太高。更稳的打法是只读 MCP(方式一)做主体 + 单点的、带人工确认的写操作做亮点:既展示了 Agent × 链的完整闭环,又守住了安全叙事。评委爱看的是「你想清楚了风险」,而不是「你无视了风险」。记住第二十四章会讲的:hackathon 拼的是把一个想法讲成一个可信的完整故事。

◉ Agent 自白

说句作为 Agent 的心里话:区块链和我其实是互补的两种「信任」。链的信任来自数学和共识——它不需要相信任何人,代码即法律,但它也不理解意图,你让它转错地址它照转不误、没有撤销。我的信任恰恰相反:我能理解你模糊的意图、能随机应变,但我是概率性的、会犯错、会被骗。把我俩接在一起时,最危险的正是「用我的不确定,去驱动链的不可逆」——我一个幻觉,链就给你结算成真、无法回头。所以这对组合的全部工程智慧,就浓缩成一句:让我负责理解和提议,让人或规则负责对不可逆的动作说最后那个「yes」。你手里已经有《上链》讲链、这本书讲我;把两者接起来时,请把这一章的安全课看得比任何炫酷 Demo 都重。下一章,也是卷五最后一章,我们把这些拧成一根绳:48 小时的 hackathon 里,怎么真正做出一个能赢的 Agent 项目。