Constrained Autonomy
1
为什么这件事是主线

D0 正在从 reactive chatbot 走向 proactive trading agent。

Reactive 模式有天然防线：agent 分析 → 人审阅 → 人决定执行。错了能截住。

Proactive 模式下这道防线消失了。Agent 会在用户不在场时持续观察、判断、行动。错误不再是「答错一句话」，是在更大范围内能否被限制在可控边界内。

Human-in-the-loop 时代把人当最后的安全边界。Proactive 时代不能默认这道边界始终存在。

所以 Constrained Autonomy 不是 safety 副本 — 它决定 D0 能不能从「有点聪明的 bot」变成「可以安全放权的 agent」。

2
七层 Autonomy Stack
三层记忆：现实/数据 → 边界/控制 → 决策/演化。下面展开成七层。
1
现实事件层
真实世界发生了什么 — 交易成交、强平、行情变化、余额/仓位变动
涉及：交易后端 · 行情数据 · 基础设施
2
感知上下文层
「发生了」≠「agent 知道了」— 中间隔着 context 注入、通知格式、memory 写入
涉及：MCP 工具链 · Dashboard · 主动推送 · 数据质量
3
推理计划层
Agent 基于上下文形成判断和计划 — 关键是推理完之后怎么被约束
涉及：AI 推理 · 对话能力 · 主动智能
4
验证边界层
计划能不能被结构化校验后再进入执行 — LLM 不能想做什么就做什么
涉及：MCP 校验 · 风控安全 · 评测
5
控制策略层
系统允许 agent 做什么、不允许什么 — GRPS、审批流、硬边界
涉及：GRPS 风控 · 交易安全 · 审批流
6
个性化决策层
同样的规则，对不同用户怎么导出不同行为 — 风险偏好、授权、用户风格
涉及：用户画像 · Onboarding · 信任梯度
7
评测放行演化层
系统怎么观测 agent、评测它、放行、让它下一轮变好
涉及：Eval 体系 · Langfuse/PostHog · Release Gate
3
四个原则 — 有严格的依赖顺序
看见 → 验证 → 约束 → 进化。每一条依赖前一条先成立。

原则一 Ground Truth

第 1–2 层 · 优先级最高
Agent 必须运行在真实状态上，不是幻觉上。
没有这条，后面一切建在沙子上。

原则二 Typed Boundary

第 3–4 层
推理输出必须经过结构化校验才能进入执行。
LLM 不能只隔一个 function call 就碰真钱。

原则三 Constraint Arch

第 4–6 层
约束必须是系统强制的、分层的、每用户可配的。
不是 prompt 里一句话，是架构事实。

原则四 Closed-Loop

第 7 层 + 全栈
整条栈必须可观测、可评测、可放行、可迭代模型本身。
真实执行数据是不可压缩的竞争壁垒。
!
过去 7 天的「乱」，是 Layer 1→2 断裂的组织镜像
不只是代码架构问题 — 是 org 结构在重复产品架构的断裂

证据 1 — 通知服务审计 (3/26 Peter)

Peter 审计发现：爆仓 (liquidation) 没有任何用户通知、TPSL 触发完全静默、GRPS 的 sendSlack()/sendWs() 写了代码但 TODO 跳过。

Trading 侧事件发生了 (Layer 1)，但根本没有管道把它推到 Agent 或用户 (Layer 2)。

L1→L2 断裂事件产生了但没有传递

证据 2 — PRODUCT-2629 仍然开着

Trading→Agent 事件推送管道缺失。Agent 会用过期上下文做判断。这是 Spec 里标注的 P1 根因 — Fei 七天前标出来的，至今没有 owner 在推。

L1→L2 断裂最关键的断裂 issue，无人 own

证据 3 — Polymarket schema 冲突 (3/26 Ethan vs Liang Han)

Ethan 的 PR#163 (bias.mjs signal 输出) 和 Liang Han 的 PR#155 (schema 重命名 side→direction, fair_value→fair_prob) 撞了。两个人改同一个接口面，没有事先协调。

典型的 Layer 3→4 断裂：agent 推理和交易执行之间没有 typed contract。

L3→L4 断裂无共享接口契约

证据 4 — Deposit Flow 5 个问题 (3/27)

充值地址混乱、金额受限于单链余额、不支持外部充值 — 全部是「每条链各自为战」的结果。

Layer 1 (各链资产) 和 Layer 2 (用户感知的统一账户) 之间没有聚合层。

L1→L2 断裂底层分散，上层未聚合

证据 5 — 187/268 MCP 工具裸透传 (3/27 Fei 审计)

Agent 调 Trading 工具时，80% 以上是直接 callTool 零校验。Blog 写的是「LLM should never be one function call away from moving money」，实际就是一个 function call away。

Layer 3 (推理) 直接撞进 Layer 1 (执行)，中间的 Layer 4 (验证边界) 基本不存在。

L3→L4 断裂验证层缺失

证据 6 — Sprint Retro 模式持续

3/15 sprint retro 里的跨模块信息不通模式一模一样地在本周重现：后端 Done 但前端不知道，接口改了但下游没感知，issue 只写「做什么」不写「谁受影响」。

组织断裂信息不通在重复发生
!!
更多证据：感知层全面碎裂
过去 7 天暴露出的断裂 issue；已按 2026-04-02 的 Linear reality 标记 current / historical

这块信息密度高，但不适合默认整屏展开。现在按三类证据折叠：先看哪一类断裂最影响判断，再点开细证据。

输入 / 工具链断裂
证据 7–12：用户输入进不来，工具结果不稳定，Agent 的世界模型在变窄。
6 条证据 · 默认展开
🔇 用户输入根本进不来 — 感知入口断裂

证据 7 — TG Bot 无法接收图片/文件/语音 (3/28，当时 Urgent，现已 Done)

用户发送任何媒体类型给 D0 bot → 报错 "Failed to download media"。根因是 TG proxy 没有 strip virtualToken 前缀，一行代码的 bug 导致所有用户的图片/语音/文件全部无法接收。PR#867 已提交但还没合并。

用户想告诉 agent 的信息（截图、语音指令）根本进不了 agent context。

L1→L2 断裂ENG-1212 · Done · historical evidence

证据 8 — 用户对语音输入有强需求但不可用 (3/27)

用户反馈明确表示对语音输入功能有强需求。但当前语音消息根本无法接收（见证据 7），配置层面的问题让产品承诺的能力名存实亡。

L1→L2 断裂PRODUCT-2717 · Todo · 能力缺口，非当前主线 blocker
🔧 工具链碎裂 — Agent 的眼睛看不清

证据 9 — d0-cli 工具链返回格式不一致，多处崩溃 (3/28，旧 ID: TES-748，当前 canonical: PRODUCT-2777，现已 Done)

Bot 执行脚本因缺少防御性解析而崩溃 — 4 种不同的崩溃模式：KeyError 'response'、list 当 dict 解析、NoneType.get()、undefined is not iterable。

API 返回了数据但格式不一致，agent 无法正确解析 → 即使 L1 有数据，L2 也消费不了。

L1→L2 断裂PRODUCT-2777 · Done · historical evidence

证据 10 — MCP 工具 schema 与 bot 调用不匹配 (3/28, Urgent)

Bot 调用 DONUT_MARKET_DISCOVERY → 连续 2 次 "Invalid arguments" 错误。Bot 传入的参数格式与 gateway schema 不匹配。工具存在但 agent 调不通。

L1→L2 断裂TES-747 · Done · historical evidence

证据 11 — 链上工具不存在 + 数据源 403 + API 耗尽 (3/28)

三个独立数据源同时断裂：
· DONUT_ONCHAIN_PUMPFUN_TOKENS 工具声称存在但实际不存在（当前 canonical: PRODUCT-2720，仍在 Triage）
· ForexFactory/Investing.com 宏观日历返回 403（当前 canonical: PRODUCT-2721，已 Canceled）
· Birdeye API 用量耗尽，链上数据断流（ENG-1216，已 Done）

Agent 的「世界模型」在持续缩窄 — 它以为自己能看见的东西，实际上越来越多在返回错误。

L1 断裂当前仍活跃的是 PRODUCT-2720；其余已转成 historical evidence

证据 12 — 热更新未同步 skills，老用户看到旧版 agent (3/28)

D0 热更新没有同步 workspace skills — 老用户容器里的 d0-perps/index.md 版本过旧。不同用户看到不同版本的 agent 行为，Layer 2 感知层连一致性都没有。

L2 断裂TES-741 · Done · historical evidence
安全 / 控制反向泄漏
证据 13–15：不是“看不见”，而是内部推理和控制信号反过来泄漏给用户。
3 条证据
🔓 安全 / 控制反向泄漏 — 内部信号涌向用户

证据 13 — Bot 内部推理过程泄漏 + 一问多答，100% 复现 (3/26, Urgent)

Session review 中 3/3 sessions 全部命中：72 条 narration 泄漏，42 次一问多答。用户问 "BTC analysis" 收到 4 条消息，前 3 条是 "Let me load the skill…" "Now let me pull data…" 内部推理噪音。

这是「反向断裂」— Layer 3 的内部推理在往 Layer 2 的用户感知层泄漏。不只 L1→L2 断了，L3 还在往 L2 灌噪音。

L3→L2 反向泄漏PRODUCT-2675 · In Review · 当前仍活跃

证据 14 — NO_REPLY 控制文本泄漏到 Telegram — 已修 Bug 回归 (3/26，旧写法 PRODUCT-2674，当前 canonical: TES-769，已 Done)

内部系统控制信号 "NO_REPLY" 直接显示给用户。这是 TES-642 的回归 bug — 修过一次又回来了，说明没有系统级的 regression 防护。

L3→L2 反向泄漏TES-769 · Done · historical evidence

证据 15 — 公开仓库内部信息泄漏 (3/27)

DonutLabs-ai/openclaw 公开仓库包含不应公开的内部信息，需要清理。

安全断裂ENG-1210 · Triage · security hygiene，非当前 v1 blocker
交易结果到了，但用户感知没跟上
证据 16–18：交易能力和资金状态在底层存在，但没有稳定到达 Dashboard / Bot / 环境层。
3 条证据
💰 交易→用户感知断裂 — 钱到了但看不见

证据 16 — 充值后资金卡在主账户，Dashboard 不显示 (3/27)

两个 issue 说同一件事：Agent 充值后资金未自动转入交易子账户 (TES-739)、Dashboard 充值后 transferToSub 无轮询重试 (TES-740)。交易后端 (L1) 充值完成了，但 Dashboard (L2) 看不到资金。

L1→L2 断裂TES-739 / TES-740 · Done · historical evidence；当前活跃对账面转到 PRODUCT-2816 / PRODUCT-2861

证据 17 — Jupiter V2 限价单在 Bot 完全不可用 (3/26, Urgent)

6 项问题导致 Jupiter V2 限价单在 D0 Bot 中完全无法使用。交易能力 (L1) 存在但 agent (L2-L3) 无法调用。已修，但暴露了「后端功能上线 → bot 能力跟进」之间没有验证流程。

L1→L2 断裂TES-734 · Done · historical evidence

证据 18 — 共享 VM 网络泄漏 + 扩容失效 (3/27)

Docker 网络泄漏导致新 agent 创建失败 (PRODUCT-2714)；自动扩容机制在突发流量下失效 (PRODUCT-2715)。Layer 1 地基层不稳 — agent 连创建都可能失败，七层全不存在。

L1 地基PRODUCT-2714 / PRODUCT-2715 · Canceled · historical evidence
⚡
根因：团队按模块划分，但产品需要按层间接口划分

现在的组织逻辑：

交易团队
Peter / Alex / Calvin
建 GRPS、perps、结算
Agent 团队
Regison / Fei / JackJun
建 D0、skills、eval
前端
Gary / Jin Xu
建 Dashboard、TG Bot

每个团队 own 自己的模块。但 Constrained Autonomy 的七层是垂直的 — 它需要有人 own 的是「层之间的接口」，不是「层本身」。

Trading team 以为 AI team 只是在做会聊天的 agent。AI team 以为 Trading 只是在提局部风险需求。PM 以为数据、eval、GRPS、profile、dashboard 是五摊事。

其实它们是一件事：把 autonomy 放进 constraint architecture。

具体来说，每相邻层之间需要有人保证上游产出 = 下游消费。现在没人做这件事：

层间上游产出什么下游需要什么断在哪
L1→L2
事件管道		 Trading 产出事件：成交、强平、TPSL、余额变动、行情 Agent 需要：实时 context 注入、通知推送、MCP 可查询 事件产出了但没管道送上去（证据 1-2, 7-12, 16-17）
L3→L4
验证关卡		 Agent 推理后输出：function call、交易参数、执行计划 系统需要：schema 校验、参数边界检查、幻觉拦截 187/268 工具裸透传、schema 冲突（证据 3, 5, 13-14）
L5→L6
策略适配		 GRPS 输出：全局约束、风险等级、杠杆上限 Agent 需要：按用户 profile 导出差异化行为 GRPS 只覆盖 perps，Profile 未接入决策
L7→全栈
进化回路		 Eval/Langfuse/PostHog 输出：质量信号、成本、用户反馈 全栈需要：prompt 改进、模型切换、规则更新 多人在做但闭环未通
🗺
Autonomy Stack 在产品矩阵上的位置
颜色 = Stack 的四个阶段在矩阵上覆盖的区域
High-Stake →
Proactive ↓
S0Research
S1Guarded
S2Managed
S3Continuous
P0Reactive
v1 NOW
v1 NOW
安全基础
P1Monitor
v2 30D
v2
P2Draft
v3
v3 6M
P3Constrained
v3
v4 12M
P4Adaptive
v4
v1 看得清
核心流程跑通
能用敢用愿意付费
= 第 1–2 层
v2 想得明
个性化基础
知识体系 + 评测
= 第 3–4 层
v3 做得住
自动执行
风控闭环 + 审批
= 第 5–6 层
v4 越来越好
质量闭环
增长 + 自我进化
= 第 7 层
依赖是硬的：v1 没过（agent 看不见真实世界），v2 的推理就在幻觉上跑。v2 没过（推理没有校验），v3 的自动执行就是脱缰的马。不能跳。
👥
每个人在哪层、每层之间谁盯交接

这一页本质是“谁在守哪条交接线”。先看摘要卡理解每个阶段的关键 owner 和当前断点；如果要查人，再展开阶段明细。

现在在这
看得清
关键 owner：Peter / Alex / Ethan / Regison / Jin Xu / Gary / JackJun
当前断点：事件产出了，但没有稳定进入 agent / 用户感知
30D 目标
想得明
关键 owner：JackJun / Fei / Jiagui
当前断点：推理和执行之间还没有统一验证关卡 owner
3-6M
做得住
关键 owner：Peter / Jiagui / Sylvia / Justin / Ethan
当前断点：GRPS 约束还没有和 profile / approval 产品面接起来
12M
越来越好
关键 owner：Fei / Kevin / Jim / Wenzhang
当前断点：执行结果还没稳定回到 eval / release / rule update 闭环
怎么读
查阶段，不查人名墙
  • 先定位你在看哪一层交接线。
  • 先看“当前断点”，再看 owner。
  • 只有要追具体协作边界时，才展开人员明细。
看得清
现实事件 + 感知上下文。当前主线在这里，默认展开。
事件管道 owner：Wenzhang
现实事件 — 真实世界发生了什么
Peter
交易执行 · 撮合 · 结算 · 事件产出
Alex
Perps 撮合引擎 · TPSL · API
Liang Han
量化数据 · Polymarket · 行情数据源
Ethan
多链资产 · Deposit/Withdraw/Transfer
事件管道交接 — Owner: Wenzhang
负责把成交、强平、余额变动等事件收成 schema、推送管道、通知服务和 MCP 数据注入，保证上游产出真的进入下游消费。
感知上下文 — Agent 看见了什么
Regison
MCP 工具链 · d0-cli · 数据质量
Jin Xu
D0 前端 · TG Bot · Skills
Gary
Dashboard · Onboarding · WebApp
JackJun
主动推送 · Alert · 信号处理
想得明
推理计划 + 验证边界。不是没人做，而是还没形成统一交接 owner。
关键缺口：验证关卡 owner
推理计划 — Agent 怎么想
JackJun
Agent 架构 · LLM Routing · 推理链路
Fei
AI 研究 · Frontier · 推理质量
验证关卡交接 — 需要指定 Owner
Agent 推理完成后，function call 执行前经过什么校验。现状仍是 187/268 工具裸透传，需要 schema 校验 + 参数边界 + 幻觉拦截。
验证边界 — 校验、风控、审批
Fei
Eval 体系 · 验证框架 · Safety Audit
Jiagui
容器安全 · 浏览器隔离 · 硬边界
做得住
控制策略 + 个性化决策。当前最大问题不是规则，而是规则没有接进 profile / approval。
关键缺口：策略适配 owner
控制策略 + 个性化决策 — 约束 × 用户画像
Peter
GRPS 风控规则 · 交易约束
Jiagui
系统安全 · 权限硬边界
Sylvia
用户画像 · 交易偏好 · Persona
Justin
产品策略 · Approval Inbox · 用户可见配置
Ethan
DeFi 交易执行 · Dashboard 功能页
策略适配交接 — 需要指定 Owner
GRPS 约束怎么和用户画像结合，导出每个用户不同的 agent 行为。现状：GRPS 只覆盖 perps，Profile 还没接入决策。
越来越好
评测放行演化。证明面在形成，但执行结果还没有稳定回到 release / model / rule 更新。
关键缺口：进化回路 owner
评测放行演化 — 系统怎么变好
Fei
Eval 框架 · Safety 审计 · Release Gate
Kevin / Jim
E2E 测试 · Trading QA · 发版流程
Wenzhang
Eval Infra · 监控 · Observability
进化回路交接 — 需要指定 Owner
执行结果怎么变成 eval 信号，反馈回模型和规则。现状：Langfuse / PostHog / d0-evals 各做各的，闭环没通。
监控
Constrained Autonomy 监控看板
总原则 issue 已拆成两张 active 监控板：一张看真实状态，一张看执行边界

这一页先看现在的监控面，再按需展开审计细节。 总原则先回答“受限自治要靠哪些依赖链成立”；两张监控板再分别回答“真实状态有没有进 agent”以及“执行有没有被系统边界限制”。repo PR、窄 issue 和运行态 proof 仍然是 execution SSOT，这里只负责把 reality 收回到原则链。

总原则
依赖链与拆解方式
定义「看见 → 验证 → 约束 → 进化」四个原则及依赖顺序。
对应：PRODUCT-2718 · In Progress
真实状态监控
Ground Truth
按 source-family coverage 审 agent 有没有运行在真实状态上。
对应：PRODUCT-2725 · 当前最大 gap：GT-3 / pull-path truth contract
执行边界监控
Typed Boundary
按 execution-surface coverage 审 reasoning 有没有被稳定限制在系统边界里。
对应：PRODUCT-2726 · 当前最大 gap：TB-1 + TB-4
先看
两张原则板的当前缺口
再看
coverage 是否完整
最后看
issue map / 证明面
不要混淆
这里不是 repo / PR 的执行 SSOT
展开总原则与两张监控板的关系
如果需要看父级定义、这张 tab 的使用方式、以及为什么这里不替代 execution SSOT，再展开。
说明层
这三张 issue 不是 execution SSOT。repo PR、窄 issue、运行态 proof 仍然是执行 SSOT；这张 tab 只负责把 repo reality 重新收回到 2718 的原则链，并持续映射到 2725 / 2726 两张 active audit boards。
对象这张 tab 怎么用它当前状态
PRODUCT-2718parent spec / principles / dependency-chain issue；定义四个原则及其严格依赖顺序In Progress
PRODUCT-2725Ground Truth 原则审计板；先看 source-family coverage，再看 GT-1..GT-4 哪一段还没成立In Progress
PRODUCT-2726Typed Boundary 原则审计板；先看 execution-surface coverage，再看 TB-1..TB-5 哪一段还没成立In Progress
Execution SSOTrepo PR、窄 issue、runtime/eval/release proof；这张 tab 不替代它们，只负责原则收口External SSOT
GT
真实状态监控板
对应 PRODUCT-2725 · 先按 source-family coverage 监控，再往下审 canonical、ingress、truth contract、traceability
第一视角
先看哪些现实源头被覆盖
不是先问“有多少通知”，而是先问 agent 今天到底从哪些真实源头拿状态。
HyperLiquid Donut Perps Onchain / Webhook Action outcome Pull-path live data
当前判断
统一事实面在形成，但 GT-3 仍没过
  • 最完整的 source family：Donut Perps。
  • 最大的 active gap：pull-path truth contract 还没成为 runtime 事实。
  • 这张板的用途：判断 repo / issue 到底在补 source、canonical、ingress 还是 truth contract。
最完整
Donut Perps
最大缺口
GT-3 / Pull-path truth contract
当前 owner
Fei · Peter · Regison
当前读法
先看 coverage，再看 issue map
展开 source-family coverage
看 5 类现实源头分别由谁承载，以及每一类当前缺在哪一段覆盖链。
5 个 source families
Source Family上游 owner / repo要审的覆盖链当前判断
HyperLiquid`donut-agents-backend`orders / fills / positions / liquidations → canonical fact → ingress统一 publisher 基础设施已出现，但 HL → agent ingress 仍没有被单点 issue 收口
Donut Perps`donut-perpetual`成交 / 结算 / 强平 / funding / risk → canonical event bus当前最完整；`PRODUCT-1959` 在 In Review，`PRODUCT-2629 / 2670` 已转历史桥梁
Onchain / Webhook`donut-backend`swap / transfer / limit fill / wallet 状态 → webhook / bus / trace链上 webhook 正在进入统一总线，但 user-facing traceability 还没被单点收口
Action Outcome`donut-backend``action.mcp` execute outcome → action result envelope → agent / trace动作结果已经被当成独立 source family；不能再混回“通知副作用”里看
Pull-path Live Data`d0-cli` + 第三方数据源tool result → schema / freshness / structured failure → reasoning这是当前最大的 active 缺口；truth contract 仍没变成 runtime 事实
展开 GT-1..GT-4 建构性要求
看 2725 真正在审哪四段链，以及每一段当前是 converging、partial 还是 largest gap。
4 段链
要求监控链面向当前判断
GT-1`source family -> canonical fact / envelope`；先审现实源头有没有被收成机器事实事实面Converging
GT-2`canonical fact / bus -> agent ingress`；不只问“有通知”，而是问 agent 是否有显式 ingress回流面Partial
GT-3`pull-path source -> runtime truth contract`；schema / freshness / structured failure 必须成为 runtime contract工具面Largest Gap
GT-4`fact -> user / event / execution traceability`；事实必须能绑定回 user / event / execution证明面Partial
展开真实状态监控的当前 issue map
查这条板子当前到底挂了哪些 active issue；这是后台明细，不是阅读主路径。
8 个相关 issue
Issue做什么谁进度
PRODUCT-2725Ground Truth principle audit board；用 source-family coverage + GT-1..GT-4 收口 realityFeiIn Progress
PRODUCT-1959Perps event pipeline 总设计；负责 canonical event envelope 与 consumer contractPeterIn Review
PRODUCT-2629历史性的 return-path gap 修复；现在更像旧桥梁已关账，而不是当前主控 issuekevin wangDone
PRODUCT-3216canonical executed contract + USD notional；把事实口径钉进 analytics / trace contractFeiIn Review
PRODUCT-3222MCP result validation 主承载；阻止脏数据直接进 agent 决策Jin XuTriage
PRODUCT-2934`@Tool` 结果校验 / staleness / precision 的工程入口RegisonTodo
PRODUCT-3228tool / skill 静默失败的 immediate mitigation未指派Triage
PRODUCT-2563trace / observability / downstream proof；补 traceability 的主要证明面Justin WuIn Progress
TB
执行边界监控板
对应 PRODUCT-2726 · 先按 execution-surface coverage 监控，再往下审 typed intent、validation、hard boundary、verify、non-bypass proof
第一视角
先看哪些执行面在把 reasoning 变成动作
不是先问“有多少安全 issue”，而是先问 agent 今天到底能通过哪些 execution surfaces 动真钱。
Onchain / Action Gateway Donut Perps HyperLiquid Wallet / Privileged actions
当前判断
安全 exploit 关掉了一批，但中心边界还没成形
  • 最大的结构空洞：TB-1 / 统一 Typed Intent object。
  • 第二个核心缺口：TB-4 / 通用 post-result verification。
  • 这张板的用途：判断 issue / PR 在补 intent、validation、hard boundary 还是 non-bypass proof。
最硬的边界场
Donut Perps
最大缺口
TB-1 / Typed Intent
次级缺口
TB-4 / Result Verify
当前读法
先看执行面，再看 proof
展开 execution-surface coverage
看 4 类执行面分别由谁承载，以及每一类当前缺在哪一段边界链。
4 个 execution surfaces
Execution Surface主 owner / repo要审的边界链当前判断
Onchain / Action Gateway`d0-cli` + `donut-backend`swap / transfer / limit fill / `action.mcp execute` → typed intent → validate → gate`PRODUCT-1219` 证明 validate 能力存在，但还没变成 D0 默认主路径
Donut Perps`d0-cli` + `donut-backend` + `donut-perpetual`开平仓 / 调杠杆 / 风险敏感仓位动作 → hard boundary → engine是最能做硬边界的主场，但 amount / HIL / typed intent 仍未统一收口
HyperLiquid`donut-agents-backend`HL order / position / exchange-side execution → pre-call / post-result boundary`ai.Decision` 证明局部 typed decision 可以存在，但它还不是全局 typed contract
Wallet / Account Privileged Actions`donut-backend` + `donut-wallet-service`签名 / 钱包归属 / nonce / 账户级敏感操作 → ownership / auth / hard gate归属校验已修，后续 wallet-service hardening 继续在证明特权路径必须显式受控
展开 TB-1..TB-5 建构性要求
看 Typed Boundary 真正在审哪五段链，以及每一段当前为什么还没彻底成立。
5 段链
要求监控链当前结构判断
TB-1`execution surface -> typed intent`最大的结构空洞仍在这里；还没有 D0 主路径的统一 typed intent object
TB-2`typed intent -> deterministic pre-call validation`局部能力已存在，但没有跨 execution surfaces 的统一 contract
TB-3`validated intent -> hard boundary -> execution engine`关键 exploit 已关一批，但 amount / daily quota / HIL / scope / rate / breaker 仍渠道分裂
TB-4`execution -> post-result verification`结果回流在变强，但通用的 plan-vs-actual verifier 仍不存在
TB-5`boundary path -> non-bypass proof`proof surface 在增强，但“每条 execution surface 都不可被旁路”还没有统一证明结构
展开执行边界监控的当前 issue map
查这条板子当前挂了哪些 active issue；这是明细层，不占主叙事。
11 个相关 issue
Issue做什么谁进度
PRODUCT-2726Typed Boundary principle audit board；用 execution-surface coverage + TB-1..TB-5 收口 realityFeiIn Progress
PRODUCT-2501Agent-first 策略设计；理论上最终应承载 agent action semanticsPeterTriage
PRODUCT-1958Agent Trading API 总设计；最接近 execution contract 总轮廓PeterIn Review
PRODUCT-1219`/action-mcp/validate` 预校验能力；能力已存在，但 issue 本身已 Done 并归档jimDone
PRODUCT-2598Polymarket 9 项 pre-call risk checks；证明局部渠道可以先闭环EthanIn Review
PRODUCT-2177代码级硬边界总设计；system-enforced limit / HIL / scope / breaker 的总入口JiaguiTriage
PRODUCT-2113金额 / 日累计限额 guard；ActionMcpController 前置硬拦截JiaguiTriage
PRODUCT-2615钱包归属校验；wallet / account 特权执行面的核心 ownership 漏洞已关闭jimDone
PRODUCT-2236trading-mcp-server 认证 + 执行沙箱；把高危执行面先做硬边界kevin wangDone
PRODUCT-2618message role 注入防护；阻止上游 prompt 绕过边界kevin wangDone
PRODUCT-1920策略验证标签；是 post-result verification 的相邻证明层，不是 typed intent 替代JackJunIn Review
展开辅助证明面
这些 issue 很重要，但它们是 proof surface，不替代核心边界本身。
proof surfaces
Issue做什么谁进度
TES-721跨边界 contract / QA / Trading 防线；强调防止旁路和漏测kevin wangTriage
TES-723d0-evals 为中心的 QA 流程；把质量信号汇总到可判定面FeiTriage
PRODUCT-2508Release Checklist 模板kevin wangDone
PRODUCT-2509Release Gate 机制建设kevin wangDone
PRODUCT-2664Eval ↔ E2E CI 接入发版流水线kevin wangDone
PRODUCT-2505`d0-skill-eval` CI / deploy / benchmark run 流水线FeiDone
PRODUCT-2507Core-30 canonical benchmark 收敛FeiIn Progress
▸
后续路线 — 按依赖链推进
每个阶段有验收标准。上一个没过，不进下一个。
NOW
v1 · 核心流程跑通，能用敢用愿意付费
事件管道通 + MCP 数据准 + 通知到位 + Dashboard 可对账
当前 reality：Perps 的部分交易事件已可注入 agent context；全渠道 1 分钟 SLA 仍未达成
完成口径：theoretical 上由本页两张原则监控板收口结构缺口；empirical 上由 benchmark / eval 证明真实系统过关
事件管道 Owner: Wenzhang · Peter · Regison · Jin Xu · Gary · Liang Han · JackJun
30D TARGET
v2 · 个性化基础 + 知识体系 + 评测
价格提醒 · GRPS 软约束 · Strategy Hub · 每个 function call 执行前校验
验收：零裸透传 — 每个 MCP 工具调用都有 typed 验证
验证关卡 Owner: 待定 · JackJun · Fei · Jin Xu · Jiagui
3-6M
v3 · 自动执行 + 风控闭环 + 审批
Approval Inbox · GRPS 扩展全品类 · Profile→agent behavior policy · 用户可见可配
验收：Agent 行为因用户 profile 不同而不同，用户可在 Dashboard 调整
策略适配 Owner: 待定 · Peter · Jiagui · Sylvia · Justin · Ethan
12M
v4 · 质量闭环 + 增长 + 自我进化
Eval→Release Gate→Model 改进完整闭环 · 24/7 自主值班 · 极端行情自动降仓
验收：模型行为可证明地从上一轮执行数据中改进
进化回路 Owner: Fei · Kevin · Jim · Wenzhang
💡
一句话总结

根因不是人不够 — 是各模块团队各自建自己那一段，层之间没有人保证「上游产出 = 下游消费」。

每个阶段的验收本质上是在验收「对应交接线的质量」。先让「看得清」过关，再往「想得明」走。

Ctrl+S 保存