OSS Autopilot
面向开源贡献者的 AI 工作流引擎：自动追踪 PR、提醒维护者反馈、诊断 CI 失败并按贡献历史发现新 issue，让贡献节奏可控。
证据充分：SECURITY.md 详细列出令牌不落盘、execFileSync 数组参数、0600/0700 权限、原子写入、注入围栏 wrapUntrustedContent 及回归语料；CI 明确禁止 agent 使用 mcp__* 通配符，外部效果被 Human-in-the-loop 门控（post/claim 需显式批准，overnight 模式从不 push/post/merge）。扣分点：dependency_security 仅 2 分，因 ci.yml 中 pnpm audit 步骤设为 continue-on-error（即便有注释解释端点下线），静态审计实为弱阻断；data_flow_transparency 2 分，README 提到 oss-widgets.vercel.app 外部端点，与"仅联系 GitHub"的表述存在张力；source_attribution 2 分，作者具名但发布者未经验证，'Ink 第三大贡献者'等身份主张无法在仓库内证实。
CLI 结构化错误输出 { success, data, error, timestamp }、FAQ 故障排查（gh auth、构建失败、PR 不显示）和 CI 对 e2e bundle 缺失的显式门控支持依赖可用性与失败消息。扣分点：self_consistency 仅 2 分——README 内部数字相互矛盾（'2,600+ tests' 与 '3,000+ across 120+ files'；agents 8 个 vs 表格 7 个；SECURITY.md 称 26 条命令而 README 称 35+），静态审查无法调和。
三种部署模型（插件/MCP/CLI）、明确的个人贡献者定位、独立 Limitations 节（仅 GitHub、1000 PR 上限、单人使用）支持受众与边界评分。扣分点：trigger_precision 2 分，agent '由 Claude 根据上下文自动分发'的精确触发条件未在文件中完整展示；environment_fit 2 分，要求 Node>=22、gh CLI、pnpm，首次构建失败需手动 find+rebuild，跨平台自动化适配仅部分可见。
信息架构清晰（monorepo 结构图、命令表、配置表），安装说明完整（三种路径），MIT 许可证文件与声明一致，release-please 自动版本化且 CI 强制 server./package./README 版本一致性，Limitations 节具体坦诚，FAQ 详尽。扣分点：maintenance_responsibility 2 分——单人维护者，虽有安全通告路径与支持版本表，但更新持续性依赖未验证的个人。
输出可用性强：-- 结构化、markdown/badge 导出、结构化报告目录。扣分点：marginal_value 与 cost_benefit 均 2 分——'每个功能来自真实使用'的叙述可信但静态不可验证，npx @latest 默认拉取最新版带来供应链与行为漂移风险，5 分钟日常工作流的实际收益未在证据内证明。
大量引用 issue/PR 编号（#1053、#1372、#1651），独立文档（repo-scores.md、anti-llm-policy.md）解释决策启发式，事实与解释总体区分。扣分点：claim_traceability 2 分——测试数、发布数等聚合指标无仓库内可核对的清单；cross_source_corroboration 2 分——CI 内置了文档/代码一致性守卫（工具数、参考文档同步）但静态审查无法确认其通过；fact_inference_separation 2 分——推广性叙述（'built and used daily'、贡献者排名）与可验证事实混合出现。
- CI 中 pnpm audit 为 continue-on-error，依赖漏洞审计并非硬性门控，使用前应自行运行审计。
- npx @latest 默认拉取最新版本，无版本锁定，存在供应链与行为漂移风险；建议固定版本号。
- README 内部数据不一致（测试数、agent 数、命令数），引用其指标前应自行核对。
- 发布者身份未经企业注册表验证，'Ink 第三大贡献者'等身份主张未经独立证实。
- over-night/无人值守模式会在本地 worktree 准备修改并写入报告，虽声明不 push/post，仍建议首次使用时审查其产物。
这个 Agent 能做什么，适合哪些场景？
OSS Autopilot（GitHub: costajohnt/oss-autopilot）是一个以 Claude Code 插件、MCP 服务器和独立 CLI 三种形态发布的 TypeScript 开源工具，用于规模化管理个人开源贡献。它通过 GitHub Search API 实时拉取你的所有 PR，标记维护者反馈、CI 失败与合并冲突，并按你的贡献历史匹配可参与的新 issue。核心采用 pnpm workspaces 单仓库结构，包含 @oss-autopilot/core、@oss-autopilot/mcp 和 @oss-autopilot/dashboard（Preact + Vite）三个 npm 包。设计上遵循确定性内核 + AI 编排层：PR 状态分类、CI 失败归因等关键逻辑在经过测试的 TypeScript 中实现，由 3,000+ 测试覆盖，不依赖提示词。工具坚持人在环中：任何评论或代码都不会在未经你明确批准的情况下发布到 GitHub。
运行 /oss 执行每日检查时，工具调用 GitHub Search API 实时获取你提交的 PR，并逐个补全 CI 状态、评审决策、合并冲突检测、维护者评论分类与 checklist 进度，不落盘存储 PR 数据。pr-responder 代理为维护者反馈起草回复；pr-health-checker 诊断 CI 失败并按确定性分类法归类（可操作 / fork 限制 / 认证门槛 / 基础设施）；issue-scout 搜索并筛选与你贡献历史匹配的新 issue；repo-evaluator 用 history score 与 health score 两套 1-10 评分评估仓库健康度，并通过反 LLM 政策检测扫描 CONTRIBUTING/CODE_OF_CONDUCT/README，跳过不接受 AI 辅助贡献的项目。/oss-overnight 以无人值守模式在本地 worktree 中准备修复分支并生成晨报，绝不推送、发布或合并。MCP 服务器暴露 30 个工具、6 个资源和 4 个提示词；CLI 所有命令支持 -- 结构化输出（{ success, data, error, timestamp }）。
- 同时在多个上游仓库维护 10 个以上活跃 PR 的独立贡献者，需要一个每日五分钟的巡检流程来跟进 CI 失败和维护者反馈。
- 不使用 Claude Code、但使用 Cursor、Claude Desktop、Codex 或 Windsurf 的开发者，可通过 MCP 服务器接入同一套能力。
- 想在程序或脚本中以结构化 JSON 输出集成 PR 监控与 issue 发现的开发者，可直接调用 @oss-autopilot/core 的 runDaily、runSearch 等函数。
- 希望在自己 GitHub 主页 README 上展示开源贡献统计徽章的贡献者，可使用 stats --badge 和 oss-widgets 提供的 Shields.io 端点。
- 接受 AI 辅助贡献前提下的长期贡献者，可利用 per-repo guidelines、/pr-ready 预推送评审循环来避免给维护者留下粗糙代码。
这个 Agent 有哪些优点和局限？
- 三种部署形态共用同一核心库：Claude Code 插件（8 个专用代理 + 9 个斜杠命令）、MCP 服务器（30 工具/6 资源/4 提示词）和独立 CLI，可随客户端切换而不损失功能。
- 确定性内核 + AI 编排架构：PR 分类、CI 失败归因和状态管理位于经 3,000+ 测试验证的 TypeScript 代码中，输出可复现、不依赖提示词质量。
- 生产级 GitHub API 集成：ETag 缓存、限速退避重试、有界并发池和分页抓取，正确处理跨 fork PR 的 diff 区间、squash 计数与 --head 标志，适合每日运行。
- 严格的人在环中保障：未经明确批准不发布任何内容；草稿中的事实性声明会先与实际 diff 核对；状态文件以 0o600 权限写入并经 Zod 运行时校验。
- 仅支持 GitHub：GitLab、Bitbucket 等其他托管平台明确不受支持。
- GitHub Search API 单查询最多返回 1,000 条结果，PR 超过 1,000 时最旧记录会被截断。
- 面向独立贡献者设计：没有团队看板、共享状态或多用户工作流。
- 最佳体验绑定 Claude Code 插件生态；MCP/CLI 路径虽有同等核心功能，但专用代理需通过工具与命令间接访问。
- 无人值守 overnight 模式只支持 launchd 定时，未文档化 systemd 等其他调度方式。
如何安装或部署这个 Agent？
方式一（推荐）：在 Claude Code 中执行 /plugin marketplace add costajohnt/oss-autopilot，然后 /plugin install oss-autopilot@oss-autopilot，重启 Claude Code 并运行 /setup-oss 完成配置。方式二（MCP 服务器，适用于 Cursor / Claude Desktop / Codex / Windsurf）：先运行 npx @oss-autopilot/core@latest init <你的GitHub用户名> 完成一次性初始化，再在 MCP 客户端配置中加入 {"mcpServers":{"oss-autopilot":{"command":"npx","args":["@oss-autopilot/mcp@latest"]}}}。方式三（独立 CLI）：npx @oss-autopilot/core daily -- 或 npm install -g @oss-autopilot/core。所有方式均需 GitHub 认证（CLI 自动使用 gh auth token；故障时运行 brew install gh && gh auth login）。运行时依赖 Node.js。
如何使用这个 Agent？
每日流程（约 5 分钟）：1) 运行 /oss 查看需要处理的事项；2) 逐项处理关键问题（CI 失败、维护者评论、冲突）；3) 结束。无人值守模式：/oss-overnight 会在本地 worktree 中准备修复分支并把报告写入 ~/.oss-autopilot/reports/，不执行推送、发布或合并；可用 oss-autopilot overnight schedule --install（launchd）定时执行。其他命令：/oss-search 查找 issue、/oss-dashboard 打开交互式看板（也可 npx @oss-autopilot/core dashboard serve，本地 http://localhost:3000）、/oss-guidelines 配置仓库级贡献准则、/pr-ready 预推送评审、/setup-oss 交互配置。配置存放于 ~/.oss-autopilot/state.，关键项包括 githubUsername、maxActivePRs（默认 10，新手建议 3-5）、dormantDays（默认 30）、minStars（默认 50）、excludeRepos/excludeOrgs、boostIssueTypes 等。