技术总览
一、本专题关注什么
本专题用于说明 产线军师 Agent 为什么能在制造场景中稳定工作。
本专题重点回答技术原理问题：
- Agent 为什么不能脱离工厂语义独立工作
- 自然语言问题如何进入可控的能力调用链路
- 为什么 Agent 既需要记忆，也需要知识闭环
- 为什么现在不能再把 Agent 简化理解为“一个大 Prompt + 一组工具”
二、产线军师 Agent 的三条技术主线
随着当前架构演进，产线军师的 Agent 更适合按三条主线来理解：
| 主线 | 关注点 | 解决的问题 |
|---|---|---|
| 语义与能力主线 | UNS、MCP、工具与 Skill | 让系统先“看懂工厂”，再“调得对能力” |
| 执行与上下文主线 | Agent 架构、场景路由、上下文工程、记忆 | 让系统知道这轮该怎么走、该看什么、该延续什么 |
| 表达与治理主线 | 提示词工程、知识闭环、安全与可信 | 让系统知道该怎么说、如何给依据、如何守边界 |
如果换一种更贴近运行时的说法，当前产线军师 Agent 由以下关键机制共同构成：
| 机制 | 作用 |
|---|---|
| UNS 统一语义底座 | 统一对象、状态、关系、时间和业务口径，让系统先“看懂工厂” |
| MCP 能力开放机制 | 把查询、分析、诊断、检索和协同能力封装成可调用能力 |
| Agent 架构与编排 | 根据问题、上下文和边界组织执行顺序 |
| 三层技术架构 | 从 Harness、Context、Prompt 三个层面解释 Agent 如何真正运行 |
| 场景路由与意图解析 | 把自然语言问题转换为更适合执行的场景入口 |
| 能力模块（Skill） | 为不同角色和场景注入领域知识、方法和使用规则 |
| 工具调用机制 | 让结果建立在可执行、可约束、可追溯的业务能力之上 |
| 分析剧本（Playbook） | 为高频、关键或高风险流程提供更确定的执行路径 |
| 上下文工程 | 决定本轮到底看哪些历史、记忆、知识、时间与工具边界 |
| 提示词工程 | 决定运行时提示资产如何被装配、约束和治理 |
| 记忆机制 | 维持会话连续性、长期偏好和任务中间状态 |
| 知识闭环与治理 | 沉淀案例、规则和经验，并以可检索、可审核、可追溯方式复用 |
| 安全与可信机制 | 控制权限、调用边界和结果可信度 |
三、整体关系图
这套结构强调的是：
- 先在语义和边界内理解问题
- 再决定本轮该看哪些上下文、该用哪些能力
- 必要时结合记忆和知识补全依据
- 最后把结构化结果组织成用户可执行的输出
四、为什么这些机制必须同时存在
如果只用通用模型而缺少其中某一层，系统通常会出现明显短板：
| 缺少的层 | 直接问题 |
|---|---|
| 缺少 UNS | 对象、时间、层级和指标口径容易理解偏差 |
| 缺少 MCP / 工具层 | 容易退化为“会说不会算”的问答系统 |
| 缺少场景路由 | 所有问题都走同一条链路，执行稳定性下降 |
| 缺少上下文工程 | 要么信息不足，要么大量无关历史被塞给模型 |
| 缺少提示词工程 | 角色、边界、模式切换和子代理约束难以治理 |
| 缺少记忆 | 多轮对话容易断裂，重复澄清成本高 |
| 缺少知识闭环 | 经验无法沉淀，类似问题每次都要从零分析 |
| 缺少安全治理 | 调用边界、结果可信度和权限约束难以控制 |