OpenRig rig ask 与 ask-wake 实战上下文包提问与唤醒机制【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig 是一个多智能体运行框架Multi-agent Harness让Claude Code 与 Codex 像同一个系统一样协同工作。当多个 Agent 并行运转数天后我们当时到底讨论过什么就成了高频难题——️ 这正是rig ask与ask-wake机制要解决的问题前者用自然语言检索整个 rig 的历史转录后者通过 resume token唤醒一次离线的 Agent 会话拿到快照式回答后立即回到冷启动状态。为什么问旧事对多 Agent 系统很难传统单 Agent 场景下翻聊天记录就够了。但在 OpenRig 里一个 rig 可能包含 lead、planner、driver、qa 等大量 seat席位每个 seat 还经历多代会话generation会话文件散落在宿主上token 一长串几乎没人记得住检索有成本全 rig 转录很大不能每次问旧事都真把 Agent 叫醒唤醒有运行时开销真正执行 Agent 是有代价的必须显式、可控、不能无限挂起。OpenRig 的解法是一条分层的信息获取阶梯先便宜地考古实在需要才唤醒。rig ask 三级机制从只读考古到头less唤醒rig ask是关于过去的信息这一个动词见 ask.tsrig ask rig question [--json]它按成本从低到高分为三级第一级全 rig 转录检索只读最便宜直接用自然语言问整个 rig 的历史rig ask my-rig what decisions were made about deployment?结果以转录证据Transcript Evidence或结构化答案的形式列出零运行时成本。第二级--seat / --session 精确考古只读--seat 成员rig把检索限定到一个 seat 的跨代转录cross-generation archaeology——同一个席位上坐过的所有住户都会翻出来--session token只按会话 token 检索某一份JSONL 会话文件适合我有 token帮我找的场景。rig ask my-rig what did we decide --seat dev-plannermy-rig rig ask my-rig SECRET_MARKER --session 3f2a-...-9c1第三级--wake 无头唤醒EXECUTES有运行时成本这是唯一真正执行的层级唤醒目标会话、问一个问题、拿到快照式回答snapshot answer、进程立即回到冷态。核心实现在 ask-wake.ts按运行时构造无头命令Claudeclaude -p --resume token questionCodexcodex exec resume token question唤醒目标既可以是原始 token也可以是席位rig ask my-rig summarize the gateway plan --wake 3f2a-...-9c1 rig ask my-rig summarize the gateway plan --wake leadmy-rig2 # 指定第 2 代住户leadmy-rig2这种写法中末尾纯数字段表示 generation见 parseSeatGen。席位目标会先通过守护进程的/api/wake-resolve接口wake-resolve.ts解析为具体 token解析失败会拒绝并列出该席位所有已知住户绝不猜测唤醒。ask-wake 的四条诚实性设计ask-wake的默认行为刻意追求不撒谎runWake设计说明有界超时默认 180 秒超时明确报告而非静默挂起可用--wake-timeout 秒调整大文件预警会话文件超过 200 MB 时提示唤醒可能需要几分钟失败即失败进程非零退出 失败token 失效/缺二进制/需鉴权不是成功但空回答快照证言输出标注 checked, not believed——回答是待核实的证词不是事实上下文包让提问和唤醒有锚点单靠唤醒拿到的是历史会话的视角而**上下文包Context Pack**为 Agent 提供一份一致、可寻址的起始上下文——它是运营者编写的manifest 文件打包context-packs.tsrig context list # 浏览库中的上下文包 rig context add source # 从目录或 URL 安装上下文包本身不投递This noun never delivers投递由send、broadcast、queue create等动词负责queue create --body-context ref会把整个上下文包快照进队列条目正文并打上body-context:ref溯源标签。实践中的典型组合拳是上下文包定锚 → Agent 干活 → rig ask 考古 → ask-wake 唤醒求证。用 Demo 环境快速上手项目自带一套开箱即用的演示 rig拓扑里混编了 CLAUDE 与 CODEX 两种运行时的节点demo/rig.yaml、demo/README.md./demo/run.sh # 启动 demo rig启动后按这个顺序体验最顺rig ps/rig status确认 rig 与守护进程状态rig ask demo ...全 rig 检索感受证据式输出rig ask demo ... --seat leaddemo看跨代考古拿到某会话 token 后用--wake体验唤醒观察快照回答 回到冷态。 退出码约定0成功、1守护进程未运行、2获取数据失败或唤醒超时详见 cli-reference.md 中rig ask小节。常见坑速查Daemon not running先rig up或rig status--wake传原始 token 时可不依赖守护进程席位解析失败输出会列出该席位全部已知住户含无 resume token标注换一代次再试即可唤醒超时大会话文件数百 MB会明显变慢加--wake-timeout 300或后台执行回答为空非零退出已被诚实地报告为失败不要把它当Agent 说没事。小结rig ask与ask-wake构成了 OpenRig 的历史信息获取阶梯L1/L2 只读考古便宜安全--wake显式唤醒昂贵但精准配合上下文包为 Agent 锚定一致语境。分层、有界、失败不装成功——这三点让问旧事在多 Agent 系统里第一次变得既可靠又可控。【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考