每隔五分钟，OpenAPS 都会处理一个安全攸关的问题：胰岛素泵是否应该暂时提高、降低或维持基础率？任何一次答案都只有有限的执行权限。原始参考实现收集一条足够新的葡萄糖读数和泵历史记录，计算体内仍有活性的胰岛素，给出一项带有可读理由的动作提议，再用多项限制检查这份提议。需要采取动作时，系统会要求泵设定或取消临时基础率；基础设计中的临时基础率通常持续 30 分钟。随后，系统还会核对泵所上报的状态。[1][2][4]

“闭环”容易让人联想到一台封闭设备：传感器数据进入，胰岛素输出，智能藏在中间看不见的地方。OpenAPS 的做法几乎反向而行。即使工程师永远不会实际操作它，这套系统仍值得当作开源架构来读。代码公开本身不会自动带来安全性。更有启发性的设计，在于把每次五分钟决策的权限限定得远小于整套应用表面拥有的权限。

本文研究系统设计，搭建指南和医疗建议不在讨论范围内。胰岛素给药安全攸关，硬件兼容范围有限，各司法辖区的法律与临床规则也有差异。一份国际共识认为，开源自动胰岛素输送已有实质性证据，同时明确拒绝提出两类普遍性建议：一是相较商业系统一概优先采用，二是在当地治理之外使用。[6]

循环由一组产物串起，模型置于明处

oref0 仓库用三个动词概括其工具：监测（monitor）、预测（predict）和控制（control）。[2] 三类工具分别回答不同的问题。

监测要回答当前事实是什么。连续血糖监测仪送来新数值时，OpenAPS 会读取它；这一过程通常每五分钟发生一次。系统同时查询泵内预设的治疗配置、近期大剂量输注、临时基础率历史、储药器余量和运行状态。汇总后的状态包括近期葡萄糖变化量、体内活性胰岛素（insulin on board，IOB）、基础率计划、胰岛素敏感度、目标区间、用户提供的碳水化合物信息，以及用户偏好设置。[1][4]

预测要回答当前状态将向何处发展。核心脚本 determine-basal.js 把当前读数与短时和较长时窗内的葡萄糖变化量、预期胰岛素活性、近期读数相对预期的偏差，以及多条葡萄糖预测路径结合起来。它没有把不确定性收束成一条确信无疑的预测；输出仍保留最终葡萄糖（eventual glucose）、最低保护葡萄糖（minimum guard glucose）、仅胰岛素预测（insulin-only predictions），以及在启用相应配置时的未宣布进餐预测（unannounced-meal predictions）等数值。[4]

控制要回答预测结果是否足以支持一条泵指令。在原始 oref0 流程里，结果首先是一项临时基础率建议：给出输注率和持续时间，或维持现状，同时用 reason 字段记录进入该分支的原因。启用 SMB（超级微量大剂量）的后续配置还可以建议一次微量大剂量；这项动作差异十分重要，后文还会说明。[1][2][4] 计算结果可以独立接受检查，设备动作留在另一环节；实际下发的动作可以和先前建议对照；循环选择维持现状时，也能说明究竟是哪项输入或限制阻止了动作。

这套架构带有鲜明的 Unix 风格。长期设置、当前观测、计算状态，以及建议动作或已执行动作，分别记作小型产物，在工具之间传递，不会藏进单个常驻进程的内部状态。这里的重点无关审美上的纯粹性。实体结果攸关安全时，审查者需要分别追问四件事：输入是否足够新？计算内部是否一致？指令是否处在设定限制内？设备是否真的接受了指令？

临时方案受到多层限制

原始 oref0 设计从多个层次收窄动作范围。

第一层采用临时基础率，常规大剂量指令留在这条路径之外。重复发送大剂量指令，会让胰岛素随每次发送而累积。再次发送相同的临时基础率，只会让该输注率继续生效，不会让输注率成倍叠加。基础参考设计使用 30 分钟临时基础率，因此指令会自行到期。如果通信中断，下一次决策也没有到来，泵就会回到预先设定的基础率方案。[1]

第二层限制算法可选择的基础率。按默认倍数计算，maxSafeBasal 取以下三者中的最低值：泵自身设定的最大基础率、计划中最高基础率的三倍，以及当前计划基础率的四倍。对应的配置键是 max_daily_safety_multiplier 和 current_basal_safety_multiplier。另一方面，max_iob 自 oref0 0.6.0 起生效，会限制循环在处理高于目标的葡萄糖时所允许累积的体内活性胰岛素总量，其中包括由基础率输注、SMB 校正和大剂量输注产生的胰岛素。[1][5]

第三层把缺失或互相矛盾的证据也视为输入。参考设计要求，在必要信息缺失或信息彼此冲突时，OpenAPS 回退到预设基础率。发出指令后，设备还会再次查询泵，确认泵报告所请求的临时基础率正处于活动状态。[1] 因此，函数成功返回不能证明泵已经接受新状态；即便泵上报了该状态，也不能证明胰岛素已经输送到人体内。

这些层次共同划出安全包络；安全认证的含义远超于此。由错误泵设置推导出的上限仍会出错。葡萄糖传感器会出现延迟、受压失真、失效或噪声读数。已经输注的胰岛素无法撤回。因此，偏好设置文档把 max_iob、敏感度限制和超级微量大剂量设置列为会实质影响治疗的参数，不能把它们当作无害的应用开关。[5]

其中的差别细微，却触及根本：OpenAPS 从算法会出错这一前提出发，逐项限制一次计算能够请求什么、请求持续多久、泵会接受什么，以及下一次观测始终没有到来时系统如何处理。

小型计算机是一道兼容性边界

题图发布于 2016 年，Dana Lewis 站在一套早期 OpenAPS 设备旁：Raspberry Pi 与无线电链路周围散布着泵、血糖监测硬件、电池、手机和屏幕。[7] 它带着明显的拼装痕迹，因为这些设备跨越了多处分界，而制造商最初并没有把它们设计成同一款产品。

这套实体设备也解释了“算法”为何只是其中一个组件。血糖监测仪负责测量；泵保存自身预设的治疗方案和执行器限制；无线电接口负责转译专有设备与 Linux 计算机之间的通信；oref0 负责计算与编排；网络连通时，Nightscout 可以接收数据，供远程查看。参考设计让本地循环自主运行，联网仪表盘没有进入给药依赖链。[1][7]

这样的分离会把故障约束在局部，也会带来运维工作。整套设备需要电力。各设备时钟与读数时间戳必须足够一致，读数也必须足够新，才能用于剂量计算。计算机运行正常时，无线电通信依然会失败。远程图表已经过时时，本地循环仍可继续；本地设备已经停下后，远程图表也会暂时显示正常状态。只有明确指出具体服务，“服务正在运行”才有意义：这里可以指传感器采集、泵通信、计算、指令执行或上传。

因此，兼容性处在设计中心。OpenAPS 最初依赖一类泵，社区开发的工具能够读取并控制其通信。换用不同的泵协议、葡萄糖数据源或无线电桥接器，系统中对安全影响最大的适配层也会随之改变，即使 determine-basal.js 仍逐字节完全相同。[2][7]

可观测性应嵌入控制链路

许多应用要等主体设计完成后才添加日志。OpenAPS 则把解释写进动作本身。reason 字段能够说明葡萄糖下降速度超过预期、某条预测越过阈值、现有临时基础率已经足够接近建议值，或某项安全设置限制了请求输注率。[4][5]

这份输出同时服务三类读者。系统使用者可以看到它采取动作的原因。贡献者可以把意外结果追溯到有名称的输入或分支。研究人员可以区分预测与随后发给泵的指令。意图由此直接留在记录中；若只看后来的葡萄糖曲线，进餐、活动、传感器误差、吸收过程和先前注入的胰岛素全都叠在一起，很难反推系统当时为何行动。

这里还需要分清透明与简单。可读的理由字段能够概括一个分支，却无法教会读者如何验证胰岛素作用曲线、基础率方案或传感器行为。开源代码开放了检查入口，临床能力仍来自代码仓库之外。共识指南把教育、知情选择、数据隐私、专业支持和当地政策都纳入代码周围的完整系统。[6]

这项运维经验同样适用于医疗软件以外的领域。对于控制器，日志应保留从观测、提议、受限指令到确认回执的完整链条。只展示最终状态的仪表盘，会丢掉解释状态转换所需的证据。

实现逐渐陈旧，设计模式传播到别处

维护状态如今会改变采用决策。oref0 发布页面把 0.7.1 列为最新版本，发布时间是 2022 年 6 月 19 日。[3] 这个时间点清楚表明，到了 2026 年，原始 Raspberry Pi 软件栈已经不适合作为普通的新安装项目。文档仍能打开，无法让安全关键代码自动跟上当前环境；仓库尚未归档，也无法等同于仍在持续发布的产品。[2][3]

这套设计的影响超出了版本发布时间线。临床共识列出了 OpenAPS、AndroidAPS 和 FreeAPS X 中的 oref0/oref1 算法，同时把它们与独立的 Loop 算法区分开来。[6] 然而，动作模型没有保持不变：oref1 可以输注超级微量大剂量，而胰岛素一经输注便不会随时间到期。因此，它增加了两项检查：系统必须掌握完整的泵历史记录，并且在发出超级微量大剂量之前，能够先设定足够时长的零临时基础率，让预测结果保持安全。[1] 本文所述的 30 分钟到期模式只属于原始 oref0 临时基础率流程，不能外推到所有后继系统的每一种动作。

守住这一区分，是负责任地阅读这套架构的前提。硬件支持范围应以当下资料为准；老照片无法证明今天仍支持其中的硬件，历史设置页上的命令也不应直接复制到医疗设备中。源代码更适合用来观察一个社区如何让安全关键动作接受审查：先计算，再下发；把执行器限制放在预测之外；让指令到期后回到已知基线；拒绝过期证据；确认泵上报的指令状态；并把解释与动作保存在一起。

与“开源代码可以取代医疗硬件周围的一切制度”这样的主张相比，OpenAPS 最持久的工程贡献范围更窄，也更加锋利：软件一旦能够触碰实体世界，设计就应清楚呈现哪些指令可以发出、指令持续多久、哪些证据导出了指令，以及下一次读数始终没有到来时系统如何处理。

来源

1. OpenAPS 项目，《OpenAPS Reference Design》——系统组件、五分钟周期、oref0 临时基础率限制、oref1 保护措施、回退行为、指令确认与离线控制边界。
2. OpenAPS 项目，openaps/oref0 仓库——参考实现及其监测、预测与控制工具边界。
3. OpenAPS 项目，“oref 0.7.1 release”，2022 年 6 月 19 日——oref0 最新列出版本及维护时间参照点。
4. OpenAPS 文档，《Understanding the determine-basal logic》——计算输入、预测术语、建议输出与 reason 字段。
5. OpenAPS 文档，《Understanding your preferences and safety settings》——max_iob、基础率安全倍数、敏感度范围与高级设置注意事项。
6. Katarina Braune 等，《Open-source automated insulin delivery: international consensus statement and practical guidance for health-care professionals》，The Lancet Diabetes & Endocrinology，2022 年——证据、实现分布、临床支持、伦理与治理边界。
7. Gitter，《Building Online Communities: OpenAPS》，freeCodeCamp，2016 年 10 月 28 日——Dana Lewis 访谈、早期系统历史、硬件背景与题图。