# FDE W7D3 评测题 · Spring AI MCP Client/Server 与 Observability
> 对应手册：`FDE-W7D3-SpringAI-MCP与可观测-学习手册.html`
> 候选人背景：36 岁，Java + 大数据 + 医疗保险。场景统一用「保险知识库 / 特药理赔 Agent」。
> 评分：每题按"考察点 + 评分维度"给分，L1/L2 答到要点即过，L3/L4 看深度与工程权衡。
---
## 一、L1 基础（概念辨识，4 题）
### 1. 什么是 MCP？它和 W2 手写的"保单/规则 Server"是什么关系？
- **考察点**：MCP 协议本质与演进关系。
- **评分维度**：① 模型连接外部工具/数据的开放协议；② 标准化 tools/resources/prompts；③ W2 是自定义协议，MCP 是标准化放大。
参考答案
MCP（Model Context Protocol）是统一的开放协议，把"模型/Agent 如何连接外部工具与数据"标准化为 tools/resources/prompts。W2 我们手写的保单/规则 Server 是自定义协议；MCP 就是把这类 Server 标准化——任何兼容 MCP 的 Client 都能发现并调用，工具方与模型方互不需知道对方技术栈。W2 是"原理+手写"，W7D3 是"标准协议+框架支持"。
参考答案
本质区别：本地 @Tool 是同进程 Java 方法，编译期注解扫描；MCP Client 调的是远端 Server 进程，运行时通过 listTools 动态发现并转成 ToolCallback。后者有网络开销、跨团队、工具可独立部署扩缩。ChatClient 调用体验一致，但远程工具要额外处理超时/重试/降级。
参考答案
Stdio：Client 启动 Server 子进程、通过 stdin/stdout 通信，适合同机、随用随起的本地工具/调试。HTTP/SSE：Client 通过 HTTP 连已部署的 Server，适合独立部署、多 Client 共享的生产服务。保险平台的保单 Server 应选 HTTP/SSE，可水平扩展、多应用共享、便于加鉴权限流。
参考答案
三支柱：结构化日志（Logs）、聚合指标（Metrics）、链路追踪（Traces）。AI 应用更需要：LLM 调用不可预测（高时延/可能失败/输出随机）、成本来自 token 需按 trace 统计、工具调用链长（模型→工具→回灌）需链路串联定位。没有 Trace，一次理赔答错无法定位是哪一层问题。
参考答案
```java
McpClientTransport transport = HttpClientSseClientTransport.builder("http://mcp-policy-svc:8081").build();
McpSyncClient client = McpClient.sync(transport).build();
client.initialize();
List callbacks = client.listTools(null).tools().stream()
.map(t -> new McpToolCallback(t, client)).toList();
ChatClient chatClient = ChatClient.builder(chatModel).defaultTools(callbacks).build();
```
要点：用 HTTP/SSE 传输连已部署 Server；initialize 建立会话；listTools 动态发现并转 ToolCallback。生产要加超时+重试+降级防 Server 不可用带崩链路。
参考答案
用 `@Tool` 标注要暴露的方法（写清 description/@ToolParam），在 Spring Boot 启动类加 `@EnableMcpServer`（引入 MCP Server starter），框架自动把这些 @Tool 暴露为标准 MCP 协议。这样保单系统团队的 Java 资产无需改造即可被任意 MCP Client（Spring/Python/JS）调用，实现工具资产化。注意 Server 侧必须做鉴权与输入校验。
参考答案
```
上游 Agent ──MCP──> 我的应用(MCP Server: 特药推理能力)
│ 同时作为 MCP Client
└──MCP──> 保单 Server / 规则 Server / 药品 Server
```
底层是保单/药品/规则三个 MCP Server（各团队维护），上层理赔 Agent 应用既消费（Client）又暴露（Server），形成工具网络。Gateway 可在 MCP 传输前做统一鉴权限流，构成"MCP 网格"。这正是 W2 单 Server 思想在 Spring AI 下的放大。
参考答案
至少埋：trace_id（全链路 ID）、model（实际模型）、tool（工具名）、prompt/completion tokens、latency_ms、status（成功/失败/降级）。在 Advisor 里：从 MDC 取入口传入的 trace_id（不新建），调用前后用 Micrometer Timer/Counter 记录 model/tool/latency，token 取 ChatResponse 真实 Usage。这样一次理赔可聚合分析。直接对齐 W4 的 Trace 字段规范。
参考答案
MCP 只解决连接标准化，不解决工具本身问题：① 鉴权——暴露即对外开放，必须做 token/scope 防越权查他人保单；② 输入校验——防恶意/越界参数；③ 权限与幂等——有副作用工具（创建工单）要权限+幂等+确认；④ description 质量——即使被别人调，工具描述仍影响调用准确率，要写清。保险场景合规尤其严。
参考答案
trace_id 在入口（Gateway/Controller）生成并贯穿全链路，Advisor 只取 MDC 里的，否则每段对话各自生成 id，无法串联定位。工具调用 Trace 要展开成子 span（模型→tool→回灌）保留因果，扁平记一条会丢失"哪步慢/哪步错"。token/cost 必须从 ChatResponse.getMetadata().getUsage() 取真实值，不可估算。且要和 W7D4 Gateway 出口的 trace_id 一致。
参考答案
① 统一 Trace：所有 AI 调用经 Advisor 埋点，trace_id 贯穿 Gateway→应用→工具，对接现有 APM（Prometheus+链路追踪）；② 成本可控：token/cost 指标进 Kafka+数仓，按业务线/险种核算 AI 成本；③ 质量可查：工具错误率、拒答率、幻觉率进监控大盘并告警；④ 合规可审：日志含 trace_id+用户标识，理赔决策全程可追溯（监管刚需）。结合大数据（数仓分析）+医保（审计刚需）背景，可观测性从"会用 Micrometer"升到"平台能力"。
参考答案
方案：
- 保单团队用 `@Tool + @EnableMcpServer` 暴露 Java 保单 MCP Server；特药团队用 Python MCP SDK 暴露特药目录 MCP Server（体现跨语言解耦）。
- 理赔 Agent 作为 MCP Client，用 McpSyncClient（HTTP/SSE）连两个 Server，listTools 发现后转 ToolCallback 注册到 ChatClient，像调本地工具一样调。
- 韧性：每个 Client 配超时 + 指数退避重试 + 降级（Server 不可达时返回"暂无法查询，转人工"），避免雪崩。
- 可观测：Advisor 埋 trace_id/model/tool/token/latency，对接 APM。
达标线①要讲清：① MCP Client 用 McpSyncClient 连远端、动态发现 tools 转 ToolCallback；② MCP Server 用 @Tool + @EnableMcpServer 暴露 Java 方法为标准协议；同一应用可双栈形成工具网络。
参考答案
方案（规范→实现→衔接）：
- W4 定义 Trace 字段规范（trace_id/model/tool/step/token/cost/latency/status/error）——这是"要记什么(Why)"。
- W7D3 用 Advisor 埋点 + Micrometer 实现——"怎么记(How)"：入口（Gateway/Controller）生成 trace_id 写入 MDC，Advisor 贯穿取用；工具调用展开为子 span（模型→tool→回灌）；token/cost 取 ChatResponse 真实 Usage。
- W7D4 Gateway 在 HTTP 出口也记同一 trace_id 与 model/token，必须与应用层 trace_id 一致，否则链路断裂——Gateway 管接入层、Advisor 管应用层，二者同一 id 串联。
- 审计落库：Trace 数据（含 user_id、决策结果、引用条款）进数仓/对象存储，按监管留存期保留，支持按 trace_id 回放任意一笔理赔的完整链路。
结论：W4 规范、W7D3 实现、W7D4 Gateway 出口，三者靠同一 trace_id 串成端到端可审计链路。