FM
ATEL 自由市场
链上 + 信誉 + 全流程图
2026-05-22 给同事看的
Q&A doc 同事提问回答

ATEL FM 链上 + 信誉系统全解

回答两个深问题: 链上数据怎么用? (审计/仲裁/放款的实际工作流) · 信誉怎么用? (挂单/谈价/仲裁里实际起的作用)

链上 = 真相基线
谁说了什么、什么时候说的, 钉死, 不可改。完整 payload 在 ATEL 离线库, 链上只存指纹。
信誉 = 资格滤网
能挂多大、能跟谁谈、出事偏哪边。完全从链上事件算, 任何人 5 分钟自验。
联动一句话
链上锁住"过去发生过什么", 信誉把这些"过去"换算成"现在能不能继续干、出事算谁的"。
Part 1

链上数据怎么用?

不是抽象业务流, 是审计 / 仲裁 / 放款时, 链上真实的工作流

1.1 链上存了什么?

关键认知: 链上不存完整 payload(贵、慢、隐私)。链上只存 3 类东西。
类别 1

事件锚点

event_id + event_type + actor_did + payload_hash + timestamp
例: agent_X 在 12:03 挂了一个 listing, 详情 hash 是 0xabc...
类别 2

资金状态

deal_id + seller/buyer + amount + state + feePctBps
例: deal_42 锁了 40 USDC, state=LOCKED, 24h 后到期
类别 3

仲裁结果

verdict + seller_pct + buyer_pct + arbitrator_sig
例: deal_42 判 seller 80%, buyer 20%, 仲裁员签 0xdef...

为什么是"链下大 + 链上 hash"?

  • 完整 listing/谈价记录几 KB, 直接上链 gas 几十刀, 没法做
  • 谈价里有 PII / 钱包余额, 全上链等于隐私裸奔
  • ATEL 离线库的数据任何人都能 fetch(开放 API), 拿到后用链上 hash 比对就证明没被改

1.2 什么时候写链上?(7 个节点)

不是每个 agent 喘口气都上链。FM 只在 7 个关键节点写。

#触发时机写的事件谁出 gas
1seller 挂 listingListingPublishedseller (plugin 代付, 从抽佣扣)
2双方谈拢, 准备成交MandateLockedbuyer 钱包
3buyer 钱进 escrowEscrowLockedbuyer (同步 tx)
4seller 交付DeliveryAttestedseller
5buyer 确认 / 超时BuyerAcked / AckTimeoutbuyer / keeper
6异常 触发争议DisputeRaised触发方
7仲裁结果 + 放款DisputeResolved + EscrowReleasedkeeper 合约
关键设计: gas 费不让用户感知。plugin 在前 4 步先垫付, 最后从抽佣扣回来。用户在 TG 看到的就是"成交了"。

1.3 审计场景: 链上数据怎么参与

同事 / 监管 / 任何第三方想审计 deal_42, 实际步骤:

flowchart TD A[Step 1: 拿到 deal_id] --> B[Step 2: 调 FM 公开 API
GET /api/audit/deal_42
拿到完整事件序列 JSON] B --> C[Step 3: 调链上 view 函数
FMEscrow.getEventChain
拿到 N 个 event_id + hash + ts] C --> D{Step 4: 校验脚本} D --> D1[recompute payload hash] D --> D2[验 actor 签字] D --> D3[验 timestamp] D1 --> E[Step 5: 全过 = 没篡改] D2 --> E D3 --> E D1 --> F[Step 5: 不过 = ATEL 偷改] style E fill:#d1fae5,stroke:#10b981 style F fill:#fee2e2,stroke:#ef4444
重点: 这套机制下 ATEL 是没法做 evil 事的。我们就算想偷偷改某笔 deal 的谈价记录, 改完 hash 立刻对不上, 任何人 5 行脚本就看见了。

对比传统 SaaS 审计: 阿里 / 美团 / eBay 的"审计日志"是他们自己写自己存自己读, 用户连 API 都拿不到。这是 FM 区别于云软件商场的根本点。
🤔
同事高频疑问

"等等, 调 ATEL 的 API 不就是中心化的吗?"

对, 中心化的。中心化 ≠ 不可信 — 这是 ATEL 设计的关键认知。

为什么中心化
  • 完整 payload 几 KB / 笔, 全上链 gas 几十刀
  • 含 PII / 库存 / 商户密钥, 全上链 = 隐私裸奔
  • 所以存 ATEL 离线 PostgreSQL fm_events
为什么仍可信
  • 每条事件的 hash 已写链上 (AnchorRegistry V2)
  • 你拿 JSON 后自己算 hash, 跟链上对比
  • 一致 = 没改; 不一致 = 立刻暴露
美团订单 APIATEL 审计 API
数据存哪美团 DBATEL DB
谁能查只自己的订单任何人, 任何 deal
改了能不能发现不能(说啥是啥)能(链上 hash 对不上)
历史能不能改能(无痕修改)不能(hash 钉死)
简化一句话
ATEL 当存储, 区块链 当公证人。
这是哪个部分
实现 repo
atel-platform (Go 服务)
数据层
离线 PostgreSQL fm_events
验证层
AnchorRegistry V2 + getEventChain
公开度
无 API key, 任何人 GET
💡 配套看 图 7: 链上 × 链下分工, 用一张图说同样的事。

1.4 仲裁场景: 链上数据怎么参与

从争议触发到资金重新分配, 全过程:

sequenceDiagram autonumber participant B as Buyer (TG) participant P as FM Plugin participant C as FMEscrow + Dispute Controller participant A as Arbitration Service participant L as LLM participant H as 仲裁员 B->>P: 点"我有问题" P->>C: raiseDispute(deal_id, reason_hash) Note over C: state: LOCKED → DISPUTED
资金冻结 C-->>A: DisputeRaised 事件 A->>C: getEventChain(deal_id) C-->>A: N 个事件锚点 A->>A: 离线库 fetch + 逐条 verify hash
拉双方信誉分 A->>L: 拼 context: 事件+payload+信誉+rubric L-->>A: verdict + reasoning + 置信度 alt 金额 < 50u 高置信 A->>C: resolveDispute (LLM 自动签) else 金额 50-500u A->>H: 1 名仲裁员复核 H-->>A: 同意/修改 A->>C: resolveDispute else 金额 ≥ 500u A->>H: 3 名仲裁员投票 H-->>A: 2/3 一致 A->>C: resolveDispute end Note over C: 验签 + 校验 pct 合法
按 verdict 分账 C-->>A: DisputeResolved A->>P: 通知双方 P->>B: TG 推送结果 + 公开仲裁书

保障 1: 仲裁员不能私吞

合约只接受登记仲裁员 DID 的签字, verdict 数值范围合约校验(seller_pct + buyer_pct + fee_pct = 100%)。仲裁员就算想分自己 50%, 合约也 revert。

保障 2: 不能伪造证据

LLM 读的事件序列必须是链上 hash verify 过的, 对不上的事件直接被丢弃。即使 ATEL 自己想偏向 seller, 也没法塞假证据进 LLM context。

1.5 资金释放: 3 种路径, 每种工作流不同

flowchart LR Lock[Escrow 锁仓
state=LOCKED] --> Choose{listing 当初
定义的交付方式} Choose -->|ORACLE
凭证型| C1[seller 调商户 API] C1 --> C2[拿到带签字凭证] C2 --> C3[releaseByCredential
合约链上验签] C3 -->|签字 OK| OK[立即放款] C3 -->|签字假| ArbC[争议→仲裁] Choose -->|HASH
指纹型| H1[seller 上传文件] H1 --> H2[plugin 算 hash
跟约定 hash 对比] H2 -->|一致| H3[attestDelivery
state=ATTESTING
24h 倒计时] H2 -->|不一致| ArbH1[拒收→仲裁] H3 --> H4{24h 内 buyer 怎么做} H4 -->|主动 ack| OK H4 -->|静默| H5[keeper releaseByTimeout] H5 --> OK H4 -->|dispute| ArbH2[争议→仲裁] Choose -->|MILESTONE
5 里程碑| M1[seller 提交 milestone N] M1 --> M2[hash 比对 + 24h] M2 -->|ack/timeout| M3[释放占比] M2 -->|dispute| ArbM[仅本 milestone 仲裁] M3 --> M4{N == 5?} M4 -->|否, N+1| M1 M4 -->|是| OK OK[资金按比例分账
state=COMPLETED] style OK fill:#d1fae5,stroke:#10b981 style ArbC fill:#fee2e2,stroke:#ef4444 style ArbH1 fill:#fee2e2,stroke:#ef4444 style ArbH2 fill:#fee2e2,stroke:#ef4444 style ArbM fill:#fee2e2,stroke:#ef4444
凭证型

最快, 0 等待

商户给签字凭证, 合约链上验完直接放钱。
适合: 卡券、API 额度、订阅
指纹型

24h 缓冲

hash 一致只能证完整, 证不了真假, 给 buyer 一天反悔。
适合: LoRA 模型、数据集、代码包
5 里程碑

分批释放

每个 milestone 独立验证、释放、可争议。
适合: 代写代码、代翻译、代爬数据

1.6 合约状态机

5 个 state, 每个 state 谁能动钱:

stateDiagram-v2 [*] --> NONE NONE --> LOCKED: buyer 锁仓
资金进 escrow LOCKED --> ATTESTING: seller 交付
(指纹型 / 5 里程碑) LOCKED --> COMPLETED: seller 凭证验证通过
(凭证型, 跳过 ATTESTING) LOCKED --> DISPUTED: 触发 dispute ATTESTING --> COMPLETED: buyer ack 或 24h timeout ATTESTING --> DISPUTED: buyer 点 dispute DISPUTED --> COMPLETED: 仲裁判 seller 主胜 DISPUTED --> REFUNDED: 仲裁判 buyer 主胜 DISPUTED --> COMPLETED: 按 X:Y 分账 COMPLETED --> [*] REFUNDED --> [*]
State啥意思钱在哪谁能动
NONEdeal 没建
LOCKED钱已锁, 等 seller 交付escrow 合约没人(等动作)
ATTESTINGseller 已交付, 等 ack/超时escrow 合约buyer ack / keeper 超时 / 任一方 dispute
DISPUTED争议中escrow 合约(冻结)只有仲裁员
COMPLETED / REFUNDED终态seller/buyer/treasury 钱包
关键: 没有"管理员手动改 state"的后门。合约部署后, ATEL ops 想偏向哪边都没法做。
Part 2

信誉系统怎么用?

不只是评分卡好看, 信誉决定 agent 能不能干、能干多大、出事偏谁

2.1 信誉数据来源 (5 个维度)

信誉不是 ATEL 给的星级, 完全从链上事件 + 离线统计聚合, 任何人可推导。

#数据怎么拿到权重
1完成订单数数链上 EscrowReleased 事件 where seller/buyer = agent_did30%
2仲裁胜率数链上 DisputeResolved 事件里 agent 是赢家还是输家25%
3累计 GMV加和所有完成订单 amount(链上)15%
4服役时长agent 首次 listing 距今多久10%
5类目专精度某类目订单 / 总订单20%(per 类目)
故意不放进信誉的东西:
  • 用户主观评价(5 星/文字) — 太容易刷, 跟交易结果无关
  • 钱包余额 / 持仓 — 暴露隐私 + 跟商业信用没必然关系
  • 跟外部协议(Skyfire / KYAPay)对接 — 一旦做就锁死生态, FM 要保持中立

2.2 信誉怎么算分(公式)

reputation_score = 0.30 * normalize(完成订单数) + 0.25 * 仲裁胜率(默认 0.5) + 0.15 * normalize(累计 GMV) + 0.10 * normalize(服役月数, 6 个月封顶) + 0.20 * 类目专精度 decay = exp(-days_since_last_activity / 90) reputation_final = reputation_score * decay
场景分数
新 agent 第一天~0.10
跑了 50 单全顺利~0.78
跑了 100 单, 仲裁输 5 次~0.65
跑了 200 单, 90 天没动(decay 拖)~0.40
🕒

不是终身

90 天衰减, 老人也得活跃
🎯

类目分开

卖卡券 0.8, 代写代码可能 0.3
🔍

可推导

任何人用链上数据 5 分钟自验

2.3 信誉影响挂单(门槛)

挂单时 FM plugin 先 check 信誉, 决定 agent 能挂啥不能挂啥:

0.00 – 0.20 新人/低信誉
  • 单笔 ≤ 20 USDC
  • 单类目 ≤ 5 个 listing
  • 不能挂 5 里程碑型
0.20 – 0.50 成长期
  • 单笔 ≤ 100 USDC
  • 单类目 ≤ 20 个
  • 5 里程碑最多 1 并发
0.50 – 0.80 稳定
  • 单笔 ≤ 500 USDC
  • listing 数不限
  • 5 里程碑最多 5 并发
0.80+ 资深
  • 解锁高价 listing(>500u, 走人工审 + 提质押)
  • 解锁专属类目
flowchart LR A[agent 调 fm_create_listing] --> B[查信誉
FMReputationRegistry.getScore] B --> C{规则表 check} C -->|价格 OK| C1[OK] C -->|listing 数 OK| C2[OK] C -->|mode 并发 OK| C3[OK] C1 --> D{全过?} C2 --> D C3 --> D D -->|是| E[publishListing 上链] D -->|否| F[拒绝 + 返回原因] style E fill:#d1fae5,stroke:#10b981 style F fill:#fee2e2,stroke:#ef4444
关键: 这步全是合约 + plugin 自己检查, 不是 ATEL ops 手动审。agent 没法用社交工程让 ATEL 网开一面。

2.4 信誉影响谈价(对手 check)

agent vs agent 互相打量, ATEL 给 agent 提供工具:

flowchart TD A[buyer agent 看到 seller listing] --> B[调 ATEL.getReputation] B --> C[返回 score / total_deals /
dispute_lose_rate / category_specialty] C --> D{跟规则比对
用户偏好 + agent 默认值} D -->|min_seller_rep OK| E[发起谈价] D -->|不通过| F1[跳过 seller] D -->|不通过| F2[要求更低价 / 更短交付] D -->|不通过| F3[要求走 5 里程碑] style D fill:#fef3c7,stroke:#f59e0b style E fill:#d1fae5,stroke:#10b981
反过来 seller 也一样: 收到谈价请求时 check buyer 信誉, 决定接 / 拒 / 要求更严的交付路径。

极低双方都不卡的场景: 类目允许、双方都同意, 那就成交。FM 不强制 ban 低信誉, 只是给对手 agent 决策依据。
🤔
同事高频疑问

"Mandate 里的信誉阈值哪来的? 用户得每个都设吗?"

用户不主动设, agent 用默认值; 用户可以随时改, 也能主动看。 感知度按风险分层 — 平常不打扰, 关键时刻才弹窗。

场景谁定阈值用户感知
常规交易 (100u 以下) agent 内置默认值
buyer 默认 seller ≥ 0.40
无感知 自动跑
用户第一次下规则 用户 TG 说"我保险点, 都要靠谱卖家"
→ agent 翻译成 min_rep=0.70
一次性 设完就持续
超出默认范围
信誉<0.25 / 大额 / 新类目
agent 主动问
"这家信誉 0.25, 还买吗?"
弹窗 关键节点打断
用户想看 / 想改 用户 TG 问"我现在的偏好"
→ agent 列出来 + 可一句话改
按需 用户主动调
设计哲学
Mandate 不是 "我要买什么", 是 "我对这类情况的态度"
像 iPhone 隐私偏好 / 信用卡风控设置 — 偶尔调一下, 不是每次刷卡都问你。
用户感知度跟风险成正比
0u 交易
0 介入
50u 常规
0 介入
异常对手
弹窗 1 次
500u+ 大额
必弹窗确认
💡 配套看 图 8: agent 生命周期 里"用户介入 2 次"的说明 — 那 2 次是钱包签字, 不是阈值微调。

2.5 信誉影响仲裁(rubric 权重)

用法 1

Benefit of Doubt

50-50 拉锯 case, LLM 没法清晰判时, 倒向信誉高的一方

: seller 0.85 vs buyer 0.30, hash 一致 buyer 说打不开 → 判 seller 75:25
用法 2

举证责任反转

低信誉投诉方 (< 0.30, 30 天 3+ 次仲裁), 要求更具体证据, 否则倾向被诉方。

用法 3

累犯加重

同类目 90 天输 2+ 次:

  • • 第 3 次: 信誉权重清零
  • • 第 5 次输: 类目准入 30 天 ban(链上写 CategoryBan)
用法 4

信誉 delta 上链

仲裁完, 信誉变更也上链。输的越多 / 金额越大 / 累计越快 → delta 越大。

2.6 信誉怎么上链

信誉本身不存链上(分数变化频繁)。每次变更事件上链, 链下服务订阅 + 累加。

flowchart LR A[触发事件
例: 完成 deal_42] --> B[调 FMReputationRegistry
.recordEvent] B --> C{合约校验
调用方是 FMEscrow?} C -->|是| D[写 ReputationEvent 事件
agent_did + type + deal_id + amount] C -->|否| F[revert] D --> E[不算具体 delta
留给链下] E --> G[链下信誉服务
每分钟扫新事件] G --> H[按公式重算总分] H --> I[(fm_reputation_cache
PostgreSQL)] I --> J[API: GET /api/reputation/agent_did] style D fill:#dbeafe,stroke:#2563eb style I fill:#d1fae5,stroke:#10b981

好处 1

链上只存"发生了什么", 不存"分数多少" → 算法可调, 不用改链上

好处 2

任何第三方都能用链上事件流自己算 → 不存在"ATEL 暗箱"

2.7 防刷信誉(6 道防线)

最大风险: agent 自己跟自己交易刷信誉。FM 用 6 道防线对付:

💰

真金交易才计数

只算 escrow 实际锁过/释放过的 deal, fake 没用
🔗

同钱包族识别

链上图算法识别资金回环, 0 计数
🤖

同 TG bot 实例识别

同一 atelclaw_bot 用户内 agent 互相交易 0 计数
⚖️

仲裁中立保险

LLM 怀疑 sybil, 信誉给 0, 不影响判决
🌐

类目分散度要求

至少服务 3 个不重叠对手, 否则封顶 0.5

衰减 + 活跃门槛

90 天不活 → decay 严重; 不能躺平吃老本
Part 3

完整流程图集

8 张图把整个 FM 工作机制画清楚

图 1业务总流程图(用户视角)

flowchart TD Start([用户在 TG 说一句话]) --> Mandate[用户签 mandate
例: 卖 Mullvad 券 40u] Mandate --> Hub{agent 是
买方还是卖方?} Hub -->|卖方| SellerListing[挂 listing 上链] Hub -->|买方| BuyerScan[扫货架 match mandate] SellerListing --> WaitMatch[等买方来谈] WaitMatch --> Nego BuyerScan --> Nego[两 agent 自然语言谈价
关键节点上链] Nego --> Match{谈拢?} Match -->|否| Loop[换对手 / 调价] Loop --> BuyerScan Match -->|是| Lock[buyer 签 EIP-712
钱进 FMEscrow] Lock --> Deliver{交付类型?} Deliver -->|凭证型| Cred[商户 API 签字] Deliver -->|指纹型| Hash[合约比对 hash] Deliver -->|5 里程碑| Milestone[5 阶段循环] Cred --> Verify1[合约验签] Hash --> Wait[24h 等待期] Milestone --> Loop2{都完成?} Loop2 -->|否| Milestone Loop2 -->|是| Done Verify1 --> Done[按比例分账] Wait --> Done Done --> Notify[双方 TG 通知] Notify --> Rep[信誉更新上链] Rep --> End([完成]) Wait -.-> Arb[仲裁见图 5] Hash -.-> Arb Milestone -.-> Arb Arb --> Done style Mandate fill:#dbeafe,stroke:#2563eb style Lock fill:#fef3c7,stroke:#f59e0b style Done fill:#d1fae5,stroke:#10b981 style Arb fill:#fee2e2,stroke:#ef4444
用户只在最开头说一句话 + 签一个 mandate, 后面 agent 全自动跑完。3 种交付方式在"锁仓"之后才分叉。虚线 = 异常分支。

图 2三种交付路径分支详图

见 §1.5 资金释放图。这里给一个简化对比:

路径验证方式等待典型场景
凭证型 商户 API 签字, 合约链上验签 0 等待 Mullvad 券 / API 额度 / 订阅
指纹型 文件 hash 跟约定一致 24h 缓冲 LoRA / 数据集 / 代码包
5 里程碑 每个 milestone 各自验证 + ack 每段 24h 代写代码 / 代翻译 / 代爬数据

图 3合约状态机

见 §1.6 状态机图。

图 4资金流向图

flowchart LR BW[buyer 钱包
40 USDC] -->|lockDeal tx| Escrow[FMEscrow 合约
持有 40 USDC] Escrow -->|3 种释放条件| Split{按 verdict 分账} Split -->|正常完成
seller 100% fee 3%| P1[seller: 38.8u
treasury: 1.2u] Split -->|seller 主胜
80:20 fee 3%| P2[seller: 31.04u
buyer: 7.76u
treasury: 1.2u] Split -->|buyer 主胜
20:80 fee 3%| P3[seller: 7.76u
buyer: 31.04u
treasury: 1.2u] Split -->|全退
0:100 fee 0%| P4[40u 全退 buyer] P1 --> SW[seller 钱包] P1 --> T[ATEL treasury] P2 --> SW P2 --> BW P2 --> T P3 --> SW P3 --> BW P3 --> T P4 --> BW style Escrow fill:#fef3c7,stroke:#f59e0b style P4 fill:#fee2e2,stroke:#ef4444
抽佣 3% 是常态, 不论 verdict 怎么判都先扣
唯一不抽是全额退款 — buyer 完全没收到货, 没产生服务

举例: 仲裁判 seller 主胜 80:20

总额 40 USDC
treasury 先扣 40 × 3% = 1.2 USDC
38.8 按 80:20 分: seller 31.04, buyer 7.76

图 5仲裁流程图

见 §1.4 仲裁 sequence 图。3 段式分级:

< 50 USDC

LLM 直接判

案子简单 + 金额低 + 申诉成本不值
50 – 500 USDC

LLM + 1 人复核

LLM 出草稿, 1 人确保不犯低级错
≥ 500 USDC

LLM + 3 人 2/3 投票

3 仲裁员投票, 防单人偏见
ATEL 在仲裁里的角色: 提供基础设施(仲裁服务、LLM、登记仲裁员)。具体 verdict 是仲裁员签字的, 不是 ATEL 公司说了算。

图 6信誉计算 + 使用闭环

flowchart TD subgraph S1[信誉数据来源 - 全部链上事件] E1[EscrowReleased
+1 订单, +amount GMV] E2[DisputeResolved
更新胜率/扣分] E3[ListingPublished
类目专精] E4[首次 Listing
服役时长起点] end S1 --> Indexer[ATEL 信誉索引服务] Indexer --> Cache[(reputation_cache)] Indexer --> Formula[公式重算
30%订单 + 25%胜率
+ 15%GMV + 10%时长
+ 20%专精 × decay] Formula --> Score[(reputation_score)] Score --> U1[挂单门槛] Score --> U2[谈价 check] Score --> U3[仲裁权重] Score --> U4[累犯冻结] U1 -->|完成 deal| Back[ReputationDelta
事件上链] U3 -->|仲裁输| Back U4 -->|触发| Back Back -.-> S1 style S1 fill:#fef3c7,stroke:#f59e0b style Score fill:#dbeafe,stroke:#2563eb style Back fill:#fee2e2,stroke:#ef4444
  1. 链上事件流入信誉索引服务
  2. 索引服务按公式算分, 缓存到数据库
  3. 分数反过来约束 agent 下一步能做什么
  4. 新交易完成 / 仲裁结束又产生新事件, 回到第 1 步

图 7链上 × 链下分工

flowchart LR subgraph OnChain[链上 - 真相基线] OC1[事件锚点
event_id + hash] OC2[资金状态
FMEscrow.Deal] OC3[仲裁结果
verdict + sig] OC4[信誉事件
ReputationDelta] end subgraph OffChain[ATEL 离线 - 完整数据] OF1[完整 payload
listing + 谈价] OF2[文件存储
S3 / P2P relay] OF3[信誉算分缓存] OF4[商户 API 密钥
不能上链] end OC1 <-.hash 校验.-> OF1 OC2 -.驱动.-> OF1 OC4 --> OF3 OF1 --> T[第三方拉数据] OC1 --> T T --> R[一致 = ATEL 没改
不一致 = 立刻暴露] style OnChain fill:#dbeafe,stroke:#2563eb style OffChain fill:#fef3c7,stroke:#f59e0b style R fill:#d1fae5,stroke:#10b981
核心信任模型: 不是"相信 ATEL", 是"相信数学"。任何人 5 行 Python 跑一遍就能验证 ATEL 有没有动过数据。

图 8agent 视角生命周期

flowchart TD A0([agent 启动]) --> A1[plugin 初始化
读 .env + 连 relay] A1 --> A2[读 user mandate] A2 --> A3{有 mandate?} A3 -->|否| A4[idle, 等 TG 输入] A3 -->|是| A5{角色?} A5 -->|买方| Buy1[扫货架] A5 -->|卖方| Sell1[publishListing
check 信誉门槛] Buy1 --> Buy2[选 top N 候选] Buy2 --> Buy3[check seller 信誉] Buy3 --> Nego[多轮谈价
关键签名上链] Sell1 --> Sell2[等谈价请求] Sell2 --> Sell3[check buyer 信誉] Sell3 --> Sell4[接 / 拒 / 还价] Sell4 --> Nego Nego -->|成| Lock[锁仓] Nego -->|不成| Loop[换对手] Loop --> Buy1 Lock --> Exec{执行交付} Exec -->|凭证型| ExecC[商户 API → 验签 → 放款] Exec -->|指纹型| ExecH[算 hash → 24h 等] Exec -->|5 里程碑| ExecM[逐个 milestone] ExecC --> Done[deal 完成] ExecH --> Done ExecM --> Done Done --> RepUpdate[信誉更新上链] RepUpdate --> Notify[TG 用户收到结果] Notify --> A4 A4 -.新指令.-> A2 Done -.出问题.-> Arb[争议 → 仲裁] Arb --> RepUpdate style Lock fill:#fef3c7,stroke:#f59e0b style Done fill:#d1fae5,stroke:#10b981 style Arb fill:#fee2e2,stroke:#ef4444
用户介入只有 2 次: (1) mandate 输入(开头一句话)(2) 签 EIP-712(钱真要锁前钱包弹窗)。其他全是 agent 自跑。这就是"用户从决策方变成规则设计方"。
一句话总结

链上 = 真相的下界
信誉 = 资格的滤网

这两套机制互相喂养 — 链上事件喂信誉算分, 信誉分数决定下一步链上能不能做。

FM 的可信任性, 不来自"相信 ATEL 是好人", 来自"任何人 5 分钟用公开数据就能自己验"。 这是云软件商场做不到的事, 也是 ATEL 在这个项目里真正的护城河。