上周香港 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 团队进入。敬请期待。