AICAP-180 · 前沿 AI 能力训练
面向 DeepSeek 模型策略/Agent Harness PM ∪ Anthropic Applied AI Architect ∪ OpenAI SA/FDE 的并集门槛 —— artifact-first：把「学过」升级成「建过 + 量过 + 能为取舍辩护」。逐日笔记，由浅入深（B1→B18）。
180 天能力训练大纲
180 篇逐日深度笔记 · 18 批次（B1-B18）
- DeepSeek V4-Flash 79.3% / V4-Pro 89.7% completion（真模型，非 mock）
- A/B 配对 Δ+10.3pp 95% CI [0,20.7] — N=29 不显著（eval 严谨的活教材）
- 真网络 MCP server + OAuth 2.1（401/200 已验）· 423 测试绿 · 5 轮对抗审查
配套：计划与长文 · 代码在仓库 src/agent/eval · src/agent/mcp · src/aml（无 key 全部真建真测）。
B1
evals 方法论 + tokenization 起步Day 1-10eval 方法论总览
这是 AICAP-180 整条能力曲线（B1→B18）的第 0 米：在动手写任何模型、tokenizer、agent loop 之前，先把「怎么判断一个 AI 系统做对了」这件事的心智框架立住。整条计划的隐性铁律是「只有笔记没有数 = 这天没学会」，而「数」从哪来、靠什么判定可信——答案就是 eval。今天不碰模型，只读一篇方法论 + 通读已在仓库里的任务套件，把每条任务拆到 task / tri
三种 grader
昨天（Day 1）把 eval 切成 task / trial / outcome 三层，并立下「判分锚定可判定的最终产物」。今天往下钻一层：outcome 到底由谁来判。这就是 grader 三件套——code-based / LLM-judge / human——以及它们各自的盲点。这条线很关键，因为整个 P1 评测体系的可信度上限就是 grader 的可信度上限：grader 不准，下游 c
BPE/tokenization 原理
前两天（Day 1/2）立的是 eval 方法论：怎么判、谁来判。今天转入 B1 的第二条主线——tokenization，回答一个看似无关其实极现实的问题：调用模型要花多少钱。OpenRouter 按 token 计价，而 token 不是字符也不是单词，是 BPE 切出来的子串。要在发请求前预估成本，就得先理解 token 怎么来的。今天只学原理 + 手算，为 Day 7-9 自写 byte-
OpenRouter 接入
Day 3 把 token 怎么来的讲清楚了，但 token 只有换算成钱才有决策价值。今天接通真实计费侧：OpenRouter 统一路由多模型，按 input / output token 分别计价，各模型上下文窗口不同。要在跑全套 eval 前预估成本，就得先对比候选模型的单价与窗口、并发一个 ping 确认链路通。这是 B1 从「纸面 token 数」到「真实美元」的桥。最小可判定产出：.e
跑通 eval harness
Day 1-2 立方法论、Day 3-4 接 token 与计费。今天把它们拧成一台能跑的机器：eval harness——给一个具名模型跑整套任务，输出 completion%（达标 outcome 占比）+ 总 cost + commit hash 三个可引用的数。这是 B1 的第一个「真产物」原型：从此评测不再是论述，而是一份带 commit 的报告。但诚实地说，真 cost 要 key；h
解析首跑结果
在 B1→B18 整条能力曲线里，B1 解决的是最底层的问题：怎么判一个 AI 输出对不对、贵不贵。
byte-level 编码器 (1)
B1→B18 能力曲线上，Day 1-6 是「评测方法论」这条支线，Day 7-10 切到「tokenization 工程」这条支线——但两条线在 B1 末尾会合。
byte-level 编码器 (2)
Day 7 写完了编码器骨架（vocab/merge 表/encode/decode），但留了一个洞：merge 表是从哪来的？
全量编码 + token 报告
B1 tokenization 支线到今天才接上「为什么要自写 tokenizer」这个动机：token 数直接决定 OpenRouter 计费（cost ≈ token × 单价）。
双数对齐收口
Day 10 是 B1（Day 1-10）的收口日，也是 B1→B18 能力曲线的第一个里程碑。
B2
attention/decoder/KV + judge 校准Day 11-20Scaled dot-product + causal mask
B1（Day 1-10）把「评测方法论 + tokenization + 成本对齐」打底完毕——我们已经能数 token（1760 token 实测）、能把 cost 和 token×单价对齐。但那是把模型当黑箱看「外部行为」。从今天起 B2 进入模型「内部机理」：Day 11 拆开 decoder 的最小原子——单头 scaled dot-product attention + causal m
Multi-head + decoder block 结构
Day 11 把单头 causal attention 跑通并用单测证明了「未来不影响过去」。但单头只能学一种「关系」。今天 Day 12 沿能力曲线上爬一格：把 d 维投影切成 h 个头各自做 attention 再拼回（multi-head），并把它包进一个完整 decoder block——causal multi-head attention + 残差 + LayerNorm + FFN
Reference 对齐
Day 11-12 我们手写了 attention 与 decoder block，单测证明了它「causal 且 shape 对」。但「不泄露未来 + 形状对」不等于「数值算得对」——一个把 √d 缩放写错、或 LayerNorm 漏了除标准差的实现，照样能通过 causal 单测却给出错误的 logits。今天 Day 13 补上 B2 这块拼图最关键的一环：数值对齐——固定权重与种子，把我们
KV cache 原理
Day 11-13 我们把 decoder block 写对、验对了（causal + 数值对齐）。但「正确」之外，自回归生成还有「快」的问题——朴素实现每生成一个 token 都重算整条前缀的注意力，是 O(n²) 的纯浪费。今天 Day 14 引入推理侧第一个、也是最基础的优化：KV cache——把历史 token 的 K/V 存下，每步只算新 token，把每步注意力从 O(n) 总量重算
采样策略
Day 11-14 我们把 decoder 写对、验对、加速（KV cache 让逐 token 解码划算）。但模型每步输出的是一个整个词表上的概率分布——怎么从分布里挑下一个 token，就是「采样策略」，它直接决定输出的确定性 vs 多样性、稳定 vs 发散。今天 Day 15 把解码侧的旋钮系统化：greedy / temperature / top-p / top-k / structur
JSON-validity sweep
昨天（Day 15）我们把采样策略的「机理」过了一遍——greedy / temperature / top-p / top-k 各自怎么改写概率分布，以及为什么 structured output 要在解码阶段就用 grammar 约束。
LLM-as-a-Judge 偏差
Day 16 我们用温度扫描量化了「自由采样会破坏严格格式」；今天把镜头从「被评的输出」转向「评分的判官」。
人工金标准
Day 17 我们认定「judge 不校准就不可信」，并备好了 rubric 与 50 条待标清单。今天动手把那 50 条标成人工金标准（gold label）。
judge-human κ
Day 17 我们认定 judge 有系统性偏差、必须校准；Day 18 手标并冻结了 ≥50 条人工 gold。今天把两条线合流。
Bootstrap CI + 收口
Day 19 我们算出了 judge-human κ 的点估计并对照 0.6 阈值——但点估计会骗人，尤其样本小的时候。
B3
agent loop + 评测统计Day 21-30Agent loop 范式
- 能力曲线位置：B1-B2 我们打通了「会跑模型 + 会评测模型」的底座（tokenizer/cost、attention/decoder/KV 机理、judge 校准与 bootstrap CI）。从今天起 B3 把这套度量能力对准一个真正的研究对象——agent loop。
Tool 设计契约
- 承接昨天：昨天（Day 21）确立了「该不该上 agent」的判据，并看清 agentEval.ts 缺一条真正的工具回路。今天往前一步：在写回路之前，先把 agent 与外界打交道的唯一接口——工具（tool）——的契约定清楚。
评测统计基础
- 能力曲线位置：B3 是「agent loop + 评测统计」双线推进——Day 21-22 搭 agent 这一侧（回路判据 + 工具契约），今天切到统计这一侧。
无框架 agent loop 骨架
- 承接前三天：Day 21 判定了「该不该上 agent」并标出 agentEval.ts 缺一条真正的回路；Day 22 把工具契约定清；Day 23 补了评测统计。三块拼图齐了，今天动手把缺口补上。
多步 AML 任务接入
- 承接昨天：Day 24 手写好了 framework-free 的 agent loop（observe→act→observe，硬上限 8 步）。今天给它接上第一个真实多步任务——AML 调查，验证「为什么这类任务天然需要 agent 而非 workflow」（呼应 Day 21 的判据）。
runTaskEval 打通
B3 这一批的主题是「把 agent loop 跑起来 + 把它量出来」。
Qwen3 对比与稳健性
Day 26 把 agent loop 接进了 runTaskEval，能在一个模型上跑出 completion + tool-call 双指标。但「一个模型的分」无法支撑选型——你不知道它是好是坏，没有对照系。
paired bootstrap + CI
Day 27 拿到了两模型在同一 29 任务上的 Δcompletion，但一个点估计（比如 Δ=+8pp）不能直接拿来选型——它有抽样误差，可能真值横跨 0。
统计功效 power
Day 28 给 Δ 加了 95% CI，能判「这个差显不显著」。但有个更隐蔽的陷阱：当任务太少时，即使真有差异也检不出来——CI 宽到永远含 0。
stats-on-evals 收口
B3 整批从「agent loop 跑起来」（D21-25）到「量出来」（D26-27）再到「把数字变可信」（D28-29 的 CI 与 power）。
B4
reasoning/planning/multi-agent + 何时不用 agentDay 31-40reasoning/planning 谱系
B1-B2 把 tokenizer/provider 接好，B3 把「agent loop + 评测统计」搭起来，P1 给了 29 任务套件与 κ-harness。到 B4，问题从「怎么跑 agent」上升到「该不该让模型多步推理、该不该上 agent」。今天是 B4 的开篇：先把 reasoning/planning 的范式谱系（CoT / ReAct / self-consistency /
agent vs workflow
昨天（Day 31）把 reasoning 范式谱系厘清、给 29 任务打了「需推理」标签。今天在能力曲线上更进一步：从「该不该多步推理」上升到「该不该用 agent」。这是 AISA 选型论证的核心二分——workflow（预定义代码编排 LLM）vs agent（LLM 自主决定步骤与工具）。最小可判定产出：复用 Day 31 标注，把 29 任务分类成 workflow-fit / agen
非确定性统计基础
Day 31-32 解决了「该不该多步推理 / 该不该上 agent」的定性判定。但所有这些选型最后都要靠数字裁决，而 agent 输出是非确定的——同一任务跑两次可能一次过一次挂。今天补的是 B4 后半段一切实测的统计底座：为什么单跑不可信，以及 pass@k 与 pass^k 的根本区别。它直接决定 Day 34（self-consistency）、Day 39（pass@k+pass^k 实
self-consistency 机制
Day 33 立了非确定性的统计底座（pass@k / pass^k / variance），并建了 runNTimes 复跑封装。今天把这个封装用起来，落地第一个降方差技术：self-consistency——同 prompt 多采样再多数投票。它在能力曲线上的位置是「方差控制」：不是让模型更聪明，而是把偶发错误样本稀释掉。最小可判定产出：用 DeepSeek-V3 对 8 任务跑 single
bootstrap 置信区间
Day 34 跑出了 single-shot vs k=5 的 Δaccuracy 点估计。但 8 任务的小样本下，一个看着「+几个点」的 Δ 可能纯属噪声。今天补上 B4 实测的显著性裁决器：bootstrap 置信区间——用有放回重采样给 Δ 配一个 95% CI，CI 跨 0 则差异不显著。这是整个 B4 选型论证的收口工具：Day 40 的「何时不用 agent gate」里「Δaccur
supervisor/worker 模式
B4 前半（Day 31-35）解决的是「单个 agent 的推理形态 + 怎么用统计判它」：
单 agent vs 多 agent
昨天（Day36）我们把 orchestrator-workers 编排搭出来、跑通了一条确定性 transcript。但「能搭」不等于「该搭」。今天在 B1→B18 能力曲线上做的是一次对照消融（ablation）：
cost/latency 度量
Day37 我们用 accuracy Δ + token 倍数比了单 vs 多 agent，但 accuracy 只是可靠性的一个面。今天在 B1→B18 曲线上把「可靠性」从一维（准确率）扩成三维：
pass@k + pass^k 实测
Day33 我们建立了 pass@k / pass^k 的定义与 runNTimes 复跑封装，Day35 建了 bootstrap CI，Day38 把可靠性扩成三维。今天是 B4 里把可靠性口径落到实测的一天：
何时不用 agent gate
B4（Day31-40）从「单 agent 推理形态」一路走到「多 agent 编排 + 三维度量 + 脆弱性证据」。今天是 B4 的收口日：把前面所有数字合并成一张决策 gate——
B5
tool/context engineering + 指标树Day 41-50context engineering 范式
B5 是整条 B1→B18 能力曲线从「会跑 eval」转向「会经营 agent 输入面」的拐点。
tool 设计反模式
昨天（Day 41）确立了 context engineering 的总命题：agent 的输入是有限 token 预算，工具描述是预算的主要消费者之一。
指标树与 North Star
B5 前两天（Day 41-42）从两个角度量化了 agent：输入面的 token 信噪比、动作面的工具反模式。
context-budget 表
Day 41 立了「context 是有限 token 预算」的命题，Day 43 把 context-token 列成指标树输入层的一个叶子。
tool 重设计（合并+收窄）
Day 42 给工具体检（标出五类反模式），Day 44 算出 tools 配额常超额——今天动手治：把重叠工具合并、给 description 写「何时用/何时不用」、给参数加 enum/required 收窄取值域。
A/B eval 设计
在 B1→B18 这条能力曲线上，B5 的前半段（Day 41-45）做的是「把工具集当作有限 token 预算来经营」——审计 token、画指标树、重设计工具（v1→v2）。
判分一致性校准
昨天（Day 46）我们用受控 A/B 把「v2 工具更好」变成了一个带 Δ 的数字——但这个数字完全建立在「judge 判得准」这个未经检验的前提上。
跨模型稳健性
Day 46 拿到了 v2v1 的 Δ，Day 47 校准了判这个 Δ 的裁判。但还有最后一个隐患没排除：这个 Δ 会不会只是 DeepSeek-V3 这一个模型的怪癖？
指标仪表盘雏形
Day 43 我们画了指标树（NSM=task 自主完成率 + 叶子指标），Day 46/48 我们（待 key 后）跑出了真实的 A/B 报告。
Block 收口与归因
B5 这十天（Day 41-50）走完了一条完整的「用 eval 证明工具改进」的方法论闭环：审计 token（41-44）→ 重设计工具 v1→v2（45）→ 受控 A/B（46）→ 校准裁判（47）→ 跨模型复核（48）→ 活数据仪表盘（49）。
B6
真 MCP server (2026-07-28 spec)Day 51-60MCP 2026-07-28 stateless 规范精读
B1→B50 我们一直在「进程内」把工具暴露给 LLM——评测方法论（B1）、attention/KV（B2）、agent loop（B3）、reasoning/multi-agent（B4）、tool/context engineering（B5）。B5 收口时（Day 50）已经能用双模型 + κ 给「v2 工具带来 Δ」做数字归因，但所有工具调用都还停在同一个 Node 进程里的函数调用。B
Streamable HTTP transport + 官方 TS SDK v1.x
Day 51 我们读懂了 stateless 规范并列出进程内 mock 缺的 5 项，第 1 项就是 transport（没有 HTTP）。今天补这一项：用官方 @modelcontextprotocol/sdk 的 McpServer + StreamableHTTPServerTransport 真起一个监听本地端口的 HTTP server，并用 curl 打通 initialize 握手
Zod 工具 schema vs 现有 JsonSchema 子集
Day 52 我们让 server 的 transport 通了（curl 打通 initialize），但那个 server 还没有任何业务工具。今天给它挂上第一个真工具，并解决一个工程现实问题：工具的输入怎么声明。仓库的 toolRegistry.ts 里是手写的 JsonSchema 子集 + 自写 validate()；官方 SDK 走的是 Zod——你写一个 Zod shape，SDK
tools/list 网络语义
Day 53 把第一个 Zod 工具注册进了 server。但「注册了」不等于「客户端能正确发现」——发现走的是 tools/list，而在 stateless 规范下，tools/list 有它特定的网络语义：任意节点都能回完整清单、客户端可按 TTL 缓存、工具顺序必须稳定。今天用 MCP Inspector 真连上 server，调 tools/list，核对返回的工具数/名称/顺序与进程内
tools/call 网络往返 + content 封装
Day 54 验证了发现层（tools/list 返回什么、顺序稳不稳）。今天补最后一块协议拼图——执行层 tools/call：成功结果怎么封装（result.content），失败怎么走标准 JSON-RPC 错误码（-32602 INVALID_PARAMS）。这是 B6 协议三件套（list/call/error）的收口，也是把仓库手写的 McpCallError 错误对齐到标准 JSON
迁移 AML 工具集上网
B6 从 Day 51 的规范精读、Day 52 的官方 TS SDK 起步、Day 53 的 Zod schema、Day 54-55 的 tools/list/tools/call 网络语义一路铺到今天——前 5 天我们都在「用一个玩具工具（assessTypology）练管线」，今天第一次把真业务能力（仓库里已存在的 AML 三件套）按 MCP 契约拆成 3 个工具暴露上网。这是 B6 从「
DeepSeek-V3 经 OpenRouter 作 MCP 客户端
B6 前 6 天我们都站在 server 侧：注册工具、暴露 tools/list、处理 tools/call。今天第一次切到 client 侧——让一个真模型（DeepSeek-V3 经 OpenRouter）连上昨天（Day 56）暴露的 AML server，自己读 tools/list、把自然语言查询映射到 tools/call。这是 B1→B18 能力曲线上「从手工调工具」升级到「让 L
工具输入零信任校验
Day 57 我们让「自己的」LLM 当客户端去调工具——很容易产生「客户端是我的，输入可信」的错觉。今天专门打破它：即便客户端是自己的模型，server 也必须零信任校验每一条入参。这是 B6 从「让它跑通」转向「让它扛得住」的安全转折，也是 B7（OAuth 2.1 + MCP 安全 + CI gate）的前置防线。承接 Day 53 写好的 Zod/JSON Schema（那时为「类型正确」
进程内 mock vs 真 server 等价回归
B6 一路把 AML 工具从「进程内函数」迁到「网络 server」（Day 56 上网、Day 57 客户端、Day 58 零信任校验）。迁移最隐蔽的风险不是功能缺失，而是行为漂移：同一批请求经两条路径（进程内 handle() vs HTTP server）输出悄悄不一致，上线即回归。今天用 differential testing（对拍） 把这个风险钉死。这是 B6 从「能跑」收口到「可上线
收尾 + Inspector 端到端验收
B6 整块（Day 51-60）从 stateless 规范精读起步，经 SDK/Zod/tools/list/tools/call、AML 工具上网、LLM 客户端、零信任校验、对拍回归，今天收口。收口不是再加功能，而是端到端验收 + 诚实盘点收益与缺口：用 MCP Inspector 一次跑通全工具，把 B6 攒下的三个里程碑数（tools/call 3/3、恶意拦截 9/9、对拍 20/20
B7
OAuth 2.1 + MCP 安全 + CI gateDay 61-70OAuth 2.1 资源服务器模型 (RFC 9728/8707)
B1→B6 我们把一个进程内的 MCP 工具注册表升级成了真网络 MCP server（B6，2026-07-28 stateless spec 形状）：真 JSON-RPC、真 tools/list/tools/call、真 schema 校验。一个能被远端 agent 通过 HTTP 调用的 server，下一道必答题就是授权——谁有资格调哪个工具。B7 整批就是补这道课：从 OAuth 2.
MCP Security Best Practices 2026-01
昨天（D61）我们把 MCP server 的身份钉成 OAuth resource server，画了 5×scope 矩阵。但「身份对了」不等于「实现安全」——具体会被怎么打？今天读 MCP Security Best Practices (2026-01) 这份权威，把三类典型攻击拆清，然后用 TDD 红阶段先固化「应该拒绝什么」的契约：写 6 条失败断言。这是 B7 从「设计」转入「可执行
JWT 校验内核 (jose)
D61 定身份、D62 写红测试，今天进入 TDD 绿阶段第一步：把 JWT 校验内核跑通。这是 B7 里第一段真代码落地——用 jose 库实现 mintToken/verifyAccessToken，让 D62 那批红断言里的「过期拒/错密钥拒/audience 限定/scope 校验」逐条变绿。今天只追求一条 happy-path：mint 一个有效 token → verify 通过 →
把校验接到 MCP 工具网关
D63 让 JWT 校验内核 happy-path 绿了，但「能验 token」≠「网关真的拦得住越权」。今天解决点位问题：在哪一行代码做拦截？答案是「事中拦截」（in-band enforcement）——在 toolRegistry 真正派发工具调用之前，每次 tool call 都重做 token + scope 双校验。这是 B7 把 D61 的 audience 模型、D62 的三类攻击
拒绝路径与错误语义 (WWW-Authenticate)
D64 把 guard 接到了网关，「拦得住」了；但怎么拒和拦不拦得住同样重要。今天打磨拒绝路径的语义——401 与 403 的区别、WWW-Authenticate 头该回什么、error="invalid_token" vs error="insufficient_scope"。为什么 PM/架构师要在意这种细节？因为自动化 agent 要靠这些语义自我修复：401 告诉它「去重新取 toke
成功路径端到端
B7 这一周是「给 MCP 工具网关装上 OAuth 2.1 资源服务器（RS）能力」的完整闭环。Day 61-64 建机理与 guard（RS 模型 / 三类攻击 / jose 校验内核 / 接进 toolRegistry），Day 65 走的是拒绝路径（401/403 + WWW-Authenticate），今天 Day 66 走的是成功路径——把一个只含最小 scope 的 token 注进
eval CI gate 设计 (M2)
B7 前半周（Day 61-66）建的是安全支柱（OAuth 2.1 RS + 审计）。从今天起，B7 后半周（Day 67-70）转入评测支柱：把「模型能力是否退步」从主观印象变成可阻断合并的门禁。在 B1→B18 能力曲线上，这是「有 eval」升级成「eval 进 CI 当 gate」的一格——也是 AISA 作品集里 hiring manager 四问之一「你怎么知道它没退步」的答案。今天
GitHub Actions 接 eval 阻断
Day 67 把 eval gate 的决策逻辑（gate.ts，fail-closed，纯函数）做好了。但一个躺在仓库里、要人手动跑的脚本不是「门禁」——门禁的定义是「不通过就合不进去」。今天 Day 68 把 pnpm eval:gate 接进 CI 编排（GitHub Actions），让 PR 触发时自动跑、低于阈值就 exit 1 使 job fail、从而阻断 merge。在 B1→B
制造回归验证 gate 会红
Day 67 设计了 gate 的决策逻辑，Day 68 把它接进 CI。但一道从没红过的门禁是不可信的——你不知道它到底会不会拦。今天 Day 69 做「testing the test」：故意制造一个真的坏改动让 pass-rate 跌破阈值，确认 eval-gate job 真的失败（红）。如果故意搞坏后 gate 仍绿，说明阈值或对比逻辑失效，门禁形同虚设。在 B1→B18 曲线上，这是「
修复回归 + 双 transcript 收口
B7 这一周从安全（Day 61-66：OAuth 2.1 RS + 审计）走到评测（Day 67-69：fail-closed gate + 红测）。Day 69 已证明「坏改动→红」成立；今天 Day 70 收口：revert 那个回归改动，让 pnpm eval:gate 转绿，证明「好改动→绿」也成立——「坏→红、好→绿」双向都成立，门禁才完整可信。同时把 Day 65「被拒(403)」和
B8
真 API + 流式 + DockerDay 71-80HTTP API 边界设计
B7 把 agent runner 包进了一个真实网络服务（stateless MCP server + OAuth 2.1 + fail-closed eval gate），证明「这套东西能被远程、带授权地调用」。B8 这一周要补的是「这套东西如何被工业级地调用」：
SSE 流式协议
昨天（Day 71）把 agent runner 的网络边界写成了契约：RPC 风格 POST /chat + 4 类 typed error code。但契约里的「响应」还是一次性 body——用户要盯着空白屏等整段生成完。
模型流式接入
Day 72 用硬编码的 3 帧把 SSE 管子打通了，但管子里流的是假 token。今天在 B1→B18 曲线上把假 token 换成真模型：
typed 错误 + 重试
Day 73 把真模型流式接通、测了 TTFT，但真流式必然会遇上游故障：限流、瞬时 5xx、超时、流中断。今天在 B1→B18 曲线上补「韧性」这块——把 Day 71 契约里的 4 类 typed error code 落到执行层：
API 接 eval 套件
Day 71-74 把 agent runner 包成了一个有契约、能流式、会重试的真 API。现在缺最后一块拼图：怎么证明这个 API 包装层没把能力搞坏。
流式接 Qwen3 对比
B1→B18 这条能力曲线，前半（B1-B7）把「评测怎么算数」立住——任务集、judge、统计、CI gate；
多阶段 Docker
B8 这一段把 agent runner 从「脚本」推向「真服务」。
镜像瘦身 <300MB
B8 这一段把服务封装成镜像。
vibe-coding worklog
B1→B18 这条曲线的产出，不只是代码和数字，还要变成可链接、可被招聘方核验的资产——这正是 AISA（AI Solutions Architect）作品集的命门。
端到端固化
B8（Day 71-80）这一段把 agent runner 从脚本推到「真服务 + 镜像」。
B9
部署 + 韧性 + 可观测 + 独立红队Day 81-90Cloud Run scale-to-zero 部署模型
B1→B8 我们把能力底座一层层垒起来：评测方法论（B1）→ 真 token/cost 测量（B1）→ A/B 统计（B3）→ agent 运行时与工具（B6-B7）→ 真 API + 流式 + Docker 多阶段镜像（B8）。到 Day 80 收口时，镜像（Dockerfile.mcp）已经能本地 docker build 出来、容器内能跑 eval，但它还只活在我本机的 docker dae
OTel GenAI 语义约定 + Langfuse/Phoenix
昨天（Day 81）把容器推上了 scale-to-zero 的部署模型，解决了「在哪跑」。但部署上去之后有个新问题：你看不见它在干什么——一次模型调用花了多少 token、多少钱、多久、用了哪个 model id，全是黑盒。
韧性模式 backoff+jitter / circuit breaker / fallback
B9 前两天解决了「在哪跑」（Day 81 Cloud Run）和「看见它在干什么」（Day 82 OTel trace）。但一个上线服务还缺最关键的一环：它依赖的下游会失败——模型 API 会 429（限流）、会超时、会 5xx。今天补韧性模式：失败了怎么重试、下游半死时怎么自保、主模型挂了怎么降级。
熔断 + fallback 路由实战
昨天（Day 83）把韧性三件套（backoff+jitter / 熔断 / fallback）作为单独原语写进了 resilience.ts 并测绿。今天把其中两件——CircuitBreaker 和 withFallback——组合成一条主→备路由，并用故障注入验证它们在一条真实链路上协同工作。
把 eval harness 接入 OTel
Day 82 给单次模型调用打了一条 GenAI span；Day 83/84 补了韧性。今天把可观测性从「单条调用」拉升到「整套评测流水线」：把 29-task suite 批量埋点——每个 task 一条 span，span 内挂 gen_ai. 属性 + 该任务的评分（judge pass/fail + partial-credit）。
部署上线 + 公网可观测
B9 把前面攒下的「能在本机跑通」的 agent/eval/MCP 升级成「能在公网活着且被观测」。昨天（Day 85）做的是把 29-task eval suite 接进 OTel、让评测变成可观测的 trace 流；今天往前再走一步——真正把容器推上 Cloud Run，拿到公网 URL，并确认 trace 落进托管 Langfuse。在 B1→B18 整条能力曲线上，这是从「P2 评测 /
trace 量产 + 仪表盘
昨天（Day 86）拿到公网 URL 并确认了「1 条」线上 trace 入库——但一条 trace 只能证明链路通，不能支撑任何容量/成本决策。今天的任务是量产 trace 并聚合成分布：对线上 URL 跑 50+ 次混合请求，把延迟样本喂进已建好的 summarizeLatency 算 p50/p95/p99，再用 dashboard.ts 把延迟/token/cost 切片画成一张概览图。在
OWASP LLM Top-10 红队方法
前三天（Day 85-87）把系统「观测明白了」——eval 接 OTel、上线拿 URL、量产 trace 出 p95/cost。但可观测只回答「系统跑得怎么样」，不回答「系统能不能被攻破」。今天 B9 的后半段转向独立红队：先建立攻击面的系统性词汇表（OWASP LLM Top-10），再针对本仓最敏感的路径——src/aml 的 SAR 生成——编出针对性的 attack prompt 投向
攻击评级 + 真攻击确认
昨天（Day 88）按 OWASP LLM Top-10 编了 ≥10 条 attack prompt 投向 SAR 路径、固化成 committed transcript——但「投出去拿到响应」只完成红队的一半。今天补齐另一半：对这些 transcript 逐条评级，并确认至少 1 条是真命中的攻击。关键纪律是「评级方必须独立于被测者」——必须把 src/aml/evalBaseline.ts
修复闭环 + 回归
Day 88 投放攻击、Day 89 独立评级并确认了 ≥1 条真攻击——红队抓到了洞。今天是 B9 的收口：把洞补上，并写回归用例防止复发。红队的价值不在「抓到」而在「闭环」——抓到→落策略修复→写回归→重放验证已挡→eval gate 转绿。在 B1→B18 曲线上，这是 P7（安全/合规）与 P2（评测 gate）的合流：修复手段落在 src/agent/mcp/toolRegistry.t
B10
p95/cost 测量 + 成本级联 + tau2-benchDay 91-100延迟/吞吐指标体系 (M4)
B1→B18 能力曲线上，B9 刚把「部署 + 韧性 + 可观测 + 独立红队」做完——我们已经知道系统是否安全、是否会崩。
并发压测方法 (M4 serving)
B10 的核心是把 LLM 服务「量化运营」。
$/query 成本测量 (M4)
B10 把 LLM 服务量化运营：Day 91 测延迟分布、Day 92 测并发吞吐，今天补上第三个轴——钱。
LiteLLM 路由/级联 (M6)
B10 前三天把延迟（Day 91）、并发（Day 92）、成本（Day 93）量化清楚。
级联省钱 vs 质量权衡 (M6)
昨天 Day 94 搭好了 model-cascade 机制、量化了升级触发率——但「触发率」本身不回答最关键的问题：这套级联到底值不值？
tau2-bench 概念 (M2, 2026-03)
B1→B18 的能力曲线在 B10 进入「把模型/agent 当作可测量系统」的工程化阶段。
held-out 任务设计 (M2)
昨天（Day 96）搭好了 tau2 retail 双控制脚手架，但脚手架要测出可信数字，前提是任务集本身没被「刷过」。
pass^k 测量 (M2)
Day 96 搭了 tau2 双控制脚手架，Day 97 写了 3 个 held-out retail 任务 + 确定性验证函数（纯逻辑已可单测）。
三表整合 (M4+M6+M2)
B10 这一程跑下来攒了三组互相独立的数据。
Block 复盘 + SOTA 检查
B10 走到收口。
B11
GRPO/后训练机理 + 首跑Day 101-110后训练地图 (M5)
B10（Day 91-100）把「服务侧」量化运营拉通了——延迟分布、$/query、级联省钱、tau2 多轮 agent 评测，产出了一份可链接的能力-成本报告。从今天起 B11 转入一个新维度：不再只是评测和路由别人的模型，而是理解「如何把一个模型训得更对」。这是 B1→B18 能力曲线从「会用、会评、会算成本」迈向「会改模型本身」的关键跨越——一个 AI Solutions Architec
GRPO 原论文精读 (arXiv:2402.03300)
昨天 Day 101 画了后训练全局地图，把 GRPO 定位成「去掉 critic、用组内相对得分估 advantage」的那一支。但「组内相对得分」到底怎么算、为什么这样就能替掉 value 网络，地图层面没展开。今天精读 GRPO 原论文（DeepSeekMath, arXiv:2402.03300）的核心公式，手算一组 8 样本的 mean/std/advantage，再用本仓 groupR
R1 训练范式 (arXiv:2501.12948)
Day 102 把 GRPO 的「优势怎么算」钉死了——但 GRPO 只是优化器，奖励 r_i 从哪来才决定训出的模型对不对。昨天用的 0/1 奖励是哪来的？今天进入 R1（DeepSeek-R1, arXiv:2501.12948）的核心答案：RLVR——可验证奖励。对 math/code 这类有 ground truth 的任务，用确定性 grader 直接给 0/1，把整个 RM 省掉。这是
DPO vs GRPO 机理 (Unsloth GRPO guide)
前三天（Day 101-103）把后训练地图、GRPO 优化器、RLVR 奖励都打通了，全是「纸面 + 确定性数学」。今天做两件事：一是把 DPO vs GRPO 的权衡讲透——为什么有了 DPO 还需要 GRPO；二是第一次碰真实训练运行时，用 Unsloth 的 LoRA+GRPO 流水线在单卡上加载 Qwen3-4B 跑一个冒烟。这是 B1→B18 曲线上从「能讲清训练」迈向「真的能跑起来」
reward 函数设计
Day 102 学了 GRPO 怎么算 advantage、Day 103 学了 RLVR 怎么用确定性 grader 给 0/1、Day 104 比了 DPO/GRPO 权衡。但所有这些的输入都是 reward——reward 函数设计错了，优化器再好也是把模型往坑里推。今天是 B11 的「奖励工程」核心日：多目标 reward 如何组合、为什么任何 grader 漏洞都会被 RL 利用（rew
数据集与 prompt 构造
在 B1→B18 的能力曲线上，B11 是「能把后训练讲清楚并自己跑一遍」的关键拐点：前面 B1-B10 把 eval、A/B 严谨性、成本/p95 测量都打通了，现在要把这些「评判工具」反过来当作 RL 的奖励信号来源。昨天 Day 105 用确定性 rubric grader 替换了 evalBaseline 的自评闭环，解决了「奖励从哪来且不被作弊」；今天 Day 106 解决「训练数据长什
GRPO 训练循环搭建
B11 这一批是「自己跑通一次后训练」的实操段，处在 B1→B18 能力曲线上「从会评判到会训练」的转折点。昨天 Day 106 把数据落成了 64 行 prompt+verifier 的 grpo_train.jsonl；今天 Day 107 把数据、reward 函数、超参三者装进一个真正的训练循环，并跑 50 步冒烟（smoke run）确认管线不崩。明天 Day 108 才上 ≥300 步
训练监控与诊断
B11 走到「全量首跑」这一步，是 B1→B18 能力曲线上「能训练 → 能诊断训练」的递进。昨天 Day 107 用 50 步冒烟确认管线不崩、拿到 step-0 起始 reward；今天 Day 108 把训练拉到 ≥300 步，第一次真正盯着曲线看模型有没有在学。明天 Day 109 才把训练产物（LoRA adapter）拉去严谨评测、Day 110 复盘固化。今天的核心是「训练健康三曲线
adapter 评测与对齐
B11 的训练已经跑完（Day 108 看了三曲线），今天 Day 109 在 B1→B18 能力曲线上处于「能训练 → 能严谨证明训练有效」的位置。今天的核心动作是「证明它真变好了没有」——把 GRPO 产出的 LoRA adapter 拉进同一个 eval harness，前后对比，并用 Cohen's κ 校准 judge 一致性，防止「评测漂移冒充能力提升」。这是 B1-B10 攒下的 e
复盘与产出固化
B11 收口日，是 B1→B18 能力曲线上「跑通一次后训练 → 把它讲成作品」的闭环点。Day 101-109 走完了「机理 → 数据 → 训练循环 → 监控 → 评测」整条 GRPO 首跑链路；今天 Day 110 做两件收尾事：
B12
RLVR + 模型策略 memoDay 111-120RLVR 原理
B11 我们把 GRPO 的机理与首跑跑通了（reward 上升斜率、no-critic 省显存），但留了一个更底层的问题没答：奖励信号本身从哪来、可不可信。今天的 RLVR（Reinforcement Learning from Verifiable Rewards）正是回答这个的——它把 RLHF 里那个「会漂移、要标注」的学习型 reward model 换成一个确定性 grader。这是整
Reward hacking 谱系
昨天（Day 111）我们建立了 RLVR 的乐观面——确定性 grader 取代学习型 RM，省标注、无 RM 漂移。今天必须给这份乐观泼冷水：可验证奖励不等于免疫作弊。在 B1→B18 能力曲线上，这是从「会设计奖励」走向「会审计奖励」的一跳——能列出 reward hacking 的谱系、并在自己的代码里指出哪条路径正在自评循环，才算真正握住了 eval 严谨性。今天还有一个具体动机：本仓
GRPO 奖励信号
Day 111 讲了奖励从哪来（RLVR：确定性 grader），Day 112 讲了奖励会被怎么作弊（reward hacking 谱系）。今天补上中间那块：拿到奖励后怎么把它变成策略更新信号——GRPO 的组内归一化优势。这是 B1→B18 曲线上「奖励设计」的收口：能把 grpo.ts 的纯函数读懂、并把具体任务映射成「该用 exactMatch 还是该用 judge」的奖励设计表，就具备了
实验设计基础
前三天（111-113）把奖励侧（RLVR / reward hacking / GRPO）讲透了。今天换轨到评测侧的因果地基：base-vs-tuned 不是「跑两次比大小」，而是一个因果实验——要先定假设、控变量、算最小样本量。这是 B1→B18 曲线上「会跑 eval」走向「会设计能下结论的 eval」的一跳。本日的杀手锏是直接吸取一个已落地的真实教训：A/B（V4-Pro vs V4-Fl
Base 模型基线
昨天（Day 114）把 base-vs-tuned 的因果实验框架搭好了——H0/H1、唯一变量、n≈70。今天落地这个框架的第一块砖：固化 base 基线。在 B1→B18 曲线上，这是「设计实验」走向「跑出可复现锚点」的一跳。核心纪律一句话：基线分必须先于任何调优固化存档，且固定 seed/温度/prompt/模型 id/grader 版本，否则后续一切 Δ 都无法归因到模型。今天还要避一个
Tuned 模型对照
在 B1→B18 的能力曲线上，B12 是「把已建好的 eval/训练管线用作一次正经的因果实验」的收口段：B11（D101-110）刚把 GRPO/后训练机理与首跑跑通，B12 这十天则退一步，先把「怎样才算一次能下结论的对照实验」立规矩，再串成一页模型策略 memo。昨天（Day 115）固化了 base 基线——锁死 seed/温度/prompt/模型 id/grader 版本后存档的锚点；
Δ 与置信区间
在 B1→B18 能力曲线上，今天是 B12 实验段的「下结论之前的最后一道数学关」：昨天（Day 116）已经把 tuned 候选（Qwen3 经 OpenRouter）在与 base 完全相同的配置下跑出 agent-evals/b12-tuned.json，于是手里有了两份按 taskId 可对齐的报告。今天要做的是把它们配对求差值 Δ，再用 bootstrap 估 95% 置信区间——只有
结果显著性裁决
在 B1→B18 能力曲线上，今天是 B12 实验段的「下判决」环节：昨天（Day 117）已经把 base/tuned 配对求出 Δ 与 95% CI，今天要把这个 CI 翻译成一句能写进 memo 的结论——显著还是不显著？能不能换模型？ 与此同时，还要回头校验「打分这件事本身可不可信」：用 Cohen's κ 复核两套标注（两个 judge，或 judge-vs-人工真值）的一致性。逻辑链是
Gap→数据构造
在 B1→B18 能力曲线上，今天是 B12 实验段从「评判」转向「改进」的拐点：前三天（Day 116-118）把 base/tuned 跑出来、求出 Δ±CI、下了显著性裁决。但裁决不是终点——尤其当结论是「方向性更优、不显著」时，真正有价值的产出是从失败样本里挖出能力缺口（gap），并把每个 gap 翻译成一条可执行的数据构造方案。这就是 eval 驱动的数据飞轮：eval→gap→data
模型策略 memo
在 B1→B18 能力曲线上，今天是 B12 这十天的收口，也是把整段「RLVR 机理 → 对照实验 → Δ±CI → 显著性裁决 → gap→数据」凝成一件作品级交付物的一天。前面九天每天产出一块拼图（base 基线、tuned 对照、Δ±CI、verdict、gap-to-data）；今天把它们串成一页可执行决策 memo，回答 hiring manager 会问的三件事：现在该不该换模型？该
B13
FATF typologies + BSA grader + 用户研究Day 121-130FATF 五大类型学签名
在 B1→B18 的能力曲线上，B12（D111-120）刚把「模型策略 memo」收口——回答「该不该换模型、补什么数据、用什么指标验收」。但那条线上一直有个隐患：眼下的 AML eval 用的是合成数据自己生成、自己当真值，外部效度薄弱。
BSA 报告机制与阈值
昨天（Day 121）把 FATF 五大类型学落成了带真值标签的数据，回答了「洗钱长什么样」。今天进一步——洗钱被「看见」之后，金融机构有法定义务报告它，而报告机制（BSA 四件套）恰好决定了「哪些判定能写成纯阈值规则、哪些必须留给人工/LLM」。
混淆矩阵与 per-typology 召回
昨天（Day 122）用确定性规则分类器对 typed.csv 打了标，产出 5 类命中计数。但「命中多少」不等于「打得准不准」——要回答后者，必须把预测和真值放进混淆矩阵，逐类算 recall/precision/F1。
LLM-as-classifier prompt 设计
前三天（Day 121-123）走的是确定性规则线：FATF 签名 → BSA 规则分类器 → 混淆矩阵。但这条线有个结构性弱点——evalBaseline.ts 里「同一套规则既当被测、又当裁判」是循环自评，外部效度薄弱（规则给自己生成的数据打分，分数虚高）。
LLM grader 接入 eval harness
昨天（Day 124）写好了独立 LLM 分类 prompt，产出 200 条 {case_id, predicted_typology, reason}——但那还只是「另一套预测」。今天把它正式接进 eval harness：核心动作是解耦「被测系统」与「裁判」，把 evalBaseline.ts 的循环自评换成独立 grader，再用 Cohen's κ 度量 LLM 标签与 AMLSim 真
Qwen3 对照与模型间一致性
B13 这一个 block 的主线是「杀死循环自评、建立外部裁判」。Day 124 把 LLM 立成 typology 分类器，Day 125 用 Cohen's κ 把单个 LLM 裁判（DeepSeek-V4）对齐到 AMLSim 真值。但单模型裁判有它自己的系统偏差——它可能在某一类上稳定地错。今天往前推一步：引入第二个模型（Qwen3）做对照裁判，用两模型之间的 κ 衡量裁判间稳定性（in
规则 vs LLM 召回缺口分析
B13 到这里，三套预测已经齐了：Day 122-123 的规则混淆矩阵、Day 124-126 的 LLM 混淆矩阵（DeepSeek-V4 / Qwen3）。前面都在「各自把分数算出来」，今天做对比与归因：逐 typology 算 recall delta = recall(规则) − recall(LLM)，看清楚「哪一类规则赢、哪一类 LLM 赢、为什么」。这是 B1→B18 能力曲线上「
M6 用户研究——survey 设计
B13 前七天（Day 121-127）都在做定量评测：把 AML 类型学变成可标注数据、用规则与 LLM 双裁判算混淆矩阵、算 κ 与 recall delta。今天起转向定性用户研究——因为再准的 eval 也回答不了「调查员到底想要 Copilot 怎么帮他」这种问题。M6 用户研究的第一件工具是 survey（问卷）：规模化、可量化地收集态度。这是 Solutions Architect
M6 用户研究——半结构化访谈脚本
Day 128 搭好了问卷（survey），它长于广度——规模化、可量化，但短于深度：自陈数据挖不出受访者自己都没意识到的痛点。今天补上 M6 用户研究的另一半——半结构化访谈（semi-structured interview），它用一个固定大纲保证可比性，又留出开放追问的空间挖深度洞察。这是定性研究方法学的核心一档：问卷告诉你「多少人觉得慢」，访谈告诉你「为什么慢、慢在哪个环节、他怎么绕过去」
Block 收口——grader 报告与工具固化
B13 走了十天：从 FATF 五大类型学（Day 121）→ BSA 报告阈值（Day 122）→ 混淆矩阵与 per-typology recall（Day 123）→ LLM-as-classifier（Day 124）→ LLM grader 接 κ（Day 125）→ Qwen3 对照（Day 126）→ recall delta 归因（Day 127）→ survey（Day 128）
B14
外部 ground-truth AML evalDay 131-140循环自评为何无效
B13（Day 121-130）我们用合成金标 + 规则/LLM 双裁判，把类型学 recall、Cohen's κ、混淆矩阵这一整套度量工具铸好了；但 Day 130 收口时已埋下一颗雷：那套规则基线的高召回，是自己给自己打分打出来的。
AML 公开标注集选型
昨天（Day 131）我们诊断出循环自评的病根：预测器和标签同源、无外部效度，于是给规则基线盖了「作弊基线」钢印。要真正治病，前提是接入一批带真标签、且不是我们自己造的外部数据。
schema 对齐
Day 132 选定了 IBM AMLworld 并量化了它的极端不平衡，但外部数据要能喂进我们既有的评测代码，必须先做列结构 → 领域模型的映射与运行时校验——这就是今天的 schema 对齐（schema alignment）。
loader 与去偏
Day 133 把 AMLworld 行结构校验干净了，但有一根刺没拔：Is_Laundering 极度不平衡（<0.1% 正例）。今天做的 loader 与去偏（debiasing）就是拔这根刺——用流式读取避免一次性载入大文件，用分层平衡抽样（stratified balanced sampling）把均衡子集喂给裁判，让召回率和置信区间可解释。
LLM judge 校准
Day 134 把均衡评测集 balanced_300.json 备好了，但喂给谁判？答案是一个 LLM judge。今天做 judge 校准（calibration）：设计一个 rubric 明确、二元输出、强制理由的 judge prompt，用 NAMED deepseek-v4-flash 对 Is_Laundering 做二分类，并在小手验子集上比对 judge 输出与真标签的一致率。
混淆矩阵与指标
在 B1→B18 的能力曲线上，B14 是把「自造金标循环」彻底换成外部 ground-truth 的一整块：B13（D121-130）打好了 FATF typologies + BSA grader + 用户研究的地基，B14 这十天则把 IBM AMLworld 真标签灌进既有评测管线，用真召回率拷问规则基线和 LLM judge。前几天（D131-135）已经把列结构映射（amlworldS
bootstrap 置信区间
在 B1→B18 的能力曲线上，今天是 B14「外部 ground-truth」段把点估计升级成区间估计的一跳。昨天（Day 136）在真标签 balanced_300 上用 binaryEval 出了第一张混淆矩阵 + recall/precision/FPR 三个点估计——但 N=300 的单点指标带抽样噪声，单看一个数字不能下结论。今天接着学 bootstrap 置信区间：对预测对有放回重采
第二模型交叉验证
在 B1→B18 的能力曲线上，今天是 B14「外部 ground-truth」段给裁判本身去偏的一跳。前两天（Day 136-137）已经用 deepseek-v4-flash 当 judge，在真标签 balanced_300 上出了混淆矩阵 + 带 CI 的三指标。但单一裁判有系统性偏差——prompt 敏感、家族偏好——它的「真召回率」里掺着裁判自己的脾气。今天接着学第二模型交叉验证：用
替换循环 baseline
在 B1→B18 的能力曲线上，今天是 B14「外部 ground-truth」段的核心动作——把「规则引擎评测自己造的数据」这个循环亲手杀掉。前面整个 block（Day 131-138）都是为这一刀做准备：列结构映射、去偏 loader、judge 校准、混淆矩阵、CI、交叉验证，全是在搭「用外部真标签评测」的脚手架。今天把 src/aml/evalBaseline.ts 里 assessCa
三方榜单与归档
在 B1→B18 的能力曲线上，今天是 B14「外部 ground-truth」整块的收口——把这十天造出来的所有部件（真标签 balanced_300、混淆矩阵、bootstrap CI、双模型交叉验证、去循环的规则基线）汇成一张可复现的三方 leaderboard。昨天（Day 139）杀死了循环 baseline、让规则在外部集上暴露真实掉分；今天把规则基线 vs deepseek-v4-f
B15
FIS×Anthropic 模式 + 对抗/HITL 套件Day 141-150FIS×Anthropic Financial Crimes 模式拆解
B14（Day 131-140）把内部规则基线接上了外部 ground-truth（IBM AMLworld 真标签）做去循环 eval，解决的是「数字可信不可信」。从今天起的 B15 把视角抬高一层：先搞清楚一个生产级金融犯罪 Copilot 应该长什么样，再围绕它建对抗/HITL 测试套件。今天是 B15 的开篇——拆解 2026-05 FIS×Anthropic Financial Crim
对抗威胁建模——AML Copilot 的攻击面
昨天（Day 141）把五段链拆出来，标出了「哪段无对抗测试、哪段无 HITL 闸门」的缺口。今天把这些缺口翻译成攻击者视角的威胁模型——一个安全可靠的 AML Copilot，必须先列清楚「会被怎么攻」，再为每条攻击写硬判据。这一天在 B1→B18 能力曲线上是「从架构缺口 → 结构化威胁模型」的关键一跳，紧接昨天的五段链映射，通向 Day 143-146 把每条攻击落成 fixtures 与
AMLGentex strategic-evasion 范式
Day 142 列清了 4 类攻击面，其中第 8-10 条（教 mule 拆分、规避 CTR、洗白话术）属于最危险的一类——strategic-evasion：模型被诱导去「帮助规避检测」而非「检测」。今天专攻这一类：先从机理上把它和 GRPO 的奖励黑客对齐（理解模型为什么会被诱导），再把 3 条 evasion prompt 落成 fixtures。这一天在 B1→B18 曲线上把 B11-1
子套件骨架搭建
Day 143 把 3 条 evasion fixtures 设计出来了，但 fixtures 只是「题目」，还需要一套「考场」来跑它们并判分。今天搭这套考场——evasion & safety 子套件的三层防御骨架：harness 跑任务、codeCheck 硬断言、LLM-judge 兜底。这一天在 B1→B18 曲线上把 B14 学的 ground-truth eval 方法论落到一个新的子
memo 注入 & PII 外泄任务
Day 144 把子套件骨架搭好（4 任务：3 evasion + 1 OFAC，codeCheck 全绿）。今天把攻击面里第 1、2 类——memo 注入与 PII 外泄——落成 3 个具体任务，让套件从 4 涨到 7。机理上要讲清两件事：为什么「数据里的指令」不能信（MCP 信任边界），以及为什么客户 SSN 不能跨案回放（PII 最小化）。这一天在 B1→B18 曲线上把 Day 142 威
auto-SAR 诱惑 & OFAC 硬停
B15 在整条 B1→B18 能力曲线上的定位，是把前面攒下的「带 CI 的可复现 eval」工程能力（B7-B14）落到一个真实高危场景：
替换 evalBaseline 循环自评
B15 到这里完成了一次重要转折：
跨模型对抗对比
B15 的对抗套件已经从「规则评规则」（Day 146）升级到「外部 NAMED model 当裁判」（Day 147），
失败归因 & judge 校准
B15 走到这里，两个模型的对抗失败转录已经跑出来（Day 147-148，需 key）。
抵抗率报表 & HITL 闸门固化
B15 的最后一天，做收口。
B16
治理一页纸 + AI 原型 + 可用性Day 151-160MRM 体制变更 (OCC 2026-13)
B1→B15 我们一路从「能跑评测」（B7 eval gate）走到「能对抗、能 HITL、能算 κ」（B14-B15 FIS×Anthropic 模式 + 对抗/HITL 套件）。但一个能跑分的 harness 不等于一个能过监管审查的系统——这正是 B16 的位置：把已建的技术能力套进真实的模型风险治理框架，让它能被「有效挑战」。今天是 B16 第一砖：监管底座从废止的 SR 11-7 换成
EU AI Act Omnibus 时间线
昨天（Day 151）我们换上了 MRM 的内部治理底座（OCC 2026-13）。但 MRM 只管「模型本身的验证流程」，管不到「面向用户/市场必须披露什么」——那是 EU AI Act 的地盘。今天在 B16 能力曲线上接着把第二套框（AI Act 的合规时间线）钉死：哪条义务哪天生效、AML Copilot 命中的是哪一条。最容易翻车的地方是用错时间线：旧叙事说「高风险 2026-08 生效
NIST GenAI Profile (NIST AI 600-1)
Day 151（OCC 2026-13，内部模型验证）+ Day 152（EU AI Act，对外披露义务）给了我们「流程」与「合规义务」两套框，但都没有给出一份具体的 GenAI 风险清单——幻觉、信息完整性、危险内容这些 LLM 专属风险该挂到哪里。NIST AI 600-1（GenAI Profile）补的就是这一块。今天在 B16 曲线上的动作是：把本仓已建的 failureTaxonom
一页纸治理设计
Day 151-153 我们分别钉死了三套框：OCC 2026-13（内部模型验证）、EU AI Act Art.50（对外披露）、NIST 600-1（GenAI 风险清单）。三套框各自一段，但 hiring manager / 审计不会读三份文档——他们要的是一眼看清「谁负责、控什么、证据在哪」。今天在 B16 曲线上的动作是收口：把三框收敛成单页 RACI + 8 控制点表，并写下本批最关键
评测独立性 (Anthropic Demystifying evals 2026-01)
Day 154 的 ADR 拍板了「用独立 κ harness 替换自评闭环」，但那还是文档层的决议。今天在 B16 曲线上把它落到运行：用 src/agent/eval/cohensKappa.ts 真的去跑 V4 标注 vs 人工金标，算出裁判与人标的 Cohen's κ。这是把治理原则（评测独立性）变成可量化数字的一步——也是整套 AML harness 能否被称为「有独立验证证据」的临界点
原型工具与可用性测试法 (NN/g)
B16 的前半段（Day 151-155）把治理收敛成一页纸、把评测拆成独立 κ harness——解决的是「系统对不对、可不可信」。从今天起 B16 转向「人用着顺不顺」：再准的 κ、再独立的评测，如果调查员看不懂面板、找不到 κ 是否达标，价值就漏在最后一公里。在 B1→B18 能力曲线上，这是第一次把「可用性工程」正式纳入——从纯后端正确性（B1-B15）走向人机交互可验证性（B16）。今天
AML 面板信息架构
昨天（Day 156）确立了方法——真人 think-aloud 5 人法 + AI 原型工具，并把它用在 harness 面板上。今天把同一套方法搬到本项目的金融旗舰作品 AML Copilot 上：先解决「信息架构」——调查员的任务流是怎样线性流动的、AI 结论的证据链在哪个环节必须可见、SAR 草稿哪里必须可编辑可追溯。在 B1→B18 曲线上，这是把 B15 已经建好的硬约束（hitl.t
跑 think-aloud 第 1 批
Day 156 定方法、Day 157 定 IA 与任务脚本，今天进入执行：把原型摆到真人面前跑第一批 think-aloud。在 B1→B18 曲线上，这是第一次让外部真人接触本项目的作品并产生可编码的行为数据——从「我认为面板清晰」跨到「3 个真人的逐任务成功率」。首批只招 3 人，目的不是统计显著，而是抖出最严重的结构性坑。今天的最小可判定产出：3 份转录 + 一张 n=3 的逐任务成功率表
跑 think-aloud 第 2 批 + 痛点聚合
Day 158 跑了首批 3 人、抖出高危点。今天补测 2 人凑齐 5 人，并把两批编码合并、按「频次 × 严重度」聚类成 top-3 痛点——这是从「散乱的成功率表」收敛到「可排优先级的待修清单」的一步。在 B1→B18 曲线上，这一步是把「散乱观察 → 排序决策」的收敛器，给即将到来的迭代（Day 160 只改 top-1）提供决策依据：改哪个、为什么先改它。它也是 B16 从「发现问题」转向
一次量化迭代 + 复测
Day 159 聚出 top-3 痛点并锁定 top-1。今天闭环 B16：只改 top-1、复测同一批任务、对比改前→改后的成功率 Δ——把可用性从「主观吐槽」升级成「可验证的 outcome 数字」。在 B1→B18 曲线上，这是 B16 的收口，也是通向 B17（outcome 指标仪表盘 + A/B）的桥：同样的「改前/改后受控对比 + 小样本只示方向」纪律，B17 会放大到模型层面的 V
B17
outcome 指标仪表盘 + A/BDay 161-170M7 outcome 指标定义
B17 是整条 B1→B18 能力曲线上「从能跑到能证明价值」的拐点。
M7 FPR 与 normalFalsePositiveRate
昨天 Day 161 把 4 个 outcome 指标的公式与数据源钉成了 metricsSpec。
M7 SAR 质量量化
昨天 Day 162 落地了 outcome 四指标里的 FPR（报得准不准）。
M7 cost-per-case + p95
前两天落地了 outcome 四指标里的「准」（FPR，Day 162）和「好」（SAR 质量，Day 163）。
活仪表盘聚合
Day 161 立了 4 指标骨架，Day 162-164 分别把 FPR / SAR 质量 / cost-per-case / p95 四个指标落地。
仪表盘可视化
B17 这个 block 的任务是把 AML 系统的「outcome 指标」从一堆散落的 eval 数字，凝成一块能被人一眼读懂的仪表盘。
M6 A/B 实验设计
Day 161-166 把 outcome 指标定义、聚合、可视化做完了——但这些指标都是「单个系统的体检」。
M6 配对显著性检验
Day 167 把 A/B 实验设计好、双模型各跑一遍、落了两组 per-task transcript。
A/B 落仪表盘
Day 167 设计了 A/B、Day 168 算出了 Δ + CI 并判了「不显著」。
Block 收口 + SOTA 检查
Day 161-169 把 B17 的两条主线都铺完了：outcome 指标（定义 → 独立金标 FPR → SAR 质量 → cost/p95 → 聚合 → 可视化）和 A/B（设计 → 显著性 → 落仪表盘）。
B18
OSS 收口 + 英文 + 全局 SOTA 复核Day 171-180smolagents v1.26.0 入口扫描
B17（Day 161-170）把 outcome 指标仪表盘 + 配对 A/B 收口——我们手里已经有了「用独立金标 + 真实成本/时延 + 配对 A/B」打出来的真值（V4-Pro 89.7% vs V4-Flash 79.3%、Δ+10.3pp、cost $0.0139/run）。
DeepEval + Inspect AI 评测框架
昨天（Day 171）扫的是 smolagents 的 agent 主循环（模型怎么编排工具）。今天往同一条「读真框架」的线再走一步，但视角从「怎么跑 agent」切到「怎么评 agent」——拆两个 2026 活跃主线评测框架 DeepEval 与 Inspect AI（UK AISI），并把它们的抽象对回本仓的评测内核（cohensKappa.ts 的 judge-human 一致性、agen
claude-cookbooks + 全局 SOTA 复核
Day 171-172 读的是两个具体框架（smolagents 的 agent 主循环、DeepEval/Inspect 的评测口径）。今天把视角一次性拉到全局：执行 AICAP 硬纪律——agent 领域半衰期约 6 个月，必须逐项确认整条主线资料是否还活着、还是不是 SOTA。
OSS PR 选题与 good-first-issue 定位
前三天（Day 171-173）是「读懂主流框架 + 把全局资料过期体检一遍」，结论是 smolagents / DeepEval / Inspect AI 三个 repo 都仍是 2026 活跃主线、未冻结。
英文 writeup 体例
Day 174 学了 OSS 选题方法论、复现了一个外部 bug。今天把「复现/去循环」这类素材转成可对外的英文技术 writeup——学标准体例 problem → repro → fix → eval，并把本仓最干净的一个真实叙事（evalBaseline.ts 循环自评 → groundTruthEval.ts 独立 ground-truth）写成英文 README 段落。
抽独立公开 repo 工程化
B18 是整个 AICAP-180 的收口批次。回顾整条曲线：
真实 OSS PR 实现
B18 的主线是「把私有资产变成外部可验证的工件」，今天是这条主线上的关键一跳：
提 PR + 英文沟通
B18 的能力曲线在这里到达「对外说服」的顶点：
HF Agents Course Unit4 GAIA
到 B18 尾声，AICAP 的评测能力已经历一整条自有评测链：
(stretch) verifiers Environment + 收口
这是 AICAP-180 的最后一天，也是 B1→B18 整条能力曲线的收口。