工业AI Agent六大核心设计原则：从理论到Java/Spring Boot实战

1. 项目概述：工业Agent的实战价值与挑战

最近和几个在制造业、能源行业做数字化转型的朋友聊天，大家不约而同地提到了一个词：Agent。不是电影里的特工，而是AI智能体。尤其是在工业场景下，从预测性维护到能耗优化，从质检排产到供应链协同，似乎不提Agent就落伍了。但真正动手去做的团队，十个里有八个会卡在从“Demo玩具”到“生产级应用”的鸿沟上。我自己也经历了这个过程，从最初一个简单的设备异常检测脚本，到最终构建起一套包含22个不同功能Agent的微服务集群，踩过的坑、绕过的路，足够写一本避坑指南。

这个“从0到22篇”的过程，本质上是一套方法论和设计原则的沉淀。它不是什么高深的理论，而是用Java和Spring Boot这样的“传统”技术栈，结合LangChain4j这类新兴AI框架，在TDEngine这样的时序数据库基础上，把AI能力真正“焊”进工业业务流程里的实战总结。今天要聊的，就是支撑这22个Agent稳定运行的六大核心设计原则。如果你正苦恼于Agent的幻觉问题、响应延迟、或是难以融入现有系统，那么接下来的内容，或许能给你一些直接的参考。

2. 工业Agent的六大核心设计原则拆解

工业场景和互联网场景对Agent的要求有本质不同。互联网应用可以容忍一定的错误率和延迟，但工业现场的一个误判可能导致生产线停机、设备损坏，甚至安全事故。因此，工业Agent的设计必须遵循一套更严谨、更务实的原则。

2.1 原则一：确定性与边界控制优先

这是工业Agent设计的铁律。AI，尤其是大语言模型（LLM），天生具有不确定性（幻觉）。而工业控制要求的是可预测、可解释的确定输出。

核心思路：不是让LLM天马行空地“思考”，而是为它构建一个高度结构化的“决策框架”。Agent的职责是理解意图、调用工具、组织结果，而非创造知识。

实操要点：

1. 工具化一切：将所有对外的操作（查询数据库、调用API、发送指令）都封装成明确的“工具”（Tool）。在LangChain4j中，这意味着为每个操作定义一个清晰的函数接口，包括输入参数、输出格式和可能的异常。例如，查询TDEngine中某设备最近一小时的温度趋势，就是一个独立的工具。
2. 严格的输入输出Schema：使用强类型（如Java Record或POJO）定义工具的参数和返回结果。这不仅能利用编译器的类型检查提前发现错误，还能为LLM提供清晰的结构化示例，极大降低其“胡言乱语”的概率。
3. 流程编排而非自由发挥：通过设计好的“执行链”（Chain）来约束Agent的行为顺序。比如，一个故障诊断Agent的链可能是：解析用户问题 -> 查询设备实时状态(TDEngine) -> 检索历史工单(业务数据库) -> 调用诊断规则引擎 -> 生成格式化报告。每个环节都是确定的工具调用。

注意：切忌让LLM直接生成SQL或API调用字符串。必须通过工具调用，由工具内部进行参数校验、SQL拼接和安全过滤，防止SQL注入或非法操作。

2.2 原则二：状态持久化与上下文管理

工业流程往往是长周期、多步骤的。一个维修Agent可能需要和工程师对话多轮，才能定位问题。这就要求Agent必须能记住之前的对话和操作历史。

技术实现：

1. 对话状态存储：每个对话会话（Session）需要一个唯一ID。将会话中所有的消息（HumanMessage, AIMessage, ToolExecutionMessage）序列化后存储到Redis或关系型数据库中。LangChain4j提供了ChatMemoryStore接口，可以方便地对接各种存储。
2. 关键信息摘要：工业对话可能很长，不能把所有历史都塞进LLM的上下文窗口。需要在每轮对话后，由Agent自动生成一个“会话摘要”，提炼关键决策、设备状态和待办事项。下一轮对话时，将摘要和最近几条消息作为上下文传入。
3. 业务上下文注入：除了对话历史，启动Agent时，还应自动注入相关的业务上下文。例如，当工程师与“泵机P-101维修助手”对话时，Agent后台应自动加载该泵机的设备档案、近期运行参数（从TDEngine获取）、维修记录等，并作为系统提示词的一部分。

// 示例：使用Redis存储对话记忆 ChatMemoryStore memoryStore = new RedisChatMemoryStore(redisConnectionFactory); ChatMemoryProvider memoryProvider = (sessionId) -> MessageWindowChatMemory.builder() .id(sessionId) .maxMessages(20) // 保留最近20条原始消息 .chatMemoryStore(memoryStore) .build(); // 创建Agent时注入记忆 Agent agent = AiServices.builder(MyAgent.class) .chatLanguageModel(chatModel) .chatMemoryProvider(memoryProvider) .tools(tools) .build();

常见问题：直接使用LangChain4j的默认内存（如MessageWindowChatMemory）在服务重启后状态会丢失。必须配置持久化的ChatMemoryStore。

2.3 原则三：实时数据接入与时序数据处理

工业Agent的“眼睛”和“耳朵”是实时数据。TDEngine作为高性能时序数据库，是处理海量设备测点数据的绝佳选择。与Agent的集成关键在于高效、低延迟的数据查询。

架构设计：

1. 数据桥梁工具：创建一个专门的TDEngineQueryTool。这个工具内部封装TDEngine的JDBC或RESTful连接，提供几个高度优化的查询方法：
   • getCurrentMetric(deviceId, metricName): 查询设备某个指标的最新值。
   • getMetricHistory(deviceId, metricName, startTime, endTime, interval): 查询历史时序数据，支持降采样。
   • detectAnomaly(deviceId, metricName, algorithm): 封装简单的异常检测算法（如3-sigma），返回布尔值或置信度。
2. 查询优化：TDEngine针对时序查询有诸多优化。例如，对超级表（Super Table）进行查询时，一定要利用好标签（TAGS）进行过滤，避免全表扫描。在工具内部，生成的SQL应类似：

   SELECT last(current) FROM meters WHERE ts >= now - 1h AND device_id = ‘P-101’ INTERVAL(1m);

3. 数据格式化：LLM不擅长处理原始的数字序列。工具在返回数据前，应将其格式化为更易读的形式，如：“过去一小时内，电机温度从65°C缓慢上升至72°C，在10:25达到峰值75°C，目前稳定在71°C。” 可以结合简单的图表生成（如输出ASCII趋势图或生成图片URL）供前端展示。

避坑技巧：避免在Agent的思考循环中执行复杂的多表关联查询或长时间范围的全量数据查询，这会导致响应超时。复杂的分析应通过预计算、物化视图或流处理平台（如Flink）完成，Agent只查询结果。

2.4 原则四：分层决策与人工介入点设计

不要指望一个Agent解决所有问题。工业决策是分层的：简单、重复、规则明确的由自动化Agent处理；复杂、模糊、高风险的必须引入人工判断。

决策流设计：

1. 规则引擎前置：在调用LLM之前，先用一套简单的规则引擎（如Drools、Easy Rules）过滤。例如，“如果设备状态为‘紧急停机’，则直接触发报警并通知值班班长，无需询问Agent”。这既快又可靠。
2. 置信度阈值：Agent给出的每个建议或结论，都应附带一个置信度分数（可以由LLM自身输出，或通过后续验证逻辑计算）。设定阈值（如0.85）。低于阈值，自动转为“待人工审核”状态，并将上下文推送到工单系统或IM群。
3. 明确的移交协议：设计好人工介入的接口。当Agent请求人工帮助时，它需要提供一份清晰的“简报”，包括：问题概述、已收集的数据、已尝试的分析、不确定的点、以及需要人类专家决策的具体问题。这能极大提升人机协作效率。

// 示例：在工具执行后评估置信度 @Tool(“诊断设备异常”) public DiagnosisResult diagnoseEquipment(String deviceId) { // 1. 调用规则引擎进行初步诊断 RuleEngineResult ruleResult = ruleEngine.fire(deviceId); if (ruleResult.isConfident()) { return new DiagnosisResult(ruleResult.getConclusion(), 0.95); } // 2. 规则引擎无法确定，调用LLM Agent进行深度分析 String analysis = agent.analyze(deviceId); double confidence = calculateConfidence(analysis); // 3. 根据置信度决定流程 if (confidence < 0.85) { // 创建人工审核工单 createManualReviewTicket(deviceId, analysis, confidence); return new DiagnosisResult(“分析已完成，待专家审核”, confidence); } return new DiagnosisResult(analysis, confidence); }

2.5 原则五：可观测性与全链路追踪

一个黑盒的Agent在生产环境是可怕的。你必须能清晰地看到：用户输入了什么？Agent“想”了什么（内部推理过程）？调用了哪些工具？输入输出是什么？最终结果如何？

实现方案：

1. 结构化日志：使用SLF4J+Logback，并以JSON格式输出日志。每一条日志应包含：traceId（全链路唯一标识）、agentName、sessionId、step（如：tool_call,llm_invoke）、content。
2. 工具调用埋点：在每个工具方法的开始和结束处记录日志，包含执行耗时和结果摘要。这有助于性能分析和故障定位。
3. LLM交互记录：记录发送给LLM的完整Prompt和返回的Response。这是分析幻觉和优化提示词的关键。注意：这部分日志可能包含敏感数据，需做好脱敏和访问控制。
4. 度量指标（Metrics）：使用Micrometer集成Prometheus，暴露关键指标：
   • agent_invocation_total：Agent调用次数。
   • agent_duration_seconds：Agent处理耗时分布。
   • tool_call_total按工具名分类：各工具调用次数和错误数。
   • llm_token_usage：Prompt和Completion的Token消耗。
5. 追踪（Tracing）：集成OpenTelemetry，将一次Agent调用内部所有的工具调用、LLM请求、数据库查询串联成一个完整的追踪链路，在Jaeger或Zipkin中可视化。

实操心得：初期可以简单点，但结构化日志和关键指标必须从第一个Agent开始就做。等到出问题再补，就像飞机失事后才去找黑匣子一样被动。

2.6 原则六：渐进式迭代与版本化管理

不要试图一次性设计出完美的Agent。工业场景复杂，需求会变，模型会更新。必须建立敏捷的迭代机制。

开发运维流程：

1. Agent即微服务：每个独立的Agent都应作为一个单独的Spring Boot微服务来开发和部署。这保证了技术栈统一、独立伸缩、便于管理。
2. 配置外部化：所有可变部分（如LLM的API地址和密钥、工具的参数、置信度阈值、提示词模板）都必须放在配置中心（如Nacos、Apollo）或环境变量中。绝对不要硬编码在代码里。
3. 提示词工程版本化：提示词（Prompt Template）是Agent的“灵魂”。应该像管理代码一样管理它，使用Git进行版本控制。每次对提示词的修改，都应记录变更原因、预期效果，并通过测试用例进行回归验证。
4. A/B测试与灰度发布：对于核心Agent的升级（如更换底层LLM、优化提示词），应通过网关进行流量切分，将一部分请求导向新版本（B），对比其与旧版本（A）在响应质量、耗时、成本上的差异。
5. 回滚预案：任何时候都要有一键回滚到上一个稳定版本的能力。这依赖于清晰的版本标签和可靠的部署流水线。

3. 从原则到实践：构建一个设备健康评估Agent

让我们用一个具体的例子，串联起上述原则。我们要构建一个“设备健康评估Agent”，它能根据实时数据和历史记录，给出一台设备的健康评分和维保建议。

3.1 技术栈选型与项目初始化

• 框架：Spring Boot 3.x。提供成熟的Web、监控、配置管理能力。
• AI框架：LangChain4j。与Java生态集成好，抽象层次适中。
• LLM：根据实际情况选择。国内可选通义千问、文心一言的API，注意网络延迟和成本。
• 数据库：
  • TDEngine 3.x：存储设备所有的时序数据（电流、电压、温度、振动）。
  • MySQL/PostgreSQL：存储设备元数据、维修记录、Agent会话状态。
• 缓存：Redis。用于存储高频访问的设备实时快照和会话记忆。
• 监控：Prometheus + Grafana + Loki。用于指标、日志和链路追踪。

用Spring Initializr创建一个新项目，引入spring-boot-starter-web，langchain4j-spring-boot-starter，taos-jdbcdriver，redis等依赖。

3.2 核心工具类设计与实现

首先，遵循“原则一”和“原则三”，创建核心的数据查询工具。

@Service public class EquipmentDataTool { @Autowired private JdbcTemplate tdEngineJdbcTemplate; // 配置好的TDEngine数据源 @Tool(“获取设备当前关键指标”) public CurrentMetrics getCurrentMetrics(@P(“设备编号”) String deviceId) { // 参数校验 if (StringUtils.isBlank(deviceId)) { throw new IllegalArgumentException(“设备编号不能为空”); } // 优化查询：只查询最新时刻的数据，利用TDEngine的last函数 String sql = “SELECT last(current) as current, last(voltage) as voltage, last(temperature) as temp, last(vibration) as vib FROM meters WHERE device_id = ? AND ts >= now – 10s”; // 使用预编译语句防止注入 Map<String, Object> result = tdEngineJdbcTemplate.queryForMap(sql, deviceId); // 封装为结构化的对象，便于LLM理解和后续处理 return new CurrentMetrics( ((Number)result.get(“current”)).doubleValue(), ((Number)result.get(“voltage”)).doubleValue(), ((Number)result.get(“temp”)).doubleValue(), ((Number)result.get(“vib”)).doubleValue() ); } @Tool(“分析设备指标历史趋势”) public TrendAnalysis analyzeTrend(@P(“设备编号”) String deviceId, @P(“指标名称”) String metric, @P(“时间窗口”) String window) { // 解析时间窗口，如 “1h”, “24h” // 构建查询，使用INTERVAL进行降采样，减少数据量 String sql = String.format(“SELECT _wstart as ts, avg(%s) as avg_val FROM meters WHERE device_id = ? AND ts >= now – %s INTERVAL(5m)”, metric, window); List<DataPoint> points = tdEngineJdbcTemplate.query(sql, new Object[]{deviceId}, (rs, rowNum) -> new DataPoint(rs.getTimestamp(“ts”), rs.getDouble(“avg_val”))); // 进行简单的趋势计算（如线性回归斜率） double slope = calculateSlope(points); String trend = slope > 0.1 ? “上升” : (slope < -0.1 ? “下降” : “平稳”); // 格式化描述，供LLM使用 String summary = String.format(“在过去%s内，设备%s的%s指标总体呈%s趋势。平均值约为%.2f。”, window, deviceId, metric, trend, points.stream().mapToDouble(DataPoint::value).average().orElse(0)); return new TrendAnalysis(summary, slope, points); } }

3.3 Agent服务层与提示词工程

接下来，定义Agent接口，并注入工具和记忆。

// 1. 定义Agent接口 interface EquipmentHealthAgent { @SystemMessage(“”” 你是一个专业的设备健康管理专家。 你的任务是综合评估工业设备的健康状况，并提供可操作的维护建议。 你必须严格使用提供的工具来获取数据，并基于数据事实进行分析。 你的输出必须包含以下部分： 1. 健康评分 (0-100分)。 2. 主要依据 (列出关键指标及其状态)。 3. 风险评估 (低/中/高)。 4. 具体建议 (如：立即停机检查、安排计划性维护、继续观察)。 “””) @UserMessage(“请评估设备 {{deviceId}} 的健康状况。”) HealthAssessment assessHealth(String deviceId); } // 2. 配置并构建Agent Bean @Configuration public class AgentConfiguration { @Bean public EquipmentHealthAgent equipmentHealthAgent(ChatLanguageModel chatModel, EquipmentDataTool dataTool, ChatMemoryProvider memoryProvider) { return AiServices.builder(EquipmentHealthAgent.class) .chatLanguageModel(chatModel) .chatMemoryProvider(memoryProvider) .tools(dataTool) // 注入工具 .contentRetriever(/* 可选：注入设备文档检索器 */) .build(); } }

提示词设计要点：

• 角色明确：@SystemMessage中清晰定义Agent的专家身份和职责边界。
• 指令具体：明确要求输出必须包含的结构化内容，这能极大减少LLM的随机输出。
• 使用工具：在提示词中强调“必须使用提供的工具”，这是约束其行为的关键。

3.4 业务逻辑层与决策流控制

在Service层，我们实现“原则四”的分层决策。

@Service public class EquipmentHealthService { @Autowired private EquipmentHealthAgent agent; @Autowired private RuleEngine ruleEngine; @Autowired private TicketService ticketService; @Transactional public AssessmentResult assess(String deviceId) { // 步骤1：规则引擎快速检查（如：是否处于停机状态？是否有未关闭的紧急报警？） RuleResult ruleCheck = ruleEngine.quickCheck(deviceId); if (ruleCheck.isBlocking()) { return AssessmentResult.fastFail(ruleCheck.getMessage()); } // 步骤2：调用Agent进行综合评估 HealthAssessment assessment; try { assessment = agent.assessHealth(deviceId); } catch (Exception e) { log.error(“Agent评估失败”, e); // 降级策略：返回基于规则的简单评估 return fallbackAssessment(deviceId); } // 步骤3：根据Agent输出的置信度或风险评估等级，决定是否需要人工介入 if (“高”.equals(assessment.getRiskLevel()) || assessment.getScore() < 60) { // 高风险或低分，创建加急工单，通知工程师 Long ticketId = ticketService.createUrgentTicket(deviceId, assessment); return AssessmentResult.needManualReview(ticketId, assessment); } // 步骤4：评估通过，生成报告，可能触发自动工单（如计划性维护） if (assessment.getScore() < 80) { ticketService.createScheduledMaintenanceTicket(deviceId, assessment); } return AssessmentResult.autoCompleted(assessment); } }

3.5 可观测性集成与部署

最后，贯彻“原则五”，添加可观测性代码。

1. 日志：在Service和Tool的关键方法入口添加@Slf4j注解，记录入参和结果。
2. 指标：使用@Timed,@Counted注解或手动Micrometer计量，记录assess方法的调用次数、耗时和结果分布（成功、降级、人工介入）。
3. 配置：将LLM的Base URL、API Key、超时时间、各工具的查询超时等全部写入application.yml，并通过@ConfigurationProperties加载。
4. 部署：将该项目打包为Docker镜像。在Kubernetes或Docker Compose中，与TDEngine、Redis、MySQL等依赖服务一同编排。通过Ingress或Gateway暴露API接口。

4. 常见问题排查与性能调优实录

在实际部署和运行这22个Agent的过程中，我们遇到了形形色色的问题。以下是其中最典型的一些及其解决方案。

4.1 问题一：Agent响应慢，超时频繁

现象：前端调用Agent API，经常出现5秒以上的延迟，甚至超时（默认HTTP超时30秒）。

排查思路：

1. 检查链路：使用追踪工具（如SkyWalking, Jaeger）查看一次请求的完整链路，找到耗时最长的环节。
2. 分段诊断：
   • 网络延迟：Ping LLM API的服务地址，检查网络是否通畅。
   • LLM响应慢：检查发送的Prompt Token数量是否过多。是否每次都将完整的对话历史（可能很长）都发送了？启用流式响应（Streaming）虽然不能减少总时间，但能提升用户体验。
   • 工具调用慢：检查EquipmentDataTool中对TDEngine的查询。是否查询了过大的时间范围？是否没有使用索引？用EXPLAIN分析SQL语句。
   • 数据库连接池：检查JDBC连接池配置（如HikariCP）。是否连接数过少导致等待？连接是否正常关闭？

解决方案：

• 优化提示词：精简SystemMessage，移除冗余描述。使用“会话摘要”（见原则二）替代完整的对话历史。
• 优化数据查询：
  • 为TDEngine的查询条件字段（如device_id,ts）建立标签索引。
  • 限制历史数据查询范围，默认只查最近24小时或更短。
  • 对需要长期历史分析的场景，使用预计算的聚合结果表。
• 设置超时与重试：为LLM调用和每个工具调用配置独立的超时时间（如LLM 10秒，TDEngine查询2秒）。并配置合理的重试策略（仅对网络超时等可重试错误进行重试）。
• 异步化：对于非实时必须的后续操作（如生成详细报告、发送通知），使用@Async或消息队列进行异步处理，先返回核心结果。

4.2 问题二：LLM产生“幻觉”，给出错误建议

现象：Agent建议对一台正常运行的设备进行“立即停机检修”，依据是它“幻想”出了一个不存在的异常高温数据。

排查思路：

1. 检查日志：查看记录的完整Prompt和Response。确认提供给LLM的设备数据是否准确。
2. 分析工具输出：检查EquipmentDataTool返回给LLM的数据格式。是否是LLM容易误解的格式？例如，返回了一个复杂的JSON对象，LLM可能没有正确解析其中的某个字段。
3. 审查提示词：SystemMessage中的指令是否足够清晰？是否强调了“基于工具返回的事实数据”？

解决方案：

• 强化工具输出格式化：工具返回给LLM的数据，应尽可能以清晰、自然、无歧义的文本描述形式呈现。例如，不要只返回{“temp”: 72.5}，而是返回“当前电机温度为72.5°C，处于正常范围（65-80°C）内。”。
• 增加验证步骤：在Agent输出最终结论前，增加一个“事实核查”工具。这个工具将Agent的结论草稿与原始数据再次进行比对，检查是否存在矛盾。例如，如果Agent说“温度超标”，核查工具就去查询温度阈值定义和当前值，返回验证结果。
• 后处理规则：对Agent输出的结构化字段（如riskLevel,score）实施后处理规则。例如，如果健康评分>80，则强制将风险评估从“高”改为“中”或“低”，避免逻辑冲突。
• 提示词迭代：这是最关键的。收集一批“幻觉”案例，分析LLM误解的原因，针对性修改提示词。例如，增加负面示例：“如果工具返回的数据显示所有指标正常，则不得建议停机维修。”

4.3 问题三：高并发下内存溢出（OOM）

现象：在压力测试时，服务出现java.lang.OutOfMemoryError: Java heap space错误。

排查思路：

1. Heap Dump分析：使用jmap或在启动参数中添加-XX:+HeapDumpOnOutOfMemoryError生成堆转储文件，用MAT或JVisualVM分析，看是什么对象占用了大量内存。
2. 怀疑点：
   • 大对象：是否缓存了过大的设备数据？ChatMemory中是否存储了未经截断的超长对话历史？
   • 内存泄漏：是否有集合类（如Map,List）只增不减？连接池、HTTP客户端是否未正确关闭？

解决方案：

• 限制记忆容量：严格配置MessageWindowChatMemory的maxMessages参数，例如只保留最近10轮对话。对于更早的历史，定期清理或归档到冷存储。
• 优化缓存策略：对于从TDEngine查询的实时数据，使用带有TTL（生存时间）的缓存（如Redis），而不是存储在JVM内存的HashMap里。
• 调整JVM参数：根据容器内存限制，合理设置堆大小（-Xms,-Xmx）和年轻代大小。对于主要处理文本和缓存的Agent服务，可以适当增加堆内存。
• 代码审查：检查所有工具类和服务类，确保没有在类成员变量或静态变量中无限累积数据。使用WeakHashMap或定期清理策略。

4.4 问题四：TDEngine连接与查询错误

现象：日志中出现TDengine error (0x2600): SQL: show hospital_iot.views like ...或连接中断。

排查思路：

1. 错误码分析：0x2600通常是语法错误。检查生成的SQL语句，特别是表名、字段名是否含有特殊字符或关键字，需要用反引号括起来。
2. 连接池问题：TDEngine的连接可能因为网络波动或服务重启而失效。检查连接池的validationQuery（如SELECT 1）和testOnBorrow配置。
3. 版本兼容性：检查使用的taos-jdbcdriver版本与TDEngine服务器版本是否匹配。

解决方案：

• SQL规范化：在拼接SQL时，对数据库名、表名、超级表名使用反引号包裹。尤其是当名称包含点号.或中划线-时。

  // 正确 String sql = “SELECT * FROM `” + dbName + “`.`” + stableName + “` WHERE …”; // 错误（如果名称含点号） String sql = “SELECT * FROM ” + dbName + “.” + stableName + “ WHERE …”;

• 配置连接池健康检查：

  spring: datasource: hikari: connection-test-query: SELECT 1 connection-timeout: 30000 validation-timeout: 5000

• 实现连接重试机制：在工具类中，捕获SQL异常，如果是连接类错误，可以尝试初始化一个新的数据源连接（需谨慎，避免雪崩）。
• 监控TDEngine状态：在Grafana中监控TDEngine的节点状态、连接数、查询QPS等指标，提前发现资源瓶颈。

5. 进阶思考：Agent的协同与系统集成

当单个Agent稳定运行后，自然会考虑多个Agent如何协作，以及如何与现有工业系统（如MES、SCADA、ERP）深度融合。

Agent协同工作流：一个复杂的“产能优化”任务，可能涉及多个Agent的接力。

1. 订单解析Agent：从ERP接收新订单，解析产品规格、数量、交期。
2. 资源评估Agent：检查MES中的设备状态、物料库存。
3. 排产模拟Agent：调用仿真模型，模拟不同排产方案的结果。
4. 优化决策Agent：综合成本、时间、能耗等因素，选择最优方案。
5. 任务分发Agent：将方案分解为具体工单，下发给MES和现场人员。

实现这种协同，可以通过消息队列（如RabbitMQ, Kafka）进行解耦。每个Agent监听特定主题的消息，处理完后发布新的事件，触发下一个Agent的工作。这要求每个Agent都有清晰的事件输入输出定义。

与现有系统集成：这是价值落地的关键。

• API网关：在Agent集群前部署统一的API网关（如Spring Cloud Gateway），处理认证、限流、路由。
• 协议适配：工业现场协议繁多（OPC UA, Modbus, MQTT）。需要建立“协议转换层”，将设备数据统一采集到TDEngine，同时将Agent的指令转换为设备能理解的协议。
• 用户界面：为Agent提供聊天界面（集成到企业微信、钉钉或内部Web系统）只是方式之一。更深入的是将Agent的“建议”直接转化为业务系统的“工单”或“指令”，实现闭环。这需要与工单系统、调度系统建立稳定的API集成，并处理好异常回退。

构建工业Agent系统，技术只是骨架，真正的血肉是对业务的理解、对边界的掌控以及对失败的预案。从0到1是验证想法，从1到22则是构建一套可复用、可观测、可进化的工程体系。这套六大原则，就是我们在这条路上摸爬滚打后，留下的最实在的路标。