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。

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。

社区活跃度

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

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

背景与起源

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

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

多工具 Agent 架构

模型无关，支持四大 LLM Provider

内置评估体系

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

技术栈概览

目录结构

Dockerfile 设计亮点

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

优点：安装极简

门槛：需要 API Key

局限与争议

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

2. 无 Web UI，调试困难

3. 无 License：法律风险

4. Agent 可靠性

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

快速上手

社区活跃度

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

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

背景与起源

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

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

多工具 Agent 架构

模型无关，支持四大 LLM Provider

内置评估体系

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

技术栈概览

目录结构

Dockerfile 设计亮点

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

优点：安装极简

门槛：需要 API Key

局限与争议

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

2. 无 Web UI，调试困难

3. 无 License：法律风险

4. Agent 可靠性

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

快速上手