OpenRig 活动钩子设计全解/api/activity/hooks 如何做到绝不泄露提示词【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig让你用 Claude Code、Codex 和 Pi 组建一支持久运行的 AI Agent 团队——每个 Agent 有角色、共享上下文、拥有自己的工位seat。当你盯着一支多 Agent 团队时最关心的问题只有一个它们现在在干什么OpenRig 的答案是活动钩子Activity Hooks与中继Relay机制。本文带你完整看懂/api/activity/hooks这个端点以及 OpenRig 如何通过发送端白名单 接收端白名单 本地令牌 最小状态词汇四层设计保证你的提示词prompt与工具参数永远不会被上报。先看效果每个席位的正在忙/空闲从哪来在 TUI 的拓扑视图里每个 Agent 席位都会显示一个状态点和上下文占用百分比。这些状态不是靠偷看终端输出猜出来的而是由运行时Claude Code、Codex、Pi 等自带的生命周期钩子在关键时刻主动上报会话开始、停止、等待输入等事件触发中继脚本把一条极小的事件 POST 到守护进程的/api/activity/hooks。中继脚本在源头就做减法上报的起点是插件目录里的中继脚本 activity-relay.cjs。它挂在运行时如 Claude Code 的 Stop 钩子、Codex 的 hook上从 stdin 读入供应商给的完整事件负载然后只挑出 7 个字段重新组装sessionName/nodeId/runtime—— 我是谁generation—— 哪一代占位者发的防旧进程诈尸hookEvent/subtype/occurredAt—— 发生了什么、什么类型、何时注意供应商原始负载里可能有工具名、文件路径等敏感信息而 buildOpenRigPayload 只读取白名单字段提示词正文和工具参数在源头就不存在。官方 README 也明确写明That payload excludes prompt text and tool arguments见 README.md。中继还有两个贴心的健壮性设计绝不拖慢 AgentPOST 超时上限 1.5 秒任何错误直接吞掉钩子永远不阻塞 Agent 主循环。三级发现机制优先读环境变量OPENRIG_URL/OPENRIG_ACTIVITY_HOOK_TOKEN读不到就用 hostport 拼 URL再不行就回退读取~/.openrig/activity-endpoint.json文件——这样即使守护进程重启过、进程环境是冻结的旧值席位依然能正确上报。/api/activity/hooks 端点接收端再做一次白名单事件到达 activity.ts 的 POST/hooks后还要过两道关卡第一关令牌认证。守护进程为每个安装生成一个活动钩子令牌32 字节随机数以0600 权限存在本地状态目录里见 activity-endpoint.ts。令牌跨重启保持稳定所以老席位重启后仍能通过认证。请求必须携带Authorization: Bearer token或x-openrig-activity-token头二者缺一即 401。这个令牌被刻意设计为本地回环内部凭证不出现在日志里也不为它过度设计脱敏机制——因为它本来就只在本机生效。第二关字段白名单。端点并不JSON.parse后照单全收而是调用store.recordHookEvent()时逐个指名取值activity.ts#L260-L271runtime、sessionName、nodeId、hookEvent、subtype、occurredAt、generation。即使有人在请求体里塞入提示词全文这些字段也会被静默丢弃——接收端根本不认识它们。为什么保证不泄露提示词四层设计一览层位置防什么① 发送端白名单中继脚本原始负载中的 prompt、工具参数在组装 payload 时就被剔除② 接收端白名单recordHookEvent服务端只按字段名取值多余内容不入库③ 本地令牌认证0600 权限 token 文件防止未授权进程向端点投递任意内容④ 最小状态词汇活动分类法即便事件入库也只映射为 working / idle-at-prompt / unknown 三值第四层是最精妙的。看 activity-taxonomy.ts整个活动分类法只有三个状态值working | idle-at-prompt | unknown。钩子事件经 evidenceFromHookActivity 转换后running→ workingidle→ idle-at-promptneeds_input则变成一个计数 短理由短语比如 permission prompt理由也只是一句人类可读的话而非原文内容。未知状态被当作噪声直接丢弃诚实的 unknown 好过自信的错答。换句话说即使上游某个环节失守这个数据模型的天花板也只是某席位在等待输入——没有任何字段能装下提示词。顺带一提推送通道也只发有变化的通知守护进程还提供GET /api/activity/eventsSSE但按 activity.ts#L328-L358 的设计它只转发seat.activity_changed、seat.rung_health等变更通知身份 序号视图收到通知后自行从/api/ps拉取完整状态。推送链路里同样没有派生内容没有第二套活动机制由构造上就成立。想亲眼验证从这里读起中继脚本与三级发现机制activity-relay.cjs端点认证与字段取值routes/activity.ts令牌生成与 0600 持久化domain/activity-endpoint.ts状态词汇表与证据阶梯domain/activity-taxonomy.ts防篡改测试验证rip-proofactivity-hook-rip-proof.test.ts令牌持久化测试identity-hook-token-persisted.test.ts演示 rig 配置demo/rig.yamlAgent 角色定义见 demo/agents/lead/agent.yaml总结OpenRig 的活动钩子体系是一个值得借鉴的最小数据面设计范例在产生数据的最源头就只采集白名单字段接收端再独立做一遍字段过滤用本地令牌守住入口最后用一个三值状态词汇表给所有数据模型封顶。四层叠加任何一层单独失效都有下一层兜底——这就是/api/activity/hooks能大胆地只看状态、不看内容从而在实时掌握 Agent 团队动态的同时保证提示词一个字节都不外泄的原因。【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考