开发与工程 code-reviewpull-request-reviewbring-your-own-keygit-integrationscustom-review-rulestechnical-debt-trackingci-cd-reviewmodel-routing

Kodus

可自选模型与控制成本的 AI 代码审查平台。

FollowAgents 评估 · FARS-2.1
谨慎使用
66/ 100 五分制 3.3 / 5
1 2 3 4 5 6
1信任安全16 / 29 · 2.8/5

README 说明了源码、模型提供商、自带密钥、云端与自托管选择,以及每日匿名心跳的内容和关闭变量;CLI 测试也表明本地 diff 会发送到 /cli/review,并使用团队密钥请求头。安装钩子提供 dry-run、状态和卸载路径,发布工作流的外部写入及 Discord/API 交互也较明确。扣分在于加密和“不用于训练”等敏感数据承诺只有声明,未给出实现证据;权限控制主要作为企业功能描述,发布工作流使用 contents: write 和可绕过主分支保护的 PAT,未展示更细的权限收敛或人工确认。依赖安全仅有固定工具版本、冻结锁文件安装和固定 Action 版本,没有提供漏洞扫描或处置证据。品牌、仓库和联系方式清楚,但给定的发布者身份仍未验证。

2可靠稳定9 / 14 · 3.2/5

CLI 集成测试覆盖帮助、版本、结构化输出、字段投影、认证头、无变更、无效输入、dry-run、钩子安装与卸载;失败状态含稳定错误码和明确消息,因此失败消息证据充分。依赖安装固定 pnpm 版本并使用 frozen lockfile,且产品支持多个模型和 Git 平台,但所给材料没有完整依赖清单或降级逻辑。主要一致性扣分来自 README 要求 yarn setup,而 package.json 的 preinstall 明确拒绝非 pnpm 客户端;此外测试采用模拟 API,不能证明真实服务可用性。

3适用触发15 / 18 · 4.2/5

材料清楚区分云端、自托管、CLI、CI/CD 和本地贡献场景,并覆盖 Community、Teams、Enterprise 及多个 Git/模型提供商,受众与场景描述充分。严格的发布标签正则、staged/branch 等局部范围选项、已移除参数的拒绝测试以及命令 schema 展现了良好的触发精度。扣分在于广泛的平台、模型和环境兼容性多为 README 声明,完整部署细节仅通过外部文档链接指向,且 yarn/pnpm 冲突削弱环境适配指引;能力边界主要由版本表和命令帮助体现,没有系统说明分析盲区或不支持的代码审查情况。

4规范维护12 / 18 · 3.3/5

README 提供多语言入口、使用方式、功能、版本层级、monorepo 树和资源导航,信息架构成熟。命令示例、CLI 帮助测试、结构化 schema 以及严格的 selfhosted 语义化标签和自动 changelog 流程支持较强的使用与版本约定。扣分在于安装说明与实际 pnpm 强制策略矛盾;旧 business-rules-validation 名称需要迁移,显示命名曾变化;没有独立 FAQ,已知限制主要是套餐上限而非技术限制。license.md 清楚描述 AGPL/商业双许可证,但根 package.json 标为 UNLICENSED、输入元数据为 NOASSERTION,且材料未包含被引用的企业许可证正文,导致许可证状态不够一致。社区、联系入口和发布机器人表明存在维护渠道,但没有明确列出经验证的责任人或维护承诺。

5有效结果10 / 13 · 3.8/5

CLI 支持 JSON、Markdown、agent envelope、字段投影、安静与详细模式,并返回文件、行号、严重性和建议等可操作信息;这些由集成测试和模拟响应结构具体支持,因此输出可用性充分。上下文审查、自然语言规则、问题跟踪和成本控制可能带来明显增量价值,但真实审查质量示例主要是产品陈述,测试响应也是固定 mock,不能静态证明实际增益。BYOK、令牌用量和明确套餐价格支持成本规划,但“无隐藏加价”和可预测成本缺少实现或账单证据,因此未给满分。

6证据核验4 / 8 · 2.5/5

部分核心 CLI 声明可追溯到测试、mock 请求记录、脚本和工作流,例如 diff 上传、认证头、输出格式、命令边界、钩子生命周期和发布触发条件;README、package 脚本与测试之间也存在一定交叉佐证。扣分在于隐私、安全、模型兼容、审查效果、SOC 2 和成本等重要产品声明缺少对应实现、策略或独立材料,且 README 常将营销性结论直接陈述为事实。固定 mock 数据只能验证接口契约,不能佐证模型结果或真实服务行为,事实、主张与推断的区分仍不足。

证据充分度: 评估于 2026年8月14日 审查版本 bca1db9228f9
上游仓库在本次评估后已有新提交;当前评分仍对应所示审查版本,可能尚未覆盖最新改动。
使用前请注意
  • README 的 yarn setup 与 package.json 强制 [email protected] 明显冲突;安装前应以实际脚本和锁文件要求为准。
  • 本地代码 diff 会发送到配置的 Kodus API;在处理专有代码前,应核实实际端点、数据保留、模型提供商路由和 BYOK 密钥存储方式。
  • 加密、不用于训练、匿名遥测和 SOC 2 均未由所给实现或合规材料证实。
  • 发布工作流使用具有写权限且可绕过主分支保护的 RELEASE_BOT_TOKEN;应审查其作用域、环境保护和轮换措施。
  • 许可证信号不一致:license.md 声明双许可证,package.json 标为 UNLICENSED,元数据为 NOASSERTION,且未提供企业许可证正文。
  • 测试主要验证 CLI 与模拟服务器的契约,不能视为真实模型审查质量、服务可用性或安全性的独立证明。
查看完整评分方法 →

这个 Agent 能做什么,适合哪些场景?

Kodus 是面向拉取请求、终端和 CI/CD 流程的 AI 代码审查系统,核心审查角色名为 Kody。它能连接 GitHub、GitLab、Bitbucket、Azure Repos 与 Forgejo,并在拉取请求中按严重程度标记风险、提出具体修改建议。仓库采用 monorepo:包含 NestJS API、Next.js 管理界面、审查与队列 worker、Git webhook 服务,以及 kodus-flow 和 kodus-common 两个共享包。团队可以用自然语言编写 Kody Rules,并将规则应用到组织、仓库、路径或特定审查范围。产品提供 Kodus Cloud、自托管部署和 CLI 三种使用边界,同时支持自带 OpenAI、Anthropic、Gemini、Vertex AI、Novita 或 OpenAI 兼容端点的凭据。

GitHub、GitLab、Azure Repos、Bitbucket 或 Forgejo 的 webhook 由 apps/webhooks 接收,apps/api 处理身份验证、组织、团队、权限、集成、Kody Rules 与代码审查编排,apps/worker 执行审查、消费队列并运行建议检查和自动化任务。Kody 读取拉取请求的差异及项目上下文,使用所选模型和适用的 Kody Rules 分析代码,在拉取请求中生成按严重程度划分的风险说明与具体修复建议。CLI 可通过 kodus review 审查工作树,通过 kodus review --staged 审查暂存差异,也可针对分支或提交运行;kodus review --prompt-only 可生成仅提示词形式的结果。Cockpit 汇总审查效果、规则健康度、仓库健康度和交付指标,Kody Issues 则记录已关闭拉取请求中尚未实施的建议,并可在后续修复出现时将其解决。

  1. 使用多个 Git 托管平台的工程团队,希望在现有拉取请求流程中自动发现风险并获得可直接执行的修复建议。
  2. 有既定架构、安全、测试或目录规范的平台团队,希望用 Kody Rules 在组织、仓库或路径层面统一审查要求。
  3. 需要控制推理成本的团队,希望自带模型供应商密钥、直接向供应商付费,并通过 Token Usage 查看消耗。
  4. 有数据驻留或运行环境控制要求的组织,希望在自有基础设施中部署 Kodus,并可关闭每日匿名遥测。
  5. 希望在提交前检查代码的开发者,可从终端审查工作树、暂存差异、分支或提交。
  6. 希望在流水线中加入自动代码检查的 DevOps 团队,可将 Kodus CLI 用于 CI/CD。

这个 Agent 有哪些优点和局限?

优点
  • 支持 OpenAI、Anthropic、Gemini、Vertex AI、Novita 和任意 OpenAI 兼容端点,可按团队需要选择模型。
  • 支持 BYOK,模型费用直接支付给供应商;README 明确表示不对 LLM 成本加价,并提供 Token Usage 追踪。
  • 同时覆盖拉取请求、终端和 CI/CD,并原生连接 GitHub、GitLab、Bitbucket、Azure Repos 与 Forgejo。
  • Kody Rules 可按组织、仓库、路径或审查范围应用,比单一的全局提示词更便于落实工程规范。
  • 可使用云服务或自托管,并声明代码不会用于训练、传输和静态数据均加密。
  • Kody Issues 能持续跟踪已关闭拉取请求中未采纳的建议,而不只生成一次性评论。
局限
  • 自带密钥模式要求团队自行开通、保管并支付模型供应商账户,审查可用性和费用也会受外部模型端点影响。
  • 本地快速开始只给出 git clone、cd 和 yarn setup;Node.js/Yarn 版本、CLI 安装命令及首次启动命令未在所给材料中列明。
  • Community 版最多只能配置 10 条 Kody Rules 和 3 个活跃插件,且没有优先队列或 Cockpit 工程指标。
  • SSO、RBAC、审计日志、分析和 SOC 2 合规仅列于 Enterprise 版,可能增加受监管团队的采购成本。
  • 自托管实例默认每天发送匿名聚合遥测;不希望发送遥测的管理员必须显式设置 KODUS_TELEMETRY_DISABLED=true。
  • 仓库元数据显示 License 为 NOASSERTION,而 README 徽章标示 AGPLv3;采用前需要核对实际 license.md 条款。

如何安装或部署这个 Agent?

本地贡献环境的已记录步骤为:

git clone https://github.com/kodustech/kodus-ai.git
cd kodus-ai
yarn setup

该流程用于运行包含 API、worker、webhooks、Web 应用和本地基础设施的 monorepo。来源没有给出所需 Node.js/Yarn 版本、基础设施启动命令或 CLI 安装命令;完整本地流程指向 https://docs.kodus.io/how_to_deploy/en/local_quickstart/orchestrator,自托管流程指向 https://docs.kodus.io/how_to_deploy/en/deploy_kodus/generic_vm。使用模型审查前,还需配置 OpenAI、Anthropic、Google Gemini、Vertex AI、Novita 或 OpenAI 兼容端点的供应商凭据。

如何使用这个 Agent?

无需管理基础设施时,可在 https://app.kodus.io/signup 创建 Kodus Cloud 账户,并连接受支持的 Git 平台和模型供应商凭据。CLI 的首个已记录调用是 kodus review,用于审查当前工作树;审查暂存内容可运行 kodus review --staged,仅生成提示词可运行 kodus review --prompt-only。来源还说明 CLI 支持分支和提交,但没有提供对应参数示例。团队可在管理界面中设置 Kody Rules 和模型,然后由 Git webhook 触发拉取请求审查;自托管实例默认每天发送一次仅含聚合计数的匿名心跳,可设置 KODUS_TELEMETRY_DISABLED=true 关闭。

常见问题

模型费用如何计算?
BYOK 模式下,团队直接向所选模型供应商付费,Kodus 声明不增加 LLM 费用倍率。Teams 方案另列为每位开发者每月 10 美元或年付折合 8 美元,并另加 tokens/dev;Enterprise 为定制报价。
是否必须把代码托管给 Kodus?
不是。产品既提供 Kodus Cloud,也提供自托管方式;自托管可控制数据、模型和运行配置,并支持自托管 runner。
支持哪些代码托管平台?
来源明确列出 GitHub、GitLab、Bitbucket 和 Azure Repos 的原生 PR 工作流;webhooks 服务的说明还包括 Forgejo。
自托管会发送遥测吗?
默认每天发送一次匿名心跳,仅包含聚合计数,不包含代码、名称或标识符。设置 KODUS_TELEMETRY_DISABLED=true 可退出。
如果模型供应商不可用会怎样?
来源没有描述重试、故障转移或离线审查行为。由于审查调用所选模型端点,采用前应验证供应商中断时的队列和失败处理方式。

相关 Agents