AI Agent 的现状解析：应用路径、基础设施与区块链结合-web3.0-PHP中文网

上周集中研究了一下 ai agent，前天又参加了 ai16z 在北京的活动，核心想法很直接：看清楚 ai agent 现在到底能做什么，以及它接下来可能会走向哪里。

一文详细了解AI Agent 的现状与未来

顺带一提，我原本还想让 AI 生成一张对应的配图，结果发现它并不能很好理解“藏”这个表达。

AI Agent 框架的基本工作方式

现阶段的 AI Agent 框架，本质上更像一层“连接器”或“粘合层”。它一端连接各类客户端入口，例如 Twitter、Discord、Telegram 等社交或 IM 系统；另一端连接不同插件能力，包括多链能力、外部工具和业务接口。同时，框架本身通常还会提供一组基础能力，例如记忆存储、会话隔离、上下文生成等，再继续向后对接各类 AI 平台接口。

AI Agent 框架如何与应用和业务场景结合

从去年 AI 热潮持续升温以来，市场上出现了大量平台和工具，但真正关键的问题始终没有变：AI 如何进入实际应用，如何和业务场景真正结合。

围绕这个问题，行业已经给出过多种路径。有的平台采用插件模式，有的尝试工作流模型，也有传统应用选择在原有产品中直接嵌入 AI 能力。但归根结底，核心仍然是两个问题：

应用的交互入口在哪里？
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 的期待，似乎主要分成两类。

oracle知识库

oracle知识库下载

下载

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

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

从当前市场进展来看，行业主要还在探索第一种方向。这个方向可以理解为“服务的 Agent 化”：未来很多服务可能不再依赖传统 App 界面，而是以 AI Agent 的形式对外提供能力，并呈现出更强的拟人化特征。

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

AI Agent 对基础设施的要求

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

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

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

AI Agent 与区块链的结合方向

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

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

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

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

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