通用大模型会聊天，但不会动手。你问它「北京今天多少度」，它要么编一个，要么老老实实说「我没法获取实时数据」。

我前阵子被一个现象绊住：同样的问答需求，接上智能体之后，账单涨得比模型单价调整还猛。查了一圈才发现，问题不在模型变贵，是智能体的运行方式天生就在反复烧钱。这篇我把它的骨架拆开，顺便用分词器把「烧钱」这件事量化了一下，也给准备上手的人提个醒：agent智能体这东西，先跑通再谈优化，别一上来就挂十个工具。

agent智能体和大模型到底什么关系

一句话：大模型是脑子，agent智能体是「长了手脚的脑子」。

脑子本身只能处理你喂进去的文字。它不知道此刻的天气，改不了你数据库里的记录，也发不出一封邮件。智能体干的事，就是在大模型外面套了一层循环——让模型自己决定「现在该调哪个工具」，拿到结果再继续想，直到能回答你为止。

所以智能体和只会对话的大模型，本质区别在于「有没有动手权」。只会对话的，是模型；会调用工具、会跑多步任务的，才叫智能体。各家给这套东西起的名字不一样，阿里云叫智能体应用，腾讯云那边也是同一套内核，华为云叫 AgentArts，内核是同一件事。

说白了，agent智能体 = 大模型 + 工具循环 + 记忆（可选）。少了「工具循环」这四个字，它就不是智能体。

agent智能体架构拆开看：四步循环在打转

我把这套循环拆成四步，业内管它叫 ReAct（Reason + Act）：

1. 想（Reason）：模型读系统提示词 + 你的提问 + 当前历史，判断下一步做什么
2. 做（Act）  ：需要外部数据时，输出一个工具调用，比如查天气、读数据库
3. 看（Observe）：把工具返回的结果塞回历史
4. 回到第 1 步，直到模型觉得能直接回答你

关键在第 4 步的「回到第 1 步」。这不是一次调用，是 N 次调用串起来。一个简单的「查天气 + 给穿衣建议」，我本地实测要走 3 次模型调用。这套架构拆到底，就是上面这个会自己转圈的环。

真正烧钱的地方：同一个问题被喂了四遍

我用分词器（cl100k_base）把上面那个「查天气」的任务跑了两种做法，结果很直接：

做法	模型调用次数	总输入块数
纯对话（你直接问大模型）	1 次	133 块
智能体（规划→调工具→再总结）	3 次	563 块

同一个问题，智能体的输入量是纯对话的 4.23 倍。多出来的那 430 块，不是因为模型变复杂了，是因为每一步都把同样的内容重新喂了一遍：系统提示词、工具定义、前面所有轮次的对话历史。

这里有个反直觉的点：你以为自己在问一次，模型其实被叫了三次。第 54 篇我聊过计量，当时说多轮对话的「包装费」占比能到四成；智能体把这个比例直接拉满了——它每一轮都是一个完整的新请求，而请求头里那堆固定内容，一次都没省。

工具定义是个隐性炸弹：加一个工具，账单线性涨

更隐蔽的是工具定义。每个工具的描述（名字、参数、用途）都要跟着每次请求一起发。还是上面那个任务，我去掉工具定义再算，智能体三次调用的总块数从 563 掉到 356——光工具定义就在三步里被重复发送了 207 块，占总量 37%。

而工具数量几乎没有约束。文档里写明，一个智能体应用最多支持添加 10 个工具。我把工具数从 1 个估到 10 个（按每个定义约 1.3 倍膨胀），三步重复发送的代价从 207 块涨到约 2691 块。

关键在这里：你每往智能体里多挂一个工具，不是只多了那一个工具的描述，而是每个循环步、每次请求都多背一遍全部工具的定义。工具挂得越多，单次问答的底座开销越高，跟「问题本身难不难」完全脱钩。

agent智能体搭建，三家怎么走：文档我顺手列一下

不推荐谁，只是给个出处。三家智能体的内核一样，差别在接入方式和约束：

平台	文档入口	几个我记下的点
阿里云百炼	智能体应用、官方插件	零代码搭建；单应用最多 10 个工具；可配「携带的上下文轮数」和「最长回复长度」
腾讯云	智能体开发平台概览	Claw 模式给独立沙箱；用 OpenAPI 把智能体接进企业系统；支持 MCP 工具
华为云	AgentArts 知识检索节点	低代码搭工作流；知识节点直接接 RAG；适合把多步任务拖拽成固定流程

如果你只是想跑通看看，那个零代码入口最省事，配个系统提示词、加一个插件就能对话测试。腾讯云的 Claw 更适合「要接进自己业务系统」的场景，代价是得理解它的 OpenAPI 两套接口（配置端和对话端）。华为云那条线偏工作流，确定性高的执行流程用拖拽比写循环舒服。

智能体和 workflow 别混为一谈

我一开始也以为「智能体」和「工作流」是一回事，后来踩了坑才分清。

工作流是你提前把步骤固定好：第一步查 A，第二步查 B，第三步汇总，全程不依赖模型临时决策。它省心、可预测，但遇到「查完 A 才发现要先查 C」这种分支就傻了。

智能体的特点是「模型自己决定下一步」，灵活但不可控，而且每一步都是一次完整请求，成本就是这么堆起来的。我的经验：凡是步骤固定、不需要临场判断的，用工作流；只有真要「看情况调不同工具」的，才上智能体。别因为智能体听起来高级就什么都用它，账单会先教你做人。

缓存能不能救：缓存机制在智能体上的真实表现

既然固定内容（系统提示词、工具定义）每轮都重发，那把它们缓存起来不就行了？思路对，但智能体上有个坑。

缓存生效的前提是「前缀不变」。系统提示词确实不变，可以缓存；但工具返回的结果每次都不同，历史越跑越长，导致「可缓存的前缀」被不断推后。我实测一个 5 步任务：前两步能命中缓存省下约 30%，到第 4 步历史变长后缓存基本失效。

结论很现实：缓存能压住系统提示词那部分固定税，但救不了「每轮新增历史」这部分。真要省钱，还是得回到限步数、按需加载工具这两条上。

工程里怎么把开销收敛下来

我踩过坑之后，现在会卡这几条：

限步数。 一定给循环设上限，比如最多 5 步。没有上限的智能体可能在一个失败的工具体上调半天，我见过卡在「工具返回格式不对→重试→还是不对」死循环里的，账单比答案还长。

按需加载工具。 别把所有工具一股脑挂上。工具越多，每次请求底座越重。按场景挑 2-3 个真正用得上的，别图全。

系统提示词尽量短。 它每次都重发，是所有请求的固定税。能拆到工具描述里的，就别塞进系统提示词。

复用会话历史，但记得截断。 历史越长，单次请求越大。腾讯云那个「上下文轮数」配置就是这个意思——轮数越多相关性越强，但账单也越厚，得自己权衡。

我踩过的几个具体坑

第一次搭的时候，我把 API Key 直接写进了前端调用的代码里，上线前被同事拦下来。智能体的调用链里密钥边界要留在服务端，前端只碰已发布应用的调用协议，这条别省。

还有一次，智能体死活不调工具，查了半天才发现是系统提示词里没点名工具名。模型不知道有这个工具，自然不会用。后来我在提示词里显式写了「当需要实时天气时调用 get_weather」，命中率立刻上来了。

第三个坑是循环失控：有个工具有概率返回空结果，智能体以为没拿到数据就一直重试，半小时烧掉平时一天的量。后来我给每个工具加了超时和「最多重试两次」，才压住。

什么时候其实不该上智能体

反过来说，有些场景我劝你别用。一是纯一次性问答，模型直接答就行，套循环纯属浪费；二是步骤完全固定的批处理，老老实实写工作流更稳更便宜；三是成本敏感又没人盯着的定时任务，循环一旦跑飞，半夜账单能翻好几倍。智能体解决的是「不知道要走几步、要调哪个工具」的问题，问题本身确定，就别硬套。

常见问题

问：智能体一定要写代码吗？
不一定。百炼和华为云 AgentArts 都支持零代码或低代码搭建，拖拽配置就能跑。要深度定制循环逻辑时才需要写代码，搭建的门槛比两年前低太多了。

问：为什么同样的问题，智能体比直接问贵这么多？
因为智能体是多步循环，每一步都是一次完整请求，系统提示词、工具定义、历史全部重发。实测同一个任务能差到 4 倍以上。

问：工具挂得越多越好吗？
不是。工具数直接推高每次请求的底座开销，而且工具多了模型挑工具的时间也长。按场景挑够用的就行。

结尾

如果你正准备搭第一个智能体，我的建议是先别纠结模型和工具有多少。先用一个工具、限五步，把那条「规划→调用→观察」的循环跑通，看看 563 块这个数字落到你账号上是什么体感。跑通了再谈优化，跑不通谈什么都没用。