三层技术架构
一、为什么需要用“三层”来理解 Agent
在早期理解里，很多人会把 Agent 想成“一个大模型 + 一套提示词 + 一组工具”。这种理解对演示型系统足够，但对制造场景的长期落地并不够。
原因很简单：
- 制造问题不是单句问答，而是多轮连续分析
- 分析结果不能只靠生成，还要建立在真实能力和真实数据之上
- 同一轮里不仅要决定“说什么”，还要决定“看什么”“能做什么”
因此，当前产线军师更适合按三层技术架构来理解。
二、三层分别是什么
| 层 | 核心问题 | 在产线军师中的作用 |
|---|---|---|
| Harness Engineering | Agent 跑在什么样的执行世界里 | 负责会话、工具、状态、事件流、权限与运行时治理 |
| Context Engineering | 本轮到底能看到什么 | 负责历史、记忆、知识、时间范围、工具边界和预算控制 |
| Prompt Engineering | 本轮该怎么说、怎么收敛 | 负责角色、规则、模式切换、输出契约与子代理约束 |
可以把它简单理解为：
- Harness 负责“造世界”
- Context 负责“看什么”
- Prompt 负责“说什么”
三、为什么不能只靠 Prompt
如果只靠 Prompt，希望模型自己理解全部上下文、自己判断工具边界、自己管理多轮状态，通常会遇到几个问题：
- 历史越来越长，模型看到的信息反而越来越乱
- 工具能不能调、该不该调、调完如何收敛，难以稳定控制
- 一个 prompt 很难同时承担角色、流程、边界、治理、会话状态等全部职责
- 一旦场景增多，系统会越来越依赖“临场发挥”
这也是为什么产线军师现在不再把 Agent 简单理解为“Prompt First”，而是更强调“Runtime + Context + Prompt”的协同。
四、三层如何协同
更具体地说：
- Harness 先准备好真实执行环境，包括会话、工具、权限、状态与事件机制。
- Context 决定本轮到底带哪些历史、记忆、知识、术语和时间范围进入分析。
- Prompt 再把这些输入组织成模型可执行的角色约束、输出方式和边界规则。
三层不是串行替代关系，而是共同组成一次完整的 Agent 执行。
五、三层分别带来什么产品价值
| 层 | 对产品的直接价值 |
|---|---|
| Harness | 让 Agent 不只是“会回答”，而是真正能连接业务能力、执行调用、输出结构化结果 |
| Context | 让 Agent 不只是“记得多”，而是能把最相关的信息带进本轮分析 |
| Prompt | 让 Agent 不只是“说得像”，而是能在不同模式下保持稳定表达和边界收敛 |
六、三层和其他机制是什么关系
三层架构并不是替代 UNS、MCP、Skill、记忆或知识闭环，而是把这些机制重新放回更清晰的技术位置：
- UNS、MCP、工具 更偏 Harness 层的能力基础
- 场景路由、上下文工程、记忆 更偏 Context 层的裁决与编排
- 提示词工程、子代理约束、输出契约 更偏 Prompt 层的表达与治理
也正因为有了这种拆分，系统才能在场景增多时仍然保持可扩展和可治理。
七、对业务和实施的意义
从业务和实施角度看，三层技术架构的意义在于：
- 更容易解释为什么系统既能对话、又能分析、还能继续追问
- 更容易解释为什么系统不是简单把聊天历史和工具列表塞给模型
- 更容易把能力建设拆成语义、能力、上下文、提示和治理几个明确工作面