Claude 接入 MCP 之后,问题不只是"能不能连工具"。更实际的问题是:哪些场景适合让 Claude 参与,哪些步骤应该交给工具层、权限层,或者干脆交给轻模型。
一个简化链路是:
text
用户请求 -> AI 应用 -> MCP client -> MCP server -> 外部工具 -> Claude 理解和生成
MCP 不会让模型凭空变强。它解决的是工具接入问题。工具负责拿数据,Claude 负责理解、判断和组织结果。
代码仓库和 issue 分析
Claude 适合处理长代码、长 issue、PR 讨论和技术文档。接入 GitHub 相关 MCP server 后,它可以少猜一点,多看一点仓库里的真实上下文。
典型链路大概是这样:
- 用户描述 bug 或需求
- Agent 查询 issue、PR、代码文件
- Claude 读取上下文并判断问题位置
- 人工确认后再进入修改或评论
分工可以简单一点:Claude Sonnet 处理日常代码理解和 issue 梳理,Claude Opus 放在复杂架构判断和高风险代码评审里。
企业知识库问答
知识库问答最怕两件事:没查到资料却硬答,查到旧资料还当成最新结论。
更稳的链路是:
text
问题分类 -> 权限判断 -> 文档检索 -> Claude 阅读上下文 -> 生成答案
这里权限不能只写在 prompt 里。哪些部门能看哪些文档、哪些字段要脱敏,最好在 MCP server 或业务服务层处理。
Claude 也不应该替代检索系统。它更适合读检索结果、发现冲突,然后把答案组织清楚。
数据库和业务系统查询
很多企业 AI 助手最后都会卡在业务系统上。
比如销售问:"这个客户最近三个月续费风险怎么样?"如果模型不能访问 CRM、订单、工单和沟通记录,它只能写一段通用话术。
接入 MCP 后,查询动作可以交给受控工具,Claude 再综合结果,判断风险点和下一步动作。
这类场景要先管住几件事:
- 只读优先,写操作必须单独授权
- 字段脱敏,避免敏感数据直接暴露给模型
- 调用日志要能追溯工具参数、模型版本和最终输出
落地建议
企业不要把 MCP、模型和业务逻辑写成一团。拆开会好维护很多:
text
工具层:MCP servers、内部 API、数据库、文档系统
模型层:Claude、GPT、Gemini、轻量模型
治理层:鉴权、路由、计费、日志、fallback、限流
147AI 适合放在模型接入和治理入口,统一接入 GPT、Claude、Gemini 等模型,把接口兼容、人民币结算、专线优化、按量计费和成本控制放到一层处理。
从工程实现看,它承担的是模型侧的抽象层。业务代码尽量只面对统一接口,具体用哪个模型、要不要切备用模型、不同团队怎么统计用量,都可以放到接入层处理。
这样 MCP server 负责工具标准化,模型调用通过统一入口管理。后面替换某个模型时,业务系统不用跟着大改一轮。
检查清单
引入 Claude + MCP 前,至少先确认这些事:
- 哪些工具只读,哪些可能写入?
- 哪些结果需要脱敏?
- 哪些步骤必须人工确认?
- 哪些任务必须用 Claude,哪些可以用轻模型?
- 工具调用失败时,是重试、换工具,还是转人工?