收尾 + Inspector 端到端验收

阶段: B6 · 真 MCP server (2026-07-28 spec)（Day 51-60） 标签: #mcp-inspector #e2e-acceptance #stateless #milestone

今日导引（由浅入深）

B6 整块（Day 51-60）从 stateless 规范精读起步，经 SDK/Zod/tools/list/tools/call、AML 工具上网、LLM 客户端、零信任校验、对拍回归，今天收口。收口不是再加功能，而是端到端验收 + 诚实盘点收益与缺口：用 MCP Inspector 一次跑通全工具，把 B6 攒下的三个里程碑数（tools/call 3/3、恶意拦截 9/9、对拍 20/20）汇成验收 transcript。这是 B6 在 B1→B18 曲线上的封顶，也是向 B7（OAuth 2.1 + MCP 安全 + CI gate）的交棒——今天明确把鉴权列为「留给 B7 的已知缺口」。今日「最小可判定产出」：Inspector 验收 transcript + 平均往返延迟（本地实测，待跑后填）+ 里程碑数归档。

1. 机理精读

整块复盘 stateless 的三项收益（对照 Day 51 的规范精读）：

1. 可水平扩展：stateless 把每个 JSON-RPC 请求当独立 HTTP 调用，无需服务端维护 session（旧版的 Mcp-Session-Id 握手 + SSE 长连），于是可直接跑在普通 round-robin load balancer 后，无需粘性路由。toolRegistry.ts 头注（第 4-6 行）正是此意：「移除初始化握手与协议级 session 头，让远端 MCP server 能跑在普通 HTTP 基础设施后」。
2. tools/list 可缓存：无状态发现意味着任意节点都能回完整工具清单，客户端可按 TTL 缓存（呼应 Day 54）。list() 的稳定排序（toolRegistry.ts 第 170 行）保证缓存键确定。
3. 无粘性路由：请求自带全部上下文，任意节点可处理任意请求，运维大幅简化。

端到端验收 = Inspector 一次跑通全工具的 tools/list + tools/call。验收不是单元测试的重复，而是从「客户端工具」视角确认：真有一个外部 MCP 客户端（Inspector）能连上、能发现 3 个工具、能逐个调通、能拿到结构化结果。这是「能上线」的最后一次人在回路的确认。

诚实盘点剩余缺口（不掩盖、明确交棒）：

• OAuth 2.1 鉴权留给 B7：当前 server 无 Bearer/OAuth（toolRegistry.ts 头注第 14 行「没有 OAuth 授权」明确标注）。stateless 便于扩展，但也便于被任意调用——无鉴权下绝不能暴露公网（见 SOTA 检查 AVOID）。
• Tasks / 长任务扩展尚未覆盖：2026 规范把长任务从核心挪到 Tasks extension（tasks/get|update|cancel，toolRegistry.ts 头注第 14-15 行）。本块只做同步 tools/call。
• resources / prompts 尚未覆盖：MCP 还有 resources（服务端资源暴露）、prompts（提示模板）原语，本块聚焦 tools，未触及。

把这三项缺口排成「上线就绪度」清单，可一眼看出 B6 到哪、还差哪：

这张表就是「诚实复盘」的载体——B6 把契约层 + 安全输入层 + 回归层做实了，但「可安全公网部署」还差鉴权和 CI gate 两块，明确交棒 B7。

关键权衡复盘：stateless 用「客户端每次携带上下文」换「服务端无状态」——这是用带宽/客户端复杂度换运维可扩展性的典型架构取舍，与 Day 51 讲的「代价是上下文需由客户端在每次请求里携带」首尾呼应。

端到端验收为何不能被单元测试替代？ 三个层次的覆盖各不相同：

1. 单元测试（如 validate 测试）：覆盖单个函数的逻辑分支，但不经过 transport/序列化。
2. 对拍测试（Day 59）：覆盖「进程内 vs HTTP」两条路径的一致性，但用的是测试 harness 构造的请求，不是真客户端。
3. Inspector 端到端验收（今天）：用一个真实的、独立实现的 MCP 客户端（Inspector，非本仓代码）连真 server，确认「外部世界看到的契约」成立——这是前两层都给不出的「跨实现互操作性」证据。

三层缺一不可：单元保逻辑、对拍保迁移、E2E 保互操作。今天补的正是最外层那环。

2. 推导 / 手算 / 代码走读

Day 60 是验收日，走读「验收依赖的真实底座 + 归档对象」：

• 验收入口：McpToolRegistry.handle(req)（toolRegistry.ts 第 199 行）/ list()（第 169 行）/ call()（第 183 行）——Inspector 经 HTTP transport 打到 server，server 内部最终落到这三个进程内方法（B6 全程的对照基线）。
• tools/list 验收：Inspector 调 tools/list → list() 返回按 name 稳定排序的 3 个 McpToolSpec（assessCase/draftSar/listTypologies）。记「工具数」。
• tools/call 验收：对 3 个 AML 工具各 call，成功走 {content: result}（第 209 行）。底层委托真实模块——draftSar → src/aml/sarDraft.ts 的 draftSar()（第 61 行，generatedBy:'rule-template'）；assessCase → src/aml/typology.ts 规则引擎；审计留痕 → src/aml/auditTrail.ts 的 AuditTrail（第 123 行）。这些 src/aml/* 与 toolRegistry.ts 均为真实已有文件（本批已 Read 核实）。
• 里程碑数来源：tools/call 3/3（本日）、恶意拦截 9/9（Day 58 的 validate→-32602 路径）、对拍 20/20（Day 59 的 differential test）——三者都建立在同一份确定性实现上。
• 延迟测量：单次 tools/call 往返延迟为本地实测值（Inspector 本地连本地 server，无网络跳数），算 3 工具平均。注意这是本地数，非生产网络延迟。
• 归档：transcript 与里程碑数写入 docs/aipa/day60-*.md（交叉引用，非本仓代码走读）。

B6 十天的能力曲线小结（每天的「最小可判定产出」串成一条上线路径）：

这条曲线的诚实底色：B6 把「协议形状 + 业务工具 + 客户端 + 安全 + 回归」串通了，但 server 上网部分整体待建、模型选对率需 key——验收 transcript 是把这些目标变成实测数的最后动作，今天尚未跑完。

3. 今日实战

1. 用 npx @modelcontextprotocol/inspector 连本地 AML server。
2. 调 tools/list，记录返回的工具数（预期 3：assessCase/draftSar/listTypologies）。
3. 对 3 个 AML 工具各 tools/call 一次，记成功数与每次往返延迟，算平均延迟。
4. 汇总 B6 三个里程碑：tools/call 成功率（目标 3/3）、恶意输入拦截率（9/9，Day 58）、对拍一致（20/20，Day 59）。
5. 把 transcript 与里程碑数归档到 docs/aipa/day60-*.md，并在文末诚实列出剩余缺口（OAuth/Tasks/resources/prompts）。

4. 今日实测 / 产出

• 状态：待建——验收 transcript：tools/call 成功率目标 3/3 工具、恶意输入拦截率 9/9（Day58）、对拍 20/20（Day59）；平均往返延迟为本地实测值（待跑后填）。
• server 上网部分待建；底层 src/aml/* 与 toolRegistry.ts 为真实已有。
• 无需 key（Inspector 本地）。

（按诚信纪律：「待建」「待跑后填」逐字保留；3/3、9/9、20/20 为各日目标数，平均延迟未臆造具体值。）

5. 常见误区 / 陷阱

• 在无鉴权下把 server 暴露公网：SOTA 检查硬告警。stateless 便于扩展也便于被任意调用——OAuth 2.1 留给 B7，未鉴权前只能本地/内网。
• 把里程碑数当「已测得」上报：3/3、9/9、20/20 均为目标，server 上网部分待建、延迟待跑——验收 transcript 未跑完前不能宣称达成。
• 以为 B6 已覆盖完整 MCP：Tasks 扩展、resources、prompts 都未做；本块只覆盖同步 tools/call + 工具发现。
• 把本地延迟当生产延迟：Inspector 本地连本地无网络跳数，平均延迟仅作本地基线，不代表跨网部署性能。
• 把「Inspector 跑通」当「生产就绪」：互操作性 ✅ 不等于安全/可扩展 ✅。缺的鉴权、限流、Tasks 长任务、resources 都还在 B7+ 待办里，验收只证明「契约层成立」。
• 复盘只报收益不报缺口：诚信纪律要求收尾文档明确列出 OAuth/Tasks/resources/prompts 四项缺口并交棒 B7，不能让「3/3 调通」掩盖「还不能上公网」。

6. 学习资源（每条带 YYYY-MM）

• MCP 规范（2026-07-28，硬复查点 07-28）—— stateless core、tools 原语、Tasks/resources/prompts 扩展边界。
• MCP Inspector（随 spec 升级，用最新版以支持 2026-07-28 stateless 语义）—— 端到端验收工具。
• MCP TypeScript SDK server 文档（2026-03）—— McpServer + StreamableHTTPServerTransport 落地。
• OAuth 2.1 / RFC 9728（Protected Resource Metadata）/ RFC 8707（Resource Indicators）—— B7 鉴权缺口的标准依据（前置阅读）。
• FIS × Anthropic「Financial Crimes AI Agent」（2026-05-04，GA 2026 H2）—— AML Copilot 工具集的产品对标主线。

SOTA检查 (2026-06 更新)

• 当前主流方案：MCP 2026-07-28 stateless server + Inspector 端到端验收，是 2026 远端工具暴露的主线形态。
• 是否仍 SOTA：是，但本块主线 MCP 2026-07-28 spec 须在 07-28 定稿后整体重验（写作时尚未最终定稿）。
• 过时黑名单 / AVOID：禁止在无鉴权下把此 server 暴露到公网——stateless 便于扩展但也便于被任意调用，OAuth 2.1 鉴权（RFC 9728/8707）为已知缺口，B7 补齐。禁止把旧 session-based Streamable HTTP 叙事当主线。
• 下次复查点：07-28 MCP 规范定稿后整体重验（Mcp-Session-Id 是否降级为可选、content 字段、Tasks 扩展形态）；B7 接入 OAuth 2.1 + CI gate 后回填验收延迟与鉴权覆盖。

衔接

• 昨天：Day 59 — 进程内 mock vs 真 server 等价回归（对拍 20/20，验证迁移无漂移）。
• 今天：B6 收口——Inspector 端到端验收，复盘 stateless 三项收益与剩余缺口（OAuth/Tasks/resources/prompts），里程碑数 3/3·9/9·20/20 归档。
• 明天：Day 61（B7 · OAuth 2.1 + MCP 安全 + CI gate 起点）——补齐本块明确留下的鉴权缺口，把 server 从「本地可调」推向「可安全暴露 + CI 守门」。