Postman 的 Governance、Catalog、Workspaces 与 MCP
理解 Postman 从团队协作、API 治理、Catalog 到 AI agent 接入的组织级扩展能力。
#tech / dev / api
#type / synthesis
#status / growing
#resource / postman
#tech / ai
[!info] related notes
- 所属 MOC: postman-moc, AI MOC
- 相关概念: mcp-moc, Function Calling, Open API Swagger
- 易混淆概念: postman-cli-and-monitors, postman-mock-documentation-and-spec-hub
- 相关资源: postman
Postman 的 Governance、Catalog、Workspaces 与 MCP
范围
这篇笔记讲的是 Postman 从“团队 API 工具”继续扩展到“组织级 API 平台”和“AI agent 上下文层”的部分。
为什么要放在一起理解
这些能力都不是单次调接口要用的，而是 API 资产规模变大以后才出现的需求：
- 谁在协作
- API 怎么被发现
- API 质量怎么统一
- AI agent 怎么拿到真实 API 上下文
依赖路径 / 调用链 / 演进链
1. Workspaces
Workspace 是 Postman 协作的基本容器，里面可以共享：
- collections
- environments
- docs
- mock servers
- monitors
- flows
- specs
2. API Distribution / API Network
当资产需要被团队或合作伙伴消费时，分发问题就出现了：
- 内部发现
- partner onboarding
- public API 发布
3. API Catalog
Catalog 回答的是组织级问题：
- 我们到底有哪些 API
- 谁负责
- 哪些 API 缺文档、缺监控、缺治理
4. API Governance
Governance 关注的是一致性和质量控制，例如：
- 命名规范
- 错误格式
- 分页格式
- breaking change 风险
5. MCP / Agent Mode
这一步代表 Postman 从“给人用”进一步扩展到“给 agent 提供 API 上下文”。
MCP Server 的价值是让支持 MCP 的 coding agent：
- 访问 Postman workspace 里的真实 API 资产
- 理解 collection、environment、documentation、spec
- 基于真实 API 上下文生成 client、测试或集成代码
对比与易混淆点
Workspaces 不等于 Catalog
- Workspaces 更偏协作空间
- Catalog 更偏组织级 API 目录和可见性
Governance 不等于测试
- 测试更关注“功能是否正确”
- governance 更关注“设计和规范是否一致”
MCP Server 不等于 Function Calling
- Function Calling 更偏单次工具调用机制
- MCP Server 更偏把 Postman 的 API 资产按协议暴露给 agent