考察点
这道题出自字节跳动大模型应用工程实习一面，是基础概念辨析题。面试官想筛掉把「调了工具就是 Agent」挂在嘴上的人——这两个概念一个在模型能力层、一个在系统架构层，混用说明对 Agent 的理解停留在演示级别。能讲出「Agent 可以不用 FC，FC 可以不在 Agent 里用」这两个反例，才算真正把边界划清了。追问会往 ReAct、Agent 的循环结构、不用 FC 怎么实现工具调用走。
参考答案
先各给一句准确定义
Function Calling 是模型的一种输出能力：给模型一组工具的 JSON Schema 描述，模型在需要时输出结构化的调用请求（工具名 + 参数），由外部代码执行。它是单次的、无状态的——模型不知道执行结果会怎样，也不决定下一步，它只负责「表达调用意图」。
Agent 是一个目标驱动的系统模式：模型在一个循环里反复「观察现状 → 规划下一步 → 执行动作 → 观察结果」，直到达成目标。它包含规划、工具使用、记忆、错误恢复等多个组件，是多步的、有状态的、有自主决策权的。
关键区分：能力 vs 系统
用一个类比讲最清楚：FC 是「会用手机打电话」这项能力，Agent 是「一个能自己查路线、订酒店、改行程的旅行规划师」。规划师要用到打电话这项能力，但会打电话不等于会规划旅行。
这个区分能推出两个重要的反例，也是面试的加分点：
- FC 可以脱离 Agent 使用。大量场景用 FC 只为拿结构化输出：从一句话里抽实体、把自然语言查询转成 SQL 参数、表单填充。模型调一次工具就结束，没有循环、没有自主性，这跟 Agent 毫无关系，但它是 FC 最高产的用法之一。
- Agent 可以不用 FC 实现。最早的 ReAct 就是纯 prompt 方案：模型按约定格式输出
Action: search[query]，框架用正则解析再执行。MCP 出现前的很多 Agent 框架都这么干。甚至可以用代码生成当行动空间（模型输出 Python 代码、沙箱执行），完全绕开 FC。
两者的真实关系：FC 是 Agent 工具交互层的最优实现
虽然概念上独立，但工程上 FC 已经成为 Agent 调工具的主流机制，原因很实际：
- 可靠性：正则解析自由文本格式，模型输出稍微走样就解析失败；FC 的输出受 schema 约束，成功率高一截。
- 训练加持：主流模型在训练时专门优化过 tool calling，工具选择、参数填写的质量比纯 prompt 引导好。
- 标准化：schema 描述工具、tool_calls 表达意图、tool role 回传结果，这套交互格式已经成了各家 API 的通用约定，框架可以直接围绕它建。
所以准确的说法是：Agent 需要「某种」工具调用机制，FC 是目前最好的那种。FC 提供的是 Agent 四肢的接口标准，而 Agent 的大脑——规划、反思、记忆——在 FC 的能力范围之外。
容易混淆的第三个概念：Workflow
顺带把边界划全。Workflow 里步骤和分支是开发者预先编排好的，模型只在个别节点做判断；Agent 是模型自己决定下一步走哪。FC 在两者里都能用——它只是节点内的一个调用机制。判断一个系统是不是 Agent，看的是「下一步谁说了算」，不是看「有没有调工具」。
可能的追问
1. 不用 FC 的 Agent 有什么实际劣势？
解析脆（输出格式漂移就断链）、训练信号缺（模型没专门学过工具用法）、多工具并行表达困难。除非模型本身不支持 tool calling，否则没有选纯文本解析的理由。
2. 模型输出的 tool_calls 由谁执行？
永远是调用方代码，模型从不执行。这个边界决定了所有安全设计：参数校验、权限控制、审计都在执行侧做，因为模型输出本质是不可信的意图表达。
3. 什么时候不该把系统做成 Agent？
步骤可枚举、分支有限的任务（审批流、固定数据管道）用 Workflow 更稳更快更便宜；Agent 留给步骤组合空间大、需要临场判断的开放任务。