第 12 章 实习项目路线与面试问答

12.1 用一个问题串起整套项目

本章目标：把前面各章变成可复现项目，能给出基线、机制改动、验收证据和失败分析，并用三分钟解释自己的技术贡献。

选择一个范围明确的研究资料助手：用户给主题和范围，系统读取原始论文或官方资料，提取问题、方法、实验设置与局限，输出有来源且能逐条核验的简报。遇到证据不足或冲突，标记未知或继续查证。

项目价值不是“会联网搜索”，而是把资料变成有依据的结论。这里与本指南的引用导读要求一致：每个链接都要说明原文讲什么，不能列十条链接让用户自己猜。第一版可以只读你提供的公开本地文档，先建立质量基线；联网和多 Agent 都是后续可比较的扩展。

12.2 先写验收题，再选框架

准备小型资料集，每份保存标题、来源、时间/版本、正文与适用范围。标注问题及支持答案的片段，包含单来源、跨来源、不同版本冲突和无答案问题。不要只选你知道系统肯定能答好的题。

验收题本身也要检查：标准答案是否由资料支持？范围是否明确？多种合理表述是否都能通过？一个坏的评测集会把系统训练成迎合错误答案，而不是帮助用户理解。

12.3 第一版架构可以很小

用户主题与范围 → 输入校验 → 查询/资料选择
                          ↓
                  读取与检索证据
                          ↓
             结构化事实卡 → 报告生成
                          ↓
             来源/条件核验 → 最终报告
                          ↓
                  轨迹与评测结果

事实卡可以包含 claim、source_id、version、evidence_span、confidence_reason。这里的置信说明应解释证据质量，不要求模型凭空给一个精确概率。综合比较另存为 synthesis，列出支持它的多份事实卡，避免把自己的归纳写成某一篇论文的直接结论。

project/
  data/public_docs/      原文与元数据
  tasks/dev.jsonl       开发题
  tasks/eval.jsonl      隔离的验收题
  tools/                搜索、读取与受限写入
  runtime/              循环、预算与状态
  graders/              来源、条件和格式检查
  runs/                 配置、轨迹、报告与指标

这是建议目录，不依赖某个框架。先跑通一条任务链，再根据真实瓶颈选编排工具；要能解释框架替你管理了哪些状态、哪些问题仍由你实现。

一份最小报告的参考写法：用户问“ReAct 和 Reflexion 怎样利用反馈”，可以先提取两份事实，再做综合比较。

错误报告若写“Reflexion 通过强化学习微调权重，因此必然优于 ReAct”，即使挂上真实论文链接，也应被核验拒绝：机制描述与原文不符，优势结论缺乏同条件证据。这个小例子给出了项目验收的具体标准，后续可扩成逐事实的标注与评分。

12.4 四个里程碑，每个都有可检查产物

M1：工具与执行闭环。 从 mini_agent.py 理解搜索反馈，再读 repair_lab.py 的参数校验、调用关联和验收。研究助手至少具备搜索、读取与报告保存，返回无结果、错误参数和超时的明确状态。交付一条成功与一条失败轨迹，不仅是聊天截图。

M2：证据检索。 用 retrieval_lab.py 先理解 Recall@k，再在自己的文档集实现一种检索。保留来源、版本与访问范围，标注证据。交付逐题召回表；若引入向量或重排，固定问题与预算比较，说明漏检在哪一层减少。

M3：可信报告。 输出“研究问题、方法、实验范围、局限、与用户问题的关系”。每项事实关联原文，综合判断显式标记。交付无答案与版本冲突示例，人工核验引用支持关系。链接能打开只是最初检查，不等于结论受支持。

M4：评测与运行边界。 固定初态、模型和工具版本，记录所有尝试成本与终态；加入故障与注入材料，明确合法任务范围。交付运行命令、评测结果和一份失败复盘。长任务再加摘要、检查点与恢复，沿第 11 章做消融；多 Agent 只在能说明瓶颈时增加。

12.5 如何报告改进，避免无效指标

可以设置基线“单次生成只看全部给定文本”，实验组“检索后带证据生成”；也可以固定检索后只比较有无引用核验。改变多个机制时，把它们拆成阶段实验，避免不知道哪项产生收益。

结果表要包含任务数、运行次数、配置、指标口径和失败分布。下面是待填写模板，不是已经测得的数据：

若核验减少编造，但也把一些有答案问题拒绝了，应同时报告这两个变化。不能只挑一个上升指标。对于很小的任务集，描述个案和波动比给出未经支持的泛化结论更诚实，也更便于改进。

12.6 一份 README 怎样让别人复现

README 应按阅读者的路径写：项目解决什么任务 → 输入/输出示例 → 安装与运行 → 架构和边界 → 评测方法与实际结果 → 已知失败与限制。依赖、模型配置、数据取得方式和可重置环境要明确。

至少保留一份输入、一份报告、一条轨迹和对应验收结果。对失败案例说明期望、实际、第一处偏离、修复措施与回归结果。若代码需要账号或付费 API，另提供不需要凭据的最小 fixture，让阅读者能先理解运行机制。

发布前检查数据与日志是否可公开。评测结果不得混入凭据、私人文件或隐藏答案。源码中的 mock 策略和真实模型运行应明确区分，避免把教学成功展示成能力证据。

12.7 面试答题：先机制，再例子，再验证

“Agent 和 workflow 有什么区别？” 先说下一步控制权，再举例：固定搜索→总结是 workflow；根据缺失证据改变查询与读取路线是动态循环。最后说明你为什么保留确定性验收和预算，而没有把所有控制交给模型。

“RAG 为什么还有幻觉？” 沿链路回答：相关文档可能没召回；旧版本可能混入；生成可能扩展条件；引用可能不支持结论。给出一次真实失败与对应指标，不能只答“因为模型不够强”。

“为什么不用多个 Agent？” 说明单 Agent 的实测瓶颈是否存在；如果需要并行探索，再解释任务依赖、上下文/工作区隔离、合并验收与全部成本。没有比较数据时，把选择写成工程判断而非已证明的优势。

“怎么防注入？” 说明不可信材料怎样进入上下文，哪些工具可以产生副作用，以及运行时如何限制资源与外发。再拿一条被拒绝的攻击轨迹和一条正常任务成功轨迹说明保护与可用性。

“Harness、Skill、Agentic RL 是什么关系？” Harness 管执行环境与生命周期；Skill 提供可复用流程；RL 更新策略参数。引用第 11 章具体机制，说明你的项目实际实现了哪些，不能把文件记忆增加称为训练了模型。

“系统失败了怎么调？” 先还原轨迹，区分目标、检索、参数、执行、状态和验收；找到第一处偏离，构造最小复现，再只改相关机制并加入回归。能拿实际证据讲这条链，比罗列工具名更有信息量。

12.8 三分钟项目讲述与简历模板

第一分钟讲用户任务、现有方法的问题、输入输出与验收；第二分钟讲一项关键机制，例如版本过滤或当前状态验收；第三分钟讲同条件结果、典型失败与下一步。技术名词服务于具体问题，不需要把全部章节塞进讲述。

简历可采用这段待填写模板：

为〔用户/场景〕实现〔任务边界〕；以〔资料集、任务数与基线〕评估，通过〔机制变化〕改善〔实际测得指标〕；记录〔总成本与时延〕，针对〔具体失败〕增加〔验收/回归〕。可复现材料包含〔代码、轨迹与运行命令〕。

括号内容必须由实际材料支撑。没有测量就写“实现并验证某机制”，不要补一个看似亮眼的百分比。项目规模小也可以有价值，关键是问题明确、边界清晰、证据可复查。

12.9 两周实践路线与阅读次序

Hello-Agents [导读] 适合按课程补齐概念、框架与项目实现；Building effective agents [导读] 用于思考架构选择；ReAct [导读]、Reflexion [导读]、RAG [导读] 对应行动、反馈经验和证据知识三条基础路线。协议实现读 MCP [导读] 与 A2A [导读]，评测设计读 Agent evals [导读]。各份资料的完整导读仍直接附在本节。

本章交付物：一个范围明确的项目、一份可运行 README、一组未经挑选的评测结果、一份失败复盘和一段可被证据支持的项目讲述。