摘要：让企业软件从积累中生长
企业引入 AI 时，真正耗费交付精力的往往不只是模型。设备要接入，数据要关联，告警要处理，工单要流转，权限和操作记录也要完整。模型升级之后，这些已经运行的业务仍然需要继续工作。Kit 要解决的，就是业务积累如何被保留、复用和持续扩展的问题。
业务完整
部署出来的 Kit 应能承载一类业务的完整过程，从数据进入到任务完成。
模板可复用
共同能力作为产品沉淀，客户差异通过配置、API 和 SDK 开发实现。
Agent 原生
既能在业务中装配 Agent，也能把业务能力以标准接口开放给 Agent。
下文以设备运维为主线：同一套设备 Kit 如何服务燃气轮机、电潜泵与压缩机，如何更换诊断能力，以及如何让人和 Agent 安全地使用同一套业务。
一、先定义业务闭环，再定义 AI 功能
设备 Kit 的起点，是一套可运行的设备运维系统。它需要知道设备是什么、数据从哪里来、异常如何被发现、由谁处理、处理结果如何回写。只有“设备列表 + 智能诊断按钮”，还无法承担完整交付。
- 接入与建档：关联设备台账、测点、实时数据和历史数据，建立一致的设备身份。
- 监测与识别：呈现状态与趋势，把异常转换为有设备、有时间、有证据的告警事件。
- 诊断与处置：结合数据形成诊断建议，进入风险评估、人工审核或维修工单流程。
- 完成与追踪：记录执行结果，关闭工单，并保留从告警到处置的关联关系。
视觉 Kit 也遵循同一原则。摄像头接入、视频流与算法管理、识别事件、告警和后续处置，需要形成完整过程。目标检测模型是其中一项能力，摄像头与算法如何绑定、谁能查看结果、事件如何进入业务，同样属于 Kit 的职责。
因此，判断业务是否完整，应从一个真实任务能否走到结果开始。页面数量和 Agent 数量，都不能单独说明这个问题。
二、模板复用的是业务结构
燃气轮机、电潜泵和压缩机的诊断知识不同，但它们都需要设备管理、测点数据、状态监测、告警、诊断和工单。Kit 应把这些稳定的共同部分抽象出来，把设备模型、阈值、诊断方法等差异留给具体项目。
把可复用的业务保留下来，让项目差异在上面生长。
这样的抽象，需要明确哪些东西共享，哪些东西允许变化。以告警为例，事件编号、设备关联、时间、状态和处理记录应有稳定的结构；阈值规则、告警等级和分派方式则可以根据项目调整。共同结构使不同项目能够共享业务能力，扩展点使模板保留足够的适应性。
三、把常见的项目差异变成配置
可配置意味着，把已经理解清楚的变化范围设计成明确选项。菜单、字段、表单、权限、告警规则和流程节点，都可以成为配置对象。配置应有业务含义、约束和默认值，让实施人员知道自己改变了什么。
AI 能力也应进入这一配置体系。一个“智能诊断”按钮使用哪个 Agent、读取哪些上下文、输出什么结构、失败后走哪条路径，都需要被清楚地定义。这样，业务页面可以保持稳定，诊断方法可以独立调整。
配置本身也会影响生产行为，因此应当有版本、校验和发布过程。修改一个诊断绑定，与修改一项业务规则一样，都需要能够说明变更范围，并在验证失败时恢复。
四、用 API 和 SDK 承接超出配置的需求
企业需求不会停在模板预设的范围内。Kit 应为开发者提供两条清楚的扩展路径：通过 API 组合现有业务能力，或通过 SDK 在工程内部增加能力。
API：把 Kit 作为业务能力服务使用
上层应用可以查询设备、读取告警、创建工单，也可以把处理结果同步到 MES 或 EAM。调用方使用稳定的业务接口，不需要重复实现底层设备管理与工单逻辑。
SDK：在真实工程中继续开发
当需要新的页面、领域对象、业务服务、数据连接器或特殊流程时，开发者可以在前端与后端工程中实现。扩展应沿用现有身份、权限和数据规则，并通过明确的模块边界接入。
例如，为设备详情增加“健康评分”，可以先定义评分数据与更新方式，再扩展服务接口和页面组件，最后把评分接入告警或巡检流程。已有设备台账、历史工单和权限体系继续承担原来的职责。
五、让 Coding Agent 理解工程，持续做增量开发
AI Coding Friendly 的重点，是让工程结构和扩展约定能够被理解。目录、模块边界、接口、数据模型与示例应彼此一致。Coding Agent 需要能够找到设备页面、业务服务、Agent 定义、Workflow，以及项目允许使用的扩展点。
- 理解现状：定位相关模块、数据依赖和现有业务约束。
- 实现变化：在明确的扩展点上添加页面、服务或能力绑定。
- 验证影响：检查接口契约、权限、状态转换和关键业务流程。
- 发布与保留：记录版本和变更范围，保留已有业务数据与运行能力。
增量开发的结果，应是系统每次只增加或调整必要的部分。今天加入健康评分，明天换一个诊断 Agent，后天连接客户的 MES。业务能力随着项目推进逐步积累，原有流程不因新增 AI 功能而被反复重建。
六、Agent Native：把智能能力装配到业务动作中
在设备详情页上，用户发起的是“诊断这台设备”这一业务动作。具体由通用诊断 Agent、燃机专家 Agent，还是包含多个步骤的 Workflow 完成，可以由场景配置决定。业务动作与智能实现之间，需要一层明确的绑定关系。
校验结果 → 必要时人工确认 → 调用业务服务 → 留下审计记录
能够装配的不只有 Agent，也可以是 Workflow、Skill、算法或 Tool。例如“诊断并处理”可以先读取设备数据，再形成诊断建议，经过风险判断与审核，最后调用工单服务。每一步的输入、输出和失败处理，都应能被单独检查。
可替换并不意味着任意实现都能直接互换。新的诊断 Agent 必须理解相同的设备标识与数据范围，返回约定的结果结构，并遵守同一套操作权限。只有这些契约成立，替换才不会把变化扩散到整个业务系统。
稳定的部分是设备、工单、审批和业务状态；持续演进的部分是模型、Agent、算法和 Workflow。Kit 的任务，是把二者的连接关系设计清楚。
七、系统本身，也应能够被 Agent 使用
Agent Native 还有另一个方向：外部 Agent 应能通过标准入口使用 Kit 的业务能力。查询设备、读取告警、创建工单和提交审核，都应有明确的接口，而不必依赖 Agent 模拟人在页面上逐次点击。
API、Tool 或 MCP 都可以承担能力开放的入口，具体协议可以不同，但业务语义需要一致。例如“创建工单”应明确设备、问题描述、关联告警和责任人等参数，并返回可以继续查询的工单标识。失败也应有可理解的原因。
- 身份与范围：Agent 以什么身份调用，可以访问哪些设备、数据和操作。
- 审批与执行：哪些操作可以直接执行，哪些需要先由人确认。
- 记录与恢复：保存调用、版本、结果和业务状态，失败后能够追踪并继续处理。
八、把定义落到一个设备诊断项目里
假设企业要为一组电潜泵建设诊断应用。已有设备 Kit 提供台账、时序数据、告警和工单。实施工作的重点应放在项目差异上，按照以下顺序把通用能力变成可运行的应用。
- 配置设备与数据：建立泵型、测点、单位和数据映射，验证历史与实时数据能关联到正确设备。
- 绑定诊断能力：选择电潜泵诊断 Agent，规定输入时间窗、可读资料、结果结构和超时后的处理方式。
- 接入处置流程：把诊断建议连接到风险判断、人工审核与工单服务，明确谁能执行每一步。
- 开发客户差异：通过 API 对接客户 EAM；需要新增页面或服务时，通过 SDK 在现有工程中扩展。
- 验证并发布：从一个告警走完整个流程，检查数据、权限、审批、工单结果和操作记录，再发布对应版本。
项目运行之后，诊断 Agent 可以继续升级，设备数据、工单记录和已确认的业务规则则持续积累。下一次面对另一种设备，复用的就是这套已经形成边界的业务结构与工程方法。
九、如何判断一套模板是否达到 Kit 的设计目标
判断一套 Kit，可以沿着真实交付过程提出问题，而不是只看它是否展示了 AI 对话。以下四组问题，对应业务、模板、工程和 Agent Native 四个方面。
成熟的传统平台可能已经具备其中若干能力。Kit 的设计目标，是把这些能力放进同一个可交付、可复用、可持续开发的产品中，并从一开始考虑人和 Agent 两类使用者。
结语：业务长期积累，智能持续演进
企业软件的价值，来自被理解的业务、已经运行的数据和流程，以及长期积累的工程能力。Kit 把这些积累变成可以复用的起点，同时为新的模型、Agent 和开发方式保留清楚的接入位置。
- 业务是完整的。
- 模板是可复用的。
- 工程是可持续开发的。
- Agent 是原生的。