Argot 仓库风格审查器
从 Git 历史学习隐性规范，发现新代码与仓库惯例的偏离。
- Star 数
- ★ 48
- 最近更新
- 14 天前
- License
- MIT
- 主语言
- Rust
- FA 评分
- 93/100 · 表现优秀
30 秒速览
- 可在哪里用
- 通用 · 跨平台Claude Code
- 开始前需要
- 典型场景
- 维护者审查 AI 生成的拉取请求，希望发现代码虽然可编译，却使用了仓库从未采用的依赖、调用方式或表达习惯。
- 主要局限
- 需要质量合适且足够深入的 Git 历史；浅克隆、生成代码、供应商代码或不适合的历史可能无法形成有用模型。
- 源码审查
- 93/100 · 表现优秀
这个 Agent 能做什么，适合哪些场景？
Argot 是一个 MIT 许可的 Rust 静态二进制工具，依据仓库自身的 Git 历史建立统计基线，再审查指定变更集。它通过 CLI 提供 audit、init、check 和 status 等命令，也可接入技能工作流、只读 MCP 工具、Claude Code 插件、pre-commit 与 GitHub Actions。检测范围包括陌生依赖与调用、罕见代码模式、重复函数、模块错放、反向分层依赖、测试削弱以及规则篡改。每项发现都附带仓库证据，结果定位为人工审查提示，而非缺陷证明或正确性判定。分析、嵌入模型推理和拟合均可在本地完成，不需要账户或云服务，但有效性依赖足够且适合分析的历史记录。
首次评估可在 Git 仓库中运行 argot audit：它会在临时 worktree 中拟合历史基线，并检查从基线到 HEAD 保留下来的净差异，不修改当前工作树。正式采用时，argot init 生成 argot.toml 和 .argot/ 拟合快照，团队审阅并提交这些文件后，再用 argot check 对目标变更集评分；argot status 会在已接受的源码、函数或目录布局发生实质变化时建议刷新快照。内置规则会产生 voice、semantic、architecture、integrity 和 governance 类发现；团队还可以在 .argot/rules/ 下用 TOML 清单和沙箱化 Rhai 脚本添加规则。CLI 提供完整检查，MCP 提供只读上下文、代码块或完整变更集工具，pre-commit 可检查已暂存文件，GitHub Action 可检查配置的引用或范围。Claude Code 插件的可选写入前钩子只检查 Write、Edit 或 MultiEdit 是否引入陌生 import，并且只提示、不阻断。
- 维护者审查 AI 生成的拉取请求，希望发现代码虽然可编译，却使用了仓库从未采用的依赖、调用方式或表达习惯。
- 大型仓库团队准备合并新函数时，用
redundant和misplaced检查是否重复已有实现，或把逻辑放进了不合适的模块区域。 - 架构负责人需要识别新内部 import 是否逆转了仓库历史形成的层级方向。
- 测试负责人审查生产代码变更时，希望发现测试被删除、禁用、掏空，或断言被移除、恒真化和放宽。
- 希望在开发机与 CI 之间共享同一学习基线的团队，可提交
argot.toml与.argot/快照，并在后续检查中复用。 - 需要为特定仓库补充治理规则的团队，可使用 TOML 与沙箱化 Rhai 脚本定义规则，并检测锁定规则是否被削弱。
如何安装或部署这个 Agent？
macOS 或 Linux：curl --proto '=https' --tlsv1.2 -LsSf https://github.com/get-tmonier/argot/releases/latest/download/argot-installer.sh | sh。Windows：powershell -c "irm https://github.com/get-tmonier/argot/releases/latest/download/argot-installer.ps1 | iex"。也可通过 npm 安装：npm install -g @tmonier/argot。发布版测试目标为 macOS arm64/x64、Linux x64/arm64 和 Windows x64。无需账户或 API 凭据；分析可完全离线运行。首次使用需要进入一个具有可用 Git 历史且包含受支持源码的仓库。
如何使用这个 Agent？
快速试用：cd your-repository，然后运行 argot audit。若结果有参考价值，运行 argot init 和 argot check；审阅并提交生成的 argot.toml 与 .argot/ 快照，并先将这次快照变更合入未来 PR 的目标分支，再单独添加 CI 工作流。CI 仅读取基础分支中的快照，不执行拟合。后续可用 argot status 判断是否需要在本地重新拟合并提交；需要禁止网络访问时设置 ARGOT_OFFLINE=1，分析能力不会因此减少。
这个 Agent 有哪些优点和局限？
- 基线来自目标仓库的真实历史，而不是通用风格规则或第二个生成式模型，并为每项发现提供仓库证据。
- 核心分析完全在本地运行，嵌入模型编译进二进制；无需账户、云服务或上传源码，也没有默认遥测。
- 一个工具覆盖代码习惯、语义重复、模块放置、架构分层、测试完整性和规则治理，并支持仓库自定义 Rhai 规则。
- 提供 CLI、MCP、Claude Code、pre-commit 和 GitHub Actions 等多种运行路径，可让本地工具与 CI 读取同一已提交快照。
- 公开了各检测器的命中率、语料范围和噪声数据，并明确区分不同检测任务的分母与限制。
- 需要质量合适且足够深入的 Git 历史；浅克隆、生成代码、供应商代码或不适合的历史可能无法形成有用模型。
- 初次采用需要本地拟合、审阅并提交通常为数 MB 到数十 MB 的
.argot/快照，而且快照 PR 必须先于 CI 工作流 PR 合并。 - 结果是概率性审查提示，不能证明代码有错；完全由熟悉词汇写成的错误、被文本掩盖的问题或选定范围外的代码尤其可能漏检。
- 不同入口覆盖范围不一致：Claude Code 写入前钩子仅检查陌生 import，MCP 依赖客户端主动选择工具，GitHub Action 默认也不会因命中而失败。
- 公开测量是按检测器划分的结果，尚无产品整体准确率、组合简报效果或普通仓库运行时间的公开测量承诺。
- 只提供 12 种语言适配器和五个经过测试的发布目标，其他语言与平台没有得到来源材料的支持。
这个 Agent 与同类方案有什么区别？
类型检查器主要回答代码能否通过类型约束，而 Argot 关注变更是否符合该仓库历史形成的代码语言、布局和依赖方向。与把代码交给第二个 LLM 评判不同，它使用本地统计、图结构、脚本和嵌入证据生成提示，不由生成式或观点形成模型决定结论；相应地，它也不是通用正确性验证器。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| Argot 仓库风格审查器 当前 | 93 · 表现优秀 | ★ 48 | 14 天前 | Rust | Claude Code |
| Gortex 代码智能引擎 | 78 · 表现良好 | ★ 1.6k | 7 天前 | Go | Codex · Claude Code · OpenAI API · Claude API |
| Aura 代码变更审计 | 70 · 存在缺口 | ★ 47 | 5 天前 | Rust | Codex · Claude Code |
| Happier | 82 · 表现良好 | ★ 1.7k | 今天 | TypeScript | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示分析默认在本地完成、无遥测或源码上传，分析模型嵌入二进制，并提供 ARGOT_OFFLINE=1；Git 操作移除了网络传输，脚本规则受到 I/O、时间和资源限制，CI 权限也被显式声明。检查结果默认仅供建议，拟合、CI、门禁和更新均需明确配置或调用。依赖审计、校验和、构建来源证明、禁止自有代码使用 unsafe、第三方模型及许可证归属均有具体说明。未给满分的 rollback：临时工作树和可提交快照提供了良好恢复路径，但材料没有完整说明自更新失败或版本回退机制。
工作流覆盖 Linux、macOS ARM64、Windows、正常发现、SARIF、缺失快照、缺失发布资产及校验和错误，并验证具体失败消息，因此失败反馈证据充分。静态二进制、内嵌模型和固定 Rust 工具链降低了可用性风险，但安装与 Action 仍依赖发布下载和外部托管环境。self_consistency 扣分是因为 README 和 SECURITY.md 多处称模型始终编译进二进制，SECURITY.md 又称缺失语义模型可能首次下载，形成未解释的合同矛盾。
材料明确区分 CLI、技能、MCP、Claude Code 插件、pre-commit 和 GitHub Action 的受众、前置条件、覆盖范围与触发方式；还列出十二种语言、五个发布目标和不适用的历史条件。能力边界尤其清楚：它是概率性审查提示而非正确性证明，自动钩子和 CI 默认不阻断，语义工具需要已拟合仓库。现有证据足以支持全部适应性 criterion 满分。
README 具有清晰的入门、功能、运行方式、证据、限制、隐私、贡献和归属结构，安装与两阶段 CI 引导具体；MIT 正文、NOTICE 归属说明、安全联系渠道和单人维护责任都明确。限制文档与支持政策详尽。扣分项是 naming_stability：名称目前一致，但 0.2.x 滚动发布及仅支持最新版不足以证明长期稳定；examples_and_faq 提供命令和规则示例但没有可见 FAQ；versioning_changelog 仅引用发布记录，所给材料未包含实际 changelog 内容。
输出可用于终端、JSON、GitHub 注释和 SARIF，工作流还检查 SARIF 必填字段、非阻断默认值及机器可读状态。它在传统类型检查之外提供仓库历史驱动的风格、重复、放置、分层、测试完整性和治理信号，边际价值明确，并公开各检测器命中率与噪声率。cost_benefit 扣分是因为项目明确不承诺固定运行时间，拟合快照可能达到数十 MB，且尚未公开普通仓库耗时或组合结果的完整测量。
主要主张关联到批准的 claim manifest、研究证据、固定语料、证明回执和再生成程序；工作流、Cargo 配置、README 与 SECURITY.md 对本地执行、依赖边界、输出契约和平台支持形成多源佐证。材料明确区分作者制作的演示与野外语料、检测器指标与产品整体准确率、发现与缺陷，以及测量结果与尚未测量的事项，因此事实与推断分隔充分。
- README 与 SECURITY.md 对语义模型是否可能首次下载存在矛盾；在依赖离线保证前应核实实际发布版本的行为。
- 安装命令采用 curl|sh 或 irm|iex，并且示例 Action 跟随 main 或 latest；高保障环境应固定版本并在执行前验证发布校验和及来源证明。
- 该工具是概率性审查辅助，不是正确性或安全性证明；浅历史、生成代码、供应商代码、不合适的拟合范围及完全使用熟悉词汇的错误都会降低效果。
- 只有最新版受支持，维护由单人以尽力而为方式承担；采用方应评估升级频率、维护连续性和回退需求。
- 公开指标是按检测器和不同语料计算的，不能合并解释为产品整体准确率或所有仓库上的预期表现。
常见问题
使用 Argot 需要云账户、API 密钥或付费模型吗？
它会把源码或历史记录上传到外部服务吗？
ARGOT_OFFLINE=1 可阻止网络使用。