第 14 章：为什么“一次生成”已经不够了？
约 903 字大约 3 分钟
在很多入门教程中，LLM 应用被简化为一个公式：
Prompt → LLM → Response
这个抽象在前几部分仍然成立，但一旦任务开始具备操作性（需要与外部系统交互、需要分步骤验证、需要动态调整策略，问题就出现了。
14.1 一个真实的企业场景
假设用户对企业知识库助手说：
“帮我确认一下，海外员工的差旅报销流程，现在是不是还需要主管审批？”
表面上看，这是一个 “问答”，但实际上包含了多个隐藏的操作需求：
- 查询最新制度：差旅报销流程可能在 3 个月前更新过，系统需要找到 2024 年版的《海外差旅管理规范》，而不是 2023 年的旧版本；
- 定位关键条款：在文档中找到 “审批环节” 的具体描述，确认是否包含 “主管审批” 这一项；
- 验证特殊情况：文档中可能注明 “金额超过 5000 美元需额外审批”，需要确认用户的问题是否涉及这类例外；
- 对比历史变更：如果旧流程需要主管审批，而新流程取消了，需要明确说明 “当前已不需要”，而不是沿用旧记忆；
- 处理不确定性：如果文档中没有明确说明，需要告知用户 “未找到明确条款，建议咨询行政部”，而不是编造答案。
这些步骤环环相扣，且每一步都依赖 “实际执行”（比如真实查询文档、验证版本）—— 模型不可能在 “一次生成” 中完成所有操作，更无法确保中间步骤的准确性。
14.2 技术决策点：我们要什么？
在这个阶段，系统设计者必须做出一个选择：
是让模型“假装想清楚了”，还是让系统真的一步一步做事？
如果继续依赖 “一次生成” 的模式，后果会很明显：
- 模型只能在 “脑内模拟” 查询、验证等步骤，但无法真正执行
- —— 比如它可能 “认为” 自己查了最新文档，但实际上用的是训练数据里的旧信息；
- 中间过程完全不可见，一旦出错无法追溯
- —— 如果回答错误，我们无法知道是 “查询步骤漏了” 还是 “理解条款错了”；
- 复杂任务会失控
- —— 比如当用户要求 “根据最新报销流程，帮我计算这笔海外差旅能报销多少” 时，模型可能会忽略汇率转换、发票类型等细节，直接给出错误结果。
这正是 Agent 出现的根本原因：当任务需要 “做” 而不只是 “说” 时，必须用可执行的步骤替代模型的 “脑内模拟”。
14.3 本章小结：任务复杂度发生了质变
简单来说，我们可以用一个标准判断是否需要升级系统：
- 若任务是问答（如 “报销标准是什么”）：一次生成可能足够；
- 若任务是操作（如 “确认报销流程是否需要主管审批”）：必须分步骤执行。
这引出了下一个问题：
如果要分步骤，模型如何与系统“对接”？
模型和外部工具（如文档检索系统、审批系统）之间，需要一个明确的 “对话接口”。这个接口，就是我们下一章要讨论的 Function Calling。
Loading...