你在这里。看看这个问题与其他知识怎样相连。
选择节点前往页面 · 展开后可留在地图中阅读
一个问题
这么多 provider，应该怎样分类？
先看资源和职责，再看它住在哪个目录。
用三个问题选入口
| 想解决什么 | 代表实现 | 先核对什么 |
|---|---|---|
| 访问已有数据 | FS、JSON、KV、DID Space | 数据归属、持久化、读写能力 |
| 观察或操作运行环境 | proc、registry、observability、UI | 生命周期、调用者范围、操作效果 |
| 接入外部服务 | HTTP、MCP、消息服务 provider | 认证、限流、远端失败与副作用 |
这些是学习分组，不是互斥的类型系统。仓库中的 core、basic、runtime 等目录用于组织实现，不能仅凭目录推断某个 provider 在所有部署中都已挂载。
名单不能代替发现
想读取任务，先在当前工作空间发现实际挂载，再查看路径说明与能力。某个实现存在于源码中，只证明可以研究它；不证明当前服务已配置凭据，也不证明匿名读者能够调用。
可以先从 JSON 看结构如何映射，再从 FS 看本地边界，从 MCP 看协议适配。这样比较的是同一组问题：名字怎样解析、返回什么、操作有什么效果、失败怎样表达。
技术目录可继续看 Provider catalog，把它作为实现导航而非当前会话状态。