常驻智能体需要持续监视并响应事件，而事件来源之多，远超它在上下文窗口里所能追踪的范围。Comma 的分布式智能体框架 Salix 让智能体可以把小巧的 eBPF 程序加载到集群中，并让它们 24/7 持久运行：监视事件，调用 Jev 做快速的智能判断，并在发生值得关注的事情时唤醒智能体主循环。
只有内循环是不够的
大家熟悉的智能体循环很简单：把上下文发给模型，执行它返回的工具调用，追加结果，然后重复。这个循环擅长干活，却不擅长等活。
让智能体“合同签回来时告诉我”，或者“盯着这个仓库，凡是涉及计费的改动都标出来”，内循环只有两个糟糕的选项。一是轮询：每隔几分钟醒来一次，重新读一遍收件箱，再花一次完整的模型调用得出“什么都没发生”的结论。二是把任务交给心跳或 cron 调度，这其实还是轮询，只是间隔更长、延迟更差。无论哪种方式，系统里最昂贵的部分，即大模型读取大段上下文，在每个周期都要运行一次，而几乎每个周期都风平浪静。
常驻智能体真正需要的是一个外循环：它守在事件流上，完成低成本的过滤，只在有值得思考的事情时才上报给模型。而且每个智能体监视的对象和方式各不相同，所以这个外循环不能是一个固定的产品功能，必须由智能体自己来写。
在 Salix 中，这个外循环叫作 Loop。
Loop 是一个小小的 C 程序
Loop 是由智能体编写的单个 C 文件，编译为 eBPF 后，在集群上紧挨着它所属的智能体运行。每个 Loop 的结构都一样：
它等待一个定时器或事件，检查某些情况，偶尔唤醒智能体。智能体通过 loop.sdk 工具拿到完整的 SDK 头文件和编程指南，编写程序，用 loop.build 编译，再用 loop.create 启动。没有模板，也没有 DSL。只要智能体能用 C 描述这项监视任务，就能把它跑起来。
为什么选 C 和 eBPF，而不是比如说容器里的 Python 脚本？原因在于我们设计 Salix 时所依据的那些数字。Salix 运行着数百万个智能体，每个 CPU 核心上超过 100 个。智能体不可能拥有一个始终开着的沙箱，它的监视任务也一样。Loop 必须足够便宜，便宜到可以为每个智能体永远运行下去，并且运行在共享的多租户节点上，执行没有经过任何人工审查的代码。
eBPF 与这些要求出奇地契合：
它很小。 一个处于等待状态的 Loop 只占几十 KB 常驻内存。没有进程，没有解释器，也没有堆。
它可以安全地运行不受信任的代码。 目标平台没有系统调用，没有函数指针，也没有无界栈。程序能做的，只有在自己的内存上做计算，以及调用我们交给它的宿主函数。
它等待时几乎不花钱。 阻塞在
sf_event_next或sf_sleep_ms中的 Loop，除了内存之外没有任何开销。
代价是一种受限的 C 方言，SDK 指南对此毫不讳言：只能用整数 C（没有浮点数，没有有符号除法），栈帧 4 KiB，调用深度最多 8 层，不能递归，没有 sprintf，同时存活的句柄最多 128 个。事实证明模型对此适应良好。它们本来就会 C，而这些约束正是编译器报错能讲清楚的那一类。
Spinfoam：每个 Loop 之下的运行时
Loop 运行在我们的 eBPF 循环运行时 spinfoam 上。Spinfoam 构建于 async-ebpf 之上，这是一个用户态 eBPF 运行时：对异步友好、完全抢占式，其核心的内存安全性经过了形式化验证。
用户态 eBPF，做成异步
Spinfoam 不是内核 eBPF。它是一个普通的 Rust 进程，每个 Salix 节点一个，不需要内核的 eBPF 支持，也不需要任何特权，在 Linux 和 macOS 上表现一致。Salix 通过 stdin 和 stdout 上的 JSON-RPC 与它通信。双方的职责划分非常严格：spinfoam 负责本地执行、程序之间的隔离、取消，以及有界的消息投递；Salix 负责一切需要在崩溃后保留下来的东西：调度放置、持久状态、重启策略、凭据和网络。
async-ebpf 中的“async”，正是让 Loop 看起来像普通顺序 C 代码的关键。每个加载的程序都有一次长期存在的调用，运行在自己的协程上。当程序调用 sf_sleep_ms、sf_event_next 或 sf_host_call 时，辅助函数会挂起协程，把等待交给 Tokio。C 栈和程序的全局变量原封不动地留在原处。等定时器触发、事件到达，或者 Salix 应答了宿主调用，协程就从下一行继续执行。智能体写的是 for (;;) { wait; check; wake; }，从来不用碰回调。
“完全抢占式”则让共享运行变得安全。所有访客代码都运行在同一个 Tokio 线程上，一个看门线程会中断任何长时间运行而不让出的程序。一个在 for (;;) {} 里空转的 Loop 会像其他程序一样失去时间片，停止它也不需要它配合。一个有 bug 的 Loop 拖不垮它的邻居。
大多数 Loop 几乎把所有时间都花在等待上，所以这种设计可以排布得非常密集。在我们的验收测试中，10,000 个小型监控 Loop（全部由内嵌编译器编译）在一个执行线程上运行，每个约占 64 KB 常驻内存。加载并启动全部 10,000 个 Loop 用了 3.07 秒。向每个 Loop 投递一个事件，并应答每个 Loop 随之发起的宿主调用，用了 1.56 秒。控制请求的 p99 延迟保持在四分之一毫秒以内。整个进程在加载期间使用四个操作系统线程，空闲时使用两个。
可以检验的内存安全
在一个进程里运行成千上万个由智能体编写的程序，前提是它们都碰不到不属于自己的内存。在 async-ebpf 中，这一保证始于内存布局，终于机器检验的证明。
先说布局。每个程序的数据都位于一个指针笼中：这是一块预留区域，周围布有随机化的保护页。访客栈被布置成一个个单帧的“孤岛”，彼此之间隔着不可访问的间隙，间隙宽度超过任何 eBPF 内存指令能够到达的范围，因此越出自身栈帧的函数会触发错误，而不会读到调用者的栈帧。JIT 代码页永远不会同时可写又可执行。
再说证明。async-ebpf 会在每个 eBPF 函数首次运行时将其编译为本机代码。它的 x86_64 后端经过特意的结构设计，使其中做决策的部分可以被证明：
验证器是可靠的。 对于它接受的程序，在每一条执行路径上，程序都不会到达未定义的指令，不会跳进某条指令的中间或跳出程序，并且帧指针始终是当前调用深度对应的帧基址。
函数是封闭的。 除了局部调用或返回，控制流永远不会离开函数，正因如此，JIT 才能一次只编译一个函数。
生成的代码是内存安全的。 如果检查器接受了一个函数，那么其本机代码的每一次执行都只会访问一组允许的地址（它的栈帧、它自己的访客内存区域、它自己的栈和字面量池），并在返回时保持调用者的状态不变。惰性编译的被调用函数也能用同一条定理组合起来。
字节与模型一致。 汇编器发出的每条指令，都能解码回模型所推理的那条指令。
这些证明在两处与硬件相连。一个可执行的模拟器被证明是 Lean 机器模型的一次运行，并有一项差分测试让两万条随机指令序列同时在模拟器和真实处理器上运行。每次调用之前，运行时都会对照定理的前提条件检查具体的内存布局，一旦不满足就拒绝运行。
哪些内容没有被证明，我们也说得很清楚。可信基包括 x86 指令语义（经过硬件测试，但未经证明）、入口跳板、故障处理程序、内存映射、每个辅助函数调用的宿主侧，以及 Charon 和 Aeneas 本身。这条定理关乎内存安全，不涉及功能正确性或信息泄露。而且它只覆盖 x86_64 后端；arm64 后端经过测试，但未经证明。
这些证明把访客限制在它自己的内存里。Loop 对外部世界做的一切都要经过宿主调用，而这条边界归 Salix 管：也就是下文介绍的能力白名单和权限规则。
编译器也运行在沙箱里
Loop 由智能体自己编译，因此编译器同样要处理不受信任的输入。Spinfoam 内嵌了 TinyCC，并把它编译成 eBPF，像其他访客一样运行在 async-ebpf 上。每次构建都会得到一个全新的编译器实例，配有 8 MiB 的内存池、一个只包含提交的源文件和 SDK 头文件的纯内存文件系统、15 秒的时限，并且无法访问网络、进程或宿主文件。编译输出同样被视为不受信任。每个目标文件在加载时都要经过同样的验证，无论它是否来自这个编译器。
这就是为什么 loop.build 不需要工具链、不需要容器，也不需要节点上的任何特权。智能体的 C 源码从不接触本机编译器。
唤醒智能体才是昂贵的部分
Loop 可以独立运行，但如果它没法告诉智能体任何事，那就毫无用处。它唯一的途径是 agent.notify：
通知会作为一条普通消息投递到 Loop 的目标 Session。只有在这时，智能体主循环才会运行，也只有在这时才会消耗模型 token。平静的一小时完全不花 token。
dedup_key 比看上去更重要。Loop 会被重启，事件会被重新投递，访客程序也可能重试一次不确定是否成功的调用。Salix 以 loop:<id>:<dedup_key> 的形式投递唤醒，因此同一封邮件、同一个 issue 或同一条告警只会唤醒智能体一次。
正因为唤醒是昂贵的部分，它也有预算。一个 Loop 每十分钟最多唤醒它的智能体六次。如果一个 Loop 持续一小时都停在这个上限，它就会暂停（原因记为 budget），并告知智能体。一个有 bug 或过于积极的 Loop，最终会变成一个可见的、已暂停的 Loop，而不是一张账单。
不靠大模型也能快速判断
监视任务的难点通常不在于“有没有变化”，而在于“这个变化重不重要”。这封邮件是不是主人今天必须处理的？这个 PR 有没有碰到我们关心的那部分系统？用整数 C 写的 Loop 自己回答不了这些问题，而对每个事件都调用一次前沿模型，又会让我们回到原点。
所以 Loop 多了一项能力：decide。它把一个小而有类型的问题发给快速决策模型（Jev），并拿回结构化的答案。下面是我们邮件监视原型里的问题：
decide 支持用 choice 从候选项中选出一个，用彼此独立的是非题处理多项匹配，以及用 score 给出有序的相关度。它只返回判断结果，不读取数据源，不运行工具，也不授予权限。数据由 Loop 提供，问题由 Loop 提出，阈值也由 Loop 在自己的代码里判断。
有两个设计选择让它运转良好：
不确定也是有效答案。 显式的
none或defer选项表示“我判断不了”，这是一个成功的结果，而不是传输错误。Loop 会保留该事件，而不是捏造一个“静默”的判断。它便宜到可以对每个事件都运行。 我们的价格目录中，
typesafe/jev-1.13.0每百万输入 token 收费 $0.042，输出 token 免费。这个价格足以筛查每一封邮件，而不只是关键词过滤器放行的那些。
结果是一个两级系统：小模型筛查每个事件，大模型只看通过筛查的那些。
事件进来，持久留存
定时器足以应付轮询，但很多来源可以主动推送。每个 Loop 都有一个邮箱，外部系统可以通过三种方式向它投递：
Salix API：使用群组 API 密钥调用
POST /v1/agent-groups/:group_id/loops/:loop_id/events；一个秘密 webhook URL，智能体可以用
loop.webhook启用、轮换或吊销它；来自用户已连接应用的 Composio 触发器，到达时会带上提供方的事件 ID 和触发器 slug。
上述任何一种方式返回 202，都表示 PostgreSQL 已经把事件保存在对应的 Loop 上，但并不表示 Loop 已经处理了它。访客程序在到达安全点时调用 loop.ack：安全点可以是一个“静默”的判断，也可以是一次持久的交接，例如一次成功的 agent.notify。在此之前，事件一直处于待处理状态；Reconciler 会在 Loop 迁移或重启后重放待处理事件，并且无论如何每分钟都会重放一次。如果一个事件在 15 分钟内没有被确认，Loop 就会显式地失败，待处理事件会被保留下来，由智能体决定重试还是丢弃。
构建过程中的一个教训：spinfoam 的邮箱是在接收时对事件 ID 去重，而不是在业务完成时。在早期原型中，我们以为模型调用失败后，提供方重新投递事件就能完成重试。实际上并没有：重新投递的事件被正确地当作重复项丢弃了。所以重试应当由访客程序负责，它保留事件并进行有限次数的重试；崩溃后的恢复则由持久收件箱负责。现在我们把这条规则写进了 SDK 指南。
确认、持久的 Session 接收、可见的消息和外部副作用，是四个相互独立的事实。我们为每一个都指定了各自的负责方，要求下游使用稳定的去重键，并且不承诺外部副作用恰好执行一次。
在不断变化的集群上永续运行
“24/7”说起来容易，但在节点来来去去的集群上做起来很难。Loop 运行在持有其智能体租约的节点上，并跟随这份租约迁移。
放置。 智能体的服务端进程认领租约时，会接管它的活跃 Loop。智能体被钝化或被隔离时，会释放这些 Loop。活跃的 Loop 会让它的智能体保持驻留，因此一个带有 Loop 的空闲智能体会续租，而不是停驻。
化身。 Loop 每加载一次，它的化身编号就递增一次，这是 Loop 记录行上的一个隔离值。来自非当前化身的对象的宿主调用会被拒绝，来自它的
ack也一样。滞留在即将离开的节点上的过期 Loop 副本无法再采取任何行动。检查点。
loop.state.put最多保存 16 KiB，下次加载时会以config.state的形式取回。智能体只为游标和最后看到的 ID 做检查点，而不是保存一切。故障。 发生故障时，Loop 会从检查点重新加载，每小时最多三次。超过之后它会变为
failed，并告知智能体一次。搁浅。 一个周期性的清扫任务会找出没有挂载对象、或挂载在已离开节点上的活跃 Loop，并重启它们的所属方。
Loop 在运行时之外还有一份事实来源。loop.build 把编译好的 ELF 写入智能体的文件系统，loop.create 记录它的路径和 SHA-256。每次加载都会重新读取文件并校验哈希，因此 Loop 要么运行的恰好是创建时的那个程序，要么根本不运行。
Loop 被允许做什么
Loop 是由模型编写、在无人监督的情况下昼夜运行的代码。它的权限必须小于智能体，而不是与之相等。
Loop 只能调用一份封闭的宿主能力白名单：agent.notify，loop.state.*、loop.ack 和 loop.log 调用，被归类为只读的 Salix 工具，环境和设备工具，SSH 工具，读取对话，web.http_request，用于已连接应用的 composio.execute，以及 decide。对其他任何名称，Spinfoam 都以 SF_DENIED 拒绝。这里根本没有可能出错的授权步骤。
每次调用都要经过与普通智能体轮次相同的工具分发和信息流检查。Loop 以创建者的身份行事，通过委托主体 schedule|loop:<id>|<creator>，遵循创建者的披露规则和 Loop 的封存来源。事件载荷只是数据。它们不携带任何权限，也无法扩大 Loop 能做的事情，这正是上文的决策提示明确把邮件当作不受信任输入的原因。
最后，配额让整个系统保持有界：每个智能体最多 20 个活跃 Loop，每个群组最多 100 个；每个 Loop 最多 32 个待处理事件，每个 16 KiB；webhook 入口另有速率限制。
脚本：同一个运行时，只跑一个轮次
一旦有了一个安全、廉价、能运行智能体所写 C 代码的运行时，第二种用途便浮现出来。script.run 会在单次工具调用内，把一个整数 C 程序编译并运行一次，运行时可以通过 salix.call 访问调用方轮次自己的工具。脚本没有记录行，没有化身，没有检查点，也没有 agent.notify。它让智能体能把许多次工具调用打包成一个确定性程序，而不必经历多次模型往返。我们随产品提供的技能中，有两个就是以这种方式运行的 C 程序。
为自己编写事件系统的智能体
综合起来，当你让 Comma 智能体盯住某件事时，它会做到传统智能体做不到的三件事：把监视任务写成程序；集群只需几 KB 的代价，就能让这个程序按需一直运行下去；再由一个小模型逐个事件地判断，大模型到底需不需要醒来。
内循环仍是智能体思考的地方，外循环则是它保持关注的地方。Salix 让智能体两者都能亲手构建。
