企业建设 MCP，不要一开始铺满系统：从一个真实场景开始做 Agent POC

企业第一次做 MCP，常见冲动是先盘点所有系统，再把能找到的接口都接进来。结果往往是工具目录越来越长，业务人员却说不清哪个场景真正有用。

MCP建设更适合从业务任务开始。先找一个高频、边界清楚、能看到结果的场景，再决定要接哪些知识、系统和工具。

一、先选任务，不要先选技术

适合作为 POC 的任务，通常具备几个特点：业务人员经常做，步骤相对清楚，涉及的系统不宜过多，结果可以被观察和比较。

例如，销售客户拜访准备、合同与回款查询、供应商资质风险查询、工单创建、费用异常分析、入职待办汇总，都可以作为候选场景。

这些场景的共同点是，员工现在已经在做，只是需要跨系统查询、重复整理或手工录入。Agent是否有价值，可以直接拿现有做法来比较。

二、把任务拆成知识、数据和动作

确定场景后，可以画出任务链路：员工提出什么目标，Agent需要查哪些知识，访问哪些系统，调用哪些工具，哪些步骤需要人工确认，最后交付什么结果。

以“查询合同和回款并生成跟进建议”为例，可能需要知识库提供跟进规范，CRM提供客户和商机数据，合同系统提供合同信息，财务系统提供回款状态，最后由员工确认是否把跟进记录写回 CRM。

拆清楚之后，MCP要接的工具就不会凭感觉增加。

三、POC先验证四件事

第一，数据能不能取到。系统接口、字段口径和权限范围要满足任务需要。

第二，Agent能不能正确理解任务。它是否能选择合适工具，处理缺失信息和异常情况。

第三，动作能不能安全执行。草稿、确认、提交和审批边界是否清楚。

第四，结果能不能被业务使用。员工是否愿意采用，结果是否有依据，过程是否能追溯。

调用次数和聊天轮数可以作为辅助指标，但不宜直接当作业务价值。企业更关心的是任务完成质量、处理时间、错误情况和持续使用。

四、从验证到试点，治理要提前放进去

POC阶段就应保留用户身份、工具权限、人工确认和调用记录。等场景做大了再补治理，往往需要重新设计工具和流程。

得小帆的落地路径包括场景梳理、知识与系统准备、POC验证、试点推广和平台化运营。企业可以先选择 1—2 个真实场景，验证技术可行性和业务效果，再扩大用户范围和工具范围。

如果一个场景经常失败，不一定是模型不行，也可能是数据对象没有统一、接口返回不清楚、权限没有设计好，或者业务流程本身还没有理顺。

五、平台化不是把工具越堆越多

当多个场景开始复用同一批客户、供应商、物料、订单和消息能力时，企业才会感受到标准化工具的价值。

这时可以把高频工具纳入统一注册和版本管理，建立服务目录，观察使用和失败情况，再逐步沉淀为企业 AI 资产。

平台化的重点，是让能力可以复用、权限可以管理、调用可以审计、问题可以定位。工具数量本身不是目标。

写在最后

MCP的建设起点，应该是业务人员每天正在做的一项工作。先把任务链路讲清楚，再决定接哪些系统和工具；先让一个场景稳定运行，再讨论更大范围的复用。

企业 AI 最后要进入价值链，靠的不是一次接入多少接口，而是能否把真实工作交付给员工，且过程有边界、结果可检查、运行能持续。