AFAgent Field Notes会员账号
知识目录选择核心方向与细分内容

LEARNING PATH

Agent 开发学习路线

已有后端经验，从七天入门开始；需要深入时，继续完整工程路线。

每天 20–30 分钟 · 本地可完成

后端转 Agent 七天入门

面向已有后端开发经验、第一次接触 Agent 的你。每天 20–30 分钟，先答三个短问题，再用本地模拟完成一个小任务。

每天 5 分钟短答、5–10 分钟阅读、10–15 分钟本地实验；较长的题目只读当天指定部分。

纸笔、伪代码或你熟悉的语言都可以，不需要模型账号、付费接口或在线执行。七天产出是入门实验记录，能否掌握仍要通过独立作答和验证判断。

Day 1先跑通最小执行闭环把 Agent 看作一个受预算约束的后端循环，区分模型建议和运行时控制。约 25 分钟

先独立短答 · 5 分钟

  1. Agent 和普通接口调用最明显的区别是什么？

    对照参考回答

    普通接口通常按固定步骤执行；Agent 可以根据模型给出的下一步建议继续调用工具。运行时仍负责校验、执行和停止。

  2. 模型说“完成了”，运行时就可以结束吗？

    对照参考回答

    先核对任务的验收条件。模型文字只能是候选结果；达到条件、步数上限或遇到不可恢复错误，都应有明确的结束状态。

  3. 工具结果为什么还要返回模型？

    对照参考回答

    让模型根据真实回执继续决策。回执应区分成功、失败和结果未知，不能把失败包装成已经完成。

再读相关题 · 5–10 分钟

先读“Agent 循环”的简短回答和终止条件；LLM 必要概念只关注工具调用消息和结构化输出。

本地小任务 · 10–15 分钟

模拟一个查询订单状态的循环：用固定数组替代模型响应，最多执行 3 步。

  1. 写下输入 orderId、输出 status/source，以及最大步数 3。准备“调用查询工具 → 返回已发货”的假响应。
  2. 让查询工具固定返回 {status: "已发货", source: "mock"}；每步记录建议、工具回执和结束原因。
  3. 把响应换成不断调用查询工具，观察第 3 步后是否停止；再换成一个不存在的工具名。

验收时逐条核对

  • 正常路径产生一条查询回执，输出标注 source=mock，结束原因是满足验收。
  • 重复调用路径最多执行 3 步，输出预算耗尽，不能声称查询已完成。
  • 未知工具不会执行，日志中有工具不存在的错误和明确结束原因。

留意这些故障现象：循环一直运行、凭文字宣告成功，或把不存在的工具当作执行过，说明运行时边界未落实。

保存实验过程与实际结果。题目页可以独立作答、记录笔记并安排复习；阅读参考回答不会自动代表掌握。

Day 2给工具加上输入边界沿用熟悉的接口校验，把格式、业务条件和调用权限分开检查。约 25 分钟

先独立短答 · 5 分钟

  1. JSON Schema 校验通过，业务请求就有效吗？

    对照参考回答

    不一定。Schema 检查结构与类型；金额范围、资源归属等业务条件，还要在服务端校验。

  2. 模型提供的 userId 可以直接用于权限判断吗？

    对照参考回答

    不能。调用者身份来自可信会话，模型参数只能描述请求对象，不能决定自己是谁或拥有哪些权限。

  3. 校验失败应返回什么？

    对照参考回答

    返回稳定的错误码和可修正信息，例如 INVALID_AMOUNT；不执行工具，不把失败说成成功。

再读相关题 · 5–10 分钟

只读简短回答、参数校验顺序和基础达标标准；复杂授权架构可稍后阅读。

本地小任务 · 10–15 分钟

为本地 mock 的“创建退款草稿”工具加校验，不连接支付或真实订单。

  1. 固定会话 userId=u1；准备订单 o1（归属 u1、实付 100）和 o2（归属 u2、实付 100）。
  2. 校验 orderId 是字符串、amount 是正数；再验证订单归属与退款金额不超过实付。仅通过后追加本地 drafts 数组。
  3. 依次输入 o1/20、o1/"20"、o1/120、o2/20，记录返回值和 drafts 长度。

验收时逐条核对

  • o1/20 创建 1 条本地草稿，结果明确标注尚未执行退款。
  • 字符串金额、超额金额、他人订单分别拒绝，拒绝后 drafts 长度仍为 1。
  • 修改传入的 userId 不会改变固定会话身份，也不能访问 o2。

留意这些故障现象：任一拒绝用例新增草稿，或模型参数覆盖会话身份，说明校验顺序或授权边界有缺口。

保存实验过程与实际结果。题目页可以独立作答、记录笔记并安排复习；阅读参考回答不会自动代表掌握。

Day 3用证据解释 RAG把检索、上下文和回答分开记录，遇到没有资料的问题时明确回答不足。约 30 分钟

先独立短答 · 5 分钟

  1. RAG 中模型负责查到文档吗？

    对照参考回答

    检索组件负责找候选资料，模型根据实际传入的上下文生成回答。先看召回和上下文，再判断回答是否忠实。

  2. 搜到了相关标题就足够了吗？

    对照参考回答

    不够。要确认段落里包含回答所需事实，并检查该段落是否进入模型上下文。

  3. 资料里没有答案时怎样处理？

    对照参考回答

    返回资料不足，并说明缺少哪项证据。不能根据常识补出一个看似合理的公司规则。

再读相关题 · 5–10 分钟

只读检索链定位方法和简短回答；今天用关键词检索理解链路，不安装向量库。

本地小任务 · 10–15 分钟

用三条本地文本模拟一个有引用的政策问答，保留每一步证据。

  1. 准备 d1：“标准订单退款在 7 天内申请”；d2：“会员积分每月更新”；d3：“退款需要订单号”。为每条设置 id。
  2. 按“退款”关键词筛选，再为“几天内申请退款”选择包含天数的 d1；记录候选 id、实际上下文和回答引用。
  3. 测试“会员退款是不是 30 天”；再故意从上下文移除 d1，观察回答是否转为资料不足。

验收时逐条核对

  • 第一问输出“7 天内”，引用 d1，并能在上下文找到对应原文。
  • 资料未说明会员例外，第二问不能声称“会员有 30 天”。
  • 移除 d1 后明确报告资料不足，日志能看出“检索到了但没有传入上下文”。

留意这些故障现象：引用 id 存在但原文不支持回答，或缺失上下文后仍给出 7 天，说明生成与证据脱节。

保存实验过程与实际结果。题目页可以独立作答、记录笔记并安排复习；阅读参考回答不会自动代表掌握。

Day 4分清任务状态与长期记忆记录当前任务做到哪一步，同时避免把任务数据当成所有用户共享的记忆。约 25 分钟

先独立短答 · 5 分钟

  1. 聊天历史、任务状态和长期记忆是一回事吗？

    对照参考回答

    不是。聊天历史是消息；任务状态记录本次任务的阶段与中间结果；长期记忆保存经过筛选、可供后续任务使用的信息。

  2. 本次订单号要写进所有任务共享的记忆吗？

    对照参考回答

    通常不需要。它属于当前任务状态，任务结束后按生命周期处理；长期保存需要明确用途和范围。

  3. 读取记忆时为什么仍要校验作用域？

    对照参考回答

    因为相似内容可能来自其他用户或项目。读取必须受可信的组织、用户或线程身份限制，不能只按关键词匹配。

再读相关题 · 5–10 分钟

只读作用域划分和简短回答；线程状态与长期记忆的区分是今天的重点。

本地小任务 · 10–15 分钟

用两个对象模拟任务状态与用户偏好，检查跨任务和跨用户读取。

  1. 建立 taskState[runId]，放 step、orderId、lastToolResult；建立 preferences[userId]，只放用户确认过的语言偏好。
  2. 让 u1 的 run1 执行到 queried 并保存结果；u1 开启 run2 时，只读取语言偏好，不复用 run1 的订单结果。
  3. 让 u2 请求读取 u1 的偏好，用固定会话身份校验；再用同一 run1 读取状态并继续下一步。

验收时逐条核对

  • run2 可以得到 u1 的语言偏好，但没有 run1 的订单号与工具结果。
  • u2 无法读取 u1 偏好，用户身份不由模型传入参数决定。
  • 恢复 run1 能看到保存的 step 和工具结果，并明确它们只是本地实验状态。

留意这些故障现象：新任务继承旧订单结果、所有用户共用一个偏好对象，或相似搜索绕过身份限制，说明作用域混在一起。

保存实验过程与实际结果。题目页可以独立作答、记录笔记并安排复习；阅读参考回答不会自动代表掌握。

Day 5模拟失败与恢复知道重试、检查点和幂等分别解决什么，用回执处理“执行过但没收到响应”。约 30 分钟

先独立短答 · 5 分钟

  1. 超时一定代表工具没执行吗？

    对照参考回答

    不一定。请求可能已经执行，只是响应丢失。写操作应先查回执或使用稳定的幂等键，不能直接换新请求重试。

  2. 有检查点就能确保写操作只发生一次吗？

    对照参考回答

    不能。外部写入与本地检查点可能不在同一事务，恢复时会重放。还需要操作幂等和可查询回执。

  3. 所有错误都应该重试吗？

    对照参考回答

    不应该。参数与权限错误先纠正，瞬时错误才有限重试。限制次数和截止时间，并保留取消或预算耗尽的状态。

再读相关题 · 5–10 分钟

先读重试与预算的简短回答；检查点题只关注“恢复可能重复执行”这一边界，租约等进阶内容留到完整路线。

本地小任务 · 10–15 分钟

模拟本地草稿工具已经执行、响应却丢失的情况，恢复后避免重复草稿。

  1. 沿用 Day 2 的本地 drafts，增加 receipts[operationId]；固定本次业务键 run1:create-draft。已有回执时返回同一 draftId。
  2. 第一次创建草稿并写入 receipts 后，故意抛出响应丢失；把任务检查点保留在 pending。
  3. 用同一 operationId 恢复执行，记录 recovered 回执；另测一个总失败的 mock，最多尝试 2 次。

验收时逐条核对

  • 响应丢失后恢复，drafts 仍只有 1 条，恢复结果返回原 draftId。
  • 重试沿用同一业务键，日志能区分首次执行与读取已有回执。
  • 总失败 mock 在 2 次后停止并标记失败，不声称完成；说明内存回执在进程重启后会丢失。

留意这些故障现象：恢复时换了幂等键出现重复草稿、无限重试，或把内存对象称为持久化保障，说明恢复方案仍有遗漏。

保存实验过程与实际结果。题目页可以独立作答、记录笔记并安排复习；阅读参考回答不会自动代表掌握。

Day 6写出可以核对的验收把“回答看起来不错”改成可逐条检查的结果、边界和执行记录。约 25 分钟

先独立短答 · 5 分钟

  1. 输出格式正确等于任务成功吗？

    对照参考回答

    不等于。还要核对事实、引用、权限和实际业务回执；合法 JSON 也可能包含错误答案。

  2. 为什么要把失败用例放进评测？

    对照参考回答

    正常路径无法暴露证据不足、越权和恢复重复等问题。失败用例检查系统有没有安全停止，并如实报告结果。

  3. 一天的小样本通过，可以宣布生产可用吗？

    对照参考回答

    不能。只能报告测试了哪些用例、观察到什么结果和未覆盖的边界，生产判断还需要代表性数据与更完整验证。

再读相关题 · 5–10 分钟

只读结果验收契约和基础标准；今天用人工核对表，不引入 LLM 裁判。

本地小任务 · 10–15 分钟

为前五天的本地实验整理 4 条验收用例，记录实际结果和未覆盖项。

  1. 建立表格：输入、预期结果、实际结果、证据、是否通过。加入正常退款草稿、他人订单、资料不足和响应丢失恢复四种用例。
  2. 逐条重跑或手工推演已有 mock，保存草稿数量、引用原文、错误码或恢复回执。未执行的用例写“未执行”，不要记为通过。
  3. 故意移除 Day 2 的归属校验，观察越权用例是否失败；恢复校验后复核，并写下未测试的数据库故障和真实模型表现。

验收时逐条核对

  • 每条用例都有明确预期，实际观察有对应证据；未执行与失败状态分开记录。
  • 移除归属校验时越权用例失败，恢复后拒绝创建他人订单草稿。
  • 结果报告仅覆盖这 4 条本地 mock，用例未覆盖范围被明确列出。

留意这些故障现象：所有用例总是通过、只检查输出有文本，或把未执行项标成通过，说明验收标准不能发现真实问题。

保存实验过程与实际结果。题目页可以独立作答、记录笔记并安排复习；阅读参考回答不会自动代表掌握。

Day 7把实验讲成可追问的项目用真实实验记录解释目标、边界、失败与取舍，区分已验证和待实现。约 25 分钟

先独立短答 · 5 分钟

  1. 面试介绍 Agent 项目时先讲哪个部分？

    对照参考回答

    先讲用户任务、输入输出与验收，再讲模型、工具和状态如何协作。这样每个设计选择都有明确目的。

  2. 没接真实模型，能把这些实验称为生产项目吗？

    对照参考回答

    不能。应说明它是本地 mock 入门实验，具体哪些行为验证过，哪些涉及真实模型、持久化或上线的能力尚未验证。

  3. 现在就需要多 Agent 或复杂框架吗？

    对照参考回答

    先根据状态、恢复和协作需求选择最小方案。这个入门实验可以用普通代码循环；更复杂方案要有明确需求与对比证据。

再读相关题 · 5–10 分钟

选型题先读简短回答；项目追问题只用来检查你的证据，不要求完成高级生产架构。

本地小任务 · 10–15 分钟

用一页笔记和 90 秒口述介绍你的“订单问答与退款草稿”本地实验。

  1. 画出输入 → 循环 → 工具/检索 → 状态 → 输出，标出固定会话、预算与验收检查的位置。
  2. 各选一条正常与失败轨迹，引用前几天真实保存的证据；写出你为什么先用 mock 和代码循环。
  3. 录音或计时口述 90 秒，再回答“工具超时是否执行过”“没有文档时怎么答”“重启后怎么恢复”；没验证的内容列成后续任务。

验收时逐条核对

  • 笔记包含目标、输入输出、验收、架构图和两条有证据的轨迹。
  • 口述能解释模型与运行时边界、作用域、幂等键和资料不足的处理。
  • 明确标注本地 mock、内存状态和人工评测，待实现项至少包括持久化、真实模型接入与更多评测用例。

留意这些故障现象：讲述只有技术名词、没有回执或实验记录，或把 mock 结果说成生产成功率，说明项目证据还不完整。

保存实验过程与实际结果。题目页可以独立作答、记录笔记并安排复习；阅读参考回答不会自动代表掌握。

继续深入

完整工程路线

沿着实际开发顺序复习。每一阶段先回答问题，再完成一次边界实验。

01

搭起执行闭环

能画清模型、状态、工具与运行时的边界；解释为什么工具调用需要校验、授权和回执。

动手验证

实现一个有步数预算的工具循环。模拟无效参数、工具失败和重复写入，解释终止与补偿策略。

02

接入数据与记忆

能沿着检索链定位错误，区分任务状态与跨任务记忆，把权限和撤销落实到查询链路。

动手验证

构造一个同主题、不同租户的数据集；验证召回、缓存和历史上下文都遵守权限。

03

验证长任务可靠性

能说明检查点、租约、幂等与取消的组合；用结果契约和执行轨迹共同判断质量。

动手验证

在工具请求前后注入宕机。记录恢复路径、重复请求与外部回执，用评测检查是否完成真正的业务目标。

04

完成生产系统方案

能交代链路追踪、审批边界、框架选型、成本预算和系统职责；给出可以验收的企业架构。

动手验证

设计一个企业研究助手：拆出请求入口、编排、工具网关、检索、记忆、评测和运维，并说明上线与回滚条件。

按需补充

模型基础与接口

理解上下文、结构化输出与工具调用的开发边界即可。

做 Agent 开发，必须掌握哪些 LLM 接口基础？Token、上下文窗口与输出上限分别约束什么？怎样给下一轮留出空间？预训练、RAG 和微调分别改变什么？企业知识问答为什么常要组合使用？模型输出了文字或工具请求，就算完成了吗？流式断线如何判断？