mlb-decision-logger

MLB Decision Logger

目录

• 示例
• 工作流
• 常见模式
• 防护措施
• 快速参考

示例

场景：2026-04-17 的早间简报中，三个 Agent 同时提交结果。每个 Agent 都将决策数据交给此技能。2026-04-21（星期一），教练对星期五的阵容决策进行校准。

流程：

1. mlb-lineup-optimizer 提交 Junior Caminero 的首发/替补决策。
2. mlb-waiver-analyst 提交针对一名两场先发替补投手的 FAAB 报价。
3. mlb-streaming-strategist 提交一项临时补员操作。

技能行为：

• 读取 tracker/decisions-log.md 当前末尾的内容。
• 通过统计当天同类型条目的数量并递增，自动分配 decision_id（2026-04-17-lineup-01、2026-04-17-waiver-01、2026-04-17-stream-01）。
• 根据 context/frameworks/decision-log-format.md 中的架构验证每份数据。
• 按时间戳顺序逐条追加，并在每次写入之间重新读取末尾内容。
• 将分配的 decision_id 返回给调用该技能的 Agent。

星期一校准（2026-04-21）：

• 读取所有 will_verify_on <= 2026-04-21 且 outcome_recorded_on 为空的条目。
• 对于每条记录，Agent 通过网页搜索结果，并将结果传递给此技能。
• 技能会就地编辑目标条目（仅修改三个结果字段），并在 tracker/variant-scoreboard.md 中递增对应行的数值。
• 根据每个 Agent 最近 20 条已验证决策中的支持方/批评方计数，重新计算 tilt。

步骤 1 中追加的示例条目：

### 2026-04-17T08:30:00Z | lineup | mlb-lineup-optimizer
- **decision_id:** 2026-04-17-lineup-01
- **recommendation:** START Caminero at 3B
- **signals_in:** caminero.daily_quality=78 (matchup=85, form=72, opportunity=80)
- **variants:**
    - advocate -> "Start: strong matchup vs RHP, hitter-friendly park, batting 3rd"
    - critic -> "Sit: 0-for-12 last 3 games, BABIP-driven regression due"
- **dialectical_synthesis:** Advocate wins -- matchup+opportunity outweigh slump. Confidence 0.72.
- **red_team_findings:**
    - severity: 2, likelihood: 3, score: 6, note: "MIA rain watch", mitigation: "Check 1pm forecast"
- **confidence:** 0.72
- **will_verify_on:** 2026-04-18
- **outcome_recorded_on:**
- **outcome:**
- **variant_that_was_right:**

星期一校准后，最后三个字段会被填入；mlb-lineup-optimizer 对应的记分板行会递增 Total decisions、Advocate correct（如果 1-for-4 并打出 1 分打点，则计为成功）和 Synthesis correct；并重新计算 Tilt。

工作流

复制此检查清单，并跟踪每次调用的进度：

Decision Logger Progress:
- [ ] Step 1: Determine mode (append vs calibrate)
- [ ] Step 2: Read current log tail
- [ ] Step 3: Validate payload against schema
- [ ] Step 4: Serialize write (append or in-place edit)
- [ ] Step 5: Update scoreboard (calibration mode only)
- [ ] Step 6: Return decision_id and confirmation

步骤 1：确定模式

支持两种模式。每次调用恰好触发一种。

• append —— 调用方 Agent 传入完整的决策载荷。技能会创建新条目。
• calibrate —— 调用方 Agent 传入现有的 decision_id 及结果字段。技能会就地编辑该条目并更新记分板。

完整的决策树请参见 resources/methodology.md。

步骤 2：读取当前日志末尾

每次写入前都要重新读取日志。这样可以在没有真正文件锁的情况下，对并行 Agent 的并发写入进行串行化。

• 读取 tracker/decisions-log.md 最后约 80 行。
• 解析最后一个条目的时间戳和 decision_id。
• 如果自本次调用开始后有其他 Agent 写入，记下今天已使用的新 decision_id 编号。

完整的串行化协议请参见 resources/methodology.md。

步骤 3：根据架构验证载荷

检查每个必填字段。如有字段缺失或格式错误，则拒绝处理（不写入）。权威架构见 context/frameworks/decision-log-format.md；resources/template.md 与其逐字一致。

• timestamp_iso8601 为 UTC ISO 8601 格式（YYYY-MM-DDTHH:MM:SSZ）。
• decision_type 属于枚举值：lineup | waiver | stream | trade | category-plan | playoff-push | add-drop | ad-hoc。
• emitted_by 是已知的 Agent 名称。
• recommendation 以行动动词开头（START、SIT、ADD、DROP、BID $X、ACCEPT、COUNTER、REJECT、STREAM、HOLD）。
• signals_in 至少引用一个信号名称。
• variants 同时包含 advocate 和 critic 条目（引导初始化时可明确填写 n/a）。
• confidence 在 [0.00, 1.00] 范围内。
• will_verify_on 为日期、end of week N 或 end of season。
• 对于 calibrate 模式：outcome 为 {happened, did not happen, partial} 之一；variant_that_was_right 为 {advocate, critic, both, neither} 之一。

步骤 4：串行化写入

• append：使用 {YYYY-MM-DD}-{decision_type}-{NN} 格式分配 decision_id，其中 NN 为当天同类型条目序号加 1，并补零至 2 位。追加格式化后的条目，并在末尾添加分隔行。
• calibrate：通过 decision_id 找到目标条目，只替换三个结果字段，其余内容逐字节保留。
• 切勿覆盖整个文件。切勿重排条目。切勿编辑三个结果字段以外的字段。

写入协议请参见 resources/methodology.md。

步骤 5：更新记分板（仅校准模式）

• 读取 tracker/variant-scoreboard.md。
• 找到对应 emitted_by Agent 的行。
• 将 Total decisions 加 1。
• 将 Advocate correct、Critic correct 中对应的项加 1；若 variant_that_was_right = both，则两项都加 1。若综合建议符合实际情况，则将 Synthesis correct 加 1。
• 根据 resources/methodology.md 中的规则重新计算 Tilt。
• 写回更新后的表格；其他文本保持不变。

步骤 6：返回 decision_id 并确认

• 返回分配的 decision_id（append 模式），或确认已校准的字段（calibrate 模式）。
• 如果验证失败，返回包含字段名称和原因的结构化错误；不要写入。
• 使用 resources/evaluators/rubric_mlb_decision_logger.json 验证最终输出。最低标准：平均分不低于 3.5，且任何评估项都不得低于 2。

常见模式

模式 1：并行 Agent 追加（晨间简报）

Coach 在一次运行中启动 lineup-optimizer、waiver-analyst 和 streaming-strategist。每个 Agent 都会完成自己的变体对，进行综合分析，然后调用此技能。此技能按到达顺序串行处理它们，并在每次写入前重新读取日志末尾，为每种类型分配唯一的 decision_id。

模式 2：周一校准检查

Coach 打开日志，筛选 will_verify_on <= today 且 outcome_recorded_on 为空的条目，并对每个条目搜索结果、构建校准负载，然后以 calibrate 模式调用此技能。每次调用编辑一条条目并更新记分板中的一行。

模式 3：交易决策（按需，延迟验证）

交易报价到达时，mlb-trade-analyzer 会启动。决策为 REJECT、ACCEPT 或 COUNTER。由于交易价值会在数周内逐渐显现，will_verify_on 通常设为 end of week N 或 end of season。此技能照常记录日志；在验证日期到来前，该交易会在校准队列中保持“未结”状态。

模式 4：初始化 / 临时条目

对于球队初始化或元决策（更改权重、修订框架），decision_type = ad-hoc 或 bootstrap，variants = n/a，variant_that_was_right = neither。此技能会将其视为特殊格式并接受。

防护措施

1. 只追加。 永远不要重写日志，也不要重新排列条目。唯一允许的编辑是在校准期间填写现有条目的三个结果字段。任何其他修改都是错误。

2. 每次写入前都重新读取。 并行 Agent 共用同一个文件。紧接写入前读取日志末尾，是实现串行化的基本机制。不要使用本次运行中更早时候缓存的日志末尾内容。

3. 写入前进行验证。 格式错误的条目会污染下游校准。应以结构化错误拒绝，不要尝试部分写入，也不要自动修复缺失字段。

4. decision_id 是确定性的。 同一天、同一类型，按顺序使用 NN。如果另一个 Agent 已使用 2026-04-17-lineup-01，则此 Agent 使用 02。绝不重复使用 ID。

5. 结果字段编辑必须精准。 填写结果字段时，只替换三个目标行。逐字节保留时间戳、decision_id、建议、变体、综合分析、红队分析、置信度和 will_verify_on。如果写入前需要重新排版，说明操作有误。

6. 记分板更新对每个决策都是幂等的。 每个 decision_id 恰好使行数增加一次。如果重试校准调用，请重新检查条目是否已填写 outcome_recorded_on；如果已填写，则不要重复计数。

7. 判断倾向需要足够的样本量。 当该 Agent 的 Total decisions < 10 时，报告 neutral。只有样本量和差值均达标后，才切换为 advocate+ / critic+。确切阈值请参阅 resources/methodology.md。

8. Agent 绝不能直接写入日志。 每个 MLB Agent 都必须通过此技能操作。如果 Coach 发现了并非由此技能生成的格式错误条目，应将其视为错误，并记录在 tracker/calibration-review.md 中。

快速参考

模式输入：

• append 需要：timestamp_iso8601、decision_type、emitted_by、recommendation、signals_in、variants (advocate + critic)、dialectical_synthesis、red_team_findings、confidence、will_verify_on。
• calibrate 需要：decision_id、outcome_recorded_on、outcome、variant_that_was_right。

decision_id 格式：

{YYYY-MM-DD}-{decision_type}-{NN}
e.g., 2026-04-17-lineup-01

倾向阈值（每个 Agent，最近 20 个已验证决策）：

条件	倾向
已验证总数 < 10	neutral
Advocate 正确率比 Critic 高 10 到 20 个百分点	advocate+
Advocate 正确率比 Critic 高 20 个百分点以上	advocate++
Critic 正确率比 Advocate 高 10 到 20 个百分点	critic+
Critic 正确率比 Advocate 高 20 个百分点以上	critic++
相差在 10 个百分点以内	neutral

涉及文件：

• yahoo-mlb/tracker/decisions-log.md（追加，或针对结果字段进行精准编辑）
• yahoo-mlb/tracker/variant-scoreboard.md（递增行数据，重新计算倾向）
• yahoo-mlb/tracker/calibration-review.md（仅当高置信度决策错误时写入）

读取文件：

• yahoo-mlb/context/frameworks/decision-log-format.md（记录的架构）
• yahoo-mlb/tracker/decisions-log.md（尾部内容，用于序列化和分配 ID）
• yahoo-mlb/tracker/variant-scoreboard.md（用于校准更新）

关键资源：

• resources/template.md：与 decision-log-format.md 格式一致的精确条目格式。
• resources/methodology.md：追加协议、校准协议、并发处理、倾向重新计算、示例日志序列。
• resources/evaluators/rubric_mlb_decision_logger.json：包含 8 项标准的质量评分细则。

所需输入：

• 来自调用 Agent（append）：如上所述的完整决策负载。
• 来自调用 Agent（calibrate）：decision_id 和已验证的结果字段。

生成的输出：

• Append 模式：分配的 decision_id，以及条目已写入日志的确认。
• Calibrate 模式：已更新条目的确认，以及发生变更的记分板行。
• 验证失败时：结构化错误（字段名称、原因、违规值），不执行写入。