很多人做第一个大模型功能时，就是拼一段提示词、调一次接口、把结果返给前端，跑得挺好。等到要做「自己去查资料、调工具、跑好几轮」的东西，才发现原来的写法撑不住：出错没法回放、上下文越滚越大、跑一次不知道花多少。这篇不吹概念，按架构层面把两类做法拆开对照，告诉你哪些判断标准决定你该停在哪一层，以及什么时候上 Agent 其实不划算。
很多人做第一个大模型功能时，就是拼一段提示词、调一次接口、把结果返给前端，跑得挺好。等到要做「自己去查资料、调工具、跑好几轮」的东西，才发现原来的写法撑不住：出错没法回放、上下文越滚越大、跑一次不知道花多少。
这篇不吹概念，按架构层面把两类做法拆开对照。你可以把它当成一张自查表：每一节给一个判断点和几个能落地的动作，看完能判断自己现在这个需求该停在哪一层，以及什么时候上 Agent 其实不划算。
本质差别：一次调用还是一次循环
普通大模型应用的结构是「输入 → 模型 → 输出」，一次请求一个结果，路径在你写代码时就定死了。Agent 是「想 → 调工具 → 看结果 → 再想」，循环到模型自己判断可以收尾为止。区别不在用了多强的模型，而在控制权交给了谁。
判断点很直接：如果任务的成功路径你能事先写死成几步，就不需要循环；只有当「下一步做什么取决于上一步返回什么」时才需要。比如把一段合同文本抽取成字段，这是一次调用；让程序自己去查法规、比对条款、再给结论，就是循环。
- 固定路径
- 步骤在代码里写死，模型只负责某一步的生成或判断，出错点好定位
- 循环路径
- 下一步由模型的输出决定，代码只负责执行和兜底，灵活但难预测
循环会引入一个普通应用完全不用考虑的工程负担：终止条件。什么时候算做完、模型一直说「再查一下」怎么办、工具连续返回错误要不要继续，这些都得你显式写规则，而不是指望模型自觉。
状态放在哪：无状态请求 vs 有状态会话
普通应用通常把状态放数据库或前端，模型调用本身无状态，同样的输入重放一次，结果大致可复现。Agent 不一样，它的状态在上下文里滚动累积：工具返回、思考片段、失败原因都得留在窗口内，丢掉一段下一轮就断片。
所以 Agent 开发绕不开上下文治理，而且这件事没有现成答案，只能按业务决定：什么该原样保留、什么该压缩成摘要、什么该写进外部存储再按需取回。常见做法是把长文档和大段工具返回放到检索层，上下文里只留引用和结论。
- 原始对话轮次：保留最近若干轮，更早的压缩成摘要
- 工具返回：大的先在外层摘要，只把关键字段塞回上下文
- 任务进度：写成结构化的待办列表，比让模型自己回忆更稳
- 外部知识：走检索按需取回，别一股脑全塞进窗口
- 窗口上限和计费口径：到站内 /tools/model-cost-calculator 核对当时的数字，别靠印象记
一个容易踩的坑是把「上下文越长越好」当默认。窗口只是容量，不是质量；无关内容越多，模型的注意力越分散，成本也越高。上下文管理更像是给每次调用准备一份刚好的简报。
工具调用这一层，工作量比想象中大
普通应用基本不需要工具层。Agent 的核心工作量其实不在提示词，而在工具的定义、入参校验和返回裁剪上，模型只是决策方。工具设计得好，模型选错的概率会明显下降；工具设计得糊，再强的模型也救不回来。
- 先定工具边界每个工具只做一件事，名字和描述里写清适用场景与不适用场景。验证方式：把工具清单单独给一个不了解项目的人看，看能否说对什么时候用哪个
- 统一失败返回约定错误格式，比如错误码加一句人话原因，让模型知道是可重试还是该换路子。验证方式：故意让工具返回几类错误，看模型下一步反应是否合理
- 在工具内部做裁剪返回体越长越容易把上下文顶爆，所以在工具层先摘要，只回传决策需要的字段。验证方式：统计每次工具返回的体积，超预期的就改
- 加幂等和超时工具调用是外部副作用，重试可能真的扣了两次款、发了两次消息。验证方式：给写操作加唯一请求标识，重试时服务端能识别并只执行一次
如果你不打算自己写调度逻辑，可以先在站内 /stacks/frameworks 对照各家框架对工具注册和调度的处理方式，再决定是自己写还是用现成的。框架能省掉样板代码，但工具本身的边界和返回设计，还是得你自己想清楚。
出错之后怎么办：报错 vs 自我纠偏
普通应用出错就是异常抛出，交给上层重试或提示用户，路径是线性的，调试靠日志加断点。Agent 出错后模型可能自己换个工具再试，看似聪明，但也可能在同一坑里反复绕，把预算烧在无效轮次上。
所以硬上限不是可选项，是必需品：最大轮数、单次总时长、token 预算，任一触顶就强制收尾并返回当前最好结果。与其让循环跑到天荒地老，不如早点给用户一个「没完全做完，但这是目前结果」的交代。
| 失控信号 | 可能原因 | 先做什么 |
|---|---|---|
| 同一个工具被反复调用 | 工具描述含糊或返回没给出有效信息 | 检查工具返回是否只给了模棱两可的提示 |
| 轮数持续上涨不收敛 | 任务目标本身没定义清楚 | 把目标改成可判定的收尾条件，比如产出某个结构化结果 |
| 上下文体积飙升 | 工具返回没裁剪，历史没做摘要 | 在工具层摘要，给历史加压缩策略 |
| 同样的错误重复出现 | 没有把失败原因显式写回上下文 | 把错误码和原因结构化塞回去，让模型能区分类型 |
还有一条常被忽略：每一步都要留可回放记录。否则线上一次失败，你根本说不清它中间经历了什么，优化就只能凭感觉。
成本与延迟：放大倍数不一样
普通应用的成本大致和请求数线性相关；Agent 一次用户操作可能触发多轮模型调用加多次工具调用，倍数是相乘的。延迟同理，每多一轮就多一次往返，交互式场景里用户等待感的差别非常明显。
具体单价和额度口径别凭记忆，去站内 /official-api 和 /tools/model-cost-calculator 按当时的数字核算。算的时候别只算模型调用，工具侧的查询和存储开销也要算进去，那部分经常被漏掉。
- 先估单次任务的模型调用轮数上限，乘以单轮成本，得到最坏情况
- 把工具调用的外部开销单独列一栏，别混进模型费用里
- 对高频入口设每日预算或调用次数上限，触顶降级而不是无限跑
- 后台批处理任务可以用便宜模型跑粗筛，难案例再交给强模型
- 定期回到站内页面核对当时的价格，模型和工具的价格都会变
结论是：Agent 更适合「后台跑、慢一点能接受」的任务。实时对话类要想清楚是否值得，如果用户等三秒就不耐烦，多轮循环就得慎用，或者只在用户明确点「深度分析」时才触发。
权限边界：只读和能改是两个量级
如果 Agent 只会查资料、读文件，风险可控；一旦它能写库、发消息、下单，就必须上审批、白名单和沙箱。判断标准就一句话：这个动作如果模型判断错了，代价有多大。代价大就不要交给循环自动决定。
| 动作类型 | 默认策略 | 什么时候可以放开 |
|---|---|---|
| 只读查询、检索 | 可以直接执行 | 基本都可以，注意数据可见范围 |
| 生成草稿、建议 | 直接执行但要人工确认 | 流程成熟、有人复核产出时 |
| 写库、改配置 | 白名单加审批 | 有完整审计日志和回滚手段后 |
| 对外发送、下单、付款 | 强制人工确认或双人复核 | 一般不建议全自动，除非金额和影响面极小 |
工程上常见做法是给高风险动作加人工确认环节，或者把「决定」和「执行」拆成两个服务，执行侧只认结构化指令、不认自然语言。这样即使模型输出被污染，执行侧也不会照单全收。
合规与数据边界问题别自己猜，先看站内 /safety 的口径。文档里没写清楚的，就按最保守的做法来，宁可多一步确认。
测试方式完全不同：单点判定 vs 轨迹评估
普通应用可以写断言、比字段，测试用例相对稳定。Agent 的产出是「一串动作」，要评估的是路径是否合理、工具选得对不对、有没有绕远路，而不是只看最后那句话对不对。
所以 Agent 通常要建自己的小评测集，跑多次看成功率区间，而不是看单次对不对。同一批用例跑三轮，如果成功率忽高忽低，说明流程本身不稳定，这时候优化提示词的收益很有限。
- 收真实失败案例从日志里挑出跑得不对的任务，比凭空造用例更贴近实际。验证方式：用例能覆盖多数线上失败类型
- 给每条用例写明期望路径不是只写期望答案，还要写「应该调用哪类工具、不该调用哪类」。验证方式：人工检查几条，确认标准可执行
- 跑多轮看区间同一批用例重复跑，记录成功率和平均轮数。验证方式：成功率稳定、轮数没有异常长尾
- 改动前后对比任何提示词或工具改动都跑同一批用例，避免凭感觉说变好了。验证方式：有改动前后的对照记录
别直接照搬公开榜单的结论，那类分数的读法在站内 /benchmarks 与 /benchmarks/registry 有说明。榜单测的是通用能力，你的任务往往窄得多，参考价值有限。没有可回放、可比较的日志，评测就是走形式。
什么情况下别上 Agent
上面讲的都是 Agent 该怎么做，但更值钱的判断是：很多需求根本不需要 Agent。上错了层，不仅贵，还更不稳定，出问题还难查。
- 流程固定、步骤能穷举的任务：用工作流加几次模型调用就更稳更便宜
- 对延迟极敏感、用户不接受等待多轮往返的场景
- 没有可靠的自动化验证手段、错了也没人复核的场景
- 团队还没有日志、回放、预算控制这套基础设施的时候，先把这些补齐
- 单次任务的价值明显撑不起多轮调用成本的场景
另一种折中做法是「一次调用加少量工具」：模型只做一次决策，选一个工具查完就直接生成答案，不进入多轮循环。这能覆盖不少「需要一点实时信息」的需求，成本和不稳定性都远低于完整 Agent。
先用固定路径把需求做出来，等真的撞上「下一步取决于上一步」的墙，再考虑上循环。
如果你还在选具体的技术栈，可以顺路看看站内 /stacks/frameworks 和 /rankings 的口径；但选型之前，先把上面这些判断点过一遍，比选哪家框架重要得多。
下一步想估算手里的需求到底值不值得上 Agent，可以到站内的模型成本计算器和官方 API 页面，按当时的数字把最坏情况的调用成本和延迟算一遍，再决定做到哪一层。→常见问题
是不是所有大模型应用最后都要做成 Agent？
不是。判断标准是任务路径能不能事先定死。能定死的用工作流加模型调用，稳定、便宜、好调试；只有当「下一步做什么取决于上一步结果」且这个分支多到写不完时，循环式 Agent 才有价值。
Agent 开发是不是就是普通 LLM 应用加个工具调用？
不完全是。工具调用只是其中一层，真正的差别在于循环控制、状态治理、终止条件、成本上限和可回放日志。少了后面这些，套上工具调用也只是个容易失控的单次调用。
先用工作流，后面能平滑升级到 Agent 吗？
可以，前提是把模型调用封装成独立一层，工具的入参出参走结构化定义。这样把「调用」换成「循环加调用」时，业务代码和工具层基本不用推倒重写。
Agent 跑一次大概花多少？
取决于轮数和每轮上下文长度，倍数是相乘的，没法给固定答案。建议先设轮数上限和预算告警，按当时单价在站内成本计算工具里核算，跑一段时间再看真实均值。
小团队做 Agent 优先补哪块基础设施？
优先补日志回放和预算上限这两样，其次是工具层的超时与幂等。这三块不齐，出了问题既查不出来也止不住损，再好的提示词都救不回来。
