在工业设备运维中，AI 已经被用于异常检测和故障预测，帮助企业提前发现设备运行中的潜在问题。故障发现之后，工程师需要结合设备型号、维修手册和历史记录，进一步分析故障原因，确定排查方向。

大模型和 Agent 的出现，为这些故障排查工作提供了新的思路。通过知识检索和工具调用，Agent 可以从不同系统中获取设备信息、维修手册和历史工单，再根据查询结果整理故障排查思路，供工程师参考。要可靠地运行这套流程，还要解决文档版本匹配、工具权限控制和结果可靠性验证等问题。

本文以工业设备故障排查为例，结合七牛云 MaaS、AgentAPI 和 Kodo，介绍如何构建一个面向设备运维的知识 Agent，并讨论文档处理、工具调用和结果校验等具体实现问题。

说明：本文旨在展示参考架构与工程设计方法，使用的设备型号、故障代码、维修手册及工单均为模拟数据。

01 评测对象在上线后持续变化

假设某制造企业拥有多条自动化生产线，现场使用了不同型号的变频器、PLC 控制器和工业机器人。企业保存了设备操作手册、故障代码表、维护规范，以及多年积累的历史维修工单。

现在，一名现场工程师提出问题：「A 产线的 INV-200 变频器出现 E204 故障，应该怎么排查？」其中，INV-200 和 E204 均为模拟标识。

这个问题看似简单，但缺少一项重要信息：设备的唯一身份。

A 产线可能安装了多台 INV-200 变频器，即使型号相同，设备使用的固件版本也可能不同。仅凭产线和型号，系统未必能够找到唯一的设备实例。

因此，Agent 首先需要查询设备台账。如果存在多台候选设备，就应让工程师确认具体设备编号，再继续后续操作。

确认设备后，系统才能根据固件版本查找适用的故障定义与维修资料，避免混用不同设备或版本的信息。

因此，整个故障查询流程为：设备确认 → 故障代码查询 → 适用手册读取 → 历史工单检索 → 候选回答 → 证据校验 → 工程师复核。

02 工业知识 Agent 的系统架构

工业知识 Agent 可以拆分为两条相互配合的链路：离线知识处理与在线 Agent 执行。

离线链路负责将设备手册、故障代码表等原始资料转换为可查询的数据；在线链路负责理解工程师的问题，通过业务工具获取信息，再生成带有依据的回答。

图 1：工业设备运维知识 Agent 参考架构

离线处理时，企业可以将设备手册、维修规范和故障代码表保存到 Kodo，再由独立的文档解析服务完成内容提取、清洗和切分。

处理后的资料会根据内容特点，采用不同的存储和检索方式。例如，故障代码、手册章节及版本映射等信息可以写入结构化数据库，便于精确查询；维修说明等自然语言资料则通过 Embedding 建立向量索引，同时保留关键词索引与元数据，供后续知识检索使用。

这些数据和检索服务为 Agent 查询提供了基础。工程师通过企业应用提交问题后，七牛云 Agent API 根据任务需要发起工具调用，由企业应用检查任务阶段、参数和权限，再访问设备台账、故障代码库、手册服务及工单系统，获取相关信息。

查询结果回传给 Agent 后，模型据此生成候选回答，经企业应用完成证据校验后，再展示给工程师。

各组件的职责如下：

内网工具的执行位置

本文采用七牛云 Agent API 的 native 运行时，通过自定义工具接入企业内部业务系统。这类工具的业务代码运行在企业应用进程中，Agent API 负责传递工具调用请求和执行结果，实际的数据库查询和业务操作则由企业应用完成。

当 Agent 发起工具调用时，企业应用可以通过事件流（SSE）或事件列表获取 agent.custom_tool_use 事件，从中读取工具名称、调用参数及对应标识。随后，应用根据当前任务阶段检查参数和用户权限，通过校验后再访问相应的业务系统，并将执行结果通过 user.custom_tool_result 回传，使用 custom_tool_use_id 与原始调用关联。

Agent 收到工具结果后，便可以继续处理后续任务。如果一次执行中存在多个待处理的自定义工具调用，需要等它们全部返回结果后，会话才能继续。即使工具执行失败、权限被拒绝或发生超时，应用也需要回传对应的错误结果，避免会话一直等待。

由于整个业务查询过程都由企业应用完成，Agent API 无须自行访问工厂内网。对于部署在内网的设备台账和维修数据库，企业可以保留现有的网络访问方式，由企业应用负责与 Agent API 通信，同时做好出站网络连接、身份认证和敏感数据传输管理。

可信会话状态与人工确认

当设备台账返回多个候选实例时，企业应用还需要让工程师确认具体设备。由于这一过程涉及人工交互，应用需要暂时保留当前会话和待处理的工具调用，等工程师完成选择后，再将确认结果回传给 Agent。

在等待期间，Agent API 会话暂停，等待自定义工具结果。应用可以通过 session.status_idle 事件中的 stop_reason.type = requires_action 识别这一情况，并根据 stop_reason.event_ids 找到对应的待处理调用。

考虑到工程师可能长时间没有响应，或者交互过程中出现网络中断，应用还需要设置等待超时，并保存会话 ID、待处理事件 ID、工具调用标识等信息，以便恢复或结束任务。由于 Agent API 的事件流支持历史事件回放，重新连接后可能再次收到之前的 agent.custom_tool_use 事件，因此还需要记录调用的处理状态，通过幂等控制()避免重复执行。

工程师完成设备选择后，应用会先检查其访问权限，再将确认的设备 ID、固件版本等信息保存到服务端，作为后续查询的可信业务状态。手册授权范围和当前任务阶段也由应用维护，并随着查询过程更新。

这些信息来自设备台账、用户确认及应用层校验，后续工具调用应以服务端保存的状态为准，避免仅依赖模型的对话上下文来确定设备身份和查询范围。

有了这些可信信息，企业应用就可以判断当前任务允许执行哪些操作。例如，设备尚未确认时，不能继续查询故障代码或读取维修手册；如果手册没有通过版本校验，也不能读取对应章节。即使 Agent 提前发起了这些工具调用，应用也会检查前置条件，对不符合要求的请求返回错误结果。

工具执行失败后，相关的后续操作也需要受到限制。例如，故障代码查询未能找到适用的维修手册，应用就不能允许 Agent 继续读取该手册的章节。因为向 Agent 回传错误结果，并不意味着模型一定会停止后续调用，应用仍需根据当前任务状态判断哪些操作可以继续执行。

此外，可信状态也不能一直沿用。应用需要记录设备信息的核验时间、固件版本、手册版本及权限检查结果。当任务长时间暂停后恢复时，应重新核对相关信息是否仍然有效。如果工程师中途切换设备，原先查询得到的故障信息和手册授权也要一并清除，再针对新设备重新查询。

通过这些处理，应用可以根据当前设备信息和任务进度控制工具调用，确保后续查询使用的是经过确认且仍然有效的数据。

03 如何将工业资料转化为可检索知识？

工业知识 Agent 的回答质量，很大程度上取决于检索到的资料是否适用。

如果系统将其他设备型号的维修手册作为依据，或者使用了失效的维护规范，即使模型准确理解了检索结果，也可能生成错误建议。

因此，在模型调用之前，需要先解决资料归档、版本管理和知识索引等问题。

设备固件与文档版本分开管理

设备固件版本和维修手册版本需要分别记录。

例如，一台 INV-200 设备当前运行固件 2.1 ，而适用于它的维修手册版本为 3.0 。手册和固件采用各自的版本体系，不能仅凭版本号相同或大小关系判断是否匹配。

下面是模拟的应用层文档元数据：

{
  "document_id": "manual-inv200-v30",
"equipment_model": "INV-200",
"document_type": "maintenance_manual",
"document_version": "3.0",
"applicable_firmware": {
    "min": "2.0",
    "max": "2.3"
  },
"status": "effective",
"object_key": "manuals/INV-200/v3.0.pdf"
}

从这份元数据可以看到，手册版本与适用固件范围分别记录。实际项目还需结合设备制造商、硬件修订版等信息，按照厂商定义的兼容规则判断版本是否匹配，避免简单比较版本字符串。

原始手册保存在 Kodo 中，文档元数据由应用数据库管理。建立知识索引时，每个知识片段都需要关联文档 ID、章节、适用版本及来源位置，以便后续检索和引用。

保留文档的章节与表格结构

工业维修资料包含大量表格、编号列表和操作说明，一条故障记录可能同时涉及故障代码、触发条件、可能原因、检查步骤和安全注意事项。如果解析时打乱了表格的行列关系，就可能把不同故障的处理要求错误关联起来。因此，除了提取文字内容，还需要尽量保留文档原有的结构。

具体的解析方式取决于文件格式。文字版 PDF 可以提取正文和版面信息，扫描件需要借助 OCR 识别内容，Excel 故障代码表则可以按字段读取。对于包含复杂图示的资料，还可以结合多模态模型辅助分析，但涉及关键技术参数时仍需专门核验。

完成解析后，接下来需要考虑如何切分这些内容。以维修手册为例，可以按照章节、故障条目和操作主题划分，让同一条故障说明中的原因、检查步骤及注意事项尽量保留在一个知识单元中。如果章节内容较长，则可以采用父子片段检索，先利用较小的片段进行匹配，再返回所属的完整章节或故障条目，减少内容切分造成的信息缺失。

为了方便后续引用和校验，切分时还应保留章节标题、页码及原文位置。对于故障检查项目，可以进一步建立独立条目，为每条内容分配稳定的条目 ID，并关联原文、适用条件和文档版本。这样，Agent 在生成回答时就能引用具体的检查内容，应用也可以根据这些信息核对回答的依据。

结构化查询与语义检索分别处理

工业知识的查询方式需要根据具体内容来选择。设备型号、故障代码和固件版本都有明确字段，适合通过结构化数据进行精确查询；而「设备运行一段时间后出现温度异常」这样的自然语言描述，则可以结合关键词和向量检索查找相关资料。

针对这两类查询需求，离线处理时可以分别建立：

结构化知识： 保存故障代码定义、设备型号、适用版本及手册章节映射。
文档知识索引： 用于检索维修说明、故障现象、注意事项及其他技术资料。

两类数据都需要保留原始来源。例如，故障代码表可以先保存到 Kodo，解析后再将代码、定义和手册位置写入结构化数据库。

有了这些数据，Agent 遇到明确的故障代码时，可以通过结构化数据库查询；如果工程师只描述了故障现象，则可以调用混合检索服务。

设备台账和历史工单则继续由企业现有的业务系统管理，Agent 通过相应接口获取信息，无须将所有业务数据都纳入知识索引。

04 如何找到当前设备适用的维修资料？

工业知识检索需要考虑资料的适用性。两台不同型号的变频器可能出现类似告警，但故障定义和处理方法可能不同，因此，文本内容相似并不意味着资料适用于当前设备。检索之前，需要先确认设备身份及适用版本。

本文采用设备实例确认、结构化过滤与知识检索相结合的方式。工程师提出问题后，系统先查询设备台账。如果同一产线上存在多台同型号设备，就返回候选列表，由工程师确认具体设备。随后，系统读取该设备的型号、固件版本等信息，并将确认结果保存到企业应用的可信会话状态中。

后续工具调用以这份可信状态为准，检查请求是否针对当前设备，以及任务阶段是否允许执行对应操作，避免模型传入错误的设备 ID 或固件版本。

完成设备确认后，如果用户提供了明确的故障代码，系统就可以根据设备型号和故障代码查询结构化故障库，获取候选维修手册及其适用范围。企业应用再根据已确认的固件版本筛选有效资料，将通过校验的手册 ID、故障章节及必要的关联章节记录到可信会话状态中，并将查询结果回传给 Agent。

关联章节主要用于补充故障排查所需的前置条件、安全要求或参数说明。例如，故障说明位于第 5.4 节，但相关安全要求保存在第 2.1 节，系统就需要同时获取这些内容。关联章节由应用根据文档结构和业务规则确定，并完成版本、有效性及访问权限校验。后续 get \_manual_section 只能读取获准访问的章节，对未经授权的 manual_id 或章节请求予以拒绝。

如果用户没有提供故障代码，只描述了故障现象，则可以采用混合检索。关键词检索负责匹配设备型号、零部件编号和专业术语，向量检索用于理解自然语言描述，再通过重排序选取相关知识片段。

混合检索同样需要根据已确认的设备信息、文档状态和用户权限过滤资料。检索结果交给模型前，还需核对适用范围并记录文档 ID、版本及来源位置。对于缺少适用版本信息或无法确认有效性的资料，应标记为待核实，暂不作为维修建议的依据。

相比之下，对于能够通过故障代码定位手册章节的问题，优先采用精确查询，可以减少检索步骤，也方便核对结果。

资料冲突的处理

工业知识库还需要处理不同来源之间的信息冲突。例如，结构化故障代码库与维修手册中的故障定义可能存在差异，历史工单记录的处理方法也可能与当前维修规范不一致。对于这两种情况，需要采取不同的处理方式。

如果结构化故障代码库与正式手册存在冲突，系统应暂停使用有争议的故障定义，标注冲突字段、版本及来源，交由资料维护人员核实。

如果历史工单与当前有效的维修手册不一致，则应以适用的正式维修规范为依据，将历史工单作为经验参考，并向工程师说明两者的差异，避免 Agent 根据过去的维修经验自行确定处理方法。

如果这些冲突影响到当前故障的排查结论，系统还需要暂停输出相关建议，等待工程师进一步确认。

05 让 Agent 连接知识库与工业业务系统

完成数据处理和知识索引建设后，就可以将这些查询能力封装成 Agent 工具。这里设计了四个核心工具，以及一个可选的混合检索工具。

这些工具的实际执行由企业应用负责。Agent 发起调用后，企业应用会检查任务阶段、调用参数和用户权限，再查询相应的业务系统，并将结果回传给 Agent。

接下来以一次模拟的设备故障查询为例，看看这些工具如何配合完成任务。

一次完整的模拟故障查询

假设工程师输入：「A 产线的 INV-200 变频器出现 E204 故障，应该如何排查？」

为了展示执行过程，先准备一组模拟数据：

注：上述设备和故障定义均为虚构数据。

上图展示了故障查询过程中各个工具的调用顺序。Agent 根据任务需要发起调用，企业应用则负责核对当前的执行进度和调用条件，只有符合要求的操作才会继续执行。

第一步：确认设备实例

Agent 调用 get_equipment_info，查询 A 产线上的 INV-200 设备。假设设备台账返回两个候选实例：

{
  "candidates": [
    {
      "equipment_id": "EQ-A-017",
      "model": "INV-200",
      "firmware_version": "2.1"
    },
    {
      "equipment_id": "EQ-A-023",
      "model": "INV-200",
      "firmware_version": "2.4"
    }
  ],
"requires_confirmation": true
}

这里展示的是设备台账返回给企业应用的原始结果，尚未回传给 Agent。由于查询到了两台同型号设备，企业应用需要保留当前的 get_equipment_info 调用，并将候选设备展示给工程师，由其确认具体设备编号。

查询候选设备时，应用会根据用户权限限定可访问的产线和设备范围。工程师选择设备后，还需要再次检查其是否拥有该设备的访问权限。

等待工程师确认期间，Agent API 会话暂停，等待自定义工具结果。应用通过 session.status_idle 事件中的 stop_reason.type = requires_action 判断暂停原因，再根据 stop_reason.event_ids 找到对应的工具调用，并保存调用标识，以便处理超时、取消及会话恢复。

假设工程师选择了 EQ-A-017，且通过权限检查，应用便将设备 ID 和固件版本 2.1 保存到当前任务的可信会话状态中，再将确认后的设备信息作为工具结果回传给 Agent。

如果工程师没有该设备的访问权限，应用会返回权限不足的结果，停止依赖该设备信息的后续查询。如果工程师取消选择或长时间未响应，则返回相应的取消或超时结果，结束本次等待。

第二步：查询故障定义

确认设备后，Agent 调用 lookup_fault_code。输入示例：

{
  "equipment_model": "INV-200",
  "fault_code": "E204"
}

业务接口的模拟原始返回如下：

{
  "found": true,
"fault_code": "E204",
"candidates": [
    {
      "fault_name": "散热系统异常",
      "manual_id": "manual-inv200-v30",
      "manual_version": "3.0",
      "applicable_firmware": {
        "min": "2.0",
        "max": "2.3"
      },
      "section": "5.4"
    }
  ]
}

企业应用根据当前设备的型号和固件版本，对查询到的候选手册进行匹配。例如，EQ-A-017 的固件版本为 2.1，符合维修手册支持的 2.0～2.3 范围，因此可以使用这份手册。

完成匹配后，应用将故障定义、手册 ID、版本及章节位置回传给 Agent，同时记录本次任务获准访问的章节范围。

如果工程师选择的是另一台设备 EQ-A-023，其固件版本为 2.4，超出了当前手册的适用范围。应用会返回版本不匹配的结果，停止后续章节读取，并提示工程师查找适用的维修资料。

第三步：读取维修手册与关联章节

获得适用的手册 ID 和章节编号后，Agent 调用 get_manual_section。输入示例：

{
  "manual_id": "manual-inv200-v30",
  "section": "5.4"
}

收到工具调用后，企业应用会根据已确认的设备信息和手册版本，核对请求的手册 ID 及章节编号。确认属于当前任务的授权范围后，再读取对应内容。

模拟返回如下：

{
  "document_id": "manual-inv200-v30",
"document_version": "3.0",
"section": "5.4",
"page": 38,
"fault_code": "E204",
"fault_name": "散热系统异常",
"inspection_items": [
    {
      "item_id": "INV200-E204-01",
      "content": "查看设备告警记录及发生频率"
    },
    {
      "item_id": "INV200-E204-02",
      "content": "核对散热风扇运行状态"
    },
    {
      "item_id": "INV200-E204-03",
      "content": "查看外部风道是否存在可见堵塞"
    },
    {
      "item_id": "INV200-E204-04",
      "content": "核对散热相关运行参数"
    }
  ],
"related_sections": [
    {
      "section": "2.1",
      "type": "safety_requirements",
      "authorized": true,
      "source_page": 12,
      "items": [
        {
          "item_id": "INV200-SAFE-01",
          "content": "现场检查前，应由授权人员确认适用的安全作业条件。",
          "applicable_to": "E204 故障排查"
        }
      ]
    }
  ],
"safety_note": "涉及拆卸或内部检查时，由授权人员按照正式安全作业规程执行。"
}

返回结果中，每个检查项目都有独立的条目 ID，并关联原文、适用条件及来源位置，方便后续核对回答的依据。

除了故障章节，get_manual_section 还会一并返回必要的关联章节。例如，第 2.1 节中的安全要求经过版本和权限校验后，会作为具体条目提供给模型，帮助其理解故障排查的前置条件。如果缺少必要的安全信息，系统则需要等待补充资料。

这些内容优先从解析后的章节数据中读取。如果工程师需要核对原文，应用还可以根据文档 ID 和来源位置，从 Kodo 获取对应的原始文件。

第四步：查询历史维修工单

获取适用的维修手册后，Agent 可以调用 search_maintenance_records，查询当前设备的历史维修记录。

收到调用请求后，企业应用会从可信会话状态中获取设备 ID，并检查用户是否拥有相应的设备和工单访问权限。确认后，再查询工单系统，将结果回传给 Agent。

假设工具返回：

{
  "work_order_id": "WO-2026-0182",
  "equipment_id": "EQ-A-017",
  "fault_code": "E204",
  "confirmed_cause": "散热部件状态异常",
  "status": "closed",
  "verified": true
}

这条工单记录显示，该设备过去曾出现相同的故障代码，当时确认的原因是散热部件状态异常。不过，这只能作为本次排查的参考，还需要结合当前设备的实际情况判断。

如果用户没有工单访问权限，应用会向 Agent 返回相应结果。Agent 仍可依据已获取的维修手册整理排查建议，并说明未参考历史工单。

如果历史工单与当前维修手册存在冲突，则需要标明差异及来源，交由工程师核实。具体的检查和操作要求仍以当前适用的正式维修规范为准。

第五步：生成候选回答

完成上述查询后，Agent 会综合故障代码、维修手册和历史工单中的信息，整理出一份附有参考来源的排查建议。

表 1：模拟 Agent 故障查询结果

这份建议综合了不同来源的信息：故障定义来自结构化查询，检查项目依据适用的维修手册，历史工单则提供了以往的处理经验。

整理回答时，模型需要区分历史经验与当前故障的实际情况。对于涉及专业操作的检查项目，应尽量保留手册中经过审核的内容及适用条件，避免改写后产生歧义。

第六步：执行应用层证据校验

Agent 生成候选回答后，企业应用还需要核对其中的信息是否准确。除了检查设备 ID、固件版本、手册适用范围和引用章节，还可以利用前面建立的条目 ID，追溯检查项目的原文、适用条件及文档版本。

这部分校验可以分为两个层面：

结构化校验： 检查设备 ID、版本范围、文档状态、条目 ID、引用位置和任务阶段等信息，通过应用规则完成验证。
语义一致性校验： 检查回答是否符合原文，有没有遗漏适用条件、添加未经证实的故障原因，或改变手册中的检查要求。这部分可以结合评估模型与人工复核。

需要注意的是，引用来源正确，并不代表回答中的结论一定准确。例如，模型虽然引用了正确的手册章节，却可能遗漏其中的安全要求。因此，对于涉及专业操作的内容，应尽量保留经过审核的原始条目，由模型负责整理和说明。

完成校验后，企业应用还要确认回答所需的证据是否齐全。如果设备信息尚未确认、缺少适用的维修手册，或者关键资料存在冲突，就应标明缺失信息及待核实事项。对于无法获得可靠依据的结论，暂不作为维修建议输出。

最后，系统将通过校验的回答提交给工程师复核。

06 Agent 工具权限如何设计？

根据七牛云 Agent API 的权限机制，自定义工具不受 permission_policy 中 always_ask 或 always_allow 的控制。因此，用户身份验证、参数校验和访问权限管理都需要由企业应用完成。

具体来说，查询设备台账时，应用需要检查用户能够访问的产线和设备范围；工程师选定设备后，还要确认其是否拥有该设备的访问权限。查询历史工单时，同样需要核对用户是否有权查看相关维修记录。

除了用户权限，工具调用还要符合当前任务的执行条件。例如，即使用户有权查看某份维修手册，如果该手册与当前设备的固件版本不匹配，也不能用于本次故障排查。

对于内置工具和 MCP() 工具，Agent API 通过 permission_policy 管理调用权限。在 native 运行时下，可以设置 always_allow 允许自动调用，或使用 always_ask 在调用前请求确认。

不过，工具调用获得确认后，业务系统仍需检查用户是否拥有相应的操作权限。

本文的方案仅使用自定义查询工具，不涉及设备控制。如果后续需要接入内置工具或 MCP 工具，可以根据业务需求配置调用权限；涉及高风险操作时，还需由企业应用完成审批，并遵循现有的工业安全管理要求。

07 如何评估工业知识 Agent 的效果？

完成故障问答演示后，还需要进一步评估 Agent 的实际表现，包括知识检索是否准确、工具调用是否可靠，以及遇到资料缺失或信息冲突时能否妥善处理。

评估可以从一个设备系列入手，利用经过工程师确认的维修资料建立测试集。测试问题应覆盖不同设备实例、固件版本和故障代码，并加入资料缺失、权限不足、版本不匹配等异常情况。

具体可以从三个方面展开：

知识与数据检索： 检查设备实例、故障代码和维修手册是否匹配，检索结果是否来自当前适用的资料。
Agent 执行过程： 分别评估模型选择工具、传递参数和安排调用时机的合理性，以及企业应用能否正确执行或拒绝调用。
回答质量： 检查结论是否得到原文支持，有没有遗漏适用条件和安全要求，以及是否将历史维修经验误判为当前故障原因。

评估时，需要区分 Agent 自身的调用表现与企业应用的规则执行情况。例如，模型在设备尚未确认时请求读取维修手册，说明工具调用时机不合理；但如果应用正确拒绝了请求，说明应用层的校验机制正常发挥了作用。

引用可追溯率和证据支持率也有所不同。前者检查能否找到引用来源，后者还要判断原文是否真正支持回答中的结论。

针对异常情况，可以使用前面的 EQ-A-023 作为测试案例。该设备的固件版本为 2.4，而当前维修手册仅适用于 2.0～2.3，系统应识别版本不匹配，并停止使用这份手册生成排查建议。

其他测试可以覆盖未确认设备时的工具调用、未授权章节的读取，以及工具失败后的后续处理。对于长时间暂停的任务，还可以模拟固件升级、手册失效或用户权限变更，检查恢复任务时能否重新验证相关信息。

回答质量方面，则需要测试模型是否遗漏适用条件、改变手册中的检查要求，或添加没有依据的故障原因。结合 Agent 的工具调用记录和应用状态变化，可以进一步定位问题发生在哪个环节。

初期可以优先验证设备识别、版本匹配、应用规则执行和证据支持的准确性，再逐步优化响应时间、模型调用次数和运行成本。

结语

工业设备运维知识 Agent 的可靠性，除了模型本身的能力，还取决于设备信息、维修资料和业务系统能否准确配合。从设备身份确认、手册版本匹配，到工具调用和结果校验，每个环节都需要有明确的数据依据和执行规则。

对于准备引入工业 Agent 的企业，可以先选择一个设备系列，利用现有维修资料建立知识库，再逐步接入设备台账、故障代码库等业务系统，从知识查询和故障排查辅助开始验证效果。

随着检索准确性、工具调用和回答质量得到验证，再考虑扩展到维修工单等业务流程，让 Agent 逐步参与更多设备运维工作。

Agent Memory 不只是存下来：如何设计写入、遗忘与维护机制

一个新 Issue 变成下一版 Skill：Warp 的双层架构构建“自进化”Agent 机制

#工业AI #AIAgent #RAG #智能运维 #知识库 #工具调用 #七牛云

如何构建一个面向工业设备运维的知识 Agent？

摘要