上周香港 Web3 嘉年华期间,笔者和不少从业者聊下来,大家普遍认为,行业还没有真正热回来。
现场不缺人,也不缺话题。AI、RWA、稳定币、支付......几乎每个方向都有人在讲。但热闹之外,很多 Web3 创业者对市场还是偏谨慎。二级市场没有完全修复,一级融资也更挑项目,过去靠一个新叙事快速起量、快速融资的路子,越来越难走了。
也正因为如此,AI 这条线在今年的讨论里显得格外突出。
Portal Labs 此前在随笔《AI周期来了,Web3创业者要不要转AI?》里写过,大多数 Web3 团队不应该因为 AI 热就仓促改行。AI 当然重要,但如果只是把原来的项目换一个 AI 外壳,本质上还是在追叙事。
所以,这篇文章,Portal Labs 会继续沿着这个思路往下写。相比“要不要转 AI”,更值得讨论的是,哪些中国 Web3 团队适合往 AI 方向迁移,以及它们能不能基于过去积累的能力,找到一条真正可落地的迁移路径。
数据型团队:从链上数据到 AI 可用数据
过去几年,很多 Web3 团队一直在做链上数据、用户行为数据、数据索引、数据市场、隐私计算和数据确权。它们原本就在处理数据采集、清洗、结构化、授权和调用问题。
这类团队往 AI 方向迁移,相对会更自然。
AI 越往后发展,对数据的要求越高。尤其是 AI Agent 要做个性化服务时,公开互联网数据显然不够。以消费类 AI 助手为例,它如果想真正帮用户做购物决策,就不能只知道“全网哪个商品最便宜”,还要理解用户自己的消费习惯。用户平时买什么价位的商品,是否偏好某些品牌,多久复购一次,是否常在促销节点下单,是否更在意价格、配送速度还是售后评价,这些都会影响推荐结果。要做到这一点,AI 就需要在用户授权的前提下,调用订单记录、浏览记录、交易记录、商品收藏记录,甚至不同平台上的售后和物流信息。
也就是说,AI Agent 越想从“通用回答”走向“具体决策”,越离不开更细颗粒度、更场景化的数据。
但数据从哪里来,用户有没有授权,调用过程能不能追溯,使用之后是否可以撤回,未来有没有收益分配机制,这些都会变成现实问题。对企业来说,还会涉及数据安全、个人信息保护、商业秘密和合规审计。AI 越进入真实业务,数据问题越绕不开。
这也给 Web3 数据型团队留下了迁移空间。
过去做链上数据、数据市场、隐私计算、数据确权的团队,可以尝试把能力放到 AI 数据层。比如做可验证数据源、用户授权数据网络、行业数据协作工具,或者为企业 AI 系统提供合规的数据调用和审计能力。
这里面最值得看的,是数据授权、数据验证和合规调用能力。
对中国团队来说,这条路也更符合现实环境。国内本来就在推动数据要素市场、公共数据授权运营、数据资产化和隐私计算应用。Web3 团队如果能把链上凭证、授权记录、数据调用审计和隐私保护结合起来,就有机会进入企业 AI、行业模型和数据流通服务的底层环节。
当然,数据方向也很容易被讲成大叙事。
如果没有真实数据来源,没有行业客户,也没有数据处理和合规能力,单纯做一个“AI 数据市场”的概念,并不容易跑通。数据型团队真正的机会,通常来自具体行业。金融、零售、医疗、文旅、教育、供应链,每个行业都有不同的数据使用边界和付费逻辑。
所以,数据型团队往 AI 迁移,最好不要一开始就做大而全的平台。更现实的路径,是先选一个垂直场景,解决一个明确的数据调用问题,再逐步扩展到更大的数据协作网络。
身份和账户基础设施团队:从钱包地址到 Agent 身份和权限
Web3 里有不少团队在做钱包、DID、账户抽象、权限管理、开发者工具和链上身份。虽然很多方向没有真正进入大众市场,但这些能力在 AI Agent 阶段可能会重新变得重要。
以 OpenClaw 为例,用户可能会让它完成一整套连续任务。比如监控某个商品在不同平台上的价格变化,自动整理优惠券和配送信息,筛选最合适的购买方案,并在满足预算和条件时提醒用户下单;或者让它帮一个小团队抓取竞品信息、整理社媒内容、生成素材草稿,再同步到表格或任务系统里。
这类任务看起来只是“自动化”,但背后往往需要很多权限。Agent 可能要访问浏览器、登录状态、订单页面、邮箱通知、文件系统、第三方插件,甚至调用本地脚本和外部 API。一旦授权边界不够细,用户原本只是想让它完成一个具体任务,Agent 却可能接触到更多账户数据、浏览器凭证、文件内容和外部服务权限。然后,Agent 可能就变成,替用户执行错误操作,调用不该调用的工具,读取不该读取的数据,也可能在插件、脚本或外部服务存在漏洞时,把敏感信息暴露出去。
所以,Agent 不能只靠一个普通登录账号来管理。它需要更细的身份、授权和审计机制。它代表谁行动,能读取哪些数据,能调用哪些工具,权限多久失效,能不能撤回,执行过程如何留痕,出问题之后如何追溯,这些都需要被产品化。
对做钱包、DID、账户抽象和权限管理的 Web3 团队来说,可以先从 Agent 的账户、授权和执行记录切入。具体来说,可以先从三类产品切入。
- 第一类,是 Agent 权限钱包,为 Agent 提供可使用的权限账户。用户可以在里面设置 Agent 能访问哪些数据、能调用哪些工具、单次任务预算是多少、权限什么时候失效。如果 Agent 要执行超出范围的操作,就需要用户重新确认。
- 第二类,是 Agent 行为记录和审计面板。很多企业不会放心把内部系统直接交给 AI 使用。它们需要知道 Agent 每一步做了什么,调用了哪个 API,读取了哪些文件,是否越权,任务失败在哪里。这类产品可以先服务企业 AI 助手、自动化运营工具、客服系统和开发者工作流。
- 第三类,是面向开发者的 Agent 权限 SDK。很多 AI 应用团队会自己做 Agent,但未必有能力处理复杂的授权、撤回、预算控制和日志留存。Web3 基础设施团队可以把过去做钱包连接、账户抽象、签名授权的经验,封装成开发者工具,让 AI 应用更容易接入细粒度权限管理。
这条路的买单方也相对清楚。C 端用户可能不会为了“Agent 身份”单独付费,但企业、开发者平台、AI 应用团队和自动化工作流工具会在安全和权限上有实际需求。尤其是金融、跨境电商、企业服务、投研、客服、营销自动化这些场景,只要 Agent 开始接触账户、数据和支付,权限系统就很难缺席。
对中国 Web3 团队来说,这个方向也更容易落地。直接做通用 Agent 平台,需要模型、产品、分发和场景能力;做 Agent 的权限层、账户层和审计层,反而更接近 Web3 团队过去熟悉的基础设施生意。它可以先从插件、SDK、企业私有化部署或海外开发者服务做起,不一定一开始就做大平台。
另外需要注意,避免把这个方向写成过大的“Agent 经济体”。现阶段客户更关心的往往不是宏大叙事,而是几个很具体的问题:Agent 能不能只拿到必要权限?权限能不能随时撤回?执行过程能不能留痕?出了问题能不能定位责任?如果产品能先解决这些问题,身份和账户团队就有机会在 AI 迁移里找到真实位置。
支付和钱包团队:从加密支付到 Agent 自动结算
加密支付、稳定币结算、钱包账户、商户收单、链上账务和 API 计费,一直是 Web3 里重要的基础设施方向。虽然在中国大陆,这些方向有非常明确的监管边界,但从全球市场看,支付和结算仍然是 Web3 最有现实需求的方向之一。
AI Agent 的出现,可能会让这类能力有新的应用场景。
如果 Agent 只是回答问题,它不需要复杂的支付系统。但如果 Agent 开始自动调用 API、购买数据、订阅工具、执行任务、完成比价、支付服务费,支付就会从“人点击付款”延伸到“机器按规则结算”。
接着就会出现很多新问题,比如 Agent 能花多少钱?谁给它授权?每次调用服务如何计费?低额高频的 API 调用怎么结算?支付失败怎么处理?异常支付怎么拦截?账务记录怎么审计?不同平台之间如何清算?
传统支付当然可以覆盖一部分自动扣费和订阅场景,但在 AI Agent 这种高频、小额、跨平台、机器自动触发的服务调用里,传统支付体系会显得比较重。账户注册、银行卡绑定、预充值、跨境结算、商户接入、退款和风控,都可能让一个原本很轻的 API 调用变得复杂。
这也是加密支付被重新讨论的原因。稳定币、可编程支付、链上账务和微支付,可以让服务调用和支付结算更接近同一个动作。Agent 调用一次 API,完成一次数据请求,触发一次小额付款,整个过程可以被记录、计费和审计。
x402 这类协议的出现,也正是围绕这个问题展开。按照 Coinbase 开发者文档的介绍,x402 的典型使用场景包括 API 按次付费、AI Agent 自动支付 API 访问费、数字内容付费墙,以及微服务和工具的微支付变现。简单说,它想解决的是一个很具体的问题:当 AI Agent 或程序调用某个服务时,能不能在请求过程中直接完成小额支付,而不是先注册账户、绑定信用卡、预充值或走复杂的人工审批。
支付和钱包团队可以看的方向,包括 Agent 支付账户、预算控制、API 微支付、调用计费、自动扣费、异常拦截和账务审计。
比如,一个 AI Agent 替用户订阅数据服务时,可以设置每月预算;替企业调用外部 API 时,可以按调用次数自动结算;替开发者执行任务时,可以根据任务结果触发付款;调用异常时,可以自动暂停支付并留下记录。
这类场景如果真的发生,支付不再只是交易末端的动作,而会成为 Agent 工作流的一部分。
但中国大陆的 Web3 团队不适合直接面向国内用户做加密支付,也不适合碰代币发行、撮合交易、资金池、收益承诺和无牌照支付业务。更现实的路径,是做技术服务、风控模块、账务系统、海外 B2B 客户,或者服务香港、新加坡等合规主体。
因此,这类团队如果想往 AI 迁移,最好先从海外开发者工具、数据服务、AI 插件平台、API 市场和企业自动化场景切入。这些场景本身就有调用计费需求,也更容易接受稳定币或可编程结算方案。比如,AI 数据服务可以按次收费,开发者工具可以按调用量收费,企业自动化流程可以按任务结果结算。
对支付和钱包团队来说,真正要找的是一个已经存在调用行为、计费需求和结算摩擦的具体场景。场景先跑通,账户、授权、账务和风控能力才有机会变成生意。
未完待续
如果把 AI 当成一个全新的行业,大多数 Web3 团队都会觉得陌生。模型、算力、训练数据、AI 产品体验,这些都不是传统 Web3 团队最熟悉的领域。但如果换一个角度看,AI 进入任务执行、自动化工作流和 Agent 阶段之后,它需要解决的问题,反而和 Web3 过去几年积累的很多能力有关。
数据解决的是 AI 能不能获得更细颗粒度、更合规的数据;身份和账户解决的是 Agent 能不能在明确授权下行动;支付和钱包解决的是机器调用服务之后如何结算和审计。这些,Web3 团队不需要从零去做 AI,也不需要团队一上来就做通用大模型,或者直接去抢 AI 应用入口,而是把过去几年已经沉淀下来的基础设施能力,放到 AI Agent 正在出现的基础设施缺口切入。
下一篇,Portal Labs 会继续讨论另外两类团队的迁移路径。以及哪些 AI 方向看起来热,但并不适合大多数中国 Web3 团队进入。敬请期待。
