InterSystems IRIS可以很容易以动态对象(Dynamic Object) 方式操作JSON，但动态对象没有 schema，DTL 图形编辑器里没有字段可以拖拽。本文介绍一个把 JSON 报文做成 Virtual Document 的实现（下文称 JVDoc）：schema 来自 JSON Schema 或样例 JSON，DTL 编辑器、规则编辑器、搜索表和校验都能直接使用，报文本身仍然原样保存、无损透传。文末给出可以直接运行的测试用例。  

问题

在集成项目里处理 JSON 很常见，动态对象(Dynamic Object) 来处理JSON也很好用，但它没有schema，带来三个麻烦：

• DTL 编辑器里没有字段树，无法简单拖拽建立映射，只能手写代码。
• 规则编辑器无法像实体对象那样获得属性列表，也无法像虚拟文档那样输入 Document.{ 得到字段提示。
• 消息查看器（Message Viewer）没法按报文里的字段搜索。

常见的办法是用 %JSON.Adaptor 生成类。它能解决图形化映射，但有两个代价：每条报文都要先实例化为对象，大报文成本高；schema 里没有的字段在导入时会被丢掉，做不到无损透传。

思路

IRIS的虚拟文档架构（Ens.VDoc.Interface）本来就是为没有对应类的结构化文档设计的：编辑器通过它取得字段树，运行时通过路径读写值。

要将一个 ObjectScript 类转化为一个能够调用工具、使用技能并委派部分任务的智能体，需要具备哪些条件？

我开发了“My First Agent Studio”，旨在让这个探索过程更加轻松。它包含小型原生 %AI.Agent 示例、终端演示、数据集，以及一个用于交互式测试这些代理的浏览器界面。除本地模型服务外，所有内容均打包在一个 Docker Compose 项目中。

该项目是我对InterSystems 社区奖励计划——第二轮的贡献。它融合了两个理念：

• “我的第一个代理”（端到端入门指南）：通过一个涉及工具、技能、外部 MCP 服务器和子代理的小任务来学习 SDK。
• 适用于 %AI.Agent 的通用智能体测试界面：选择一个现有的智能体类，并根据该类中定义的行为与其进行对话。

源代码可在“My First Agent Studio”代码库中获取，其中包含完整的配置说明和示例

本文重点介绍各组件如何协同工作。

项目运行原理

代理在 InterSystems IRIS 中通过 AI Hub 运行，而 Ollama 则提供 LLM。我选择 Ollama 是为了让开发人员无需付费模型 API 或云提供商的 API 密钥即可尝试这些功能。 您仍需具备足够的本地资源来运行所选模型，特别是对于工具和委托示例，请使用支持工具功能的模型，例如 Qwen 3.8。

在线体验：http://43.139.159.100:8082/paymentguard/

——仪表盘、REST API 与背后的互操作生产全程在线，灰色地带决策由 DeepSeek 实时作出。

本文是英文参赛文章的中文版。源码：github.com/Dylan5237/payment-guard-ai。

以下是正文：

支付授权，本质上是个决策问题。

大多数支付没什么可纠结的：老客户、熟悉的金额、常用的设备，几条确定性规则微秒级就能放行或拦下。真正难的是中间那片灰色地带——新设备、不常见的国家、比平时高出一截的金额、KYC 还没过审的客户。人工分析师的时间基本都耗在这里，而这恰恰是大模型 Agent 能帮上忙的地方——前提是它手里有真工具，查得到真数据。

PaymentGuard AI 做的事就这么直接：把一个真实的 IRIS AI Hub Agent（%AI.Agent）当成一个业务操作，塞进一条普通的互操作生产里。Agent 不瞎猜——它通过 AI Hub 的 SQL 工具直接查支付平台自己的 IRIS 库，查完按严格的 JSON 格式给结论；剩下的路由、审计、算 token 成本，生产全接管。

混合决策：规则打头，Agent 收尾

每笔支付进生产后走三段：

• 确定性规则先上。 制裁地区、黑名单、硬性限额、速率尖峰，命中即拦；完全可信的客户加小额加常用设备加本地，直接放行。

上一篇讨论了 AI 如何提出源数据到目标字段的映射建议。但映射本身并没有说明：运行中的集成如何读取一行数据、转换一条消息，或把请求投递到目标。

接下来要回答的是：应该由哪些组件来完成集成？这些组件又该如何组合？

在 DataPipelineDemo 中，管道规划师 Agent B 并不是从空白开始设计。平台会向它提供一组受控的组件类型、相关的管道设计知识，以及当前请求的集成需求。Agent B 根据这些上下文提出拓扑，平台再补充配置并检查结果是否可用。

本文沿着这条运行时路径展开。如何由开发者构建和登记组件定义、设计 Skill，将留给后续的开发者专题。

1. 映射和拓扑回答不同问题

已确认的转换映射描述信息应该如何对应。例如，如何把 SQL 中的 FamilyName 和 GivenName 组合成 SOAP 请求中的 FullName。

管道拓扑描述执行集成所需的组件，以及它们之间的关系。典型的 SQL→SOAP 数据流中，SQL Service 读取数据行，转换流程准备请求，SOAP Operation 再将请求发送到目标。

这两者缺一不可。映射合理，不代表已经具备数据流转路径；组件连接有效，也不能证明映射后的值符合业务语义。

2. 两类能力上下文

Agent B 会接收两类预先准备好的能力信息，它们回答的是相关但不同的问题。

类型注册表：有哪些可用组件类型？

为什么同一个人有两条记录，名字却不同？当相似的记录包含相互冲突的标识符时，系统应如何处理？当关键信息缺失时，系统应给出建议，还是应向来源方索取更多证据？

这些问题促使我开发了**“患者身份冲突审查助手”**。我希望在互操作性工作流中嵌入一个人工智能代理，供人工审查并可随时暂停。该代理负责收集证据并推荐处理方案；而人工审查员则负责授权记录之间的关联。

该应用程序使用了InterSystems IRIS Community AI Hub EAP 版本 154 中的原生 ObjectScript SDK。本文描述的是 pi-review1.1.0版本（提交编号 ab53930）。 所有案例和源数据均为合成数据，与任何医院均无关联。模型使用情况来自保存的实时呼叫记录。

项目链接：GitHub 代码库·Open Exchange 应用程序 (1.1.0)·带版本号的安装指南。下文所述的实现基于已固定的 1.1.0 源代码。

从一个缺失数据案例开始

合成案例 c6 最初缺少身份标识符和出生日期。一名操作员明确启动了调查。代理读取了该案例，验证了其来源，检索了治理规则，并返回了 NEEDS_DATA。随后，生产环境通过原生 MCP 请求了数据丰富处理。

当操作员获取数据丰富结果时，服务器在更新案例前检查了收据、来源范围和版本。随后，操作员显式地启动了另一项调查

大家好， 在本系列的第一部分中，我们构建了用于镜像、主节点、备用节点和仲裁器的三个容器，创建了镜像，并将备用节点加入其中。 本部分将从那里继续，此时两个故障转移成员均已定义，仲裁器即将启动。内容涵盖如何正确读取仲裁器的连接状态、一夜之间完全自动发生的故障转移，以及因我在测试前等待时间不足而导致的数据库成为孤儿的情况。第 3 部分将进入分片（Sharding）环节。

第 4 步：正确读取仲裁器的连接状态

在仅定义了主节点（Primary）的情况下创建镜像后，系统操作（System Operation）→ 镜像监视器（Mirror Monitor）页面立即显示仲裁器连接处于非活动状态。

初次看到这种情况时，可能会误以为是配置错误。但事实并非如此。 仲裁器的全部职责在于，当两个故障转移成员对对方是否仍处于活动状态存在分歧时，打破这种僵局。由于仅定义了一个成员，目前尚无需要仲裁的情况，因此该连接确实没有理由处于活动状态。这并非连接中断，只是在等待出现第二个成员以供参考。

当我在上一步中加入 mirror-backup 时，这种状态立即发生了逆转。

这一点值得亲自验证，而不是仅凭图表就轻信。动手搭建一下，观察同一 Portal 页面上的状态变化，仲裁器的实际作用范围就会一目了然——这是再多的文档阅读也无法完全传达的。

我很高兴向大家介绍 ascot——一款面向 InterSystems ObjectScript 的开源静态分析工具。

ascot 的核心功能之一是类型检查，它对控制流有着深刻的理解，包括涉及 $order、$data、for 循环、 条件语句以及后置条件。

此外，ascot 通过维护 ObjectScript 定义和引用的索引，帮助您浏览代码库。

ascot 专为人类和 AI 代理设计，通过 CLI、MCP 和 LSP 提供其功能。与InterSystems Language ServerVS Code 扩展的集成即将推出。

ascot 采用 Rust 🦀 编写，可在 crates.io 和 npm 上获取。

在 GitHub 上了解更多关于 ascot 的信息：https://github.com/intersystems-community/ascot

欢迎提交问题 🐛、提出功能请求 💡、贡献代码 🤝 以及点赞 ⭐！

InterSystems ObjectScript – 编码代理测试套件基准测试

在我们的首次基准测试中，我们对InterSystems 编码基准测试平台对 14 个 模型进行了测试。详细情况可见这篇文章：https://cn.community.intersystems.com/node/589834

但鉴于测试结果，我们决定通过四种编码代理进行同样的测试；我们对 Claude Code、Codex CLI、pi 和 prime-agent 进行了测试，并加入了一个名为 caveman 的变体。Caveman 旨在限制提示符的 I/O 令牌数量。

我们通过在运行中的 IRIS 实例中编译并运行代码，对代理的运行情况进行了验证。

结果

成本效益指数

该指数是我们新创建的指标，设定为60%的准确率和40%的成本效率。成本效率是以下四项标准化 任务指标的平均值：输入令牌、输出令牌、墙钟时间和IRIS编译调用次数。 控制行被排除在外。

InterSystems 技术分享线上课第 4 期回放现已就绪。

点击此处或扫码查看回放。

点击文章了解课程详情。

保障 InterSystems IRIS Superserver 连接的安全性：CVE-2026-111594

InterSystems IRIS 超级服务器是一个网络监听器，用于接受来自客户端和其他 IRIS 实例的连接。它支持通过 JDBC、ODBC 和本机驱动程序访问数据库，同时也支持 Web Gateway 通信以及镜像和分布式缓存等系统功能。 所有新的 IRIS 实例默认均启用了超级服务器；各个服务及其安全设置均可配置。

InterSystems 确认 MITRE 已发布CVE-2026-111594（https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-295-01），该漏洞涉及未加密的超级服务器通信。 我们感谢Abhinav Agarwal报告该问题并与我们合作。我们欢迎与客户及外部研究人员合作，以加强我们产品和部署的安全性。

要利用该已报告问题，攻击者必须获取通过未加密连接发送至超级服务器的身份验证流量。这需要访问通信路径或获取其他来源的捕获流量。重放该流量还需具备连接相关超级服务器服务的能力。重放成功后，攻击者将获得与捕获账户相同的权限。

InterSystems 建议将超级服务器客户端连接配置为强制使用 TLS，并确保客户端配置为验证服务器证书的信任链及服务器身份。

如果源表里有一列 FamilyName，而目标接口需要 FullName，集成程序应该怎么办？

可以因为两者都是文本，就把一个字段直接复制给另一个字段；也可以因为名称不同，就认为它们无法对应；还可以判断目标值可能需要由两个源字段组合而成——再确认这种理解是否符合当前集成场景。

这正是“匹配字段名称”和“设计数据映射”的区别。在 DataPipelineDemo 中，AI 会提出源数据与目标之间可能的对应关系；验证流程根据已有事实和约束检查这些建议；用户再审阅结果，并决定是否保存供后续管道生成使用。

1. 一条映射究竟说明什么？

这里有两个相关但不同层次的匹配：

• 资产匹配：哪个源对象应该对应哪个目标对象？例如，哪张 SQL 表或哪类 FHIR 资源应输入某个目标实体或资源。
• 字段映射：哪个源值应提供给某个目标字段？传递过程中是否需要转换？

因此，字段映射不只是两个名称的配对。它可以表示直接传值、组合多个值、提供常量，或执行术语映射等受控转换。源路径和目标路径固然重要，映射表达的意图同样重要。

2. 从相似名称到有意义的数据对应

字段名称是有用线索，但不能证明两个字段含义相同。两个都叫 Code 的字段可能属于不同编码体系或业务概念；名称不同的字段也可能表达同一个标识符。

结构和约束能补充更多上下文。目标可能要求必须提供某个值；字段可能需要日期、编码、引用或特定的 FHIR 路径。

大家好，

我们很高兴地宣布即将举办的下一场在线编程竞赛： 

🏆InterSystems 编程大赛：互操作性工作流中的 AI Agent🏆

比赛时间：2026年10月26日 – 11月15日（美国东部时间）

总奖金：12 ,000美元

不复制数据、不写同步脚本，在 InterSystems IRIS 上直接对业务对象做影响链分析与知识图谱分析

一、知识不只在“知识库”里

提到知识图谱，很多人的第一反应是：先建一个知识库，抽取实体和关系，再灌进一个图数据库。这条路没有错，但它默认了一个前提：知识是“另外一份东西”，需要单独采集、单独存放。

现实里，企业最有价值的知识往往早就躺在业务数据中了：

• 采购单引用了供应商，供应商引用了所在国家；
• 货运装在集装箱里，集装箱装在船上，船执行某个航次，航次经过一串航段；
• 病人有基因变异，变异落在某个基因上，基因参与某条通路，通路关联某种药物的代谢。

这些引用关系本身就是知识。每一个外键、每一个 Relationship、每一个对象引用，都是一条潜在的边。传统做法是把这些数据 ETL 到图库里再分析，代价是数据复制、同步延迟，以及一套额外的运维体系。

这里实现的IRIS Graph 子系统走另一条路：直接把业务对象的引用属性投影（projection）成图的边，边随对象的保存、更新、删除自动维护，业务表/对象依然是单一事实来源。这样不需要复制数据，就能立刻在业务数据上做影响链分析、可达性分析和知识图谱分析。

当然，传统知识库（文档、概念、实体）一样可以进图。同一个引擎同时支持两种来源，查询方式完全一致。下面逐一介绍。

注意，它不是InterSystems IRIS的官方特性。

我们的承诺

为了营造开放、友好的环境，我们作为参与者、版主和 InterSystems 员工，承诺让每个人都能在不受骚扰的情况下参与 InterSystems 开发者生态系统，无论其年龄、体型、残障情况、族裔背景、性别认同及其表达、经验水平、国籍、外貌、种族、宗教信仰、性身份认同或性取向如何。

我们的标准

我们希望所有贡献和互动都保持尊重与建设性，即使参与者意见不同或提出批评性反馈，也应如此。

有助于营造积极环境的行为示例包括：

• 使用友好且包容的语言
• 尊重不同的观点和经历
• 以尊重的态度给予和接受建设性反馈
• 以社区的整体利益为先
• 体谅其他社区成员

参与者不可接受的行为示例包括：

• 使用带有性暗示的语言或图像，或进行不受欢迎的性关注或性挑逗
• 恶意挑衅、侮辱性或贬损性评论，以及人身攻击或政治攻击
• 在公开或私下场合实施骚扰
• 未经明确许可发布他人的私人信息，例如住址或电子邮箱地址
• 威胁、恐吓、歧视性辱骂，以及反复进行对方不愿接受的联系
• 其他在专业环境中可被合理视为不当的行为
• 垃圾信息、欺诈性提交、操纵投票、评分、积分或奖励，以及滥用 Developer Community、Open Exchange、Ideas Portal 或 Global Masters 的其他行为
• 报复善意提出疑虑或参与相关审查的人

反馈与投诉

我们欢迎对 InterSystems 产品和服务提出尊重且具有建设性的反馈，包括批评和问题报告。

使用 Claude Code 实现基于 InterSystems 的 AI 辅助开发

Claude Code 是一款非常实用的工具。它能帮助解释方法、追踪 SQL 查询（获取结果甚至设置新值），或为代码提供修复/更新建议。
但要充分发挥其最佳效能并实现成本效益，仅靠让它解决问题是不够的。为了让 AI 更高效（且更安全），你还需要决定允许它修改哪些内容（就我而言，在我亲自审查其建议的修改并检查受影响的文件之前，不允许它进行任何修改）， 它所需的上下文大小（主要由所用模型决定），以及该任务应投入多少推理精力（这会影响推理的深度，以及令牌的生成/消耗，从而影响成本）。

上下文压缩

随着对话规模的扩大，Claude Code 最终需要压缩其上下文（大多数模型的限制约为 100 万个令牌）。它会总结之前的对话内容，为后续对话腾出空间。 问题在于，摘要可能会遗漏你仍认为重要的内容，例如已被否决的方案，或是“不要触碰特定组件”之类的指令。

虽然 MEMORY.md 文件有所帮助，但它并不能保证每条指令在整个会话中都可用或被遵循，因为 Claude Code 只会自动加载其内存索引中的一小部分。
因此，你需要将最重要的指令放置在项目根目录下的 CLAUDE.md 文件中，因为该文件会在压缩后重新加载，而一些嵌套指令仅在需要时才会被重新加载。

Hi 大家好！ 

InterSystems技术分享线上课第四期来啦！这期课程我们将聚焦“定时任务的配置与监控”这一主题。

连接测试可以告诉我们服务器有响应，数据库结构可以告诉我们某列名叫 Code。但仅凭这两点，我们仍不知道这个编码代表什么，也不知道它是否应该映射到某个目标字段。

可靠的数据集成设计，要从这里开始。在决定哪个源资产对应哪个目标、哪些组件应组成一条数据管道之前，我们需要先理解接口——不只是接口的结构，还要理解这些结构在具体场景中的含义。

本文介绍 DataPipelineDemo 在 InterSystems IRIS for Health 上如何处理这个问题。核心原则是语义优先：先理解接口表达的含义，再做映射与管道设计决策。

这里的“语义优先”指的是下游决策顺序，并不是先让 AI 凭空猜测、再去看接口。实际流程是先采集结构和运行事实，再由大语言模型（LLM）基于这些事实进行解释，最后将分析结果作为后续决策的上下文。

1. 端点可达，不等于接口已理解

连通性是必要条件，但它回答的问题很有限：当前应用能否访问这个端点？

它无法证明：

• 某张源表或某类 FHIR 资源在业务领域中代表什么；
• 某个字段是标识符、状态、编码值，还是显示名称；
• 某个操作用于读取数据，还是用于接收并写入数据；
• 端点是否支持增量读取或特定的投递机制；
• 结构上合法的映射是否保留了原本想表达的业务含义。

这些问题不同，需要的证据也不同。

2026年，InterSystems在在首次发布的《Gartner Magic Quadrant：企业级电子健康档案》中位列“领导者（Leader）”。入围“领导者象限”的机构，不仅在当前愿景落地上执行力出众，更在未来布局中占据有利身位。对我们而言，此项认可既契合、也印证了我们的AI原生EHR的能力，验证了我们的EHR产品战略，更彰显了InterSystems对创新与可信赖伙伴关系的坚定承诺。

点击此处，申请查看《2026 Gartner® Magic Quadrant™：企业级电子健康档案》完整报告与评分依据。

我们很高兴宣布发布InterSystems Supply Chain Orchestrator™ 社区版（SCO CE）。此免费版本使社区成员能够探索、评估、学习并使用 SCO 进行开发。

SCO 社区版 (CE) 提供了 SCO 的全部功能，但与完全授权的 SCO 部署相比，存在某些技术限制。每个版本都包含一个内置许可证，自发布之日起有效期为一年。我们计划在未来每次发布 SCO 时，同步提供 CE 版本。

获取 SCO 社区版

SCO CE 作为容器形式发布在InterSystems 容器存储库中。请访问该存储库查找并下载 SCO 社区版。

有关 CE 限制的完整详情，请参阅SCO 社区版文档。

从社区获取帮助

SCO CE 用户无法获得标准的产品支持，因此我们建议您通过开发者社区提出问题并寻求社区帮助。

立即开始使用 SCO CE 探索 Supply Chain Orchestrator！

LLM 可以建议把某个源字段映射到某个目标字段。这很有用，但还不能称为完成了一次数据集成。

接下来，还需要建立连接、理解目标约束、选择并连接组件、启动管道，以及检查数据到底有没有正确到达目标。

Quickstart 介绍了运行在 InterSystems IRIS for Health 上的 DataPipelineDemo。这一篇往前走一步：解释集成需求与平台能力，如何共同变成一条可运行、可验证的数据管道。

核心并不是“让 AI 写出所有东西”，而是：

让 AI 在明确边界内做集成决策，再让这些决策能够被执行、被观察、被验证。

1. 一个系统，三个阶段

整体链路可以概括为：

图 1：三个阶段；虚线反馈表示按适用路径做限定范围的修复，然后重新验证。

但这条链路包含三个不同的阶段。

设计与生成阶段，产出接口模型、字段映射、组件拓扑和 Production 定义。AI 参与语义分析、转换映射与管道规划。

运行阶段，源数据通过业务服务、转换流程和目标操作流转。已有组件执行确认后的转换指令，正常数据链路不会为每一行数据或每一条 FHIR 资源重新调用 LLM 做语义判断。

验证与反馈阶段，检查生成配置与运行证据；发现问题后，按适用路径修复映射或管道，再次验证。

这一区分很重要：AI 参与决策，IRIS 承担运行。例如，消息处理过程中查询术语映射，查的是术语服务器，并不是每次都让 LLM 重新判码。

2.

大家好， 

“使用 InterSystems 嵌入式分析”在线课堂课程尚有名额！  

详情 

• 日期：2026年11月16日至20日（5天）
• 地点：线上，美国东部时间上午9:00至下午5:00

本课程适合人群：  

• 本课程适用于 InterSystems IRIS® 数据平台、InterSystems IRIS® for Health 以及 HealthShare® Health Connect 的用户。
• 本课程同样适用于旧版产品 InterSystems DeepSee 的用户。

您将学到： 

• 本为期5天的课程旨在指导开发人员和商业智能用户如何利用InterSystems IRIS®商业智能将实时分析功能嵌入其应用程序中。
• 本课程介绍了如何使用 InterSystems IRIS BI Architect 从事务数据构建数据模型的基础知识，如何使用 InterSystems IRIS BI Analyzer 探索这些模型并构建数据透视表和图表，以及如何创建仪表板来展示数据透视表、仪表和其他交互式控件。 
• 课程还涵盖了如何利用 InterSystems® 安全基础设施对模型、工具及元素（仪表盘、数据透视表等）进行安全保护。 
• 此外，本课程还将介绍用户门户的自定义、故障排除和部署等主题。

请在线注册本课程。  

让 AI 接手数据集成：几分钟里跑起来

一句话速览：登记数据源、选择目标，再让 LLM 设计数据集成流程。一条命令启动演示环境，再运行一条命令，就能端到端复现完整的数据管道。

git clone --recurse-submodules https://github.com/zlnick/DataPipelineDemo.git
cd DataPipelineDemo
bash tools/setup.sh && python3 tools/e2e_ui_flow.py

↑ 一次干净克隆环境中的实测：、验证通过，数据已写入目标 FHIR 仓库。

这是什么

这是一个运行在 InterSystems IRIS for Health 上的完整演示：由数据源出发，自动生成并运行互操作性数据管道，其中的关键决策由 AI 完成。

• 数据源（2 种）：FHIR 接口、SQL 表
• 转换目标（3 种）：数据库表、SOAP 服务、FHIR 仓库
• 支持多种源与目标组合，也支持在同一个 Production 中运行多条数据管道
• 提供中英双语界面：默认中文，英文界面位于 /en

一套 IRIS 实例同时承担多个角色：FHIR 服务器（包含相互独立的源与目标两个仓库）、互操作性引擎（Production）、SQL 数据库，以及平台自身的元数据存储。

在基于 InterSystems IRIS 数据平台开发解决方案的这些年里，我已实现了数百个与 REST API 的集成。而 IRIS 端涉及的 API 数量也不在少数！但在本文中，我想专门谈谈 REST 客户端。更确切地说，我想分享我尝试创建一个适用于所有 API 的通用客户端的经历。

将人工智能代理连接到数据库固然有用，但这立刻引发了另一个问题：应该允许该代理读取哪些内容？

在这个项目中，我希望在应用程序代码中做出这一决定。代理可以使用几个过滤条件搜索患者记录，检查一个已批准的全局变量，并检索有关 IRIS 命名空间的基本信息。它不能提交自己的 SQL 查询，也不能选择其他命名空间。

这个项目是什么？

我为 InterSystems社区奖励计划“从构想到应用”（第二轮）开发了MCP 数据暴露工具包，以响应MCP 数据暴露工具包的构想（DPI-I-985）。 我的贡献是一个可运行的 ObjectScript 示例，涵盖了 SQL、全局变量和命名空间监控。

源代码已在GitHub 上发布。本文将演示该示例的运行过程，并深入解析其背后的代码。

示例公开的内容

我选择了合成医疗记录，因为它们既提供了有用的搜索条件，又避免了将真实的患者信息存储在存储库中。该项目从Kaggle 上由 dnation 发布的“合成医疗患者记录数据集”中导入了 500 条记录。持久化类 MCPData.Data.Patient 用于存储这些记录。

简而言之：

omniEmbedding 是一个 100% 基于 ObjectScript 的网关，它将来自 10 家不同提供商（Ollama、OpenAI、Azure、Cohere、Gemini、Mistral、Voyage、 Jina、Bedrock、VertexAI）的嵌入数据，将其集中管理于 InterSystems IRIS 平台内，因此您既不会被锁定在单一提供商，也不会因在 RAG 管道中混合使用不兼容的向量而陷入困境。

我的想法并不是要锻造“至尊戒”——这事儿就留给托尔金和索伦去搞吧，😅。

事实上，原生类 %Embedding 和 %Embedding.OpenAi 让任何在 InterSystems IRIS 上进行向量搜索的人都轻松得不可思议。

不过，去年我不得不整合一个必须完全依赖 Azure OpenAI 平台的项目。情况变得有些复杂。我不得不对解决方案进行定制（在此要特别感谢 @Alex Woodhead在社区帖子中提供的关键帮助）。

现向大家介绍omniEmbedding：一个精简的、100% 基于 ObjectScript 的网关，用于在 10 家不同的 LLM 提供商之间路由嵌入向量。

方法论：基于规格的开发与人工智能

该项目的真正差异化优势在于其背后的工程实践。

在 4.0.0 发布一周后，SQL DATA LENS 4.01 于 2026 年 8 月 30 日正式发布——这是一次重大版本更新，而非补丁更新。 其78项变更中的大部分都围绕一个主题：如何建立、保护和标记与IRIS或Caché的连接。本文将带您了解对于日常使用InterSystems数据库的用户而言最重要的部分，首先从我被问及最多的那个问题开始。

问题在于：对于 InterSystems JDBC 客户端而言，TLS 配置从来都不是“只需勾选一个复选框”就能解决的

如果您曾使用 TLS 保护过 IRIS 超级服务器，然后尝试让 Java 客户端与其通信，您一定深有体会。在客户端，您需要

• 一个SSL 配置文件（即 InterSystems JDBC 驱动程序读取的 SSLDefs.ini- 风格的属性文件），
• 一个使用 keytool 构建的信任库，其中包含服务器或 CA 证书，
• 主机名验证必须与证书 SAN 字段中的 条目完全匹配，
• 以及重启客户端以验证上述操作是否生效。

社区中有关此主题的优秀文章不少——Mauro Aguirre 针对 ODBC/JDBC 客户端的分步指南以及Eduard Lebedyuk 的 Tableau 操作指南都值得一读。但这些文章之所以需要存在，且篇幅长达 6 到 13 分钟这一事实，本身就说明了一些问题。

今天外面天气真好，南半球，尤其是悉尼，终于迎来了春天， 但上周我和同事们在黑山度过了愉快的时光，庆祝Banksia成立五周年，回来后我严重时差反应，再加上还在对抗感冒症状，所以现在还是静静地坐在电脑前比较好，而不是去外面寻找新的疯狂冒险。 还有什么比浏览社区帖子更能让这段时间物有所值呢？

其中一篇特别引起了我的注意，那是@Nicholai.Mitchko关于大语言模型（LLM）代理编码基准测试的精彩研究与文章——如果你还没读过，不妨先去读一读。 研究结果基本印证了我的经验感受——在IRIS编码方面，Claude系列模型表现大同小异；正因如此，如今我进行编码任务时几乎只使用Sonnet，而OpenAI的模型虽然稍逊一筹，但依然表现不俗。 不过有一个意外发现：DeepSeek V4 Flash模型，其排名几乎与Claude持平。这激发了我尝试DeepSeek的兴趣。正如我的同事@Aleksandr Kolesov在他最近的文章中所指出的，在大型语言模型（LLM）领域，即使全力以赴，也只能勉强维持现状。

安装

Nicholai 使用的是自托管的 DeepSeek，慷慨地将其成本标为 0 美元，但我的这台“强悍”的 MacBook Air 在性能方面肯定表现不佳，所以今天我们将使用托管版本。

步骤 1：配置三个容器

docker login -u="your-username" -p="your-token" containers.intersystems.com

然后拉取镜像:

docker pull containers.intersystems.com/intersystems/irishealth:2025.3

我一直以项目经理的身份参与 IRIS Relay，目前仍担任这一角色。我的工作是跟进项目的开发，寻找有助于提升成果质量的文档、资源和工具。这种参与贯穿整个项目：包括跟进各项功能及其验证，以及持续改进的机会。

班次之间的连续性

在 Relay 中，我认为最有用的是班次之间的连续性。接手运维的人需要了解之前的背景、已共享的信息以及所做的变更，还需要确认这些变更是否确实已经应用。

对我来说，这种确认至关重要。记录变更与核实其结果是工作中相辅相成的两个部分：二者结合，有助于在责任从一个团队转交到另一个团队时减少风险和问题。这就是我在项目中追求的一致性，用以支持交接班期间的运维稳定。

在 Relay 中，这些背景信息可以导出为交接报告。不过，会话历史并不是永久的审计追踪；要保留这些背景信息，就需要保存导出的文件。这一区别界定了该工具目前所能提供的能力范围。

质量与后续计划

功能验证、安全性、一致性和持续改进是我最看重的方面。我的目标是让开发工作在项目演进过程中始终保持这些标准。

我接下来希望改进的是性能。我打算跟进实际使用需求，引导持续改进，在保持我认为对 Relay 至关重要的一致性的同时，力求取得尽可能好的结果。

了解项目

• GitHub 上的代码和文档
• Open Exchange 上的 IRIS Relay
• 0.3 版本演示视频