LoopX Worker Bridge 安装契约解析：4 步把治理守卫装进你自己的调度器
【免费下载链接】loopxLong-horizon agent control plane for durable, governed work across Codex, Claude Code, and other harnesses.项目地址: https://gitcode.com/GitHub_Trending/lo/loopx
LoopX 是一个面向长时任务（long-horizon agent）的智能体控制平面，负责在 Codex、Claude Code 等多种 Agent 运行环境之上维持持久的目标、配额与治理规则。其中的Worker Bridge 安装契约（install contract）能让你在不依赖官方 Runner 的情况下，把同一套治理守卫装进容器、虚拟机或自研调度器。
一句话理解 Worker Bridge 安装契约
Worker Bridge 的核心思路是声明式（declarative）：你不需要阅读 Runner 的私有代码，只需让 LoopX 输出一份 JSON 契约，里面声明了——
- 挂载（mounts）：哪些目录以只读方式挂进 worker；
- Python 预检（runtime preflight）：worker 环境里如何确保
python3 -m loopx.cli可运行； - 计数追踪（counter trace）：worker 侧每调用一次 LoopX CLI 就追加一行紧凑日志；
- 可选的 active-user 通道：外部用户如何以"拉取式"方式向 worker 发送安全干预。
契约实现位于 loopx/worker_bridge.py，完整说明文档见 docs/integrations/worker-bridge-install-contract.md。
一键预览契约：最小上手步骤
在装有 LoopX 的机器上执行：
loopx worker-bridge contract --format json默认输出全部使用公开占位符（如<loopx-project-root>），不授予任何执行权限，可以直接贴进文档评审：
schema_version=loopx_worker_bridge_install_contract_v0 install_mode=source_mount_read_only_pythonpath loopx_command_prefix=PYTHONPATH='<loopx-project-root>' python3 -m loopx.cli loopx_counter_trace_json=/logs/agent/loopx-counter-trace.jsonl契约渲染逻辑见 build_worker_bridge_install_contract，命令行入口注册在 loopx/cli_commands/worker_bridge.py。
契约的 4 个治理元件
1️⃣ 只读源码挂载：worker 能"看到"但不能"改坏"
build_worker_bridge_mounts 会生成两条bind挂载：LoopX 项目根目录与运行时根目录，均标记read_only: true。worker 里的 Agent 可以读源码、查状态，却改不了治理状态本身——这是"把守卫装进别人家调度器"的第一道防线。
2️⃣ Python 预检：先保证 CLI 桥能跑起来
build_worker_bridge_python_runtime_preflight_command 会生成一段预检脚本：检测到容器没有python3时，自动按apt-get/apk/yum的顺序补装，再导入loopx.cli模块验证。你的调度器只需在启动 worker 前执行一次该命令。
3️⃣ 紧凑计数追踪：治理可审计但不泄密
worker 每调用一次 LoopX CLI，就往loopx-counter-trace.jsonl追加一行"命令 + 成败 + 分类"的紧凑记录（见 append_worker_bridge_counter_trace_row）。公开产物里只有计数，没有原始日志、本地路径或凭据。
4️⃣ active-user 干预通道：受预算约束的"人肉注入"
如果你的任务允许人工/模拟器在 worker 运行中补充提示，可以用active-user-contract子命令生成通道契约：它声明了最小间隔（默认 300 秒）、每任务最多干预次数（默认 3 次）、以及可见性白名单——干预方只能读公开任务描述、worker 公开产物与紧凑状态，绝不能读隐藏测试、期望答案或凭据（见 build_active_user_intervention_channel_contract）。
把它装进你自己的调度器：挂载与参数如何翻译
契约中的mounts和agent_kwargs是"翻译件"：无论你用 Docker、虚拟环境还是 sidecar，都只要做机械映射——
| 契约字段 | 你的调度器要做的事 |
|---|---|
mounts[*] | 逐条转成容器 bind mount，保留read_only标记 |
agent_kwargs.loopx_command_prefix | 作为 worker 内调用 LoopX CLI 的统一前缀 |
agent_kwargs.loopx_runtime_preflight_command | 放进 worker 启动脚本最前面执行 |
agent_kwargs.loopx_counter_trace_json | 确保该路径可写，用于事后审计 |
需要人工协作时，追加一条可写的 feed 挂载即可；私有启动器可以替换为真实宿主路径，但真实路径、凭据与原始工具输出禁止进入公开状态与证据产物——这条边界在 边界文档中有明确约定。
边界承诺：契约"不给你"什么
安装契约刻意保持克制，这在 boundary 段中逐条声明：
- ❌ 不拥有基准测试的结果 schema、打分、上传或提交；
- ❌ 不允许据此声称官方分数或排行榜成绩；
- ❌ 不上传、不记录凭据值与原始路径；
- ✅ 允许声明"受辅助协作"（assisted collaboration）这一更弱、也更诚实的结论。
同一worker-bridge子命令族还承载了 provider 中立的附加 Agent 会话 broker，可让已在运行的宿主会话领取并处理排队的 Web/Connector 消息，但它同样从不启动替代运行时。
两条 Smoke 脚本验证你的安装
装好后，跑仓库自带的两条验证脚本确认"守卫真的生效了"：
python3 examples/cli-worker-bridge-command-modularization-smoke.py python3 examples/worker-bridge-active-user-feed-smoke.py它们分别覆盖命令面拆分正确性（examples/cli-worker-bridge-command-modularization-smoke.py）与 active-user 拉取式干预回路的完整性（examples/worker-bridge-active-user-feed-smoke.py）。更多自定义 Runner 场景可继续阅读 运行时连接器目录。
小结
Worker Bridge 安装契约把 LoopX 的治理守卫压缩成一份可读、可评审、可翻译的声明：只读挂载管住"改坏"，预检命令管住"跑不起来"，计数追踪管住"看不见"，干预通道管住"乱注入"。无论你用容器、sidecar 还是自研调度器，装好这四件，你的 worker 就与官方 Runner 服从同一套 guard。
【免费下载链接】loopxLong-horizon agent control plane for durable, governed work across Codex, Claude Code, and other harnesses.项目地址: https://gitcode.com/GitHub_Trending/lo/loopx
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
