实现MCP任务结果提交稳定性映射
This commit is contained in:
andy
159
docs/import/20260712/MCP_最终提交稳定性改造要求_给开发伙伴_2026-07-12.md
Normal file
159
docs/import/20260712/MCP_最终提交稳定性改造要求_给开发伙伴_2026-07-12.md
Normal file
@@ -0,0 +1,159 @@
|
||||
# MCP 最终提交稳定性改造要求
|
||||
|
||||
## 一、改造目标
|
||||
|
||||
在不改变现有业务规则和业务系统输出规范的前提下，确保 Agent 生成的业务结果可以稳定转换为 MCP 可接收的 payload。
|
||||
|
||||
我们不要求 Agent 自行理解或猜测 MCP transport 字段。`source_event_index`、`ai_task_results[]` 等字段的含义、类型和映射，必须由 MCP/Adapter 侧提供确定性实现。
|
||||
|
||||
目标链路必须是：
|
||||
|
||||
```text
|
||||
booking-desk-event Skill
|
||||
→ 业务结果
|
||||
→ Result Adapter
|
||||
→ MCP payload
|
||||
→ Schema Validator
|
||||
→ 冻结
|
||||
→ MCP 提交一次
|
||||
```
|
||||
|
||||
## 二、必须保持不变的内容
|
||||
|
||||
MCP 侧不得通过修改以下内容来解决字段接收问题：
|
||||
|
||||
- 现有公开业务 JSON 根结构；
|
||||
- `message_events` 的业务事件类型和 subtype；
|
||||
- Parent Group / Child Group 业务语义；
|
||||
- Trace、Parent、linked/derived 事件关系；
|
||||
- S10、S99 和基础设施错误规范；
|
||||
- Skill 的业务裁决权；
|
||||
- 一次冻结、一次提交、失败不重试的生命周期。
|
||||
|
||||
MCP 只负责接收和处理已经形成的业务结果，不负责重新解释业务含义。
|
||||
|
||||
## 三、必须由 MCP/Adapter 侧承担的职责
|
||||
|
||||
### 1. 提供确定性的 payload mapping
|
||||
|
||||
必须建立固定的：
|
||||
|
||||
```text
|
||||
BusinessResult → MCP payload
|
||||
```
|
||||
|
||||
映射层。
|
||||
|
||||
该层不能由 LLM 临时生成，也不能让 Agent 根据字段名称猜测。
|
||||
|
||||
至少需要明确：
|
||||
|
||||
| 字段 | 必须明确的内容 |
|
||||
|---|---|
|
||||
| `source_message_id` | 来源、类型、必填规则、透传方式 |
|
||||
| `source_event_index` | 真实含义、类型、索引基准、对应数组 |
|
||||
| `related_source_event_index` | 单事件关系如何映射 |
|
||||
| `related_source_event_indices` | 多事件关系如何映射、顺序和唯一性 |
|
||||
| `ai_task_results[]` | item 的完整结构和业务结果映射方式 |
|
||||
| `extraction_warnings` | 是否必填、允许的结构和空值规则 |
|
||||
|
||||
`E1`、`E2` 只能作为 Agent/业务结果中的内部事件标识，不能默认当作 MCP 的 `source_event_index`。
|
||||
|
||||
### 2. 负责生成 `source_event_index`
|
||||
|
||||
Adapter 必须建立事件映射，例如：
|
||||
|
||||
```text
|
||||
E_CHILD_1 → MCP index 0
|
||||
E_CHILD_2 → MCP index 1
|
||||
E_PARENT → MCP index 2
|
||||
E_TRACE → MCP index 3
|
||||
```
|
||||
|
||||
实际索引类型和起始值必须以真实 MCP schema 为准，不允许 Agent 猜测。
|
||||
|
||||
对于：
|
||||
|
||||
```json
|
||||
"related_source_event_indices": ["E_CHILD_1", "E_CHILD_2"]
|
||||
```
|
||||
|
||||
Adapter 必须将其转换成 MCP 真实要求的索引格式，并保持顺序、唯一性和关联正确。
|
||||
|
||||
### 3. 支持跨事件 Trace
|
||||
|
||||
当前业务要求：
|
||||
|
||||
- 一个补充请求覆盖完整 Parent split 的全部 Child；
|
||||
- Trace 必须关联全部 Child；
|
||||
- 不得绑定到第一个 Child E1；
|
||||
- 必须保留完整跨事件关系。
|
||||
|
||||
因此 MCP/Adapter 必须能够接收和保持：
|
||||
|
||||
```text
|
||||
Trace
|
||||
→ related_source_event_indices[]
|
||||
→ 全部 Child New Booking
|
||||
```
|
||||
|
||||
不能把多目标 Trace 压缩成单一 `source_event_index`。
|
||||
|
||||
## 四、提交前必须有 Schema Validator
|
||||
|
||||
MCP 调用前必须校验：
|
||||
|
||||
- 必填字段；
|
||||
- 字段类型；
|
||||
- 允许值；
|
||||
- 数组顺序；
|
||||
- 索引是否存在；
|
||||
- 关系是否悬空；
|
||||
- 是否存在重复索引；
|
||||
- 是否存在未知字段；
|
||||
- `ai_task_results[]` item 是否符合完整 schema；
|
||||
- `source_message_id` 是否正确传播。
|
||||
|
||||
校验失败时：
|
||||
|
||||
- 不让 Agent 猜字段；
|
||||
- 不修改已经冻结的业务结果；
|
||||
- 不重新调用 Skill；
|
||||
- 不重试 MCP；
|
||||
- 按既有 transport/基础设施错误通道结束；
|
||||
- 保留原始错误和 mapping 诊断。
|
||||
|
||||
## 五、必须提供的 MCP 交付物
|
||||
|
||||
请提供以下内容：
|
||||
|
||||
1. 当前实际使用的完整 MCP tool schema；
|
||||
2. `ai_task_results[]` 的完整 item schema；
|
||||
3. `source_event_index` 和关联索引的正式定义；
|
||||
4. BusinessResult → MCP payload mapping 文档；
|
||||
5. 一个成功的完整 payload 示例；
|
||||
6. 一个跨 Child Trace 的成功示例；
|
||||
7. 一个错误字段被拒绝的示例；
|
||||
8. Adapter 或 MCP wrapper 的实现位置；
|
||||
9. Schema validation 和一次提交测试结果；
|
||||
10. 失败不重试、payload 不被修改的测试证据。
|
||||
|
||||
## 六、验收条件
|
||||
|
||||
以下测试必须通过：
|
||||
|
||||
1. Agent 使用 `E1` 时，Adapter 不会盲目把它当成 MCP index；
|
||||
2. 错误关系索引会在提交前被拒绝；
|
||||
3. 缺失 `source_message_id` 会按既有基础设施错误处理；
|
||||
4. MCP 失败时只提交一次，不重试；
|
||||
5. 提交 payload 与冻结结果的 mapping 可追溯；
|
||||
6. MCP 响应不会污染业务 JSON。
|
||||
|
||||
|
||||
## 最终要求
|
||||
|
||||
请不要通过继续增加 Prompt 文字，让 Agent 学习 MCP 内部字段含义来解决问题。
|
||||
|
||||
我们要求的是：
|
||||
|
||||
> MCP/Adapter 提供稳定、确定性、可验证的业务结果到 MCP payload 的转换能力；Agent 负责业务结果，MCP 负责 transport 接收，两者之间不能依赖模型猜测。
|
||||
Reference in New Issue
Block a user