很多人第一次做 AI 功能时都会卡在同一个地方：到底该用一个「输入-输出」的模型调用，还是搭一套会自己循环、自己调工具的 Agent？选错了不是跑不起来，而是后面越改越乱。这篇不讲术语史，只给对比维度、判断标准和落地检查清单，让你十分钟内决定方向，并且知道什么情况下这个判断不成立。
做 AI 功能的第一个岔路口，往往不是选哪个模型，而是选哪种形态：一次性把输入丢给模型拿输出，还是搭一套会自己循环、自己调工具的 Agent。这个问题看着像术语之争，实际是架构之争。选错了不会立刻报错，而是两三个月后代码越堆越乱、成本越跑越高，回头改还得推翻重来。
这篇不聊发展史，只给你三样东西：一条判断界线、一张六维对照表、一套四步决策加起步清单。目标是你读完就能拍板，同时也清楚这个判断在什么情况下不成立。涉及具体型号和价格的地方，都留了口子，请到站内页面核对当时的数字。
先划清线：什么算 Agent，什么不算
最省事的判断口径只有一句：谁在决定「下一步做什么」。流程由你的代码写死分支，哪怕中间调了大模型，也只是传统 AI 的一种实现；如果下一步是模型看着当前结果自己选的，那才进入 Agent 的范畴。这条线比「用了几个模型」「调了几个接口」都更接近本质。
- 传统 AI 的基本形态是一次输入对应一次输出，模型不决定后续动作，流程全由代码控制
- Agent 的核心是循环：观察结果、选择动作、执行、再观察，直到满足你设定的停止条件
- 只加了一次 function call 但分支仍写死在代码里，更接近工具调用，别急着按 Agent 架构设计
- 模型规模不构成分界线，小模型套上循环也可以是 Agent，大模型单轮调用也还是传统 AI
- 判断谁决定下一步：代码决定就是传统 AI，模型决定就是 Agent
这条界线不是用来贴标签的，而是用来决定你要写多少工程代码。传统 AI 的复杂度集中在提示词和接口调用；Agent 的复杂度会平摊到编排、工具协议、终止条件和日志上，工作量差一个量级。
六个维度对照：从成本到可测性
把两种形态放在同一张表里看，你会发现真正的差距不在能力上限，而在不确定性带来的工程成本。下面六个维度，是按实际排错和上线体感排的，不是按理论漂亮程度排的。
| 维度 | 传统 AI | Agent |
|---|---|---|
| 可控性 | 路径可预测，输入输出一一对应 | 每轮都可能走岔，需要步数上限和工具白名单兜住 |
| 成本结构 | 近似单次消耗乘以调用量 | 轮数与工具返回内容都会进上下文，按最坏情况留余量 |
| 可测性 | 固定输入跑断言即可 | 同一输入两次结果可能不同，按行为是否合格打分 |
| 排错位置 | 报错基本集中在请求层 | 失败分布在规划、工具参数、循环终止三处 |
| 适用场景 | 步骤固定、答案唯一、需要审计 | 步骤随输入变化、要多源信息聚合 |
| 日志要求 | 记录请求和响应就够 | 要能还原每一步的决策和工具返回 |
不适用的情况也要说清楚：如果任务本身没有「需要根据中间结果改路线」的成分，硬上 Agent 只会同时增加成本和不确定性。反过来，任务步骤虽然多但完全固定，同样不该用 Agent，用带状态的普通流程代码更省心。想知道当前主流形态的实际花费区间，到 /price-watch 核对当时的数字，别用记忆里的印象做预算。
怎么选：四步决策和最小起步
决策不用凭感觉，按顺序走四步，每一步都有明确的通过条件。走完还拿不准的，就退回上一步，不要靠加工具数量来赌效果。
- 把任务画成流程图如果分支数量有限、提前能枚举完，直接按传统 AI 写死流程，不用往下走了。画不出来说明你还没想清楚任务，先补这一步。
- 标出必须临时查或临时算的环节只有当这类环节占比高、且出现顺序不固定时，才值得考虑 Agent。占比低就单独把那几个环节做成工具调用。
- 先做单轮能力验证模型只看一次上下文能不能给出可用答案。不能的话，先补提示词和资料，别用 Agent 去掩盖基础能力不足。
- 最小起步跑通再加码一个工具、一个目标、明确的停止条件。跑通并观察几天，再加第二个工具，每次只动一个变量。
收尾检查项有四个：预算上限、最大轮数、工具白名单、失败兜底。这四项没定下来之前，不要接生产流量。它们不是优化项，是防止线上失控的最低配置。
- 预算上限：单次任务最多花多少，超了直接终止而不是继续试
- 最大轮数：循环多少次必须停，防止模型在死胡同里反复横跳
- 工具白名单：哪些工具允许被调，参数范围是否要再做一层校验
- 失败兜底：工具不可用、模型超时、返回格式错误，分别走哪条路
真要上 Agent，先配好这几件工程物件
决定用 Agent 之后，先把下面几件事配齐再谈功能。顺序上先做日志和超时，因为这两样没做好，后面所有问题都只能靠猜。接口延迟基线建议先到 /tools/speed-test 量一遍你自己的网络环境，再据此定阈值，别照搬别人的默认值。
| 工程物件 | 要先定清楚的问题 |
|---|---|
| 超时与重试 | 区分连接超时、读取超时、整体超时，各定各的值 |
| 并发与排队 | Agent 内部并发调工具和对外并发限制要分开算 |
| 降级路径 | 工具不可用时降级成文本回答还是直接报错 |
| 日志 | 每轮的输入摘要、选了哪个工具、参数、返回状态、耗时 |
日志这块最容易偷懒，也最容易在出事后追悔。至少保证能从日志还原一次完整决策链，否则线上出问题只能靠猜。日志字段建议固定下来，别每次加工具就随手改格式，否则后续做统计会很痛苦。
评测也要换个思路。Agent 不适合比对字符串，要按「行为是否合格」打分：有没有选对工具、有没有在合理轮数内结束、最终结果能不能用。准备一批覆盖主路径和边界的小用例，改提示词或换模型后重跑，看通过率的变化趋势。单次手感不算数，因为同一输入两次结果本来就可能不同。
如果想横向看看不同方案的实际表现，可以到 /rankings 和 /sites 翻当时的记录，再结合 /tools/speed-test 的实测数据做决定。中转方案的稳定性和价格会变，别用几个月前的印象下单。
下一步先把你手上的任务画成流程图，数一数分支能不能枚举完，再决定用哪种形态。站内 /tools 有可直接上手的小工具，/price-watch 能核对当时的成本区间，定方案前顺手对一遍。→常见问题
AI Agent 是不是就是更强的模型？
不是。同一套模型，包一层循环和工具就能变成 Agent，相反再强的模型被写死在固定流程里也只是传统 AI。区别在架构决定谁掌握下一步，不在参数规模。想快速分清这两者的边界，可以看站内技术栈图谱里 Agent 那一栏的条目。
我只有一个简单功能，需要上 Agent 吗？
大多数情况不需要。如果输入和输出的对应关系固定、不需要中途查询外部信息、也不需要根据结果改路线，直接用一次模型调用最省钱也最好维护。只有当步骤顺序本身取决于中途结果时，Agent 的复杂度才换得回收益。
怎么判断我的 Agent 有没有跑偏？
看三件事：轮数是否远超预期、是否反复调同一个工具、单次任务花费是否持续超出你设的上限。任意一项异常就先停下来查工具返回内容和停止条件，而不是直接换模型。日志字段该记哪些，站内日志相关页面有对照清单。
