AI Agent 写完代码谁来审？crt 把人类反馈放回终端循环
AI 编程 Agent 可以很快生成一批提交，但“能写出来”不等于“值得合并”。真正耗时的往往是审查：人在一个窗口看 diff，在另一个聊天窗口描述问题，Agent 再猜测你指的是哪一行。Rust 工具 crt 选择了更直接的路径：把代码审查放回终端，并通过 MCP 让 Agent 读取人类留下的、带上下文的评论。
它解决的不是自动审查，而是反馈断裂
crt 的定位很明确：它既可以让人审查 Agent 写的代码，也可以让 Agent 审查代码；但它不是替你做决定的“自动批准器”。项目 README 将核心流程概括为：先让 Agent 编写并提交代码，再用 crt 查看指定基准之后的改动，人在具体代码行上评论，Agent 通过 MCP 获取评论并修复。
这和把一整段 diff 粘贴进聊天框不同。评论直接附着在代码行或选定范围上，Agent 能得到原始代码、附近上下文和评论内容，减少“文件名对了但位置错了”的往返沟通。审查者也可以先批准已经看过的文件，只把注意力留给真正需要修改的部分。
最小工作流：从提交到迭代修复
crt 以 Git 引用作为审查边界。假设 Agent 已经完成三个提交，可以这样启动：
crt HEAD~3
也可以指定分支，或从仓库根提交开始查看：
crt main # 审查 main..HEAD crt --root # 从第一个提交开始 crt main --reset # 重置该分支的审查状态
启动后会进入双栏 TUI：左侧是变更文件，右侧是 diff。[ 和 ] 在代码块之间跳转，Ctrl-n / Ctrl-p 切换文件；按 a 可以批准当前文件，按 c 或空格在行上添加评论，需要连续选区时使用 V。
这套交互的关键不是快捷键，而是“批准状态”和“评论状态”都属于审查会话。文件没有变化时，已经批准的内容不会因为 Agent 后续改写历史就要求你从头再看。
为什么 rebase 后评论不会失效
很多审查工具把评论绑定到行号或某个 commit。一旦 Agent amend、squash 或 rebase，行号移动，评论就可能飘走。crt 保存评论所覆盖的确切代码以及周围上下文，再根据内容重新定位：找到原位置就保持不变，移动到别处就跟着代码走，只有完全找不到时才标记为 orphaned。
批准也不是简单记录“文件名已看过”。crt 会保存文件 diff 的哈希；历史被重写后，只有实际发生变化的文件才重新进入待审列表。这很适合 Agent 高频提交、人工低频确认的工作方式。
让 Agent 通过 MCP 接入
构建二进制并放到 PATH 后，可以把 crt 作为 MCP Server 接入客户端：
{
"mcpServers": {
"crt": {
"command": "/path/to/crt",
"args": ["mcp-server"],
"env": {
"CRT_SERVER_HOST": "127.0.0.1",
"CRT_SERVER_PORT": "25175"
}
}
}
}
Agent 加入审查后，先调用 list_review_sessions 和 select_review_session 找到当前会话，再用 list_review_comments、get_comment_detail 读取具体意见。它可以配合 get_file_diff、search_codebase 和 find_definition 分析影响范围，完成修改后调用 resolve_comment。
这种设计把“人指出问题”和“Agent 负责修复”分成两个清晰阶段。人不需要写一份长提示词解释上下文，Agent 也不必猜测“这里”究竟对应 diff 的哪一块。
安装与边界
当前项目仍处于早期开发阶段，接口和存储格式可能变化。源码构建方式很朴素：
cargo build --release cp target/release/crt ~/.local/bin/crt
审查状态保存在仓库根目录的 .crt/reviews.db，建议把 .crt/ 加入 .gitignore。如果 Agent 在另一个 git worktree 中工作，也可以继续使用同一审查状态，因为状态按 merge base 和分支关联，而不是简单按目录关联。
需要注意的是，README 中提到的“source file review markers”目前仍未实现；因此不要把它当成已经可用的第三种接入方式。crt 更适合这样一个明确场景：代码可以由 Agent 快速产出，但合并前仍需要人类对关键行为负责。
结语：把审查意见变成 Agent 能执行的工件
AI 编程的瓶颈正在从“写不出代码”转向“无法稳定确认代码是否正确”。crt 没有试图用另一个模型替人类批准，而是把批准、评论、上下文和修复状态组织成一个可持续的审查会话。
如果你的团队已经使用 Claude Code、Codex 或其他能接入 MCP 的 Agent，最值得尝试的不是一次性审查整个仓库，而是从一个小分支开始：让 Agent 按原子提交工作，人用 crt 标记少量真实问题，再观察它能否准确读取、修复并完成闭环。