很多人把接了函数调用的模型就叫智能体，结果上线后发现任务跑不完、谁在决策说不清、出问题也不知道该改 prompt 还是改循环。这篇不重复协议和原理，只从「谁做决定、做几次决定」这条线切开，讲清两者边界在哪、什么场景该用哪个、写代码时怎么落地和验收。
不少人一看到模型能调外部接口，就顺手把整个流程叫成智能体。上线后才发现两件事分不清：任务跑到一半停了，不知道该怪模型还是怪自己写死的分支；成本超预算，也说不清是轮次问题还是参数问题。
这篇不碰协议细节和框架原理，只从一条线切进去——「这一步谁做决定、一共做几次决定」。把这条线拉直，你自然能判断手里的活该写成固定流程，还是该写成循环，也能在出问题时知道先查哪一层。
先问一句：这一步的决定权在谁手上
函数调用的决策点全在你写的代码里。什么时候发起请求、命中工具后调哪个接口、拿回来的参数怎么处理，都是你提前排好的固定分支。模型在这个形态里只干一件事：把参数填对、把格式对齐，它不关心流程往哪走。
智能体的决策点在模型的循环里。要不要再走一步、下一步用哪个工具、这轮够不够收尾，是模型在每一轮自己选的。你的代码从「排流程的人」变成「定规矩和兜底的人」，这个角色转换是两者最本质的分界。
决定次数：一次 vs 不定次，是分水岭
函数调用通常是单轮或者你事先数得清的固定几轮：请求一次，拿到结构化参数，执行，把结果回填，结束。整个过程的轮次是个常数，你能提前画在纸上。
智能体是不定次循环。模型看到工具返回的内容后可以重新决策，一直走到它自认为任务完成，或者撞上你设的步数上限。轮次是变量，这才是成本、延迟、可复现性全都变难管的根源。
- 任务开环、输入输出高度固定（纯抽取、纯改写、格式转换）：写函数调用，硬套循环只会更慢更贵
- 任务路径依赖中间结果（先查再判断、查不到换源、多步试错）：循环有价值，但要配上限
- 一次拿不全信息、需要边跑边收敛（排障、跨系统取数）：倾向智能体形态
- 已经有稳定人工流程、只是想把某几步自动化：先做函数调用，别一上来就循环
- 对外计费或审计口径敏感的批处理：优先可复现的固定流程
可控性与自主性的取舍
自主性越高，可控性和可复现性越低，这不是缺点，是交换。函数调用同样输入两次跑，路径基本一致，好复现、好对账。智能体的路径由模型每轮选出来，同样的输入两次跑可能走不同工具、不同顺序，你没法拿两次结果直接比对。
所以别问哪个更先进，问你的场景能不能接受路径漂移。需要审计、需要复现、需要确定性输出的地方，优先函数调用；只有信息不全、必须多步试错的地方，才值得付出这份自主性的代价。
| 判断维度 | 函数调用 | 智能体 |
|---|---|---|
| 谁决定下一步 | 你写的固定分支 | 模型每轮自选 |
| 决策次数 | 可数、固定 | 不定，受上限约束 |
| 同输入可复现性 | 高 | 低，路径可能不同 |
| 出问题先查哪 | 参数校验与分支逻辑 | 工具选择、上下文、终止条件 |
| 适合的活 | 格式固定、要审计 | 信息不全、要试错 |
这张表不是让你二选一，而是让你在写代码前先填一遍。填不出「适合的活」那一行，说明任务本身还没想清楚，先别动手。
成本与延迟的口径差异
函数调用每一轮都是你主动发起的请求，轮次和带上来的上下文量都在你的估算范围内，做预算相对可控。智能体的轮次由模型决定，而每多一轮，历史上下文就要重新带一次，消耗是乘法式增长而不是加法，轮次一多曲线就陡。
- 设最大轮次在循环里写死一个步数上限，触顶就退出，不能让模型无限续杯
- 设单任务预算给每个任务一个 token 或调用次数预算，跑到阈值就停下并记录，方便后续归因
- 定超预算动作提前想好触顶后是返回半成品、报错，还是转人工确认，别等线上第一次触顶才临时决定
- 核对单价口径具体单价和额度用当时的数字算，到 官方 API 价格（/official-api） 和 模型成本计算器（/tools/model-cost-calculator） 核对，别凭记忆写进注释
要提醒的是，这套闸门只在任务本身有收敛性时才有意义。如果任务天生发散，加再多轮次上限也只是把它变得更早失败，这时候该改的是任务定义，不是循环参数。
两种写法的代码骨架长什么样
函数调用的骨架是一条直线：定义工具 schema，请求模型，命中工具就校验参数，由你的代码去执行，结果回填一轮，输出结果。全程没有「要不要再来一次」的分支，测试时把每个分支单独覆盖就行。
智能体的骨架是一个循环：定义工具集，进入 while，让模型决定动作，校验并执行，把结果塞回上下文，判断终止条件后退出。这里最关键的一点是——终止条件必须由你的代码兜底，不能只听模型自称「我完成了」。
# 函数调用：直线流程；请求模型 -> 校验参数 -> 执行 -> 回填 -> 输出；# 智能体：循环流程；while 未达停止条件:; 模型选动作 -> 校验 -> 执行 -> 结果入上下文 -> 检查轮次/预算上限; # 两者共同点：参数校验、超时、错误回传，一个都不能省；# 差别只在「下一轮调不调、调什么」是谁定的写法上的这个差别，直接决定你调试时该盯什么。直线流程出错，八成是参数或分支写错；循环流程出错，先去查工具选择、上下文污染和终止条件这三处。
自主性带来的三个必须补的坑
一旦把决定权交给模型，有三类风险会随之出现，而且它们不会在开发环境自动暴露，往往上线后才冒出来。下面这几点是选智能体形态时要一并补上的，不是可选项。
- 工具白名单：模型能自己挑工具，就必须圈定可选范围，写操作、删除类接口不要一股脑塞进同一个工具箱
- 步数与成本上限：没有上限的循环不是智能，是失控；触顶后的行为要提前定义好并写进日志
- 幂等与副作用：模型可能重复调用同一个工具，写类操作要有幂等键或二次确认，纯读操作风险低得多
不适用的情况也说一句：如果工具箱里全是只读查询接口，且每次调用都很快很便宜，那第三点的优先级可以往后放，但仍然建议保留调用次数上限，避免单任务把额度吃光。
从函数调用迁到智能体，或反向退回去
迁移前先做一次「函数调用扛不扛得住」的验证：把任务拆成固定步骤跑一版，记录哪一步需要人工兜底最多。那一步就是真正需要自主性的地方，其余步骤没必要一起变成循环。
迁移顺序建议保留原有固定流程作为降级路径：新循环跑失败时能退回老流程，跑一段时间对比成功率、平均轮次和成本，再决定要不要完全替换。反向退回同样常见——智能体老是绕圈、选错工具、成本超预算时，把它降级成「先固定几步检索、最后一步让模型选工具」的混合形态，往往更稳。
框架和 SDK 的选择不用先纠结名词，到 Agent 框架与 SDK 目录（/stacks/frameworks） 按你的语言、部署方式和是否依赖外部服务来筛，先跑通最小闭环再说。
上线前怎么验收你选对了
准备二十条左右真实任务用例，同一批输入分别用两种形态跑一遍，看成功率、平均轮次、失败时的可解释程度。重点不是谁分高，而是失败时你能不能一眼看出问题出在模型选错工具，还是你的分支写错了。
- 失败可归因：能不能定位到是模型决策问题还是代码逻辑问题
- 成本可预估：单个任务的消耗能不能估到一个量级，而不是看账单才知道
- 有降级开关：出问题时能不能一键切回固定流程或转人工
- 轮次有记录：每轮调了什么工具、带了多长上下文，日志里查得到
- 参数有校验：模型给的参数越界或格式不对时，是报错还是悄悄执行
判断不适用：如果你的任务输入输出高度固定、又要求可复现和可审计，验收结果多半会指向函数调用。这不是保守，是正确的取舍。
下一步把你手里的任务按「谁做决定、做几次决定」两栏过一遍，先填判断表再动手写；顺便到站内核对当时的模型价格与调用口径，把预算算清楚再决定要不要上循环。→常见问题
接了函数调用的模型，能叫智能体吗？
看决定权。如果你的代码已经写死了调哪个工具、调几次，模型只负责填参数，那它是结构化输出的一种用法，不算智能体。只有当「下一步做什么、要不要继续」由模型在循环里反复决定时，才谈得上智能体。这个界限比模型能力大小更能说明问题。
智能体一定比函数调用强吗？
不一定。任务步骤固定、要求可复现和可审计时，函数调用更快更稳也更便宜。智能体换来的是面对不确定任务的适应能力，代价是延迟、成本和可预测性。先问任务本身是开环还是闭环，再决定用哪种，别倒过来按技术热度选。
从函数调用改成智能体，第一步该动什么？
别整体重写。先抽出任务里最需要人兜底的那一步，把它变成「模型可选工具」的一轮决策，其余步骤保持固定流程，同时留一条退回旧路径的开关。跑一段时间看成功率和轮次变化，再决定是否继续扩大自主范围。
智能体老是绕圈子、重复调同一个工具怎么办？
先查三件事：工具返回是不是没有区分度的报错（模型看不懂就容易重试）、工具描述有没有写清适用条件、有没有设最大轮次。多数绕圈来自工具返回信息太模糊，而不是模型能力不够，把错误信息改成模型能读懂的句子往往直接见效。
怎么判断我现在该控制成本还是该放宽自主性？
按任务量级估一遍：单任务平均轮次乘以每轮上下文规模，再和你能接受的单任务预算比。如果放宽一轮带来的收益抵不上增加的开销，就收紧工具集和步数；具体单价按你所用平台的当时口径，到站内对应价格页核对后再算。
