模型能注册成功、能被调用，和调用起来顺不顺手，是两件事。
qModel 算法模型平台开源版发布 v1.4.3，改动集中在模型 API 调用前后的配置环节。业务逻辑没动，动的是”填参数”和”看结果”这两段最磨人的过程。
参数定义躺在接口里，用的人还得重抄一遍
一个稍复杂的模型，输入参数十几项到几十项很常见。每建一次计算任务、每做一轮在线测试，都得对着接口文档把参数名、类型、是否必填逐项敲进去。敲错一个字段名，调用就失败，排查还得从头对文档。
问题不在模型，在于已有的 inputSchema 只是接口注册信息，没有变成使用端能直接拿来用的配置。定义和填写之间隔着一层重复劳动。
把接口注册成可复用的参数源
v1.4.3 在”数据管理”下开了 API 接入入口，把接口注册信息和输入参数定义放在一处维护。登记接口名称、请求地址、请求方式、用途说明，再把参数定义录进去，这份定义就成了可复用的参数来源。
使用侧有两个落点。新建计算任务时进”数据绑定”区域，模型详情里做在线调试时进对应页面，点”选择 API”，弹窗里检索目标接口，选中即完成绑定。
绑定后平台读取该 API 已注册的参数定义，解析成参数表格。参数名称、是否必填、类型、说明由系统带出，用户只填值就能发起计算。
绑定关系变更也做了处理：取消 API 绑定，参数自动清空重置，不会残留上一次的选择干扰当前计算。
对参数多的模型，这一步省下的是逐项查阅和录入；对团队，参数定义统一维护在 API 接入管理处，接口定义变了改一处，不用在多个任务里重复改。
要分清的是，平台带出的是定义，不是值。业务参数仍需按实际场景填写，输入是否满足调用要求也得自己校验。这个功能优化的是配置过程，不是免掉参数准备。
返回一堆 JSON，字段含义靠猜
输入侧解决”怎么调”，输出侧决定”调完看不看得懂”。
API 接入的模型常返回多层 JSON。只给原始结构，业务人员看到 code、data、msg，再往下 data 里的 name、key、value，每个字段代表什么，得翻文档或问开发。
v1.4.3 加了输出结构定义 outputSchema，位置在模型配置的”结果定义”，用表格维护字段名称、示例值、用途说明。嵌套结构支持逐层展开，用户按层级对照查看，而不是面对一段没有解释的 JSON。
在线调试页面同步展示这份定义：左侧执行结果与日志，右侧结果定义表，边看实际返回边对字段说明。
业务人员不必读代码就能判断字段含义，字段疑问先查结果定义，少一次找开发的往返。调用出问题时，字段说明也是理解返回内容的参照。
边界要说清楚。outputSchema 是静态描述，适合返回结构稳定的接口。如果键名是动态生成的、数组元素结构不固定、或者字段随业务分支变化，静态定义就会失真，这时应以接口文档和实际返回为准，别把定义表当成唯一真相。它也不改变模型计算结果，替代不了对数据正确性和业务含义的判断。
配置完怎么验证？在线调试跑一次真实调用，逐层比对返回 JSON 的键路径与定义表中的层级是否一致，示例值类型与实际值类型是否匹配，嵌套层是否都能展开到叶子字段。任一项对不上，回去补定义，别急着交付给业务侧。
升级要动的三处配置
存量环境升到 v1.4.3，有三件事绕不开。
数据库脚本在项目 sql/mysql 目录。全新环境用 v1.4.3 初始化脚本；存量环境按版本递增顺序执行对应升级脚本，别把初始化脚本往老库上跑。执行前先备份，确认当前库版本号与脚本版本对得上，混用脚本是升级事故的常见来源。
新增了数据管理（API 接入）相关表结构和菜单权限，升级完成后重新登录刷新菜单。如果重登后新菜单仍不显示，先查角色是否被授予对应权限，再清浏览器缓存和会话，多数情况是权限未分配而非脚本没跑。
HTTP 请求方式字典统一改成大写展示：GET、POST、PUT、DELETE。只改展示，底层编码不变，已有配置不受影响。
存量模型的补配置建议
已经通过 API 接入的模型，建议补上输出定义。配置完成后，在线调试和结果查看就能用上字段说明，业务侧理解返回结构的成本会明显下降。
模型能对外提供服务只是起点。参数定义能不能复用、返回结果能不能读懂，决定了算法团队、业务人员和对接人员协作时要花多少沟通成本。v1.4.3 在这两个环节各补了一刀，调用逻辑本身没变。使用中遇到兼容性问题或有流程上的需求，走项目 Issues 反馈即可。
ID:7654
