协同原理
一、为什么 Agent 不能脱离语义和能力层独立存在
在工业场景中，Agent 是否可靠，不取决于“会不会对话”这一点，而取决于它是否建立在清晰的语义基础和可控的能力边界之上。
对产线军师来说：
UNS负责让工厂对象、状态和关系可被一致理解MCP负责让分析、诊断和协同能力可被规范调用Agent负责把用户问题转化为有顺序、有约束的业务执行链路
这三层缺少任意一层，Agent 都容易退化为纯问答工具、孤立接口调度器，或缺少业务闭环的分析助手。
二、产线军师的五层协同架构
| 层次 | 作用 | 典型内容 |
|---|---|---|
| 连接层 | 接入现场与业务系统数据 | CMS、LMES、MES、设备、数据库、事件流 |
| UNS 语义层 | 建立统一对象模型、状态语义和关系上下文 | 订单、产线、工位、设备、工艺、质量、报警、人员、项目 |
| MCP 能力层 | 把分析与动作封装为 AI 可调用能力 | 查询、统计、诊断、检索、通知、协同、业务动作 |
| Agent 编排层 | 根据意图、上下文和边界组织多步执行 | 任务拆解、工具选择、知识增强、结果汇总 |
| 交互层 | 承载用户输入与结果呈现 | 对话工作台、图表、报告、角色工作界面 |
三、从问题到动作的协同链路
这条链路的关键不在于“多了一次调用”，而在于每一步都有明确职责：
- 语义层保证对象和口径被正确理解
- 能力层保证调用范围和返回结果可控
- 编排层保证复杂问题能够被拆解和组织
- 知识层保证解释更接近业务现场
四、为什么产线军师更适合采用角色化 Agent
制造现场的工作目标并不单一。生产运营、设备维护、质量追踪、项目交付和管理驾驶舱关注的对象、指标和动作都不同，因此产线军师更适合采用角色化 Agent，而不是单一的“万能 Agent”。
| Agent 角色 | 关注重点 | 更常调用的能力 |
|---|---|---|
| 生产运营 Agent | 产量、节拍、在制、瓶颈、计划达成 | 产能分析、节拍分析、计划目标、工序拆解 |
| 设备维护 Agent | 停机、故障、报警、寿命与保养 | 故障分析、设备状态、易损件、报警追溯 |
| 质量追踪 Agent | 良率、缺陷、工序波动、SPC | 质量分析、缺陷分布、过程参数、SPC |
| 项目交付 Agent | 实施节点、异常协调、验收风险 | 项目状态、问题跟踪、协同提醒、知识检索 |
| 管理驾驶舱 Agent | 经营概览、跨区域对比、关键风险 | 汇总分析、趋势对比、报告生成、指标钻取 |
这种方式的价值在于：
- 每类 Agent 都围绕明确业务目标组织能力
- 不同角色共享同一套语义底座和能力开放层
- 新场景扩展时，更容易新增角色或补充能力，而不必重做整套交互逻辑
五、为什么这种协同比直接“模型连数据”更稳妥
直接把模型连接到底层数据或接口，虽然看起来路径更短，但在工业场景里往往会带来三类问题：
- 业务对象和指标口径容易被误解
- 调用范围和执行边界难以稳定控制
- 结果很难沉淀为可复用的组织经验
产线军师通过 UNS + MCP + Agent 的协同方式，把“理解工厂”“调用能力”“推动闭环”拆成相互配合的层次，因此更适合长期演进和规模化落地。
六、与本专题其他页面的关系
本页解释的是 为什么产线军师要把语义层、能 力层和 Agent 编排放在同一套体系中。
如果需要继续展开，可以结合以下页面阅读：