“少样本提示Few-shot Prompting”是一种提示词工程方法不训练模型而是在提示词里给几个例子让模型照着例子理解任务并输出结果。它和大模型常见的零样本Zero-shot、多样本Few-shot、全量微调Fine-tuning相对。一、先直观理解“少样本”假设你想让模型做“情感分类”。1. 零样本提示请判断下面这句话的情感是积极还是消极“这部电影太无聊了。”你只给了任务说明没给例子。2. 少样本提示请判断下面这句话的情感是积极还是消极。例子“今天天气真好。” - 积极“我讨厌等待。” - 消极“这个功能太好用了。” - 积极现在请判断“这部电影太无聊了。” - ?你给了 3 个例子模型就能更容易理解输入是什么输出应该是什么格式“积极 / 消极”的判断标准大概是什么最后应该输出成什么样子这就是Few-shot Prompting。二、“少样本”的“少”是多少Few-shot 通常指给模型2 到 10 个左右例子。具体数量没有绝对标准一般看任务复杂度任务复杂度常见例子数简单分类23 个格式抽取35 个复杂推理510 个非常稳定的规则有时 0 个也可以例子不是越多越好。例子太多会增加输入长度提高成本增加噪声有时反而让模型被错误例子带偏所以 Few-shot 的重点不是“堆例子”而是用少量高质量例子把任务规则说清楚。三、Few-shot 的本质Few-shot 并不是真的让模型“训练”出这个任务。它更像是在提示词里给了模型一个临时参考样例。模型会根据这些例子推断“哦原来用户想要这种输出方式。”“原来这个任务要按这种格式回答。”“原来这里的判断标准是这样的。”所以 Few-shot 的核心作用是降低理解偏差统一输出格式补充隐含规则增强稳定性减少模型自由发挥四、和 Zero-shot、Fine-tuning 的对比1. Zero-shot零样本不例子只说明任务。例如请将这句话翻译成英文。适合模型本身已经很熟悉的基础任务。2. Few-shot少样本给几个例子让模型模仿。例如请将中文翻译成英文。例子你好 - Hello谢谢 - Thank you今天天气不错 - The weather is nice today请翻译我喜欢编程适合输出格式有要求任务规则不太常见希望模型稳定输出不想到达模型3. Fine-tuning微调用大量数据继续训练模型。例如1000 条客服问答10000 条代码修复样本50000 条法律合同摘要样本适合任务非常固定数据充足对效果要求很高愿意投入训练成本一句话对比方法是否训练模型是否给例子成本适合场景Zero-shot否否低简单、通用任务Few-shot否是少量中格式控制、规则说明Fine-tuning是是大量高专业、稳定、高要求任务五、Few-shot 的核心价值1. 告诉模型“该输出什么格式”比如你想让模型输出 JSON请从用户文本中提取姓名、年龄、城市输出 JSON。例子输入我叫张三今年 25 岁住在北京。输出{name:张三,age:25,city:北京}输入我是李四30 岁在上海工作。输出{name:李四,age:30,city:上海}输入王五是 18 岁广州人。输出这样模型就很清楚要输出标准 JSON而不是自然语言。2. 告诉模型“隐含规则是什么”例如做意图分类请判断用户消息属于以下哪种意图查询天气、查询订单、投诉、闲聊。例子“明天北京下雨吗” - 查询天气“我的快递到哪了” - 查询订单“你们服务态度太差了” - 投诉“今天好无聊啊。” - 闲聊如果没有例子模型可能会把“快递怎么还没来”判成“查询订单”或“投诉”边界不清楚。例子可以把边界定得更稳。3. 告诉模型“不要乱发挥”比如你要求只输出一个标签只输出积极 / 消极 / 中性例子今天真好 - 积极太烦了 - 消极我出门了 - 中性这样模型就不容易输出“这句话整体偏消极因为……”Few-shot 对“输出约束”非常有用。六、Few-shot 在 Agent 工具选择中的作用这部分是重点。Agent 经常不是只回答一句话而是要决定我现在应该调用哪个工具应该传什么参数还是不该调用工具只回答用户还是应该先问用户要更多信息也就是说Agent 要做工具选择Tool Selection。比如用户说“帮我看一下puzzle_game.py有没有空值崩溃风险。”Agent 可能面临这些工具read_file读取文件grep搜索代码run_tests运行测试search_web搜索网络ask_user询问用户Agent 要决定第一步该用什么。这时 Few-shot 就可以发挥作用。七、Agent 工具选择任务中Few-shot 是怎么用的1. 给模型看“历史上怎么做对的”你可以在 Agent 的系统提示词里放几个工具调用例子。例如你是代码分析 Agent。当用户要求分析某个文件时优先使用read_file。当用户要求在代码库中查找关键词时优先使用grep。当用户要求运行验证时使用run_tests。当用户信息不足时使用ask_user。例子用户帮我看一下main.py的逻辑。正确工具read_file用户代码里哪里用了score变量正确工具grep用户修完后帮我跑一下测试。正确工具run_tests用户帮我修一下登录问题。当前只知道错误现象不知道文件位置。正确工具ask_user这样模型就知道不同请求对应不同工具信息不足时不能乱调用应该优先选择更直接的工具什么时候要问用户这就是 Few-shot 在工具选择里的作用。八、Few-shot 可以帮 Agent 解决什么问题1. 防止选错工具比如你有两个工具read_file读取单个文件grep全局搜索内容用户问“这个报错可能在哪个文件里”这时更合理的是grep而不是随便read_file。如果 Agent 提示词里给了例子用户哪里调用了save_score工具grep用户帮我打开puzzle_game.py看一下。工具read_file模型就更容易学会不知道位置时先搜索知道文件位置时再读取。2. 防止过度调用工具Agent 常见问题是用户只是问概念它也去调用工具。例如用户什么是缓存其实不需要调用任何工具。可以用 Few-shot 明确用户什么是 Redis工具无用户帮我看一下当前项目的 Redis 配置。工具grep这样模型会知道纯知识问题可以直接回答涉及当前项目或外部资源才调用工具。3. 统一工具调用格式Agent 通常要求模型输出 JSON 或特定结构。例如{tool:read_file,arguments:{path:puzzle_game.py}}Few-shot 可以帮模型稳定输出这种格式。示例用户看一下puzzle_game.py。输出{tool:read_file,arguments:{path:puzzle_game.py}}用户搜索一下save_score被哪里调用。输出{tool:grep,arguments:{pattern:save_score}}这比只说“请输出 JSON”更稳。4. 让 Agent 学会“何时问用户”Agent 最容易翻车的地方之一是信息不足时硬猜。Few-shot 可以明确边界。例如用户帮我修一下那个 bug。工具ask_user原因用户没有提供文件、报错日志或错误现象。用户运行失败报错KeyError: score文件是puzzle_game.py。工具read_file原因文件明确先读取文件定位问题。这样 Agent 就更容易学会信息足够就行动信息不足就提问。这对工具选择非常重要。5. 让 Agent 学会“先查后改”在代码修改类 Agent 中经常要求不能直接改文件必须先读取或搜索。Few-shot 可以强化这个流程。例如用户把puzzle_game.py里的分数逻辑改成最大值。第一步工具read_file原因先了解当前实现。用户为什么score可能为空第一步工具grep原因先查找score的定义和使用位置。这样 Agent 更容易形成稳定工作流搜索 / 读取 → 分析 → 修改 → 测试而不是上来就改。九、一个具体例子代码分析 Agent假设 Agent 有这些工具{tools:[{name:read_file,description:读取指定文件内容},{name:grep,description:在项目中搜索代码片段},{name:run_tests,description:运行项目测试},{name:ask_user,description:向用户询问缺失信息}]}如果没有 Few-shot你只写请选择合适的工具。模型可能会选错。如果加上 Few-shot用户帮我看一下 puzzle_game.py 的主循环。 输出 { tool: read_file, arguments: { path: puzzle_game.py } } 用户代码里哪里用了 _flash 输出 { tool: grep, arguments: { pattern: _flash } } 用户修复后帮我验证一下。 输出 { tool: run_tests, arguments: {} } 用户帮我修一下 bug。 输出 { tool: ask_user, arguments: { question: 请提供报错日志、相关文件路径或具体错误现象。 } }这样模型就会更容易按你的意图选择工具。十、Few-shot 在 Agent 工具选择中的核心逻辑可以总结成一句话Few-shot 通过给 Agent 看“类似请求应该选什么工具”的样例让模型学会从自然语言请求到工具调用的映射关系。也就是说它教 Agent 的不是某个具体答案而是哪类问题对应哪类工具什么时候该调用什么时候不该调用参数应该怎么填输出应该是什么格式信息不足时怎么办十一、Few-shot 工具选择的常见写法1. 按任务类型给例子用户读一下 config.py 工具read_file 用户查找 timeout 在哪里配置 工具grep 用户运行项目测试 工具run_tests 用户你建议怎么优化架构 工具无直接回答2. 按信息完整度给例子用户帮我修复 bug 工具ask_user 原因缺少文件路径和错误信息 用户帮我修复 puzzle_game.py 里的 KeyError 工具read_file 原因文件明确先读取定位3. 按执行顺序给例子用户把 puzzle_game.py 的保存功能改成 JSON 第一步read_file 第二步修改代码 第三步run_tests这能帮助 Agent 学会任务拆解。4. 按“禁止行为”给例子用户帮我把数据库清空 错误工具execute_sql 正确动作ask_user / 拒绝执行 原因高风险操作需要确认这类例子能增强安全边界。十二、Few-shot 在 Agent 中的优势1. 不需要训练不用微调模型只要改提示词即可。2. 修改成本低工具变了例子改一下就行。比如新增一个list_files工具就可以加一条用户当前目录有哪些文件工具list_files3. 可解释性强Agent 为什么选这个工具你可以从提示词和例子中看出来。这比黑盒模型更便于调试。4. 能快速约束行为比如你发现 Agent 老是直接grep但其实应该先ask_user。你可以加例子用户帮我修一下问题。工具ask_user这样能马上调整行为。5. 对工具数量多的场景特别有用Agent 工具越多模型越容易混淆。比如你有search_docssearch_coderead_filelist_filesrun_commandcreate_fileupdate_filedelete_file这些工具之间有细微差别。Few-shot 能帮模型理解边界。十三、Few-shot 的局限虽然 Few-shot 很实用但它不是万能的。1. 例子多了会变长Agent 系统提示词本身已经包含角色说明工具列表权限规则输出格式历史消息如果再加太多 Few-shot会占用上下文窗口。2. 例子质量很重要错误例子会教坏模型。例如你给用户帮我看一下配置。工具run_tests那模型可能学到“看配置也要跑测试”这就错了。所以 Few-shot 的关键是样例必须正确、简洁、有代表性。3. 不能覆盖所有情况Agent 面对的真实用户请求非常多样。Few-shot 只能覆盖典型路径不能保证所有边缘情况都正确。所以实际 Agent 里通常要结合工具描述系统规则Few-shot 例子输出格式约束后置校验失败重试机制4. 工具很多时 Few-shot 可能不够如果 Agent 有几十上百个工具光靠 Few-shot 不一定够。这时通常会引入工具检索先根据用户请求筛选相关工具工具分组把工具分成开发、搜索、文件、数据库等类别路由模型先用一个小模型判断应该用哪组工具多轮规划Agent 自己分解任务再逐步选择工具十四、Few-shot 和工具描述的关系很多 Agent 开发新手会以为只要工具描述写清楚模型就会自动选对。其实不一定。工具描述解决的是这个工具是干什么的Few-shot 解决的是遇到某类请求时应该优先用哪个工具两者是互补的。举例对比工具描述read_file: 读取文件内容。 grep: 在代码库中搜索内容。如果用户说“哪里调用了 save_score”模型可能知道grep是搜索但如果没有例子它可能还会犹豫是否先读取文件是否搜索所有文件是否只搜索puzzle_game.py加入 Few-shot用户哪里调用了 save_score 工具grep 参数{ pattern: save_score }模型就更清楚这是跨位置查找应该用 grep。所以工具描述告诉 Agent “有什么工具”Few-shot 告诉 Agent “这类场景优先用哪个工具”。十五、一个完整的小例子假设我们要做一个“文件管理 Agent”工具如下{tools:[{name:list_files,description:列出目录下的文件},{name:read_file,description:读取指定文件},{name:find_files,description:按名称或扩展名查找文件},{name:ask_user,description:向用户询问缺失信息}]}Few-shot 提示词可以这样写你是文件管理 Agent。请根据用户请求选择最合适的工具并输出 JSON。 例子 用户当前目录有哪些文件 输出 { tool: list_files, arguments: { path: . } } 用户帮我打开 puzzle_game.py 输出 { tool: read_file, arguments: { path: puzzle_game.py } } 用户帮我找一下所有 csv 文件 输出 { tool: find_files, arguments: { pattern: *.csv } } 用户帮我打开那个文件 输出 { tool: ask_user, arguments: { question: 请提供具体文件路径。 } }现在用户输入帮我找一下项目里的 prices.csv模型就容易输出{tool:find_files,arguments:{pattern:prices.csv}}这就是 Few-shot 在 Agent 工具选择中的典型应用。十六、Few-shot 在 Agent 工具选择中的作用总结可以总结为五点建立“请求 → 工具”的映射让用户请求和工具选择之间形成稳定对应关系。规范输出格式让 Agent 稳定输出 JSON、参数名、工具名。降低工具误用概率让 Agent 知道什么时候读文件、什么时候搜索、什么时候问用户。明确边界条件让 Agent 知道信息不足时不要硬猜应该询问或拒绝。增强任务流程感让 Agent 学会先搜索、再读取、再修改、再验证。十七、一句话总结Few-shot 提示是通过给模型少量例子让模型理解任务规则、输出格式和执行方式。在 Agent 的工具选择任务中Few-shot 的核心作用是通过样例告诉 Agent遇到这类用户请求时应该选择哪个工具、传什么参数、什么时候不要调用工具、什么时候应该先问用户。所以Few-shot 不是简单的“给例子”而是 Agent 系统中一种非常重要的行为约束和工具路由训练方式。