Agent和LLM的区别

很多人第一次做 AI 功能时会卡在一个问题上：我到底是在调一个大模型，还是在做一个 Agent？把这两件事混在一起，就会出现「以为加了工具调用就是 Agent」「以为换个更强的模型就能自动干活」这类误判。这篇不谈协议兼容也不谈客户端配置，只从职责边界、控制权归属、工程成本三方面把区别讲清楚，并给一套判断顺序和落地清单。

很多人第一次做 AI 功能时会卡在一个问题上：我到底是在调一个大模型，还是在做一个 Agent？把这两件事混在一起，就会出现「以为加了工具调用就是 Agent」「以为换个更强的模型就能自动干活」这类误判。这两者的差别不在模型能力上，而在你代码里那一圈控制逻辑上。

这篇不谈协议兼容也不谈客户端配置，只从职责边界、控制权归属、工程成本三方面把区别讲清楚，并给一套判断顺序和落地清单。看完你应该能做两件事：说清自己现在写的是哪一层，以及在动手前判断这一步到底该不该加循环。

先分清：你调的是一个函数，还是一个循环

大模型最朴素的用法就是单次请求、单次响应：你给一段上下文，它返回文本或者结构化结果，请求结束就结束。这个过程里没有状态，没有下一步，调用方拿到结果之后由自己的代码决定接下来干什么。哪怕你把请求包在一个函数里、加了重试、加了结果校验，本质上还是「一次调用」。

Agent 不一样，它是在大模型外面套了一圈控制逻辑：决定下一步做什么、调什么工具、拿到结果之后要不要再调、什么时候该停。这圈逻辑可能是几十行的状态机，也可能是一整套编排框架，但判断标准只有一条——谁在决定「下一步」。

单次调用

给上下文，拿输出，流程结束；后续动作由你的业务代码写死

Agent 循环

由模型输出下一步动作，代码执行后再把结果喂回去，直到满足停止条件

判断口诀

谁决定「下一步」，谁就是 Agent 的那一部分

控制权在谁手里：一次调用还是多轮决策

LLM 场景下控制权基本在调用方代码里，模型只负责生成内容。你可以预测它一次调用大致消耗多少、花多少时间，因为就那么一次。Agent 场景下控制权被部分让渡给模型，由它自己选工具、排顺序、判断是否继续。控制权交出去不是免费的，它换来的是灵活性，代价是不确定性和工程复杂度。

把循环交出去之后，有两样东西必须补上，否则线上会出问题：一是步数上限，防止模型陷入反复调用同一个工具的死循环；二是失败兜底，某一步超时或者返回异常时，整条链路要能干净地退出并保留现场，而不是把错误状态带到下一步。

• 设定最大决策轮数，超了就中断并返回当前已有结果
• 给每类工具设独立超时，不要让一个慢接口拖垮整轮
• 任何一步失败都要记录输入、输出与决策依据，方便复盘
• 对幂等性没有把握的工具不要放进循环里自动调用

职责怎么切：模型负责判断，工程负责约束

一个常见的误会是把边界交给提示词。提示词能影响模型的倾向，但约束不住行为，因为模型不执行权限校验，也不会真的阻止越界调用。真正能约束边界的只有代码层：白名单、参数校验、幂等控制、超时和成本上限，这些必须在模型之外写死。

反过来，模型擅长的部分也别用代码硬扛。语义理解、模糊匹配、从一段自然语言里抽出候选动作，这些用规则写会又长又脆。合理的分工是：模型负责判断和生成候选，工程负责在候选执行前做校验和拦截。

有工具调用不等于有 Agent

现在很多模型都支持工具调用，于是很容易得出一个结论：我接了工具，我这就是 Agent 了。其实不一定。如果你的流程是固定的——先查天气、再查库存、最后拼一段话——模型只是其中一个节点，调哪个工具、按什么顺序调都是你代码写死的，那这就是流程编排，跟 Agent 没什么关系。

分界线不是工具的数量，而是决策是否动态。只有当「调哪个工具、调几次、失败之后是换工具还是重试还是放弃」这些判断由模型在运行时给出时，才更接近 Agent。这个判断标准对两种场景都成立：工具只有一个，也可能构成 Agent；工具一堆，也可能是纯流程。

1. 数一数决策点把流程里所有「根据情况选择」的地方列出来，看每一个是你写死的还是模型决定的
2. 拿掉模型试一次把模型替换成一个返回固定动作的桩函数，流程能不能跑完；能跑完说明决策本来就在代码里
3. 看失败分支检查工具调用失败后的处理写在业务代码里还是模型的选择里，写在代码里通常不算 Agent

成本与延迟结构完全不同

单次调用的账单很好估：输入加输出大致多少 token，换算成钱和延迟都是线性的。Agent 不是，它的步数不定，token 随轮次累积——每一轮都要把前面的历史再发一遍，所以总消耗往往远高于把这几轮拆开单算之和。延迟也是叠加的，用户等的是整条链路跑完的时间。

上线前先按最坏情况算一遍：假设模型用满步数上限、每步都调一次最贵的工具，这一轮任务要花多少、要等多久。如果这个数字你接受不了，就得回头砍步数上限或者收窄工具范围。各家模型与当前价格不要凭印象，到站内 /official-api 与 /price-watch 核对当时的数字，尤其注意是否有输入输出分别计价。

• 按最坏步数估算单任务开销，而不是按平均步数
• 监控每轮累积的上下文长度，必要时对历史做裁剪或摘要
• 给单任务设成本与时间预算，超预算直接中断而不是硬跑完
• 把每步的耗时和 token 消耗打进日志，否则优化无从下手

什么情况下不该上 Agent

不是所有任务都值得加循环。如果步骤固定、输入格式稳定、出错代价还高，那么固定流程加一次模型调用通常更稳、更快、更便宜。Agent 的价值在于处理那些路径本身就不确定的开放任务，一旦路径是确定的，把决策权交出去只会引入没必要的波动。

另外几种情况也要谨慎：并发量高但人工审核跟不上的，别急着把循环放出去，因为出问题时你来不及拦；需要对外承诺确定时延的接口，Agent 的步数不定天然不适合放在同步链路上；团队还没做过日志回放和评测的，先把单次调用跑稳再考虑加循环。

从单次调用演进到 Agent 的落地清单

如果你判断确实需要往 Agent 方向走，别一步到位重构，按下面这个顺序推。每一步都有明确的完成标准，前一步不达标就不要急着做下一步，否则问题会互相掩盖，最后连是哪一层出的错都说不清。

1. 把输出改成结构化先保证模型输出能被下游稳定解析，字段缺失或格式错乱时要有明确的失败信号，而不是靠字符串截取硬凑；相关技巧可以在 /ai-dict/category/tips 里找。
2. 封装工具接口把要用的能力逐个包成独立接口，每个接口都能单独调用、幂等重试、有明确错误码；验证方式是脱开模型直接调一遍，看结果是否符合预期。
3. 加上三道闸步数上限、工具白名单、单任务的成本与时间预算。验证方式是故意让模型给出超范围动作，看代码能不能拦住。
4. 打通日志回放把每一步的输入、输出、决策依据都记下来，保证任意一次失败都能重放复盘。验证方式是随便挑一次历史任务，看能不能完整还原当时的决策路径。
5. 小样本评测后放开先在一个小规模评测集上跑通，观察成功率与异常分布，再逐步放开并发；评测口径可以参考 /benchmarks 里的方法。

这套顺序里最容易被跳过的是第四步日志回放。很多团队等到线上出问题才发现，Agent 的失败不像单次调用那样一眼能看出来，往往是一连串看起来都合理的选择叠加出的结果，没有完整日志根本定位不了。

评审时怎么一句话说清你在做哪一层

评审或者汇报的时候，与其争论「这算不算 Agent」，不如用几个可检查的信号直接说清自己在做哪一层。这样别人也能立刻知道该关注什么风险，而不是听完一段架构描述还是没抓到重点。

• 看代码里有没有循环加状态：没有 while 或者等价的迭代结构，就是单次调用
• 看失败处理归谁：重试和兜底写在业务代码里，说明决策权还在你手上
• 看变更影响面：改提示词影响的是输出质量，改工具集会直接改变行为路径
• 看成本模型：能提前给出单任务预算的是单次调用，需要按最坏步数估算是 Agent

最后补一句判断上的提醒：这条线不是非黑即白。现实里的系统常常是混合的——主链路是固定流程，其中一两个环节允许模型动态选择下一步。这种混合形态没问题，前提是你清楚哪一段交出去了、边界在哪里、出了问题从哪儿开始查。