Agent 架构
一、总体架构思路
产线军师的 Agent 架构采用“统一入口 + 分层编排 + 专业能力协同 + 治理约束”的方式，目标不是做一个无边界的万能对话体，而是让用户通过同一个入口获得稳定、可验证、可扩展的制造分析能力。
二、单入口不等于单一 Agent
对用户来说，产线军师可以表现为一个统一的 Agent 入口；但在系统内部，它更适合被理解为一套围绕场景自动路由和协同编排的能力体系。
这意味着同一个会话入口背后， 可能会根据问题类型自动组织不同角色的能力，例如：
- 指标与经营分析能力
- 质量与异常诊断能力
- 故障与设备分析能力
- 知识检索与经验增强能力
- 结果整合与表达能力
这种设计的价值在于，系统不需要让一个单体 Agent 同时承担所有职责，而是让更合适的能力在更合适的场景中参与执行。
三、核心层次
| 层次 | 作用 | 对用户的价值 |
|---|---|---|
| 交互层 | 接收问题、维护会话上下文、多轮追问 | 让用户可以像对话一样持续分析 |
| 路由与编排层 | 识别意图、拆解任务、决定执行路径 | 把复杂问题转换为清晰步骤 |
| 能力模块层 | 为不同角色和场景注入领域方法、规则和使用方式 | 让结果更贴近角色目标与业务场景 |
| 场景能力层 | 组织指标、质量、故障、节拍等专业能力 | 让分析更贴近真实业务语义 |
| 记忆层 | 延续会话上下文、长期偏好和任务中间状态 | 让多轮分析 更连续、减少重复澄清 |
| 工具执行层 | 调用具体业务工具与结构化能力接口 | 确保结果建立在可执行能力之上 |
| 知识增强层 | 引入术语、规则、案例、复盘经验 | 提升解释力和复用能力 |
| 治理层 | 控制权限边界、调用规则和结果可信度 | 让系统更稳定、更可控 |
四、从当前演进看，更适合按“三层协同”理解 Agent
如果进一步往运行时内部看，当前产线军师 Agent 已经不适合再被理解为“一个 Prompt 驱动一切”的系统，而更适合按三层来理解：
| 层 | 关注点 | 作用 |
|---|---|---|
| Harness Engineering | 运行时、工具、会话、事件流、状态与治理 | 决定 Agent 跑在什么样的执行世界里 |
| Context Engineering | 历史、记忆、知识、时间、工具边界与预算控制 | 决定本轮到底能看到什么 |
| Prompt Engineering | 角色、规则、模式切换、技能目录、输出契约 | 决定本轮该怎么说、怎么收敛 |
可以把它简单理解为：
- Harness 负责“造世界”
- Context 负责“看什么”
- Prompt 负责“说什么”
更完整的说明可继续阅读 三层技术架构、上下文工程 和 提示词工程。
五、Agent 架构中的关键关系
如果用三层视角重看这张图：
- Harness 保障会话、工具、状态与执行环境真实存在
- Context 决定会话上下文、记忆与知识如何进入本轮分析
- Prompt 负责把这些输入组织成模型可执行的行为约束
六、典型协同方式
在一个典型的复杂问题中，产线军师的 Agent 架构通常会表现出以下协同方式：
- 先判断问题属于查询、对比、诊断还是建议场景
- 再识别应调用哪些专业能力
- 结合上下文、记忆与知识补充必要依据
- 最后把结构化结果组织成用户可读、可追问的输出
这种协同方式既支持单步问答，也支持多步链式分析。
七、为什么采用分层与协同架构
1. 便于扩展场景
新增分析主题时，不需要重写整套交互逻辑，而是扩展新的能力模块、场景能力和知识资产。
2. 便于控制边界
把交互、路由、上下文、工具、知识和治理拆开之后，系统更容易控制哪些能力可调用、哪些问题需要澄清、哪些结果需要收敛。
3. 便于持续演进
业务案例、语义规则、提示资产和诊断流程可以逐步沉淀，不必和底层执行逻辑混杂在一起。
八、Agent 架构的产品意义
从产品视角看，这种架构让产线军师同时具备四个特征：
- 统一交互体验：用户只需要围绕问题发起对话
- 专业能力协同：系统能自动组织更合适的分析能力
- 上下文连续与结果收敛：系统不只会算，还能接住追问并控制边界
- 可治理、可扩展：随着场景增加，仍能保持稳定性和可信度