Agent Market

Agent Market：现状 PRD 与项目讲述

1. 文档身份与事实口径

三本账，不能合成一个“全部上线”

现有材料冲突保留： README 的候选段仍写 release pending，而交付 TODO 与非 AWS JSON 台账已记录发布；TODO 总标题写 complete，其 System-One 扩展仍有未完成项。本文以具体版本、具体验收范围为单位，不沿用无范围的总状态。链上台账某些描述使用 createWorkflowTask，本轮所读合约实际入口为 createTask，接口说明以源码名称为准，不假设二者是同一版本 ABI。

2. 一句话定义与产品背景

一句话： 把“找智能体做任务”拆成可确认的任务计划、合格候选选择、受控执行、独立质量检查、争议处理和有证据的资金结算。

要解决的不是“再做一个聊天框”，而是三个问题：智能体能不能接这个任务；失败后由谁负责；页面上的“成功”有没有外部事实支撑。

产品假设是：需要研究、代码等交付物的发布方，希望看到明确验收条件、可解释选择和可追踪责任；Agent 提供方希望获得合理曝光、明确报酬和不被随意扣款的规则。没有本轮可查证的用户访谈、付费客户、收入或留存数据，以上是产品假设，不是市场验证结果。

按已确认简历，这是北京阿拉丁兼职经历下的项目；仓库中的课程实践标签与持续工程增强记录说明技术材料的起源和演进，不能覆盖履历归属。两层材料同时保留，不把上游 Laya/Jev 模型或框架本身算作本人原创产品，也不由兼职归属推导真实客户或营收。（E19）

3. 用户、角色、权限与场景

2026-10-12 企业审批 v1 增量： 提交者、一名独立审核员、文档归属部门授权管理员采用与钱包独立的企业身份。当前只是可切换的合成假身份。管理员只能按文档版本、成员、动作显式授予跨部门许可，不自动获取正文/执行/审批权；禁止自审与跨企业访问。（E20）

核心场景：发布研究或代码任务；按硬条件找 Agent；确认 Queen 计划；失败后修复或拒绝；验收后结算并评价；Owner 在本地试验台调用私有模型；通过 Cocos Office 查看脱敏任务状态。

当前不是 DAO 自动分钱系统。 旧委员会界面、治理审查、AI 终审、V3 合约仲裁四者不能混用。

4. 目标、成功指标与非目标

待实测指标：真实任务完成/验收率、争议归责率、冷启动曝光分布、用户满意度、端到端 P95 延迟、单任务成本、恢复可靠性、模型校准误差。没有真实数据就不填“提升 X%”。

非目标：主网真实收益承诺、无人工约束的自治支付、DAO 自动仲裁、持续生产服务等级承诺、通过合成样本宣称模型优于基线、在本轮新建云资源或部署。

5. 产品边界、模块与入口

新增 /enterprise 本地企业审批模拟入口及中英文菜单，客户端懒加载。确定性文本片段提取不是 AI 推理/OCR；模拟记录仅在浏览器内存中、刷新重置。没有接入生产 SSO、持久数据库、MCP 工具市场或真实业务系统；未发布。（E20）

上下游包括浏览器钱包、Cloudflare Edge、Transaction Engine、PostgreSQL/pgvector、Owner 本地 Runtime、Ollama/Provider API、Sepolia RPC、历史 AWS 性能链。The Graph 延期；Temporal 的本地恢复与生产服务是两回事。

6. 正常流程与失败/取消/恢复

目标业务闭环：本地模块具备，不等于当前生产全链路验收

发布方需求与验收条件
  -> 钱包会话、任务身份与权限检查
  -> 初步风险报价，发布方确认
  -> 合格候选过滤、匹配、Queen 提出计划和分配
  -> 最终报价 + 当前图版本 + 发布方和各 Agent 确认
  -> 生成资金意图，钱包签名，精确回执读回
  -> Agent 执行 -> 格式/安全 Gate -> Judge
  -> 高风险 Red Team -> AI Final Arbiter
  -> 交付物验收 -> 结算/退款读回 -> 合格评价

不同子系统的组合完整性需要端到端证据；上述箭头不宣称 9 月 UI 发布或 10 月 shadow 增强已在生产完成整条链。

补救、取消与恢复

Judge / Red Team 要求修订 -> Repair -> 再审
  修复最多 2 次；拒绝或耗尽 -> rejected
用户不批准计划 -> rejected；批准必须对应当前 revision/fingerprint
服务重启 -> 从持久化状态恢复 -> 重新检查服务端授权和操作键
外部操作已发生但响应超时 -> 对账/人工复核，不自动重复扣款
未启动链上任务取消 -> cancelBeforeStart -> 核对退款事件与状态
争议 -> 固定平台钱包 resolveTask -> 精确 TaskResolved 读回

真实历史恢复案例：Sepolia 第 17 笔 stake 领取已上链，但浏览器等待监听停止推进；以事件、独立 RPC 回执及 nonce/状态读回恢复，没有重复发送交易。它证明该次恢复，不证明所有钱包故障都已覆盖。（E03）

7. 需求矩阵

企业审批局部需求 ENT-01：合成文档只读分析、精确字符引用校验、独立人工复核、当前许可检查与幂等模拟写入。批准绑定文档/分析/工具版本及提交者/审核员授权来源；撤权后重新授权不能复活旧批准，当前版本授权不能查看历史版本私有记录。状态为已实现并通过有限本地验收，非生产交付。（E20）

下面 ID 是本文用于追踪的稳定标识，不冒充仓库旧需求 ID。P0 是安全/权威底线，P1 是产品闭环，P2 是优化。

8. 状态机与业务规则

工作流状态，不是钱包状态

StateGraph 源码状态为 planning、awaiting_approval、executing、reviewing、repairing、completed、rejected。repairing 出现在 schema；实际 Repair 节点返回 reviewing，不能声称每个枚举都已有独立可观察迁移。

合法主路径由图定义：Queen 规划 -> approval interrupt -> Agent -> Judge。Judge 通过后，低风险走 Final Arbiter，高风险先走 Red Team；要求修订且 repairCount < 2 才进入 Repair；其他结果拒绝。最终节点再次校验 Judge 通过，高风险还必须 Red Team 通过。（E09）

确认载荷必须绑定 graphRevision 与 taskFingerprint。每个节点先调用 authorize，因此从旧 Checkpoint 恢复不是重新获得业务权限。

幂等与不确定副作用

操作键由 scope、task、图版本、fingerprint、动作和修复次数确定。Ports 必须在外部副作用前持久化去重；Checkpoint 本身不能消灭“Provider 成功、存档失败”的崩溃窗口。

Outbox 认领、发布、标记已发布存在自己的失败窗口；源码接口不证明全局 exactly-once。消费者/下游仍须幂等，消息不是授权凭证。

报价与链上状态分别约束

风险报价分 preliminary/final；最终报价必须有 Agent 分配，分配总额等于 A；初步报价不能偷带最终分配。任务、图、预算、权限或策略变更需要新报价。

V3 合约状态包含 NONE/OPEN/IN_PROGRESS/DISPUTED/SETTLED_AGENTS/SETTLED_PUBLISHER/CANCELLED。成功交易不仅检查 receipt status，还检查合约、任务及匹配事件。交易等待超时是“结果未知”，不是“没发生”。工作流 completed 不自动等于合约 settled。（E10/E15）

9. 数据与领域模型

未查证统一的生产数据保留、备份恢复和用户删除流程；不能写成完整合规能力。私有概率记录的“手工清理”只是该分支已批准的策略，不代替其他表的删除政策。

10. API、事件与外部接口

源码合约名称包括 createTask、anchorWorkflow、assignNode、acceptNode、openDispute、resolveTask、claimStake、cancelBeforeStart。重要事件包括 TaskCreated、WorkflowAnchored、NodeAccepted、TaskResolved、StakeClaimed、TaskCancelled。（E15）

System-One 不是新增支付接口。Provider-neutral port 是 match、scoreQuality、routeDispute，返回 observed/fallback；coordinator 另有容量导致的 skipped。以上是内部程序接口，不虚构为公网 REST 路径。（E07/E17）

11. 架构与技术取舍

浏览器 React UI / MetaMask / Cocos 快照展示
           |
Cloudflare Edge：SSR、路由、会话代理、签名 Runtime 网关
           |
           +--> Transaction Engine --> PostgreSQL：任务/报价/订单/Outbox
           |             |
           |             +--> unsigned intent --> 钱包签名 --> Sepolia
           |                                         |       RPC/event 读回
           |
           +--> Owner 本地 Runtime：Queen / StateGraph / 私有 Provider
                         |          |
                         |          +--> PostgreSQL workflow/checkpoint
                         +--> Ollama / Provider API
                         +--> System-One shadow：Laya + 可选 Jev
                                  基线仍权威；公共摘要与拟建私有记录分离

独立历史性能链：HMAC API -> SNS -> SQS/DLQ -> dispatcher
                      -> ECS Fargate -> PostgreSQL -> 独立读回/暂停

图表达模块关系，不保证这些组件当前均在线。

采用 软件设计与思维方法（内部证据或非公开入口） 的原则：小接口隐藏复杂度；从权限与资金事实出发；确定性 Gate 先于模型判断；结论要能被失败样例推翻；小步修复而不是用框架名字替代质量。

12. Agent、System-One 与评测要求

模型负责建议，规则负责权限和金额

Queen 组织任务；执行 Agent 产生结果；Judge/Red Team 检查；Risk Assessor 输出有限因子。检索来源和交付物来源应按任务验收，不因本地课程助手存在就宣称全平台已经有生产 RAG（Retrieval-Augmented Generation，检索增强生成）闭环。

System-One 是三种决策的候选观察：agent_match、agent_quality、dispute_route。它不改变默认确定性决策，不作为付款条件。

当前 policy 为 system_one_dual_shadow_v1、mode: shadow、calibrated: false。门槛记录为 match/quality confidence 0.8、margin 0.2，dispute confidence 0.9、margin 0.3；它们是未校准策略参数，不是已证实概率可靠。

Laya 使用固定 revision/hash 的预装 ONNX（Open Neural Network Exchange）资产。Jev 只有显式启用、配置 key、正采样率和正请求预算时才创建；按 decisionId 确定性采样并限制请求数。不能偷偷追加调用来补评测数据。（E06/E17）

可观察不等于“可采纳”

合法 observation 仍可能是 accepted、abstained 或 below_threshold。Choice 校验允许池、概率范围/总和与所选最大值；quality 要五类 0..4，并核对连续分数与概率加权期望的一致性，不能四舍五入抹掉小数。（E07）

当前公共 Evidence 保存 sorted probability masses、selected/abstain probability 和结果摘要；排序后丢失类别对应关系，不能据此计算可信多分类校准。 用户已确认下一步把完整对应关系只写 Owner 私有持久记录；目前只有合同和 before 快照，没有实现或新测试结果。（E18）

10 月 11 日修复保留合法 reported input/output token：必须为 JavaScript 非负安全整数，0 有效；缺失/非法省略。它覆盖有效 observed 结果，不补造失败/超时消耗，也不能直接折算真实费用。（E07）

尚缺的评测合同

同一冻结、去重、脱敏、有代表性标签的数据集比较基线与候选；记录首次尝试与重试分母、模型/策略/资产身份、任务划分、拒答、分歧、延迟、费用和安全退化。再评估 Brier score（概率预测误差）与 ECE（Expected Calibration Error，预期校准误差）；当前未完成这组评测。

真实模型的三次离线合成输入 Smoke 证明可加载/可推理，13-case 合成 fixture 证明有限机制，都不证明业务准确率。未完成评测/校准前不得提升模型权威。

13. 非功能要求

安全与隐私： Hash-based Message Authentication Code（HMAC，消息认证码）保证请求完整性；keyId 对 public/owner scope 的访问控制列表分开。HMAC 不是钱包身份或任务授权。原始 Prompt、Provider key、本地路径、私有模型权重与关联钱包事件不得进入公开台账。低熵路由/分数的裸 hash 可被枚举，公开观测仍需隐私审查，不宣传“hash 就匿名”。

性能与降级： 基线即时返回，Provider 在后台观察。源码默认每 Provider 并发 1（允许配置上限 16），pending 128（上限 1024）；sink 限时默认 500 ms；Runtime Provider deadline 是两者配置最大值加 250 ms。这是代码约束，不是实测生产 P95。超时后底层工作未结束，容量仍须被占用，避免无限积压。

成本： Laya 本地模型资产约 1.69 GB 量级，不是“整个推理依赖很轻”；持久化私有记录必须单条/run/队列有界。Jev 费用和 AWS 配额独立控制，当前无完整单任务真实费用数字。不得改变免费套餐或新建重复基础设施来打卡。

维护与恢复： 小范围源码/测试/hash/receipt 一一对应；保留最初失败与修复记录；模型缺失 fail closed；启动未 ready 不泄露数据库连接；关闭结果 distinguish closed/deferred/failed。整体 Runtime 启动/收尾仍有缺口。

可用性承诺： 未测 uptime、持续吞吐、容量上限、RPO/RTO（恢复点/恢复时间目标）或生产 SLA（Service-Level Agreement，服务等级协议），不填虚构数字。

14. 测试、验收与发布分账

企业审批 v1 / 2026-10-12 / E20： 19/19 新领域测试、48/48 受影响路由/Edge 测试、Shared/Web 类型检查、Pages 客户端及 SSR/Worker 构建均通过；使用现有公共 Evidence，不执行生成器。独立审查首次 REPAIR 的三项修正后静态复审 ALLOW，九文件 SHA-256 匹配。主任务浏览器完成正负向、中英文和 1280/390 宽度验收。before 是特性实现后、await/类型修复前的快照，不是特性实施前基线；pnpm 入口异常曾下载/重建依赖，不能声称依赖环境未变。未运行全仓库完整 Gate，也未提交、推送或部署。

token 快照 SHA-256 为 8deebc93485f82ed4039f183310bc1469707dff3cdb3f206b8f0f06ca1ceed88；增量 hash 为 c3c3577b89c9ffdd5ac7536e7292c5ef95310e0e146b82fd44e75d0109467345。它们标识这次冻结内容，不是 Git commit。

本轮文档没有重跑测试、模型、构建或生产读回。历史数量按原记录日期引用，不相加成“最新通过总数”。

15. 本人职责与协作边界

用户已确认的事实： 用户提出产品流程、公平曝光、对称保证金、动态风险、状态图/持久存档、VRF 和 Evidence 展示要求；授权本任务实施、局部验证与既有复审，并明确 AWS 由专门任务统筹。已确认简历把 AM 与 BabySteps 列在北京阿拉丁兼职项目下，时间为 2025.06–2026.10；Personal AI Agent 另列个人工程，不混用归属。简历职位表述为“高级前端 / AI Agent 与 Web3 全栈协作”，保留职位名称与实际职责范围的区别，不擅自改成已确认的全栈岗位 title。（E19）

仓库/回执能证明的工程工作： 本项目已有 UI、契约、账本、Agent 工作流、Adapter、局部回归和独立审查记录。本轮增强把基线权威、未知 token 和资源关闭语义收紧。这证明项目中存在工程实现，不自动证明本人逐行独立手写。

需要本人核对： 原始课程任务与后续自研比例；个人写过/审过的模块；AI 辅助范围；协作人数及分工；实际最困难的问题与投入周期；是否有真实用户。不存在这些答案就不编 STAR（Situation/Task/Action/Result，情境/任务/行动/结果）故事。

Jev/Laya 上游模型、LangGraph、Temporal、Cloudflare/AWS 是依赖或平台，不是本人发明。Office 是展示边界；Dashboard 作品集索引、其他项目 Evidence 不由 Agent Market 随意改写。

16. 缺口、风险与路线图

项目讲述设计目标：完整方案与实施结果分开

本文区分完整设计方案与已有实现，不要求真实项目已经具备全部建议功能。下文保留 as-built 来源、版本和 E01–E20 的证据边界；设计完成、本地验证和生产交付各自判定。企业审批 v1 的本地结果见 E20，不代表 SSO、持久化或真实业务 Connector 已接入。

目标业务流程与失败分支（建议合同）

企业成员明确发起操作
  -> 认证适配器解析身份；检查组织、部门、角色、资料版本和当前授权
  -> 白名单只读工具执行；固定输入、工具与解析版本，传入 deadline / AbortSignal
  -> 输出 schema + 来源映射校验
  -> 保存私有结果及不可变内容身份；提交当前版本
  -> 非提交者且当前获授权的审核员人工批准 / 拒绝
  -> 条件校验批准、版本、有效期、提交者与审核员授权
  -> 模拟业务记录（已有 v1）/ 持久写入意图 + Outbox（建议）
  -> Connector 执行；精确对账后投影完成状态
  -> 公共视图仅显示脱敏状态，详细资料留在私有权限边界

无权或跨企业 -> 拒绝，不返回正文或私人历史
无可靠来源 / schema 错误 -> 拒绝分析，不进入批准
撤权 / 授权被替换 / 内容或工具变化 -> 旧提交或批准失效，重新走适用阶段
审核拒绝 -> 不允许业务写入
超时 / 服务中断 -> 保留真实占用与 unknown 状态，恢复先重新鉴权和对账
重复操作 / 消息重投 -> 同一业务绑定返回既有记录；键绑定冲突则拒绝
外部副作用已发生 -> 保留历史，不把撤权或回滚 UI 当成撤销了外部事实

最小接口、状态与技术取舍（建议，不是假装已部署的 API）

按软件设计与思维方法（内部证据或非公开入口）做取舍：基本事实是“谁能读、谁能批准、哪次副作用确实发生”，不是“用了多少框架”。Tool Port 要隐藏协议和凭据复杂度；不能把每个薄转发都做一个平台。规则 Gate 能确定的权限、schema 和版本不交给模型打分覆盖；新增功能与不改变行为的重构分开说明。

可执行验收方法：是检验方案，不是新增通过数字

以下 Given/When/Then 可由本地 fake Adapter、测试时钟、阻塞 Promise、模拟 Connector 和冻结 fixture 执行。此设计增量只写验收方法，不执行测试，也不要求先补实现再复习；只有 E20 明示的已跑结果可以使用通过时态。

当前最大风险不是缺少更多框架，而是不同版本/环境的成功状态串台，以及在评测未完成时赋予模型业务权威。

17. 项目讲述稿

本轮讲述口径与连续问答（统一复习入口）

事实用“在某版本/环境实现或验收过”；未实施方案用“我会这样设计”；学习内容用“我能解释并给出检验办法”。这三种答案可共同构成完整 PRD，不能相互冒充。以下直接给出可口述回答，仍需本人作答才能判断掌握程度；企业场景属于产品假设，不代表已核实客户需求；设计完整不代表真实产品已实现全部内容。

企业身份与逐资料授权

提问：企业成员想读文档、调用工具并批准写入，你怎样判断他能不能做？

可口述回答（约 30 秒）：我把“是谁”和“能做什么”分开。输入是 session、资料引用和操作，服务端解析当前 active member，再按组织、部门、角色、文档版本和 grant 校验；输出是允许的有界结果或拒绝原因，不让客户端提交可信 principal。钱包 Owner 不自动等于企业员工，权限管理员也不自动看正文。AM v1 用假身份验证过局部机制；真实认证只是设计目标。

机制追问：为什么不只用角色 RBAC？文档 grant、缓存和待执行消息如何配合？

回答：只有 reviewer 角色还不够，同一企业不同部门也未必能看同一份资料。我会用角色做动作准入，用文档/版本/成员/action grant 约束具体资源；这是组合授权，不是给所有复杂场景堆通配规则。纯部门 RBAC 更简单，但会扩大共享范围，只有产品确实允许部门级共享时才选。缓存必须按获准资源/版本隔离，访问和执行时检查当前授权；缓存命中不能跳过检查。待执行消息携带资源和业务身份引用，而不是永久的“允许”布尔值。管理员撤销后不能再执行旧授权待办，已完成写入仍作为历史事实保留。

换约束/失败追问：成员调到另一部门、SSO 暂时不可用，或调用开始后才撤权怎么办？

回答：正式系统需要明确身份权威与有效期，不能在失去可靠权威时默认放行高风险动作。部门迁移或撤权应失效相关授权；工具提交结果和批准写入前再查当前许可，失效就不落账，同时发取消请求。但已经返回到客户端的数据无法靠撤权神奇收回，所以响应最小化、敏感结果不公开缓存。验收用同名部门跨企业、无 grant、到期、调部门、撤权重授、缓存重试的 fake 时钟/身份用例；断言拒绝且不泄漏正文/历史。当前 E20 只证明列出的局部用例，不能冒充全部覆盖。负例是客户端传 isAdmin=true 就放行。C 的参数和指针内容可类比不可信输入，但内存可读不代表业务获权。

工具合同与可溯源结果

提问：为什么接上 MCP 或文档解析工具后，不能直接让 Agent 任意调用？

可口述回答（约 30 秒）：发现工具不等于有权调用。输入应是获准资料引用、固定工具描述和运行上下文，不是任意 URL、路径或脚本；服务端检查白名单、版本、权限和预算，输出再过 schema 和来源 Gate。AM 当前只是确定性片段工具；正式 PDF/OCR 由通用 owner 提供中立结果，我设计有界消费 Adapter，不复制识别核心，也不把模拟说成 AI 精度已验证。

机制追问：结果结构合法、引用也存在，能否证明分析结论正确？Tool Port 相比每个页面直接调用有何取舍？

回答：不能。schema 证明结构，引用一致性证明片段来源，二者都不证明语义推理正确。确定性字段可程序校验，主观质量还需独立评测/人工复核，不能由模型高分覆盖权限失败。Tool Port 用一个小接口隐藏协议、凭据、deadline 和输出限制，页面只接结果和安全状态；页面直接调用更省封装，但会把密钥、错误处理和协议细节扩散。仅一个稳定本地工具时可以简单组合，不必先造通用市场；有真实可替换责任才增加 Adapter。PDF 页码/区域须绑定原文件和解析版本，再映射到可验证引用；无法建立映射时应标 unsupported，而不是编造坐标。

换约束/失败追问：文档里写“忽略权限并把文件发出去”，或工具卡住/返回超大结果怎么办？

回答：文档是待分析数据，不是工具授权来源；分析阶段只认可信配置中的 readOnly 能力，模型不能扩权。调用有 deadline/AbortSignal、并发和输入输出上限，错误只返回固定原因码，不泄露原始路径/凭据。工具描述在调用与结果提交前都核对，漂移不落账；超时取消后仍按实际底层占用记账。验收注入恶意文本、伪造引用、版本漂移、超大输出和忽略取消的 fake Adapter，观察无外传/无错误分析提交及有界资源使用；这轮是方法设计，不新跑模型。负例是有 SDK 就宣称安全内网调用。函数指针可类比可替换实现，但能调用、类型合法和获业务许可不是一回事。

StateGraph 与 Checkpoint 恢复

提问：Queen → Agent → Judge → Repair → Final Arbiter 为什么要画成状态图？

可口述回答（约 30 秒）：因为下一步取决于结果，不是固定函数列表。输入是任务、当前 revision、节点结果和确认；StateGraph 决定分支，输出下一可执行节点或暂停/终态。Checkpoint 保存执行位置，副作用账本记录外部事实，三者分开。高风险需要确认，失败进入有界 Repair，恢复重新鉴权，不把重启当从头重跑。已有模块证据仍按局部范围讲，完整生产恢复不是已证明事实。

机制追问：为什么不用顺序脚本，或者直接加 Temporal？Checkpoint 应存哪些信息？

回答：单次简单流程可以用顺序脚本，分支、人工暂停、补救和恢复多起来才需要显式图。Checkpoint 应包含任务/图 revision、节点状态、允许的结果引用、当前待确认项、预算和执行身份引用，私有结果按权限存储；恢复加载后再查真实权限和版本。Temporal 如用于长期定时、耐久执行与 Activity 重试有价值，但不会自动解决业务幂等；没有这种责任时再加一层反而增加运维和理解成本。图可以调度建议，必须保留独立 Judge/Final Arbiter 与确定性 Gate，不能让规划模型自行跳过拒绝分支。

换约束/失败追问：节点提交外部写入后宕机，用户又取消任务，恢复时怎么做？

回答：取消先阻止新的可执行节点，并向活跃调用传取消信号；已发生副作用不能被“cancelled”状态抹掉。恢复按操作键/回执查询外部状态：已完成则记事实、未发生且仍获授权才继续、未知则对账或人工审查，不能直接重发。验收在批准前、调用中、回包后保存前分别注入崩溃，用 fake Connector 的调用计数和持久日志观察没有重复副作用；再用旧 revision、撤权和新增高风险节点证明恢复不能跳过确认。闭包是短期变量环境，不是跨进程存档；ELF 装载恢复程序映像，不恢复业务执行位置。

批准的版本与授权来源

提问：审核员点了批准以后，为什么还要在写入前检查一遍？

可口述回答（约 30 秒）：批准针对一个确定快照，不是永久开关。输入是当前文档/分析/工具版本、内容身份与双方授权来源；输出是一份可被复核的批准记录。写入前重新检查，内容改版、工具变化或 grant 被替换就不能沿用。AM v1 的局部版本/授权机制验收过；正式政策版本、批准有效期和并发事务是设计补充，不说已经上线。

机制追问：审核员看 v1，提交者并发更新 v2，怎样保证不会批准错版本？为何不能只比较内容 hash？

回答：审核命令带 expectedVersion 与 analysisRef，服务端事务/条件更新同时核对版本、内容、当前状态和授权来源，不符合就拒绝，不靠前端按钮加锁。hash 证明内容身份，但不证明谁有权批准、工具/政策是否变了，也不证明批准仍有效。只有内容 hash 的方案简单，却遮蔽权限与政策变化；我选择显式版本和来源绑定，代价是需要清楚定义哪些变化使批准 stale。若批准/写入需跨存储，还要指定一致性边界，不能说 CAS 自动锁住外部系统。

换约束/失败追问：撤权后又重新授权，内容完全相同，能否复用旧批准？

回答：不能自动复用。旧提交依赖的授权来源已经失效，新 grant 是一次新授权，必须重新提交并由独立审核员确认适用快照；这也是 v1 修正的实际漏洞之一。工具运行中变版本，结果提交时拒绝，不标成旧工具成功。取消应阻止尚未发生的写入，但保留已完成记录。验收安排并发 v1/v2、撤权重授、相同文本不同分析或工具、过期批准的用例，断言没有新 mock/真实意图；前两类与工具漂移已有 E20 局部结果，其他方法不能算已跑。负例是仅存 approved=true。闭包捕获的引用仍可变，不能替代服务端版本锁。

幂等、Outbox 与副作用对账

提问：用户多点一次、队列重投一次，为什么不会写出两份业务记录？

可口述回答（约 30 秒）：输入用作用域明确的 operationKey，并绑定同一业务资源和批准；输出返回已有记录或拒绝键绑定冲突。AM 企业 v1 只用有界 Map 做进程内模拟，不能保证跨进程。正式方案要有持久唯一约束、事务内写入意图和 Outbox，外部结果未知先查询对账；我不把“接口只回一次”说成全链 exactly-once。

机制追问：为什么不用数据库写完立刻发消息？SNS/SQS/DLQ 和补偿扫描各负责什么？

回答：数据库与消息系统是两个提交点，先写后发之间会崩溃，先发后写也可能出现无账任务。事务内把业务意图和 Outbox 一起保存，派工器扫描发送；发送成功但确认丢失会重复，所以消费端还要按业务键幂等。SNS 做扇出、SQS 做有界派工/重试，DLQ 保存超过重试策略的失败消息，补偿扫描查“账有而状态不前进”的意图；DLQ 不是业务账本，也不是无限重放授权。只一个短事务且无外部副作用时可以直接写，Outbox 不是所有按钮必加；有跨系统责任时才承担它的运维成本。

换约束/失败追问：Provider 已执行但超时，不支持幂等键，取消后能否再次发送？

回答：不能以超时或取消推断未执行。我会先查稳定业务引用/外部流水，能对账再推进；既不支持幂等也无法查询时，明确不能安全自动重试，进入人工审查，不宣称 exactly-once。取消只停止未发出的动作，已发出结果待对账；消息重放也重新鉴权。验收用模拟 Connector 记录调用次数，注入 DB 提交后崩溃、重复投递、执行后丢回包、键冲突，断言一个业务效果或明确 unknown/manual_review。负例是每次重试换 UUID。Map 类比去重表，只在当前进程成立；ELF 符号唯一性不是数据库唯一约束。

超时、取消与容量账

提问：接口超时了，为什么还说后台任务占着并发容量？

可口述回答（约 30 秒）：超时是等待截止，不是实际终止。输入包括 deadline、AbortSignal 和容量上下文，输出区分及时成功、失败、取消请求和结果未知。适配器忽略 signal 时还在跑，实际 settle/退出前继续占槽位，阻止重试堆积。v1 有这一局部容量机制；生产各 Provider 和子进程的完整回收仍按各自证据讲。

机制追问：为什么 Promise.race 不能直接停止调用？等待任务结束和杀进程有什么取舍？

回答：race 只选择首先 settle 的 Promise，不自动取消其余工作。AbortSignal 是通知，Adapter 要主动传给 I/O 或检查；不服从时需要隔离运行和受控终止策略。等实际结束避免误释放，但慢任务占容量；强制终止更快，却可能丢清理和副作用结果，必须指定安全边界。查询型工具可丢弃晚到结果；写入型工具仍要保存 operationKey 并对账。内存 timer、请求超时与 Provider deadline 还要统一，不让一层已超时、下一层继续无限重试。

换约束/失败追问：用户取消后立刻重新提交，而旧调用晚到成功，会出现什么？

回答：旧调用仍活跃就拒绝/排队新请求，容量与取消身份不能被新请求覆盖；晚到只用于释放/对账，不把旧运行结果写到新 revision。真实子进程需观察退出和清理，而不是看到 signal 发送就报完成。验收用可控 Promise 忽略取消，先超时再重试，观察 active 仍在、无第二次调用、晚到无提交；再让它实际 settle，验证容量恢复。当前 E20 证明超时保留容量，不冒充其余组合也跑过。C 的返回、fd 关闭、进程退出是不同事件；JS Promise 拒绝不代表系统资源停止。

Shadow、评测与成本计数

提问：Laya/Jev 的候选模型怎样进入业务，又怎样证明它比基线好？

可口述回答（约 30 秒）：当前候选先 shadow 旁路观察，业务先返回基线，不让未校准 confidence 决定权限或金额。输入是同一任务的受限特征和候选身份，输出是候选决策、拒答、概率与延迟/计数记录。token 局部通过不证明质量更好或完整成本更低。设计上要用冻结标签集、隐私安全记录和安全发布 Gate 才讨论灰度接管，不报没有测过的提升百分比。

机制追问：为什么不用 confidence 超过一个阈值就自动选模型？sorted probability masses 有什么问题？

回答：confidence 可能未校准，阈值只是政策参数，不是可靠性证明。概率排序后若丢了 label 映射，就不能把每类概率和真实标签对应，不能据此算可信多分类校准；私有记录应保留映射和样本身份，公共 Evidence 只放允许的摘要。直接替换基线更快，但可能把效果回归暴露给用户；shadow 更安全却增加资源成本，所以要限流、deadline、样本量与保留范围。比较时冻结去重数据与划分，区分首次尝试/重试分母，记录拒答、分歧、安全失败、延迟和 reported/unknown token，不把缺失填零。

换约束/失败追问：模型超时、输出坏 JSON、标签不足或费用未知时，还能上线吗？

回答：坏输出不进入业务决策，超时取消并返回基线，底层占用照实记；费用未知单列，标签不足不能宣布已校准。先明确候选目标和允许回归，做代表性冻结集评测与关键安全用例，达到预先约定 Gate 后才评估有限灰度；这里没有新测数字。验收以离线 fake Provider 验证 fallback/坏输出/缺失计数，再用经授权的数据评测真实效果，不拿演示集代替生产分布。负例是答对几题或 token 缺失记零就宣布更便宜。C 数组排序需保留索引映射，但这个类比不证明样本代表性。

可解释匹配与公平边界

提问：新 Agent 没有历史分数，怎样既给它机会又保证任务质量？

可口述回答（约 30 秒）：我把准入和曝光分开。输入是任务约束、Agent 能力/访问范围、信誉及候选身份；先硬过滤，再规则排序，从合格新人里分配有界探索，输出候选和原因，不把不合格模型靠洗牌选进来。公平需要曝光/选择记录和可解释规则，VRF 只可能证明随机源，不能证明候选池或身份公平。相关完整公平效果是设计与评测目标，不是已经证明的数字。

机制追问：为什么不完全按历史分选，或完全随机？什么时候才引入历史数据训练？

回答：完全按历史分会让新人永远缺样本，完全随机又可能忽略能力/风险。选择先做准入 Gate、再受限探索，按类别/能力/风险分组观察曝光与履约，不保证所有人一样机会。评价资格、去重、关联主体和真实交付证据决定历史能否用；未经清洗的历史会学到刷分、曝光偏差和任务泄漏。有足够且有代表性的合法数据，再用时间/主体隔离的评测比较规则基线和学习排序，先 shadow 不直接接管。成本是日志与审计复杂度，替代方案是继续规则排序，数据不足时更可解释。

换约束/失败追问：新人反复失败、关联钱包刷好评，或随机源不可用时怎么办？

回答：质量/安全 Gate 优先于探索，失败进入限制/退出探索与补救，不为“公平”绕过验收。关联评价应拒绝或隔离，保留原因和申诉路径，不只用地址是否不同来判独立性。随机源不可用就按事先声明策略暂停随机选择或使用明确标记的替代，不伪造 VRF 证明。验收固定候选 fixture，断言越权/不合格永不召回、重复主体不放大曝光、同输入原因可解释；公平效果需真实分组测量，不能由一次通过推断。C 随机排列只是索引重排；对象引用、钱包和现实主体不等价。

链上回执与最终仲裁

提问：界面说任务完成了，就能给 Agent 打钱或者给发布方退款吗？现在 DAO 决定吗？

可口述回答（约 30 秒）：不能把界面状态当资金事实。输入是获授权意图、具体合约/方法/业务任务，输出应分别记录钱包签名、交易提交、回执、事件和结算状态。AI Judge 只是判断材料，既有 V3 的最终权威是固定平台仲裁钱包，不是 DAO 多数票。历史 Sepolia 闭环有范围和单 EOA 限制，不能证明多钱包隔离或当前网页直接发过交易。

机制追问：链上回执为什么还要核对地址和事件？若想加 DAO，替代方案是什么？

回答：status 成功只证明那笔交易执行成功，仍须核对预期链、合约、调用与匹配业务事件，不能把无关交易当本任务结算。还需声明确认/finality 策略与重组处理，具体参数不能未经场景就报为生产配置。DAO 可作为咨询或复核，也可重新设计最终裁决，但必须明确角色、仲裁规则、延迟、冲突与合约升级/迁移，不能靠改文案把固定仲裁者变成投票。固定仲裁更简单、责任明确，但中心化；DAO 增加治理与攻击面，是否采用是产品/合约决策，不是现有既成事实。

换约束/失败追问：交易已发出但页面取消，回执未找到，或者发生重组，怎么回复用户？

回答：取消页面不能撤销已广播交易，先保留原 hash 和意图身份，显示待确认/unknown，不立即重复发或宣称退款。查询精确交易及预期事件，按已定义最终性策略对账；无法判断就停止自动推进，恢复也不盲重发。验收先用模拟 RPC 注入 pending/reverted/无关事件/重组/重复响应，断言状态不会虚假 settled；真实测试链操作需独立具体授权与回读，不是本轮文档任务。负例是 HTTP 200/截图就报钱到账。ELF 链接装载可类比阶段分账，但不是共识、权限或资金证明。

SSR、Hydration 与 Cocos 私有边界

提问：为什么用 SSR/Hydration，还把 Cocos 和 Evidence 媒体延迟加载？

可口述回答（约 30 秒）：输入是路由、公开初始状态和构建版本，服务端先给可用 HTML，客户端接管交互；输出不是只有一张截图，而是可读、可降级的页面。重媒体/Cocos 按需加载降低首屏负担，失败显示真实离线状态。Cocos 只拿脱敏快照和选桌动作，不拿执行、下载或钱包权限。已有 SSR/Cocos 证据与本轮有限页面验收分账，不冒充新的全站性能提升。

机制追问：纯 CSR 更简单，为何不选它？Hydration 不匹配时怎么办？

回答：纯 CSR 可减少服务端状态一致性责任，但弱网络/大包时首屏依赖下载执行；SSR 能先读内容，代价是构建/初始状态一致性与服务端开销。选择取决于公开路由与交互需求，不是 SSR 一定更快。服务端和客户端保持同一初始版本，记录可恢复错误；严重失败只做有界 CSR 回退，不能重复循环渲染。未知路由仍真实 404。Cocos 用小消息合同与 allowlist 字段，隔离展示和业务权威；iframe 不是天然可信主体，origin/消息类型和资源身份都要检查。

换约束/失败追问：媒体加载失败、Runtime 离线、用户切路由/取消，或 iframe 伪造执行消息怎么办？

回答：旧路由请求取消或按运行身份丢弃，不把旧结果写进新页面；媒体失败保留替代文字和重试边界，Runtime 离线明确标出，不展示成功结果。iframe 只允许合同内的选桌消息，伪造批准/执行/下载一律不能推进业务。验收固定桌面/移动、语言和网络条件，检查溢出、深链、404、水合错误、切路由陈旧结果以及恶意消息；性能比较在同条件记录 TTFB/LCP/交互与错误，不从单截图推断改善。负例是 SSR 200 就宣称所有交互成功。公开对象投影可帮助理解最小字段，但 JS 私有字段、闭包和 iframe 都不能替代服务端访问控制。

以下为基于事实的复述草稿。“我”仅在本人确认对应职责后使用；未确认时说“项目中实现了”。

30 秒

Agent Market 是我参与北京阿拉丁兼职期间的可验证智能体协作项目。它把任务计划、候选匹配、执行、独立质量审查和结算分开，重点是模型不能决定权限或资金。项目有具体版本的 Web、测试链和历史 AWS 性能证据；现在做 Laya/Jev 双影子比较，确定性基线仍权威。最近完成的是 token 计数局部修复，45 个受影响测试通过，不把它说成模型效果已验证。

90 秒

这个项目面对的是“智能体回答了，但交付有没有完成、钱该给谁”的问题。发布方先明确验收，再确认计划、候选和报价。Queen 组织任务图，Agent 执行，Judge 独立检查，高风险增加 Red Team；失败只能有界修复。Checkpoint 负责保存进度，恢复时仍要重新授权，不能凭存档重放扣款。

资金和业务事实放在确定性账本及合约边界，浏览器钱包签名，独立回执决定链上完成。公平性通过硬过滤、可复现探索、置信度感知信誉和可审计风险报价表达，不宣称绝对公平。历史 UI 发布、24 笔 Sepolia 回执和 AWS 性能样本各自有证据，但不能互相替代。

当前 Laya/Jev 只在后台 shadow 做匹配、质量和争议路线观察，立即返回原基线。难点是超时后底层工作还活着，以及计数缺失不能当零。最近 45/45 是后者的局部验收；完整 Runtime 收尾和代表性评测仍待补齐，未把增强发布为生产。

5 分钟提纲

1. 背景（约 30 秒）： 聊天结果、任务完成、支付成功是三件事。按确认简历说明阿拉丁兼职归属，课程标签只解释技术材料起源；产品假设与真实客户分开，不虚构客户。
2. 目标与流程（约 60 秒）： 从验收条件、初步报价、候选/计划确认讲到执行、Judge/Repair、验收/争议/结算。指出 AI Final Arbiter 和平台仲裁钱包不同。
3. 架构（约 60 秒）： Edge UI/SSR；Transaction Engine 和 PostgreSQL；Owner Runtime 与 StateGraph；钱包/Sepolia；独立历史 AWS 性能链。模型是建议依赖，规则与回执是权威。
4. 机制难点（约 75 秒）： 硬过滤后冷启动探索；报价与本金/费用分离；Checkpoint 不等于 exactly-once；Shadow timeout 后保留底层容量；missing token 不能伪造 0。
5. 取舍（约 45 秒）： 为何先 deterministic baseline 再 shadow；为何暂缓 The Graph；为何完整 label 概率图选择 Owner 私有；为什么不让模型直接裁钱。
6. 证据与边界（约 30 秒）： 展示一个版本绑定的外部台账、一次局部 RED/GREEN+独审；结尾主动声明生产增强和校准仍未完成。

优先挑一个本人真正能解释源码的机制深入，不背全部框架清单。没有本人承担的具体事故，就用“回归测试发现的问题”而不是“我处理过线上事故”。

18. 追问树与大白话复习

将现有知识接到项目，不新增课程或题号

复习时间与深度按实际理解程度调整，不采用固定工时作为掌握证明。已掌握的机制压缩复述，薄弱的输入/输出、取舍、失败恢复和验收展开练习，不为了旧工时删内容，也不无边际加课。统一入口仍是本 PRD 的连续问答，不另建平行教材/重复题库。每轮按“提问 -> 本人回答 -> 机制追问 -> 回答 -> 换约束/失败追问 -> 回答”推进，先由本人作答再对照；文档写完不代表已掌握，编码/部署不是复习前置。

复述时必须能回答六件事：已有版本做到了什么；设计输入输出是什么；为何选它及替代方案；接口/状态如何组织；失败或取消如何处理；怎样验收并反驳错误解释。直接使用 §16 的 Given/When/Then 与 §17 的连续问答；换约束用于检查迁移理解，不制造重复题库。本人回答正确且能处理负例则压缩，不能解释关键边界就延展，实际掌握待本人作答。真实企业客户、内部系统、个人手写范围和未测性能数字继续标为未确认，不能从方案完整反推项目上线。

具体公平与金额公式（按源码契约及 README 已记录策略理解，不是收益承诺）：

rawScore = 0.35*delivery + 0.25*quality + 0.10*communication
         + 0.15*dispute + 0.15*experience
confidence = n/(n+10)
reputation = 30 + confidence*(rawScore-30)

P = 任务本金；A = 单方保证金；B = 独立平台费
publisher = P+A+B；Agent Team deposit = A
R1..R5 保证金比例 = 5%、10%、15%、25%、40%
R5 强制人工复核；金额使用 atomic 整数

风险八因子权重：复杂度 20%、验收歧义 15%、外部依赖 10%、数据敏感性 15%、资金风险 15%、不可逆性 10%、期限 5%、Agent 不确定性 10%。手续费历史默认 6% 不能擅自提升为所有版本恒定商业政策。

历史测试链 Vault 有预先注资奖励池的收益领取回执；商业方案里的保证金复利仍不能称真实平台收入或保本收益。两种材料不能互相代替。

19. 演示顺序、证据索引与必要确认

项目讲述演示顺序

1. 先说明这是哪次发布/本地增强，打开市场与 Evidence，让评审看到事实边界。
2. 展示 Agent 资料/Owner-only、任务验收条件、匹配解释；示例数据明确说示例。
3. 展示风险报价：P/A/B、版本、确认和不变式，而非承诺收益。
4. 展示 Queen 条件分支与确认/恢复；用源码或已有回归证据讲清权限重新检查。
5. Office 展示快照和状态；说明 Cocos 不执行钱包或授予权限。
6. 展示仲裁页面与 V3 台账，说明固定钱包和单 EOA 测试边界，不触发新交易。
7. 展示 System-One 代码与 45/45 回执，说明 off/shadow、缺失 token、未校准与未部署。
8. 结尾打开缺口表，坦诚完整 Runtime/代表性评测等还未完成。

参考站点：项目、Evidence。本文仅提供定位，不表示本轮已访问或实时可用。

本地证据索引

只有本人能回答的 Grill-me 问题（不阻塞本文）

E20 企业文档审批 v1 本地验收增量

• 设计、实现及30/90秒讲述稿（内部证据或非公开入口）
• 验收与边界记录（内部证据或非公开入口）
• 最终独立静态复审（内部证据或非公开入口）
• 浏览器结果（内部证据或非公开入口）

工具消费边界：AM 当前合同是有界文本、文档版本、摘要/固定问题枚举、严格原文字符位置与引用片段，不是 PDF 页码/坐标/OCR 结果合同。通用 document parser 尚未接入；只读选型或其他 owner 的消费者合同不能当 AM 已兼容。原文识别/版面解析留给通用核心，AM 只承担结果合同校验、受控调用、权限审核和模拟写入。真实持久化/认证、更多过期/队列组合覆盖及生产集成仍待独立范围确认。

1. 本人贡献： 你能逐行解释且实际参与实现/审查的两个模块是哪两个？A：明确模块与动作；B：主要提出需求和验收、代码由 AI/协作实现。允许混合，但请逐模块说明。
2. 材料起源与本人贡献： 阿拉丁兼职归属已按确认简历记录，不再由旧课程标签覆盖。哪些技术材料来自课程、哪些是兼职中的新增设计，哪些由你实现/审查？请逐项说明，不把材料起源、雇佣关系和独立原创混为一谈。
3. 用户与商业： 有没有实际使用者或付费任务？A：没有，保持产品假设，阿拉丁兼职归属不变；B：有可脱敏的记录。没有用户/收入记录不能反推任职归属。
4. 经历故事： 哪次失败是你亲自发现、判断并推动修复的？请给当时决策和参与分工，而不是只给测试通过数字。

文档完成范围： 已覆盖 19 节现状 PRD、三种讲述长度、12 个机制追问和版本化证据索引。项目本身仍有未完成项；本文没有修改业务代码、实施私有 Evidence、运行测试、下载模型、推送或部署。