AI Agent 实战：从架构选型到 Token 成本控制的踩坑经验

1. 先搞清楚：AI Agent 到底是个什么东西

1.1 从“会聊天的模型”到“会干活的系统”

很多人第一次接触 AI Agent，脑子里浮现的还是那个对话框——你问一句，它答一句，聊得挺热闹，但关掉窗口啥也没留下。这其实是Chatbot（聊天机器人）的形态，不是 Agent。

我自己的理解是：Agent 是一个能自己拆任务、自己调工具、自己看结果、自己决定下一步的系统。它和普通对话模型最大的区别在于“闭环”——模型输出不再是终点，而是下一轮动作的输入。

打个比方。普通对话模型像一个只会纸上谈兵的顾问，你问它“怎么订机票”，它给你列一堆步骤；Agent 像一个真能帮你订票的助理，它会打开订票页面、填信息、比价、下单、把确认号发给你。中间哪一步失败了，它自己重试或者换方案。

这个差别听起来简单，但落到工程上，复杂度差了一个数量级。因为一旦模型要“动手”，你就得给它配工具、配记忆、配权限、配失败处理，还要防止它乱来。

1.2 一个 Agent 最少要有哪几个零件

我把一个能跑起来的 Agent 拆成四块，缺一块都不太成立：

• 大脑（推理核心）：通常是大语言模型，负责理解目标、拆解步骤、决定调用哪个工具。它不一定要最强，但一定要“听话”且“稳定”，因为后面所有动作都依赖它的判断。
• 手脚（工具层）：函数调用、API 请求、浏览器操作、文件读写、数据库查询，这些都是工具。工具的定义要清晰，参数要严格，否则模型会瞎填。
• 记忆（状态管理）：短期记忆是当前任务的上下文，长期记忆是跨会话的知识沉淀。没有记忆的 Agent 每次都是从零开始，做不了多步任务。
• 循环控制（编排层）：决定什么时候继续、什么时候停、失败了怎么退。这一层最容易被忽略，但恰恰是 Agent 和“一次性调用”的分水岭。

我第一版 Agent 就是只做了大脑和工具，没有循环控制，结果模型调一次工具拿到结果就停了，根本不会根据结果决定下一步。后来补上循环，才真正跑通。

1.3 为什么这一年我烧了几千块

说“烧了几千块”不是夸张。Agent 的 token 消耗和普通对话完全不是一个量级。普通对话一问一答可能几百 token，Agent 一个任务跑下来，中间要经历“思考—调工具—看结果—再思考”好几轮，每轮都把历史上下文重新塞进去，token 是成倍涨的。

我做过一个粗略统计：一个中等复杂度的任务（比如“查一下某城市明天天气，如果下雨就提醒我带伞，并把提醒写进日程”），大概要跑 5 到 8 轮，每轮输入加输出平均 3000 token 左右，一个任务就是两万多 token。如果一天跑几十个任务，一个月下来账单很可观。

所以这篇不是科普文，是我真金白银踩出来的经验。下面按“怎么搭、怎么省、怎么不翻车”三条线展开。

2. 主流架构怎么选：别一上来就上最复杂的

2.1 三种常见架构的适用场景

市面上聊得比较多的 Agent 架构，我归成三类，按复杂度从低到高：

我一开始被“多 Agent 协作”这个概念吸引，觉得越复杂越厉害，结果搭了一套三个 Agent 互相聊的流程，跑一个简单任务花了十几轮，token 爆炸，效果还不如单 Agent。后来老老实实退回 ReAct，只在真正需要分工的场景才上多 Agent。

提示：架构复杂度要和任务复杂度匹配。任务本身只有两步，你上多 Agent，多出来的全是内耗。

2.2 ReAct 循环为什么是性价比最高的选择

ReAct 的核心就一句话：让模型在每一步都先“想”再“做”，做完看结果再“想”。它的循环结构大概是：

1. 模型输出思考（Thought）：我现在要干什么
2. 模型输出动作（Action）：调用哪个工具，参数是什么
3. 系统执行工具，返回观察（Observation）
4. 把观察塞回上下文，回到第 1 步
5. 模型判断任务完成，输出最终答案

这个结构的好处是透明。每一步你都能看到模型在想什么、调了什么、拿到了什么。出问题的时候好排查，不像多 Agent 那样一堆消息飞来飞去，根本不知道哪步错了。

我实测下来，ReAct 在 80% 的日常任务上都够用。它的主要成本在上下文长度——每轮都要把之前的思考、动作、观察全部带上，轮数一多，token 就上去了。所以优化重点也在这里，后面会讲。

2.3 多 Agent 什么时候才值得上

多 Agent 不是不能用，是要用对地方。我总结下来，只有满足下面至少两条，才考虑多 Agent：

• 任务需要不同视角交叉验证，比如一个写一个审
• 任务步骤之间有明确的角色边界，比如规划的和执行的不是一回事
• 单个 Agent 的上下文塞不下所有信息，需要拆分
• 任务允许并行，多个 Agent 同时干活能省时间

如果只是“任务有点复杂”，那还是单 Agent 加更多工具更划算。我见过太多项目为了显得高级硬上多 Agent，结果调试成本翻三倍，效果没提升。

3. 搭建实操：从零跑通一个能用的 Agent

3.1 技术栈选型：为什么我最后选了 Rust

热词里有个“基于 rust 语言 ai agent”，我确实用 Rust 写过一版。先说结论：Rust 适合对性能和资源敏感的场景，但开发效率不如 Python。

我选 Rust 的原因是我有个 Agent 要长期驻留跑定时任务，Python 进程跑几天内存就涨上去了，Rust 版本跑了两个月内存曲线基本平的。但如果你只是做原型验证，Python 生态成熟得多，LangChain、LlamaIndex 这些框架能省你大量时间。

我的实际组合是：

• 原型阶段：Python + 轻量编排，快速验证想法
• 生产阶段：核心循环用 Rust 重写，工具层通过 HTTP 调用复用
• 部署：容器化，单实例跑，配健康检查

这个组合的好处是原型跑通后再重写，不会一上来就陷进 Rust 的编译错误里。

3.2 工具定义：Agent 能不能干活全看这一步

工具定义是 Agent 搭建里最容易被低估的环节。我踩过的坑是：工具描述写得太模糊，模型要么不调用，要么乱填参数。

一个好的工具定义要包含四样东西：

• 名称：动词开头，见名知意，比如get_weather而不是weather
• 描述：说清楚什么时候用、什么时候不用，最好带例子
• 参数：每个参数的类型、是否必填、取值范围都要写死
• 返回：返回结构要稳定，别这次返回字符串下次返回对象

我举个实际对比。早期我写天气工具的描述是“获取天气信息”，模型经常在不需要天气的时候也调它。后来改成“当用户明确询问某地天气，或任务需要根据天气做判断时调用。参数 city 必须是城市中文名”，误调用率明显下降。

提示：工具描述不是写给人类看的文档，是写给模型看的指令。要具体、要有边界、要带反例。

3.3 记忆管理：短期和长期要分开设计

记忆这块我走过弯路。一开始我把所有历史都塞进上下文，结果跑几轮就超长，模型开始“忘事”。后来拆成两层：

短期记忆就是当前任务的上下文，我做了两个优化：

• 只保留最近 N 轮的完整内容，更早的做摘要压缩
• 工具返回的大段结果先截断或提取关键字段，不原样塞回去

长期记忆是跨会话的，我用一个简单的向量库存历史任务的结论，需要时检索相关片段注入上下文。这里要注意，长期记忆不是越多越好，检索回来的内容如果不相关，反而干扰模型判断。

我实测下来，短期记忆控制在 8 到 10 轮，长期记忆每次检索 3 到 5 条，效果和成本比较平衡。

3.4 循环控制：什么时候停比什么时候跑更重要

循环控制是 Agent 的刹车。没有刹车，模型可能陷入死循环，一直调同一个工具，token 哗哗烧。

我设了三道保险：

• 最大轮数：超过 15 轮强制停止，返回当前最好结果
• 重复检测：连续两轮调用同一个工具且参数相同，判定卡住，中断
• 超时控制：单个任务超过 60 秒强制结束

这三道保险救过我很多次。有一次模型因为工具返回格式不对，一直重试同一个调用，如果没有重复检测，那一晚上能烧掉我几十块。

4. Token 成本控制：这是真金白银的教训

4.1 Token 到底花在哪了

热词里有“ai agent token是什么意思”，我用自己的账单解释。Agent 的 token 消耗分三块：

• 输入 token：每轮都要把系统提示、工具定义、历史上下文、当前观察全部塞进去，这是大头
• 输出 token：模型的思考和动作，相对少
• 工具返回 token：如果工具返回一大段 JSON，原样塞回上下文，也很可观

我统计过自己的消耗比例，输入占 70% 以上。所以省钱的重点在压缩输入。

4.2 我实测有效的五个省钱手段

第一，精简系统提示。我第一版系统提示写了 2000 多字，后来压到 600 字，效果没变，每轮省 1400 token。

第二，工具按需加载。不是所有任务都需要所有工具。我按任务类型动态注入相关工具定义，而不是一次性全塞进去。工具从 20 个减到 5 个，输入直接少一截。

第三，工具返回做预处理。工具返回的原始数据先在代码里提取关键字段，再塞回上下文。比如天气 API 返回一大坨，我只留温度、天气、降水概率三个字段。

第四，历史做摘要。超过 5 轮的旧内容，用一次便宜的模型调用压缩成一句话摘要，替换掉原文。

第五，选对模型。不是所有步骤都要用最强的模型。我把“决定调什么工具”这种简单判断交给便宜模型，“复杂推理”才用强模型。混合使用后，成本降了大概四成。

这些手段叠加，我从每月几百块降到了几十块。

4.3 一个具体的省钱案例

我有个任务是每天定时抓几个信息源，汇总成简报。最初版本每轮把抓到的全文塞进上下文，一个任务跑下来 5 万 token。

优化后：抓取在代码层完成，只把标题和摘要注入上下文，模型负责筛选和排序。同样的任务降到 8000 token 左右，效果反而更好，因为模型不用在一堆噪音里找重点。

这个案例说明一个道理：能让代码干的活，别让模型干。模型贵在判断，不在搬运。

5. 常见翻车场景与排查技巧

5.1 模型不调工具，只在那聊天

这是新手最常见的问题。模型收到任务后，不调工具，直接编一个答案给你。

原因通常是工具描述不够明确，或者系统提示没强调“必须用工具获取真实数据”。我的解法是在系统提示里加一句硬约束：“涉及实时数据、计算、外部查询的任务，必须先调用对应工具，禁止凭记忆回答。”

如果还不行，就在工具描述里加反例：“不要在没有调用本工具的情况下回答天气问题。”

5.2 工具调用参数乱填

模型把参数填错，比如城市名填成英文、日期格式不对。这是工具定义不够严格导致的。

我的做法是参数尽量用枚举或明确格式说明，并在工具执行层做校验，参数不合法直接返回错误信息让模型重试。重试两次还不行就中断，避免无限循环。

5.3 任务跑一半卡住

卡住的表现是模型反复调同一个工具，或者输出一堆无意义的思考。前面说的重复检测和最大轮数就是治这个的。

排查的时候我会把完整日志打出来，看它卡在哪一步。十有八九是工具返回了模型看不懂的格式，或者工具报错但错误信息不清晰，模型不知道怎么办。

提示：工具报错信息要写成人能看懂的话，模型也是“人”，清晰的错误信息能帮它自我纠正。

5.4 成本突然飙升

有次我账单突然涨了五倍，查下来是一个任务的循环没设上限，模型卡在一个逻辑里跑了几百轮。

所以最大轮数这个保险一定要设，而且要设得保守一点。我现在的默认值是 15 轮，特殊任务才放宽。

5.5 常见问题速查表

6. 学习路线与后续扩展方向

6.1 我给新手的四周学习路线

如果你现在想入门 Agent，我建议按这个节奏走，别一上来就啃框架源码：

• 第一周：跑通一次工具调用。用最简单的 API，让模型调一个工具拿到结果。理解“工具定义—调用—返回”这个链路。
• 第二周：加上循环。把单次调用改成 ReAct 循环，让它能根据结果决定下一步。这一步会开始烧 token，注意设上限。
• 第三周：加记忆和成本控制。短期记忆做截断，工具返回做预处理，把成本压下来。
• 第四周：做一个真实的小任务。比如自动整理每日信息、自动回复某类消息。跑通一个完整场景，比看十篇教程有用。

6.2 后续可以扩展的方向

Agent 跑通之后，能扩展的地方很多。我自己在试的有两个方向：

一个是把 Agent 接到实际业务系统里，比如让它操作内部工具、查数据库、生成报表。这里的关键是权限控制，Agent 能碰什么、不能碰什么，要在工具层卡死。

另一个是多 Agent 协作的精细化，不是简单堆角色，而是让不同 Agent 负责不同粒度的决策，规划者定方向，执行者做细节，审核者把关。这个方向我还在摸索，目前只在少数场景跑通。

热词里提到的“让小红书自动发消息”“用 ai agent 开发 django”这类，本质都是把 Agent 接到具体平台上。我的建议是先把单 Agent 跑稳，再考虑接平台，否则平台的各种异常会把你的 Agent 拖垮。

6.3 我个人的一点体会

这一年最大的收获不是技术，是心态。Agent 不是魔法，它是一个会犯错的系统。你要做的不是让它永不犯错，而是让它犯错的时候你能知道、能兜住、能恢复。

我现在的做法是每个 Agent 任务都留日志，关键步骤打点，出问题能回溯。这套东西看起来笨，但比任何花哨的架构都管用。

最后分享一个小技巧：如果你不确定一个任务该不该用 Agent，先问自己“这个任务需不需要根据中间结果改变下一步”。如果需要，Agent 合适；如果不需要，一次调用或者写死流程更省事。这个判断标准帮我省了不少冤枉钱。