00 核心概念与任务拆解

在写代码前，先把一个 AI 应用拆成能解释的部件。本页以“回答文档构建问题”为例，说明你在后续课程里会反复遇到的概念，以及它们各自解决什么问题。

1. 模型、应用和 Agent 的关系

语言模型根据输入上下文生成输出。文档助手还需要准备资料、组织请求、检查答案和呈现结果；这些都属于应用的职责。

当流程固定为“检索资料 → 请求模型 → 检查答案”时，可以直接写成固定工作流。当下一步需要根据上一步结果选择工具、追加查询或决定结束时，才出现本教程第三课的控制循环。

应用
├── 输入：问题与用户上下文
├── 资料：检索与证据整理
├── 模型：生成答案或提出工具调用
├── 执行：校验、调用工具、管理步骤
└── 输出：答案、引用、缺失信息或错误

“用了模型”“用了工具”“有多步循环”是不同层面的描述。给一个程序起名为 Agent，不会自动赋予它可靠性、记忆或权限控制。

2. Token 与上下文到底限制什么

Token 是模型处理文本的编码单位，不等于中文字符、英文单词或字节。准确数量取决于具体模型的分词方式；不能用固定的“一个字等于一个 token”估算所有情况。

一次任务可能消耗上下文的内容包括规则、问题、历史消息、工具定义、检索片段和工具结果。输入不断变长，会占用更多预算，也可能引入互相冲突或不相关的信息。

先做一个无需分词器的观察实验：同一个问题分别附上一条相关文档和四条文档，比较请求体包含哪些信息。开启真实调用后，再看 API 返回的 usage；请求体字符数只可用于理解规模，不能作为准确的 token 计费值。

更多基础原理见 Token、Tokenizer 与上下文窗口 与 Transformer 架构。

3. Prompt、上下文和知识的分工

部件	文档助手中的例子	典型错误
任务规则	只能根据 evidence 回答	规则散落在多轮消息中，相互矛盾
用户问题	如何构建文档	没有说明所指的项目或环境
外部上下文	build 文档的内容	塞入大量无关文本，或混入过期版本
输出约定	答案、引用、状态	下游依赖自然语言猜测任务是否成功

例如，单写“你是资深架构师”不能补齐缺失的构建命令。更有效的操作是提供正确的项目资料，并规定资料缺失时怎样结束任务。

提示词改变当前任务的行为要求；检索把外部资料带进上下文；模型训练则改变模型参数。后续遇到新需求时，先判断你缺少的是信息、任务约定，还是模型能力，不要把所有问题都归到提示词。

4. 结构化输出和工具调用不是一回事

结构化输出让结果符合一份数据契约，例如返回 answer/citations/status。工具调用让模型提出一个动作，例如调用 search_docs。

结构化答案：给调用者什么结果？
工具请求：应用下一步执行什么动作？

模型返回 {"status":"answered"} 并不意味着应用真的执行了部署。同样，模型生成一个函数调用也不意味着函数已经运行。执行记录必须来自程序自身。

5. RAG 和 Embedding 放在哪一层

RAG 的核心路径是先获取外部证据，再依据证据生成答案。Embedding 可以把内容表示成向量，帮助查找语义相关资料，但只是检索的一种手段。

本教程先用关键词基线：看得到每条资料为什么被选中，能区分“找错资料”和“有资料仍答错”。之后替换检索器时，只需保持证据对象的结构，便于公平比较。

学习概念时可用下面的对照：

• 找不到资料：先检查入库、切片、检索和权限。
• 找到资料但答错：检查证据拼装、任务说明和生成质量。
• 答案正确但引用错：检查引用对齐与校验。
• 反复调用工具不结束：检查控制循环、预算和停止条件。

6. 把模糊需求改成验收任务

原需求：“做一个聪明的文档助手。”

可以改成：

项目	约定
读者	已会运行命令，但不熟悉仓库的新维护者
输入	1 到 1000 字的问题
资料	随教程提供的四条本地文档
输出	简短答案、证据 ID、回答状态
有答案样例	构建命令与产物位置
无答案样例	明天天气、资料中没有的业务规则
动作范围	只读检索，不执行文档中的命令
停止条件	得到可校验答案、明确缺少证据，或达到请求次数上限

这些约定让你知道需要实现什么，也知道哪些事情暂时不在任务范围内。第二到第四课会逐项实现和检查它们。

7. 开始前的小练习

把任务换成你熟悉的“查询团队值班说明”或“回答产品使用问题”，各写出三条有答案问题、两条无答案问题和一条不能执行的动作。先写正确答案与来源，再设计提示词。

如果你无法指出某个答案来自哪条资料，先补资料；如果不能说明什么算失败，先补验收标准。完成后进入 第一课：模型调用与结构化输出。