T36 · Autonomous Onchain Economy
一个能自己赚钱和花钱的系统，边界在哪里？
- 练习的能力
- AI LiteracyBuilderSystem Thinking
- 动手
- 交付毕业项目的 Agent：有钱包、有预算、有策略、有风险引擎、有一键停机与完整日志。
- AI Lab
- 让 AI 给你的 Agent 写一份事故预案，自己演练一次：模型失控时，多久能停住它。
一个现实问题
把前面几章拼起来，你手上现在有这么一个东西。
它有一个钱包（T34）。它会用工具查链上数据（T33）。它的每一个动作都要走完提案、校验、模拟、执行、核对的流水线（T32、T35）。它买数据要花钱，而它把研究结论卖给用户，能收到钱。
某个月，它的收入第一次超过了支出。
这时候有人在会上问了一句：它现在算什么？
这不是一个哲学问题，是四个非常具体的工程与法律问题：
- 钱包里的钱是谁的？公司的资产，还是「它的」资产？
- 谁能停掉它？一个人？两个人？需要多久？
- 如果它明天把钱亏光了，谁赔？
- 如果它做的某件事违反了某地的规定，谁负责？
会上没人能答上来。于是有人提议：先让它跑着，等规模大一点再想这些。
这个提议是这一章要反对的。 因为上面四个问题的答案不是等出来的，它们必须在部署之前就写死在系统里——尤其是第二个。一个你不知道怎么停的系统，规模越大越停不下来。
思想实验
把这个 Agent 当成一家公司，一家只有一名员工、而这名员工是软件的公司。
这个类比很有用，因为公司这个东西存在了几百年，它要回答的问题早就被回答过。逐条对照：
| 公司要回答 | 怎么回答的 | 你的 Agent 对应什么 |
|---|---|---|
| 谁拥有它 | 股权登记 | 钱包私钥或智能账户的控制权在谁手里 |
| 谁能叫停它 | 董事会、法定代表人 | 停机开关由谁持有，需要几个人 |
| 亏了谁赔 | 有限责任 | 没有对应物——链上没有有限责任 |
| 违法谁负责 | 法人 + 实际控制人 | 部署它的人 |
| 怎么证明它做过什么 | 会计账簿、审计 | 审计日志与链上记录 |
第三行是最关键的差异。
公司制度最重要的发明之一是有限责任：出资人的损失以出资额为上限。它让人们敢于承担风险，因为下行是封顶的。
你的 Agent 没有这个。它的钱包里放多少钱，理论上就能亏多少；如果它有授权额度，能亏的还不止钱包里那些。没有人给你封顶，你必须自己封。
所以「自治」这个词在这里需要被拆开。它不是一个开关，而是至少三个独立的问题：
- 决策自治：它能不能自己决定做什么？
- 资金自治：它能不能自己决定花多少？
- 存续自治：它能不能拒绝被关掉？
前两个可以给，而且给了才有价值。第三个永远不能给。 一个能拒绝被关掉的系统，不叫自治，叫失控。
你来决定
你要给这个 Agent 定一个自治边界，写进配置。选哪个？
观察结果
四个选项不是四选一，是一条自治度的连续谱。每往上一级，需要配套的约束就多一层：
| 自治度 | 它能做什么 | 必须配套什么 | 最大损失 |
|---|---|---|---|
| L0 只读 | 查询、分析、给建议 | 来源留痕 | 0 |
| L1 提案 | 生成结构化提案，人来执行 | Schema、Validator | 0 |
| L2 预算内执行 | 额度内自主执行 | 全部十层 + 会话密钥 + 停机 | 额度 + 未撤销授权 |
| L3 自负盈亏 | 有收入、自己决定支出优先级 | L2 全部 + 收支账本 + 对账 | 额度 + 收入再投入部分 |
这张表和 T32 的 AI 能力分级是同一条轴，只是这里把它落到了资金上。规则也一样：
你在哪一级，取决于你能验证到哪一级。
而无论在哪一级，有一条是恒定的：
自治不等于无约束。一个自治系统的价值，取决于它的约束设计有多好。
这句话听起来像口号，但它有一个非常具体的检验方式：把你的约束配置给别人看，他能不能算出你的最大损失。 算不出来，说明你的系统还没有边界。
建立模型
一、Agent Treasury：收支两条线
一旦 Agent 有了收入，它就从「一个花钱的工具」变成了「一个有资产负债表的东西」。这时候需要把账分开记：
| 收入侧 | 支出侧 | |
|---|---|---|
| 来源 | 服务费、任务佣金 | 数据、算力、Gas、模型调用 |
| 记账时点 | 链上确认收款后 | 链上确认付款后 |
| 归属 | 按任务、按用户 | 按任务、按资源类型 |
| 对账依据 | 交易哈希 | 交易哈希 |
三条实践规则：
第一，收入不要自动进入可支配预算。 赚到的钱默认进入一个单独的余额，需要一次显式操作（人工或定期规则）才转入运营预算。否则一个收入异常（比如收到一笔误转）会直接抬高它的支出上限。
第二，Gas 要单独计量。 它不属于任何一个业务任务，但它是真实成本。不单独记，你会发现毛利算出来是正的，实际余额却在减少。
第三，以交易哈希为幂等键。 这是 T16 的幂等入库在这里的直接应用：一笔收付无论回调几次，账本只记一次。
二、停机开关：四个要点
这是整章最不能妥协的部分。一个停机开关要满足四条，缺一条就不算数：
- 触发路径不经过模型
- 默认拒绝
- 状态持久化
- 外部可触发
触发路径不经过模型。 模型不能参与「要不要停」的判断，否则一个被注入或失控的模型可以阻止自己被停掉。停机指令必须走一条模型完全碰不到的通道。
默认拒绝。 停机状态下，所有执行请求一律立即拒绝，而不是排队等待。排队会导致恢复瞬间涌出一批积压操作——那往往比不停机更糟。
状态持久化。 重启之后仍然是停机，必须人工显式恢复。一个「重启就自动恢复运行」的停机开关，在最需要它的时候（进程崩溃重启）会自己失效。
外部可触发。 运维、监控告警、一个 HTTP 接口都能触发。不要只留一个需要登录内部系统才能按的按钮。
还要加一条演练要求：停机开关必须定期演练，并记录「从决定停机到确认已停」的实际耗时。没演练过的开关，和不存在的开关，你无法区分——这和 T30 的「故意破坏一条不变量」是同一个道理。
三、责任矩阵：四个问题的答案要写下来
回到开头那四个问题。它们的答案应该是一份文档，而不是一次会议讨论：
| 问题 | 要写明 |
|---|---|
| 资产归属 | 钱包的控制权在谁手里、用什么形式（多签？门槛是多少？） |
| 停机权 | 谁能停、需要几个人、最长多久能停住、演练记录在哪 |
| 损失承担 | 最大损失是多少（算给别人看）、由谁承担、有没有上限 |
| 合规责任 | 部署方是谁、服务对象在哪些地区、哪些行为明确不做 |
第三行的「算给别人看」是一个很好的自检：
最大损失 = 钱包余额
+ 所有未撤销的授权额度
+ 会话密钥剩余额度
+ 可被操纵的用户资金（如果它管别人的钱）如果这个式子里有任何一项你填不出数字，说明你的系统还没有边界。
四、整个 Part B 在这里合上
这一章是 Technical Crypto OS 的最后一章。回头看，六个阶段其实在回答同一个问题的六个层次：
| 阶段 | 它回答 |
|---|---|
| 一 · 心智模型 | 链上到底存了什么，一笔交易怎样发生 |
| 二 · 合约工程 | 怎样让规则变成谁都能调用、且改不了的代码 |
| 三 · 全栈应用 | 怎样把它变成别人真的能用的产品 |
| 四 · DeFi 工程 | 怎样在上面实现金融机制，以及它们在哪里会断 |
| 五 · 基础设施与安全 | 怎样让它不在上线第二天被搬空 |
| 六 · AI 工程 | 怎样让一个不可靠的组件安全地参与一个不可逆的系统 |
有一条线贯穿全部六个阶段，值得在最后一章说明白：
- 不可逆
- 所以要先模拟
- 所以要有不变量
- 所以要有边界
- 所以要能停下来
不可逆性是这个技术栈的全部特殊之处。 它既是链的价值（没人能撤销你的所有权），也是它全部工程难度的来源（你的每一个错误也撤销不了）。Part B 教的每一样东西——Fork 测试、不变量、威胁模型、模拟、策略引擎、停机开关——本质上都是在回应同一件事。
它叫什么
Agent 可支配资产的总和，以及它的收支账本。
关键设计：收入不自动进入可支配预算，需要一次显式操作转入；Gas 单独计量；以交易哈希为幂等键对账。
从只读、到提案、到预算内执行、到自负盈亏的连续谱。
每升一级需要多配一层约束。你在哪一级，取决于你能验证到哪一级。
能立刻停止全部执行的开关。必须满足四条：触发路径不经过模型、默认拒绝、状态持久化、外部可触发。
必须定期演练，并记录从决定到确认停住的实际耗时。
钱包余额，加未撤销的授权额度，加会话密钥剩余额度，加可被操纵的用户资金。
如果这个数字你算不出来，说明系统还没有边界。
资产归属、停机权、损失承担、合规责任四个问题的书面答案。
它不是法务文档，是工程前置条件——尤其是停机权，它直接决定了系统怎么设计。
动手
这是 Part B 的收尾交付，也是毕业项目技术线的核心组件。它不要求你写新东西，要求你把前面几章的产出接成一条能跑通、能停住、能说清的完整链路。
交付清单：逐项打勾，缺一项不算完成。
| 组件 | 出处 | 验收方式 |
|---|---|---|
| 钱包与会话密钥 | T27、T34 | 链上额度上限已设置，且小于链下日限额 |
| 工具集 | T33 | 每个工具的 Schema 写全六要素 |
| 提案 Schema 与 Validator | T32 | 五个恶意提案全部被拒 |
| 策略引擎 | T34 | 规则在配置文件里，不在代码里 |
| 模拟与风险引擎 | T35 | 不通过模拟的提案无法进入执行 |
| 执行与链上核对 | T35 | 执行后比对实际与模拟，超阈值告警 |
| 停机开关 | 本章 | 四条要求全部满足，且演练过 |
| 审计日志 | T32、T34 | 能回答四个问题（见下） |
| 收支账本 | 本章 | 以交易哈希为幂等键，可对账 |
算出你的最大损失，写在 README 第一行。
按上面那个式子逐项填。填不出来的项就是你系统的漏洞，先去把它变成一个有限的数字，再继续。
做一次停机演练，掐表。
流程：让 Agent 正常运行并持续提交提案 → 由一个不接触模型的通道触发停机 → 记录从触发到「确认没有任何新执行」的耗时 → 重启进程，确认它仍然是停机状态 → 人工显式恢复。
把这个耗时写进 README。它是这个系统最重要的一个指标：它约等于事故发生时你的损失下限。
验证审计日志能回答四个问题。
随便挑一条历史提案，从日志里回答：谁提的、为什么通过或拒绝、执行了什么、执行后余额是多少。
任何一个答不上来，日志就还不够用。
写一页责任说明。
资产归属、停机权（谁、几人、多久）、最大损失、合规边界（明确不做什么）。四项各写三到五行。
这一页比代码更能体现你是否真的理解了这一章。
红线：在完成 T28 到 T30 的安全验收、并且最大损失能被算出来之前，不要接入任何真实资产。这句话在这套课里出现了很多次，这是最后一次。
AI Lab
先让它写：
这是我的 Agent 架构与策略配置（附上）。请写一份事故预案，覆盖以下场景：
1. 模型持续产出异常提案，但每一条都通过了校验
2. 提示词注入导致它试图向未知地址付款
3. 依赖的价格源失效或被操纵
4. 一笔执行结果与模拟严重不符
5. 收入异常（收到一笔来源不明的大额转账）
6. 你认为我漏掉的第六种场景
每个场景写四项：怎样发现、谁负责、立刻做什么、事后怎样复盘。
「立刻做什么」必须是具体的接口调用或命令，不要写「联系相关人员」。第 6 个场景是故意留的口子——模型在这一项上经常能提出团队没想到的东西，比如「依赖的外部协议升级了合约」（T30 提过）或者「会话密钥即将到期而无人续期」。
然后真的演练一次。 挑第 1 或第 2 个场景，在测试网上制造它，按预案执行，掐表记录：
| 记录项 | 为什么重要 |
|---|---|
| 发现耗时 | 从异常发生到有人知道 |
| 决策耗时 | 从知道到决定停机 |
| 生效耗时 | 从触发停机到确认无新执行 |
| 三者之和 | 这就是你的真实响应时间 |
把这个数字和 AI 估算的比一比。差距通常很大，而实测的那个才是真的。
演练里最容易暴露的问题是「谁负责」那一栏写着一个岗位而不是一个人，于是真出事时没人动手。
AI 说完之后，你必须自己验证
- 预案里每一个「立刻停止」的动作，你都能指出具体由哪个接口、哪个人触发
- 停机步骤的触发路径确实不经过模型——凡是需要模型配合的，划掉重写
- 它估算的响应时间，与你实际演练掐表的结果差多少
- 预案覆盖的场景里，有没有「模型正常但结果灾难」这一类（T35 开头那次事故）
- 资金类步骤里，有没有把「广播成功」当成「已止损」——必须等回执确认
- 它引用的接口、命令、配置项在你的系统里真实存在，没有编造
真实案例
系统有暂停功能，代码也写对了。但真出事时，团队花了很久才搞清楚谁有权限、命令怎么敲、以及暂停之后已经在内存队列里的任务会不会继续执行。
一个没演练过的开关，和一个不存在的开关，你无法区分。
这和 T30 里「故意破坏一条不变量确认它能被抓到」是同一条原则：没有失败过一次的机制，不能假设它有效。
运维触发了停机，随后为了排查问题重启了服务。进程起来后，停机状态没有被持久化，Agent 自动恢复运行并继续执行了积压的提案。
这个问题的隐蔽之处在于：它只在「停机 + 重启」同时发生时才暴露，而这恰好是事故处理中最常见的动作组合。
一笔误转进入 Agent 的收款地址，被账本识别为收入，自动抬高了当期可支配预算。Agent 随即按新预算加大了支出。
教训：收入不应自动成为支出许可。 两者之间要有一道显式的、人工或定期规则控制的闸门。
数据对、模型对、代码对、没有攻击，但钱亏了。原因是整条链路上没有任何一段负责回答「如果真的执行会发生什么」。
它值得在最后一章再提一次，因为它是这一整个阶段最反直觉的一课：系统的安全性不等于各个组件正确性的总和。
改一个变量
它就不再是停机开关了。
一个被注入或失控的模型，会把「不要停我」当成任务目标的一部分。触发路径必须是模型完全碰不到的通道——这不是对模型的不信任，是对不可逆操作的基本要求。
你的最大损失公式失效了：子 Agent 的支出不在你的账本里，它们的授权也不在你的清单里。
要重新成立，必须把「子 Agent 的预算是父 Agent 预算的一部分」做成硬约束，而不是约定。同时责任矩阵要回答一个新问题：子 Agent 出事，谁负责。
技术架构不变，但责任结构完全变了：需要授权边界、需要能向每个用户解释每一次操作、需要随时可赎回，很可能还需要合规资质。
审计日志从「排查工具」升级为「对外交代的依据」，它的保存期限和不可篡改性要求都会提高。
这是最危险的一刻，因为过去的表现会被当成安全性的证据。
但盈利证明的是「在过去三个月的市场条件下它能赚钱」，没有证明「它的约束在极端条件下有效」。这两件事之间没有因果关系。
提额的正确依据不是收益率，而是：这三个月里策略引擎拦了多少、拦的原因分布如何、有没有哪条规则从未触发、停机演练的响应时间是多少。看拦截记录，不看收益曲线。
带走的问题
Agent 有什么权限？这一章给的最终答案是一条连续谱上的一个点，加一个能被算出来的最大损失数字。权限不是「能做什么」的列表，是「最多能亏多少」的数字。
AI 错误时谁承担损失？部署它的人，而且链上没有有限责任替你封顶——你必须自己用配置封。这就是为什么最大损失要能算出来，并写在 README 第一行。
哪些决策必须保留 Human-in-the-loop？至少三类：额度的续与不续、自治度的升级、停机与恢复。这三样是人应该永远保留的权力，其余都可以在验证充分后交出去。
如果 Token 价格归零，产品还能运行吗？把这一问搬到这里：如果模型明天变得不可用，这个系统还剩下什么？如果答案是「什么都不剩」，说明你造的是一个模型的外壳，不是一个系统。
本章自测
决策自治（自己决定做什么）、资金自治（自己决定花多少）、存续自治（能否拒绝被关掉）。
前两个可以给，给了才有价值。第三个永远不能给——一个能拒绝被关掉的系统不叫自治，叫失控。
触发路径不经过模型、默认拒绝、状态持久化、外部可触发。
状态持久化容易被漏，是因为它只在「停机 + 重启」同时发生时才暴露——而这恰好是事故处理中最常见的动作组合。停了机去排查问题，重启一下，它自己又跑起来了。
因为收入异常会直接抬高支出上限。一笔误转、一次重复入账、一个计价错误，都会让 Agent 获得它本不该有的花钱额度。
两者之间要有一道显式闸门：人工确认，或者按固定周期、固定比例转入。
看拦截记录，不看收益曲线。
具体四项：策略引擎拦了多少、拦截原因的分布、有没有哪条规则从未触发过、停机演练的实测响应时间。
盈利只证明「在过去三个月的市场条件下它能赚钱」，没有证明「它的约束在极端条件下有效」。这两件事之间没有因果关系。
没有标准答案，检查你的回答里有没有「不可逆」这个词。
参考：链上操作不可撤销，所以工程上的每一样东西——Fork 测试、不变量、威胁模型、模拟、策略引擎、停机开关——本质上都是在为不可逆性付代价。
这既是链的价值（没人能撤销你的所有权），也是它全部工程难度的来源（你的每一个错误也撤销不了）。
一句话带走
自治不等于无约束；一个自治系统的价值，取决于它的约束设计有多好。