从内嵌助手到独立 AI 平台：一次架构演进的复盘

最初的目标是让用户通过对话查询设备数据。后来，目标变成让不同业务系统的能力进入同一个助手。看起来只是“多接几个接口”，实际改变的是工具来源、配置方式、部署边界和执行责任。

更新于 2026-09-09。本文按历史阶段组织，结合 2026-08 的平台里程碑与 2026-09-07 的产品评估记录；当前架构另见工具接入与运行架构。

第一阶段：在具体业务里理解工具调用

工业系统已有设备、点位、历史和告警服务，最小助手可以通过 Spring AI 将这些查询包装成工具，通过 SSE 返回回答。这个阶段复用本地 Service，部署简单，也便于观察模型究竟缺少什么信息。

我很快发现，接口能返回 JSON，并不等于模型能正确解释它。一个字段至少可能需要：业务名称、单位、采样时间、数据来源、可查询范围，以及下一步操作所需的标识。

例如，“当前温度”与“过去一小时平均温度”不是同一个工具调用。内存缓存只有近期数据时，提示词不能让它变成完整历史库。这个经验后来推动了历史查询来源标记和语义说明的完善。

第二阶段：抽离业务依赖

我把对话编排、工具契约和业务访问适配分开，让模型相关代码尽量不直接依赖设备实现。这样，后续可以把本地调用替换为远程能力。

早期文档曾用“零重写”等比例描述抽离收益，这种说法缺少可验证依据。真正有效的约束是：哪些包允许依赖业务类型，业务 DTO 是否混入运行时，会话和工具的错误语义是否独立。

从进程内调用变成远程调用后，还会新增序列化、认证、超时和失败状态。接口名字保持相同，不代表行为没有变化。

第三阶段：独立部署仍然可能只是定制助手

把 AI 放到独立应用后，如果工具清单、角色和系统地址仍冻结在 Java 代码里，接入新场景仍需要改代码和重建部署物。

2026-08 的 V2 审计正是据此重新对齐目标：平台应让 Agent、工具绑定和模型档案参与配置，而不是只把部署目录拆开。

配置化并不消除接入工作。非标准鉴权、模糊接口说明和业务实体关联，仍需要适配与验证。它减少的是重复编写相似胶水代码的需求。

第四阶段：从两条调用路径收口到统一工具池

MCP 工具与 HTTP 工具统一进入 tool_definition。平台根据执行器配置构造回调，模型使用统一的工具描述，远端差异由执行器处理。

这一步的难点是旧路径清理。若同一能力既能通过手写 Bean 注入，又能通过注册行动态构造，测试通过可能只说明其中一条路径正常。平台实施记录中，退役旧包装、收编存量工具时，就暴露过参数类型保持问题。

这个经历让我更重视“只有一条权威装配路径”。共享命名规范有价值，但仅统一名字不够，发布状态、绑定和执行日志也必须对应同一条路径。

第二系统验证了什么

P4 演练使用一个独立的资产示例服务，提供 8 条内存只读资产记录，与工业设备构造名称关联。记录中的查询流程是：告警取设备名，资产检索取编码，再查询档案并汇总。

它证明了系统登记、工具装配和跨系统参数接力具备演练路径。停用资产系统后，工具集收缩，回答也应说明能力减少。

但示例服务不是客户 ERP，预先对应的名称也不足以证明复杂实体消歧。真实接入还会遇到同名资产、编码迁移、单位不同和权限差异，必须用目标业务的数据验证。

工具数量不是唯一优化指标

导入接口后，很容易得到一大批相似工具。合并列表与详情、减少重复描述有帮助，但把工具压到某个数量以内不应该牺牲可区分性。

P6 记录中，原先“收敛到不超过 15”的目标最终按具体规范修正为约 30 的机械下界。这不是一个普适数字，而是说明接口结构和合并条件限制了数量优化。

我更关心模型是否选对工具、参数是否准确、失败是否可定位，以及完成一次问题需要多少调用。若合并后只有模型更难判断，数量减少并不是成功。

下一阶段从回答正确走向执行正确

2026-09-07 的修复记录包括批准凭据的会话隔离与原子消费、MCP 错误识别、参数类型保真，以及最小身份登记与写权限检查。

这些是具体进展，但聊天记录持久化仍不等于任务恢复。规则保存成功后响应丢失、批准后服务重启、保存成功但启用失败，都需要运行时记录确定的状态。

模型适合理解请求、选择能力和组织回答；授权、已批准参数、幂等和结果核验应由程序约束。后续重点是让一个具体任务可以解释地完成，而不是先增加更多 Agent 或更复杂的画布。

这次演进留下的判断方法

我保留独立平台、统一工具池与配置化 Agent 的方向，同时收回“任意系统零适配”“一次确认即可生产可用”等过强结论。判断平台是否前进，应看新系统接入时少写了什么代码、实际问题如何完成、失败后能否说明发生了什么。

想先看两个系统的关系，可以阅读项目全景；想看当前管理流程与运行流程如何分开，可以继续阅读AI 平台架构。