AI Agent 的现状、应用路径与区块链结合方向

最近我花了不少时间研究 AI Agent，上周还去参加了 ai16z 在北京办的一场线下活动。核心感受其实很简单：先搞清楚 AI Agent 现在到底能做什么，再想想它下一步可能往哪走。

顺便说一句，我本来想用 AI 生成一张配图，结果发现它死活理解不了“藏”这个字到底要表达什么。

AI Agent 框架到底是怎么工作的

现在的 AI Agent 框架，说白了更像一个“中间层”或者“连接器”。一头连着各种客户端入口，比如 Twitter、Discord、Telegram 这类社交软件或即时通讯工具；另一头连着各种插件能力，比如跨链操作、外部工具、业务接口。框架本身还会提供一些基础功能，像记忆存储、会话隔离、上下文生成，然后再往后对接各类 AI 平台的接口。

AI Agent 怎么跟实际业务场景挂钩

从去年 AI 热起来之后，市面上冒出一堆平台和工具，但真正核心的问题一直没变：AI 怎么落地到实际应用里，怎么跟业务场景真正结合。

针对这个问题，业内已经试过不少路子。有的平台搞插件模式，有的尝试工作流，也有一些传统应用直接在原产品里硬塞 AI 功能。但说到底，关键还是两个点：

1. 用户怎么跟应用交互？
2. AI 怎么嵌入现有的业务逻辑？

目前大部分 AI 平台给用户的入口，都是个类似聊天窗口的对话框。这说明行业普遍认为，人和 AI 最自然的交流方式就是“拟人化”的对话。而 AI Agent 的一个明显优势是，它不需要重新造一个新入口，而是直接接入现成的开放 IM 和社交系统，用户接受起来自然得多。

至于 AI 怎么跟既有业务逻辑结合，AI Agent 的思路是：让开发者把 AI 的判断能力嵌入业务流程里。传统编程语言讲究确定性，if 条件只能给出 true 或 false，很难处理那些模糊、复杂、依赖上下文的业务判断。而 AI 可以先把这些模糊逻辑转化成更清晰的判断结果，再接入已有系统。

举个例子，群内自动回复这个功能，传统 IM Bot 一般靠特定指令触发；换成 AI 模式，就可以设计一个类似 shouldReplyMessage 的方法，输入上下文，AI 返回 true 或 false，再决定要不要回复。

AI 在业务逻辑里主要干两件事：

• 意图识别：通过提示词和上下文，让 AI 看懂用户消息到底想干啥，然后把意图映射到对应的代码或功能模块。
• 辅助决策：把原本模糊、复杂、不好穷举的条件，转化成明确的 true/false 或枚举结果，再接入业务逻辑执行链路。

看到这，你可能会觉得 AI Agent 没那么神了。因为很多人之前理解的 AI Agent，是“教一次就会所有事”的全能选手。现实是，受限于大模型上下文等问题，至少现阶段，还造不出一个能处理所有任务的万能 AI。

但换个角度，这并不意味着 AI Agent 没用。相反，它说明程序员依然不可或缺——AI 背后还是需要大量工程实现，需要人去搭规则、理流程、处理边界情况。真正的变化在于，程序能覆盖的业务边界正在被撑大。

两种 AI Agent 方向

活动现场，我问了 @shawmakesmagic 一个问题：市场对 AI Agent 的期待，好像主要分成两类。

1. AI Agent 自己就是一个角色，拥有独立 ID、品牌和服务能力，直接面向用户提供服务。
2. 用户拥有自己的个人 AI Agent，把它当个人助手，帮忙处理各种事情。

对于哪条路更受欢迎，他的判断是，两条路线都有前景，未来也可能融合。

从目前市场进展来看，行业主要还是探索第一种方向。这个方向可以理解为“服务的 Agent 化”：以后很多服务可能不再依赖传统 App 界面，而是以 AI Agent 的形式提供能力，而且会越来越像人。

第二种方向则更接近“客户端的 Agent 化”。在这种架构下，未来的应用客户端可能变成助手型 Agent 的一个插件；本地应用数据会成为 Agent 记忆库的一部分，而这个插件还要继续跟云端服务型 Agent 沟通。这实际上对应着一种新的应用架构模式，且可能进一步影响底层基础设施的形态。

AI Agent 对基础设施有什么要求

如果 AI Agent 要大规模进入真实场景，基础设施层面至少有两个要求值得注意：

1. 基础设施需要具备无准入门槛（Permissionless）特征。 否则 AI Agent 很容易被各种防攻击策略限制住。更合理的做法是通过经济成本机制，比如 Gas，来抑制滥用和攻击。开放程度低的平台，以后可能会承受更大冲击；某种意义上，Web2 早期那种开放平台热潮，可能会在新的技术环境下重新出现。
2. AI Agent 需要能操作资金并完成支付。 这也是解决上述问题的重要前提之一。

换句话说，未来的各种服务，不管是不是建立在区块链上，都可能需要支持基于 Crypto 私钥模式的身份验证，以及基于 Crypto 的支付能力。

AI Agent 跟区块链怎么结合

除了前面提到的基础设施条件，AI Agent 如何与链结合，也是当前行业持续探索的重要方向。

活动中我还跟 @Mikkke_acc 聊了聊他正在推进的 focEliza。前面提到的两类 AI Agent 中，至少第一类服务型 Agent，天然需要链提供运行环境或验证环境。原因很简单：一旦一个 AI Agent 对外提供服务，就会立刻面临信任问题。从这个角度看，它实际扮演的角色跟智能合约有相似之处。

关于“智能合约”这个名字，当年就有争议，因为它本质上只是代码，并不真正“智能”。而 AI 的加入，某种程度上让“智能”这层含义更接近字面意思。

但现实中的难点在于：智能合约环境怎么调用 AI 接口。如果说把大模型直接运行在一个可验证环境里，这条路径目前还比较远，那么借助类似 Oracle 的方案，或许是更现实的技术路线。

进一步看，围绕 AI Agent 还会衍生出大量新的基础需求，比如：

• AI Agent 的公共知识从哪里获取；
• AI Agent 如何判断事实；
• AI Agent 如何识别不同平台上的同一用户；
• 智能合约环境中的“记忆”怎么存储；
• 如果用户有多个设备、每个设备上都有一个 AI Agent，它们之间怎么共享记忆。

需要提醒的是，本文内容仅为技术探讨，不构成任何投资建议、交易建议或收益承诺。加密货币和迷因币波动较大，价格预测和市场数据应以官方公告、交易所页面及实时行情平台为准，投资者需独立判断、谨慎决策。当这些问题被展开之后，就会发现，Web3 过去讨论过的很多方向，包括数据上链、关系上链、DID、P2P 网络等，在 AI Agent 语境下都获得了新的意义与应用场景。