在企业级开发平台里做资源管理，看起来是个简单的活儿，实际坑不少。你自己电脑上可能存着一堆密码和API密钥，团队协作时每个人又各管各的，新人入职配环境得翻半天文档。AI工具普及以后更乱了——查数据库的、发邮件的、调地图的，每个都要重新填配置，凭证越攒越多，最后谁也理不清。
我们团队倒腾了一段时间，设计了一套三层级工作区 + 凭证自动匹配的方案，效果还不错，这里分享一下思路。
一、核心问题
凭证爆炸是最直观的麻烦。现在各种AI工具（MCP服务）爆发式增长，查数据库、发邮件、调地图、调AI模型……每个都需要填host、port、密码、API key。用户手里攒了一堆凭证，散落在各处，安全没保障，管理也头疼。
重复配置的问题也很常见。同一份数据库配置，个人项目填一遍，团队协作又填一遍，AI助手再用还得填。改一次密码要到处同步，不同步就报错。
协作方面更是费劲。团队成员各自维护自己的凭证清单，A配好了服务器，B想用还得重新来一遍，信息孤岛严重。
新用户注册后面对一个空白的系统，不知道从哪里开始配置，只能翻文档或者找人问。
我们的目标是凭证只填一次，AI工具自动拿去用。用户只管告诉AI要做什么，系统自己找到正确的凭证，安全地交给对应的工具执行。
二、核心设计：三层工作区 + 降级优先级
2.1 三个层级
我们按使用场景把资源分成三个层级，规则是高层可以看见低层，低层看不见高层。
Level 1是个人层，用于个人日常干活的环境，只有自己能看到。
Level 2是项目/团队层，用于团队共享的生产资源，团队成员都能访问。
Level 0是示例层，供新手上手使用的示例配置，也是只有自己能看到。
继承逻辑是这样的：在项目/团队层（Level 2）工作时，可以看到团队资源、个人资源和示例资源；在个人层（Level 1）时，可以看到个人资源和示例资源；示例层（Level 0）是一个独立的沙盒，仅供学习和复制改造。
2.2 降级优先级
调用某个资源时，系统按照**个人层（Level 1）→ 项目/团队层（Level 2）→ 示例层（Level 0）**的顺序查找，返回第一个命中的配置。 整个流程可以这样理解：收到调用请求后，先查个人层有没有配置？有就直接返回；没有就继续查项目/团队层；还没有就查示例层；如果示例层也没有，就提示未配置。
这样设计有几个考虑。个人配置最贴近当前工作需求，优先级最高，这很合理。如果没有个人配置，自动使用项目/团队共享配置，能保证协作一致性。新人什么都没配的时候，示例配置让系统可以"开箱即用"，不至于一上来就卡住。
举个例子，如果你在个人层配置了开发库账号，系统就自动用这个。如果没有个人配置，但项目层有生产库只读账号，系统就自动降级使用项目配置。如果什么都没有，系统会使用示例层的demo库（只读，假数据）。整个过程完全不需要用户操心。
三、多MCP场景下的凭证管理
3.1 什么是MCP
MCP（Model Context Protocol）让AI工具能够调用外部服务。比如PostgreSQL MCP让AI自动查询数据库，邮件MCP让AI自动发送邮件，地图MCP让AI查询地理位置。
但问题在于每个MCP需要的凭证字段可能完全不同。
3.2 统一凭证模型
我们把所有凭证统一成一种存储结构：
| 字段 | 说明 | 示例 |
|---|---|---|
workspace_id | 所属工作区 | ws_project_123 |
credential_type | MCP类型 | postgresql、redis、s3、email |
config_details | JSON配置 | {"host":"...","user":"...","password":"..."} |
3.3 按MCP类型和降级优先级查找
AI调用某个MCP服务时，请求里需要带两个信息：mcp_type（需要什么类型的服务，比如postgresql）和workspace_id（当前在哪个工作区）。
系统的处理步骤是：先根据workspace_id确定当前层级，然后按降级顺序（Level 1 → Level 2 → Level 0）查找该credential_type的配置，最后返回第一个匹配的（密码自动解密）。
例如，AI调用postgresql MCP，当前workspace_id是项目A。系统先查个人层有没有postgresql配置？有（比如开发库账号）就直接用。没有就降级到项目/团队层查，有（比如生产库只读账号）就用这个。还没有就继续降级到示例层查，有（比如demo库）就用这个。
3.4 按MCP类型定制降级策略
不是所有MCP都适合"个人 → 项目 → 示例"这套固定顺序。比如生产数据库MCP只允许项目层，禁止降级到个人；公共地图API可以优先使用示例层的公司统一Key，个人可以覆盖。
所以我们支持按MCP类型配置独立的降级链。比如，postgresql_prod可以只查项目/团队层，没配置直接报错；postgresql_dev可以从个人层查到项目层；amap可以从示例层查到个人层。
四、凭证安全保障
凭证集中管理以后，安全这块需要更加重视。
传输方面，前端使用RSA加密，防止中间人攻击。存储方面，后端使用AES加密，数据库里不保存明文。使用方面，仅在MCP服务调用时临时解密，用完后立即丢弃。权限方面，使用JWT认证 + 工作区隔离，只能访问自己层级的凭证。审计方面，所有调用记录日志，谁用了哪个凭证都可以追溯。
这里的关键设计是工作区ID隔离。每个AI请求必须携带workspace-id，系统严格按照层级返回凭证，跨工作区无法获取数据。就算某个AI工具被恶意利用，也只能访问该工作区内的凭证，无法横向扩散。
五、适用场景
我们发现这几类场景特别适合这套方案。
个人开发者 + AI助手：自己配置一套凭证（Level 1），各种AI工具直接拿去用。查询数据库、发送邮件、调用API，口令只输一次，后续全靠AI自动匹配。
团队协作 + 资源共享：团队共享生产环境的凭证（Level 2），成员个人的测试环境（Level 1）自动继承。新成员加入后可以立即获得全部团队凭证，AI工具立即可用，不需要手动同步。
多AI工具统一管理：平台接入了十几个MCP服务，用户不需要记住哪个工具需要填什么凭证。统一在工作区配置，系统自动分发。修改一次数据库密码，所有用到它的AI工具都会自动生效。
企业级凭证托管：敏感凭证集中加密存储，外部系统通过API推送标准配置，保证开发、测试、生产环境的一致性，避免"我本地好好的"这种尴尬。
六、总结与思考
做这套系统最大的感受是：凭证管理的核心不是"存"，而是"用"。
把凭证存起来并不难，难的是让各种AI工具能够安全、方便地拿到正确的凭证，而不需要用户反复填写。三层级解决了"存在哪里"和"谁能看到"的问题，自动匹配解决了"给谁用"的问题，加密和隔离解决了"如何安全"的问题。
尤其是在多MCP的场景下，凭证爆炸是个真实存在的麻烦。我们希望用户面对十几个工具时，不需要填十几遍配置，而是填一次，系统自动适配所有需要的工具。这才是该有的体验。
如果你也在折腾资源管理或者AI工具集成，希望这篇文章能给你一些灵感。欢迎交流想法，特别是如果你也在做多AI工具的平台，凭证管理这块是怎么设计的？有没有更好的自动匹配思路？
使用技术：FastAPI + SQLAlchemy + PostgreSQL + Vue 3
核心特性：三层级工作区 | 凭证自动匹配MCP服务 | RSA+AES加密 | 层级继承与降级优先级
