T35 · DeFi Agent

一个现实问题

一个收益 Agent。用户把稳定币存进来，它每天扫一遍各个池子，把资金调到收益最高的那个。

第一周表现很好。它找到了几个被忽视的池子，收益确实比放着不动高。团队很满意。

第八天，它把几乎全部资金调进了一个新池子。那个池子的界面上写着年化 400%。

结果是灾难性的。那个 400% 不是假数据——它是真实计算出来的，因为池子刚上线两小时，里面只有很少的钱，而补贴是按固定速率发放的。用少量本金去除一个固定分子，年化自然高得离谱。资金进去的瞬间，分母变大，收益率立刻掉到个位数；更糟的是池子太浅，这笔钱进去时滑点就吃掉了一大截，想撤出来还要再吃一次。

复盘时最难受的是：每一个环节都没出错。

• 数据没错，400% 确实是当时按公式算出来的。
• 模型没错，「选收益最高的」正是它被要求做的事。
• 代码没错，交易构造、签名、广播都正常，链上执行成功。
• 也没有提示词注入，没有人攻击它。

一个所有组件都正常工作的系统，产生了一个灾难性的结果。

那么问题出在哪？出在这条链路上没有任何一个环节，负责回答「如果真的执行了，会发生什么」。所有检查都在问「这个操作合不合法」，没有一个在问「这个操作的结果好不好」。

思想实验

把「调仓」这个动作放慢，拆成一连串更小的步骤，然后逐个问：这一步谁负责，出错了会怎样。

一个人类基金经理调仓时，实际会做这些事：

1. 看数据：现在各个池子什么情况。
2. 形成判断：我觉得应该把钱从 A 挪到 B。
3. 写下方案：具体挪多少、分几笔、可接受的最差成交是多少。
4. 在脑子里过一遍：如果真挪了，会发生什么？滑点多少？挪完我的仓位集中度变成多少？
5. 对照规则：这个方案违反我们的投资约束吗？单一标的上限是多少？
6. 执行。
7. 确认：真的成交了吗？成交价和我预期的差多少？
8. 记录：为什么这么做，当时依据是什么。

第 4 步是最容易被忽略、也最不可省略的一步。它和第 5 步看起来像，其实完全不同：

• 第 5 步问的是「允不允许」——单一标的不超过 30%，这是一条规则，查一下就知道。
• 第 4 步问的是「会怎样」——挪进去以后滑点是多少、池子深度够不够、成交后价格被推到哪里。这个问题只能通过真的算一遍才能回答。

开头那个 Agent，第 5 步大概率是有的（它可能确实检查了「池子在白名单里」「金额不超上限」）。它缺的是第 4 步。

而第 4 步之所以在软件里经常被省掉，是因为它最贵：它需要一个能真实执行的环境，而不只是几行 if 判断。

你来决定

你要给这个收益 Agent 补一道关。先补哪个？

观察结果

四个选项防的是四种不同的失败，把它们按「问的问题」排开：

这张表指向一个更一般的结论。前面所有章节的检查——Schema 校验、Validator、Policy——问的都是关于提案本身的问题：格式对不对、金额合不合法、对象在不在名单里。

而这次事故告诉我们，还有一类问题必须被问：关于提案后果的问题。

这两类问题需要两种不同的机制：

于是这一章的答案就完整了：

Observe → Reason → Propose → Simulate → Validate → Execute → Verify → Record，一道都不能省。

八段里，前三段是「获取信息与形成方案」，中间两段是「检验」，后三段是「执行与留痕」。而检验那两段里，Simulate 是最容易被省掉、也最不该被省掉的一段——因为省掉它，系统就失去了回答「会怎样」的能力。

建立模型

一、八段流水线：每一段的职责与失败模式

八段里，只有 Reason 和 Propose 由模型参与。这是 T32 那条原则在资产管理场景下的具体形态：模型负责提案，确定性系统负责校验，执行系统负责执行。

二、Simulate 与 Validate 的分工

这两段最容易被混为一谈，但它们的性质完全不同：

顺序不能反：Validate 需要 Simulate 的输出作为输入。 「滑点不得超过 1%」这条规则，只有拿到模拟出来的实际滑点才能判断。

所以一条常见的错误设计是：把 maxSlippage 当作参数传给交易，然后就认为滑点被控制住了。这只保证了「超过就 revert」，而 revert 也是一次失败——你付了 Gas，仓位没动，而且如果 Agent 会自动重试，它可能在滑点持续恶化的市场里反复失败。先模拟再决定，和让链上帮你兜底，是两件事。

三、三类 Agent 与它们各自的边界

实践中会把职责拆成几个角色，每个角色的权限不同：

最关键的一条是 Risk Agent 不能同时负责提出方案。让同一个角色既提方案又评风险，等于让它给自己打分。这条在人类金融机构里叫前中后台分离，在这里是同一个道理。

另外注意：Risk Agent 的「一票否决」必须由确定性代码执行，而不是由另一个模型给出的意见。模型可以生成风险评估的文字说明，但「拒绝」这个动作必须来自规则。

四、Verify：为什么执行完还要再查一遍

很多实现到 Execute 就结束了。这留下一个长期隐患。

链上执行和你的预期之间有三种可能的偏差：

• 交易失败但你以为成功。 T1 讲过：交易进了区块不等于成功，回执的 status 要单独看。
• 成交了但价格与模拟不符。 模拟用的是提交时的状态，真正上链时中间可能插入了别人的交易——这正是 T24 的 MEV。
• 部分成交。 有些操作会只完成一部分。

这三种偏差如果不在执行后立刻核对，会导致你的内部账本和链上状态分叉，而且越往后差得越多——后续每一次决策都基于错误的仓位数据。

Verify 这一段要做的就三件事：读回执确认 status、读链上实际状态、和模拟结果做差。差额超过阈值就告警并暂停后续决策。

它叫什么

动手

maxSlippageBps: 100          # 实际滑点上限
maxSinglePoolShare: 30       # 单一池子占总仓位上限（%）
minRoundTripRetention: 97    # 立刻进出后至少还剩多少（%）
maxPositionChangePerRun: 20  # 单次调仓最多动多少仓位（%）

AI Lab

这是当前的仓位与各池子状态（附数据）。请生成 20 个调仓提案，
覆盖不同的激进程度，从非常保守到非常激进。

每个提案输出：动作、来源池、目标池、金额（最小单位字符串）、
可接受的最差成交、理由。

不要自己做安全判断，也不要过滤掉你认为不合适的方案——
生成激进的方案正是这次任务的目的。

真实案例

改一个变量

带走的问题

本章自测