hodor

Hodor：让 AI Agent 做你的 Code Review 搭档

项目图标

图 1：Hodor 项目 Logo（来源：mr-karan/hodor 仓库）

场景引入：提 PR 后最怕什么？

代码审查（Code Review）是软件开发中保障质量的关键环节，但对开发者而言，它也是最耗时的"苦力活"——reviewer 需要通读代码、理解上下文、找出潜在 bug，再给出清晰的反馈。整个过程重复且枯燥，尤其当 PR 改动涉及跨文件逻辑时，人工审查很容易遗漏跨文件的关联性问题。

Hodor 正是为解决这一痛点而生：它是一个基于 AI Agent 的代码审查工具，能够像经验丰富的 reviewer 一样，理解 PR 改动的全貌，自动分析 bug、安全漏洞和逻辑错误，并输出结构化的审查意见。更重要的是，它支持 GitHub PR、GitLab MR、Gitea/Forgejo PR 以及本地 diff，覆盖了主流代码托管平台。

Hodor 的核心能力在于多步骤推理（Multi-step Reasoning）——它不只是简单地扫描 diff，还会调用工具链（文件读取、grep 搜索、bash 执行等）深入理解代码上下文，从而发现那些"需要跨文件分析才能定位"的隐蔽 bug。

背景与起源

Hodor 由 Karan Narotra（GitHub ID: mr-karan）开发，他是印度金融科技公司 Zerodha 的工程师。Zerodha 是印度最大的折扣券商之一，以技术驱动著称，其技术博客 zerodha.tech 经常输出高质量的技术实践。

Hodor 的诞生源于 Zerodha 内部的实际需求：随着团队规模扩大，代码审查的负担越来越重。传统的静态分析工具（如 ESLint、SonarQube）只能检测规则性错误，无法理解业务逻辑；而通用的大语言模型虽然聪明，但直接拿来审查代码往往输出笼统、缺乏针对性的意见。

为此，Karan 设计了一个专为代码审查优化的 AI Agent 框架：通过精心设计的提示词（Review Instructions）和多工具编排（Read/Grep/Bash/Find），让 Agent 能够像人工 reviewer 一样思考——先理解改了什么，再分析改得对不对。

核心功能：从 Diff 到结构化 Review

支持多平台，覆盖主流场景

Hodor 不绑死平台，目前支持：

平台	支持情况
GitHub PR	✅ 完整支持（含 --post 自动发评论）
GitLab MR	✅ 含自托管 GitLab
Gitea / Forgejo	✅ 开放协议全覆盖
本地 diff	✅ 离线场景可用

使用方式极为简单：

# GitHub PR 审查
npx @mrkaran/hodor https://github.com/owner/repo/pull/123

# 自动发评论到 PR
npx @mrkaran/hodor https://github.com/owner/repo/pull/123 --post

# 指定模型
npx @mrkaran/hodor <PR_URL> --model openai/gpt-5

# 复杂 PR 开启深度推理
npx @mrkaran/hodor <PR_URL> --reasoning-effort high

多工具 Agent 架构

Hodor 的设计哲学是只读工具 + 主动推理。与一些 AI 编程助手不同，Hodor 不会修改代码、不会提交 commit，它的工作完全聚焦于审查。

Agent 依赖 @earendil-works/pi-coding-agent SDK 实现，这是一个基于 Anthropic Model Context Protocol（MCP）的 Agent 运行时，提供了以下只读工具：

ReadTool：读取文件内容（受限于 diff 中的文件）
BashTool：执行 shell 命令（受限环境）
GrepTool：在代码中搜索特定模式
FindTool：按条件查找文件
LsTool：浏览目录结构

通过工具编排，Agent 遵循严格的工作流：

获取 Diff：执行 git diff origin/target...HEAD，仅分析 PR 改动的文件
按文件逐一审查：只在改动范围内分析，不做全库扫描
跨文件关联分析：当检测到某处改动可能影响其他文件时，主动读取相关文件验证

模型无关，支持四大 LLM Provider

Hodor 不绑定特定模型，通过 @earendil-works/pi-ai 库实现模型抽象：

export ANTHROPIC_API_KEY=sk-...      # Anthropic (默认)
export OPENAI_API_KEY=sk-...         # OpenAI
export OPENROUTER_API_KEY=...        # OpenRouter（支持 Kimi K2.6 等国产模型）
export AWS_PROFILE=default          # AWS Bedrock（无需 API Key）

支持的模型命名风格：

anthropic/claude-sonnet-4-5 — 直接用模型名
openai/gpt-5 — OpenAI 系列
bedrock/converse/anthropic.claude-sonnet-4-5-v2 — AWS Bedrock
openrouter/kimi/k2.6 — OpenRouter 路由

内置评估体系

Hodor 在 evals/ 目录下维护了结构化评估案例：

null-dereference.json：空指针解引用检测
safe-refactor.json：安全重构检测

每个案例都包含 PR 描述、预期检测结论和评分标准，确保 Agent 的审查质量可量化。

技术架构：TypeScript + Bun + Pi-Coding-Agent

技术栈概览

层级	技术选型	说明
运行时	Bun 1.3.14	比 Node.js 更快的 JavaScript 运行时
构建工具	tsup	基于 esbuild 的 TypeScript 打包
语言	TypeScript 6	强类型保障
Agent 框架	@earendil-works/pi-coding-agent	工具编排 + Session 管理
LLM 接口	@anthropic-ai/sdk + @earendil-works/pi-ai	模型抽象层
CLI 框架	Commander.js	命令行参数解析
测试框架	Vitest	快速单元测试

目录结构

src/agent.ts 是 Agent 核心，负责 Review 循环与 pi-coding-agent Session 管理；src/cli.ts 是 Commander.js CLI 入口；src/github.ts 和 src/gitlab.ts 分别封装 GitHub 和 GitLab API；src/platform.ts 提供平台抽象层；src/model.ts 处理模型字符串解析与 API Key 解析；src/prompt.ts 构建审查提示词；src/workspace.ts 管理仓库克隆、CI 检测和 PR 分支 checkout；src/review-policy.ts 定义审查策略；src/review-diff.ts 获取并解析 Diff；src/codequality.ts 计算代码质量评分；src/metrics.ts 统计 Token 用量与费用。

Dockerfile 设计亮点

Hodor 的 Dockerfile 采用了多阶段构建（Multi-stage Build）：Base Stage 基于 oven/bun:1.3.14；Install Stage 分别安装 dev 和 prod 依赖，利用 Docker 层缓存；Build Stage 编译 TypeScript 到 JavaScript；Final Stage 基于 bun:1.3.14-slim，安装 git/curl/jq/ripgrep/shellcheck 等工具，最终镜像约 200MB。

使用门槛：极低，但不是零门槛

优点：安装极简

Hodor 最令人惊喜的是零安装体验：

npx @mrkaran/hodor <PR_URL>   # 即开即用

如果你习惯全局安装：

npm install -g @mrkaran/hodor

Docker 用户：

docker run ghcr.io/mr-karan/hodor:latest <PR_URL>

门槛：需要 API Key

Hodor 是一个"API Key 即服务"的工具，它本身免费，但需要用户自备 LLM API Key。默认使用 Anthropic Claude，对大多数场景已经足够好用。如果追求更低成本，可以切换到 OpenRouter 路由（支持 Kimi 等国产模型）。

局限与争议

1. 依赖人工复查，不能替代人工

Hodor 的审查质量完全取决于底层 LLM 的能力。对于复杂的业务逻辑、无明确对错的架构决策，AI 的建议只能作为参考。Zerodha 团队也明确表示，Hodor 是辅助工具，不是替代人工 reviewer。

2. 无 Web UI，调试困难

纯 CLI 设计意味着如果 Agent 跑偏，用户只能通过 --verbose 模式观察 Agent 的思考过程，对非技术用户不够友好。

3. 无 License：法律风险

目前 Hodor 仓库没有明确的开源许可证（License: None），这意味着法律上不能自由使用、修改和分发。这是一个重要的风险点，建议社区推动作者补充 License（如 MIT 或 Apache 2.0）。

4. Agent 可靠性

AI Agent 在复杂场景下可能出现工具调用失败、分支判断错误等问题。Hodor 通过 review-recovery.ts 实现了基本的失败恢复机制，但在极端场景下仍可能需要人工干预。

行业意义：AI Code Review 的轻量化实践

Hodor 代表了 AI 代码审查工具的一种新范式：不是追求"全自动"替代人工，而是做一个可靠的 AI pair programmer，在人工审查之前做一轮"初筛"。

从增长曲线看，Hodor 虽然 stars 数量不大（106），但其技术架构清晰、工具链完整，且背靠 Zerodha 这样有真实需求的团队，后续迭代值得期待。

在 AI 代码审查赛道，Hodor 的差异化在于：

Agent 原生设计：不是 LLM + 规则引擎的简单叠加，而是真正的多步骤推理 Agent
平台无关：GitHub/GitLab/Gitea 全覆盖，不绑定生态
本地 diff 支持：离线场景也能用，适合安全敏感环境

快速上手

# 1. 安装（零配置）
npx @mrkaran/hodor https://github.com/owner/repo/pull/123

# 2. 配置 API Key（推荐 OpenRouter 性价比方案）
export OPENROUTER_API_KEY=sk-...

# 3. 自动发评论到 PR
npx @mrkaran/hodor <PR_URL> --post

# 4. Docker 方式（CI 环境推荐）
docker run ghcr.io/mr-karan/hodor:latest <PR_URL>

本文基于 GitHub 仓库 mr-karan/hodor 分析生成，仓库由 Zerodha 工程师维护，当前版本 v0.7.2。