AI + DeFi 的真正机会在哪里

讨论 AI + DeFi 时，最容易想到的是一个自动寻找机会、配置资金和执行交易的 Agent。

这也是最容易制造演示效果的方向：用户说一句目标，Agent 分析市场，然后调用钱包或协议完成操作。

但在当时的研究里，我得到的结论恰好相反。AI + DeFi 最值得先做的，不是“AI 帮你赚钱”，而是：

当 AI 即将碰钱时，谁负责确认它碰的是正确对象，并且没有超出允许范围？

DeFi 天然适合被机器调用

与传统金融相比，DeFi 的状态和动作更容易被软件直接访问：合约接口公开，资产和仓位可以链上读取，协议提供 SDK、API 或 RPC，多个动作还能被组合。

一个 Agent 理论上可以完成完整循环：

读取市场和仓位
-> 比较协议
-> 选择动作
-> 构造调用
-> 请求签名或自动执行
-> 监控结果

MCP 等工具协议降低了模型调用外部工具的接入成本，x402 等支付机制则试图让机器能够按次购买 API。它们让“Agent 使用金融工具”更容易被产品化。

但这些机制只回答了 Agent 怎样调用和付费，没有回答它为什么应该调用、目标是否正确，以及一次错误最多能损失多少。

接口更通用，不等于行为更可靠。

能行动以后，模型错误不再只是错误答案

一个聊天模型给出错误解释，用户可能得到一段坏信息。一个拥有钱包工具的 Agent 误解指令，结果可能是错误授权、错误合约调用、重复支付或者真实资产损失。

风险来源不只包括模型幻觉：

• 网页或工具返回恶意指令。
• Agent 解析了假冒协议或钓鱼域名。
• 合约地址正确，但 spender 或 recipient 不符合预期。
• 重试机制导致重复交易或支付。
• 用户给出的目标模糊，Agent 自行补全了关键约束。
• 工具权限大于完成任务所需权限。

当 Agent 从“建议者”变成“行动者”，产品的安全边界也从内容质量升级成金融基础设施。

这使执行前检查不再只是一个友好功能，而可能成为系统中必须存在的控制点。

Preflight Layer 的产品定义

这一阶段提出的空位，是 Agent-readable DeFi Preflight Layer。

在 Agent 执行之前，先回答几个确定性问题：

目标实体是谁？
URL 是否匹配官方路径？
合约是否与该协议有关？
spender 是否符合这个动作的预期？
是否命中已知风险信号？
证据来自哪里？
是否必须让人确认？

它不负责判断某个 token 会不会上涨，也不替用户决定该把多少资金放进哪个协议。

它负责把一个模糊的 Agent 意图，转化成可检查的实体、路径、合约、权限和证据。

输出不仅是一个 allow 或 deny，还应该生成可分享、可审计的 evidence page，让人类、社区和后续系统能够复核为什么做出这个判断。

这不是另一个自动交易 Agent

当时明确排除的方向包括自动交易、自动理财、用户资金托管和未经确认的签名。

原因不是这些功能永远不能做，而是它们会把产品直接推入最昂贵的安全和责任范围。一个早期团队如果同时负责策略判断、密钥权限和交易执行，任何一层错误都会落到同一个品牌上。

Preflight 的克制在于：它站在执行之前，提供结构化上下文和风险证据，把最终授权保留给用户或另一个权限系统。

但这种克制也有限制。仅仅给 Agent 返回一份风险说明，并不能阻止它绕过结果。真正的安全最终需要把策略约束、权限限制和签名控制落实到执行路径中。

因此，Preflight 可以成为起点，却不能被误解成“调用一次安全 API，Agent 就安全了”。

MCP 和 x402 不是需求证明

新的协议和支付机制很容易制造一种市场已经到来的感觉。

MCP 可以让 Agent 调用工具，x402 可以让机器为调用付费。但开发者是否需要一个 DeFi Preflight 产品，仍然取决于三个更普通的问题：

1. 他们是否真的在运行会执行 DeFi 动作的 Agent？
2. 现有钱包、安全 API 和内部规则是否已经足够？
3. 他们是否愿意把 Preflight 放进生产 workflow 并付费？

一次 MCP demo、几次测试调用或一笔 x402 微支付，都不能证明产品具有持续需求。

真正有价值的验证是：外部团队愿意在 before_execute 流程中依赖它，检查失败会阻止或升级动作，并且团队愿意为可靠性承担预算。

对 Build-to-Sell 的吸引力

从资产角度看，Agent Preflight 比单纯安全页面更容易形成完整收购叙事：域名、机器可读 registry、MCP/API 使用、evidence graph、协议关系和真实调用记录可以被一起转移。

钱包、安全公司、数据平台或 Agent framework 理论上都可能从这套资产中获得协同价值。

但“可能的战略买家很多”仍然不是买家需求。只有当真实团队接入、持续调用并且产生难以自建的数据时，这套叙事才从故事变成资产。

否则，Agent-ready 只是给原有 Preflight 方案增加了一层更热门的包装。

第一阶段应该验证什么

最小验证不应该是开发一个会自动交易的 Agent，而应该是让少量外部 Agent、bot 或协议团队接入一个非常窄的执行前检查：

输入：URL、协议、合约、spender 和预期动作
输出：实体匹配、官方路径、已知风险、证据和是否需要人工确认

需要观察的行为包括：

• 客户是否把它放进真实 workflow，而不是只看 demo。
• Preflight 是否改变了执行结果。
• 哪些输出是现有工具没有提供的。
• Registry 是否随着客户增加而复用。
• 客户是否愿意为持续更新和可靠性付费。

如果大家只说概念有趣，却不愿集成、依赖或付费，就应该停止借 Agent 叙事扩大产品。

这轮探索保留了什么

AI + DeFi 的结合并不需要从“自主投资经理”开始。

更基础也更可信的机会是：让金融 Agent 的每个动作具有明确实体、可验证路径、最小权限、风险证据和人工升级条件。

这一轮保留了 Agent-readable registry、结构化 Preflight、公开证据页和 before_execute 控制点；放弃的是把自动赚钱、自动签名和 Agent 热度当作第一阶段产品需求。

接下来的问题重新回到人类用户：除了行动前检查，defi.io 是否可以成为一个用户日常保存协议、入口、仓位和 Agent 权限的可信工作台？

下一篇，我会复盘 Personal DeFi Home 这个假设，以及它为什么比“统一入口”更个人化，也可能更难形成高频需求。