KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
MCP Protocol Engineering：从协议边界到可交付 Bridge — keel 龙骨
MCP Protocol Engineering 的参考信息：MCP Protocol Engineering：从协议边界到可交付 Bridge
课程定位
模型会提出工具请求，但真正的系统还需要知道：工具从哪里来、谁可以看到、当前版本是什么、调用是否可恢复、结果如何回到上下文、失败能不能被解释。MCP 把这些问题放进一个可协商的协议边界里；工程师仍然要负责授权、状态、超时、审计和生产替换。
章节地图
| 章节 | 关键问题 | 项目落点 |
|---|---|---|
| 01 | MCP 解决什么，不解决什么？ | contracts.py 的边界对象 |
| 02 | Host、Client、Server 如何分责？ | JsonRpcMessage 与会话 |
| 03 | 版本和能力怎样协商？ | 初始化与 server/discover |
| 04 | tools、resources、prompts 如何成为可发现原语？ | 注册表与只读发现 |
| 05 | 结果、结构化输出和用户输入如何返回？ | MRTR / elicitation 形状 |
| 06 | stdio、HTTP、通知和取消怎样传播？ | 可替换传输层 |
| 07 | 授权和本地服务器为什么不能省？ | bearer 验证与最小权限 |
| 08 | 长任务如何暂停、恢复和取消？ | Tasks 状态机 |
| 09 | 如何证明客户端真的兼容？ | 兼容矩阵、事件和指标 |
| 10 | 如何把课程项目提升为生产 Bridge？ | Incident Bridge capstone |
学习闭环
每章都按“事实 -> 决策 -> 失败 -> 验证 -> 替换点”推进。阅读时先运行项目的对应示例，再回到正文解释输出为什么如此；不要从一开始就接入真实模型或远端服务器。
版本提示
本课程按 MCP 2026-06-18 / 2026-07-28 文档中的现代协议形状组织，重点覆盖版本协商、server/discover、Streamable HTTP、任务扩展和授权。具体 SDK 的 API 可能变化，生产实现以官方规范和 SDK 版本锁定为准。