Token（词元）、Skill、Agent、RAG 一次讲透：定义、能力边界与落地结果

很多团队在做 AI 应用时，最容易卡住的不是代码，而是概念混用：Token 当字数算、Skill 当插件堆、Agent 当聊天壳、RAG 当向量库同义词。本文把这 4 个高频名词拆开讲清：是什么、能干吗、产出结果怎么验。你可以直接复制文中的命令和最小配置，今天就能做一版可测的知识问答 Agent。

场景引入：为什么你总感觉“都懂了但做不出来”

最近高热讨论里有两个很典型的分歧：

• 一派说“长上下文够大，RAG 已经过时”。
• 一派说“没有 RAG，Agent 一上生产就会胡说”。

争议背后本质是边界不清：

• Token 决定成本与上下文预算。
• Skill 决定模型可调用的动作边界。
• Agent 决定任务编排和自主程度。
• RAG 决定知识是否可追溯、可更新、可隔离。

下面按工程落地顺序讲。

一、Token（词元）：它不是“字数”，是模型算账和算力调度的基本单位

问题现象

同一段中文，进不同模型后 token 数差别明显，账单和延迟也跟着波动。很多人只看“字数”，结果预算总是超。

根因分析

Token（词元） 是模型内部处理文本的最小切分单位，不等于一个字，也不等于一个词。空格、标点、大小写、词片都会影响 token 数。计费通常按 input/output/cached 等类别统计。

解决步骤

先做“调用前估算 + 调用后核对”：

# 1) 安装 tiktoken
pip install tiktoken

import tiktoken

text = "请总结这段文档并列出 3 条行动建议。"
enc = tiktoken.get_encoding("cl100k_base")
print("token_count=", len(enc.encode(text)))

关键参数说明：

• max_output_tokens：限制输出上限，防止一次回答打爆预算。
• temperature：越高越发散，通常也更容易拉长回答。

验证方式

连续发 20 条同类型请求，对比两组数据：

• 组 A 不限 max_output_tokens。
• 组 B 把 max_output_tokens 固定为 512。

若组 B 的 P95 成本和延迟显著收敛，你的 token 预算控制就生效了。

二、Skill：它不是“功能列表”，而是可复用、可编排、可控风险的能力单元

问题现象

不少项目把几十个工具一次性挂给模型，最后出现“乱调工具、误调用、回包结构不稳”。

根因分析

Skill 的本质是“语义清楚的函数集合”。它必须让模型知道三件事：

• 什么时候用。
• 用哪个参数。
• 返回结构怎么读。

如果函数名、参数名、描述含糊，模型就会误判。

解决步骤

先把 Skill 做小、做清晰，再逐步扩展：

{
  "name": "search_docs",
  "description": "在内部知识库检索与问题最相关的文档片段",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {"type": "string", "description": "用户问题或关键词"},
      "top_k": {"type": "integer", "description": "返回片段数量，建议 3-8"}
    },
    "required": ["query"]
  }
}

关键参数说明：

• top_k：RAG 中常用检索数。太小会漏信息，太大会塞爆上下文。

验证方式

做一组 50 条问题回放，统计：

• 工具命中率（该调时是否调用）。
• 参数正确率（字段完整、类型正确）。
• 回答可引用率（是否引用到检索片段）。

这三项一起看，才能判断 Skill 是否可上生产。

三、Agent：它不是“聊天机器人”，是一个带循环控制的任务执行器

问题现象

同样是“帮我查资料并输出结论”，普通聊天一次答完但经常漏步骤；Agent 版本会多轮检索、调用工具、修正答案。

根因分析

Agent 常见运行环是 Thought -> Action -> Observation（想 -> 做 -> 观测）。它会根据工具回包继续下一步，而不是只靠一次生成。

解决步骤

先上最小可控循环，再谈复杂自治：

1. 读取用户目标
2. 选择 skill（例如 search_docs）
3. 执行检索
4. 根据返回片段生成答案
5. 若证据不足则再次检索
6. 达到停止条件后输出

关键参数说明：

• max_iterations：限制最大迭代轮次，避免死循环和失控成本。

验证方式

给 Agent 设两条硬门槛：

• 必须给出处或片段编号。
• 超过 max_iterations 必须停止并返回“信息不足”。

能稳定命中这两条，才算具备基础可控性。

四、RAG：它不是“上了向量库就完事”，而是检索增强的完整链路

问题现象

最常见误区是“只做 embedding + 相似度搜索”，上线后仍然答非所问，或者引用过时内容。

根因分析

RAG 至少包含四步：Ingestion、Retrieval、Augmentation、Generation。缺任何一步质量控制，最终答案都会漂。

解决步骤

最小可跑链路可以按这个顺序搭：

# 1) 文档切块
# 2) 向量化入库
# 3) 查询时 top_k 检索
# 4) 拼接上下文并要求“无依据就回答不知道”

可直接使用的提示模板：

QUESTION:
{{user_question}}

CONTEXT:
{{retrieved_chunks}}

请只基于 CONTEXT 回答。若 CONTEXT 无答案，直接回复“我不知道”。

验证方式

准备 30 条带标准答案的问题集，记录 3 个指标：

• 命中率：是否检索到相关片段。
• 真实性：回答是否被片段支撑。
• 拒答率：无依据时是否正确拒答。

这三个指标比“主观感觉回答不错”可靠得多。

常见报错与处理建议

• 报错：context_length_exceeded 处理：减小 top_k、压缩 chunk、下调 max_output_tokens。
• 报错：tool arguments invalid 处理：给参数加 schema 和必填约束，减少可选歧义字段。
• 报错：rate limit exceeded 处理：加重试与退避，拆高峰流量，缓存高频问题结果。

常见坑（至少先避开这 3 个）

• 把 Token 当字数做预算，导致成本和延迟持续失真。
• 一次塞太多 Skill，模型选错工具概率上升。
• RAG 只看召回不做评测，结果“看起来能答，实际上不可信”。

快速自检清单

• 是否有请求级 token 统计与告警阈值。
• 是否限制了 max_output_tokens 和 max_iterations。
• Skill 是否有清晰 description 与参数 schema。
• RAG 是否有标准问题集与离线评测脚本。
• 回答是否强制带证据片段或来源标记。

今天就能做的下一步

1. 先做一个 20 条问题的小评测集，别先追求大而全。
2. 把 search_docs 作为唯一 skill 跑通，再加第二个 skill。
3. 给 Agent 加 max_iterations=6 和超时停止条件，先把稳定性立住。

一句话总结：Token 管预算，Skill 管动作，Agent 管流程，RAG 管事实。四者不是替代关系，而是分层协作关系。

当你把边界画清楚，系统就会从“会演示”变成“可复现、可评测、可上线”。先小步跑通，再按指标扩展，是这类系统最稳的做法。

关注 【iDao技术魔方】，获取更多全栈到AI可落地的实战干货。