前八篇讲了 harness 的每个组件。这一篇讲怎么知道装好的 agent 可靠不可靠、上线后怎么运营它。agent 的失败与传统服务不同：多数不是异常——它”成功地”做了错事、在第 17 步忘了目标、把一个半成功的工具结果当成功、被一段网页里的文字带偏、跑了三十步花了五美元然后放弃。这些失败要被分类、被检测、被评测、被监控，否则你只知道”用户说不好”。

三部分。可靠性设计：失败分类学、幂等的工具、预算与卫士、部分结果的交付。评测：结果之外看过程——轨迹评测；公开基准（SWE-bench Verified、Terminal-Bench 2.1 → 4.0、τ-bench）与它们的局限；自己的轨迹评测集从 trace 里采。运营：trace 的结构（会话 → 任务 → 步骤三级、决策点日志——L5 展开）、每任务成本的分布、面板与告警、从 demo 到生产的清单。

本篇要回答的核心问题是：

agent 的失败有哪几类，各怎么检测与应对？¹ 轨迹评测评什么，公开基准能信多少，自己的评测集怎么建？² 上线后看什么，从 demo 到生产要过哪些关？³

一、总览

1. 失败分类学

%%{init: {"flowchart": {"wrappingWidth": 200}}}%%
%% 图：agent 的三种结束方式 → trace → 失败打类 → 评测用例的闭环
flowchart TB
    R["agent 跑一个任务"] --> O{"结束方式"}
    O -- "模型给出最终回答" --> V["结果校验：文件真改了？测试真过了？<br/>（「已完成」要有佐证）"]
    O -- "步数 / token / 美元 / 时间任一到顶" --> P["<b>交付部分结果：</b><br/>done · pending · blocker"]
    O -- "卫士：重复调用、连续失败" --> H["降级给人"]
    V & P & H --> TR["每一步进 trace（第五篇）"]
    TR --> C["失败打类（十类里只有一类是异常）<br/>分布进面板，每类有药"]
    C --> E["<b>坏轨迹 → 评测集用例</b><br/>轨迹评测：结果之外看过程<br/>（步数、越权、工具选择、成本）"]
    E -. "下次改动先过这一关" .-> R

agent 失败分类学

类	形态	是异常吗	检测	应对（篇）
幻觉的动作	调用了不该调的工具、参数编造、声称”已完成”而没做	否	结果校验；”已完成”必须有工具返回佐证	权限与确认（5）、结构化输出的证据字段（L2）
死循环	重复同一调用、在两个状态间摆	否	重复检测、无进展检测	卫士（1）
预算耗尽	步数 / token / 美元 / 时间到顶	否（是设计的出口）	卫士触发	部分结果交付（1）、卸载与压缩（4）
工具半成功	命令返回 0 但没做对；API 超时但已生效	否	幂等 id、结果校验	幂等工具（《模型作为组件（06）：客户端工程——重试、超时、幂等、限流与流式解析》、本篇）
权限拒绝	沙箱或策略拦住	否	沙箱拒绝事件	让模型换方法或问人（5）
上下文腐化	忘目标、重复已做的事、引用过期状态	否	探针问题、漂移检测	复述、压缩策略（4、L2）
注入	工具返回里的指令被执行	否	异常动作（突然访问陌生域名）	四层（5）、L6
中断未恢复	崩溃 / 重启后任务丢失或重复	是	会话状态与日志的不一致	事件溯源与幂等（3）
协调失败（多 agent）	worker 结果被误信、handoff 卡住、死锁	否	树状 trace	校验、超时（7）
模型 / 供应商变更	同一 prompt 行为变了	否	回归评测	评测门禁（《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》、《Prompt 与上下文工程（06）：prompt 当代码管——版本、评测、A/B，以及上下文 vs 检索》）

十类里只有一类是异常。所以 agent 的可靠性不能靠 try / catch，要靠检测 + 评测 + 监控。

%% 图：一个团队最近 50 次 agent 失败按十类归类的典型分布（示意）——幻觉的动作与上下文腐化占大头，其次是预算耗尽、工具半成功、死循环；只有「中断未恢复」那一类是程序异常，try / catch 只能抓到它
%%{init: {"xyChart": {"width": 760, "height": 340, "plotReservedSpacePercent": 60}, "themeVariables": {"xyChart": {"plotColorPalette": "#c0392b, #5b8fd6, #4d9a5c"}}}}%%
xychart-beta
    title "50 次失败的分类分布（示意）"
    x-axis ["幻觉的动作", "上下文腐化", "预算耗尽", "工具半成功", "死循环", "权限拒绝", "协调失败", "注入", "供应商变更", "中断未恢复（异常）"]
    y-axis "次数" 0 --> 14
    bar [12, 10, 7, 6, 5, 3, 3, 1, 1, 2]

2. 本文的章节安排

第二章可靠性设计：幂等、预算、部分结果；第三章轨迹评测；第四章公开基准与它们的局限；第五章 trace 与运营；第六章从 demo 到生产的清单；第七章实践建议。

二、可靠性设计

1. 幂等的工具

《模型作为组件（06）：客户端工程——重试、超时、幂等、限流与流式解析》讲过：模型调用重复只多花钱，工具重复有副作用。agent 里重复的来源更多——重试、崩溃恢复后重放、模型重复调用（卫士提醒之前）、并行的子 agent 各调一次。工具的设计：按 call_id 或业务键幂等（第二次调用返回第一次的结果）、不幂等的走确认门（发送、付款——第五篇的风险分级）、返回”已存在”而不是报错（创建资源时目标已存在 → 返回它，让模型继续而不是把”重复”当失败）。运行时侧：记录已执行的 call_id，恢复时不重复执行（第三篇）。

2. 预算

四种预算同时设：步数（第一篇）、token（每任务累计输入 + 输出）、美元（按 《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》的价目实时算，含子 agent）、时间（墙钟）。任一到顶触发同一出口——交付部分结果。预算按任务类型定（研究任务大、分类任务小），并让模型看到剩余（Codex 的 get_context_remaining——第四篇）。子 agent 的预算从父任务的预算里扣。

3. 部分结果

预算耗尽或卫士触发时，agent 应交付已完成的部分 + 未完成的清单 + 阻塞原因，而不是一句”失败”。结构化输出（《Prompt 与上下文工程（03）：结构化输出——约束解码、schema 设计与失败修复》）里预留这个形态：status: partial、done: [...]、remaining: [...]、blocked_by: ...。复述机制（第四篇的 plan / todo）让这个清单现成。对人来说，一个诚实的部分结果远比一个编造的完成有用——PocketOS 事件里 agent 的”猜测而不是验证”在这里也适用：不确定就说不确定。

%% 图：四种预算同时设、任一到顶走同一个出口——步数、token、美元（实时按价目算，含子 agent）、墙钟；出口是结构化的部分结果：status: partial、done 列表、remaining 列表、blocked_by；复述机制维护的 todo 让这个清单现成；子 agent 的预算从父任务里扣
flowchart LR
    T["<b>任务预算（按类型定）</b><br/>研究任务大 · 分类任务小"] --> B1["步数 ≤ 40"] & B2["token ≤ 800K"] & B3["<b>美元 ≤ 3.00</b><br/>实时按价目算，含子 agent"] & B4["墙钟 ≤ 20 min"]
    B1 & B2 & B3 & B4 -->|"任一到顶"| OUT["<b>同一个出口：部分结果</b><br/>status: partial<br/>done: [模块 A 迁移, 测试通过]<br/>remaining: [模块 B, 文档]<br/>blocked_by: 数据库凭据缺失"]
    TODO["复述的 todo / plan（第四篇）"] -.->|"清单现成"| OUT
    SUB["子 agent 的预算"] -.->|"从父预算里扣"| T
    classDef n fill:#fff7e0,stroke:#c98a00,color:#222
    classDef b fill:#eef6ff,stroke:#5b8fd6,color:#222
    classDef ok fill:#eefaf0,stroke:#4d9a5c,color:#222
    class T,SUB n
    class B1,B2,B3,B4 b
    class OUT,TODO ok

4. 结果校验

“已完成”要有佐证：文件改了 → 读回来看；测试过了 → 测试的输出在工具返回里；数据入库了 → 查一次。让模型在最终回答前做一步校验（系统提示里要求，或作为一个固定的工作流步骤），并在结构化输出里要求证据字段。这是对”幻觉的动作”最直接的防线。

三、轨迹评测

1. 结果之外看过程

单步任务评结果就够；agent 的失败常在过程里：结果对了但走了 40 步花了十倍的钱、结果对了但中途越权、结果错了但错在第 3 步的一个工具选择。轨迹评测对整条轨迹打分：

轨迹评测的维度与指标

维度	指标	怎么算
结果	任务完成率（自动验证优先：测试通过、输出匹配；否则 judge）	每题跑 \(k\) 次看分布（《模型作为组件（01）：失效模式——非确定性、幻觉、上下文与越界，把「模型会出错」拆成七条可检测的性质》）
效率	步数、token、美元、墙钟；与基线（人或最优路径）的比	从 usage 与 trace 聚合
过程正确性	工具选择对不对、参数对不对、有没有不必要的弯路、有没有重复	规则（重复检测）+ judge 看轨迹
安全	有没有越权尝试、被拒次数、绕过障碍的提议	沙箱与策略事件计数
鲁棒性	面对工具错误、注入、缺信息时的行为（问人 / 降级 / 硬闯）	评测集里故意放这些情形
部分结果质量	预算耗尽时交付的清单是否准确	人工 / judge

2. 评测集从哪来

与 《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》、《检索与知识接入（07）：检索评测与运营》同源：从 trace 里采真实任务——高频的、失败过的、边界的；每条含初始状态（仓库快照、数据库状态、可用工具）、任务、验收标准（自动验证脚本或评分标准）。agent 评测集比问答评测集贵得多（要可重现的环境），所以：先几十条，用容器快照固定环境，验收尽量自动化（测试、断言），judge 只评自动化不了的部分并与人工校准（L5）。

3. 录制回放

《模型作为组件（01）：失效模式——非确定性、幻觉、上下文与越界，把「模型会出错」拆成七条可检测的性质》讲过的手段在 agent 上更重要：把每步的模型输出录下来，改了工具、解析逻辑、卫士之后用录制回放做回归（不重跑模型——省钱且可复现）；只有改了 prompt、模型、effort 才需要重跑模型。DeepSeek Harness 的 replay 建在事件溯源日志上（第三篇），”keyless recorded-session replay”是它的一类测试。

%% 图：录制回放把两类改动分开——改了工具实现、解析逻辑、卫士阈值、权限规则：重放录制的模型输出，不重跑模型，免费、可复现、秒级；改了 prompt、模型、effort：模型的输出会变，必须重跑（评测集 × k 次）；两类都进门禁，但成本差两个量级
flowchart TB
    LOG["录制的轨迹：每步模型的完整输出 + 工具返回"]
    CH{"改了什么？"}
    CH -->|"工具实现 · 解析 · 卫士阈值 · 权限规则 · 压缩逻辑"| RP["<b>回放：喂录制的模型输出</b><br/>不调模型 · 免费 · 可复现 · 秒级<br/>看：解析对不对、卫士该触发的触发了没、权限判定变了没"]
    CH -->|"prompt · 模型 · effort · 工具描述"| RR["<b>重跑：模型输出会变</b><br/>轨迹评测集 × k 次 · 按分布比 · 贵"]
    LOG --> RP
    RP & RR --> GATE["门禁：逐条 diff → 灰度 → 回滚"]
    classDef n fill:#fff7e0,stroke:#c98a00,color:#222
    classDef dec fill:#eef6ff,stroke:#5b8fd6,color:#222
    classDef ok fill:#eefaf0,stroke:#4d9a5c,color:#222
    classDef exp fill:#fdecea,stroke:#c0392b,color:#222
    class LOG,GATE n
    class CH dec
    class RP ok
    class RR exp

四、公开基准与它们的局限

1. 三个基准

三个 agent 基准

基准	测什么	现状
SWE-bench Verified	给真实 GitHub issue，agent 改代码让隐藏测试通过；500 题人工核验过的子集	coding agent 的标准指标 前沿系统七成以上 对 harness 敏感
Terminal-Bench	终端里的多步任务（配环境、跑工具、处理数据）	2.1 → 3.0 → 4.0 快速加难：DeepSeek V4.1 Flash 的发布说明给出 90.6 / 30.0 / 31.2——同一模型在相邻版本上差三倍，是饱和后加难的痕迹（《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》）
τ-bench	多轮工具使用 + 与模拟用户对话（航空、零售的客服场景），按策略遵循评	测”在规则下与人交互着做事”，比纯代码更接近业务 agent

2. 局限

• 脚手架不可横比：同一模型换 harness 分数差很多——工具集、系统提示、压缩策略、允许的步数都影响结果。DeepSeek Harness 的 Minimal 模式（只留 shell 与文件编辑器）就是为了在比较模型时控制这个变量（第六篇）。读任何 agent 基准先看它用了什么 harness、多少步、有没有测试反馈。
• 污染与饱和：与 《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》相同——题在网上、模型见过；分数到顶后换更难的版本，版本之间不可比。
• 只测结果：多数基准报完成率，不报步数、成本、越权——轨迹维度缺失。
• 分布不是你的：GitHub issue 与航空客服不是你的业务；用它们缩范围，用自己的评测集决定。

3. 正确用法

基准用来判断”这个模型 + harness 组合是否在合理水平”、发现新模型值得进评测；决策用自己的轨迹评测集，且报告完成率与成本 / 步数 / 越权一起。

五、trace 与运营

1. trace 的结构

三级树：会话（用户、模型版本、prompt 版本、工具集版本、权限档、开始结束时间、总成本）→ 任务 / 轮次（用户输入、最终输出、状态：完成 / 部分 / 失败、成本）→ 步骤（每次模型调用的完整输入输出、usage、effort、每次工具调用的参数、结果、耗时、沙箱、审批；卫士触发；压缩 / 卸载事件；子会话 id）。第三篇的事件溯源日志天然是这棵树的来源；L5 讲 trace 的存储、可视化、与 OpenTelemetry GenAI 语义约定的对齐。

决策点日志：在循环的每个分支打结构化事件——选了哪个工具、为什么终止、权限判定结果、预算余量、卫士是否触发——让轨迹能画成状态图而不是日志流。

%% 图：agent trace 的三级树——会话（用户 · 模型 / prompt / 工具集版本 · 权限档 · 总成本）→ 任务 / 轮次（输入 · 输出 · 状态：完成 / 部分 / 失败 · 成本）→ 步骤（每次模型调用的完整输入输出与 usage、每次工具调用的参数 / 结果 / 耗时 / 沙箱 / 审批、卫士触发、压缩与卸载事件、子会话 id）；子会话再挂一棵同样的树
flowchart TB
    S["<b>会话 s-7f3</b><br/>用户 · Sonnet 5 快照 · prompt v12 · 工具集 v4 · workspace 档 · 总 2.4 美元"]
    S --> T1["轮次 1：「把模块 A 迁到新 API」<br/>状态：完成 · 0.9 美元"]
    S --> T2["<b>轮次 2：「顺便修一下测试」</b><br/>状态：部分 · 1.5 美元"]
    T2 --> P1["<b>步 1 模型调用</b><br/>完整输入 / 输出 · usage · effort high · 思考 2.1K"]
    T2 --> P2["<b>步 2 工具：run tests</b><br/>参数 · 结果（3 fail）· 4.2 s · 沙箱 ok"]
    T2 --> P3["<b>步 3 工具：edit file</b><br/>审批：allow 规则 · 结果 · 卸载 → spill://…"]
    T2 --> P4["<b>步 4 子 agent：explore</b><br/>子会话 s-7f3/c1 →（同样的一棵树）"]
    T2 --> P5["<b>步 9 卫士：预算耗尽</b><br/>→ 部分结果"]
    P1 -.- D["决策点日志：选了哪个工具 · 为什么终止 · 权限判定 · 预算余量 · 卫士是否触发"]
    classDef s fill:#eef6ff,stroke:#5b8fd6,color:#222
    classDef t fill:#fff7e0,stroke:#c98a00,color:#222
    classDef p fill:#eefaf0,stroke:#4d9a5c,color:#222
    classDef g fill:#fdecea,stroke:#c0392b,color:#222
    classDef n fill:#f0f0f0,stroke:#888,color:#222
    class S s
    class T1,T2 t
    class P1,P2,P3,P4 p
    class P5 g
    class D n

2. 面板

agent 运行面板的指标与告警

指标	含义	告警
任务完成率（按类型）	结果	掉出评测集基线的置信区间
失败分类分布	十类各占多少	某类骤升（注入、越权、死循环）
每任务成本 p50 / p95	钱	p95 涨、或 p95 / p50 比值涨（弯路变多）
步数分布	效率	中位数涨
卫士触发率	健康度	重复调用、预算耗尽的频率
审批率与拒绝率	人机分工是否合理	拒绝率趋零（疲劳）或趋百（规则太严）
沙箱拒绝与越权尝试	安全	任何上升
部分结果比例	有多少任务没做完	涨
缓存命中率、TTFT	《Prompt 与上下文工程（05）：prompt caching 与上下文的排列》、《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》	骤降接部署时间线
等待中的会话数	运行时容量（第三篇）	积压

3. 在线评测

抽样把 judge 跑在真实轨迹上（按比例）、指标进面板；用户的采纳 / 拒绝 / 修改 / 接管带 trace id 落库（L5）。这些是评测集的补充来源——离线集覆盖不到的失效模式从这里发现。

4. 变更管理

模型升级、prompt 改动、工具集变化、harness 版本升级（两个开源 harness 都在快速迭代）——每一项都是一次发布，走 《Prompt 与上下文工程（06）：prompt 当代码管——版本、评测、A/B，以及上下文 vs 检索》的门禁：轨迹评测集 × \(k\) 次、逐条 diff、灰度、回滚。agent 系统的变量比问答多（工具、权限、压缩策略都会影响行为），门禁更重要。

六、从 demo 到生产

一份清单，按本系列的顺序：

从 demo 到生产的清单

项	检查	篇
循环	四个卫士 + 两个出口都有并有测试；工作流能做的没做成 agent	1
工具	描述从模型视角写 MCP server 按 2026-07-28 带授权 二十个以上用 tool search 多步数据处理用 PTC 且有沙箱	2
运行时	会话是 append-only 日志 崩溃可恢复且幂等 挂起释放 worker 前端从日志订阅 按会话预算与隔离	3
上下文	卸载阈值、清理、压缩（思考链边界、可读或可迁移）、复述；子 agent 有独立预算	4
权限	权限档默认最小 执行策略覆盖删除 / 强推 / 对外写并有测试 沙箱且拒绝不自动升级 PocketOS 五环自检 审批分级	5
交付形态	托管 / 库 / 自托管的选择有理由；日志格式自己定	6
多 agent	只在三个理由之一成立时用 每 agent 独立预算 trace 支持树	7
记忆与人	记忆有来源与遗忘 每类动作有风险级 问人是挂起点 后台 agent 交付可审阅中间物 写下当前自主级别与升级缺的验证	8
可靠性	工具幂等 四种预算 部分结果格式 结果校验	9
评测	轨迹评测集（几十条、固定环境、自动验收） 录制回放 基准只缩范围	9
运营	三级 trace + 决策点日志 面板十项 在线 judge 抽样 变更走门禁	9
fallback	模型 / 供应商 fallback 链（《模型作为组件（06）：客户端工程——重试、超时、幂等、限流与流式解析》）与推理状态方向性；harness 版本钉住	1、6

demo 通常只有第一行的前半。清单上每一空格都是一个上线后会出的事故。

七、实践建议

1. 写失败分类：把你的 agent 最近 50 次失败按十类归类，看分布——多数团队第一次做会发现”幻觉的动作”与”上下文腐化”占大头，而它们都不是异常。
2. 工具幂等审计：每个有副作用的工具问”重复调用会怎样”，不幂等的加幂等键或确认门。
3. 四种预算 + 部分结果格式，让模型看到剩余预算。
4. 建轨迹评测集：从 trace 采 30 条，容器快照固定环境，自动验收，报告完成率与成本 / 步数 / 越权。
5. 录制回放接进 CI：改工具与解析逻辑时不重跑模型。
6. 面板十项 + 决策点日志，审批率与拒绝率单独看。
7. 过一遍第六章清单，空格写进计划。

八、本文小结

• 十类失败只有一类是异常：幻觉的动作、死循环、预算耗尽、工具半成功、权限拒绝、上下文腐化、注入、中断未恢复、协调失败、供应商变更——靠检测 + 评测 + 监控。
• 可靠性设计：工具按 call_id / 业务键幂等、不幂等走确认门、”已存在”不当失败；四种预算同一出口；部分结果有格式（done / remaining / blocked_by）；”已完成”要有佐证。
• 轨迹评测六维：结果（按分布）、效率、过程正确性、安全、鲁棒性、部分结果质量；评测集从 trace 采、固定环境、自动验收优先；录制回放做非模型改动的回归。
• 公开基准（SWE-bench Verified、Terminal-Bench 2.1 → 4.0 的 90.6 / 30.0 / 31.2、τ-bench）受脚手架、污染饱和、只测结果、分布不同四个局限，只用来缩范围；Minimal 模式控制脚手架变量。
• 运营：三级 trace + 决策点日志；面板十项（完成率、失败分布、成本 p50 / p95、步数、卫士、审批率 / 拒绝率、越权、部分结果、缓存 / TTFT、等待会话）；在线 judge 抽样；每项变更走门禁。
• 从 demo 到生产的清单十二行；demo 通常只有第一行的前半。

九、自测

1. 一个 agent 报告”已把配置更新并重启服务”，但服务没重启。这属于哪类失败？怎么在设计上防止？

   答案

   幻觉的动作（声称完成而没做，或工具半成功——重启命令返回了但服务没起来）。防：最终回答前强制一步校验（查服务状态的工具返回作为佐证）；结构化输出要求 evidence 字段引用工具返回；重启类工具的返回要包含实际状态而不只是退出码。详见第一章、第二章。

2. 为什么”结果正确率 85%”不足以判断一个 agent 可靠？至少还要看哪三个数字？

   答案

   过程里的失败结果看不出来：走了弯路（成本 p95 是 p50 十倍）、中途越权尝试（被沙箱拦住但说明判断有问题）、靠猜对的（鲁棒性差）。至少加：每任务成本 / 步数的分布、沙箱拒绝与越权尝试次数、面对工具错误与注入时的行为（评测集里故意放）。详见第三章。

3. DeepSeek V4.1 Flash 在 Terminal-Bench 2.1 / 3.0 / 4.0 上分别 90.6 / 30.0 / 31.2。这三个数字说明什么？能用来比较两个模型吗？

   答案

   同一模型在相邻版本上差三倍，说明 2.1 已饱和、3.0 / 4.0 大幅加难——版本之间不可比。比较两个模型必须用同一版本、同一 harness（脚手架影响很大——Minimal 模式一类的控制）、同样的步数与反馈条件，且要看成本与步数不只完成率；即便如此它也只是缩范围，决策用自己的轨迹评测集。详见第四章。

4. 改了工具的结果格式与卫士阈值，要做回归。该重跑模型吗？怎么做最省？

   答案

   不需要重跑模型——改动不影响模型的输入决策（prompt、模型、effort 没变）。用录制回放：重放评测集里录好的模型输出，只重新执行工具与卫士逻辑，检查解析、幂等、卫士触发是否符合预期。省钱且可复现；只有改 prompt / 模型 / effort 才重跑。详见第三章。

5. 面板上审批拒绝率从 12% 降到 0.5%，任务完成率不变。这是好消息吗？

   答案

   多半不是。拒绝率趋零通常意味着审批疲劳——人不再看内容一律点允许——或规则改松让本该问的没问；审批实际失效，越权风险上升而完成率不会反映。要看：审批请求总量是否也变了、审批的内容分布、沙箱拒绝与越权尝试是否上升；修法是按风险重新分级、批一类、Guardian 先筛（第五篇）。详见第五章。

---

• 上一篇
  工具、Agent 与 harness（08）：memory 与 human-in-the-loop
• 下一篇
  工具、Agent 与 harness（10）：系列总结与通关自测

COMMENTS

评论存放在 GitHub Discussions， 用 GitHub 账号登录即可发表，支持 Markdown。 想针对正文某句话说？选中那段文字，点浮出的「评论」即可划线评论；觉得哪里写错了，发表时勾上「同时提交 Issue」。 有人回复你时 GitHub 会按你的通知设置发邮件，不用守在这里。