前四个阶段已经完成代码审查 Agent 的确定性输入链路。FastAPI 项目骨架；Pydantic 请求与响应模型；环境配置；执行预算；pytest 与 Ruff；LangGraph 依赖准备。仓库允许根目录；规范路径校验；路径穿越防护；符号链接逃逸防护；结构化路径错误。安全 Git 子进程；Git 仓库和 Ref 校验；工作区 Diff；未跟踪文件采集；Unified Diff 解析；与Dif

第八篇已经把 Code Review Agent MVP 的 V1 跑通了。Git diff↓↓↓也就是说，第八篇解决的是“能不能跑起来”的问题。但是只生成报告还不够。哪些问题最严重？哪些问题应该优先修？哪些只是建议？所以第九篇开始给 Agent MVP 增加一个新能力：风险分级。本篇完成了 Code Review Agent MVP 的风险分级能力。新增。为每条 OCR comment 增加se

创建 FastAPI 项目骨架；定义配置系统；定义 Git Diff、AnalysisPackage 和 Finding 等 Pydantic 模型；预留本地代码审查接口；建立 pytest 和 Ruff 检查体系。但是，上一篇的只完成了请求模型校验。只要请求 JSON 格式正确，接口就会直接返回repo_path 是否存在？repo_path 是否为目录？repo_path 是否位于允许访问的目

第七篇已经完成了 Code Review Agent MVP 的设计和项目骨架。为什么要新建独立项目为什么不直接改 OpenCodeReview 源码为什么要拆成 git_tools / ocr_tools / report_tools / agent_graphAgentState 为什么重要这一篇继续往前走：把这个 MVP 真正跑起来。Git 变更检测↓↓解析结构化结果↓生成 Markdown

前面几篇文章中，从不同角度学习了 Open Code Review 的核心流程。第一篇从使用者角度跑通了最小 Demo，观察到了ocr reviewfile_readfile_findfile_read 用来读取文件；code_search 用来搜索代码；code_comment 用来生成评论。第二篇分析了ocr review命令入口，知道了命令会从main.goGit diff 决定本次审查哪些

前面六篇已经把 OpenCodeReview 的核心链路基本走了一遍。跑通最小 Demo，知道ocr review可以审查 Git diff。从源码入口理解ocr review命令如何执行。学习 Git diff，理解 OpenCodeReview 如何确定审查范围。学习，理解自定义规则如何影响审查重点。学习 Agent 工具调用，理解file_readfile_find的作用。学习 JSON 输

前面几篇已经完成了两个阶段：安装 OpenCodeReview运行 ocr review理解 Git Diff理解 rule.json理解 Agent 工具调用理解 JSON 输出和 Markdown 报告Git diff↓Run OCR↓Parse JSON↓↓CriticalWarningSuggestion并且在 JSON 和 Markdown 报告中都展示了风险统计。但是第九篇还有一个明显

上一篇文章中，从源码角度找到了ocr review的命令入口。ocr review程序会从解析命令行参数。ocr review 是从哪里启动的？ocr review 为什么知道我改了哪个文件？Open Code Review 识别到了 src/user.js 的变更。[M] 是什么意思？+7 -1 是怎么来的？为什么它知道要审查这个文件？ocr review --preview 和 git dif

Git diff↓↓JSON 结构化结果↓风险分级↓LangGraph 工作流↓↓Artifact 与 Job SummaryS11 已经可以在 GitHub Actions 中自动运行 Code Review Agent，并将和历史记录上传为 Artifact。但是，这个流程还有一个很明显的问题：开发者必须进入 Actions 页面，再查看 Job Summary 或下载 Artifact，才能