Capture · 采集原始行为

用户通过推荐链接/二维码/渠道入口触发行为。系统在第一时刻捕获原始信号，包含渠道标识、时间戳、设备指纹。

Normalize · 标准化上下文

不同渠道的信号格式不同（抖音/小红书/微信/美团/飞书），Normalize 层统一为标准 Signal 格式。

Verify · 验证行为真实性

4-Gate 验证体系启动：来源验证 → 因果验证 → 完整性验证 → 时间验证。

Commit Signal · 生成可信 Signal

验证通过的 Signal 写入哈希链，追加 SHA-256 哈希节点，保证不可篡改。

Attribution · 建立归因关系

确认 Signal 之间的因果关系：哪个推荐触发了哪个转化。验证归因成立而非声明成立。

Optimize · 反馈优化策略

基于验证结果和 Trust Score，反馈给 Agent 优化推荐策略。

主路径 vs 异常路径

主路径（Happy Path）：CREATED → REFERRED → CONVERTED → SETTLED — 归因验证全链路通过，最终结算锁定。

异常路径：EXPIRED（超时过期）、ANOMALY（验证异常，可人工审核恢复）、DISPUTED（归因争议，可解决恢复）、REJECTED（验证失败终态）。

🔒 标记的状态为不可逆终态，一旦进入不可恢复。

GATE 1 · 来源验证

确认信号来自声称的渠道。校验渠道回调签名、Agent 注册有效性、入口参数合法性（防注入/防重放）。

GATE 2 · 因果验证

确认推荐确实导致了咨询，咨询确实导致了成交。验证事件之间的因果关系成立，排除独立行为。

GATE 3 · 完整性验证

哈希链无断裂，从 CREATED 到当前状态连续。每个事件的哈希 = SHA256(事件数据 + 前一哈希)。

GATE 4 · 时间验证

事件时序合理，无回跳或异常间隔。0秒内完成推荐→成交 = 刷单特征，自动标记。

链式结构

每个事件生成一个哈希节点：hashₙ = SHA256(事件数据 + hashₙ₋₁)。每个新哈希包含前一哈希，形成链式结构。

不可篡改

修改任何一个历史事件 → 该事件哈希变化 → 后续所有哈希全部失效 → 链断裂。无需检查全部数据，只需验证最后一个哈希。

不可伪造

每个事件由产生它的 Agent 使用 Ed25519 签名。修改任何字段 → 签名验证失败。无法伪造他人签名的事件。

不可抵赖

签名者无法否认自己签过的事件（Ed25519 的不可抵赖性）。结合哈希链，任何人都可以独立验证整条审计链。

审计追溯

从最终结算的 SETTLED 状态，可以逆向追溯完整路径：结算 → 成交 → 咨询 → 推荐 → 渠道来源。每一步都有哈希验证和数字签名。

Trust Score

基于完整验证链计算的信任评分（0-100）。默认结算阈值 60 分。Trust Score = 全链路行为追踪 + 不可篡改审计日志 → 信任评级。

结算条件

• 4-Gate 全部通过
• Trust Score ≥ 阈值（默认 60）
• 哈希链完整无断裂
• 数字签名全部验证通过

数据安全

传输加密（TLS 1.3）、存储加密（AES-256）、哈希链验证（SHA-256）、Ed25519 签名。

访问控制

RBAC 权限模型、API 安全（速率限制 + Token 验证 + 白名单）、合规认证（等保合规 + 数据隐私）。

第三方审计

安全审计日志、漏洞赏金计划、第三方审计报告。

8层安全架构

• Layer 1 网络层：TLS 1.3 加密传输、DDoS 防护
• Layer 2 身份层：Ed25519 数字签名、Agent 注册验证
• Layer 3 数据层：AES-256 存储加密、字段级脱敏
• Layer 4 验证层：4-Gate 验证体系
• Layer 5 审计层：SHA-256 哈希链、不可篡改日志
• Layer 6 信任层：Trust Score 计算、结算条件校验
• Layer 7 应用层：API 安全、速率限制、输入验证
• Layer 8 治理层：合规审计、权限管理、策略执行

6协议

• TLS 1.3（传输）
• Ed25519（签名）
• SHA-256（哈希链）
• AES-256（加密存储）
• OAuth 2.0（认证）
• RBAC（授权）

Business Twin Layer

企业级数字孪生系统。将线下商业实体的规则、流程、策略映射为可验证的数字模型，实现归因验证与企业业务逻辑的深度融合。

多租户架构

企业级数据隔离，每个租户独立的验证链、信任评分、审计日志。支持跨租户的渠道归因验证。

自定义验证规则

企业可自定义 Gate 验证条件（如最低成交金额、特定渠道权重、自定义时序规则），满足不同业务场景。

API 集成

• POST /v1/action — 创建 Action ID
• GET /v1/action/{id} — 查询 Action 状态
• POST /v1/verify — 触发验证链
• GET /v1/audit/{id} — 获取审计记录

SLA 保障

99.9% 可用性、端到端验证延迟 < 200ms、7×24 技术支持。

为什么需要 Behavior ID

传统归因模型基于 Link Attribution：

AI Native 场景下，归因路径变成了：

没有跳转。没有链接。没有二维码。但归因依然存在——这就是 Behavior ID 要解决的问题。

Behavior ID 生命周期

与 Action ID 的关系

Behavior ID 不替代 Action ID，而是叠加层。一次 AI 推荐（1个 Action ID）可能产生多个 AI 行为：

ID 格式规格

Behavior ID 遵循与 Action ID 对称的设计原则：

• beh_{timestamp}_{random} — 前缀 beh_ 区分于 Action ID 的 act_
• 示例：beh_1717920001_x7k2m9p0
• 关联字段：action_id 指向父级 Action ID
• 类型字段：behavior_type 标识行为类型（skill_invoke / agent_decision / workflow_step / auto_convert）

小红书 RED Skill 示例

以小红书 AI Skill 场景为例，展示 Behavior ID 如何在无链接环境下完成归因：

SDK 全家桶

接入示例：小红书 RED Skill

SDK 嵌入 AI Skill，用户无感知，后台完成归因：

基础设施类比

支持的 AI Skill 平台

对接方式：SDK 嵌入，不是跳转

很多人想错了——不是引导用户跳网页，而是在 Skill 内部完成归因：

信号入口，不是产品

所有 AI Skill 平台都只是 Fly 的"信号入口"。Fly 的核心资产始终是：

信号源全景

三层信号源

Fly 的位置

Fly 不属于任何一个平台，Fly 在所有平台之间：

• 不是渠道——Fly 验证渠道，但不产生流量
• 不是 Agent 平台——Fly 验证 Agent 行为，但不构建 Agent
• 不是 SaaS——Fly 是嵌入层，不是独立应用
• 是基础设施——类似 Stripe 处理支付、Cloudflare 处理网络、Twilio 处理通信，Fly 处理归因验证

Fly 是什么？

AI Agent 信任与归因基础设施。不是 AI 生成工具，不是自动化工具，而是验证 AI 行为是否可信、归因是否真实的基础设施层。

什么是 Action ID？

每条 AI 推荐生成的唯一归因协议标识。从点击→咨询→核销全链路可追溯。查看 Action ID 生命周期 →

Fly 如何验证归因？

4-Gate 验证体系：来源验证 → 因果验证 → 完整性验证 → 时间验证。每一步都校验，任一失败 = 归因链失效。

Fly 是渠道吗？

不是。Fly 验证渠道，但不产生流量。抖音、小红书、微信、美团、飞书是流量渠道，Fly 验证这些渠道的归因是否真实。

数据安全吗？

8层6协议安全架构：TLS 1.3 传输加密、AES-256 存储加密、SHA-256 哈希链、Ed25519 数字签名。前端不收集商业敏感数据。

如何接入？

通过 RESTful API 接入。POST /v1/action 创建 Action ID，GET /v1/action/{id} 查询状态，POST /v1/verify 触发验证。查看 API Playground →