一、LLM 的边界为什么它不能直接完成复杂任务一个场景用户说“帮我生成一份 Java 简历。”如果直接丢给 LLM它会生成一份“看起来不错”的简历——但很可能是凭空捏造的。LLM 没有用户的真实经历不知道目标岗位的具体要求也无法调用外部工具去搜索、匹配、排版。真正需要的执行流程用户输入 → 理解意图 → 收集 JD需要用户上传或描述 → 解析 JD提取技术要求 → 收集简历需要用户提供 → 解析简历提取技能、经历 → 匹配排序精确对比 JD 和简历 → 重写优化 → 生成 PDFLLM 能完成其中的“理解意图”“解析 JD”“重写优化”——这些属于语言理解与生成。但它做不了获取外部信息搜索、读文件精确计算打分排序执行动作调用 API、生成 PDF多步循环根据中间结果调整策略LLM vs Agent 本质区别LLMAgent只能“回答”可以“行动”被动的单次生成主动的循环执行不知道的只能编不知道的可以去查输出文本调用工具 输出文本Agent LLM 规划能力 工具调用 记忆 反思LLM 是一个“思考器官”Agent 是一个“完整的执行者”。二、 Tool工具Tool 的准确定义Tool 是 LLM 不具备的能力的外部扩展。它让 Agent 能够“做事情”而不只是“说事情”。为什么 LLM 需要 Tool精确计算LLM 擅长语言概率不擅长数学规则实时信息LLM 的知识有截止日期执行操作LLM 不能调 API、读写文件、操作数据库Tool ≠ 函数“Tool 就是函数”——这个理解不完整。判断标准Tool 是一个可以被调用来完成具体任务的能力单元有明确的输入输出。三、Function Calling为什么比 ReAct 稳定以前的做法ReAct让 LLM 在输出文本中嵌入特殊标记Action: Calculator Action Input: 123 * 456然后用代码解析文本提取出工具名和参数。问题格式不稳定多一个空格或换行就可能解析失败依赖正则匹配复杂场景容易出错Function Calling 的做法LLM直接输出结构化 JSON{name:calculator,parameters:{expression:123 * 456}}为什么更稳定结构化输出JSON 格式确定不会因文本差异解析失败Schema 约束可以预定义参数类型、必填项LLM 被训练去遵守这些约束训练有素现代 LLM 在训练阶段已学过 Function Calling四、Tool Calling 全过程——Agent 的核心循环所有 Agent 的通用骨架用户输入 → ① LLM 分析需要调用什么工具 → ② 决定调用 Tool → ③ 执行 Tool → 得到 Observation观察结果 → ④ Observation 返回给 LLM → ⑤ LLM 判断任务完成了吗还需要再调工具吗 → ⑥ 如需要回到②如完成生成最终回答Observation 是什么为什么一定要回传 LLMObservation Tool 执行后返回的原始结果。比如计算器 Tool →56088检索 Tool →[简历段落1, 简历段落2]为什么不能直接返回给用户用户问“我的简历匹配吗” → Agent 调检索 Tool 拿到一堆文本片段 →如果直接返回用户看到的是碎片数据不是答案。正确做法Observation 回传给 LLM → LLM 阅读并理解 → 生成自然语言回答“您的简历在 Java 方面匹配度很高但在微服务经验上有所欠缺……”Observation 必须回传 LLM 的三个原因LLM 是唯一的“理解者”和“表达者”LLM 需要判断任务是否完成LLM 需要整合多步 Observation 生成完整答案
