Caveman caveman-manage 技能评估门控实验生命周期的只读安全管控工作流【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman本篇技术指南基于 Caveman 仓库中的 caveman-manage 技能定义完整讲解如何以 Agent 技能的方式审查 Caveman Cloud 上「评估门控实验」eval-gated experiments的生命周期状态与证据并解释为什么该技能刻意将 Agent 的权限限制为只读读完你将掌握该技能的全部 6 条不可协商门non-negotiable gates、五步只读工作流的完整命令与报告模板以及底层 MCP 工具与 CLI 命令在 packages/cli/src/agent-mcp.ts 和 packages/cli/src/index.ts 中的实现依据。技能定位把每次生命周期变更当作生产控制动作caveman-manage是 Caveman 的一个 Agent 技能其元数据声明的触发场景是当用户要求启动、批准、取消、晋升或回滚一个 Caveman 实验时启用见 skills/caveman-manage/SKILL.md 的 frontmatter。它在技能注册表中被登记为agent-native套件成员、仅通过 CLI 交付delivery 为cli摘要为「Review eval-gated experiments and block unsafe lifecycle actions」审查评估门控实验并阻断不安全的生命周期动作见 skills/registry.json。技能的核心设计哲学只有一句话把每一次生命周期变更都视为生产控制动作——先读取当前状态与结果然后报告一个受支持的建议或直接阻断。技能原文还明确说明了它「只读」的原因当前的 Agent MCP 表面是有意的只读设计因为 control-api 尚未能原子性地执行完整的生命周期转移表与证据门evidence gate。这直接解释了后文「阻断不安全执行」步骤的存在——不是 Agent 能力不足而是服务端的权威门禁尚未就位前把写权限暴露给 Agent 本身就是不安全的。六条不可协商门Non-negotiable Gates技能文档用 6 条硬性规则划定了 Agent 的行为边界这些规则是整个工作流的宪法必须逐条理解读请求只授权读。「review、inspect、explain、recommend」这类请求只授权读取操作不授权任何变更。三类情况永不可批准。实验结果处于 pending 状态、所需安全护栏guardrails缺失、或证据报告显示违规breach时一律不得批准。实验 lift 永不等于verified_savings。只有活跃的真实流量加上 provider-causal提供方因果归因、provider-complete提供方账本完整的账本证据才能计入已验证节省。实验阶段的提升lift只是实验性指标不能污染账本口径。永不提供组织 id。项目与租户范围来自已登录的 Caveman 身份和服务端 RBACAgent 不能也不应自行指定组织 id。即使用户口头批准也不执行生命周期变更。原文给出的理由值得注意精确的action:experiment_id字符串是 Agent 可生成的不能作为「人类意图」的证明。未知状态与服务端错误 fail closed失败即关闭。遇到无法识别的状态或服务端错误时停止操作并报告精确的cave_snake_code。其中第 5 条实际上回应了 Agent 工程里一个经典问题用户说「你帮我批准吧」之后Agent 能不能执行该技能的答案是否定的——因为在自然语言交互中「批准」二字本身可以被诱导、被误输入唯一可靠的批准必须发生在服务端授权链路上。Step 1 — 加载项目与实验工作流第一步是读取当前身份、项目与实验。技能文档优先推荐 MCP 调用caveman_context {} caveman_experiment_get {action:get,experiment_id:id} caveman_experiment_get {action:results,experiment_id:id}当用户没有给出具体实验 id 时改用{action:list}列出当前项目的实验。MCP 不可用时的 CLI 回退命令caveman cloud experiments list caveman cloud experiments show id caveman cloud experiments results id终止条件如果登录态、项目、实验或结果中任何一项不可用立即停止后续步骤。源码印证MCP 工具的真实定义在 packages/cli/src/agent-mcp.ts 中可以确认这两个工具的确切签名caveman_context输入 schema 为空对象additionalProperties: false工具注解标记readOnlyHint: true、destructiveHint: false、idempotentHint: true即协议层面就声明为只读幂等操作。其实现并行请求/api/v1/auth/me、/api/v1/projects和当前选中项目 id返回{ identity, projects, selected_project_id }。caveman_experiment_getaction参数被限定为[list, get, results]三个枚举值experiment_id最小长度为 1。实现分支中list走GET /api/v1/experimentsget与results分别请求/api/v1/experiments/{id}与/api/v1/experiments/{id}/results全部附带从当前身份推导的project_id查询参数——这正是门 4「不提供组织 id」在实现层的落地。另外initialize握手返回的instructions字段本身就写明了设计意图agent-mcp.ts 中的 initialize 分支Read evidence first. Keep inferred headroom separate from verified savings. This MCP surface is read-only; experiment lifecycle actions require server-authoritative gates before agent exposure.也就是说「推断空间inferred headroom与已验证节省verified savings必须分开」「MCP 表面只读实验生命周期动作必须等服务端权威门禁上线后才能暴露给 Agent」这两条约束被写进了协议握手响应而不是仅仅写在技能文档里。源码印证CLI 同样只有 GETCLI 侧的 packages/cli/src/index.ts 中experimentCommand函数验证了「CLI 也只暴露读取」的说法list对应GET /api/v1/experiments?project_id...show与results分别对应GET /api/v1/experiments/{id}和GET /api/v1/experiments/{id}/results。函数体内没有任何 POST/PUT/PATCH 调用命令用法提示也只列出experiments list|show id|results id三种子命令。CLI 与 MCP 两个表面在实现上共同兑现了技能文档的声明experiment 的 Agent 表面只暴露读。Step 2 — 评估证据读取完成后Agent 需要向用户报告一份结构化的证据清单包含当前生命周期状态与安全等级lifecycle state and safety class对照组与候选组的样本量control and candidate sample sizes质量或评估结果quality or eval result存在时的各项护栏延迟、错误率、成本、重试、丢弃、升级证据成本evidence cost回滚或暂缓hold的原因结果处于 pending、failed、promotable 还是 active。技能文档对这一步有一条容易被忽略的强约束「缺失不等于通过」Absence is not a pass。如果某个必需字段缺失必须明确声明evidence incomplete证据不完整并且不得提出批准建议。这是典型的 fail-closed 工程把「没看到这个数据」和「这个数据合格」严格区分开避免 Agent 在字段缺省时做乐观推断。Step 3 — 提出至多一个动作评估之后Agent 只能提出四个受支持动作中的一个且每个动作都有严格的前置条件动作允许的前置条件start仅当实验处于可启动的 draft 或 queued 状态且已配置 graderapprove仅当证据完整且全部通过且当前角色有权批准该安全等级cancel仅用于停止一个非 active、用户不再需要的实验rollback仅用于通过服务端关联的 policy path 回滚一个 active 或有危害的变更技能文档对rollback特别加了一条诚实性要求当前部署可能会用cave_not_implemented如实拒绝回滚请求此时绝不能把这个响应描述成「回滚成功」——这与门 6 的「报告精确cave_snake_code」相呼应要求 Agent 如实转述服务端的拒绝原因而不是替用户脑补成功。推荐输出必须展示建议与实验 id原文给出的标准格式为Proposed action: approve experiment 7f... Reason: candidate passed quality and every configured guardrail. Execution: blocked until server-authoritative lifecycle and evidence gates ship.注意第三行「Execution: blocked」是格式模板的一部分不是可选项。同时文档强调之前对话里出现的 manage it、do what is best 这类泛化表述不构成对变更的批准。Step 4 — 阻断不安全执行这一步是整个技能的存在理由Agent不发出也不执行任何可执行的生命周期命令。技能文档给出的解释是当前服务端尚不能原子地强制执行每一个「证据/状态转移」因此 CLI 和 MCP 的 Agent 表面只暴露实验读取。结合前文源码分析这条声明与实现是一致的MCP 工具带readOnlyHint注解、CLI 命令只有 GET 路径协议握手 instructions 也明确写明只读表面。技能、协议、CLI 三层在「不执行变更」上口径统一。Step 5 — 外部操作者行动后重新读取当用户作为人类操作者声称自己已经在服务端执行了某条命令Agent 的正确动作不是采信而是重新读取实验详情与结果报告服务端观测到的后状态post-state、audit 或 result 响应、以及返回的任何 policy-delivery 状态永不基于「操作者声称成功」来推断成功。收尾报告必须使用固定模板Action: action experiment-id Before: state Server response: status and cave_snake_code if any After: re-read state Basis: experiment evidence only. Verified savings unchanged unless the signed ledger independently records active, provider-causal real-traffic savings.模板最后一句把第 3 条门再次钉死在每次交互的结尾除非签名账本独立记录了活跃、provider-causal 的真实流量节省否则verified_savings保持不变。这个「实验证据与已验证节省分离」的口径在仓库其他文档中也是一贯的例如 docs/WRAP-BENCHMARK.md 在报告基准结果时特意声明该数据是受控基准证据benchmark_counterfactual不是生产流量、不是供应商账单、更不是 Caveman 的verified_savings。设计要点总结caveman-manage这个技能的价值不在命令本身——list/show/results三个读操作非常朴素——而在于它用一份技能文档把「Agent 在拥有部分控制面 API 的世界里应该如何约束自己」写成了可执行的规则能力面capability与授权面authorization解耦即使服务端已经能提供 start/approve/cancel/rollback 接口Agent 也只在服务端原子门禁生命周期转移表 证据门就位之前保持只读fail closed 贯穿始终证据缺失即evidence incomplete、未知状态即停止并报告cave_snake_code、cave_not_implemented不得被美化成成功人类意图不可伪造action:experiment_id字符串是 Agent 可生成的因此它永远只是「建议」而非「批准」真正执行必须由操作者在服务端授权链路完成指标口径防污染实验 lift 与verified_savings严格分离后者只认「活跃真实流量 提供方因果账本」这一种证据来源。对维护者而言该技能的演进路径也写在文档里一旦服务端上线原子性的生命周期与证据门禁Step 4 的阻断约束即可按新门禁重新校准在那之前这份只读工作流就是当前部署下管理实验的唯一安全姿势。【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Caveman caveman-manage 技能：评估门控实验生命周期的只读安全管控工作流
Caveman caveman-manage 技能评估门控实验生命周期的只读安全管控工作流【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman本篇技术指南基于 Caveman 仓库中的 caveman-manage 技能定义完整讲解如何以 Agent 技能的方式审查 Caveman Cloud 上「评估门控实验」eval-gated experiments的生命周期状态与证据并解释为什么该技能刻意将 Agent 的权限限制为只读读完你将掌握该技能的全部 6 条不可协商门non-negotiable gates、五步只读工作流的完整命令与报告模板以及底层 MCP 工具与 CLI 命令在 packages/cli/src/agent-mcp.ts 和 packages/cli/src/index.ts 中的实现依据。技能定位把每次生命周期变更当作生产控制动作caveman-manage是 Caveman 的一个 Agent 技能其元数据声明的触发场景是当用户要求启动、批准、取消、晋升或回滚一个 Caveman 实验时启用见 skills/caveman-manage/SKILL.md 的 frontmatter。它在技能注册表中被登记为agent-native套件成员、仅通过 CLI 交付delivery 为cli摘要为「Review eval-gated experiments and block unsafe lifecycle actions」审查评估门控实验并阻断不安全的生命周期动作见 skills/registry.json。技能的核心设计哲学只有一句话把每一次生命周期变更都视为生产控制动作——先读取当前状态与结果然后报告一个受支持的建议或直接阻断。技能原文还明确说明了它「只读」的原因当前的 Agent MCP 表面是有意的只读设计因为 control-api 尚未能原子性地执行完整的生命周期转移表与证据门evidence gate。这直接解释了后文「阻断不安全执行」步骤的存在——不是 Agent 能力不足而是服务端的权威门禁尚未就位前把写权限暴露给 Agent 本身就是不安全的。六条不可协商门Non-negotiable Gates技能文档用 6 条硬性规则划定了 Agent 的行为边界这些规则是整个工作流的宪法必须逐条理解读请求只授权读。「review、inspect、explain、recommend」这类请求只授权读取操作不授权任何变更。三类情况永不可批准。实验结果处于 pending 状态、所需安全护栏guardrails缺失、或证据报告显示违规breach时一律不得批准。实验 lift 永不等于verified_savings。只有活跃的真实流量加上 provider-causal提供方因果归因、provider-complete提供方账本完整的账本证据才能计入已验证节省。实验阶段的提升lift只是实验性指标不能污染账本口径。永不提供组织 id。项目与租户范围来自已登录的 Caveman 身份和服务端 RBACAgent 不能也不应自行指定组织 id。即使用户口头批准也不执行生命周期变更。原文给出的理由值得注意精确的action:experiment_id字符串是 Agent 可生成的不能作为「人类意图」的证明。未知状态与服务端错误 fail closed失败即关闭。遇到无法识别的状态或服务端错误时停止操作并报告精确的cave_snake_code。其中第 5 条实际上回应了 Agent 工程里一个经典问题用户说「你帮我批准吧」之后Agent 能不能执行该技能的答案是否定的——因为在自然语言交互中「批准」二字本身可以被诱导、被误输入唯一可靠的批准必须发生在服务端授权链路上。Step 1 — 加载项目与实验工作流第一步是读取当前身份、项目与实验。技能文档优先推荐 MCP 调用caveman_context {} caveman_experiment_get {action:get,experiment_id:id} caveman_experiment_get {action:results,experiment_id:id}当用户没有给出具体实验 id 时改用{action:list}列出当前项目的实验。MCP 不可用时的 CLI 回退命令caveman cloud experiments list caveman cloud experiments show id caveman cloud experiments results id终止条件如果登录态、项目、实验或结果中任何一项不可用立即停止后续步骤。源码印证MCP 工具的真实定义在 packages/cli/src/agent-mcp.ts 中可以确认这两个工具的确切签名caveman_context输入 schema 为空对象additionalProperties: false工具注解标记readOnlyHint: true、destructiveHint: false、idempotentHint: true即协议层面就声明为只读幂等操作。其实现并行请求/api/v1/auth/me、/api/v1/projects和当前选中项目 id返回{ identity, projects, selected_project_id }。caveman_experiment_getaction参数被限定为[list, get, results]三个枚举值experiment_id最小长度为 1。实现分支中list走GET /api/v1/experimentsget与results分别请求/api/v1/experiments/{id}与/api/v1/experiments/{id}/results全部附带从当前身份推导的project_id查询参数——这正是门 4「不提供组织 id」在实现层的落地。另外initialize握手返回的instructions字段本身就写明了设计意图agent-mcp.ts 中的 initialize 分支Read evidence first. Keep inferred headroom separate from verified savings. This MCP surface is read-only; experiment lifecycle actions require server-authoritative gates before agent exposure.也就是说「推断空间inferred headroom与已验证节省verified savings必须分开」「MCP 表面只读实验生命周期动作必须等服务端权威门禁上线后才能暴露给 Agent」这两条约束被写进了协议握手响应而不是仅仅写在技能文档里。源码印证CLI 同样只有 GETCLI 侧的 packages/cli/src/index.ts 中experimentCommand函数验证了「CLI 也只暴露读取」的说法list对应GET /api/v1/experiments?project_id...show与results分别对应GET /api/v1/experiments/{id}和GET /api/v1/experiments/{id}/results。函数体内没有任何 POST/PUT/PATCH 调用命令用法提示也只列出experiments list|show id|results id三种子命令。CLI 与 MCP 两个表面在实现上共同兑现了技能文档的声明experiment 的 Agent 表面只暴露读。Step 2 — 评估证据读取完成后Agent 需要向用户报告一份结构化的证据清单包含当前生命周期状态与安全等级lifecycle state and safety class对照组与候选组的样本量control and candidate sample sizes质量或评估结果quality or eval result存在时的各项护栏延迟、错误率、成本、重试、丢弃、升级证据成本evidence cost回滚或暂缓hold的原因结果处于 pending、failed、promotable 还是 active。技能文档对这一步有一条容易被忽略的强约束「缺失不等于通过」Absence is not a pass。如果某个必需字段缺失必须明确声明evidence incomplete证据不完整并且不得提出批准建议。这是典型的 fail-closed 工程把「没看到这个数据」和「这个数据合格」严格区分开避免 Agent 在字段缺省时做乐观推断。Step 3 — 提出至多一个动作评估之后Agent 只能提出四个受支持动作中的一个且每个动作都有严格的前置条件动作允许的前置条件start仅当实验处于可启动的 draft 或 queued 状态且已配置 graderapprove仅当证据完整且全部通过且当前角色有权批准该安全等级cancel仅用于停止一个非 active、用户不再需要的实验rollback仅用于通过服务端关联的 policy path 回滚一个 active 或有危害的变更技能文档对rollback特别加了一条诚实性要求当前部署可能会用cave_not_implemented如实拒绝回滚请求此时绝不能把这个响应描述成「回滚成功」——这与门 6 的「报告精确cave_snake_code」相呼应要求 Agent 如实转述服务端的拒绝原因而不是替用户脑补成功。推荐输出必须展示建议与实验 id原文给出的标准格式为Proposed action: approve experiment 7f... Reason: candidate passed quality and every configured guardrail. Execution: blocked until server-authoritative lifecycle and evidence gates ship.注意第三行「Execution: blocked」是格式模板的一部分不是可选项。同时文档强调之前对话里出现的 manage it、do what is best 这类泛化表述不构成对变更的批准。Step 4 — 阻断不安全执行这一步是整个技能的存在理由Agent不发出也不执行任何可执行的生命周期命令。技能文档给出的解释是当前服务端尚不能原子地强制执行每一个「证据/状态转移」因此 CLI 和 MCP 的 Agent 表面只暴露实验读取。结合前文源码分析这条声明与实现是一致的MCP 工具带readOnlyHint注解、CLI 命令只有 GET 路径协议握手 instructions 也明确写明只读表面。技能、协议、CLI 三层在「不执行变更」上口径统一。Step 5 — 外部操作者行动后重新读取当用户作为人类操作者声称自己已经在服务端执行了某条命令Agent 的正确动作不是采信而是重新读取实验详情与结果报告服务端观测到的后状态post-state、audit 或 result 响应、以及返回的任何 policy-delivery 状态永不基于「操作者声称成功」来推断成功。收尾报告必须使用固定模板Action: action experiment-id Before: state Server response: status and cave_snake_code if any After: re-read state Basis: experiment evidence only. Verified savings unchanged unless the signed ledger independently records active, provider-causal real-traffic savings.模板最后一句把第 3 条门再次钉死在每次交互的结尾除非签名账本独立记录了活跃、provider-causal 的真实流量节省否则verified_savings保持不变。这个「实验证据与已验证节省分离」的口径在仓库其他文档中也是一贯的例如 docs/WRAP-BENCHMARK.md 在报告基准结果时特意声明该数据是受控基准证据benchmark_counterfactual不是生产流量、不是供应商账单、更不是 Caveman 的verified_savings。设计要点总结caveman-manage这个技能的价值不在命令本身——list/show/results三个读操作非常朴素——而在于它用一份技能文档把「Agent 在拥有部分控制面 API 的世界里应该如何约束自己」写成了可执行的规则能力面capability与授权面authorization解耦即使服务端已经能提供 start/approve/cancel/rollback 接口Agent 也只在服务端原子门禁生命周期转移表 证据门就位之前保持只读fail closed 贯穿始终证据缺失即evidence incomplete、未知状态即停止并报告cave_snake_code、cave_not_implemented不得被美化成成功人类意图不可伪造action:experiment_id字符串是 Agent 可生成的因此它永远只是「建议」而非「批准」真正执行必须由操作者在服务端授权链路完成指标口径防污染实验 lift 与verified_savings严格分离后者只认「活跃真实流量 提供方因果账本」这一种证据来源。对维护者而言该技能的演进路径也写在文档里一旦服务端上线原子性的生命周期与证据门禁Step 4 的阻断约束即可按新门禁重新校准在那之前这份只读工作流就是当前部署下管理实验的唯一安全姿势。【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考