实战后台 MCP 04：本地调试、部署和灰度给运营团队

AI / MCP / 实战系列
MCP部署灰度发布运营后台

先理解：部署不是把服务跑起来就完事 ​

MCP Server 进入团队使用后，真正要关注的是稳定性、权限配置、调用日志、运营反馈和灰度策略。本篇把本地调试、部署说明、灰度指标整理成上线手册。

为什么要灰度给运营团队 ​

运营后台动作和真实业务强相关。先给少量可信用户使用，观察工具调用是否符合预期、权限是否够用、AI 是否误解工具含义，再逐步扩大范围。

成品标准 ​

一个可用的后台 MCP Server 至少应该具备：清晰 Tools、必要 Resources、角色权限、审计日志、高风险二次确认、README、回滚方案。少一个都不建议开放给真实业务。

本篇把 MCP Server 从开发样例变成可灰度试用的内部工具。

环境变量 ​

.env.example：

env
ADMIN_USER_ID=local-dev
ADMIN_ROLE=readonly
AUDIT_LOG_PATH=logs/audit.jsonl

不要把真实后台 token 写进代码。生产环境应从密钥管理系统读取。

本地启动 ​

bash
npm install
ADMIN_USER_ID=dev_001 ADMIN_ROLE=operator npm run dev

本地调试目标：

  • MCP Client 能发现 Tools。
  • get_order 正常返回。
  • update_order_note 对 readonly 报权限错误。
  • 高风险退款只生成确认请求。
  • logs/audit.jsonl 有审计记录。

README 内容 ​

README.md 应包含：

md
# Admin MCP

## Tools

- get_order：只读查询订单
- export_daily_report：只读导出日报
- update_order_note：低风险写入
- prepare_refund_request：生成退款确认请求，不直接退款

## Roles

- readonly：只读
- operator：只读 + 低风险写入
- admin：预留管理员能力

灰度检查表 ​

checklist/rollout.md：

md
# 灰度上线检查

- [ ] 所有 Tool 有权限检查
- [ ] 所有 Tool 有审计日志
- [ ] 高风险动作不直接执行
- [ ] readonly 用户无法写入
- [ ] operator 用户只能低风险写入
- [ ] 运营团队完成 1 小时试用培训
- [ ] 每天检查 audit 日志

灰度指标 ​

每天检查：

  • Tool 调用次数。
  • 权限拒绝次数。
  • 高风险确认请求次数。
  • Tool 错误率。
  • 运营反馈问题数。

成品标准 ​

  • 能被 MCP Client 连接。
  • Tools 和 Resources 能被发现。
  • 只读和写入权限分级明确。
  • 高风险动作需要人工确认。
  • 审计日志可追溯。
  • 有灰度检查清单。

到这里，AI 接入后台系统不再是直接暴露 API，而是封装成可治理、可审计、可回滚的 MCP 接口。

实战后台 MCP 03：审计日志和高风险二次确认