从 0 到 22 篇：工业 Agent 的六项设计原则
系统全貌首先呈现技术栈构成：Java 21、Spring Boot 3.3、LangChain4j 0.35、DeepSeek、TDEngine、Milvus、EMQX、H2。这六条原则源于实践，指导构建高效工业AI Agent。
系统全貌
原则 1：Tool 是真正的产品
多数 AI Agent 项目以选择模型为起点，而工业 Agent 则优先思考 Tool 的设计。
模型会迭代，但 Tool 的接口设计、数据质量、错误处理才是系统长期价值的载体。 笔者更换过两次底层模型，但 Tool 代码未作任何修改。
Tool 设计遵循三条准则：
| 准则 | 反例 | 正例 |
|---|---|---|
| Tool 做数据处理，LLM 做推理 | queryRaw() 返回 100 行原始数据 | queryDeviceHistory() 返回 avg/max + latest |
| Tool 带领域知识 | 让 LLM 判断「振动 4.8 正常吗」 | Tool 标注 vibrationStatus: "CRITICAL" |
| Tool 描述 = 契约 | @Tool("查询数据") | @Tool("查询过去1小时的统计摘要和最新数据点") |
相关文章：03、04、21
原则 2：数据进入 Agent 前先「瘦身」
工业设备每秒产生大量数据点，直接喂给 LLM 会导致灾难性结果。
原始数据 100 行 ≈ 2000 token → LLM 看不清趋势
聚合统计 + 最新值 ≈ 200 token → LLM 准确判断
压缩比 10:1，判断准确率反而提升。 LLM 不适合处理逐行数字，但对异常比例和变化趋势极为敏感。
实现方式：
- TDEngine 超级表 + SQL 窗口函数完成预聚合
- DeviceDataTool 只返回三个字段：latest / stats / alarms
- 正常范围标注（
normalRange,status）写在 Tool 代码里
相关文章：19、21
原则 3：CoT 不是锦上添花，是必需品
缺少 CoT 时 Agent 的表现：
- 同时查告警 + 查数据 + 检索知识，但结论跳跃
- 数据不足时编造数值（例如「振动大概 4.5」）
- 无论设备是否有故障，每次都创建工单
引入 CoT 后：
@SystemMessage("""
思考路径：
1. 数据采集：queryDeviceAlarms + queryDeviceHistory
2. 知识检索：searchKnowledgeBase（如有异常）
3. 诊断分析：generateDiagnosis
4. 工单决策：仅在确认硬件故障时调用 createWorkOrder
5. 最终输出：状态 → 异常 → 诊断 → 建议 → 工单
""")
CoT 的价值不在于让 LLM 更聪明，而在于使推理过程可追溯、可调试、可修正。 工业场景中，不知道判断依据比判断错误更危险。
相关文章：21
原则 4：约束比能力更重要
最初 CoT 只写了「1→2→3→4→5」步骤，未加约束。LLM 每次都创建工单——无论有无故障。
加入一句话后行为收敛：
这条规则没有一行代码——仅是提示词中的一句中文。但它比任何 if (alarmCount > 0) 更灵活，因为 LLM 能理解「正常」的语义边界。
在工业 Agent 中，告诉 LLM 不做什么，比告诉它做什么更有效。 三条必加的约束：
- 数据不足时，输出「无法判断」而不是编造
- 无告警不创建工单
- 涉及停机操作时，标注「需人工确认」
相关文章：07、21
原则 5：持久化是闭环的终点
第一版 WorkOrderTool 用 ConcurrentHashMap 存储工单，存在三个缺陷：
- 重启丢失
- 无法查历史
- 无状态流转
改为 H2 + JdbcTemplate 后：
工单生命周期：PENDING → IN_PROGRESS → COMPLETED
↓ ↓
CANCELLED CLOSED
| 版本 | 存储 | 重启后 | 历史查询 | 状态流转 |
|---|---|---|---|---|
| V1 | ConcurrentHashMap | 丢失 | ||
| V2 | H2 (JdbcTemplate) | 保留 |
Agent 的交付物不是正确回答，而是产出可追溯的交付物。 诊断是对白，工单是交付成果。
相关文章：22
原则 6：RAG 填补 LLM 的工业盲区
通用 LLM 无法区分「轴承温度高」和「齿轮箱温度高」的差异。工业知识库恰好弥补这一短板。
用户：「轴承温度过高」
→ Embedding 检索 → 轴承温度过高 → 润滑油劣化/轴承磨损/负载过大
→ BM25 检索 → "轴承" 精确命中维修手册
→ RRF 融合 → Top-3 最相关维修方案
→ LLM 推理 → 结合实时数据给出根因
关键决策：
- Embedding 模型选型：
AllMiniLmL6V2384 维，ONNX 本地运行，无需 API - 混合检索：Dense + BM25 → RRF 融合，比纯向量检索命中率提高 20%+
- 分块实验：500 chars 平衡了上下文完整性和检索精度
相关文章：12、13、14、15、16、17、18
六条原则总结
| # | 原则 | 一句话 | 关键实现 |
|---|---|---|---|
| 1 | Tool 是产品 | 模型会换代，Tool 是长期资产 | @Tool 设计准则 |
| 2 | 数据瘦身 | 压缩 10:1，判断更准 | TDEngine 预聚合 |
| 3 | CoT 必需 | 可追溯比「猜对」重要 | ReAct 提示词 |
| 4 | 约束 > 能力 | 告诉 LLM 不做什么 | 负面约束句 |
| 5 | 持久化闭环 | Agent 交付物要留下来 | H2 + 状态流转 |
| 6 | RAG 补盲区 | LLM 不懂工业，知识库补 | Milvus + 混合检索 |
下一步
本文六条原则从 Tool 设计到 RAG 补盲区，完整构建了工业 Agent 的可靠性闭环。Phase 2 的完结标志着 MVP 达成，Phase 3 将迈向多 Agent 协作与自主推理链的进阶模式。