APS 把生产智能体和仪器控制拆开

政府许可

本稿由芝加哥大学阿贡有限责任公司（UChicago Argonne, LLC）撰写。该公司运营阿贡国家实验室（Argonne），该实验室是美国能源部科学办公室的实验室，合同号 DE-AC02-06CH11357。美国政府为自己及代表政府行事的人保留已付清的、非独占的、不可撤销的全球许可，以复制该文、准备衍生作品、向公众发行副本，并公开表演和公开展示。能源部将按 DOE 公共获取计划提供这些联邦资助研究结果的公共获取。http://energy.gov/downloads/doe-public-access-plan 。

在科学用户设施上把 AI 智能体部署到生产

Ming Du、Xiangyu Yin、Michael Prince、Yi Jiang、Rajat Sainju、Tekin Bicer、Yanqi Luo、Eric Codrea、Peco Myint、Nina Andrejevic、Juanjuan Huang、Trupti Mohanty、Pawan Tripathi、Dishant Beniwal、Hemant Sharma、Doga Gursoy、Aileen Luo、Tao Zhou、Chenran Xu、Jan Ilavsky、Matthew T. Dearing、Ryan Chard、Hoon Seo、Dariusz Jarosz、Elaine Chandler、Thomas Fors、Hairong Shang、Pete Jemian、Xuli Wu、Madeline Miller、Ryan Aydelott、Nicholas Schwarz、Francesco de Carlo、Byeongdu Lee、Yine Sun、Moises Smart、Philippe Piot、Joe Sullivan、Mathew J. Cherukara、Alec Sandy、Stefan Vogt、Jonathan Lang、Laurent C. Chapon

单位：美国伊利诺伊州 Lemont，阿贡国家实验室先进光子源（Advanced Photon Source，APS，一台同步辐射光源）；商业与信息系统；数据科学与学习。通讯：mingdu@anl.gov；mcherukara@anl.gov。

摘要

智能体式人工智能（agentic AI，模型自己调用工具并分步执行，而不只是回答一句话）正在从研究演示走向科学用户设施的生产使用，对象包括光源、中子源、纳米科学中心和自主实验室。它的科学价值不只是提高吞吐。智能体可以做可重复的校准、测量执行和质量控制，以及把数据变成可复核证据的初步分析，让科学家把注意力放在假设、意外观察和解释上。本文从先进光子源已部署的大语言模型（large language model，LLM，按上下文生成文字和工具调用的模型）智能体出发，抽出可以跨仪器、跨设施复用的做法。讨论的支架（harness，包住模型、会话和工具调用的运行程序）覆盖光束线控制、设施知识检索和数据分析，设计原则本身不绑定某一种实现。原则涉及推理端点、工具服务器架构、非文本数据、重计算服务、可复用技能（skill，按需加载的过程说明，不是又一个工具），以及仪器全生命周期里受治理的学习。网络和 Linux 运维、受治理的共享记忆、确定性编排，可以把这些模式延伸到设施服务。LLM 能力仍在变，这些建议只代表封面日期当时的技术快照。

缩写

1 引言

三件事碰到一起，使智能体式 AI 成为科学用户设施上说得通的生产技术。第一，近期 LLM 能稳定使用工具、用写代码解决问题、做多模态推理，并遵守针对任务的说明。第二，现代仪器控制栈给出明确的可编程接口，例如接到 EPICS 的 Bluesky/Ophyd，智能体可以经此和仪器交互。第三，MCP 越来越常用，不同支架可以用同一接口发现和调用工具 [1]。于是，交互式自然语言控制、有边界的自主执行，以及对多模态数据的当场解释，正在从孤立原型变成可部署能力。剩下的工程问题是怎样把这些能力部署好。

动机并不只是每小时多测几次。仪器和实验更强之后，科学家把越来越多注意力花在常规搭建、校准、监视、数据处理，以及从熟悉的失败模式里恢复。一个助手如果做完这些有边界的技术任务，并把测量接到文档和已验证的分析上，就能缩短从数据到可复核证据的路径，让科学家专注实验意图和科学判断。校正、决定和结果连同来源一起留下时，系统还能在仪器运行生命周期里积累知识：科学家把步骤和例外教给系统，系统以后把解释和操作知识还给新用户。带检索的设施助手、可教的仪器智能体、视觉语言实验自动化，是这些互补角色的早期例子 [2, 3, 4]。

已有系统说明智能体式 AI 在科学设施上能提供什么。面向科学的上下文感知语言模型 CALMS [2] 把文档语义检索和直接的仪器控制调用合在一起，演示了带检索和工具的 LLM 设施助手。VISION [5] 提出模块化的 cog 架构，并报告了在国家同步辐射光源二期复杂材料散射光束线上的一次语音控制实验。Vriza 等人 [3] 演示了可教的多模态多智能体系统，用来操作硬 X 射线纳米探针和一套机器人合成平台，人的反馈被留成可检索记忆。Osprey [6] 把智能体式 AI 打包成可在安全关键控制系统里生产部署的平台。PEAR [7] 把自然语言的叠层成像请求变成经过校验的重建脚本。EAA [4] 支持从交互会话到嵌入 LLM 查询的确定性逻辑。这些项目各管智能体运行的一个侧面；本文讨论的是怎样把它们的演示变成 APS 和其他设施上的日常做法。

策略来自这些已经在跑的部署：26-ID 硬 X 射线纳米探针 [3] 和 2-ID-D 微探针终端站 [4] 的仪器控制，电子日志和技术文档的检索，以及 XAS、HEDM 和叠层成像数据的分析 [7]。附录 A 收集具名实现和界面例子，正文按这些系统提供的功能来组织。先给设计原则，再给推理端点、工具服务器、数据处理、计算和技能分解的建议做法，然后延伸到网络和 Linux 运维、共享知识与记忆、跨设施服务的编排，最后给出纳米探针上的实例。这些建议不绑定某一种支架。文末指出设施眼前的需要和更长的机会。

1.1 目标架构

图 1 概括高层策略。一个设施级的 MCP/技能中枢，这里按 APS 来画，组织四类能力：

1. 从机器日志、出版物、技术报告、实验记录和其他设施来源检索知识。
2. 跨光束线的仪器和加速器控制。
3. 在线和离线科学分析。
4. 经 IRI、Globus Compute 和 MCP 工具等服务使用领导级计算。

中枢把任何遵守 MCP 契约的支架，接到提供或使用这些能力的仪器和服务。仪器环境之外的重计算作为外部服务挂上。当前例子包括 ALCF 的 Polaris 领导级系统上的 SAM3 推理和 Pty-Chi 叠层重建，以及商业云上的模型训练。图 1 画的是架构的能力，不是一套已经齐备的运行栈。身份与授权、物理安全、可观测性、来源、评测和生命周期学习，仍然是每一条辐条上的要求。第 2 节到第 3.2.4 节说明设计原则怎样决定这些部件，第 4 节说明 26-ID 纳米探针上一条仪器控制辐条怎样落地，第 5 节列出还没做出来的能力。

这四类能力还依赖共享的网络、Linux、存储和服务基础设施。第 3.4 节到第 3.6 节把架构延伸到这些依赖的运行支持、受治理的知识与记忆服务，以及在确定性执行接口之上的编排。它们是横切扩展，不是又几条仪器专用辐条。统一控制面应当提供一致的发现、资源身份、任务与结果契约，同时保留每个底层系统自己的权威。能力目录是这个设计的一个部件，不能代替它的运行时控制。

图 1：APS 上智能体式 AI 的目标能力架构。中央 MCP/技能中枢把仪器控制、科学分析、知识检索和领导级计算提供给专用应用和通用支架。图上是能力层；安全、身份与授权、可观测性、来源、评测和生命周期学习是横切要求，不是单独的辐条。

2 设计原则

• 选择从部署智能体应用的那台计算机能够访问的 LLM 推理服务。为降低运行复杂度，建议把应用部署在能直接访问仪器控制接口的计算机上。这些计算机通常在隔离的私有网络上。从该网络上的设备能访问的推理服务，可以包括机构提供的模型（例如阿贡的 Argo）和/或自托管的本地 LLM。
• 把支架和底层控制例程、数据处理包拆开。把这些工具直接做进支架，会强迫它们共享依赖，环境很难解、也很难维护。仪器有专门要求时尤其麻烦，例如遗留的 x86 库或更老的 Python 解释器。工具绑死在某一种支架上，也限制其他支架复用。
• 保证工具和控制库能一起工作。有的控制库自己管异步事件循环或线程池。工具集成应当设计成：线程安全或异步执行的问题不会把程序打崩。并行工具调用操作真实仪器时，后果可能无法预测。较好的工程做法是加守卫：把仪器或设施标成不可用，并拒绝再向忙碌对象发命令。例如加速器控制软件有一些 run-control 过程变量，表示硬件正被另一个进程修改，并阻止启动新的自动过程。即便如此，支架这一层仍应实现守卫，避免对脆弱设备做异步或多线程执行。
• 推动工具可复用。只要可能，工具应能跨支架复用。这进一步要求把工具和支架拆开，并用共同标准（例如 MCP [1]）做支架和工具之间的通信。
• 统一访问，但不要把权威混成一件事。用经过评审的确定性适配器，通过明确的请求和结果契约连接不同系统。编排器保留任务和依赖状态；执行服务执行本地权限并报告运行结果；共享记忆保留限定范围的证据和可复用知识。智能体的计划、记住的批准或完成声明，不能代替对应的执行记录或授权记录。
• 保证工具执行的物理安全。工具必须有护栏，防止错误的智能体调用损坏仪器或制造安全危险。不要靠智能体自己执行物理安全边界。除非这些边界在固件或控制库一层已经强制，工具开发者应在工具包里实现明确的校验和运行限制。智能体驱动要求独占的控制权，并且随时可以被操作员覆盖。智能体还受能力门控和命令速率限制，只能发出被批准的那几类命令。
• 仪器控制工具使用高层 API。设计仪器控制 API 时把底层例程抽象掉，把这些例程留在工具或软件实现里，不要直接暴露给智能体。这样可以减少给出大量底层 API 带来的不可预测和性能下降。工具和技能都适用同一原则。例如智能体只需要在指定位置采图，就暴露一个 acquire_image 工具，接受位置、扫描步长和其他必要参数。不要要求智能体用一串分开的调用去动电机、控光闸、采探测器数据。通用的设备级访问仍然有用，但是作为诊断和搭建时故意留下的逃生口；仪器已经定义了高层计划时（BITS 仪器就是这样），计划才是面向智能体的抽象，按信号读写是例外。
• 显式处理非文本数据。有的工具产出图像或其他高维数据，例如带 X 射线荧光或 X 射线衍射信息的微探针数据集。推理接口期望的工具结果是文本时（许多 OpenAI 兼容的 chat-completion 接口如此），必须有一条把工具产出的图像交给 LLM 的可行路径。
• 让智能体动作可观察、可复核。每一次工具调用、它的参数和返回值，都应以结构化形式记下，以便以后查询。会影响宿主计算机上的数据、改变仪器状态或无法撤销的动作，支架应支持人在回路的确认模式：操作员批准之后才执行。可观察和可确认使智能体运行可审计、可复现。
• 把学习当成受治理的生命周期，而不是不受控的自我修改。实验前，智能体可以检索以往步骤和结果；运行中，它可以在批准的边界内适应；实验后，它可以基于记下的决定、校正、失败和结果，提议记忆或技能更新。知识应双向流动：科学家教步骤和例外，智能体交回解释、证据和可复用的教训。这延伸了保留并复用人的反馈的已有做法 [3]。但提议的更新必须保留来源，只有经过评测、专家评审、版本化和批准之后才成为权威，并且有明确的回滚路径。

从原则到架构。这些原则和下面展开的部署要求，直接对应图 1 的架构。端点要可达、要有韧性，于是推理服务可配置；拆开和复用，于是有中枢和独立部署的工具服务器；并发和安全，于是有同步的控制工作进程、联锁和批准边界；高层接口和对非文本数据的显式处理，于是有稳定的工具和数据契约。计算要求推动外部分析和推理服务；可观测性和受治理的学习，要求横切的审计、来源、知识和技能登记服务。下面的部署做法按部件把这个映射做出来。

3 建议的部署做法

3.1 科学智能体的一般基础设施

#### 3.1.1 选择支架

第 2 节的原则故意不绑定支架。无论支架是 EAA [4]、Claude Code、OpenCode、Hermes Agent、VISION [5]，还是定制的 Python 应用，都适用。

建议如下：

• 工作流里没有图像时，用标准智能体支架，例如 Hermes Agent、Claude Code、Codex、APEXA 或 OpenCode。
• APS 光束线控制部署需要理解并显示图像时，用 EAA 作为起步支架，下文会说明。
• 只做叠层成像分析时用 PEAR。
• 只做 HEDM 分析时用 APEXA。
• X 射线吸收谱分析用 Dr. XAS。
• 需要更专门的功能或界面时，先看可扩展的开源支架能否提供所需核心能力；否则按光束线的仪器控制和分析要求做定制支架。

光束线控制先试 EAA，因为它已经实现本文其余部分所假设的功能：对仪器产生的图像做视觉语言推理；双向 MCP（既能消费外部 MCP 服务器的工具，也能把自己的工具暴露成 MCP 服务）；从完全由智能体驱动的工作流，到嵌入 LLM 查询的确定性逻辑的混合自主；以及可选的跨会话持久记忆。采用 EAA 的光束线几乎不用额外集成，就能继承第 4.1.1 节描述的系统布局，然后按需要扩展 EAA，或把它当作定制实现的参照。持久会话记忆提供交互之间的连续性，但它本身不是生命周期学习。信息晋升为共享的设施知识之前，应经过上面定义的来源、评测和评审。

把 EAA 当成起步，而不是硬性要求。Claude Code 适合快速原型，以及交付物就是智能体写的代码的工作流。仪器有不寻常的安全约束或硬实时要求时，专用支架可能合理。只要所选支架遵守第 2 节的原则，第 3.1.2 节到第 3.2.4 节的做法不变。

考虑可扩展的开源支架。实现新支架之前，团队应考虑社区支架能否提供可维护的核心，再按本地要求扩展。Pi 是一个具体选项：它的 MIT 许可仓库把模型 API、智能体运行时、编码智能体界面、终端 UI 和 WebUI 拆成可复用包。它的智能体层和编码智能体层已经支持持久会话树、用户消息和工具结果里的图像内容，以及可配置的串行或并行工具执行 [8, 9]。这些共享机制本身不保证光束线可靠运行，本地测试和本文的防护仍然需要。但它们能减少必须自己实现和维护的设施专用基础设施。Pi 的开发、例子和问题跟踪是公开的，扩展可以作为 npm 或 Git 包分发，本地添加也可以在原部署之外被评审和复用 [10]。

Pi 有两条写明的集成路径，不必维护一个分叉。Node.js 应用可以通过 Pi 软件开发包嵌入智能体会话；与语言无关的应用可以以远程过程调用（RPC）模式运行 Pi，用换行分隔的 JSON 命令和事件与进程交换。RPC 协议也携带扩展产生的对话框请求和客户端响应，定制 WebUI 后端可以呈现确认或输入对话框并转发用户响应，同时 Pi 保留智能体循环和会话状态 [10]。多智能体行为同样可以作为扩展加入，而不是改核心。例如 Pi 的官方子智能体扩展启动单独的 Pi 进程，支持单个、并行和链式执行，一个智能体的输出传给下一个；生成者到审阅者的序列可以用写明的链机制拼出来 [11]。

这种可扩展性有实际限制。Pi 扩展是 TypeScript 模块，软件栈主要是 Python 的团队多一层实现和维护负担。扩展和可安装包以用户的系统权限执行，接到仪器控制工具之前必须评审并约束第三方代码 [10]。而且 Pi 故意把 MCP 集成、子智能体和后台 shell 执行留在核心之外 [8]。扩展示例说明子智能体做得到，但有条件或有环的多智能体工作流需要定制编排；对照之下，LangGraph 直接表示共享状态、节点、分支、循环和并行执行，并写明了评估者–优化者和编排者–工人模式 [12]。Pi 也没有写明一种内建机制，能用可查询的会话标识释放一个正在跑的工具。这种非阻塞执行要由外部作业服务或定制的提交并轮询工具契约来补。团队在选择 Pi 或自建支架之前，应把这些集成成本和复用共享运行时的好处放在一起称。

#### 3.1.2 LLM 推理端点

部署时有两件实际的事。第一，支架可以假设一种 API 格式（例如 OpenAI Chat Completions API），但应与提供商无关，可能的话也与模型无关。端点 URL、模型名和认证密钥因此都应可配置。即使支架跑在服务账号下，也不应把配置值，尤其是 API 密钥，写死。

第二，支架应有重试：初次查询因速率限制或服务器暂时挂起而失败时再试。可以考虑主用/备用：先试首选端点（例如 Argo），主用不可达时透明地落到 OpenAI 兼容的本地模型。但切到备用路径应对用户透明，或要求人批准。

#### 3.1.3 处理工具产出的数据

LLM 提供商期望文本工具消息时（许多 OpenAI 兼容的 chat-completion 接口如此），支架必须把图像和其他不可序列化的数据分开处理。即便 API 支持更丰富的多模态内容，智能体需要访问原始数值（例如 NumPy 数组）时，支架一侧仍要设计。本节给出看图和访问数值的建议。

让智能体用视觉“看见”工具生成的图像。目标只是看见、不做数值分析时，有两种做法：

• 让工具把图像渲染成 PNG，存盘，返回绝对路径。支架加载图像，做 base64 编码，做成用户或系统消息，注入上下文。这要求工具服务器和支架在同一台计算机上，或使用挂在同一绝对路径的共享存储。支架和工具必须有契约，让支架认出图像路径。建议返回带 img_path 字段的 JSON：

{
  "img_path": "/path/to/image.png"
}

支架应解析该 JSON，字段非空时处理图像。

• 让工具把图像做 base64 编码并直接传出。支架把编码数据从工具响应里挪到随后的用户或系统消息。这不要求两边访问同一存储，但使用 Completions API 时，支架正确处理变得更重要：应拦截工具返回，从工具响应消息里抽出并去掉编码数据，再合成带编码图像的用户消息。如果支架把工具返回原样转给使用 Completions API 的推理端点，图像不会被理解，base64 还会消耗大量 token。较新的 Responses API 可以直接接收工具响应里的编码图像，但若不能保证有 Responses API，仍应实现回退。

注意：支架和工具必须有契约，让支架认出编码图像、拦截它，并以符合格式的方式送给 LLM，使推理提供商把数据认成图像。严禁把编码当文本直接送给 LLM：模型不会把 base64 看成图像，而 base64 里近乎随机的字符会用掉非常多 token。

建议返回这样的 JSON：

{
  "encoded_data": {
    "type": "image/png",
    "dtype": "uint8",
    "shape": [1024, 1024, 3],
    "data": "<base64-encoded-data>"
  }
}

两种情形里，如果工具调用的采集逻辑总是把图像存成非图像格式（例如 HDF5），工具应抽出图像、渲染成 PNG 再返回。直接返回非图像数据文件的路径、指望智能体自己加载并渲染，也可以，但不建议，因为那要求智能体再做数据抽取和图像渲染。

让智能体访问图像和数组的数值。目标是做数值分析时，数据应存盘，并把文件路径交给智能体。智能体再写加载数据的分析代码。分两种情形。

情形 1：采集后端已经把数据存成结构化格式，例如 HDF5。让工具返回数据文件路径，指望智能体写分析代码时从该文件加载或解码。文件结构复杂时，智能体应知道怎样以及在哪里找到数据（例如 HDF5 里的数据集路径）。建议把文件路径和数据集路径放进返回载荷：

{
  "data_file": {
    "name": "detector_frame",
    "type": "hdf5",
    "path": "/path/to/data.h5",
    "hdf5_dataset_path": "/exchange/data"
  }
}

另一种做法是后端存盘之后，在工具里把数据载入内存，只把相关数组存成 NPY。工具逻辑多一步，但减少智能体的工具调用和上下文用量。

情形 2：产出的数据很小，后端默认不存盘。相关数据只是一两个数组并活在内存里（例如从探测器流回来的数据）时，可以经文件存储或直接编码传送：

• 让工具服务器把数组存成 NPY，放在与支架进程共享的存储里，再返回路径和其他元数据。建议：

{
  "data_file": {
    "name": "detector_frame",
    "type": "npy",
    "path": "/path/to/array.npy",
    "shape": [1024, 1024],
    "dtype": "float32"
  }
}

此时支架可以把返回对象直接交给智能体。

• 让工具服务器把数组做 base64 编码，经 HTTP 传送。支架拦截返回对象，恢复数组，存盘，再把得到的路径发给智能体。

注意与上面相同：不要把编码当文本直接送给 LLM。建议：

{
  "encoded_data": {
    "type": "array",
    "dtype": "float32",
    "shape": [1024, 1024],
    "data": "<base64-encoded-data>"
  }
}

#### 3.1.4 工具命名

对多数 API，工具模式是平的：不同工具的模式没有层级，全部放在同一层。因此工具名必须自洽，并明确写出工具所属的功能。这既为了清楚，也为了避免同名冲突。例如 APS 2-ID-D 光束线的 MCP 服务器里有一个采图工具，不要简单命名为 acquire_image，而要命名为 aps2idd.acquire_image，以免含糊。

#### 3.1.5 让长时间的工具执行不阻塞

数据采集或复杂分析的工具可能要几分钟甚至几小时。在单线程、同步的支架里，这样的工具会堵住智能体循环，执行结束前智能体不能回应用户或做别的事。让选定的工具在后台继续，可以明显改善使用体验。

只把工具排成异步例程往往不够。OpenAI 兼容的 Chat Completions API 要求助手消息里的每一次工具调用，都先配上对应的工具响应，对话才能继续。下面的上下文是合法 JSON，但很可能被拒绝，因为工具调用 abcdef 后面跟的是用户消息，而不是工具响应：

[
  {
    "role": "assistant",
    "content": null,
    "tool_calls": [
      {
        "id": "abcdef",
        "type": "function",
        "function": {
          "name": "acquire_image",
          "arguments": "{}"
        }
      }
    ]
  },
  {
    "role": "user",
    "content": "Meanwhile, check the data at..."
  }
]

支架可以提供非阻塞执行，而不要求工具实现再采用一套异步提交加轮询的契约。一种做法是加一个可选的释放超时，把符合条件的调用放进守护工作线程。拥有图的线程在启动工作线程后等待配置的超时。若调用在该间隔内结束，支架把结果当作普通工具响应返回。若超时，支架改为返回一条临时工具响应，说明执行仍在进行，工作线程在后台继续：

{
  "role": "tool",
  "tool_call_id": "abcdef",
  "content": "{\"job_id\":\"12345678\",\"status\":\"executing\",\"description\":\"The final result will be provided later.\"}"
}

这条临时消息满足 Chat Completions API 要求的调用–响应对。它也明确告诉模型：提交的工作还在跑，最终结果稍后到达。这条消息进入上下文之后，智能体循环可以继续，模型可以回应用户并发起其他工作。

被释放的执行结束时，工作线程规范化结果，把完成记录放进本次运行范围内的队列，并通知主线程。主线程排空队列，追加一条支架定义的系统消息，里面是完成的结果。这条稍后的系统消息不是对原始调用的第二条协议级工具响应；那次调用已经和临时工具响应配对。完成信号也可以在智能体等待用户输入时把它唤醒，使完成结果及时送达。

多个被释放的工具执行可以并发。每一次执行因此应得到支架生成的作业 ID，该 ID 应同时出现在临时工具响应和稍后的完成消息里。原始工具调用 ID 仍然是把临时响应和助手的工具调用配对所必需的；但关联稍后、带外的完成时，支架拥有的作业 ID 更好，因为它稳定、对模型可见，并且不依赖提供商特定的工具调用 ID 生成方式。

支架应把完成投递限定在发起该工作的那一次图运行，以免迟到的结果被注入无关对话。但有持久后果的操作需要独立于该图运行的执行记录。压掉一条过时通知，不得删除已接受的请求、操作身份、取消状态或最终结局。上面的进程内机制本身不提供进程失败后的恢复；那种恢复需要持久的执行服务或等价的持久状态。中断或响应含糊之后，支架或编排器在重新提交工作之前应先与该服务对账，因为一个没有得到回答的请求并不能证明操作从未被接受。取消请求同样不应在没有确认时被报告成“取消已完成”。记忆摘要可以引用这些记录，但不得替换它们；第 3.6 节把这一区分延伸到跨服务工作流。

另一种做法是把长操作拆成提交工具和状态查询工具。智能体先调用提交工具，它立即返回，执行在服务器上继续；之后调用状态工具取得进度或最终结果。但这要求工具一侧专门设计，迫使智能体多做工具调用，并带来何时、以何种频率查询状态的问题。现有同步工具必须在不做这种改动的情况下被支持时，把释放和完成机制留在支架里通常更简单。

#### 3.1.6 部署计算密集的工具

神经网络或 GPU 加速的数据处理器这类计算密集工具，可以部署在有合适硬件、并且能用 HTTP 连到支架所在计算机的机器上。

边缘设备。为把计算负载和光束线计算机上的其他活动隔开，可以考虑 NVIDIA DGX Spark 这类边缘计算设备。工具仍应暴露为 MCP 服务器，以尽量兼容各种支架。工具返回图像时，遵循第 3.1.3 节。工具不做仪器控制时，异步执行和线程安全的要求可以放宽，MCP 前端和计算后端也不必像第 3.2.2 节那样拆成两个进程。

HPC 推理端点。ALCF 在 Sophia 高性能计算系统上托管若干基础模型 [13]，其中包括通用的、基于提示的图像分割模型 SAM3。光束线实验需要图像分割时，考虑用这项服务，而不是另外部署一套推理实例。

具体例子：第 4.1.1 节描述的 26-ID 纳米探针部署，把分割推理卸载到 ALCF 托管的 SAM3 端点。一台有公网的计算机上的薄 SAM3 客户端，向跑在 ALCF 上的 SAM3 推理服务器发请求；结果写到文件交换存储，由本地工具服务器取走。这个模式——光束线上的轻客户端、场外的重计算、共享文件系统做交接——可以推广到任何不直接驱动硬件的计算受限工具。

#### 3.1.7 面向特定任务工作流的结构化会话状态

支架通常把以往消息放进每一次请求，在无状态的推理调用之间维持连续性。对专门的实验工作流，另一种做法是用后续决定所需信息的结构化记录来构造上下文。相关实验状态可以显式表示时，这合适；涉及开放式用户交互或异构工具使用的工作流，可能还需要对话历史和详细的工具结果。通用支架可以按任务把这些表示合起来。如第 3.1.1 节所说，保留会话信息提供连续性，但不构成生命周期学习。

在生物纳米探针上部署的 X 射线荧光感兴趣区查找器里，保留实验意图、已校验的控制值、选定的反馈事件，以及已处理扫描的标识。循环里的六个模型作业——上下文解释、反馈解释、级联深度决定、结果复核、投票评估、框细化——各自收到这份记录的紧凑渲染，包括当前控制和最近十个事件，每个事件封顶在几百个字符。这样，专门作业都能看到保留的实验状态，而不必每个作业都收到完整交互记录。够不够用，取决于保留的字段是否抓住了工作流所需的信息；记录里省略的约束或观察，除非另外提供，否则后来的决定用不到。记录例子如下：

{
  "intent": "find individual zinc-rich cells, tightly bounded",
  "state": {"channels": ["Zn", "Ca", "K"], "max_rois": 5,
            "roi_grouping": "individual", "size_band": [49, 197]},
  "events": [
    {"t": "2026-08-15 14:02:11", "kind": "feedback_text",
     "scan": "bnp_fly0001",
     "detail": "the boxes are too large, I want individual cells",
     "patch": {"roi_grouping": "individual"}},
    {"t": "2026-08-15 14:05:40", "kind": "verdict",
     "scan": "bnp_fly0001",
     "detail": "accept 1 2, reject 3 4 5; banked 2 positive, 3 negative"}
  ],
  "processed": ["bnp_fly0001.mda.h5"]
}

支架把结构化记录持久化，以便重启后恢复，并与第 3.1.2 节的备用推理端点一起复用。控制更新在存储前校验，每次事件之后原子地替换文件，事件记下变更后的控制。恢复路径（--resume-session）恢复意图、控制和已记录的历史，已处理扫描的标识让工作流跳过已记为完成的扫描。这些机制保留显式记录的状态，但不保证跨端点的模型行为等价，也不恢复被排除在记录之外的信息。事件日志也为第 3.2.4 节的受治理回写和第 5 节提议的可观测性服务提供来源；把会话信息晋升为共享技能或记忆，仍须经过第 2 节的评测和评审。

构造上下文也影响推理效率。限制渲染出的记录可以限制它对输入长度的贡献，但反复改写前面的提示块，会降低支持提示缓存的端点上的前缀缓存复用。API 允许时，稳定的指令和工具定义应放在变化的会话信息之前。在重放消息历史和从结构化状态重建上下文之间选择时，应考虑信息需求、输入长度、缓存复用，以及测到的延迟或成本。

3.2 仪器控制智能体

#### 3.2.1 安全边界与最小权限

仪器控制智能体必须被当成会出错的操作员，而不是安全控制器。提示和技能可以描述约束，但这些说明不是可强制的安全边界，因为模型可能理解错或用错。因此建议纵深防御：每一个被请求的动作都经过与模型行为无关的控制。物理行程、速度和加速度限制、禁止的仪器状态组合、光闸和探测器联锁、曝光界限、命令速率限制，应尽可能在固件或 EPICS/Bluesky 控制层强制，否则就在确定性的工具代码里强制。超出允许运行包络的请求应在到达硬件之前失败关闭；现有的机器保护系统和操作员的立即覆盖仍然是权威。

确定性步骤同样应表示成可执行接口，而不是只写在提示里。重复的校准、采集或恢复工作流应包成高层工具、经过校验的外部 API，或随技能分发的已测试脚本。智能体选择例程并提供有界参数，程序逻辑决定底层操作序列。对仪器控制步骤，随技能分发的脚本应调用与支架相同的、有访问控制的工具或控制接口；它们不应另开 EPICS 连接，或生成绕过这些控制的直接 EPICS 或 Bluesky 命令。可用接口只应暴露该智能体角色所需的、在允许名单上的工具、计划、设备和 PV，读写权限在可行处分开。这样技能仍是文档和编排，而遵守它的文字不是防止不安全动作的唯一保护。

控制层还可以再加一道护栏。专为智能体配置的 EPICS 网关可以默认只读地暴露一组命名的 PV，只对某个工作流需要的通道授予写权限。网关位于智能体主机和控制系统之间，限制与哪一种支架、工具服务器或脚本在跑无关，也不能被智能体代码的改动或自己开连接的技能取消。专用网关实例还给设施一个自然的位置，把智能体流量和普通客户端流量分开记录和限速。因此网关是画出读写边界最稳的一点，工具级检查是第二层，不是唯一一层。

最小权限还必须延伸到宿主计算机和相连服务。智能体生成的代码和第三方扩展应在专用的非特权账号下运行，环境只暴露工作流所需的资源。在 Linux 上，Bubblewrap 可以构造挂载命名空间，只有选定的文件系统部分可见 [14]；实验输入可以只读挂载，写入限制在指定的暂存和输出目录。Bubblewrap 提供的是隔离机制而不是完整安全策略，它的命名空间和挂载配置本身应被当成与安全相关的部署代码。单个工具服务器也可以跑在容器里；智能体需要通用 shell 或代码执行时，整个支架都可以容器化。无论哪种，部署只应挂载所需的文件、设备和套接字；对进程、内存和计算时间施加适当限制；网络只允许到达批准的推理、工具和数据服务。凭据应尽可能留在需要它们的服务或工具里，而不是暴露给智能体。本地服务可以绑定回环或私有接口，远程调用应认证并授权。这些措施限制错误代码执行的后果，但不代替仪器上的访问控制和安全联锁。

资源隔离本身不能防止两个合法客户端同时指挥同一台仪器。每一条改变状态的访问路径因此应参加同一把锁，实现在工具或控制层，并最好在智能体、图形界面、笔记本和自动化脚本所共享的最近点强制。只有持锁的调用者可以驱动受保护的仪器；竞争请求应被拒绝或排队，直到锁释放。锁应记录所有者和范围，持有者失败时安全过期，并支持显式释放和操作员撤销。支架级守卫对防止同一次智能体会话里的并行调用仍然有用，但挡不住绕过支架的第二个客户端。下面讨论的 Bluesky Queue Server 所用的单操作 RunEngine，为经过 Queue Server 的请求提供这种串行化。直接的 EPICS 客户端仍在该边界之外，除非锁也在共同的控制层或固件里强制。

最后，预防性控制应配上确认、审计和软件治理。有后果或不可逆的仪器动作，以及修改宿主数据的操作，应在支架上要求人确认。结构化日志应记录已认证的调用者、所选工具、已校验的参数、结果、锁状态和任何操作员覆盖。工具和技能部署应使用经过评审的版本化发布，带认证的晋升和回滚路径。这些记录使失败可诊断，并防止未经评审的扩展、技能或智能体生成的记忆悄悄改变生产行为。

#### 3.2.2 工具服务器以及与控制系统的集成

建议把工具和支架拆开。为减少依赖冲突并促进复用，每个工具服务器放在自己的仓库里，有独立的依赖集，跑在专用环境里。

必须避免从异步函数直接调用 Bluesky、Ophyd 这类仪器控制库时出现的异步执行和线程安全问题。FastMCP 等常见 MCP 库和 FastAPI 等 Web 框架允许同步例程，但它们底下仍可能跑事件循环，尤其是 HTTP、SSE 或可流式 HTTP 传输。建议把异步例程和调用控制库的例程分清；后者如果实现在工具里，为了最大安全应完全同步。

图 2 画出为与仪器控制库安全互操作而设计的工具的可能实现。最基本的情形是仪器控制例程必须实现在工具自己里面，工具服务器由 MCP 前端和仪器工作进程后端组成。

• 前端通过 MCP 接口暴露工具函数，可以使用异步操作。
• 后端用 Bluesky、Ophyd 或其他控制库实现仪器控制例程；所有仪器控制调用必须保持阻塞且同步。

前端和后端经 ZMQ 通信。后端可以跑一个循环，轮询前端请求，收到后同步执行每一个仪器控制例程。这个设计不特定于某一种控制库。仪器工作进程后端可以用任何合适的库，只要调用保持阻塞且同步。

工具服务器应只依赖 MCP/FastMCP、ZMQ、所选的仪器控制库和其他必要包。它不应和支架共享依赖要求。更受限制的环境里（例如仪器控制需要 Python 2.x，与 MCP 等前端依赖不兼容），前端和后端可以放在不同仓库，仍用 ZMQ 通信。前端也可以做成不含 MCP 的简单 HTTP 服务器。这要求支架里有一个 HTTP 客户端，包成智能体可调用的工具，被调用时查询服务器。除非服务器和客户端采用允许客户端自动取回模式的契约，工具模式还必须定义在客户端一侧。这种替代降低工具服务器的可移植性，因为不是每个支架都认识这种契约。

图 2：为异步执行和线程安全而设计的、支架与仪器控制工具服务器的建议集成。关键是把异步的 MCP 或 HTTP 前端，和真正做仪器控制的例程分开。MCP 前端可以处理与智能体进程的异步通信。真正调用控制库（Bluesky、Ophyd 等）的例程应放在单独的工作进程里，该进程同步、阻塞，经 ZMQ 与前端通信。光束线上已经有 Bluesky Queue Server 这类解耦的仪器控制服务器时，工具服务器可以从异步例程直接与该仪器服务器通信。BAIT MCP 是这一情形的已部署实例：它只含 MCP 前端，Queue Server 充当仪器工作进程。

#### 3.2.3 与现有服务器和图形界面集成

光束线上已经有独立的仪器服务器时，工具服务器模式可以放宽：工具服务器只需向仪器服务器投递，而不自己调用控制库。例如 Bluesky Queue Server 托管仪器控制例程，经 ZMQ 被调用。它可以看成上面设计里工作进程后端的替代。光束线上有 Queue Server 时，MCP 前端可以直接经 ZMQ 与它通信，MCP 服务器仓库不再需要自己的工作进程后端。光束线上已经有服务器在听 HTTP 或 ZMQ 上的 EPICS 命令并代调用者执行时，也是类似情形。MCP 前端可以直接请求该 EPICS 服务器，而不维护自己的后端。

图 3（原文给出示意图说明，HTML 未附独立图像文件）：建议把支架和已有图形界面应用集成。这要求应用能干净地分成前端（图形界面）和后端。后端实现仪器控制和/或数据取回，并维护一个状态对象。该状态对象是应用图形界面和 MCP 服务器唯一的事实来源。用户可以从智能体（经 MCP 服务器）或从应用图形界面读写状态，两边保持同步。

有些控制能力或可视化界面已经由带图形界面的现有应用实现时，只要应用能干净地分成前端和后端，MCP 服务器和应用就可以合作。后端实现仪器控制（例如与 Queue Server 通信，或跑自己的控制例程）或数据取回。它还维护并暴露一个状态对象，应用前端和 MCP 服务器都可以读写。应用后端拥有的状态成为唯一事实来源，于是 MCP 服务器和应用在仪器状态上保持同步和一致。光束线上的图形界面已经在听并向 Queue Server 投递时，Queue Server 很适合充当应用后端。

Bluesky Queue Server 还有一个好处：不阻塞。服务器网关和控制引擎的原生对账，使 Queue Server 端点可以异步，执行 Bluesky 计划的同时仍能听其他查询。有了这一点，工具或支架的开发者可以实现异步路径，让用户从智能体界面暂停或停止正在进行的操作，或查看其状态。

12-ID 的闭环实验把关键模块做成微服务器，覆盖湿化学平台、机器人样品处理、数据采集、数据约简、后处理和实时 CNN 分析。每个模块暴露最小的命令集，细粒度控制经图形前端访问。这个架构把主编排循环和单模块失败隔开，同时监视所有服务器活动。

例子：APS 光束线上的 B-PILOT 和 AutoPILOT。这个图形界面集成模式的一个实例正在为扇区 1、20 和 3 的光束线开发。B-PILOT 是独立的图形应用，用来构建、排队和监视 Bluesky 计划：它通过每条光束线的配置档发现该光束线可用的计划和设备，直接从每个计划的签名和文档字符串生成参数表单，经光束线的 Bluesky Queue Server 分发运行。Queue Server 拥有仪器状态，在图 3 的意义上充当唯一事实来源。AutoPILOT 是嵌在 B-PILOT 里的可选智能体层，作为一个聊天面板。它是多轮 LLM 智能体，共享 B-PILOT 的后端状态，并通过只读查找工具枚举已加载的设备和计划、回答关于它们的问题、起草计划命令，用户在排队或运行之前复核——每一次改变状态的动作都有人在回路，符合第 2 节的确认原则。智能体配置到 Argo 端点。重要的是，AutoPILOT 是受守卫的可选导入：没有它，B-PILOT 也能完全独立运行，因此没有推理端点时界面仍可用；有它时，图形界面和智能体读写同一后端状态。计划中的 MCP 前端还会把 B-PILOT 的后端暴露为在中枢登记的工具服务器，让外部支架消费同一套仪器控制能力。附录图 A7 是带嵌入 AutoPILOT 面板的 B-PILOT 界面。

图 A7：B-PILOT 软件界面，嵌入的 AutoPILOT 面板提供通向 B-PILOT 的智能体接口。

例子：APS 光束线上的 BAIT MCP 和 BITS。BITS [15] 是在 APS 上构建 Bluesky 仪器所用的模板结构。BITS 仪器仓库用声明式配置定义设备和计划，它的 startup.py 构造一个 Guarneri 注册表，把设备名映射到 RunEngine 工作进程命名空间里的活 ophyd 对象。同一仓库可以不加修改地跑在控制台会话、笔记本或 Bluesky Queue Server 下。数十条 APS 光束线现在维护这样的仓库。对智能体部署的后果很大：因为每台 BITS 仪器呈现同一注册表结构、同一权限文件和同一 Queue Server 控制面，一个工具服务器就可以服务它们全部。把仪器层标准化，才把每条光束线的智能体集成变成一次性成本。

BAIT MCP [16] 就是那个工具服务器。它是 MCP 前端，也是 Queue Server RE Manager 的单个 ZMQ 客户端，除此之外什么都不是：它不实例化 ophyd 设备，不开 EPICS 通道，不跑第二个设备会话。这是图 2 模式的最简形式：Queue Server 就是仪器工作进程后端，工具服务器只保留异步前端。设备读写在 Queue Server 的活会话里执行；计划经队列被枚举、入队和执行。服务器默认绑定回环，并暴露可流式 HTTP 的 MCP 端点，任何会说 MCP 的支架都能消费它。工具面见表 1。

表 1：BAIT MCP 暴露的工具。每个工具返回带 ok 标志的 JSON 对象，于是未满足的前提（Queue Server 不可达、环境已关闭、未知设备）表现为失败的工具调用，带有解释性的 error 字段，而不是异常或挂起。

安全联锁来自 Queue Server 执行每一种请求的方式。BAIT MCP 把设备读和设备写以不同方式送给 RE Manager。读作为后台任务提交，不争夺 RunEngine，因此计划在跑时智能体仍可查询电机位置或探测器值，而不打扰它。写在前台提交，RunEngine 在它用来跑计划的同一个单槽里执行写。因为该槽一次只持有一个操作，计划进行中发出的写无处执行，被 Queue Server 拒绝，而不是和计划赛跑。智能体因此被控制系统本身阻止在扫描中途驱动硬件，而不是靠它自己克制。这个保证有两条限度必须说清楚。第一，联锁的范围是 Queue Server 自己的 RunEngine，不是硬件：它只能拒绝经过 RunEngine 的操作，看不见手工 caput、第二个 EPICS 客户端，或操作员点动电机。BAIT MCP 假设 Queue Server 是仪器的唯一控制器，这是 Bluesky Queue Server 的标准运行模型。第二，set_device 和 run_plan 在调用时就驱动。BAIT MCP 按设计不实现人在回路的门。批准是支架级的策略决定，在每个工具服务器里重复实现会使它在服务器之间不一致，并且对坐在支架前的操作员不可见。消费方支架因此必须提供第 2 节描述的确认模式。这个分工是故意的，但它是契约：消费 BAIT MCP 却不实现该门的支架，会在没有复核的情况下驱动硬件。

#### 3.2.4 把光束线步骤分解成技能

技能 [17] 越来越常用，但它们不代替工具。把工具作为服务器来跑的一个关键好处是运行时管理更容易：工具服务器可以跑在另一台计算机上，有自己的依赖和环境。只用技能达到同样能力是可能的，但需要更多由智能体驱动的步骤、更长的执行路径和更高的风险。设计得好的工具也更安全、更确定，因为底层例程是固定的，由程序逻辑控制，而不是由 LLM 临时生成。但工具模式会被注入上下文，工具数量很大或模式过长会消耗大量上下文并降低表现。为兼得技能和工具的长处、避开短处，建议：

• 只要可能，只把高层抽象做成工具。能包在一起的底层 API 就不要单独暴露。
• 把长而细的文档做成技能，而不是放进工具的文档字符串。只在需要时加载技能文本。用技能提供文档和说明，解释智能体应怎样使用工具。
• 技能可以包含可执行脚本或编码说明，但避免需要支架里还没有的依赖的脚本或 API。依赖重的可执行文件应部署成工具服务器，而不是包进技能。若确实有无法避免的理由不用工具来承载带额外依赖的脚本或 API，可以考虑在技能目录里放一个本地、隔离的 uv 或 pixi 环境，供智能体激活。

更难的问题不是用不用技能，而是怎样把光束线工作分解成技能。APS 使用下面的框架。

粒度规则。一个技能对应一个连贯的多步工作流，有经验的光束线科学家会把它说成一个步骤：“对准波带片”“在特征 X 周围做线扫描”“提交并后处理一次叠层重建”。能分解成单次硬件动作的操作（动一个电机、读一个计数器、采一张图）仍是工具，不是技能。所用的检验是：去掉这个技能，是否会迫使智能体每次都从原始工具调用重新推导该步骤。如果是，这个步骤就值得一个技能。

组合。技能可以调用其他技能，但底层的仪器控制动作应仍是 MCP 暴露的工具。技能是文档和编排；它不得嵌入绕过工具服务器的仪器控制逻辑。这避免让智能体用 EPICS 或 Bluesky 直接即兴编写仪器控制命令。

按需加载。支架应把技能元数据（名称、一行描述、适用仪器）暴露给 LLM，但只在技能被调用时加载完整技能正文。这样可以扩展到几十或几百个技能而不膨胀提示，也与上面对工具模式建议的按需模式一致。

命名、版本、审计。技能是代码：它们应得 kebab-case 名称、语义化版本和评审流程。驱动电机或以其他方式改变仪器状态的技能，部署前应再过一层评审。

生命周期学习与知识治理。技能登记处应支持受控循环：捕获观察，提议为更新，评测，由科学家评审，晋升为版本化记录，随后监视或回滚。科学家应能教步骤、约束、例外和诊断线索，智能体可以基于记下的会话提议更新。每一次更新，登记处应保留来源科学家、仪器上下文、支持证据、适用条件和评审状态。这个过程让积累的经验变成持久知识，而不允许未验证的记忆改变生产行为。第 3.5 节把这一生命周期延伸到跨智能体、跨运行的共享证据、运行片段和派生状态；第 3.6 节把它们的复用和执行权威分开。

#### 3.2.5 实例：最小的纳米探针技能集

下面的例子说明 26-ID 硬 X 射线纳米探针上工具和技能的组合：

• 工具 acquire_coarse_scan：在指定位置做粗扫描。
• 工具 acquire_fine_scan：在指定位置做细扫描。
• 工具 segment_image：用带提示的 SAM3 分割图像。该工具是 ALCF SAM3 推理端点的代理。
• 工具 render_image_for_agent：把 TIFF 或 NPY 文件渲染成 PNG。
• 工具 execute_python_code：执行 Python 代码。调用者可以指定最后打印的一行是图像路径，此时支架取回图像并在后续消息里送给 LLM。
• 技能 roi-search-workflow：记录问题陈述、所需信息、步骤和提示，用于在样品里搜索用户描述的感兴趣特征。
• 技能 zone-plate-focusing：记录校准步骤、锐度度量和接受标准，并说明怎样使用聚焦光学元件所需的移动和采图工具。

同一组工具和技能组合起来，支持第 4.1.2 节的交互会话。它们让智能体做有边界的校准、采集和初步特征定位，科学家仍掌握科学目标、解释和有后果的决定。

3.3 科学数据分析智能体

#### 3.3.1 与确定性分析软件集成

科学数据分析智能体应当编排经过验证的分析软件，而不是让 LLM 直接做数值分析。在这个架构里，确定性工具做数值运算，LLM 做计划、解释和检查。智能体因此可以在已建立的分析软件之上提供对话式编排层，同时保留专家用户所期望的可解释、可编辑和可审计。这种分工让智能体帮助把原始测量变成可复核的科学证据，而不把语言模型当成经过验证的数值方法或专家解释的替代品。

#### 3.3.2 可复核的科学产物和来源

上面的部署做法处理的是可复用、安全的智能体系统所需的后端结构，但生产采用还取决于面向用户的科学界面。在许多分析工作流里，尤其是依赖模型的解释，用户不会仅仅因为智能体返回了最终答案或报告某次工具调用成功就信任它。智能体应把中间科学状态暴露成领域专家熟悉、并与现有分析实践兼容的形式。

因此，分析工具返回的不应只有机器可读的结果，还应有结构化的、可复核的科学产物。这些产物可以包括图、参数表、拟合报告、工程文件、来源记录和可导出的数据产品。

#### 3.3.3 渐进自主和专家监督

实践中，科学分析支架应支持渐进自主。用户可以先让智能体建议分析计划，再批准具体工具调用，检查中间结果，修改约束或拟合范围，并只重跑受影响的那一步。这种交互使智能体系统更兼容现有专家工作流，并降低自动化遮蔽科学判断的风险。

#### 3.3.4 实例：用 Dr. XAS 做 XAS 分析

X 射线吸收谱是一个有用的例子。在智能体式 XAS 工作流里，可执行工具可以做确定性操作，例如加载谱、归一化、XANES 参考比较、抽取 EXAFS 信号、生成 FEFF 路径、最小二乘拟合和生成报告。但面向用户的响应还应显示专家复核所需的假设和产物：拟合范围、固定或受约束的参数、带不确定度的拟合参数、诊断指标、残差，以及社区惯用表示里的图。图 4 用 Dr. XAS 里的 EXAFS 拟合工作流说明这一点：智能体既返回惯用的拟合产物，也返回解释它们所需的假设。

图 4：智能体式 XAS 工作流里面向用户的产物。Dr. XAS 暴露惯用的 EXAFS 分析输出，包括 R 空间和 k 空间拟合、带不确定度的拟合参数、拟合质量诊断，以及与固定模型假设（例如 S0 的平方）相关的解释注意事项。这个例子说明科学分析智能体应返回可复核的产物和假设，而不只是最终文字答案或已完成的工具调用。

#### 3.3.5 实例：用 APEXA 做 HEDM 分析

APEXA 在自然语言界面后面编排 MIDAS 晶体学流水线（校准、方位积分、Rietveld/GSAS-II 精修、晶粒成图）。支架采用多智能体模式：确定性的关键词路由器把每个用户查询分发给五个范围限定的专家之一（校准、分析、知识、电机、可视化），每个专家只看见与自己职责相关的那一部分 MCP 工具。六十个工具分布在三个 MCP 服务器上（核心文件操作、MIDAS 分析、EPICS 电机控制）。因为工具登记按专家限定范围，电机智能体不能调用破坏性的文件写入或长时工作流工具，安全来自构造，而不是来自提示。APEXA WebUI 的截图见附录图 A8。

图 A8：APEXA 的 Web 界面，用于 HEDM 分析的先进光子实验助手。

下接同一来源的续篇：第 3.4 节至附录。

出处：Ming Du 等，Strategies for Deploying AI Agents in Production at Scientific User Facilities，2026-09-28，https://arxiv.org/abs/2609.36362 ，CC BY 4.0；另有美国政府许可，允许复制、准备衍生作品并向公众发行。