Sashiko 是一个很有代表性的 agentic code review 项目。它的目标不是泛泛地让大模型“帮忙看代码”，而是把 Linux Kernel 的补丁审查流程拆成一条可持久化、可恢复、可验证、可度量的流水线：先收集 patch，再解析邮件和 series，再找到合适的 kernel baseline，再用 git worktree 证明补丁能应用，最后让多阶段 LLM review worker 在受控工具箱中查证代码，并输出符合 LKML 习惯的 inline review。

这类系统真正难的地方，不是调用某个模型 API，而是如何把概率模型放进确定性工程系统里。Sashiko 的价值也正在这里：它把“模型可能发现 bug”这个不稳定能力，用数据库状态机、baseline 检测、worktree 沙箱、严格 JSON 校验、只读 git 工具、token 预算、邮件策略和 embargo 机制包起来，让它更接近一个可以长期运行的内核维护辅助系统。

本文基于该项目的 README、设计文档、源码和测试结构进行解析，重点讨论系统架构、核心模块、补丁到 review 的端到端流程、11 阶段审查协议、AI provider/tool calling 抽象，以及这个项目对 agentic engineering 的启发。

适合谁读：从项目解析进入可验证 Agent 工程

这篇文章适合三类读者。

第一类是做代码审查、CI、研发效能和 DevTools 的工程师。Sashiko 把 review 任务拆成 ingestion、baseline、worktree、tool calling、multi-stage reasoning、outbox notification 等多个可观察环节。它提供的不是一个炫技 demo，而是一套可以借鉴到内部 review bot、自动 triage、PR 风险扫描和 release gate 的工程骨架。

第二类是做 Agent 系统工程化的人。很多 agent 项目失败，不是因为模型能力不够，而是因为没有状态机、没有证据链、没有恢复机制、没有工具边界，也没有输出质量控制。Sashiko 的设计价值在于：它把不确定的 LLM 推理压进确定性的执行框架里，让每一步都可以排队、重试、记录、审计和回放。

第三类是关注 Linux kernel、系统软件和开源协作的人。内核补丁审查天然复杂：patch series、邮件线程、MAINTAINERS、子系统树、锁和内存模型、硬件状态机、LKML 礼仪，任何一个环节处理粗糙都会让自动化输出失去可信度。Sashiko 的项目边界足够窄，反而让它更能体现高质量 agent 系统应该如何尊重真实工作流。

因此，本文不会把 Sashiko 当成“某个模型 wrapper”来读，而是把它当成一个可验证 agent 系统样本：输入如何标准化，状态如何落库，工具如何受限，推理如何分阶段，输出如何变成社区可接受的 review。

项目定位：它不是聊天机器人，而是内核补丁审查系统

Sashiko 的 README 把它定义为“agentic Linux kernel code review system”。这句话里的三个限定词都很重要。

第一，它是 Linux kernel 专用。Linux 内核补丁审查不是普通应用代码 review。它涉及 UAPI 兼容性、驱动状态机、DMA、内存屏障、RCU、锁顺序、错误路径、资源生命周期、硬件寄存器访问、子系统维护规则和邮件列表礼仪。一个通用代码助手如果不了解这些上下文，很容易输出看似合理、实则不可用的建议。

第二，它是 patch review 系统。Sashiko 处理的基本对象不是仓库里的某个文件，而是邮件列表、git commit、PR/MR 或 mbox 中提交的 patchset。系统必须理解 cover letter、[PATCH 1/N]、Message-ID、References、To/Cc、baseline、series 顺序、后续 patch 是否修复前面 patch 的中间态问题等信息。

第三，它是 agentic，但不是失控 agent。LLM 能使用工具，但工具被限制为只读 git 查询：grep、show、blame、diff、log、read files、read prompt。模型可以查证上下文，却不能随意改代码。这种设计很适合 review 场景：review 的任务是发现、验证和表达问题，而不是直接修改被审查仓库。

项目当前由 Rust 实现，crate 名称为 sashiko，版本为 0.2.3。它提供 daemon、Web UI/API、CLI、本地 review binary、benchmark 工具和多 provider LLM 接入。源码分布也很清楚：src/main.rs 负责 daemon 总装配，src/reviewer.rs 负责编排 review，src/worker/prompts.rs 执行多阶段 LLM pipeline，src/ai/* 封装模型后端，src/toolbox/* 提供只读代码工具。

与普通 Code Review Bot 的差异：从单轮评论到审查生产线

理解 Sashiko 最直接的方式，是把它和常见的 code review bot 放在一起比较。很多 review bot 的核心流程是：拿到 diff，把 diff 放进 prompt，请模型输出评论。这个路径足够简单，但很难处理 Linux kernel 这类高上下文、高社区约束、高误报成本的场景。

维度	普通 Review Bot	Sashiko
输入对象	通常是 PR diff 或单个 patch	邮件、mbox、commit/range、PR/MR，最终统一成 patchset/thread/message
上下文基础	主要依赖当前 diff 和 prompt	先解析 series，再选择 baseline，并在 worktree 中应用完整补丁序列
模型调用	常见为单轮或少量多轮问答	Phase 0 + Stage 1-11，多阶段发散、去重、仲裁、验证、成文
工具权限	可能没有工具，或工具边界较宽	只读 git 工具箱，允许查证，不允许修改被审查仓库
状态管理	经常依赖一次性任务状态	libSQL 持久化 messages、patchsets、reviews、findings、tool usages、outbox
输出形态	面向平台评论区	面向 LKML inline reply、Patchwork check、Web/API/CLI 查询
质量控制	多靠 prompt 约束	schema 校验、错误重试、false positive 过滤、series final state 检查

这张表背后的核心差异是：普通 bot 更像“模型评论器”，Sashiko 更像“审查生产线”。前者强调快速接入，后者强调可恢复、可审计、可约束和可运营。对于真实研发组织而言，后者虽然复杂得多，但也更接近能够长期运行的系统。

总体架构：确定性工程外壳包住概率模型内核

Sashiko 的总体架构可以理解为四层。

入口层负责把不同来源统一成内部事件。邮件列表通过 NNTP/lore 进入，CLI 和 HTTP API 可以提交 mbox、commit 或 range，Forge webhook 可以接 GitHub PR 和 GitLab MR。无论来源如何，最终都变成 Event：ArticleFetched、PatchSubmitted、RawMboxSubmitted 或 IngestionFailed。

解析与持久化层负责把 raw event 变成数据库对象。Parser dispatcher 调用 parse_email 或使用预解析的 patch metadata，DB worker 再把 message、thread、patch、patchset、subsystem、baseline、filter、MR metadata 等信息写入 libSQL。这里的关键原则是：先落库，再排队。即使进程崩溃，状态也能从数据库恢复。

审查层由 Reviewer service 和 AI Worker 组成。Reviewer 轮询 Pending patchset，解析 baseline 候选，创建 git worktree，尝试应用完整 series，然后为每个有效 patch 构造 review 输入。AI Worker 再进行 Phase 0 prompt 选择、stage planning、Stage 1-11 多阶段审查和工具调用。

输出层负责把 review 结果变成用户可消费的形式。结果会写入 reviews、findings、ai_interactions 和 tool_usages，同时根据 email policy 进入 email_outbox，或根据 Patchwork 策略进入 patchwork_outbox。Web UI/API 和 CLI 都可以查询这些状态。

这套架构的本质，是用确定性系统约束概率模型：数据库记录状态，git worktree 验证补丁，schema 校验模型输出，工具箱限制模型行为，review pipeline 分离“发现问题”和“确认问题”。这样设计后，LLM 不再是一个孤立聊天窗口，而是流水线中的一个受控分析组件。

三类入口：邮件列表、HTTP/API/CLI、Forge Webhook

Sashiko 的入口设计体现了它对 Linux 开发工作流的理解。Linux kernel 的主战场仍然是邮件列表，但现代协作也会遇到本地开发、自动化 CI、GitHub PR 和 GitLab MR。因此项目没有把入口绑定在单一协议上。

邮件列表入口由 Ingestor 和 NntpClient 负责。live mode 会轮询 nntp.lore.kernel.org；bootstrap/offline mode 可以从 lore git archive 拉取历史对象。这使它既能长期跟踪列表，也能批量导入历史邮件用于测试和基准评估。

API/CLI 入口集中在 src/api.rs 和 src/bin/sashiko-cli.rs。API 提供 /api/submit、/api/patchsets、/api/review、/api/patchset/rerun、/api/patchset/cancel 等端点；CLI 则提供 submit、status、list、show、rerun、cancel 和 local 命令。

Forge webhook 入口由 src/forge.rs 抽象。ForgeProvider trait 定义 validate_event 和 parse_payload，当前内置 GitHub 和 GitLab provider。webhook 收到 PR/MR 事件后，提取 repo URL、PR/MR number、title、head/base ref，再交给 FetchAgent 抽取 patch。README 也明确标注 Forge integration 仍是 experimental 和 unsupported，这一点在生产使用中要特别注意。

三类入口的共同点是：它们都不直接调用模型，而是先把输入转化为统一事件，再进入同一套解析、持久化和 review 流水线。这避免了“每种入口都实现一遍 review 逻辑”的重复，也让系统状态可追踪。

事件与状态流：从 raw event 到 pending patchset

在 src/events.rs 中，Sashiko 定义了四类核心事件：ArticleFetched、PatchSubmitted、RawMboxSubmitted 和 IngestionFailed。这一步很关键，因为事件是入口层和内部处理层之间的协议边界。

src/main.rs 中的 parser dispatcher 消费 raw event，再把结果发给 ParsedArticle channel。对于 ArticleFetched，它会把 raw 邮件交给 patch::parse_email；对于 PatchSubmitted，它直接构造 PatchsetMetadata 和 Patch；对于 RawMboxSubmitted，它先把 mbox 切成多封邮件，再逐封解析。

DB worker 是第二个收敛点。它批量消费 ParsedArticle，将邮件线程、message、patch、patchset、recipients、mailing lists、subsystems、baseline 和 filters 写入数据库。这里还有几个很实际的逻辑：根据 To/Cc 和 touched paths 识别 subsystem，根据 email policy 计算 embargo，合并同一 thread 中的 series，并在收到足够 patch parts 后把 patchset 从 Incomplete 推到 Pending。

这种事件流的好处是吞吐和恢复。Parser 可以并发，DB worker 可以批量，Reviewer 不需要关心 patch 来自哪里，只要轮询 Pending patchset 即可。系统不依赖外部消息队列，而是用 tokio mpsc 和数据库状态协作：mpsc 负责运行时吞吐，libSQL 负责崩溃后的事实来源。

Baseline 与 Git Worktree：先证明补丁能应用，再谈审查

Linux kernel patch review 有一个容易被低估的问题：补丁到底应该应用在哪个树上？同一组变更可能依赖 bpf-next、net-next、drm-misc、linux-next 或主线中的不同状态。如果 baseline 选错，模型看到的上下文就是错的，review 结果自然会偏离真实开发状态。

Sashiko 用 src/baseline.rs 中的 BaselineRegistry 解决这个问题。它会从 diff 中提取 touched files，再结合 MAINTAINERS、custom remotes、subject/body 里的 tree 线索和 subsystem 特例生成候选 baseline。对于 linux-mm 这类子系统，它还会有特殊优先级处理。

Reviewer 会先检查 patchset 是否已有 forced baseline；如果有，就优先使用数据库里的 baseline commit。否则，它调用 resolve_candidates 生成候选列表，然后在 prepare_baseline_worktree 中逐个尝试。每个候选都会创建一个 git worktree，并尝试应用完整 patch series。只有整个 series 能应用成功，这个 baseline 才进入后续 review。

worktree 模型由 src/git_ops.rs 封装。GitWorktree::new 使用 detached checkout，并通过 reset --hard 固定到目标 commit。补丁应用使用 git am，失败时执行 abort。并发 worktree 操作通过全局 async mutex 做保护，避免多个 review 同时 add/remove/prune worktree 时互相踩踏。review 结束后 worktree 会显式 remove，启动时还会清理 stale worktree。

这一层是 Sashiko 的工程底座。它先用确定性 git 机制证明“补丁在这个基线上成立”，再让模型审查。没有这一步，LLM 很容易在错误上下文里批评并不存在的问题，或者漏掉 baseline 差异导致的真实风险。

AI Provider 抽象：把 Gemini、Claude、OpenAI-compatible 和 CLI 后端统一起来

Sashiko 的模型接入层集中在 src/ai/*。核心接口是 AiProvider trait，它统一暴露 generate_content、estimate_tokens、get_capabilities 和可选 cache_stats。调用方只依赖 AiRequest、AiResponse、AiMessage、AiTool、ToolCall、AiUsage 这些统一结构。

这种抽象让 Sashiko 可以同时支持多种后端：Gemini、Claude API、OpenAI-compatible、AWS Bedrock、Vertex AI，以及 Claude CLI、Codex CLI、Copilot CLI、Kiro CLI、Devin CLI 等本地/订阅式后端。不同 provider 的 wire format 可以完全不同，但 review pipeline 不需要知道这些差异。

Provider factory 还有一个重要细节：create_provider_cached 可以给 provider 包一层 CachingAiProvider，把响应缓存放在主 database 同目录的 response_cache.db。对于多阶段审查和 benchmark 迭代来说，这可以显著降低重复请求成本。

错误分类也被统一成 AiErrorClass：Fatal、RateLimit 和 Transient。SessionRunner 可以对 rate limit 和 transient error 做 sleep + retry；对某些 provider 的 recitation/safety block，也可以通过 session hook 转换成带反馈的重试。这是把外部模型服务纳入工程系统时必须做的抽象，否则每个 provider 的失败都会泄漏到业务层。

SessionRunner 与 ToolBox：让模型查证代码，而不是凭记忆猜

Sashiko 的 LLM 交互不是一次 prompt、一次 answer。src/ai/session.rs 定义了 LlmSession 和 SessionRunner。一个 session 负责提供 system prompt、initial prompt、tool declarations、temperature、response format、validation hook 和 provider error hook；SessionRunner 则驱动多轮循环。

循环逻辑大致是：构造 AiRequest 调用 provider；如果返回 tool_calls，就调用 session 的 call_tools；工具结果作为 AiRole::Tool message 放回 history；继续下一轮；如果没有 tool call，则进入 validate。如果输出格式不合格，validation 会返回反馈，Runner 追加反馈后重试。

工具箱在 src/toolbox/mod.rs 和 src/toolbox/framework.rs。ToolRegistry 负责声明工具、标准化参数、动态 dispatch；ToolBox 把 registry 和 SashikoToolContext 绑定起来。context 包含 worktree path、prompt path、active patch files、virtual HEAD 和工具缓存。

当前工具主要是只读 git 工具：git_read_files、git_blame、git_diff、git_show、git_log、git_ls、git_grep、git_find_files，以及用于读取 review prompt 的 read_prompt。这套工具让模型可以在审查过程中查调用链、看历史、读定义、找符号，而不是凭训练记忆臆测内核源码。

这里的设计很克制：工具足够强，能提高审查证据质量；工具又足够窄，不允许模型修改仓库。对 review 系统来说，这是合适的能力边界。

11 阶段审查流水线：先发散找问题，再收敛成证据

Sashiko 最有价值的设计，是把内核审查拆成 11 个阶段。Stage 1-7 类似一组专科 reviewer 并行会诊；Stage 8-11 则是 lead reviewer 做去重、仲裁、验证和最终表达。

Stage 1 分析 commit 主目标，关注架构思想、UAPI、兼容性和概念层面的错误。Stage 2 核对实现是否真的完成 commit message 里的承诺，有没有漏改驱动、漏处理 corner case 或引入未说明副作用。Stage 3 追踪执行流，检查错误路径、返回值、off-by-one、NULL dereference 等逻辑问题。

Stage 4 关注资源管理，分析内存泄漏、UAF、double free、对象生命周期、队列和 workqueue。Stage 5 关注锁和同步，包括死锁、锁顺序、RCU 规则、IRQ 上下文和线程安全。Stage 6 是安全审计，关注 buffer overflow、越界读写、TOCTOU、信息泄漏。Stage 7 是硬件工程师视角，专门审查 driver/hardware 代码中的寄存器访问、DMA mapping、memory barrier、时序和电源/时钟状态机。

前 7 个阶段产出两类对象：concerns 和 dismissed_concerns。这很重要。系统不仅记录“怀疑有什么问题”，也记录“检查过但排除的问题”。后续 Stage 9 可以把二者放在一起做冲突仲裁，避免一个阶段报问题、另一个阶段已经证明不是问题。

Stage 8 做去重与合并，把重复 root cause、重复代码位置、重复 failure mode 合成一个更完整 concern，同时保留精确 locations。Stage 9 做 concern 与 dismissed concern 的冲突解决，明确要求二者都不可信，必须回到代码证据判断哪边成立。Stage 10 做最终验证和 severity 估计，过滤 false positive，检查后续 patch 是否已经修复中间态问题，并区分 pre-existing 与 newly introduced。Stage 11 将 findings 转成 LKML-friendly inline email review。

这套 pipeline 的核心是“先提高召回，再控制误报”。前段宁可多怀疑，后段用证据收敛。相比让模型一次性输出最终 review，这种结构更像工程化的审查协议。

数据模型：patchset、review、finding 与 interaction 的主链路

Sashiko 的数据模型围绕几个核心实体展开。

threads 和 messages 保存邮件线程和邮件本体；patchsets 表示一组逻辑相关的 patch series；patches 保存 series 中的单个 patch；baselines 保存 repo、branch 和 last known commit；reviews 保存对 patchset 或单 patch 的审查结果；findings 保存结构化问题，包括 severity、problem、suggestion、preexisting 和 locations。

AI 相关审计信息也被持久化。ai_interactions 记录 provider、model、input_context、output_raw、tokens_in、tokens_out、tokens_cached；tool_usages 记录 review_id、tool_name、arguments、output_length 等。换句话说，Sashiko 不只是保存最终文本，而是尽量保存模型运行过程的可追踪证据。

子系统关系通过多对多表表达：messages_subsystems、threads_subsystems、patches_subsystems、patchsets_subsystems。recipients 也被规范化为 people 和 messages_recipients。输出侧则有 email_outbox 和 patchwork_outbox。

这个 schema 说明 Sashiko 不是“跑一次模型然后打印结果”的脚本，而是一个长期运行的 review tracking 系统。它需要回答：这个 patchset 当前是什么状态？对应哪个 baseline？哪些 patch 已 review？哪些 finding 是新增问题？模型用了多少 token？工具查了什么？邮件是否已经发出？这些问题都必须有持久化答案。

CLI 与本地审查：daemon 优先，本地 subprocess 兜底

sashiko-cli 是项目面向开发者的日常入口。它可以提交 patch、查看状态、列出 patchsets、展示 review、请求 rerun、取消 pending review，也可以执行本地 review。

最值得注意的是 sashiko-cli local 的双路径设计。默认情况下，它会先探测 daemon 是否可用。如果 daemon 正在运行，它会把本地 commit/range 通过 /api/submit 交给服务端统一排队审查。这样本地开发者和长期 daemon 共享同一套状态、Web UI、数据库和通知机制。

如果 daemon 不可用，或者用户显式使用 --force-local，CLI 会进入本地 subprocess 路径：构造 ReviewInput JSON，通过 stdin 传给 review binary，由后者解析 baseline、创建或复用 worktree、应用 patches、可选执行 AI review，并把 JSON 结果输出到 stdout。

本地模式还有 --no-ai 和 --interactive。前者只验证 patch 能否应用，适合快速检查；后者在发现 issue 后等待用户修复或输入 rebuttal，再重新运行 review。这使 Sashiko 不只是服务器端机器人，也可以作为个人开发工作流中的本地审查器。

可靠性设计：并发、恢复、限流、缓存和 embargo

Sashiko 的可靠性设计分散在多个层面。

并发控制方面，parser dispatcher 使用 semaphore 控制解析并发；Reviewer 用 review.concurrency 控制 worktree/patchset 处理并发；LLM semaphore 则按 concurrency * 3 经验值扩展，以适配 Stage 1-7 并行、Stage 8-11 串行的平均请求形态。

崩溃恢复方面，系统启动时会 reset 中断状态，例如把 Applying / In Review 相关状态恢复到可继续处理的位置。worktree 目录也会在启动时清理，reference repo 会 prune stale worktrees，避免旧状态污染新的 review。

成本控制方面，配置提供 max_input_tokens、max_interactions、max_total_tokens、max_total_output_tokens、response cache、token usage 统计和 tool usage 统计。Prompt 选择也做了优化：Phase 0 先筛 relevant subsystem guides，Stage 3-6 可以不用 full log，prefetch 只提取 modified functions/structs。

输出控制方面，email policy 支持 reply_all、reply_to_author、cc_individuals、mute_all、静态 CC、ignored emails、subject prefixes、per-subsystem overrides 和 embargo hours。对于内核社区而言，自动 review 不是越快越好；有时需要延迟释放，避免干扰 maintainer 的人工节奏。

关键工程权衡：召回率、误报率、上下文成本和社区礼仪

Sashiko 有几个非常值得学习的 tradeoff。

召回率 vs 误报率。前 7 个阶段偏向多跑、多怀疑、多收集 concern；后 4 个阶段再去重、仲裁、验证和生成最终文本。这是典型的“先扩张搜索空间，再收敛证据”。如果一开始就要求模型只输出最终答案，召回率会下降；如果只追求召回，不做后段验证，误报会污染社区信任。

上下文完整性 vs token 成本。Linux kernel 太大，不可能把整个仓库塞进上下文。Sashiko 用 prompt index 筛选、prefetch modified functions/structs、只读 git tools、truncator 和 per-stage context 策略解决这个问题。模型初始只拿关键上下文，不够再查。

并行度 vs API 压力。Stage 1-7 并行可以提高吞吐，但 LLM 请求成本和 rate limit 会成为瓶颈。Sashiko 用 patchset concurrency 和 LLM semaphore 分层限流，避免 worktree 和 provider 同时被打爆。

单 patch review vs series final state。Linux patch series 中，前一个 patch 可能引入中间态，后一个 patch 再修复或重构。Sashiko 在 Stage 10 强调要检查 final series state，避免对中间态误报。这一点非常内核化，也非常重要。

自动化速度 vs 社区礼仪。Stage 11 专门生成 LKML-friendly inline reply，email policy 默认也非常保守。Sashiko 明白 review 结果不是发给机器看的，而是发给 maintainer、作者和邮件列表社区看的。技术正确之外，还需要语气、格式和时机正确。

局限与风险：Sashiko 解决了什么，仍然没有解决什么

Sashiko 已经把 LLM review 工程化到相当完整的程度，但它仍然不是“自动维护者”。

第一，模型输出仍然是概率性的。同一个 patch 在不同模型、不同温度、不同上下文下可能得到不同结果。Sashiko 用多阶段、验证、schema、工具查证降低不稳定性，但无法完全消除。

第二，它并不可靠编译整个 kernel。设计文档也承认编译是 missing link。很多内核 bug 必须通过特定 config、特定硬件、特定 workload 或长期 fuzz 才能发现。Sashiko 更擅长静态语义审查、路径推理和上下文一致性检查。

第三，baseline 检测仍是启发式。MAINTAINERS、subject、custom remotes 和 apply success 可以提高成功率，但内核树生态复杂，某些 patch 仍可能依赖尚未进入任何已知 tree 的上下文。

第四，自动 review 可能产生社区成本。即使误报率不高，只要输出太频繁、语气不合适或位置不精确，就会打扰维护者。因此 email policy、embargo、mute、send_positive_review 等配置不是附属功能，而是生产系统的必要部分。

第五，项目 schema 中还存在一些值得后续整理的边角问题，例如 patchwork_outbox 的 schema 片段里 check_state 字段出现重复定义痕迹。这类问题不影响整体架构判断，但说明项目仍在快速迭代中。

落地建议：从实验 demo 走向可运营系统

如果把 Sashiko 的思想迁移到企业内部或开源项目维护流程中，最重要的不是立刻复制 11 个审查阶段，而是先把运营边界设计清楚。

第一，先从只读审查开始。不要让模型一开始就拥有写权限或自动修复权限。更稳妥的路径是：模型只能读取代码、读取历史、生成结构化 finding，并把最终建议交给人类 reviewer 或 CI gate。只有当误报率、漏报率、回滚路径和审计机制足够成熟后，才考虑自动 patch 生成。

第二，所有结论都要绑定证据。finding 里必须包含文件、行号、触发路径、风险解释和建议修复方向。没有代码位置、没有调用链、没有上下文证据的评论，即使听起来合理，也应该被系统降权或丢弃。

第三，把发送策略当成产品能力。自动 review 的输出对象通常是人。什么时候发、发给谁、是否抄送、是否延迟、是否允许 positive review、是否需要人工确认，都会影响系统在团队中的信任度。Sashiko 把 email policy、embargo 和 outbox 做成配置，是非常正确的方向。

第四，先度量，再扩大覆盖。上线初期应该记录每个 provider、每个阶段、每类工具调用的 token 成本、耗时、命中率、被接受率和误报原因。没有这些数据，团队只能凭感觉判断模型好不好；有了这些数据，才能决定应该优化 prompt、换 provider、减少阶段，还是增加人工 gate。

第五，保留人工反驳和复审通道。一个成熟 review agent 不应该假设自己永远正确。它需要允许作者反驳、允许 reviewer 标记 false positive、允许系统把这些结果沉淀成后续评估集。Sashiko 的 interactive local review 已经体现了这种思路。

可迁移设计清单：把 Sashiko 的方法抽出来

从 Sashiko 中可以抽出一份通用的 agentic review 系统设计清单。

输入层：把邮件、PR、CLI、Webhook 等入口统一成内部事件，不让业务逻辑散落在每个入口里。

状态层：把 thread、message、patchset、patch、review、finding、interaction 和 outbox 全部持久化，避免任务只存在于内存或一次性日志中。

执行层：在模型介入之前，用确定性工具验证基础事实，例如 baseline 是否正确、patch 是否能应用、series final state 是否成立。

工具层：给模型足够的只读查询能力，但明确限制副作用。review agent 的核心能力应该是查证和表达，而不是未授权修改。

推理层：把复杂任务拆成多个可验证阶段。前段提高召回，后段去重、冲突解决、严重性判断和 false positive 过滤。

输出层：把模型结果转成目标社区或目标组织能接受的格式。对内可能是 PR comment，对外可能是邮件回复，对 CI 可能是 check status。

运营层：记录 token、耗时、工具调用、重试、失败类型、人工反馈和发送状态。没有运营数据，agent 系统就无法持续改进。

这份清单比具体 prompt 更重要。prompt 会随着模型演进而变化，但“事件、状态、工具、阶段、证据、输出、运营”这条主线，才是可验证 agent 系统的长期骨架。

结论：真正值得学习的是“可验证 agent 系统”的工程形态

Sashiko 最值得学习的地方，不是它用了哪个模型，也不是它能否在某个 benchmark 上找出多少 bug，而是它展示了一种可验证 agent 系统的工程形态。

它没有把 LLM 当作万能黑盒，而是把 LLM 放在一个确定性的外壳里：输入被解析成事件，状态被写入数据库，baseline 被 git 验证，worktree 被隔离，工具是只读的，阶段输出有 schema，错误可以重试，token 可以统计，邮件输出有策略，结果可以在 Web UI 和 CLI 中追踪。

对于任何想做代码审查 agent、CI agent、自动 triage agent 或维护者辅助系统的人，Sashiko 都提供了一个很好的参考：真正的 agentic engineering 不是“让模型自己想办法”，而是把任务拆成可验证阶段，把不确定推理限制在清晰边界内，再用工程系统记录、校验和恢复每一步。

如果用一句话概括：Sashiko 不是一个会聊天的 review bot，而是一套面向 Linux kernel patch 的审查生产线。它把社区工作流、git 事实、数据库状态、模型推理和邮件礼仪缝合到一起，这也正好呼应了它名字的含义：用一针一线加固复杂系统中最容易磨损的位置。