Agent 应用开发会员账号
知识目录选择核心方向与细分内容

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 结果说成生产成功率，说明项目证据还不完整。

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

把基础连成一次实现

做一个能验收的退货政策助手

用同一组虚构订单、政策文档和问题，贯穿响应处理、提示迭代、只读工具和 RAG。每一步保留实际输出，最后把验收方法迁移到可靠执行实验。

默认实验无需账号，使用标准库和已保存的真实本地 Embedding 向量；生成回复是明确标注的人工夹具。课程另给真实接口请求示例，需自行调用并记录模型结果。离线通过不代表模型质量或生产上线已经验收。

下载完整应用实验 v1 ↓ · Python 3.10+，解压后在目录内运行；可选重建向量需要 Python 3.10+、额外依赖与模型下载。

01

接住每一种模型响应

区分文本、工具调用、拒答、不完整和请求失败，避免把中间结果当成业务完成。

python3 model_response_contract.py

本步交付：保存响应分类、call_id 绑定和下一轮输入；真实接口实验另保存模型名、参数、请求标识和实际响应。

逐条验收

  • 正常只读查询得到 answer_ready
  • 跨租户请求返回 permission_denied，工具没有返回受保护订单
  • 不完整响应停止，重复调用和批量调用都受共享预算约束
02

把回答要求变成可检查的契约

固定三条问题，分别检查结构、业务标签、引用和无法回答时的行为。

python3 prompt_iteration.py

本步交付：保留 v1/v2 提示、候选回答和逐条失败原因；接入模型时替换候选回答，沿用同一组标签。

逐条验收

  • 标签不进入模型输入
  • 布尔 true 不能冒充合法天数，旧版和越权引用不能通过
  • 夹具的 v1/v2 通过数分别为 1/3 和 3/3；语义质量仍为 not_scored
03

把订单查询接入有界工具循环

把模型提出的调用交给服务器验证，只允许当前用户读取当前租户的订单。

python3 -m unittest test_application.ApplicationLabs.test_readonly_loop_requires_a_matching_tool_receipt test_application.ApplicationLabs.test_cross_tenant_request_has_no_resource_receipt test_application.ApplicationLabs.test_unknown_tool_is_not_executed -v

本步交付：在 model_response_contract.py 中追踪一次请求、授权判断、工具结果和最终回答，画出各自的信任边界。

逐条验收

  • 工具白名单拒绝未知写操作
  • 租户和用户身份由服务端夹具绑定，不由模型参数决定
  • 最终文本必须与成功工具回执一致，缺失回执时不宣告完成
04

从政策文档走到有引用的回答

实际运行解析、分块、SQLite 过滤、向量与关键词检索、RRF 融合，再检查回答引用。

python3 rag_pipeline.py
python3 application_project.py

本步交付：保留 chunk ID、来源与正文摘要、模型版本、两路排名、最终上下文和验收结果。

逐条验收

  • 普通退货与电池例外需要的证据进入上下文
  • 旧政策与另一个租户的政策在检索前被过滤
  • 未知税费问题即使检索到文档也回答 unknown；改文档或查询后必须重建向量
05

给故障和拒答留下可复现证据

按结果契约分别报告检索召回、输出结构、授权和引用，说明未评分的语义部分。

python3 -m unittest discover -v

本步交付：保存测试记录与失败样本，分别解释 top-k 不足、旧向量、越权、无回执和预算耗尽。

逐条验收

  • 应用实验和五个基础实验共 32 项测试通过
  • 缩小 top-k 后能复现例外证据缺失
  • 结构与标签通过的错误正文仍需人工语义检查，不汇总成模型准确率
06

把契约迁移到进程恢复和记忆撤销

进入独立的可靠性研究实验，观察进程退出、幂等回执和记忆失效怎样影响恢复。

在对应课程的进阶实验中下载可靠性实验 v3，按 README 在独立目录运行。

本步交付：保存首次退出与恢复后的事件、检查点和服务方回执，并解释为何某个旧草稿必须停止。

逐条验收

  • collect 后进程真正退出，租约过期后恢复成功且只提交一次 collect
  • 外部成功后退出，重试只有一份服务方效果
  • 撤销记忆后旧草稿停止发布；这一独立实验不与退货助手共享状态

继续深入

完整工程路线

沿着实际开发顺序深入学习。每一阶段先理解知识原理与实现，再用短答和边界实验检查理解。

01

搭起执行闭环

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

动手验证

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

02

接入数据与记忆

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

动手验证

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

03

验证长任务可靠性

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

动手验证

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

04

完成生产系统方案

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

动手验证

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