在医院、企业和运维场景中，很多重要信息都需要及时送达相关人员：接口运行异常、系统资源告警、审批提醒、任务完成通知……这些消息通常由不同业务系统产生，但接收人员希望在一个熟悉的地方查看。

企业微信是一个自然的选择。对于已经使用 InterSystems IRIS Interoperability 的团队，如果能够直接在 Production 中配置企业微信出站组件，就可以把现有业务流程中的消息发送到员工或工作群，而不必为每个业务系统单独开发一套推送服务。

iris-wechat-gateway 就是为这个目的设计的。它提供基于 IRIS Interoperability 的企业微信出站适配器，让业务流程通过 Business Operation 发送企业微信消息。项目源码可在 GitHub 仓库查看。

项目能做什么？

当前版本支持两种企业微信消息通道：

两种通道都支持 text 和 markdown 消息。例如：

• 发送接口故障或服务器磁盘空间告警；
• 通知员工某项任务已完成；
• 向相关部门推送业务处理结果；
• 在运维群中集中展示监控通知。

据我了解，HL7消息是基于服务和操作进行索引的。但是，我无法确定索引具体在何时发生，特别是针对操作而言。例如，如果一条消息被放入操作的队列中，它会被索引吗？如果操作未运行，此时它会被索引吗？

我曾看到在转换后的流程中存在已建立索引的搜索表字段，那么这些索引是在哪里生成的？

我尝试阅读了源代码，但未能找到该逻辑所在的位置。

在开发 OcuPilot（https://openexchange.intersystems.com/package/OcuPilot）——一款用于 IRIS 管理门户的人工智能副驾驶——的过程中，我为测试运行了大量短暂存在的 IRIS 容器。 这些容器将数据保存在我 Mac 上的 /tmp 目录下的文件夹中，因为那里是临时文件的存放位置。三天后，其中一个容器开始出现莫名其妙的故障：一个仍显示为已挂载的临时数据库背后实际上没有对应的文件，且向其写入数据时会失败。

我起初怀疑是 IRIS 的问题，随后又怀疑是自己的代码出了问题。但事实并非如此。这其实是 macOS 完全按照其设计原理在正常运行。

macOS 的工作原理

每天午夜，macOS 会运行一个小型清理任务，删除 /tmp 目录下超过三天无人触碰的文件。 这是 macOS 自身的一部分，对于临时文件夹来说也是合情合理的。它只检查 /tmp（实际上是 /private/tmp），且不关心文件的具体内容。

为什么 IRIS 数据库特别容易受到影响

IRIS 将您使用的数据保存在内存中，仅在发生变更时才写入数据库文件。我对此进行了测试：读取数据库（即使是全部读取），文件的时间戳也完全保持不变。 因此，对于仅被读取或完全未使用的数据库，清理任务会将其视为未被触及，三天后该文件便会消失。

TL;DR / 简要回答

本文深入剖析了 InterSystems IRIS 的进程架构、内存结构以及 EVTW 和 SLMSPAN 等晦涩难懂的进程状态，是一份详尽的实操指南。 文章阐述了IRIS为何采用“每个任务一个进程”的模型而非多线程机制，解释了进程专用内存和符号表的工作原理，并介绍了管理员如何利用内置工具诊断和解决性能瓶颈。

本文适用对象

本指南面向管理 InterSystems IRIS 环境的数据库管理员（DBA）、系统架构师和后端性能工程师，他们需要解读低级进程状态并排查系统争用问题。
 

1. 引言：架构背后的原因

每当用户打开终端/连接会话、通过 ODBC 在 IRIS 上运行报告，或者互操作性生产环境转发 HL7 消息时，InterSystems IRIS 都会做一件许多现代平台刻意避免的事情：它将这项工作交由其自身的操作系统进程处理。 这并非从一个大型服务器进程内部的共享池中提取的线程——而是一个真正的、独立的操作系统进程，拥有自己的内存、自己的栈以及自己的生命周期。要理解IRIS为何采用这种架构，我们需要追溯到比IRIS本身更早的时期，追溯到其源头语言。

2. InterSystems IRIS 为何采用进程模型

IRIS 采用专用进程模型的关键原因在于提供强大的故障隔离并保护内存完整性。

2019 年，我编写了iris-history-monitor，旨在以可视化方式展示系统监视器（System Monitor）记录的关于 InterSystems IRIS 实例的信息，并用更易于阅读的界面取代管理门户（Management Portal）中的仪表盘和进程列表。

虽然它曾有效运行，但已显陈旧。该工具基于一个大型网格库构建，由一组 CSP 页面组成，将每次请求的数据保存在共享全局变量中；在当前的 IRIS 环境中，其“历史”屏幕会显示为空白，却未说明原因。 本文将介绍此次重新设计：您现在所看到的界面，以及为使后端能在 IRIS 2026.1 上运行而进行的底层改动。

在 2026 年 10 月 13 日发布的 2.2.0 版本中，我还添加了可选的浏览器通知功能。现在，当您在其他界面工作时，只要相关标签页保持打开状态，监控系统就能在指标恶化时及时提醒您。

有哪些变化

• 全新的三屏界面，包括“概览”、“历史”和“进程**”，这些界面以静态文件（React、TypeScript、Vite）的形式构建，由 IRIS 通过其自身的 Web 应用程序提供服务。**服务器端无需构建步骤，也无需运行其他 Web 服务器。
• **一个带有契约的 REST API。**该接口调用一个带版本号的 API（/historymonitor/api/v1），其规范由代码库中的 OpenAPI 文档描述。

许多数据库用户需要了解现代端点防护平台（例如 Palo Alto Cortex XDR 和 CrowdStrike Falcon）对其数据平台性能的影响。 本文所引用的研究（链接见下文）展示了在 RHEL 9.5 和 Ubuntu 24.04 版 Linux 操作系统上运行的 InterSystems IRIS 数据库，在采用这些终端防护平台时的测试结果。 该研究使用了这两款安全产品的正式版，并测量了多种数据库工作负载，包括 ObjectScript 执行、日志记录、进程创建、并发以及低级系统同步。结果表明，核心数据库操作基本未受端点防护的影响，性能差异通常在正常系统波动范围内。 测试框架旨在模拟真实的企业部署环境，并包含多次基准测试以确保结果的可靠性。总体而言，端点防护可在 InterSystems IRIS 上安全部署，且不会对正常的数据库操作产生显著影响。

这些发现表明，在类生产环境中验证端点保护部署并密切监控日志延迟、复制延迟、故障转移时间和 CPU 利用率等关键指标至关重要。 应特别关注日志路径，针对该路径进行有针对性的调优（包括在适当情况下将日志目录排除在实时文件扫描之外），可在保持安全效益的同时提升性能。部署前应建立性能基准。部署后应持续监控系统，以识别性能退化或配置问题。

用户经常会遇到 InterSystems IRIS 与 Red Hat 的文件访问策略守护进程（fapolicyd）之间的兼容性问题，后者是一种基于可信软件强制执行执行白名单的安全机制。 完整报告（链接见下文）解释道，fapolicyd 默认信任通过 RPM 安装的软件，而 InterSystems IRIS 则是通过基于 TAR 的安装程序分发的，因此默认会被视为不可信。 因此，当 fapolicyd 以默认模式启用时，由于所需的共享库被阻止，InterSystems IRIS 将无法初始化或运行。这种情况并非 InterSystems IRIS 本身的限制，而是信任配置导致的后果。通过使用自定义规则和信任数据库条目，一种经过验证的解决方案既能确保正常运行，又能维持安全控制。

所附报告展示了在 RHEL 8 和 RHEL 10 环境中，针对 x86_64 和 ARM64 平台进行的广泛测试结果，涵盖了多个 InterSystems IRIS 版本。验证过程分为四个阶段：基线模式、宽松模式、强制模式（默认）和强制模式（受信任）。 测试结果表明，InterSystems IRIS 在“基线”和“宽松”模式下运行正常，在“强制（默认）”策略下完全无法运行，而在应用“强制（受信任）”规则后则能成功运行。

一听到“openEHR”，你是否就感到不寒而栗？“原型”这个词是否让你起鸡皮疙瘩？

通过本文克服你的恐惧，利用 InterSystems IRIS for Health 的强大功能，轻松掌握 OpenEHR！

什么是 openEHR？

openEHR 是一项开放且与供应商无关的规范，旨在以语义丰富且长期可持续的方式表示、存储和交换临床信息。与许多互操作性标准定义固定消息结构的做法不同，openEHR 通过多层建模方法将临床知识与技术实现分离。

从本质上讲，openEHR 基于三个基本概念：

• 参考模型（RM）
  该模型定义了健康记录中使用的核心结构，例如组合（Compositions）、条目（Entries）、观察结果（Observations）、评估（Evaluations）和操作（Actions）。参考模型（RM）刻意设计为通用且与技术无关。
• 原型
  可机读的模型（以 ADL 表示），用于定义特定概念（如血压测量值或出院小结）的详细临床语义。原型对参考模型施加约束，并提供可重用的临床词汇。
• 模板（OPT文件）
  基于原型构建的特化形式。模板将原型定制为适用于特定用例、系统或表单的形式（例如，生命体征模板或区域出院摘要）。模板消除了可选性，并生成系统可安全实施的操作性定义。

向InterSystems西班牙语开发者社区的所有尊贵成员问好！

虽然我经常查阅开发者社区的内容，也偶尔在这里提问，但这将是我发表的第一篇文章，而参加第三届技术文章大赛无疑是发表首篇文章的最佳契机。

本文将探讨 InterSystems IRIS 为我们提供的各种工具，这些工具既能优化数据库，也能优化我们执行的查询，同时还将介绍新型存储和数据类型。

优化我们的 SQL 查询

为了撰写本文，我在一个 InterSystems IRIS Community 实例中搭建了一个小型示例，导入了一个 CSV 文件，其中包含 500 万条记录，这些记录模拟了多年来在不同城市进行的假想销售数据。

表结构将非常简单，但足以满足我们所需的测试。请原谅这些名称，但您也知道，没有什么比临时解决方案更持久的了。

Sales.Record

Sales.Record

竞赛.地点

我们将尝试提取像巴利亚多利德这样的城市在某一年的历史平均销售额：

让我们看看查询返回月平均销售额需要多长时间：

结果显示，返回月平均销售额耗时略超过8秒。

Visual Studio Code（VSCode）是市场上最受欢迎的代码编辑器。它由微软开发，作为一款免费的集成开发环境（IDE）发布。VSCode 支持数十种编程语言，包括 ObjectScript；直到 2018 年，Atelier（基于 Eclipse）也支持这些语言。 它曾被视为开发 InterSystems 产品的主要选择之一。 然而，2018 年 12 月，当 InterSystems 开发者社区推出对 VSCode 的支持后，相当一部分 InterSystems 专业人士开始实际使用该编辑器，并一直沿用至今，尤其是那些从事新技术（Docker、Kubernetes、NodeJS、 Angular、React、DevOps、GitLab等）的开发人员。VSCode最突出的功能之一便是其调试能力。因此，本文将详细演示如何调试ObjectScript代码，包括类代码和%CSP.REST代码。

什么是调试？

调试是一个检测并解决“错误”（即 ObjectScript 代码中的错误）的过程。有些错误是逻辑错误，而非编译错误。因此，要在源代码的执行逻辑中理解这些错误，您需要逐行查看程序的运行情况。这是识别条件或编程逻辑并找出逻辑错误的最佳方法。 还有一类错误是运行时错误。要调试此类问题，首先必须检查已赋值的变量值。

《InterSystems IRIS 互操作性实用指南：终端调用、使用 OnTask 的自定义适配器、上下文模拟以及工作流调试》（2026）

简而言之 / 快速解答

InterSystems IRIS 互操作性主机（服务、进程、操作）在独立的后台作业中运行，并通过持久化消息队列进行通信。 开发人员可直接在 IRIS 终端中测试和调试这些组件：对于无需适配器的服务，使用 Ens.Director.CreateBusinessService；对于直接操作调用，使用 %New("ConfigName")；对于完整的队列管道，使用 EnsLib.Testing.Service.SendTestRequest。 自定义入站适配器通过重写 OnTask() 方法轮询外部数据源。对于系统头信息未填充的本地终端执行场景，开发人员可以手动模拟 %SessionId 和 %RequestHeader 属性。

本文适用对象

本指南专为希望从 IRIS 终端调用业务服务和操作、通过 OnTask() 实现自定义轮询逻辑，以及系统化测试或调试生产主机的 IRIS 集成开发人员、系统工程师和解决方案架构师而设计。

主要主题/问题 #1：面向业务主机的终端执行协议

InterSystems IRIS 互操作性主机可以通过编程方式在活动的终端进程中直接实例化并执行。

万圣节到了，我们将开发者日常的烦恼化身为电子游戏中的反派角色！
试想一下，你最头疼的编程噩梦变成了游戏中的最终BOSS。它会是什么样子？会如何攻击？开发者又该如何击败它？
请在评论区按以下格式分享你的创意：
💀BOSS名称： 遗留代码怪兽
⚔️特殊攻击：每次修复一个 bug，就会搞砸三个毫无关联的功能。
🛡️ 弱点：文档 和自动化测试。
灵感可以源自真实的开发挑战、某个特别难忘的 Bug，或是每个程序员内心深处的隐秘恐惧。
让我们看看开发者社区能创造出什么样的怪物吧！👾

在与客户合作以及后续跟进过程中，我经常遇到这样的 
明确或隐含的疑问：这个“GLOBALS”到底是什么？
我将尝试解释其发展历程，以便阐明这一背景。

每个 IRIS 互操作性团队都熟悉这样的晨间例行工作：打开消息查看器，找出标记为红色的行，阅读错误信息，检查组件设置，然后决定是重新发送、修正数据还是联系相关人员。我想了解，**在绝不允许中断生产环境的情况下，**AI Hub 代理能接管其中多少工作。

最终成果便是“互操作性分诊”（Interop Triage），这也是我参加“互操作性工作流中的 AI 代理”竞赛的参赛作品。 当消息处理失败时，一个 %AI.Agent 会使用只读工具进行排查，并提出四种处理方案之一：重试、修复并重发、丢弃或上报。 确定性规则将决定该建议是直接执行、等待人工处理，还是上报。本文将探讨设计决策、模型让我感到意外的时刻，以及我在 AI Hub 154 版本中获得的经验。

各位开发者，大家好！

以下是“InterSystems 编程竞赛：互操作性工作流中的 AI 代理”的技术加分项，在投票环节中，满足这些条件将为您赢得额外积分：

• 问卷 - 1
• 生产扩展（PEX） - 3
• 工作流引擎 - 2
• 自定义适配器 - 2
• 在 AI Hub 中发现一个错误 - 2(3)
• 嵌入式 Python - 3
• IRIS 向量搜索的使用 - 2
• Docker 容器使用 - 2 
• ZPM 包部署 - 2
• 在线演示 - 2
• 实现 InterSystems 社区创意 - 4
• 在嵌入式 Python 中发现一个错误 - 2(3)
• 开发者社区上的第一篇文章 - 2
• 在开发者社区发表第二篇文章 - 1
• YouTube 视频 - 3

一个基于FHIR的自然语言代理，完全构建于IRIS for Health之上：数据处理采用FHIR SQL， 术语处理采用向量搜索，并以互操作性生产环境作为代理的运行时环境。 一个真实的问题，通过18条消息的追踪记录，以及该追踪记录揭示了这些 代理在哪些方面真正成功、又在哪些方面失败。

1. 临床文本到SQL技术的发展历程

这项任务看似已成定局。临床医生用英语提出问题，模型生成SQL语句， 数据库给出答案。相关基准测试已存在多年，该领域通过这些测试取得的进展 值得关注，因为每一步都将难点推向了新的领域。

EHRSQL [5]确立了基准——这是一个基于真实 电子健康记录（EHR）模式的大型实用文本转SQL基准测试，其问题均来自医院工作人员的实际提问。该基准证实， 难点不在于SQL语法，而在于对模式的掌握：只要知道 上百张表中哪一张存储了什么数据，这些问题就能得到解答。

随后，目标转向了FHIR。FHIR-AgentBench [6]针对真实的FHIR资源重新提出了EHRSQL风格的 问题，并报告称，回答每个问题平均需要 14.5个FHIR资源。 难点已从*“该选哪个定制表”转变为“如何遍历一个标准化但深度嵌套的模型”*。 而EHR-ChatQA [7]则实现了多轮交互，同时指出了那些 SQL 风格的基准测试 一直以来默默隐藏的难点：术语不匹配。

在 2026.3 版本中，为您的 FHIR 端点引入了一项新的“分页样式”设置。

分页样式会影响 FHIR 搜索结果的分页方式。

这些新的“样式”实际上解决了两个问题：

• 在页面内的“Includes”元素方面，更好地符合FHIR规范
• 提升第一页响应的性能

共有 3 种选项：

• 传统
• 缓存
• 缓存-异步

我将重点说明每种模式的特点，并演示部分行为——

在 InterSystems IRIS 中，用户可以轻松地通过动态对象（Dynamic Object）操作 JSON。但动态对象没有模式，因此 DTL 图形化编辑器中没有可拖动的字段。 本文介绍了一种将 JSON 消息转换为虚拟文档（下文简称 JVDoc）的实现方案：其模式来源于 JSON Schema 或示例 JSON，DTL 编辑器、规则编辑器、搜索表和验证功能均可直接使用该虚拟文档，而消息本身仍以接收时的原始形式存储，并在系统中无损通过。 文末提供了可直接运行的测试用例。

问题

在互操作性场景中处理 JSON 十分常见，动态对象虽然方便，但它们没有模式，这会带来三个困扰：

• DTL 编辑器不显示字段树，因此无法通过拖拽创建映射，而必须手动编写代码。
• 在规则编辑器中输入 Document.{ 时，不会提供字段建议。
• 消息查看器无法按消息内的字段进行搜索。

通常的做法是使用 %JSON.Adaptor 生成类。这虽然解决了图形化映射的问题，但有两个代价：每个消息都必须先作为对象实例化，这对大型消息来说开销很大；此外，导入时，模式中不存在的字段会被丢弃，因此无法实现无损直通。

该思路

IRIS 虚拟文档框架（Ens.VDoc.Interface）专为没有对应类的结构化文档而设计：编辑器通过该框架获取字段树，并在运行时通过路径读写值。

InterSystems 宣布发布 2026.3 版本开发者预览计划的第六个预览版。该版本包含InterSystems IRIS® 数据平台、InterSystems IRIS for Health™ 以及InterSystems Health Connect™。 

亮点

自第 5 版预览版以来，已新增多项更新和增强功能：

• 现代互操作性用户体验增强，包括生产配置、消息查看器、模式查看器、BPL 编辑器和规则编辑器等模块的更新。 
• 支持原生 Simplifier.net 集成的 FHIR 包管理功能，简化了 FHIR 包及其依赖项的安装和管理。
• 细粒度的 %Development 安全资源，可对开发相关权限进行更精确的控制。有关这六个新资源的详细信息，请参阅此处——《使用资源保护资产 | 系统管理指南 | InterSystems IRIS 数据平台 2026.3》。

初始文档可通过以下链接查阅。这些页面将在正式发布（GA）期间持续更新：

• InterSystems IRIS
• InterSystems IRIS for Health
• InterSystems Health Connect

未来的预览版本预计每两周更新一次，新功能将在准备就绪后陆续添加。请通过开发者社区分享您的反馈，以便我们持续改进产品。

可用性与软件包信息

此开发者预览版的构建号为2026.3.0.205.0

大家好！我想向大家介绍iris-whatsapp-gateway，这是一个用于 InterSystems IRIS 互操作性的开源 WhatsApp 适配器。它支持 Meta WhatsApp Cloud API 和 Twilio，并附带一个离线演示，让您无需服务提供商账户即可体验完整的消息流。

该项目实现了InterSystems Ideas 上 DPI-I-882 提案背后的理念。1.0.0版本已在公共 IPM 注册表中发布，源代码采用 MIT 许可证发布。

本文将说明这些组件如何集成到生产环境中，逐步演示离线演示，并展示如何接入您自己的业务逻辑。

源代码和完整文档请参见 GitHub

将消息通道集成到生产环境中

HTTP 请求可以发送消息，但业务集成还需要接收 Webhook、验证请求、转换提供商有效载荷、处理状态回调、处理重复事件，并对符合条件的失败进行重试。

IRIS 互操作性为这些职责提供了一个有用的架构。业务服务（Business Service）负责接收和路由事件，业务流程（Business Process）负责执行应用逻辑，而业务操作（Business Operation）则负责发送消息。

网关遵循该结构。Meta 和 Twilio 拥有独立的连接组件，而业务层则使用通用的请求类。因此，用于订单查询、预约确认或服务通知的流程可以处理标准化消息，并将提供商协议委托给相应的适配器。

医院中的保险审核很少能得出一个简单的结论。审核人员还需要了解：是哪次就诊产生了该发现；规则审查了哪些数据；证据适用的管辖范围和日期；以及如何对不可靠的建议进行调查。

我正是围绕这些问题开发了“医疗保险审计与证据助手”（Medical Insurance Audit & Evidence Assistant）。该应用程序将FHIR数据采集、确定性检查、向量检索、AI调查以及人工任务整合到一个可追溯的工作空间中。

该项目最宝贵的经验在于：为智能代理明确职责，提供可验证的输入和输出，并建立有助于定位故障的执行记录。

本文反映了截至 2026 年 10 月 30 日的开发和验收记录。测试运行环境为 InterSystems IRIS Community AI Hub EAP 2026.3.0AI.154.0。 临床案例均为合成数据，应用程序随附的证据模板均为虚构。单独上传的国家政策文件遵循文件审核和发布流程。

源代码：MedicalInsuranceAudit。

下方的屏幕截图来自已部署演示环境的录屏。每页均显示其录制时间；其计数器的统计范围与本文中基于多次运行汇总而得的验收总计不同。界面为英文，而病例和源内容则保留其原始语言。

图1. 概览页面整合了案例数量、事件状态以及AI/服务信息。该页面反映了录制时的状态。

摘要

问题

• 预计从2026 年 11 月 17 日起，Chrome 和 Edge网页浏览器将移除内置的 XSLT 处理功能。更新后，InterSystems 产品页面当前在浏览器中转换的 XML 内容将无法再按预期呈现。其他网页浏览器也计划在不久的将来移除 XSLT 处理功能。
• 已确认的影响包括：在管理门户的“可视化跟踪”和“消息查看器”、EDI文档查看器以及Zen Reports中查看XML消息。使用客户端XSLT的相关Health Connect Cloud、HealthShare和TrakCare界面也可能受到影响。

简而言之：InterSystems IRIS for Health 允许开发人员直接在后端 ObjectScript 例程中执行 FHIR CRUD 操作，而无需依赖 HTTP REST 层。通过使用 HS.FHIRServer.Service，开发人员可以创建服务上下文、构建动态查询、验证模式，并高效地检索 FHIR 资源。 

传统的 FHIR 实现通常通过 HTTP/REST 管道处理请求。本文探讨了绕过该层、直接在 IRIS 后端执行 FHIR 操作时的情况，重点介绍了该方法涉及的架构、服务上下文、查询处理、验证和资源访问。 

本文适用对象：本指南专为InterSystems IRIS for Health、HealthShare 和 Health Connect 开发人员，以及需要在不依赖外部 HTTP 端点的情况下，直接在后端 ObjectScript 例程中执行低开销 FHIR 操作的医疗信息学工程师而设计。

核心架构：标准流程与编程执行

部署在 InterSystems IRIS for Health、HealthShare 和 Health Connect 上的标准 FHIR 实现，依赖于通过 REST 应用层映射到 HS.FHIRServer.Service 的入站 HTTP 管道。

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。

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

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

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

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

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

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

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

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

2. 两类能力上下文

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

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

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

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