Encontrar

Artículo
· 24 oct, 2025 Lectura de 14 min
Open Exchange

构建 AI 智能体：从小白到大神

#Python #Vector Search #Herramientas #Framework #InterSystems IRIS

学习如何使用 LangGraph 设计结合了推理、矢量搜索和工具集成的可扩缩自主 AI 智能体。

cover

概括

  • AI 智能体是一种超越简单的聊天机器人的自主系统，它结合了记忆库、上下文，并具有自动完成任务的主动性。
  • LangGraph 是一种框架，它使我们能够利用具有内置状态管理的节点（任务）和边缘（连接），构建复杂的 AI 工作流。
  • 本指南将指导您构建 AI 赋能的客户支持智能体，该智能体可以划分优先级，识别相关主题，并确定是上报还是自动回复。

那么，AI 智能体究竟是什么？

让我们直面它吧 —“AI 智能体”听起来就像可以接管会议室的机器人。 实际上，它们是您得力的助手，可以简化复杂的工作流，消除重复性任务。 您可以把它们看作是聊天机器人的下一个进化阶段：它们不只是简单地等待提示；它们可以发起行动，协调多个步骤，并随时进行调整。

Comentarios (0)1
Inicie sesión o regístrese para continuar
InterSystems Official
· 23 oct, 2025

InterSystems IRIS、IRIS for Health 和 HealthShare HealthConnect 的维护版本 2025.1.2 和 2024.1.5 现已发布

#FHIR #Globals #SQL #Plataformas #Lanzamiento #Health Connect #InterSystems IRIS #InterSystems IRIS for Health #InterSystems Official #Documentación

InterSystems IRIS® 数据平台、InterSystems IRIS® for HealthTM 和HealthShare® Health Connect 的2025.1.2 和 2024.1.5 维护版本现已全面上市 (GA)。这些版本包括对最近发布的一些警报和建议的修复，其中包括以下内容：

请通过开发者社区分享您的反馈意见，以便我们共同打造更好的产品。

文档

您可以在这些页面上找到详细的变更列表和升级检查列表：

EAP计划

现在有许多 EAP 可用。请查看此页面并注册您感兴趣的项目。

如何获取软件？

InterSystems IRIS 和 InterSystems IRIS for Health 的完整安装包可从 WRC 的InterSystems IRIS 数据平台完整工具包页面获取。HealthShare Health Connect工具包可从 WRC 的HealthShare 完整工具包页面获取。容器映像可从InterSystems 容器注册中心获取。

可用性和软件包信息

该版本包含适用于所有支持平台的经典安装包，以及 Docker 容器格式的容器映像。 有关完整列表，请参阅 "支持的平台 "文档。这些维护版本的构建编号为：2025.1.2.374.0 和 2024.1.5.649.0。

Comentarios (0)1
Inicie sesión o regístrese para continuar
Artículo
· 23 oct, 2025 Lectura de 1 min

Reviews on Open Exchange - #57

#Open Exchange

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

# Package Review Stars IPM Docker *
1 DevHub Big helper for daily work 5.5 y y  
2 GBLSizeMonitor Super Graphics 5.5* 5.5 y y  
3 Erralyzer visualized SMP features 5.0 y y  
4 Free DBsize with Swagger great remote access 5.0 y y *
5 IRISConfigDashboard Easy to navigate 5.0 y y  
6 ObjectScript-Native-API-demo Cross server working without ECP or MIRROR 5.0 y y *
7 Stream-Sample-for-Beginners Not for beginners only 5.0 y y *
8 swaggertools-jsonviewer interesting setup analysis 5.0   y  
9 Interop-LookupTable handy Table maintenance 4.9   y  
10 inquisidor refresh your Spanish 4.5   y  
Comentarios (0)1
Inicie sesión o regístrese para continuar
Artículo
· 23 oct, 2025 Lectura de 9 min

IKO Plus: Operator Works From Home - IrisCluster Provisioning Across Kubernetes Clusters

#Despliegue #Kubernetes #Seguridad #InterSystems Kubernetes Operator (IKO)

IKO Helm Status: WFH

Here is an option for your headspace if you are designing an multi-cluster architecture and the Operator is an FTE to the design.  You can run the Operator from a central Kubernetes cluster (A), and point it to another Kubernetes cluster (B), so that when the apply an IrisCluster to B the Operator works remotely on A and plans the cluster accordingly on B.  This design keeps some resource heat off the actual workload cluster, spares us some serviceaccounts/rbac and gives us only one operator deployment to worry about so we can concentrate on the IRIS workloads.

IKO woke up and decided against the commute for work, despite needing to operate a development workload of many IrisClusters at the office that day.  Using the saved windshield time, IKO upgraded its helm values on a Kubernetes cluster at home, bounced itself, and went for a run.  Once settled back in, inspecting its logs, it could see it had planned many IrisClusters on the Office Kubernetes cluster, all at the cost of its own internet and power.

Here is how IKO managed this...

Clusters

Lets provision two Kind clusters, ikohome and ikowork.

 
ikokind.sh

After running the above, you should have two clusters running, loaded with the Cilium CNI and ready for business.

Install IKO at HOME 🏠

First we need to make the home cluster aware of the work cluster and load up its kubeconfig as a secret, you can get this done with the following.

kubectl create secret generic work-kubeconfig --from-file=config=ikowork.kubeconfig --kubeconfig ikohome.kubeconfig

Now, we need to make some changes to the IKO chart to WFH.

  • Mount the kubeconfig Secret as a Volume in the Operator
  • point to the kubeconfig in the operator arguments ( --kubeconfig )

The deployment.yaml in its entirety is below, edited right out of the factory, but here are the important points called out in the yaml

Mount

        volumeMounts:
...
        - mountPath: /airgap/.kube
          name: kubeconfig
          readOnly: true
      volumes:
...
      - name: kubeconfig
        secret:
          secretName: work-kubeconfig
          items:
          - key: config
            path: config

Args

The args to the container too... I tried this with the env "KUBECONFIG" but after taking a look at the controller code, found out there was a precedence to such things.

      containers:
      - name: operator
        image: {{ .Values.operator.registry }}/{{ .Values.operator.repository }}:{{ .Values.operator.tag }}
        imagePullPolicy: {{ .Values.imagePullPolicy  }}
        args:
        - run
...
        - --kubeconfig=/airgap/.kube/config
...

 

 
deployment.yaml

Chart

Same with the values.yaml, here I disabled the mutating and validating webhooks.

 
values.yaml

Deploy the chart @ home and make sure its running.

 

Install CRDS (only) at WORK 🏢

This may be news to you, it may not, but understand that the operator actually installs the CRDS in the cluster, so in order to work from home, the CRDS need to exist in the work cluster (but without the actual operator). 

For this we can pull this maneuver:

kubectl get crd irisclusters.intersystems.com --kubeconfig ikohome.kubeconfig -o yaml > ikocrds.yaml
kubectl create -f ikocrds.yaml --kubeconfig ikowork.kubeconfig

IKO WFH

Now, lets level set the state of things:

  • IKO is running at home, not at work
  • CRDS are loaded at work, only

When we apply IrisClusters at work, the operator at home will plan and schedule them from home.

Luckily, the whole burn all .gifs things in the 90's  got worked out for the demo.

 

Operator


IrisCluster




💥

1 Comentario
Comentarios (1)2
Inicie sesión o regístrese para continuar
Artículo
· 23 oct, 2025 Lectura de 1 min

[Dica Rápida] - Como usar URL em serviços REST API sem distinção entre maiúsculas e minúsculas

#API #CSP #Consejos y trucos #API REST #InterSystems IRIS

Olá a todos,

Esta é uma dica rápida sobre como usar URLs em serviços REST API sem distinção entre maiúsculas e minúsculas.

Se você tem uma classe que estende de %CSP.REST e Ens.BusinessService para criar um serviço REST API, e você definiu seu WebApplication em minúsculas:

XData UrlMap [ XMLNamespace = "http://www.intersystems.com/urlmap" ]
{
<Routes>
    <Route Url="/user" Method="POST" Call="User"/>
    <Route Url="/login" Method="POST" Call="Login"/>
</Routes>
}

Ele só aceitará URLs em minúsculas, por exemplo: http://myserver/myproduction/user

Se houver qualquer caractere em maiúscula, a URL não funcionará: http://MyServer/MyProduction/user

É fácil de corrigir, basta adicionar a expressão regular (?i) para permitir qualquer rota sem distinção entre maiúsculas e minúsculas.

XData UrlMap [ XMLNamespace = "http://www.intersystems.com/urlmap" ]
{
<Routes>
    <Route Url="(?i)/user" Method="POST" Call="User"/>
    <Route Url="(?i)/login" Method="POST" Call="Login"/>
</Routes>
}

Agora, ele aceita ambas as URLs:

http://myserver/myproduction/user

http://MyServer/MyProduction/user

Boa codificação!

Comentarios (0)1
Inicie sesión o regístrese para continuar