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

逐层增加复杂度

一句话： 从一句”这只股票该不该买？“的 prompt 出发，每次只加入某个失败迫使你加入的东西，就会一层一层走到 Sprint 1 的研究台设计；其中每一层都是为了消除一种答案可能出错的方式。

怎么读这一页

Syllabus 为复杂 agent 系统描述了一条演进路径：只有 prompt，然后是 skills、数据工具、新鲜度 gate、挑战与辩论、记忆和工作区，最后是评估。本页以 Sprint 1 的 Trade Recommendation Desk 为对象，把这条路径当作一次设计推演走一遍。对每一层，说明是哪种失败让它变得必要，以及当前设计中由哪个组件来承担。

PRD 一开头就列出了这些失败。AI 给出的买卖观点往往有这些问题：数字没有出处或取自错误的期间；回测用到了当时还不存在的信息；规则在历史数据上反复调参直到好看；结果忽略了成本或大盘本身的涨跌；判断发出后从未与实际结果对照。下面每一层都关闭其中一种或几种。

第 0 层：一个 prompt

让一个能力很强的模型对某只股票给出观点，你会得到一个流畅的回答。它也许是对的，但没人能判断：它的数字来自模型的记忆，时间范围不清楚，也没有任何东西记录这个判断后来是否成立。PRD 清单上的每一种失败都仍然存在。这是后续整个设计要反驳的基线。

各层

层	在 Sprint 1 设计中加入了什么	消除的失败	延伸阅读
1. 角色与指令	六个 agent，每个只做一件事，各有一个指令文件 `agents/<role>.md`。Desk Lead 是主频道中唯一的声音；每个专家与它共享一个私有频道。	一个声音混杂所有视角，没人对任何部分负责	案例概览
2. 数据工具	`desk-mcp` 只给每个 agent 它所属角色的工具；`desk-api` 是进入后端的唯一通道，每个角色一个 key。工具返回的每个数字都带 evidence ID。	凭记忆回忆或临时抓取的数字	Technical Design
3. 数字归后端所有	Evidence store 记录每个数值的来源、期间和时间。判断由 evidence ID 组装，发布检查 PUB-001 拦截 agent 文本中敲出的任何数字。	agent 把真实数字转述错了	Technical Design
4. 时间 gate	通过时点视图读取的不可变快照；每次运行有截止时间；只用首次报告值；盘后财报从下一个交易日算起；PUB-004 拦截截止时间之后的证据。	前视偏差，以及重述后的数字泄漏到过去	Technical Design
5. 挑战	四个信号 agent 审阅引擎的初始观点，BUY 或 SELL 需要其中三个不反对。一个隔离的 Risk agent 在看不到它们结论的情况下站在反方，其首次文本带哈希存储。风险规则只能下调判断。	片面的判断，或只是附和他人的异议	PRD
6. 状态放在 agent 之外	Run manager 保存每次运行的状态，并告诉 Desk Lead 下一步发什么。信号、评估、判断和发布尝试都只追加；修改后的判断是一条新的关联记录。	agent 在多次 Puffo 唤醒之间丢失进度，或历史被改写	Technical Design
7. 评估	设计期、验证期，以及在冻结规则上只跑一次的 holdout；每个变体都有日志；每个结果都含成本和两个基准；前向模拟交易；每个判断在复核日后打分；用埋入反证和干净用例测试 Risk agent；十个 guard test。	过拟合，以及从未被核对的判断	PRD、Technical Design

每一层的代价

复杂度不是免费的，设计对代价写得很明确：

角色消耗唤醒次数和额度。无论覆盖多少只股票，一次运行都保持在 11 次 agent 唤醒，因为每个角色的工具一次调用就返回所有股票。
工具消耗工具调用次数。Puffo 每次唤醒允许 10 次，所以每个角色都设计成 8 次以内完成。
后端掌管数字消耗工程时间。财报数据客户端、run manager 和发布服务是 Delivery Plan 中最大的三个任务，各需 4 天。
评估消耗日历时间。成功门槛必须在验证结果出现之前批准，规则必须在 holdout 之前冻结，这就固定了里程碑的顺序。

没有加入什么

同样重要的是那些问题本身在 Sprint 1 中并不需要的层。PRD 没有纳入定时任务、期权及其他资产类别、电话会议记录和分析师预期，也没有纳入纯规则对照组合。这些以后都可以加。但要让已发布的判断做到有出处、按时点、可打分，也就是 Sprint 1 要证明的东西，它们一个都不需要。

搭建顺序不等于分层顺序

上面的分层是从模型往外走。Delivery Plan 的搭建方向几乎相反：除了第 1 周检查 Puffo 能运行两个 agent 并调用一个测试工具之外，数据、快照、evidence store 和后端 API 最先完成（第 1 至 3 周）；agent 和工具适配器在它们之上搭起来（第 3、4 周）；然后是规则引擎和发布服务（第 5 周）；评估最后进行（第 6 周 holdout，第 6 至 8 周前向流程）。agent 是产品中看得见的部分，但只有掌管数字的部分已经存在，agent 才值得信任。

常见误区

“agent 是最复杂的部分。” 大部分工程量在它们下面：数据、证据、规则、发布和测试。agent 的职责被刻意收窄。
“每加一层，答案就更聪明。” 大多数层让答案更可核查，而不是更聪明。第 3、4、7 层完全没有增加新的洞见，它们只是去掉了出错的方式。
“一开始就把所有层都加上。” 这里的每一层都由一种具体的失败来证明其必要。没有这种失败的问题，就不需要这一层，这正是 Lesson 1 到 3 停得更早的原因。

典型面试题

客户的原型只是一个给出股票观点的 prompt。你先加什么？为什么？

先问哪种失败伤害最大。通常是数字没有出处，所以第一步是返回带标识符数值的数据工具，并规定发布的数字来自数据存储而不是模型的文字。接下来是时间 gate，因为带前视偏差的回测会让之后的所有结果失去意义。

为什么计划要先建后端再建 agent？

因为只有当数字、时间规则和发布检查已经存在时，agent 的输出才值得信任。先建 agent，只会得到一个建立在无法验证的基础上的漂亮演示，之后还得围绕 agent 的行为反过来改造后端。

如果研究台只汇总每日新闻、不给出判断，你会去掉哪些层？

规则引擎、回测、holdout 和模拟组合是为了生成判断并打分而存在的，所以可以去掉。时间 gate 以较轻的形式保留，因为汇总仍然只应使用运行之前发布的新闻。来源链接保留。是否需要 Risk agent，取决于片面的汇总对读者来说是不是真实的问题。