很多人第一次做需求，分不清自己是要做一个「大模型应用」还是「Agent」：一边觉得套个提示词加接口就够了，另一边又觉得不上自主规划就不算 AI。结果要么把简单需求做复杂，要么上线后才发现模型自己乱调工具、出错收不回来。这篇不堆概念，给一套按任务形态和出错代价判断的顺序，你照着对一遍就知道该往哪边走。
很多人第一次做需求，分不清自己是要做一个「大模型应用」还是「Agent」。一边觉得套个提示词加接口就够了，另一边又觉得不上自主规划就不算 AI。结果要么把简单需求做复杂，要么上线后才发现模型自己乱调工具、出错收不回来。
这篇不堆概念，给一套按任务形态和出错代价判断的顺序。你照着对一遍，就知道该往哪边走、边界该划在哪、多出来的工程活是什么。
差别不在模型，在谁决定下一步
大模型应用通常是固定流程：你写死步骤，模型只在某些节点产出文本或结构化结果。Agent 把「下一步做什么」交给模型决定，循环调用工具、读结果、再决定，直到它自己认为完成。
| 对比项 | 大模型应用 | Agent |
|---|---|---|
| 谁决定下一步 | 你写死的代码流程 | 模型在循环里决定 |
| 流程是否提前确定 | 基本确定 | 只能定个大致范围 |
| 状态管理 | 一问一答为主 | 要管中间状态和步数 |
| 出错后的收场 | 返回错误结果就行 | 可能停不下来或乱调工具 |
同一个模型两边都能用，所以区别不在模型强弱，而在控制权归谁、流程是否提前确定。判断口诀很简单：步骤能不能提前写出来。能写出来就是应用，写不出来才需要 Agent。
这些情况别硬上 Agent
- 任务步骤固定、输入格式稳定，比如摘要、分类、字段抽取、固定模板生成，走应用更省事也更省钱
- 出错代价高又不能人工兜底，比如直接改线上数据、对外发消息、走支付，别让模型自己决定调不调工具
- 要求响应时间和单次成本可控，Agent 的循环次数不确定，延迟和消耗都会浮动
- 只在少量样本上跑通就上 Agent 是常见坑，先看它在你真实输入下失败几次，再决定要不要留
这里要说清「不适用」的情况：如果你的任务其实有多个固定分支，但分支条件你一时写不清楚，那也不一定非要 Agent，可以先把条件收窄成几个可枚举的情况，用应用版本硬编码跑一遍看效果。
另一种不适合的情况是：团队还没有能力给 Agent 加硬约束。没有最大步数、没有工具白名单、没有预算上限，就先别让它碰生产环境的写操作。
工程上多出来的四件事
从应用走到 Agent，代码量增加得不明显，但责任面扩了一圈。下面这四件事，做应用时基本不用操心，做 Agent 时必须提前安排。
- 状态与循环控制
- 要管中间状态、最大步数、超时和中断，否则会绕圈或停不下来
- 工具契约
- 每个工具的参数、返回值、失败语义都要写清楚，模型看不懂就会瞎调
- 可观测与回放
- 把每一步的输入、工具调用、输出留痕，出问题能重放，不然只能靠猜
- 权限与边界
- 哪些工具只读、哪些可写、要不要人工确认，按风险分级，别一把梭全开
这四件事里，工具契约往往最耗时间。写提示词你可能半天搞定，但把五六个工具的参数和失败语义对齐，可能要来回改好几轮。
- 先画状态图把 Agent 可能经历的状态和转移画出来，标出哪些转移必须由代码强制，哪些可以交给模型判断
- 再定工具清单每个工具写清输入输出和失败返回，先只放开只读工具，验证通过再加写操作
- 最后加护栏设最大步数、单次预算上限和超时，跑一批真实输入看它是在哪一步失控的
一套按需求自查的顺序
拿不准该做哪种，就按下面这个顺序过一遍。每一步都能给出下一步的依据，不用一上来就做技术选型。
- 先写业务流程把步骤列出来，能列完就先做应用版本，跑起来看瓶颈在哪
- 只把判不准的环节交给模型在「分支爆炸且判不准」的地方引入模型决策，其余环节保持固定代码
- 给 Agent 加硬约束最大步数、白名单工具、单次预算上限，先按最小范围试
- 上线前看失败样态它是答错、还是停不下来、还是乱调工具，三种问题的修法不一样
- 用实际用量核成本成本与延迟的口径，到 /tools/model-cost-calculator 和 /tools/speed-test 按你的实际用量测一遍再定
这里也要给出不适用的判断：如果你的日请求量很小、失败一次也没什么代价，那先做应用版本、先用人工看结果，比强行上 Agent 划算得多。判断标准不是技术先进，而是你的出错代价和请求规模能不能撑住那套循环。
人和工具怎么配
应用开发更偏接口编排、前后端接入、提示词与数据流；Agent 开发还要多一层循环编排与工具治理。这两块的技能重叠，但不完全一样。
- 框架目录可以先扫一眼再选，别一上来就选最重的，到 /stacks/frameworks 对照 Agent 框架与 SDK
- 常用接口清单到 /stacks/agent-apis 看，先挑最小可用的那几个
- 小团队建议先做一个应用版本验证价值，再决定要不要拆出 Agent 那部分
- 技能面看不清的时候，去 /guides/llm-app-dev-skill-map 对一遍自己缺哪块
人怎么配，取决于你打算把 Agent 做到什么程度。只做只读工具调用，一个后端加一个懂提示词的人就够；要开写操作和人工确认流程，就得有人专门管权限和回放。
先跑一遍再选路别停在概念上。到 /tools/model-cost-calculator 用你的真实输入量算一次，再回 /guides/llm-app-dev-skill-map 对一遍团队缺什么，路线基本就清楚了。→常见问题
套了提示词再调几个工具，算不算 Agent？
关键看谁决定下一步。如果调用顺序是你写死的，比如先查库再总结，那还是应用，只是多了工具调用。只有当模型自己判断该调哪个、要不要继续调、什么时候停，才算 Agent。界线上不必纠结，能写死就别交给模型。
Agent 一定比大模型应用效果好吗？
不一定。步骤清晰的任务上，固定流程往往更稳、更快、更便宜，因为不会出现绕圈和乱调工具。Agent 的优势在多分支、输入形态杂、事先写不全流程的场景。判断方法是拿真实输入跑一批，看失败率而不是看演示效果。
从应用改成 Agent，要重做多少？
多数情况不用重做，主要加三层：状态与循环控制、工具的参数与失败契约、每一步的留痕回放。原来的模型调用和业务逻辑可以复用。建议先把工具契约写清楚再开循环，否则后面排查会很痛苦。
