考察点
这是 Agent 面试的开场题，几乎必问，而且常带追问「你们项目里用的是 LLM 直接调用还是 Agent？为什么这么选？」。面试官想看你是否真的在生产环境做过权衡，而不是背概念。核心考察点：能不能讲清楚 LLM 是「函数」、Agent 是「系统」这个本质区别，以及选型的判断标准。
参考答案
一句话区别
LLM 本质上是一个无状态的函数：输入一段文本，输出一段文本，调用结束它就「忘了」一切。Agent 是一个系统：以 LLM 为决策核心，外围加上工具调用、记忆、规划、循环控制，能对着一个目标连续做多步动作，直到任务完成或触达终止条件。用工程语言说：LLM 是 stateless 的推理引擎，Agent 是包着这个引擎的 event loop。
Agent 比 LLM 多了什么
拆开看，一个最小可用的 Agent 比裸 LLM 多四样东西：
- 工具（Tools）：Function Call、MCP 接入的搜索、数据库、代码执行器。LLM 只会「说」，工具让它能「做」。
- 记忆（Memory）：短期记忆是对话历史和中间步骤的 observation，长期记忆是跨会话的向量库或 KV 存储。裸 LLM 每次调用都是一张白纸。
- 规划（Planning）：把目标拆成步骤的能力，可以是 ReAct 式的边想边做，也可以是 Plan-and-Execute 式的先规划后执行。
- 循环与终止控制（Loop）：这是最容易被忽略、但工程上最关键的一层。Agent 不是一次调用，而是
while not done: think → act → observe的循环，必须有最大步数、超时、成本上限这些刹车。
项目里怎么选
我自己的判断标准有三条，按顺序过一遍：
- 步骤数是否固定。如果流程能画成一张静态的 DAG——比如「检索 → 重排 → 生成」的 RAG 问答——直接 LLM 调用或者 Workflow 就够了，上 Agent 是给自己找麻烦。
- 下一步是否依赖上一步的结果。比如「查到这个接口返回 404，接下来该试备用接口还是问用户」，这种决策点在写代码时枚举不完，才需要 LLM 在运行时自己判断，这是 Agent 的主场。
- 出错代价是否可控。Agent 的自主性是用不确定性换来的。自动订机票这种错了要赔钱的场景，就算技术上能用 Agent，我也会收敛成人审 + Workflow。
举个实际例子：我做过一个运维诊断功能，告警进来后 Agent 自己决定查日志、看监控曲线、翻变更记录，最后给出根因分析。这个场景步骤不可预知、每步都依赖上一步发现，用 Agent 是对的。但同一个系统里的「告警摘要生成」，就是一次 LLM 调用，没必要套 Agent 壳子。
再补一个容易忽视的成本视角：一次 LLM 调用的 token 消耗是固定的、可预算的；Agent 的消耗是「每步一次全量上下文调用 × 随机步数」，同一个任务这次跑 4 步下次跑 9 步，账单和延迟都带方差。对 SLA 有承诺的在线服务，这个方差本身就是一票否决项，跟准确率无关。
别把 Agent 当银弹
Anthropic 的工程博客说得很直白：能不用 Agent 就不用，能用单次 LLM 调用解决的问题就别加循环。Agent 的成本不只是 token 贵了几倍，更难的是调试——LLM 直接调用的 bug 是可复现的，Agent 的 bug 经常跑到第七步才出现，前面六步的上下文都是「案发现场」，没有 trace 系统根本查不动。所以我在项目里的默认姿势是：先 Workflow，Workflow 里某个节点的分支逻辑复杂到 if-else 写不下去，再把那一个节点换成 Agent。
可能的追问
- 「Agent 比 LLM 多了什么，让你从零设计一个 Agent 你会怎么做？」 按「循环骨架 → 工具协议 → 记忆 → 终止条件」的顺序答，先写一个 50 行的 ReAct 循环说清楚最小闭环，再谈怎么加护栏。
- 「LLM 的天花板是什么？」 顺着区别讲：无记忆、知识截止、不能行动、不会主动规划，Agent 的四个组件正好一一对应补这四个洞。
- 「你们为什么不用 Agent？」 反着答也是加分项：流程固定、要可审计、延迟敏感，Workflow 更稳——说明你知道 Agent 的代价。