#API

引言 - ObjectScript 中的人工智能流问题

今天，我想介绍一下我在将 AI API 集成到 ObjectScript 应用程序时遇到的一个问题以及找到的解决方案。我最初的测试很成功，但也有些令人沮丧。

HTTP 调用成功了；请求正确地发送到了我的 LLM API。但随后，沉默......漫长的等待。最终，整个响应以单个块的形式到达。

从技术上讲，它成功了，但与 ChatGPT 会话相比，用户体验令人失望。

现代模型设计为逐个令牌流式输出。这使得等待时间大大缩短，因为即使尚未生成完整的答案，您也可以开始读取响应。 要启用此行为，只 需向 API传递 stream=true。 不过，在这种看似简单的操作背后有一个重要的细节：流媒体依赖于服务器发送事件（Server-Sent Events，SSE）。

如果不支持客户端 SSE，就无法利用这种模式。

对于通常在 ObjectScript 中使用的 %Net.HttpRequest 类，响应会被缓冲，直到连接关闭。换句话说，没有增量读取，没有渐进标记，因此也就没有流。

如果我们希望将 LLM 集成到 IRIS 应用程序中，那么能够处理 文本/事件 流、即时解析事件和实时处理数据是至关重要的 。

我们一开始并没有大的人工智能战略。

我们有一个传统的 InterSystems Caché 2018 应用程序、大量老旧的业务逻辑和一个实际需求：构建一个新的用户界面并改进已运行多年的代码。起初，我认为人工智能编码代理只能帮助完成一小部分工作。也许是一些模板、系统周围的一些 REST 工作，以及帮助阅读旧的 ObjectScript。

但实际上，它的作用远不止这些。

当我们开始认真使用它时，我们意识到它可以跨越庞大的代码库，理解模式，提出重构建议，并帮助我们以比我预期快得多的速度实现 Caché 的现代化。但这只是在开始时经历了一段令人沮丧的时期之后才发生的。

真正的挑战不是获得代码建议。而是教会代理我们的 Caché 环境如何实际运行。

我们为什么能使用它

在进行任何技术工作之前，我们必须回答一个安全问题。

我们不能将企业资源规划代码和内部业务逻辑直接发送给公共人工智能服务，并寄希望于最好的结果。这样做永远无法通过严格的安全审查。

亚马逊 Bedrock 改变了我们的想法。我们的服务器、数据和开发环境已经在 AWS 中，因此 Bedrock 可以很自然地融入我们已经信任和管理的云环境。我们可以使用该模型，同时将流量、访问控制和周边安全控制保持在我们已经在使用的 AWS 框架内。

痛点所在

我们在将 IRIS 实例迁移到另一台机器（甚至可能是升级版本）后，有多少次是在几天之后才猛然惊觉：我们忘了迁移那个对于业务操作（Business Operations）至关重要的 SSL 配置？或者是漏掉了某个凭据（Credential），又或是某个包里孤零零的一个类？

解决方案

最简单的法子就是列一张清单¹。把我们必须迁移的实体项都罗列出来。但是，Word 文档里的简易清单往往会被人抛诸脑后，甚至干脆被无视。

管理学的基本原理告诉我们：如果你希望人们遵循流程，你可以采取以下手段：

1. 通过监控行为来强制他们执行；
2. 将某项活动系统地锁定在某个流程之后（例如使用流水线部署代码，并要求自动化测试通过才能合并 PR）；
3. 让流程比人工操作更便捷、更省力。​ 这样人们才会心甘情愿地去用。（这正是我的目标所在）

Python 脚本固然可行，但人们可能会忘记脚本放在哪儿，或者去哪儿下载。一旦有了新版本，所有使用者都得重新下载。

IRIS 类或任务似乎也是理想选择，直到你意识到有时你是迁移到另一个网络的服务器，一个实例根本无法访问另一个。

这就是为什么我选择了浏览器插件一旦安装，它便触手可及（哪怕你几个月不用它）；更新会自动完成。即便你换了浏览器或出于某种原因弄丢了插件，从应用商店重新安装也只是点击一下的事。