Corsair Agent Guide 实战解析仓库布局、开发命令与插件 PR 自动化【免费下载链接】corsairConnect your users to their apps项目地址: https://gitcode.com/GitHub_Trending/corsa/corsair本指南以 CLAUDE.md 为骨架围绕 Corsair开源 Agent 集成层约 70 个插件包的仓库布局、开发工作流、插件 PR 规则、LLM 网关与产品形态五个维度展开。读完你将掌握如何快速定位插件与核心代码、如何用pnpm脚本执行 lint/typecheck/build/test 与插件脚手架以及插件 PR 的自动化评审Greptile Gate 零 LLM 的 review loop与 PR 规则scope、tests、description、demo video如何被强制执行。所有结论均可在本仓库 源码与配置 中找到依据。仓库布局插件、核心与站点的边界CLAUDE.md 定义了清晰的目录职责划分packages/plugin/— 每个集成一个独立包slack、gmail、github、linear 等。除corsair、cli、mcp、studio、ui、app之外的所有包都是插件。例如 packages/slack、packages/gmail 各自维护 endpoint、schema、webhook 与测试。packages/corsair/— 核心包。所有插件在此通过core/constants.ts注册。www/— corsair.dev 官网与 OSS 贡献者仪表盘位于src/app/oss/。scripts/pr-review/— 插件 PR 自动化评审循环详见 docs/pr-review-bot.md。插件注册机制从 constants.ts 到 AllProviders插件注册的唯一入口是 packages/corsair/core/constants.ts。该文件用as const声明了BaseProviders数组从ably、abstract一直到zoominfo涵盖 Ably、Slack、Gmail、GitHub、Notion、Stripe、Zoom 等主流服务并通过ProviderDisplayNames映射每个插件的展示名。文件末尾同时导出联合类型AllProviders与AuthTypesoauth_2 | api_key | bot_token | managed构成插件命名空间的类型安全基础。新增一个插件时脚手架scaffold会直接修改这份注册表pnpm generate:plugin会为插件生成独立包并在packages/corsair/core/constants.ts中追加一行注册。这也是 PR 评审中允许额外修改的文件见下文 Gate R1之一——可见该文件是插件生态的核心枢纽。开发命令一套 pnpm 脚本跑完整个工作流CLAUDE.md 列出的命令与根 package.json 中scripts完全对应整个仓库使用 pnpm turbo 管理monorepopackageManager: pnpm10.20.0pnpm lint # biome check .代码风格与静态检查 pnpm lint:fix # biome check . --fix --unsafe pnpm typecheck # tsc --build全仓类型检查 pnpm build # turbo --filter ./packages/* --filter ./adapters/* build pnpm test # turbo --filter ./packages/* --filter ./adapters/* test pnpm generate:plugin # 脚手架生成一个新插件 pnpm run validate:plugins # 插件结构校验几点说明lint 由 Biome 承担biomejs/biome2.x并在 git 钩子中通过lint-staged对暂存文件自动执行见 package.json 的simple-git-hooks配置pre-commit 跑 lint-staged、commit-msg 校验提交信息、pre-push 跑 typecheck。build/test 只作用于包目录packages/*与adapters/*turbo负责任务编排。generate:plugin 要求插件名必须为 PascalCase如Slack、GoogleCalendarscripts/generate-plugin.ts 的validatePascalCase会拒绝含-、_、空格或以小写字母开头的名称随后生成packages/plugin/下的 package.json、tsconfig、endpoints/、webhooks/、schema/ 目录与测试骨架并写入core/constants.ts注册。生成的插件默认声明api_key与oauth_2两种认证类型依赖 scripts/plugin-tenant-routing-scaffold.ts 的buildAuthConfigTs。仓库还提供了generate:plugin-from-json、generate:docs、generate:readmes、build:explorer-catalog等配套脚本均可从根 package.json 的scripts中查到。插件 PR 规则scope / tests / description / demo videoCLAUDE.md 明确指出.github/PLUGIN_PR_RULES.md是插件 PR 规则的唯一权威来源并由 Greptile 与 Gate job 强制执行且从不自动合并、禁止在生成内容上使用eval/new Function()。Gate 的 R1–R4 判定逻辑确定性检查scripts/pr-review/gate.ts 将规则实现为可测试的纯函数runGate(input: GateInput)输入为变更文件列表、PR 描述、是否 draft、测试文件数与断言数输出逐项pass/warn/fail的检查表。其判定逻辑如下R1 — Scope一次一个插件通过pluginOf(file)从packages/plugin/路径前缀识别插件frpc-*预编译二进制 shim内网隧道用与corsair/cli/mcp/studio/ui/app被排除在插件规则之外。允许的额外文件仅限packages/corsair/core/constants.ts、pnpm-lock.yaml、docs/docs.json与同插件的docs/plugins/plugin/**。改动多个插件或越界文件直接判 fail。R2 — Tests真实断言插件包内必须存在*.test.ts且测试中要有expect()/assert()调用断言数少于 5 个ASSERTION_WARN_FLOOR会给出 warn。该检查针对插件包本身而非 diff因此更新型 PR 不必重复触碰测试。R3 — Description描述质量PR 模板清单存在未勾选项- [ ]即 fail## Description小节去除 HTML 注释后不足 20 字符判 fail若没有Fixes #…/Closes #…或 corsair.dev/oss claim 链接则给 warn。R4 — Demo video演示视频## Screenshots / Demos小节必须包含至少一个http(s)://链接否则 fail。Gate 的结果通过标记为!-- corsair-pr-gate --的 sticky 评论渲染为Plugin PR scorecard表格renderScorecard并维护gate:failed标签。Greptile 的源码级规则LLM 评审greptile.json 配置了 Greptile 对packages/**的评审规则strictness: 2开启 status checkP0阻断插件 PR 只允许改动单个packages/plugin/目录加上packages/corsair/core/constants.ts、pnpm-lock.yaml、同插件的docs/plugins/plugin/**与docs/docs.json任何其他文件的改动都视为 P0。纯文档 PR只动plugin-docs.yaml与docs/plugins/plugin/**、docs/docs.json不适用插件测试/演示规则。eval、new Function()或动态生成代码的执行、硬编码密钥同样列为 P0。P1重要缺少带真实断言的测试脚手架残留占位 base URL、被注释的 Authorization 头、多余的 endpoints/example.ts、TODO 桩每个 endpoint 必须用 zod 校验输入输出、通过插件的error-handlers.ts路由错误含 429 限流处理列表接口在供应商 API 支持时须支持分页实现与 PR 描述不一致已实现 endpoint 缺少对应测试。P2次要导出或公开 API 上的any类型。Greptile 对每个非 draft PR 评审并在每次 push 后重新评审其阻塞式 status check 在有未解决发现时阻止合并。PR review loop零 LLM 成本的自动化评审scripts/pr-review/ 目录实现了完整的评审循环逻辑见 docs/pr-review-bot.md包含gate.ts/gate-main.ts、loop.ts/loop-main.ts、pr-scope.ts/pr-scope-main.ts、parse-greptile.ts及各自的*.test.ts。工作方式如下Greptile评审每个非 draft PR每次 push 后重评发现未解决时通过 status check 阻断合并。Gate jobpr-checks.yml中的plugin-gate确定性检查 R1–R4维护 sticky 评论!-- corsair-pr-gate --与gate:failed标签。Review loopplugin-pr-review-loop.yml在每次 Greptile 评审后触发通过评论标记!-- corsair-review-bot roundN --读取轮次Round 1汇总所有 P0/P1 发现、Gate 失败项P2 仅作可选提示打上bot:round-1标签Escalation贡献者下一次 push 后若仍有 P0/P1 且 Gate 已通过则发布汇总评论并加needs-maintainer标签进入维护者队列同步到内部仪表盘若 Gate 仍未通过则推迟升级并就地刷新 round-1 评论——不完整的 PR 永远不会进入维护者队列。整个循环是模板化的、确定性的零 LLM 成本无论多少次 pushdraft 一律跳过Greptile 对该仓库走 OSS 免费计划。运维要点与本地测试Dry run仓库变量PR_BOT_DRY_RUNtrue时循环只把将要做的事以!-- corsair-review-bot dry-run --评论形式发布不做其他动作用gh variable set PR_BOT_DRY_RUN -R corsairdev/corsair --body false关闭。标签gate:failed、bot:round-1、needs-maintainer用gh label create创建一次。退役密钥旧 Codex 自动修复/推送任务使用的CORSAIR_LLM_KEY与PR_BOT_PAT已不再被该循环使用可安全删除。必选检查上线后需将 Greptile status check 与Plugin PR Gate标记为main分支的 required check。本地测试pnpm exec tsx --test scripts/pr-review/*.test.tsfixtures 为真实 Greptile payload。上线前 Dogfood 清单用非协作者测试账号在 OSS 仪表盘认领集成从 fork 提交一份埋了雷的 PR占位 base URL、注释掉的认证、无测试、未勾选清单、无视频验证 Greptile 标记 → Gate 失败 → dry-run 评论列出所有问题再推送部分修复验证升级到needs-maintainer的路径最后关掉 dry-run 做真实验证观察 3–5 个真实 PR。LLM 网关统一的 OpenAI 兼容入口CLAUDE.md 规定模型调用必须走llm.corsair.dev基于 LiteLLM 的 OpenAI 兼容网关使用带预算限额的 key严禁直接使用供应商 SDK 或个人供应商 key。详细文档见 docs/llm-gateway.mdx要点如下通过环境变量接入LITELLM_API_KEYsk-your-virtual-key、LITELLM_BASE_URLhttps://llm.corsair.dev/v1、LITELLM_MODELgpt-5.4-mini可选默认模型。用curl https://llm.corsair.dev/v1/models -H Authorization: Bearer $LITELLM_API_KEY列出模型用/v1/key/info查询花费与剩余额度返回spend、max_budget、budget_duration剩余 max_budget - spend额度耗尽后请求报错直到重置或提额。OpenAI SDK / Vercel AI SDK 只需把baseURL指向网关即可使用例如createOpenAI({ apiKey, baseURL: https://llm.corsair.dev/v1 })注意不要用默认 OpenAI provider 直连官方文档明确警告openai(gpt-4o)会绕过网关。当OPENAI_API_KEY配合网关baseURL使用时与LITELLM_API_KEY等价。产品形态从 hosted 到 hubCLAUDE.md 最后说明托管产品已从corsairdev/hosted迁移到corsairdev/hubhosted仓库仅接收文档更新。README 也印证了产品定位Corsair 基于 REST API 构建集成层同一套集成可同时服务 Agent、后端服务与客户使用的仪表盘每个集成都提供统一语法并强调开源与数据自持——可自托管或使用 Hub 由官方处理 OAuth 刷新与 Webhook用户数据始终属于用户自己。小结Corsair 的仓库工程化亮点可归纳为三点目录边界清晰插件/核心/官网互不混淆、命令链路完整lint → typecheck → build → test 一条龙脚手架自动维护插件注册表、插件质量自动化Greptile 源码级规则 确定性 Gate 零 LLM 的 review loop 三层防护。想要深入了解插件内部实现可以直接阅读任意插件包如 packages/slack、packages/gmail与其对应的 docs/plugins 文档想要参与贡献请以 CONTRIBUTING.md 与.github/PLUGIN_PR_RULES.md为准。【免费下载链接】corsairConnect your users to their apps项目地址: https://gitcode.com/GitHub_Trending/corsa/corsair创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考