摘要

  • LACNIC 发布的 pai-auth-ws-client 1.6.0 新增了 AI 用途解析和聊天两个调用，两个结果类型都会给出供应商与模型信息。
  • 公开 Java 合同没有让两个调用共享解析 ID 或配置版本，因此调用者不能仅靠这套类型，把预先查看的配置状态与随后收到的答案绑定成同一份证据。

先把最有力的辩护摆在前面：这不是一个毫无约束的 AI 接口。1.6.0 版 README 写明，调用者需要持有带 portal-ai-gateway 角色的 PAI Bearer 令牌，来源 IP 还要列入 AI_LLM_WS_IP_WHITELIST。新客户端采用标准 TLS 与主机名校验，给 use 做单一路径段编码，连接超时固定为 5 秒，响应超时为 90 秒；超时会明确返回 504 和 gateway_timeout。聊天结果还会留下用途、供应商、模型与耗时。这些都是真实的工程进步。

客户端也没有义务复制服务器的全部审计系统。它应该轻，不能为了“可追溯”就把凭据、完整提示词或内部策略都暴露给每个集成方。公开仓库没有告诉我们网关如何记录日志、调用应用还保存了什么，更没有证明 1.6.0 已在哪项 LACNIC 生产服务里运行。两份 Java 数据类里没有某个字段，绝不等于其他层面也没有。

本文只处理一个更窄的问题。1.6.0 把一次选择拆成了两个可见时刻。应用先调用 resolve(token, use)，查看某种用途会解析到什么配置；之后再调用 chat(token, use, messages)，把同一用途与消息交给网关。README 特别说明，use 由调用应用定义，客户端只负责转交。

AiResolveData 给出的信息并不少：用途、供应商、模型 ID、模型标签、是否启用、超时秒数和凭据名称，再加成功状态、HTTP 状态和错误。聊天侧的 AiChatData 则返回正文、用途、供应商、模型 ID 与延迟。也就是说，一条被保存的答案并非完全来历不明；至少可以读出网关声明由哪家供应商、哪个模型处理。

缺少的是“这一次解析”的身份。两个公开类型都没有 resolutionId、configurationId、配置版本、请求 ID、追踪 ID 或共同的关联 ID。PortalAiClient 的聊天请求也不会接收前一步解析对象或其中产生的不透明票据，只是重新发送 use 和消息。

供应商与模型既然重复出现，为什么还不够？因为描述相同不等于状态相同。解析类型自己已经说明，一套配置不只有模型名称，还包含启用状态、超时和凭据名称。两个配置版本可以继续选择同一供应商、同一模型，却改变另一项控制；use 的映射也可能在两次请求之间更新。公开代码没有证明这些变化发生过。它只证明，一旦发生，两个相同字符串无法识别到底执行了哪一版。

设想应用在 10:00 查询一项摘要用途，得到供应商 A、模型 B、超时 60 秒；10:01 发起聊天，结果仍写供应商 A、模型 B。这个吻合很有价值，却只能说明若干属性相等。若期间配置由第 17 版变成第 18 版，而两版使用同一个模型，调用者不能用公开对象证明答案属于第 17 版还是第 18 版。它有两张相似的快照，却没有同一张收据。

这不是在指控竞争条件，更不是安全漏洞。服务器完全可能在聊天请求内部原子化地完成解析与执行，并保留完备追踪；调用方也可能自行注入请求标识；私有文档还可能给出公开仓库没有的保证。证据边界必须双向约束：看不见不能被写成不存在，同样也不能被自动当作已经存在。对于只拿到 1.6.0 公共 Java 合同的集成人员，当前可保存的证据就止于这些字段。

版本时间使这个问题值得现在提出。GitHub 显示 1.6.0 于 2026 年 9 月 12 日发布。发布说明称，Java 17 环境下的 Maven 全套 59 项测试通过，项目结构校验也通过。1.5.1 到 1.6.0 的比较 显示新标签领先 8 次提交，其中一项加入 AI 网关客户端，随后一项加固调用。这不是从陈旧代码里挑一个角落，而是在公开接口刚刚成形时检查它的证据能力。

PortalAiClientTest 很清楚地展示了维护者要稳定什么：Bearer 令牌是否送出、供应商和模型能否解析、带 /、?、# 的 use 是否仍被编码成单一路径段、角色消息能否序列化、空用途是否拒绝、超时是否变成 504，以及旧 PortalWSClient 门面能否正确委托。这套测试具体而有用。没有测试把解析身份带入聊天，是因为公开接口尚未提供这种身份。

最小改动不是把两个端点强行合并，也不是把内部策略摊开。resolve 可以返回一个不透明的 resolutionId 或 configVersion。严格模式下，聊天请求携带它；若配置已过期或改变，网关明确拒绝并要求重新解析。建议模式下，网关仍可为了可用性采用当前配置，但要在结果里返回实际使用的标识。不同应用可以选择不同权衡，关键是别让“预览”看起来像“锁定”。

一张私有的模型解析收据不必很重。解析标识绑定用途、策略或配置版本、供应商、模型、解析时间和调用请求；聊天完成后再记实际标识、响应时间、延迟、状态、重试或缓存情况，以及提示词、证据包和结果的哈希。哈希可用于核对同一性，而无需公开敏感正文。凭据值根本不该写入收据。

它也不能证明模型正确、公平或适合某项业务。收据只回答更基础的问题：哪一个控制状态产生了这份输出？模型目录是一项路由意图，返回内容是一项运行事实。若两者之间的身份只能靠猜测，审计就会先在最简单的一步失去抓手。

这项改进也保护 LACNIC。没有共同标识时，调用者遇到异常答案，很容易怀疑网关悄悄换过配置，即使事实上从未改变。有收据以后，LACNIC 可以证明查询、执行和返回字段属于同一条轨迹，或准确指出在哪里分叉。可核实事实越多，责任边界反而越窄。

本文没有重写此前关于 PAI 客户端 Java 8 文档与 Java 17 构建字节码不一致的调查。那篇文章处理的是运行兼容性。这里先假定客户端能够运行，再问它留下什么决策证据。一个问题是“能不能启动”，另一个问题是“事后能不能说清网关实际用了什么”。

来源