M6第 4 课 · 交易研究台M6-L4.2M6-L4.4

Technical Design：交易研究台

一句话： 一份在不断变化的数字之上做多 agent 决策支持的参考设计：确定性后端计算并存储每一个数值，agent 通过按角色限定的工具解读和提出异议，时点数据配合每次运行的截止时间，规则在只跑一次的 holdout 之前冻结，每个判断都经过发布检查，并按实际发生的结果打分。

教学参考。 这份设计遵循 handbook 的九节骨架，来源是 Trade Recommendation Desk 的 Sprint 1 技术设计文档，该文档本身已经达到参考标准。第 8 节补充了生产部署需要的内容；第 9 节概括当前构建。

1. 设计原则

后端做决定，agent 负责解读。 每个价格、信号、规则输出和组合估值都由后端计算并存储。agent 决定看什么、说什么，只通过 evidence ID 引用数字。

2. 架构与所有权

PM ⇄ 主频道 ⇄ Desk Lead ⇄ 每个专家一个私有频道 ⇄ Technical · Volume · News · Fundamentals · Risk
                        │                                                │
                   工具适配器（按角色限定的工具）◄───────────────────────────┘
                        ▼
                   API（只在本机，每个角色一个 key）◄── 前端（卡片 + 来源抽屉）
                        ▼
   run manager · 规则引擎 · 发布服务（9 项检查）· 策略与回测 · 模拟组合与结果
                        ▼
   evidence store + 只追加账本   ·   不可变数据快照   ◄── 数据导入（公告、价格）

组件	负责
数据导入与快照	每次数据加载写入一次，附哈希和可得时间
Evidence store	每个被展示或引用的数值：来源、期间、可得时间、校验状态
策略引擎与回测	两个信号、初始观点、变体、期间、成本、基准
规则引擎	由初始观点、agent 信号和风险规则得出最终判断和信心等级
发布服务	用 evidence ID 组装判断并运行九项检查
Run manager	运行状态，以及 Desk Lead 下一步该发什么
工具适配器与 API	按角色限定的工具；每个角色一个 key；进入后端的唯一路径
Agents	审阅、挑战和解释，从不计算
前端	卡片和来源抽屉，只从 API 读取

3. 信任边界与 gate

agent 不能把数字敲进判断里。 判断由 evidence ID 组装；agent 文本中出现数字会触发发布检查第 1 条。
时间由读取路径强制执行。 每次读取都经过运行截止时刻的时点视图；截止时间之后的证据触发检查第 4 条。
规则在 holdout 之前冻结， holdout 命令拒绝第二次运行或被修改的规则。
人工 gate 放在无法挪动的位置： 成功门槛在验证结果出现前批准；冻结在 holdout 前审阅；每周流程由人启动。
没有下单路径， 一旦出现，仓库扫描会让构建失败。

4. 状态与数据

运行状态经过 commissioned、collecting、assembled、published，或以 blocked、failed 结束；run manager 保存状态，所以没有 agent 需要记住它，重复唤醒不改变任何东西。
只用首次报告值； 重述永远不会替换早期日期的数值；期间按长度识别，从不按标签。
只追加的记录覆盖信号、风险评估、规则输出、判断和发布尝试；修改后的判断是一条新的关联记录。
变体日志和 holdout 账本让每次测试和唯一一次 holdout 都可审计。

5. 独立检查

四个信号 agent 从不同证据出发审阅引擎的初始观点；BUY 或 SELL 需要其中三个不反对。
Risk agent 是隔离的：它的任务简报从不包含其他 agent 的信号，没有工具会把信号返回给它，它的首次评估带哈希存储。
风险规则和 agent 的反对只能下调判断，永远不能上调。
Risk agent 本身也用埋入反证和干净用例来评估，所以它的识别率和误报率是已知的。

6. 失败处理与幂等

失败	行为
专家超过期限	视为反对该判断
Risk agent 超过期限	整次运行失败
agent 文本中出现数字	退回一次；第二次失败则运行失败
其他任何发布检查失败	运行失败并公布原因
运行进行中收到新问题	拒绝，并附当前运行的状态
过期或重复的唤醒	幂等的工具和已保存的状态意味着什么都不会改变

7. 评测与测试

单元测试覆盖信号计算、期间处理、反应日规则、规则引擎、每项发布检查、成本和打分。
一个答案已知的黄金数据集，包括一次重述、一次拆股、一次盘后发布和一只永远不应入选的股票。
一个通过真实 API 扮演全部六个 agent、不消耗额度的模拟器。
十个故意攻击产品规则的 guard test。
设计期、验证期和只跑一次的 holdout 期回测；前向模拟交易；每个判断在复核日后打分。

8. 运维

Sprint 1 的设计运行在一台机器上，由人启动每次流程。生产部署需要补充：

调度每周流程，并保持”绝不在过期快照上运行”的保证。
纯规则基准组合， 让 agent 相对规则的贡献被衡量，而不是被假定。
密钥与角色在仓库之外管理；按角色的 key 定期轮换；API 一旦离开本机就要放在认证之后。
监控： 逾期的 agent、被拦截的运行、快照新鲜度、额度用量，以及每次运行的模型和 prompt 版本清单，以便归因结果。
备份 evidence store 和快照，可以恢复到任意一次运行。

9. 当前构建

Sprint 1 的构建按上述第 1 至 7 节实现：带按角色工具的六 agent 名单、evidence store 和时点快照、带 18 个有日志变体的策略引擎、规则引擎和九项发布检查、run manager、模拟器和 guard test，以及带模拟交易和结果打分的每周流程。第 8 节列出它有意留给后续阶段的内容。

典型面试题

这个设计如何防止 agent 引用截止时间时还不存在的数字？

agent 只能通过在运行截止时间读取时点视图的工具获得数值，每个数值都带可得时间，发布检查会拦截任何截止时间之后的证据。一个 guard test 会加入截止时间之后的数据行，并要求结果不变。

为什么一次运行无论覆盖一只还是十只股票，消耗的 agent 唤醒次数都一样？

每个专家的输入工具一次返回本次运行的所有股票，每个专家只提交一次，所以次数取决于角色和交接的数量，而不是股票数量。这让共享额度下的用量可以预测。