mcpField
C
caveman-discover

caveman-discover

github.com/juliusbrussee云与 DevOps115.8k107.3k 次安装3 天前更新
代码仓库

关于 caveman-discover

caveman-discover 是一项由操作人员调用的技能，用于查找代码库中的 LLM 工作流，并为经 Caveman 网关路由的调用添加标签。它先提交工作流表供审批，再修改代码并验证结果。

主要功能

  1. 01盘点 LLM 工作流入口
  2. 02使用有效 slug 命名工作流
  3. 03修改前征求审批
  4. 04标记经网关路由的调用
  5. 05验证已标记路径

适用场景

  1. 01为 Caveman Cloud 标记代码库工作流
  2. 02在改代码前审核工作流名称
  3. 03检查已执行路径的网关标签

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/juliusbrussee/caveman --skill caveman-discover

安装后在 Claude Code 中输入/caveman-discover确认已加载。

详细介绍

你正在为 Caveman Cloud 标注此代码库的 LLM 工作流。工作流是代码执行的一项任务——例如“回复支持工单”“生成每晚摘要”“运行评测套件”——而不是某种技术。每个网关请求都可以携带工作流标签；未标注的流量都会归入同一个 unlabeled-workflow 分类。你的任务是找出工作流，为它们起好名称，接入标签，并验证没有造成问题。

这会修改代码，因此要遵循用户的常规审核流程：先提出表格，获得用户同意后再应用。 对已标注的代码库重复运行时，不得做出任何更改（保持幂等）。

此技能由操作者手动调用。unlabeled-traffic Cave Plan 观测仅供审核，不会创建 advisory 文件、提案或 Draft PR。不要推断遥测数据选定了某个调用点，也不要推断它授权了编辑。请独立盘点代码库，展示标注表，并等待用户批准后再修改代码。

第 1 步 — 盘点工作流

从代码库的入口开始梳理，而不是从导入语句开始：

  • 调用 LLM 的 HTTP/RPC 处理程序（直接调用或经由多层封装）
  • 定时作业：调用 LLM 代码的 cron 定义、队列消费者、worker、GitHub Actions
  • CLI 命令和脚本（scripts/、bin/、package.json 脚本）
  • 会消耗实际 token 的评测 / 测试工具
  • 框架中不同的 Agent 或链（通常每个 LangGraph 图、每个 crew、每个 Agent 定义都是独立的工作流）

一个工作流 = 一项人们会命名的任务。同一个请求处理程序中的十个调用点算作一个工作流；三个作业共用的 llm.ts 辅助工具算作三个工作流（在调用方标注，绝不要在共用的辅助工具中标注）。

第 2 步 — 命名

Slug 语法（网关会强制执行）：小写 [a-z0-9_-]，长度为 1–96 个字符。命名任务，而不是技术：

  • 好：support-reply、nightly-digest、pr-review、eval-suite、 onboarding-email
  • 不好：openai-calls（技术）、main（毫无说明）、SupportReply（无效）、 johns-test-3（不适合长期使用）

名称几乎是永久的——之后重命名会拆分支出历史记录。如果无法从代码中明确判断作业的用途，请根据文件名生成 slug，并在表格中标记为 review，而不要臆造用途。

第 3 步 — 先提议，再应用

展示此表格并询问是否继续：

| workflow | job | where | how it gets labeled |
|---|---|---|---|
| support-reply | answers inbound tickets | src/bot/reply.ts:41 | defaultHeaders on the reply client |
| nightly-digest | 02:00 summary job | jobs/digest.ts:12 | header on the digest client |
| eval-suite (review) | scripts/eval.ts:8 — purpose inferred from filename | scripts/eval.ts:8 | env override at invocation |

然后使用调用点可用的最轻量方式接入每个标签：

  • @caveman-ai/sdk / caveman_cloud SDK：使用每条 trace 的 workflow 选项，或者在单作业服务构建的客户端上设置 defaultWorkflow。
  • 原始提供商 SDK（OpenAI/Anthropic/LangChain/LiteLLM/Vercel）：在现有的 defaultHeaders / default_headers / extra_headers 配置块中添加 "x-cave-workflow": "<slug>"；该配置块已包含 x-cave-api-key。如果多个作业共用一个客户端 → 每次调用时传入该请求头（上述 SDK 都支持按请求覆盖请求头），或者为每个作业创建独立的轻量客户端。
  • 封装的编码 Agent（caveman wrap）：在调用位置（cron 行、CI 步骤）使用 --workflow <slug> 标志或 CAVE_WORKFLOW=<slug> 环境变量。
  • 原始 HTTP：为请求添加 x-cave-workflow 请求头。

在调用方添加标签，让差异尽可能精简，并遵循代码库的风格。如果某个调用点完全没有经过 Caveman 网关，就不要添加标签——在报告的“未接入”部分列出它（标签只会随网关流量传递；接入工作应由 caveman-setup 技能完成）。

第 4 步 — 验证

运行代码库现有的方式来执行一条已标注路径（测试、开发脚本或一次 curl）。然后确认请求仍能成功（如果网关因标签无效而返回 400 cave_invalid_request_header，请修正 slug）。每个工作流下次运行时，已标注的支出会显示在 /activity?tab=workflows 仪表板上；按计划运行的作业会在计划触发时显示。报告中应如实说明这一点，而不要声称它们已经上线运行。

第 5 步 — 报告

## Workflows labeled

| workflow | job | where |
|---|---|---|
| support-reply | answers inbound tickets | src/bot/reply.ts:41 |
| nightly-digest | 02:00 summary job | jobs/digest.ts:12 |

Verified: <the labeled path you actually exercised, and what you observed>
Lands at: <DASHBOARD>/activity?tab=workflows — each row appears as that workflow
next runs. Anything still unlabeled shows as `unlabeled-workflow`.
Not wired (no gateway routing, so no label): <list or "none">
Marked review: <slugs whose purpose was inferred from filenames, or "none">

如果完全没有找到大模型入口：请如实说明，并指向设置技能（<docs origin>/docs/agent-setup.md），而不是凭空编造表格。

评论

支持 Markdown