MCP 能力开放机制
一、为什么 Agent 不能直接连到底层数据
如果让 Agent 直接面向底层表、接口或任意 SQL，自由度虽然更高，但在制造场景里通常会引入三个问题：
- 业务口径容易漂移
- 调用边界难以控制
- 返回结果难以标准化组合
因此，产线军师不把底层数据结构直接暴露给 Agent，而是通过 MCP 把分析、诊断、检索和协同能力组织成标准化能力层。
二、什么是产线军师语境下的 MCP
在产线军师中，MCP 不只是协议层概念，更是 能力开放层。
它承担的是“把系统已有能力转换为 Agent 可调用能力”的职责，包括：
| 能力类型 | 典型能力 |
|---|---|
| 业务分析能力 | 产量、质量、节拍、故障、OEE、SPC 等分析 |
| 主数据与语义辅助能力 | 对象查找、时间解析、维度补全、口径澄清 |
| 知识能力 | 文档检索、案例检索、证据补充 |
| 协同与动作能力 | 报告生成、通知、跳转、受控业务动作 |
三、MCP 解决的不是“能调接口”，而是“如何受控地调能力”
对 Agent 来说，MCP 的关键价值不是把接口包装得更漂亮，而是让调用具有以下特征：
| 特征 | 说明 |
|---|---|
| 能力边界清晰 | 每个能力解决的问题边界明确 |
| 输入语义稳定 | 参数围绕对象、时间、维度、范围等业务语义组织 |
| 输出结构化 | 返回结果可被继续组合、解释和展示 |
| 权限与策略可控 | 可按部署模式、角色、租户和场景约束可用能力 |
| 调用可追踪 | 能记录用了什么能力、结果来自 哪里 |
四、产线军师中常见的能力调用链路
这条链路说明了一个核心原则：Agent 先理解问题，再调用能力，而不是先生成答案再找依据。
五、为什么产线军师强调“业务语义能力”
产线军师的能力开放不是让模型自由拼接底层查询，而是优先使用面向场景的业务语义能力，例如：
- 查询某条线、某工序、某设备的产量
- 分析某时段的质量趋势和缺陷分布
- 判断哪类故障对停机影响最大
- 在口径不清时先澄清整线、工序还是设备
这种方式有两个直接好处：
- 结果更容易保持一致
- 调用行为更容易被约束、审计和解释
六、MCP 与工具调用机制的关系
两者相关，但不完全相同：
| 概念 | 关注点 |
|---|---|
| MCP 能力开放机制 | 系统如何把能力组织成可调用目录 |
| 工具调用机制 | Agent 在一次具体任务中如何选择并执行这些能力 |
简单理解：
MCP回答“系统开放了哪些能力、这些能力如何被规范提供”工具调用机制回答“Agent 在当前问题里怎么选、怎么调、怎么组织结果”
七、MCP 为什么比“模型直连数据”更适合制造场景
1. 更容易保持口径一致
当产量、良率、OEE、节拍等能力已经作为标准能力开放时，模型不需要每次重新猜测统计方式。
2. 更容易约束可用场景
不同部署模式、不同客户边界下，系统可以只开放允许的能力范围，而不是给模型无差别访问权限。
3. 更容 易形成长期演进
新增分析能力时，可以直接扩展能力目录，而不必重新设计所有对话逻辑。
八、对业务的实际意义
从使用者视角看，MCP 带来的不是“多一个中间层”，而是三种更可感知的稳定性：
- 问题更容易落到正确的分析能力上
- 结果更容易保持结构化、可复核和可组合
- 后续新增场景时，系统更容易扩展而不失控
这也是产线军师能够把 ChatBI、诊断分析和后续协同动作连接成同一条链路的重要基础。