在线演示：https://niutics.pl/interSystems（请使用 demo / demo 或 operator / 以获取受限角色) · GitHub：https://github.com/DawidKrynski/iris-admin-deck· Open Exchange：https://openexchange.intersystems.com/package/IRIS-Admin-Deck

视频，时长3分钟：https://youtu.be/gUsxZi-uAD4

IRIS 2026.2 版本新增了 SysAdmin REST API，即 。其 OpenAPI 文件包含 190 个路径和 273 个操作，涵盖了我通常在管理门户中进行的大部分操作。 为了参加*“构建你自己的管理门户*”竞赛，我基于此开发了 IRIS Admin Deck：这是一个由 IRIS 从 提供的单页应用，采用纯 ES 模块，无需构建步骤，也没有运行时依赖项。

1.0.1 版本已于今日发布。以下是该应用的功能介绍、我对该 API 的认识，以及其目前仍存在的不足之处。

一个值班的早晨

我开发这个工具是为了帮助那些在实例出现故障时接到通知的人。演示数据中包含一个小故障案例，您可以在在线演示中跟踪该案例：

PEP 578引入了 Python 审计钩子。各种事件（如模块加载、操作系统交互等）都会触发审计事件，您可以订阅这些事件。

具体操作如下。首先创建一个嵌入式 Python 钩子：

Class/// do ##class(User.Python).Audit()ClassMethod

在此示例中，我们将：

• 如果numpy 开始 加载，则终止进程
• 输出编译/执行事件 及其参数
• 忽略代码事件
• 记录所有其他事件

所有这些内容都将写入默认的 STDOUT。

要开始审计，只需调用此方法注册您的钩子即可，或者您甚至可以在任务启动时自动完成此操作：

JOBnew

以下是输出示例：

>> import json

我发现这对于调试很有帮助。

人脸识别已成为验证个人身份最广泛采用的方法，从而能够实现系统访问、个人及文件数据的核验，以及对操作和文件的审批。
相关挑战主要涉及数据库规模庞大时的性能表现、识别准确率，尤其是生物特征面部数据的隐私保护。面对这些挑战，InterSystems Vector Search 无疑是最佳解决方案，因为它能够：

1. 在数百万条记录中执行向量搜索，响应速度远快于传统方法。
2. Vector Search 所采用的向量和数学模型在保证高准确性的同时，不会牺牲性能。
3. 无需存储人脸图像，仅需存储图像嵌入向量，从而使逆向工程成为不可能。这确保了完全符合《通用数据保护条例》（GDPR）、《巴西数据保护法》（LGPD）及其他个人数据隐私法规的要求。

本文详细介绍了收集、处理、存储以及执行向量人脸搜索的分步流程。文中使用了Deepface（一款用于处理人脸并将其转换为嵌入向量的非常流行的Python库），并结合InterSystems IRIS Vector Search对存储的嵌入向量进行向量比较，从而实现近乎实时的人脸识别。

解决方案的安装与使用

请按照以下步骤安装人脸识别系统（基于 Deepface 和 IRIS 的开源解决方案）：

1. 将代码库克隆或通过 git pull 拉取到任意本地目录

   $ git clone https://github.com/yurimarx/facial-matching.git
   $ cd facial-matching
   $ docker-compose build
   $ docker-compose up -d

如何使用 IRIS Vector DB 在 Python 中为 OpenAI 代理配置 RAG

在本文中，我将通过一个示例，向您展示如何使用 InterSystems IRIS Vector DB 存储嵌入向量，并将其与 OpenAI 智能体集成。

为了演示这一过程，我们将创建一个具备 InterSystems 技术知识的 OpenAI 代理。具体实现方式是：将部分 InterSystems 文档的嵌入向量存储在 IRIS 中，然后利用 IRIS 向量搜索检索相关内容，从而实现检索增强生成（RAG）工作流。

注意：第 1 节详细介绍了如何将文本处理为嵌入向量。如果您仅对 IRIS 向量搜索感兴趣，可以跳至第 2 节。

第 1 节：数据嵌入

嵌入向量的质量取决于数据的质量！为了获得最佳效果，您应仔细准备数据。这可能包括：

• 清理文本（去除特殊字符或多余空格）
• 将数据分割成更小的片段
• 其他预处理技术

在本示例中，文档存储在简单的文本文件中，只需进行最基本的清理。不过，我们将把文本划分为若干段落，以实现更高效、更准确的 RAG。

步骤 1：将文本文件分块

将文本分割成易于处理的片段，对 RAG 系统有以下两点好处：

1. 检索更准确——嵌入向量代表的是更小、更具体的文本片段。
2. 更高效的检索——每次查询处理的文本量减少，可降低成本并提升性能。

总有人说自己的孩子更像妈妈或爸爸。要不要用数学和人工智能来确认一下呢？这款人脸匹配应用能给你答案。

看看这些结果：

1. 上传父亲、孩子和母亲的照片：

本文中的观点和见解基于我的个人经验。在起草和润色文本的过程中，我借助了大型语言模型（LLM）的协助，并亲自对内容进行了审阅和定稿。

对于熟悉代码且打字速度快的开发者来说，编写文档未必困难。对我而言，真正具有挑战性的部分其实是润色文档、梳理说明逻辑、修正语法，并确保其他团队成员能够准确理解具体实现方式。 

本文旨在分享我作为驻曼谷的实施团队成员，借助 Claude 获得帮助的经验。在处理 InterSystems IRIS 和 TrakCare 定制化项目时，我利用它来辅助文档结构设计和提升可读性，同时由我自己对最终内容进行审核。

开始之前，请遵循贵组织的 AI 政策。使用公司批准的 AI 工具，并确认您被允许提供哪些源代码和客户信息。对于 InterSystems 员工，请先向 AI 赋能团队申请批准，并务必阅读相关政策。拥有 AI 工具的使用权限并不意味着所有内容都可以与之共享。

为 Claude 准备上下文

文档的质量在很大程度上取决于所提供的上下文。我的工作流程整合了三类输入：

1. 自定义代码：例如，TrakCare API 扩展接口、LogiReport 使用的 ObjectScript 存储过程，或自定义 JavaScript 功能。如果某个类从自定义辅助类继承了方法，在相关的情况下我会将该辅助类包含进来。否则，Claude 可能会看到方法调用，却缺乏解释其行为所需的足够信息。

Hugging Face 为从事机器学习、自然语言处理、数据分析和人工智能领域的开发者提供了数千个数据集。InterSystems IRIS 则为数据的存储、查询和处理提供了一个强大的平台。将这两个生态系统结合起来，为希望直接在 IRIS 内对真实世界数据集进行实验的开发者创造了令人兴奋的可能性。

然而，导入数据集绝非仅仅是下载文件并将行插入表中那么简单。一个切实可行的解决方案需要处理数据集配置与分割、模式映射、分类标签、可重复性、大规模导入以及数据完整性等问题。

为应对这些挑战，我开发了IRIS HF Loader——这是一个开源的数据集资源管理器和导入工作室，可通过 Web 界面、ObjectScript、SQL、REST 以及 Python 将 Hugging Face 数据集导入 InterSystems IRIS。

在本文中，我将阐述该问题、解决方案背后的设计决策，以及开发人员如何利用它直接在 IRIS 中处理 Hugging Face 数据集。

1. 导入前的数据集探索

首要挑战之一是在决定导入之前，识别合适的数据集并理解其结构。

IRIS HF Loader 提供了一个数据集发现界面，支持按名称或关键词搜索 Hugging Face Hub。用户可以按下载量、点赞数、热门指数或最近更新对结果进行排序，并按任务、大小和语言进行筛选。

受@Ashok Kumar Thangavel在此创意门户上的帖子启发，加之我本人也希望找到解决此问题的方案，我设计了一种简单的方法，可以在无需逐一指定所需字段的情况下，实现更完整且一致的 JSON 查询。 我创建了一个类，该类继承了内置的 %JSON.Adaptor 类，并通过几个简单的 SqlProc 方法，使 %JSONExportToString 和 %JSONExportToStream 方法能够通过 SQL 调用。

Class DH.JSONAdaptor Extends %JSON.Adaptor [ Abstract ]
{
ClassMethod jsonstring(id, map = "") [ SqlProc ]
{
	try{
		set myobj = ..%OpenId(id)
		set sc = myobj.%JSONExportToString(.json,map)
		if $$$ISERR(sc) $$$ThrowStatus(sc)
		return json
	}
		catch ex{
		throw ex
	}
}

ClassMethod jsonstream(id, map = "") [ SqlProc ]
{
	try{
		set myobj = ..%OpenId(id)
		set sc = myobj.%JSONExportToStream(.json,map)
		if $$$ISERR(sc) $$$ThrowStatus(sc)
		return json
	}
	catch ex{
		throw ex
	}
}
}

简而言之：借助Claude，探索您产品中缺失的、对客户而言价值极高或存在显著痛点的功能，这些功能在竞品中可能已存在。

Claude 能够理解 Mermaid 实体关系图，并能利用它们辅助研究以开发新功能。
成本：少于 15 美元的代币
耗时：约3小时的提示处理时间

灵感来源

感觉小人

来源：罗伯特·哈里森（Robert Harrison）。《大脑中声学世界的表征：听觉系统中频率图的正常与异常发育》[1]
1937年，怀尔德·彭菲尔德与埃德温·博尔德雷、霍滕斯·坎蒂尔共同提出了“感觉小人”的概念。该模型直观地展示了大脑皮层表面积与感觉输入位置之间的对应关系。

“要为客户提供最佳支持，你必须理解他们的痛点” ~ 佚名
思考：与电子产品互动时的情感表现，是否类似于一种逻辑性的感官输入？

感觉幽灵

1871年，美国医生西拉斯·韦尔（Silas Weir）提出了“幻肢”这一术语。他观察并记录了美国内战截肢者中的一种综合征，将这种感觉描述为“感觉幽灵”。
参考：《利平科特杂志》，第VIII卷，第48期，1871年12月

思想实验：当顾客与您的产品互动时，您是否意识到“他们错过了哪些感受”？

提示法

凭借一个Northwind数据库的简易模式和一杯新墨西哥州皮诺咖啡，我与克劳德坐下来展开调查。开始吧！

项目文件 Source_Database_Schema 和 concepts.py 显示为初始状态。

上午10:47— 何塞·加西亚的肌酐检测结果传送至医院的FHIR服务器。 2.1 mg/dL— 比上月上升了35%。

接下来会发生什么？

• 大多数系统：❌ 检测结果会滞留在队列中，直到临床医生手动审核——这可能需要数小时甚至数天。
• 本系统：👍 人工智能代理会评估趋势，参考临床指南，并生成循证建议——仅需几秒钟，且完全自动完成。

没有聊天机器人。没有手动提示。没有“黑箱”推理。

这是一种具有完全可解释性的事件驱动型临床决策支持系统：

✅由FHIR事件自动触发✅多智能体推理（上下文、指南、建议） ✅完整的SQL审计日志（每项决策、每个证据来源） ✅FHIR原生输出（将DiagnosticReport发布到服务器）

构建技术：

• InterSystems IRIS for Health— 编排、FHIR、持久化、向量搜索
• CrewAI— 用于结构化推理的多智能体框架

您将学习：🖋️ 如何在生产级互操作性系统中协调基于代理的人工智能工作流——以及为何可解释性比单纯的准确性更为重要。

YouTube 视频播放器

🎬 本演示的输出内容

当收到何塞的肌酐异常检测结果时，系统会自动生成：

**输入：**FHIR 观察结果（肌酐 2.

如果您在 OEX 上的某个软件包收到评论，OEX 只会就您自己的软件包向您发送通知。   
该评分反映了评论者在评论时所见状态下的使用体验。   
这相当于一个快照，此后情况可能已发生变化。   
社区其他成员的评论会在最后一列用 * 标记。

注意：
如果您无法阅读某些评论，可能是这些评论仍在等待OEX管理员的审核。

IRIS 2026.2 提供了一个用于管理的、已文档化的 REST API——即位于 /api/admin 下的 SysAdmin API，其 273 个操作均附有 OpenAPI 规范。 在**“构建您自己的管理门户”竞赛中，我基于该 API 构建了名为 Aperture** 的管理门户，并根据已发布的规范生成了其 TypeScript 类型定义。编译器会检查门户发送的每个请求以及读取的每个字段。

这使得规范承担了关键职责。当规范与服务器状态不一致时，门户会出现编译器无法检测到的错误：某列保持空值、某项服务显示为禁用状态、列表过早终止。 因此，我对 Aperture 进行了实际实例测试：在自己服务器上的容器中运行 IRIS for Health 2026.2（Build 221U），并在每次代码推送时通过持续集成测试 IRIS Community 2026.2。

共发现了二十处差异。其中大部分是明显的矛盾：字段名称或类型不一致、限制条件与文档不符、操作路径不同。其余则是规范中未提及但客户端必须了解的行为，其中有一处会导致监控系统将一个运行正常的实例误判为降级状态。

针对每处差异，我列出了规范中的规定、IRIS 2026.2 的实际行为，以及客户端可采取的应对措施，并附上了相关记录答案的链接。

简介

我希望让医学影像的探索变得更加轻松，同时又不丢失赋予图像意义的关键信息。三维模型有助于人们理解解剖结构。如果能了解该模型的来源、其边界是如何定义的，以及***哪些部分实际上已经过检查，***该模型就会更加实用。

这正是我一直在开发的开源研究与教育项目DICOM3D 所致力于解决的问题。该项目现已公开发布；本文将从更个人的角度介绍该项目，以及我为何投身其中。

兴趣源于技术层面，而我之所以不断回归这个项目，原因则在于个人层面。

我为何开始思考这些问题

2025年11月，我的妻子接受了紧急剖宫产手术。我们的双胞胎女儿在孕30周时出生。当时我就在手术室里，站在麻醉师身旁，亲眼目睹了整个过程。

手术过程中，我妻子发生了严重大出血，在极短时间内失血量巨大。我曾一度濒临失去妻子和两个新生女儿的绝境。那段经历至今仍深深影响着我。

此外，我妻子还患有巨大的子宫肌瘤，尺寸约为10×8×9厘米，虽然在孕期已被记录在案，但并未有效告知我们。*（我无法确定这是否导致了紧急情况，也无法断言它是否解释了所有医疗决策。）*令我印象深刻的是，记录在案的信息与我们对其存在的认知之间存在着巨大鸿沟。

我自身经历的慢性疼痛、脊柱问题、就医过程以及影像检查，也让我有充足的时间站在了病历的另一端。我深知，当对涉及自身身体的信息心存疑问，**却又无从查证时，**那种感受是怎样的。我是一名开发者，而非医疗专业人士。

Kaggle 数据集虽然很有用，但将其导入 InterSystems IRIS 并不总是那么简单。 您可能只有一个 CSV 文件，也可能有多个相关文件、包含多个工作表的 Excel 工作簿，甚至是大小达数 GB 的文件。在导入任何数据之前，您需要了解手头的数据情况，以及这些数据应如何存储在 IRIS 中。

正因如此，我开发了iris-kaggle-loader。它允许您探索数据集、检查其结构、审查导入方案，并将数据加载到 IRIS 中。您可以通过 Web 界面，或借助 ObjectScript、SQL、REST 和 Python 进行操作。即使没有 Kaggle 账户，您也可以处理公开的数据集。

本文将通过一个真实数据集进行演示，并重点说明其中最费思量的部分。

Kaggle 的独特之处

在编写任何代码之前，我列出了 Hugging Face 加载器无需处理的内容：

• 文件，而非数据分割。一个数据集可能同时包含 CSV、TSV、Parquet、JSON、JSON Lines 和 Excel 文件，此外还有完全无法导入的图像和 PDF 文件。
• 相关表。许多数据集实际上是一个分散在多个文件中的小型数据库。
• CSV 中没有数据类型。每个列的数据类型都必须根据其值来确定。
• 超大文件。有些文件大小达几千兆字节，而你通常只想提取前几千行来尝试一些操作。
• 版本编号。

在这篇文章中，我让 Claude Code 根据三条通俗易懂的英文提示，在我的 IRIS 实例上构建了一个 LLM 配置、一个代理、一个工具和一项技能，然后我自己对结果进行了验证。以下两个社区项目使这一切成为可能：

• iris-agentic-dev是一个 MCP 服务器和命令行工具（CLI），它为 Claude Code、VS Code + Copilot、Cursor 或任何其他 MCP 客户端提供了 90 多种 IRIS 工具：读取类、编写和编译代码，以及在运行中的实例上执行 ObjectScript 和 SQL。
• iris-ai-hub是随其附带的一项技能。它会告知助手 AI Hub 文档的位置，指示其在编写任何代码前先读取已安装的 %AI 类，并列出 AI Hub 的相关事实。

开始之前我已准备好的环境

本文仅讨论构建过程。我已在实例上配置了以下内容：

我用 Node.js 构建了一个语音助手的最小可行产品（MVP）：浏览器会聆听你的语音（采用真正的语音活动检测（VAD）技术，能自动识别你何时说完一句话），API 会将语音转录成文字，并使用向量搜索（Vector Search）（VECTOR_COSINE)，仅根据检索结果进行回答，并以语音形式反馈答案。

本文将详细讲解RTVA（实时语音代理）的底层工作原理，展示代码的核心要点，并说明该概念验证（POC）目前仍存在哪些不足。

为何选择语音？

像 Alexa 这样的商用语音助手工作原理如下：您说话，它等待您说完，处理所有内容，然后返回一段完整的响应。这种方式虽然可行，但在您提问和得到回答之间存在明显的停顿。

RTVA背后的理念正是打破这种“一步接一步”的流程。系统不再等待完整的音频，而是采用分块处理（连续捕获的小段音频），各阶段相互重叠：当你还在说话时，系统就已经开始转录并进行推理。

InterSystems IRIS 中的每个 SQL 错误都会附带一个编号——-30、-119、-400。 大多数人会跳过这个编号，直接查看错误信息，但编号的范围能提供一个很好的初步线索，帮助判断语句是编译失败、运行时遇到错误数据，还是因环境因素导致失败。 本文将介绍 SQLCODE 的含义、如何确认其阶段，以及在通过 ObjectScript 运行 SQL 的各种方式中，如何查找该代码。

SQLCODE是 InterSystems SQL 在每条语句执行后设置的一个整数。其取值只有几种。

0 - 成功。语句已执行完毕。但有一点容易让人误判：没有 GROUP BY 的聚合查询（例如 SELECT SUM(Amount) FROM MyApp.Payment WHERE ...），即使没有匹配的行，也会返回 SQLCODE 0。 你会得到一行，其sum字段为NULL，而 %ROWCOUNT 的值为1。如果在此处使用 来测试“是否找到结果？”，该测试永远不会触发，因此应直接测试该值本身。 在 ObjectScript 中，SQL NULL 会被作为空字符串传入宿主变量，因此检查应为 。 则不同：它返回 0 而不是 NULL，而 、、 和 在无匹配结果时会返回 NULL。

操作员批准了一项待处理的交易。服务器保存了该决定，随后原生工作流的完成操作失败。浏览器收到 HTTP 503 状态码。

此时，一个普通的“重试”按钮会要求操作员猜测发生了什么。批准是否已持久化？是否需要其他原因？再次点击是否会触发另一轮提交？

SilentShift 将此中断视为可恢复状态。已保存的决定仍可见，案件保持待处理状态，而**“恢复已记录的审核”功能**将延续原始请求。在受控恢复测试中，该延续操作完成了原生任务，并生成了一份目标模拟器收据。

本文阐述了决策、原生任务完成与交付之间的界限。所有交易均为模拟交易；目标为 IRIS 模拟器。

将人工等待放入原生工作流中

SilentShift 致力于研究 IRIS 互操作性生产环境中的业务含义变化。其 AI Hub 代理会收集证据并提出处理路径；嵌入式 Python 策略则根据证据判断是否允许释放。第一篇文章介绍了合同比较以及代理的只读工具。

已启动的调查仍需指定负责人。SilentShift 使用一个独立的持久化Coordinator业务流程，将 ReviewRequest 异步发送至 EnsLib.Workflow.Operation。 任务处理程序继承自 EnsLib.Workflow.TaskResponse。

在人工处理案件期间，协调器可以等待本机延迟响应，而无需占用原始 HTTP 请求或操作任务。

某个集成接收了一笔金额为 20 CASE 的订单。JSON 数据已解析成功，必填字段均已包含，且目标地址可达。然而，已批准的合同中规定的金额为 240 EA。

开发人员可能会想到一个合理的解释：二十箱，每箱十二件。但当集成系统将此解释视为许可时，情况就变得危险了。该消息中并未包含已批准的包装规格，而这种看似合理的换算并不能证明合作伙伴同意发送的是什么。

SilentShift 会在交付前暂存该订单，并整理出集成操作员解决问题所需的证据。它在 InterSystems IRIS 互操作性生产环境中运行，利用原生 AI Hub 代理进行调查，并采用嵌入式 Python 策略来授权传输路径。以下示例使用了合成交易和 IRIS 目标模拟器。

在向模型提问前先定义业务承诺

核心对比在于消息与业务事件发生时生效的已批准参考记录之间的差异。仅凭一个出人意料的数值，其实并不能说明什么。

假设两项调查的入库数量和单位相同：

第二行可防止检测器成为“全盘变更”的阻碍。旧值虽有差异，但业务方已授权新值。

评估引擎在路由前会进行此区分。

某个应用程序可以使用 Supabase 作为其基于 PostgreSQL 的后端，而现有的业务数据仍保存在 InterSystems IRIS 中。这时就会产生一个问题：PostgreSQL 如何查询这些 IRIS 数据？

iris-wasm-fdw是一个针对此场景的实验性项目。它利用 Supabase Wrappers 中的 WebAssembly 外部数据封装器机制，通过 IRIS Atelier HTTP/JSON API 执行预配置的 SQL 语句，并将结果作为 PostgreSQL 外部表呈现出来。

当前的实现主要面向小规模测试以及结果集有限的读取查询。本文将详细说明其工作原理、配置方法以及使用前需考虑的事项。

什么是 Wasm FDW？

PostgreSQL 外部数据封装器（FDW）允许用户将外部数据源表示为外部表。当应用程序查询该表时，封装器会访问数据源并返回结果。

Supabase Wrappers为该机制增加了对 WebAssembly 的支持。开发者可以构建 Wasm 组件，由 Wrappers 扩展在 PostgreSQL 中加载这些组件。组件可以利用主机提供的接口访问 HTTP API，并将数据返回给 PostgreSQL。

Supabase 还提供了一个Postgres Wasm FDW 示例项目，演示了如何使用 WIT 接口构建此类组件。

作者：伊努南巴·奥内

当某项服务发生故障时，所有依赖该服务的服务都会触发各自的警报。短短几分钟内，值班人员就会面临数十条警报，而这些警报都指向同一个故障。这被称为**“警报风暴”**。Datadog 对此描述如下： “你还会收到所有试图与故障服务通信的其他服务的警报”（Datadog）。针对大型云系统的研究也报告了相同的模式：一次故障会在短时间内触发“大量相关警报”（arXiv 2403.06485）。

InterSystems IRIS 互操作性生产环境正是这一问题的天然温床：服务、路由器和运维系统紧密相连，因此一条链路中断就可能触发下游所有系统的警报。Storm Link是我为 InterSystems 编程竞赛“互操作性工作流中的 AI 代理”开发的一款应用。它能够解析警报风暴，并在 IRIS 内部直接向值班人员指出唯一根本原因。

• 演示视频：https://youtu.be/N950ADnIfTc
• 源代码（MIT 许可证）：https://github.com/inunanba/storm-link
• Open Exchange：https://openexchange.intersystems.com/portal/products/Storm-Link

一张图看懂它的功能

1. 警报会发送到 IRIS Production 中。

如果您在 OEX 上的某个软件包收到评论，OEX 只会就您自己的软件包向您发送通知。   
该评分反映了评论者在评论时所见状态下的使用体验。   
这相当于一个快照，此后情况可能已发生变化。   
社区其他成员的评论会在最后一列中用 * 标记。
 

注意：
如果您无法阅读某些评论，可能是这些评论仍在等待OEX管理员的审核。

本文介绍的是 v1.0.0 版本，即本文撰写时的公开发布版本。

当 HL7 传输失败时，必须有人决定是否重发。如果重发过期的传输数据，就会覆盖更新的数据；如果保留当前数据，患者在另一系统的屏幕上就会被显示在错误的病床上。Shutter 将每次传输失败都转化为一个案例。 由 IRIS AI Hub 代理组成的委员会会读取密封证据并提出处理建议。一个确定性门控机制会核查该方案。最终由人工或该机构自身的书面政策予以批准。随后，Shutter 执行一次有条件写入操作，并在接收系统的收据和历史记录中进行验证。 恢复写入需要通过门控并获得批准。之前的预演仍信任接收方会遵守 dry_run：如果接收方当时进行了写入，Shutter 就无法撤销该操作。

Shutter 是我参加“互操作性工作流中的 AI 代理”竞赛的参赛作品。本文按照 InterSystems 的顺序，涵盖了竞赛的四个主题：AI Hub 体验、模型与成本、追踪以及 IRIS Agentic Dev。

AI Hub 体验

此处所有内容均基于构建版本 2026.3.0AI.154.0 进行测试。在 2027.1.0AI.109.0 版本（即早期访问门户自 11 月 2 日起提供的构建版本）中，我重新检查了配置存储描述符，包括 %LogExecution、的三个参数、基础的以及缺失的IPM：这些均保持不变。

只有当测试证明某个研究步骤已完成时，实验室才会为此支付费用。

Knos 助力研究跨越“死亡谷”。

仅限模拟资金。本文探讨的是，当 InterSystems IRIS 平台内的人工智能代理读取证明时，其中一项验证的成本是多少。

在让智能代理协助做出任何涉及资金的决策之前，实验室会向我提出两个问题：每项决策的成本是多少？这个数字从何而来？在 IRIS 上的 Knos 中，答案来自对生产环境自身消息的 SQL 查询。

这个数字从何而来？决策的每一步都是决策自身会话中的一条互操作性消息，即 Knos.Iris.Msg.Span。因此，它会在 Visual Trace 中与证明和裁决结果并列显示。 相同的行会被记录到一张表中，即 Knos_Iris_Data.Span，其中包含 Model、 、 、 和 。没有任何事后估算：令牌数量即为模型给出的答案所报告的数值，而成本则是令牌数量乘以该模型的单价。

模型。该代理运行在 qwen2.5:1.5b-instruct 上，这是一个位于 IRIS 旁边的 Ollama 容器中的小型开源模型，通过 AI Hub 的 openai 提供商运行，无需密钥。 评估标准通过 snowflake-arctic-embed-s（3300 万个参数，384 个数值）以嵌入式 Python 形式实现。

测试结果。

大家好，

AI Hub 是 IRIS 的新组件，用于构建能够与您的数据和生产环境无缝协作的人工智能代理。代理即为一个类。 您可以为其提供指令、一组可调用的工具，以及可选的技能（仅在需要时加载的额外指令）和可供搜索的知识库。随后，它将进入循环运行：模型请求工具，IRIS 执行您的 ObjectScript 方法，结果返回给模型，如此循环往复，直至模型给出答案。 策略决定代理可以使用哪些工具，并可记录每次调用。会话会将整个对话记录在 IRIS 中，因此您可以稍后打开它，查看代理为何会给出这样的回答。

互操作性是应用此方案的天然首选场景。每个生产环境都会出现消息发送失败的情况，而每条失败的消息都像是一道小谜题，需要人工阅读、理解并修复。只要您能控制代理的权限范围，这正是代理可以协助完成的工作。

本文将展示正确构建该系统后的实际效果。这是我参加 InterSystems 编程大赛的参赛作品iris-agentic-production：一个 AI Hub 代理，用于在 IRIS 生产环境中对失败的 HL7 实验室消息进行分诊，并附带一个用于构建和添加自定义代理的工作台。 我将按照您今天安装后所看到的界面，逐屏为您详细讲解。第二篇文章将提供分步教程，指导您亲自构建同类系统。

应用程序的功能

凌晨2点，一条实验室结果在接口引擎中出现错误。可能是时间戳格式不正确，或者某个本地检测代码从未映射到LOINC。

大家好，

上一篇文章介绍了FlightDeck的功能。本文将探讨在开发过程中发现的发现，无论您是否关注我的应用程序，其中大部分内容都很有用，因为这涉及平台本身。

InterSystems 在本次竞赛中发布了 SysAdmin API 规范：/api/admin，190 个路径，273 个操作，六个域。全面覆盖这些内容时，我发现了一些规范中未提及的问题，同时也获得了一项关于我自身代码的测量结果——我宁愿将其公布于众，也不愿隐瞒。

规范存在缺失的三个方面

**没有日志端点。**竞赛要求提供“所有日志，即各个子系统向用户报告的内容”。对全部 190 个路径进行搜索后，只发现了审计日志和日志文件，别无其他。 没有 messages.log，没有警报，也没有互操作性事件日志。任何想要妥善覆盖该领域的人，都必须编写原生提供程序。

其中有一项是我刻意没有实现的。日志会向每位用户隐藏其无权读取的数据库记录。若要原生重构该功能，就意味着需要在 IRIS 之外决定授权规则，因此源代码会以该理由显示为不可用，而非出现细微的错误。一个经过选择并明确说明的限制，比事后才发现的限制更有价值。

社区版镜像不提供 v2 服务。intersystemsdc/iris-community:latest 是 2026.1 维护分支，仅支持版本 1。