章节检查点
规则：每章先完成 5 个口述、2 个状态追踪、1 个调试、1 个代码任务，再展开“答案标准”。答案必须包含推理和证据，不能只报最终结果。
第 0 章：Agent 全景
口述（5）
- 用自己的话解释
Agent = LLM + 上下文 + 工具，Harness 在公式外承担什么？ - 为什么“会调用工具”仍不足以称为可靠 Agent？
- 从用户输入到最终产物，列出最小闭环。
- 课程中的 Skill、MCP、RAG、Hook、Goal 分别位于哪一层？
- 为什么可观察性、安全和评估不是最后再加的功能？
状态追踪（2）
- 用户请求客服退款，画出模型、上下文、检索、工具、事件和回答的状态流。
- 工具执行成功但最终回答无引用，指出哪一层“成功”、哪一层仍失败。
调试
一个 Agent 最终回答正确，却无法复现过程。先列缺失证据，再设计最小事件记录。
小代码任务
定义 AgentEvent(type, data, id)，写一个三事件脚本表示开始、工具完成、任务完成。
答案标准
应明确模型负责推理，上下文提供当前可见信息，工具改变或读取外部世界，Harness 编排循环、权限、状态、恢复和评估；状态题须区分局部成功与端到端验收；代码须有稳定事件类型和关联 ID。
第 1 章：什么是 Agent
口述（5）
- 普通 LLM 调用与 Agent Loop 的本质差异是什么？
- Tool schema 为什么同时是接口合同和上下文成本？
- 模型返回工具调用后，Harness 必须做哪几步？
- 为什么工具结果要作为新消息回送模型？
- 什么时候应该停止循环，什么时候应该报错终止？
状态追踪（2）
- 追踪“2+3”从 user message、tool call、tool result 到 final answer 的消息序列。
- 模型连续请求工具直到超过迭代上限，写出最后事件和终止原因。
调试
工具实际算出 5，但模型下一轮看不到结果。检查消息 role、tool call ID 和结果回填位置。
小代码任务
实现一个只支持 add(a,b)、最多两轮的 Agent Loop，并记录结构化事件。
答案标准
需画出“模型提议—Harness 校验—工具执行—结果回填—模型继续”的闭环；停止条件必须显式；代码至少测试正常回答和迭代上限两个分支。
第 2 章：百行 Agent Loop
口述（5）
- 百行 Loop 中哪些代码属于协议适配，哪些属于 Harness？
- 工具注册表为什么比大量
if/elif更易演进？ - 同步与异步工具在调用边界上如何统一？
- 为什么未知工具和参数错误要变成可观察失败？
CapabilityPolicy应在模型前、工具前还是两处都生效？
状态追踪（2）
- 一次工具抛异常后，追踪
tool.started → tool.failed → model.completed。 - 模型请求未授权工具，说明 handler 是否应被调用以及模型收到什么。
调试
工具异常被吞掉，最终只看到空回答。为调用边界补事件、错误类型和关联 call ID。
小代码任务
给 ToolRegistry 增加重复注册拒绝、未知工具拒绝和异步 handler 测试。
答案标准
回答需把模型输出视为不可信提议；权限检查必须发生在副作用之前；代码应证明危险 handler 没有被执行，而非只断言出现错误文字。
第 3 章：记忆与 Skill 进化
口述（5）
- 用户记忆、知识库、运行经验和 Skill 为什么必须分开？
- 什么信息适合跨会话记忆，什么信息只能留在轨迹？
- RAG 与记忆的写入者、时效和权威性有什么不同？
- Skill 候选为何不能直接覆盖稳定版？
- 轨迹如何脱敏、聚类、评估并变成候选方法？
状态追踪（2）
- 用户偏好与企业退货政策冲突时，追踪信息来源、优先级和回答。
- 候选 Skill 从 draft 到 published，写出每一步证据与人工动作。
调试
一条轨迹含凭据样式文本，候选 Skill 把它复制进说明。定位脱敏边界并增加回归测试。
小代码任务
实现 propose(base, trajectories)：去重经验、脱敏敏感片段，只返回候选对象。
答案标准
必须指出企业知识不能被用户偏好覆盖；候选发布须满足效果、成本、安全、确定性测试和人工批准；代码不能修改原 Skill，也不能扩大权限。
第 4 章：任务规划
口述（5）
- Plan 与 Goal 有什么不同？
- 好步骤怎样做到可执行、可验证、可重排？
- 什么时候使用静态计划，什么时候根据新证据重规划？
- 依赖关系为什么比简单序号更重要？
- 规划失败常见的“过细”和“过粗”分别是什么？
状态追踪（2）
- “发布客服 Skill”中评估失败，指出哪些步骤保持、哪些步骤重排。
- 两个无依赖任务并行，一个失败，追踪父计划状态和剩余任务。
调试
计划每一步都写“完善系统”，无法判断进度。把它改成带输入、动作、产物和验收的步骤。
小代码任务
定义 PlanStep(id, depends_on, status, evidence)，实现只返回依赖已完成的 ready steps。
答案标准
答案应强调 Plan 是可变路径而非完成证据；状态追踪需保留失败证据并避免重做已验证步骤；代码要覆盖依赖未满足和并行 ready 两种情况。
第 5 章：Subagent
口述（5）
- Subagent 解决上下文容量还是模型能力问题？
- 什么任务适合委派，什么任务应留在主 Agent？
- 委派合同至少要包含哪些字段？
- 为什么 Subagent 返回摘要仍需要证据链接？
- 多个 Subagent 写同一文件会产生什么风险？
状态追踪（2）
- 主 Agent 分派两个只读研究任务，追踪父任务、子任务和聚合状态。
- 子任务需要用户授权，说明请求应如何回到主任务而不是静默等待。
调试
子 Agent 报告“测试通过”，但没有命令和输出。设计父 Agent 的验收与退回规则。
小代码任务
实现一个 SubtaskResult(status, summary, evidence, blockers) 校验器，拒绝 completed 但无 evidence 的结果。
答案标准
必须说明隔离上下文、明确产物、单一写入者和父级验证；代码任务要让失败结果可诊断，不能只返回布尔值。
第 6 章：Agent Team
口述（5）
- Agent Team 与多个独立 Subagent 的差别是什么？
- 共享上下文和隔离上下文各自的风险是什么？
- Team 中如何分配所有权，避免重复工作和写冲突？
- 消息、事件和共享产物分别适合传递什么？
- 何时并行反而比串行更慢？
状态追踪（2）
- 研究、实现、验证三个角色并行协作，画出依赖和汇合点。
- 两个成员结论冲突，追踪仲裁需要的原始证据与最终决策。
调试
三个 Agent 都在修改同一模块并互相覆盖。重构任务边界、所有权和集成顺序。
小代码任务
实现一个只允许文件 owner 提交变更的简化协调器，并测试冲突拒绝。
答案标准
回答需区分协作协议、共享状态与代码所有权；并行必须建立在真正独立的任务上；冲突解决要回到证据而非多数投票。
第 7 章：Tool、Skill 与 MCP
口述（5）
- Tool、Skill、MCP 分别解决执行、方法和互操作中的什么问题？
SKILL.md为什么采用渐进披露？skill.web.json为什么不能破坏标准 Skill 的可移植性？- MCP 的 tools、resources、prompts 各适合什么？
- 远程 MCP 为什么既需要 Bearer 鉴权又需要 scope？
状态追踪（2）
- 从客户端 initialize 到 tools/list、tools/call，追踪会话与权限。
- 只读 Key 请求创建工单，写出鉴权通过但授权失败的路径。
调试
MCP 客户端能发现工具，却在调用时报 401。区分 URL、Header、Token Verifier 与 scope 的检查顺序。
小代码任务
实现两个工具：知识检索需 kb:read，工单创建需 ticket:write，并写越权测试。
答案标准
需说清协议连接不等于授权；Skill 是给 Agent 的方法说明，Tool 是可执行能力，MCP 是暴露能力的协议；代码必须验证 handler 在缺少 scope 时未产生副作用。
第 8 章：Hooks 与评估
口述（5）
- Hook 为什么是生命周期控制面，而不是普通日志函数？
- before 与 after Hook 的能力边界是什么？
- 轨迹怎样从事件集合变成可验证证据？
- Result Verifier、Process Verifier 与质量判断分别验证什么？
- 为什么发布门禁不能只看一个综合分数？
状态追踪（2）
before_tool_call返回 deny，追踪后续 Hook、工具 handler、轨迹和终态。- 候选成功率提升但有一个安全回退，追踪 evaluate、approve、publish 的状态。
调试
安全 Hook 抛异常后危险动作被放行。判断 fail-open/fail-closed，并补异常事件与门禁测试。
小代码任务
实现按注册顺序运行、非 allow 短路的 HookRegistry，测试 deny 后后续 Hook 不执行。
答案标准
必须给出 Event → Matcher → Handler → Decision → trajectory → verifier → gate；安全指标不可被质量抵消；代码须证明短路和安全 Hook 异常策略。
第 9 章：Goal 目标驱动
口述（5）
- 分别定义 turn、run、task、plan、Goal。
- Goal Contract 为什么要包含结果、范围、检查与边界？
- 如何判断“有进展”，为什么输出更多不算证据？
- 三个连续无进展周期后为什么应暂停？
- pause、waiting、resume、cancel、terminate 的语义差异是什么？
状态追踪（2）
- Goal 连续两次无进展、一次有进展、再两次无进展，写出计数和状态。
- 等待批准时收到无关事件，再收到批准事件，追踪恢复条件和 run ID。
调试
Goal 在成功检查缺证据时仍被标记 completed。定位完成前置条件并增加状态不变量。
小代码任务
为 GoalTracker 增加 checks 与 evidence，只有全部检查通过且有证据时才允许 complete。
答案标准
五个术语必须无重叠；Goal 稳定、Plan 可改；恢复要核验关联事件；代码至少拒绝证据缺失和错误恢复事件。
第 10 章：Mini Emperor 综合项目
口述（5）
- 一个客服请求如何经过 Web、API、RAG、引用与 SSE？
- SSE 恢复和 run 创建幂等为什么是两层？
- Skill ZIP 的下载、校验、解压和原子更新如何防攻击？
- Skill 自进化如何保证候选不能自行上线或扩大权限？
feature/* → master的 MR 为什么要确定性检查、Reviewer 和 Verifier 三层？
状态追踪（2）
- 候选从 proposal 到 publish，再 quarantine 和 rollback，列出版本状态与默认 resolve。
- MR 同时含 P1 与 P3，追踪报告、Artifact、MR Note、退出码和合并门禁。
调试
浏览器断线重连后重复展示已收到事件。检查 event ID、Last-Event-ID、服务端过滤和前端去重，并说明这不等于重复执行。
小代码任务
写一个端到端测试：运行客服 Skill、断言引用、从事件 1 续传、下载 ZIP 并在临时目录验证安装。
答案标准
答案必须引用真实 API、状态、文件或测试；要区分课程 v1 的内存实现与生产能力；代码不能写真实目录或暴露任何凭据，且必须包含失败断言。
总体评分记录
| 章节 | 口述 /10 | 状态 /6 | 调试 /5 | 代码 /6 | 总分 /27 | 证据位置 |
|---|---|---|---|---|---|---|
| 00 | ||||||
| 01 | ||||||
| 02 | ||||||
| 03 | ||||||
| 04 | ||||||
| 05 | ||||||
| 06 | ||||||
| 07 | ||||||
| 08 | ||||||
| 09 | ||||||
| 10 |