前几篇把架构层面的设计讲清楚了。这篇换一个视角从一个具体的操作流程出发看一个已有的业务系统怎么一步步变成 AI 工作台里可被 Agent 调用的业务应用能力。整个流程分四个步骤治理工程、生成本体、部署文件、注册应用。如果工程治理已经做好工作台基础设施和身份体系也已经配置完成后三步加在一起确实可以在几分钟内完成。重要提示本方案仅限于使用活字格低代码开发平台构建的业务应用。理论上所有良好治理的元数据驱动型低代码平台均可实现类似的效果。前提工作台已经搭好这篇描述的是接入一个新应用的流程不是从零搭建数字员工工作台的流程。工作台本身的搭建服务器配置、MQTT Broker 部署、Agent 执行层安装等是一次性的基础设施工作第 27 篇会讨论网络和部署细节。假设现在工作台已经运行里面已经接入了几个应用现在要把一个新的设备管理系统也接进来。第一步工程治理严格说治理不是注册流程的一部分但它决定了后续生成的本体质量是决定 AI 能不能正确使用这个系统的关键。把治理放在流程第一步是因为它经常被跳过。有些团队直接把没有治理过的工程扔进去抽取得到一堆没有业务含义的本体文件然后困惑为什么 AI 调用不准。这里列出最影响本体质量的几个检查项。表名和列名是否使用了中文或有意义的英文而不是拼音缩写或代号。GLC_JJPCHZB这样的命名对 AI 来说是完全不透明的设备维修记录则直接传达了业务含义。枚举类型的字段是否有备注说明每个取值的业务含义。维修状态字段的取值是 1、2、3如果没有备注AI 不知道 1 是待处理、2 是维修中、3 是已完成。这类字段在设备管理系统里非常多每一个缺失的备注都是一个潜在的调用错误点。ID 类参数是否在名称里说明了归属。参数叫ID是无效信息叫设备 ID才能让 AI 知道这个参数对应的是哪个实体。服务端命令是否使用谓宾结构命名。新建维修工单、关闭设备故障、更新维修状态这类命名AI 能从名字直接推断语义cmd_exec_007这类命名AI 只能靠描述字段如果描述也是空的这个命令对 AI 来说就是盲区。有关联关系的表是否补充了表关联配置。设备表和维修记录表之间通过设备 ID 关联这个关联关系如果没有在工程里显式配置自动抽取时就会缺失AI 在需要跨表推理时会丢失这条线索。治理完成后把修改后的工程提交到 Git 仓库。第二步生成本体工程文件准备好之后在命令行里执行一条命令npminstall-ghuozige-ontology-builder huozige-ontology-builder https://gitee.com/kadbbz_admin/hzg-ontology-builder-sample--app_info这是一个示例应用没有具体业务第一个参数指向活字格工程文件所在的目录--app_info则是对这个应用的总体描述。如果是第一次接入还没有标注白名单可以先输出全部但这一步只用于本地审查本体质量不能直接部署到生产环境。检查完成后需要在工程里给准备开放给 AI 的服务端命令加上标记再追加--sc_mode whitelist参数使用白名单模式仅扫描备注中包含[HOB_INCLUDE]的服务端命令重新生成。生产注册时只允许部署白名单模式生成的本体。命令执行完成后在以时间戳命名的子文件中result目录就是 Ontology 文件夹里会有一批 Markdown 文件。其中主索引文件index.md列出了所有实体的目录和系统的整体描述每个实体、每个页面绑定、每个服务端命令各有独立的详情文件。打开索引文件检查两件事app-description字段的内容是否清楚描述了这个系统能做什么。这个字段是 AI 判断我应该用这个系统来回答这个问题吗的主要依据描述模糊会导致 AI 在多个系统里选错。浏览几个服务端命令的详情文件确认参数的业务含义备注是否完整出现。如果发现问题回到第一步在工程里修改然后重新运行命令直到本体文件的质量达到预期。第三步部署本体文件本体文件生成之后需要把它部署到 Agent 服务器上。这个过程被整合到工作台的管理控制台 Web 程序中。你需要在创建或修改应用系统时提供最新版 Ontology 文件夹的压缩包。填写以下信息应用名称活字格应用的名称。因为这个名称会被拼接到Url中需要确保与实际部署环境完全一致Schema/地址/端口号内网里业务系统的访问地址比如http、192.168.1.50和80本体文件刚才生成的本体文件目录压缩成的zip包。填完提交建议你执行一次“连通性测试”确保应用地址无误。验证发一条消息试试注册完成后切换到 CUI 对话界面发一条简单的消息帮我查一下编号为 EQ-001 的设备最近一次维修记录。如果配置正确Agent 会在几秒内返回结果同时在管理控制台 Web 程序系统日志页面中查看这次操作的完整记录这次调用代表哪个用户、由哪个 Agent 执行、使用的是哪个本体版本、调用了哪个 TableBinding、白名单校验是否通过、传了什么参数、返回了什么数据。如果 Agent 返回我找不到设备管理系统或者无法确定应该用哪个接口通常是本体文件里的app-description描述不够清楚或者相关实体的命名和用户输入的词语之间语义距离太大。回到工程里调整重新生成本体重新部署再试一次。首次接入和版本更新的差异上面描述的是首次接入的流程。业务系统发版之后如果接口有变化需要更新本体流程和首次接入基本一样但有一个重要的差异不推荐直接修改本体文件。修改本体文件的问题在于它会和工程文件产生版本分叉。下次重新运行抽取工具时手动修改的内容会被覆盖之前验证过的用例可能失效用户看到的是一个之前能用、现在不能用的功能信任感的损耗比从来没有这个功能更难修复。正确的做法是在工程里修改调整命名、补充备注、更新服务端命令重新运行抽取工具生成新版本的本体部署到服务器的新版本目录通过注册表切换当前生效版本并触发 Agent 的本体缓存失效或重新加载。如果接口有不向后兼容的变更还需要在注册表里标记版本变化让 Agent 在下一次构建上下文时确定性地读取新版本而不是依赖一条提示消息提醒它不要使用旧本体。这条原则背后的逻辑是本体是工程的映射工程是唯一的事实来源single source of truth。所有改动都从工程出发本体跟着工程走而不是反过来。“3 分钟”的含义标题里3 分钟指的是工程治理完成、工作台基础设施已搭好、身份体系已对接之后的注册动作生成本体、部署文件、注册应用。在标准化环境里这三步可以压缩到几分钟内完成因为它们大多是确定性的操作。治理本身不在这 3 分钟里。对于一个已经有良好命名规范的系统治理投入通常是小时级别主要工作集中在枚举值的备注说明和表关联的补充。对于一个命名混乱、文档缺失的历史系统治理可能需要更长时间但这个时间的投入不只是为了 AI同时也是在改善系统本身的可维护性这一点第 24 篇会专门讨论。