APS 生产智能体：运维边界、编排和加速器实例

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

上篇到第 3.3 节。这里从第 3.4 节继续，到附录和出处。

3.4 面向网络和 Linux 运维的 AIOps

#### 3.4.1 跨服务依赖的运行支持

仪器智能体的部署原则也适用于支撑采集、分析和数据移动的网络与 Linux 基础设施。这里用 AIOps 表示对这套基础设施的智能体协助调查、变更评估和恢复。调查的对象应是受影响的服务及其依赖，而不只是报告症状的主机或仪器。例如一次采集失败，可能需要采集进程、它所在主机、网络路径和目标存储服务的观察。智能体应返回一份可复核的说明：受影响的资源、支持性观察、尚未排除的其他解释，以及下一步诊断或运行动作。本节和后面两节的建议延伸前面的部署模式；它们不是一份设施级自主运维部署的实测报告。

#### 3.4.2 由证据引导的诊断

对反复出现的调查，必需的证据收集应由工作流强制，额外的假设探索仍由智能体引导。主机相对网络的调查应解析相关主机接口和网络附着，在可比较的时间区间上对照观察，并查阅适用的配置和变更记录。文档解释一项观察可以怎样解读；它不确立系统的当前状态。同样，一次成功的工具调用并不确立所需观察已经拿到。工作流状态应区分：可用证据、完成了观察但没有匹配发现、仪器不可用、访问受限、收集失败。缺失的观察应保持为明确的限制，而不是被算成已满足的诊断要求。

证据跨越采样间隔或保留策略不同的系统时，这个区分尤其重要。近期的主机事件和更早的交换机快照不应被当成同时的观察；收集路径不可用时，空的错误日志不能确立健康。几台主机出现相关症状时，工作流应在提议分别修复之前先检查共享依赖。有用的退出条件是一项有支持的发现，或为区分剩余解释所需的下一项观察，而不仅仅是完成了固定次数的工具调用。

#### 3.4.3 诊断协助和经过核实的恢复

只读诊断本身就是一条有用的运行边界。智能体可以定位失败、指出有支持的原因，或指定一个有判别力的测试，而干预的责任仍在管理员。诊断、提议的变更、经授权的执行和经过核实的恢复因此应分开记录。允许变更的地方，行动之后的观察应确立受影响的服务是否满足明确的接受标准；命令完成本身不证明恢复。评测应把专家确认的诊断正确性、没有支持的归因、到达有用发现的时间、操作员花费的力气，和自主解决区分开。监视同样应把进程在不在，和证据收集与投递是否成功区分开，以免观察路径已经失败、进程却还在跑的智能体被报告成运行健康。

3.5 面向编排式自主流水线的 KnowledgeOps

#### 3.5.1 带类型和范围的记忆

这里用 KnowledgeOps 表示智能体消费和生产的知识与记忆的受治理生命周期：捕获、组织、检索、验证、复用、修订和退役。RAG 是这个生命周期里的一种访问机制，不是整个记忆架构。有用的记忆区分语义笔记、按时间索引的片段、派生的状态投影、版本化的步骤，以及智能体日志。它们是不同种类的信息：记录下来的知识或解释、发生了什么、从记录事件推断出的状态、任务应怎样做，以及一个工作者对自己活动的叙述。每一种都应保留作者、资源和项目范围、证据关系，以及适用的时间或版本。有来源依据的解释在其支持被评估之前仍是派生主张；附上一条引用并不使该解释成为一手证据。

检索应跟着信息需求走。相似性搜索适用于类似事件，基于标识的检索适用于已知记录，按时间和实体限定的查询适用于运行历史，对定义好的总体做显式汇总适用于计数和趋势。返回的相关段落数量，或事件样本，都不能确立设施级的失败率。活的运行状态应从其权威服务或足够新的观察取得，任何派生投影都应标明自己是派生的。记忆被检索和复用时应做访问检查；共享摘要不得绕过对其源记录的限制。

#### 3.5.2 来源、时间有效性和并发更新

来源标识和派生关系应在摘要和智能体交接之后仍然存在。几个工作者重复从同一条日志条目派生的解释，并不构成独立印证。来源是否存在、它的修订是否仍是当前的、它是否支持某一具体主张，是分开的问题。支持性记录被更正或取代时，依赖它们的记忆和步骤应被标出来重新验证，或标成需要评审，而不抹掉它们被使用过的历史记录。

并行工作者也可能观察到不同修订，或在操作员已经改正共享状态之后才结束。对派生状态的更新因此应标明它们所依据的版本，并拒绝或重新评估冲突的过时写入，而不是谁后到就接受谁。片段应保留事件何时发生、何时被记录，以及一项主张适用的区间。派生投影应暴露自己的新鲜程度，以及它们已经通过哪些事件被更新。这些区分让后来的调查能把系统行动时知道的东西，和事后记下的信息分开；它们不会使不完整的观察历史变完整。

#### 3.5.3 从运行片段到可复用步骤

完成的工作流应保留一个片段：尝试了什么、相关条件、证据和观察到的结局，包括失败或没有结论的做法。这份记录可以支持一个候选步骤，带明确的前提、所需观察、期望输出和失败处理。晋升为共享的运行知识，应遵循第 3.2.4 节的评测、专家评审、版本化和回滚，而不是依赖智能体对自己成功的叙述。适当的检查可以包括确定性分析、新的运行测量或专家接受。在别处复用的步骤必须检查对接收环境是否适用；在一台主机上成功的干预不是普遍药方。这建立一条从执行到可复用知识的受控反馈路径，而不授予记忆改变生产行为的权威。

3.6 经确定性控制面做设施级编排

#### 3.6.1 盖在现有权威之上的共同接口

设施级控制面应提供一种一致的方式，在原本各不相干的系统上发现能力、识别资源、提交有界工作并检查其结局。这是逻辑集成层，不是要求替换现有控制系统，或把全部特权集中到一个服务。网络管理、Linux 管理、存储、仪器控制、计算和知识服务可以保留自己的执行引擎和管理边界。经过评审的确定性适配器应把共同请求翻译成适当的原生接口，保留每个系统的授权、并发和运行限制。目录或共享的 MCP 端点使发现和调用成为可能，但本身不建立共同的资源身份、动作权威或完成语义。

共同契约应无歧义地标明目标资源、所请求的能力和接口版本、已认证的调用者，以及适用的范围。资源关系应支持沿依赖导航，而不假设不同系统的名字或标识可以互换。不支持的能力和无法解析的身份应是明确的失败，而不是让智能体猜测目标或发明另一条访问路径的场合。这样得到的控制面可以在独立部署的服务之间联邦化，同时对智能体和操作员呈现连贯接口。表 2 概括责任边界。

表 2：统一设施控制面里建议的责任边界。共同接口并不把全部权威转给智能体、编排器或知识服务。

#### 3.6.2 可执行契约，而不是只有提示的集成

重复操作应表达成经过测试、版本化的例程，带已校验的参数和明确前提，遵循第 3.2.1 节。智能体选择一项能力并提供有界参数；确定性代码解析目标、校验请求、执行批准的序列并报告结果。工作流已经建立的地方，它的例程转移不应要求模型在每一次运行时重建底层命令。智能体生成的集成代码可以提议并测试，但应进入与其他生产代码相同的评审发布过程，而不是变成一条短暂的特权执行路径。

底层服务支持时，契约应区分观察、变更提议、执行、状态取回和取消。批准应关联到具体目标、提议的变更和适用的有效条件，并在执行前再检查一次。人的确认可以由支架集中呈现，如上文所述，而执行服务强制已认证的权限和适用的批准条件。脚本、笔记本或第二个智能体不得用另一条路径到达同一资源来绕过这些条件。返回的观察应带上来源、时间和覆盖范围；改变状态的结果应标明已接受的操作、执行状态、受影响的资源和可用的行动后证据。确定性执行使这些规则明确且可测试；它不保证分布式操作会成功，也不保证智能体选对了操作。

#### 3.6.3 持久的工作与有界编排

编排器可以用智能体分解目标、选择步骤或评估发现，但它的运行时应在任何工作者的对话之外，保留持久的任务身份、依赖状态、执行引用和接受条件。一次交接应携带目标、资源范围、约束、适用的步骤版本、可解析的证据引用、已完成的观察和未解决的问题。工作者只应收到其任务所需的能力和上下文。替换工作者或推理端点，于是可以保留工作的已记录依据，而不暗示模型行为等价，也不恢复从未被保留的信息。

并行工作应由服务容量、资源所有权、速率限制和明确的时间或成本预算来限定。只读调查在被支持的地方可以并发进行，冲突的变更则需要在共享的执行边界上仲裁。中断或响应含糊之后，运行时应先与执行服务对账再重新提交。稳定的操作标识和幂等的记账并不保证外部效果恰好一次；跨越几个系统的操作可能只完成一部分。这类工作流需要明确的部分失败状态，以及在支持这些动作的地方经过评审的恢复或补偿动作。取消请求不应在没有确认时被报告成取消已完成。

接受应依赖针对任务的证据，而不只是工作者的完成消息。应按任务应用确定性检查、新的服务级观察和专家复核，接受标准未满足时做有界的重试或升级。KnowledgeOps 可以保留已接受的结局并提议步骤更新，但记住一次过去的批准不得授权后来的动作。控制面、编排器和记忆服务于是支持连续运行流水线的互补部分，而不把证据、执行和权威混成一件事。

#### 3.6.4 跨域调查的示例

设想几台采集主机报告向共享存储服务的传输停住了。编排器可以建立一个事件，协调主机、网络路径和存储三方面的调查。确定性适配器解析资源身份，并在可比较的区间上收集观察。KnowledgeOps 可以取回以前的事件及其经过评审的步骤，作为假设的来源，而不是作为当前失败的诊断。若当前证据支持存储侧的访问变更是原因，诊断结果可以被接受，并向负责的操作员提议一项范围限定的变更。执行服务记录经授权的干预，独立的服务级测试决定传输是否恢复。该事件、不成功的假设、来源引用和经过核实的结局，随后可以进入受治理的知识生命周期。这个例子说明所提议的责任分离，而不是报告一次测到的自主恢复。

4 演示

4.1 26-ID 硬 X 射线纳米探针上的 EAA

为把上面的建议锚在具体实践上，这里描述 EAA 在 26-ID 硬 X 射线纳米探针上的一次有代表性的部署。

#### 4.1.1 系统布局

图 5（原文描述部署，HTML 未附独立图像文件）给出部署。智能体支架（EAA）、仪器控制工具服务器和 SAM3 代理跑在不同计算机上，因为它们对环境的要求和网络连通性不同。这遵循第 3.2.2 节把支架和工具服务器拆开的原则。仪器控制工具服务器暴露粗/细采图工具（acquire_coarse_scan 和 acquire_fine_scan），从智能体接收工具调用，并用光束线仪器的原生控制协议执行数据采集。一台推理与拼接计算机托管基于深度学习的叠层重建模型和图像拼接器；推理与拼接服务听从来自仪器服务器的数据流，不由智能体直接控制。这些计算机共享同一 NFS 存储做数据交换，使拼接后的叠层重建图像能被工具服务器取回，并最终被智能体查看。图像分割推理，例如 SAM3，按第 3.1.6 节卸载到 ALCF：公网计算机上的薄 SAM3 客户端向 ALCF 上的 SAM3 服务器提交作业。轻量分割时，微调过的 SAM3 可以在本地工作站上推理。12-ID 的 DAQ 软件捕获活的显微镜相机画面并传送，用于样品周界分割，从而限定扫描范围。

图 5：26-ID 硬 X 射线纳米探针上的 EAA 部署。光束线计算机托管 EAA 和一个 HTTP 工具服务器；仪器控制、在线拼接和重视觉推理各自跑在自己的进程或自己的计算机上，用共享 NFS 存储交换数据。图 3 是一般示意图；本图是它的一次具体实例。

#### 4.1.2 一次交互会话

图 6 捕捉 26-ID 上与 EAA 的一次有代表性的用户交互。用户看到先前采集的、一块带图案器件的概览图，粗视场里有一条大致沿对角线的界面。用户要求智能体“在（界面的）中心周围开始一次细扫描”。智能体检查概览图，认出界面，拟合一条形如 y = -2045 - 0.58x 的直线，算出界面中心大约在 (x = 1000, y = -2624)，并发出一次 acquire_fine_scan 工具调用，坐标就是这些。

这一次交换用到了本文大部分建议。概览图是工具产出的多模态数据，按第 3.1.3 节处理。acquire_fine_scan 调用越过第 3.2.2 节建立的支架/工具服务器边界。在这些工具之上，roi-search-workflow 技能引导智能体在样品里搜索用户指定的特征。技能充当高层的“怎样做”文档，并建议用哪些工具，遵循第 3.2.4 节。工具、技能以及偶尔的支架专用工作流适当组合之后，可以实现更自动的操作。例如，有移动波带片的工具、记录步骤的技能，以及支架里的图像配准中间件，就可以实现自主的波带片聚焦：智能体驱动聚焦扫描，并从得到的锐度曲线里选出最优 [4]。好处不只是更快地发出一条扫描命令。通过把图像证据、校准步骤和仪器动作连成可复核的链，智能体减少常规导航和搭建所需的操作员注意力，同时把科学目标及其解释的权威留在人手里。

图 6：26-ID 纳米探针上与 EAA 的一次有代表性的交互。用户用自然语言描述想要的测量；智能体在概览图上推理以定位界面，计算所请求的扫描坐标，并发出一次工具调用来执行这次扫描。

4.2 Osprey

上面的演示来自设施的光束线一侧。加速器一侧有平行的工作在进行：智能体作用在 APS 储存环和注入器上，而不是某一台仪器上。这项工作建在 Osprey [6] 上。Osprey 是面向安全关键控制系统的智能体平台，现已在 MOAT 种子项目下的几台加速器上部署 [18]。这里简要概括，因为它独立于光束线工作发展出来，却到达了非常相似的部署结构，说明第 2 节的原则对科学仪器和设施控制大体适用。

Osprey 分开的正是本文建议的那些层。支架目前是经 Web 终端驱动的通用编码智能体，但平台按构造与支架和模型无关，既用前沿商业模型测试过，也用本地托管的开放权重模型测试过，与第 3.1.2 节一致。设施能力通过 MCP 服务器暴露，而不是编译进支架，覆盖控制系统访问、归档检索、工作区和产物生成，以及对运行记录的搜索。工具层之下，连接器层把读、写和发现请求翻译成本地控制系统的协议，于是 EPICS 是一种被支持的情形，而不是内建依赖。这就是第 3.2.2 节的支架/工具服务器拆分，再用到低一层。工具调用在到达硬件之前经过一道门，做命令过滤、范围和限制检查、授权和日志核实，从而把第 3.2.1 节的护栏放在平台层，而不是每个工具里。经过验证的步骤再按第 3.2.4 节的意义捕获为技能，并可以一句话调用。

这样分层的理由是：模型和支架以周到月的时间尺度演化，而把它们接到控制系统、操作步骤和设施知识上的工作应当稳定、持久。Osprey 因此把集成层当作持久投资，允许上面的模型独立更换。

Osprey 在 APS 上的应用目前分三组。第一组是对归档机器数据的分析。一个例子是调查 BPM 的 IOC 超时，这些超时会使受影响的 BPM 退出轨道反馈。智能体回溯归档器，统计过去两年里每个单元失败的频率，把瞬时毛刺和真正故障分开，并标出下一维护周期最该修的单元。步骤经系统专家核对之后被打包成技能，同一调查可以按请求重复。

第二组是按需诊断，相关数据在智能体提出要求之前并不存在。电源电流回读和 BPM 逐圈数据采样太快，无法连续归档，因此只在请求时捕获。一个例子是追查 60 Hz 束流运动的来源。智能体配置并触发数据采集，然后在得到的波形里搜索 60 Hz 分量，既发现某一磁铁家族共有的模式，也发现单个电源明显高于同类、现已排入检查。同一工作流正在被打包成技能，以便针对某次调查运行，或按例行监视日程运行。另一个例子是快轨道反馈系统的调试研究。反馈在储存环的两个扇区新启用之后，智能体在相似束流条件下比较启用前后的轨道运动，并确认这些扇区的束流轨道有明确改善，从而很快看到新调试系统的表现。

第三组涉及驱动。早期例子是光阴极枪和注入器其他位置的束流发射度测量。智能体端到端驱动已有的发射度测量例程：选择配置、跑磁铁扫描，并返回带诊断图的拟合参数。它不自己生成扫描逻辑，这使驱动保持确定，也是已有经过验证的例程时更稳妥的安排。Osprey 也允许智能体组合控制逻辑并直接写设定值。

加速器却缺少组织图 1 光束线一侧的那种结构分离。控制系统是一个有几百万通道的单一系统，没有天然的按仪器边界来划分工具服务器、技能集或批准策略。作用在机器上的智能体，作用的是每一条光束线都依赖的那一个对象。缓解办法是门控的写权限，而不是隔离。部署的绝大部分是只读的，包括归档检索、通道发现和分析。允许写的地方，对照允许通道的白名单和每通道限制来检查，写模式按部署设定。在 APS，驱动目前限制在范围清楚的测量步骤，例如上面提到的注入器扫描。并发控制相应地比光束线一侧松。光束线一侧由 Bluesky 队列把对一台仪器的访问串行化。机器没有等价的单一排队权威，平台也还不能在争夺同一子系统的智能体之间仲裁。在上述写访问限制下，这还没有成为实际限制，但随着自主程度和并发会话数增长，将需要明确的仲裁。

5 讨论与展望

已经见效的。回报最稳定的一个决定，是把支架和仪器控制工具拆开。端点换过，支架换过，技能集反复改过，都没有动工作进程一侧的仪器控制代码。MCP 和技能提供了持久的互操作层：为一个支架写的工具，在其他支架里几乎不用改就能复用。这种架构上的可移植是必要的，但不够。生产系统最终应按它们所支持的科学决定的质量和可复现性、取得可解释证据所需的时间、用户之间的知识传递，以及它们为科学问题腾出的操作员时间来评测，而不是只按吞吐。

评测运行流水线和知识流水线。对第 3.4 节到第 3.6 节的扩展，评测应沿着从观察到已接受结局的链走。相关度量包括证据覆盖、诊断正确性、到达有支持的发现的时间、操作员花费的力气、在受影响服务上核实的恢复，以及适当的升级。知识复用应按来源支持、时间适用性和访问边界是否被保住来评估，包括来源被更正、或工作者带着过时状态恢复的测试。这些是提议的评测维度，不是设施级自主部署的测量结果。

眼前的下一步。最基础的缺失是 MCP/技能中枢本身。图 1 里的中央网关被画成架构的脊柱，但还不存在。目标是以轻量、对用户友好的方式设计和运行这个中枢：

• 建立一个 GitHub 组织，托管工具服务器和技能的源代码与文档。每个工具或技能有自己的仓库。
• 在此之上开发一个类似 SkillsMP（https://skillsmp.com/）的轻量网站，作为工具和技能的目录。网站不直接存放代码或文档，而是链接到对应的 GitHub 仓库。网站应：
• 允许用户按名称或功能标签（例如 microprobe、database 或 ptychography）浏览或搜索工具和技能；
• 提供每个工具或技能专用的安装和部署说明；
• 暴露 API 端点和对智能体友好的文档，让 AI 智能体搜索、下载、安装和部署工具与技能。

为保护技能和 MCP 仓库的完整性、防止未经授权的更改，将采取：

• 目录网站托管在阿贡网络内部，不公开访问。
• 每条目录条目指向特定提交或发布标签，而不是可变的仓库分支。更新需要经阿贡单点登录的已认证请求，再经管理员审计和批准。这个过程保证被评审的版本保持不变，直到替代版本被明确晋升。

运行时控制面的扩展应与目录发布分开推进。分阶段集成可以先通过共同的身份和结果契约暴露只读清单、运行观察和知识检索，然后加入可复核的变更提议，只有在那之后才对选定步骤允许经授权的执行。启用跨域工作流之前，每个参与的服务应定义自己的动作范围、失败和取消行为、仲裁边界和接受证据。共享记忆应按第 3.5 节的来源和修订控制引入。这个顺序允许在广泛写权限可用之前就提供有用的诊断协助，并且不要求替换现有服务后端。

中枢运行之后，四类能力可以并行填充。知识检索是今天最容易拿到的能力。APS 的检索增强生成服务（APS-RAG，https://rag.aps.anl.gov/）[19] 已经搜索机器日志、实验和配置记录、工作请求、运行讨论、技术报告和其他运行应用。机器日志的来源是 BELY。把这项服务登记为 MCP 工具，会使这些来源可用，而不要求用户知道底层系统的内部名称。但知识交换不应停留在单向。科学家的更正、加了注释的结局，以及智能体提议的步骤，应进入受治理的回写队列，在晋升为持久的设施知识之前记录来源证据、适用条件和评审状态。

仪器控制需要共享的技能登记处，使在一条光束线上验证过的步骤可以在另一条上被发现、评审和复用，而不必重新开发。对已有 Bluesky 部署的仪器，BITS 提供统一的设备注册表和 Queue Server 接口，BAIT MCP 提供对应的工具服务器入口。

这样的登记处的第一个实例已经在加速器一侧开始成形。第 4.2 节描述的工作建立了共享加速器技能的市场，由在运行中验证、然后打包成一句话复用的工作流填充。它起的作用与图 1 里的技能中枢相同。

分析和计算能力也部分就位，因为 EAA 把 SAM3 推理和 Pty-Chi 重建卸载到 ALCF 的 Polaris。这些服务应通过中枢提供，使其他支架能经共同接口访问。此外，一项横切的可观测性服务应以共同的、可查询的格式记录工具调用、推理痕迹、证据和经确认的人的覆盖。Hutch 包 [20] 是这个方向的第一步。

意图让光束线和加速器目录互相引用。把这些系统当成统一框架，才能做复杂的自动工作流，使光束线用户对特定加速器参数获得有选择的本地控制。例如，用户可以直接实现本地轨道凸起，或查询实时加速器诊断，把束流表现和基于 X 射线的实验测量关联起来。两边的内容向不同方向推广。光束线技能常常能转到实验设置相似的另一条光束线，并越来越多地转到另一设施上可比较的仪器，因此该目录的自然范围是技术而不是站点。两者共享的是一组能力类别，包括通道发现、归档检索、日志和文档搜索、出图，以及上面描述的可观测性和来源服务。互相引用对跨越两个域的问题很重要，例如源点处的束流稳定性，或与机器状态相关的漂移。此时智能体需要发现机器一侧的诊断技能，并以只读方式调用它，而不继承对加速器的写访问。

更长的展望。更长的机会是在仪器的整个运行寿命里提高它们的科学价值。智能体可以做常规校准、测量执行、质量监视和初步数据综合，科学家保留对实验目标、不确定度、异常和解释的权威。知识然后可以双向流动：科学家把步骤和判断教给系统，系统通过交回解释、来源和跨实验积累的教训来支持后来的用户。经过验证的教训可以变成在仪器之间、最终在设施之间移动的版本化技能；未验证的经验应作为候选知识保持隔离。具体实现会变，但可分离、安全、来源、人的权威和受治理的学习仍是持久要求。成功因此不应只按吞吐来量，还应按可复现性、可及性、取得可信证据所需的时间，以及系统所促成的科学决定的质量来量。

致谢

本工作由先进光子源支持。先进光子源是美国能源部科学办公室设在阿贡国家实验室的用户设施。研究基于美国能源部科学办公室基础能源科学的支持，合同号 DE-AC02-06CH11357。

参考文献

• [1] Anthropic，Model Context Protocol，2024，https://modelcontextprotocol.io 。
• [2] M. H. Prince 等，Opportunities for retrieval and tool augmented large language models in scientific facilities，npj Computational Materials 10，251，2024。
• [3] A. Vriza 等，Operating advanced scientific instruments with AI agents that learn on the job，npj Computational Materials 12，160，2026。
• [4] M. Du 等，Experiment automation agents: automating materials characterization with vision language model agents，npj Computational Materials，2026。
• [5] S. Mathur 等，VISION: a modular AI assistant for natural human-instrument interaction at scientific user facilities，Machine Learning: Science and Technology 6(2)，025051，2025。
• [6] T. Hellert、J. Montenegro、A. Sulc，Osprey: production-ready agentic AI for safety-critical control systems，APL Machine Learning 4(1)，016103，2026。
• [7] X. Yin 等，Pear: a robust and flexible automation framework for ptychography enabled by multiple large language model agents，arXiv:2410.09034，2024。
• [8] M. Zechner 等，Pi: an open-source agent toolkit and coding-agent harness，https://github.com/badlogic/pi-mono ，MIT，访问于 2026-08-28。
• [9] M. Zechner 等，Pi agent runtime and session documentation，访问于 2026-08-28。
• [10] M. Zechner 等，Pi extension、SDK 与 RPC 文档，访问于 2026-08-28。
• [11] M. Zechner 等，Pi subagent extension example，访问于 2026-08-28。
• [12] LangChain，LangGraph graph API, workflows, and agents，2026，访问于 2026-08-28。
• [13] A. Tanikanti 等，First: federated inference resource scheduling toolkit for scientific AI model access，SC’25 Workshops，52–60，2025。
• [14] Bubblewrap contributors，Bubblewrap: unprivileged sandboxing tool，https://github.com/containers/bubblewrap ，访问于 2026-09-11。
• [15] E. Codrea 等，BITS: BCDA-APS bluesky instrument software，Zenodo，https://doi.org/10.5281/zenodo.22801741 。
• [16] E. Codrea，bait_mcp: BCDA-APS software，Zenodo，https://doi.org/10.5281/zenodo.22801757 。
• [17] Anthropic，Agent Skills，2025，https://docs.claude.com/en/docs/agents-and-tools/agent-skills 。
• [18] J.-L. Vay、T. Hellert、A. Huebl 等，The Multi-Office Accelerator Team (MOAT) seed project，2026。
• [19] R. Sainju 等，APS-rag: a domain-aware hybrid retrieval augmented generation system for accelerator operations and knowledge synthesis，IPAC’26，MOP6302，2026，未正式出版。
• [20] X. Yin，The hutch: observability, steering, and provenance for autonomous-research agents，https://github.com/xyin-anl/hutch ，访问于 2026-06-12。

附录 A 建议的智能体支架界面截图

图 A1：EAA 的 WebUI 截图。

图 A2：可在 Claude Code 里启动的 MCP 工具列表（配图未单独下载，见原文 HTML）。

图 A3：在 Claude Code 里经 MCP 工具调用请求扫描进度（配图未单独下载，见原文 HTML）。

图 A4：APS 检索增强生成服务的 Web 界面。左栏是可用模式和助手，包括每日摘要、排障和图像搜索。右栏是关于束流寿命和束团长度测量的查询。选择文内引用会在侧栏打开对应的 BELY 条目，保留生成答案和其运行来源之间的连接。

图 A5：用于谱学分析的 Dr. XAS WebUI 截图（配图未单独下载，见原文 HTML）。

图 A6：用于自动叠层重建的 PEAR WebUI 截图（配图未单独下载，见原文 HTML）。

图 A7 见第 3.2.3 节。

图 A8 见第 3.3.5 节。

图 A9：ChatMD-WebUI，分子动力学模拟的智能体工作流（配图未单独下载，见原文 HTML）。

图 A10：Auto-CT，断层数据集自主分析的智能体系统。当前用 tomocupy 作为重建引擎，并支持重建切片的可视化和操作（配图未单独下载，见原文 HTML）。

图 A11：APS USAXS 光束线上用于 Bluesky 数据采集规划的 AIDA 界面（配图未单独下载，见原文 HTML）。

出处：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；另有美国政府许可，允许复制、准备衍生作品并向公众发行。