★ FEATURED ARTICLE 1. 从聊天机器人到AI Agent先搞清楚这个词到底在讲什么AI Agent这个词最近被反复提起打开技术社区满屏都是AI Agent搭建AI Agent部署AI Agent学习路线但真正能把Agent、聊天机器人和普通API调用区分开的人其实不多。我自己的理解是Agent不是又一个更聪明的聊天框而是一个能感知环境、做出决策、调用工具、并最终把任务闭环完成掉的系统。它解决的是大模型只会说不会做的问题——模型负责思考和生成Agent负责把思考变成行动。这篇文章不是什么学术综述就是我从几个实际项目里摸爬滚打出来的经验总结。我会把Agent的演进过程拆开讲清楚每一代Agent到底解决了什么问题、留下了什么坑然后落到今天的工程实现上主流架构长什么样、Agent token是什么意思、怎么用Django这类Web框架把Agent包成服务、什么时候值得用Rust去写Agent、部署上云要注意什么。无论你是刚准备入行的小白还是已经被Agent项目的token账单折磨过的开发者应该都能从这里找到点有用的东西。1.1 我理解的Agent不是更聪明的聊天框而是会干活的系统很多人把Agent简单理解成带记忆的ChatGPT这个理解不能说错但会误导你在架构设计上走弯路。聊天机器人的核心链路是用户输入 - 模型生成 - 返回文本。Agent的核心链路多了两个关键环节一个是工具调用模型可以发起某个函数、查询某个数据库、调用某个外部API另一个是循环模型会根据工具的返回结果继续推理决定下一步做什么直到任务完成。打个比方聊天机器人是个嘴皮子很溜的顾问你问他问题他给你建议但建议对不对、能不能执行他不负责。Agent是个项目经理他会自己拆解任务、派活给工具、检查结果、发现问题再返工最后把活干完交给你。这个干活的闭环才是Agent和普通聊天应用的分水岭。在具体项目里这个区别会直接反映在系统设计上。聊天应用只需要一个流式接口加前端页面就够了Agent系统至少要拆出几个独立模块任务规划器、记忆库、工具注册中心、执行引擎、反馈收集器。这也是为什么现在网上讨论AI Agent时大家更多在聊架构、记忆、工具、token成本而不是单纯地调prompt。1.2 三条演进线索模型能力、记忆与工具调用回头去看Agent的发展历程你会发现所有演进都沿着三条主线在走。第一条是模型能力的提升。从早期的规则模板、检索式问答到后来基于Transformer的预训练模型再到GPT系列这种能理解复杂指令、能生成结构化输出的大模型。模型能力的每一次跃升都直接解锁了Agent的新玩法。最典型的就是Function Calling函数调用能力没有它模型只能输出JSON让外部程序自己解析有了它模型可以精确地告诉系统我现在要调用某个函数参数是什么工具调用从碰运气变成了稳操作。第二条是记忆机制的完善。最早的问答系统根本没有记忆每次请求都是独立的。后来的会话式Agent加了对话历史再后来出现了向量数据库Agent终于有了长期记忆能把过去几周甚至几个月的交互沉淀下来。现在大家讨论的记忆已经分成了短期工作记忆、长期事实记忆、语义记忆好几个层级每个层级的存储、召回、更新策略都不一样。第三条是工具调用能力的扩展。Agent能不能真正干活取决于它能操作多少工具。早期只能调几个写死的函数现在已经发展出成千上万个API组成的工具生态从查天气、订机票到操作数据库、执行代码、控制浏览器Agent的工具箱越来越丰富。工具调用的可靠性也从模型自己发挥发展到了用结构化协议约束模型输出的阶段。这三条线不是孤立的它们互相拉扯、互相成就。模型能力不够时记忆再多也用不好记忆机制不完善时工具调用再精准也没法完成跨多轮的复杂任务。理解这三条线后面看任何Agent架构都不会懵。2. 演进路上的几个关键节点每代Agent到底解决了什么问题2.1 规则系统和检索式问答Agent的远祖其实很笨如果往前追Agent最早的形态可以追溯到专家系统和规则引擎时代。那时候没有大模型系统靠的是人写的if-else规则用户输入查天气系统匹配到天气关键字就去调天气API把结果拼成一段话返回。这套逻辑在今天看来笨得可爱但它已经具备了Agent的雏形——感知输入、做出决策、调用工具、生成回复。规则系统的最大问题是脆弱。规则覆盖不到的输入系统直接傻掉。一个稍微复杂点的任务规则之间还会互相冲突维护成本指数级上升。后来出现了基于检索的问答系统也就是把文档切块、建索引、根据用户问题检索最相关的段落返回。这类系统能处理的问题范围大了很多但本质上还是查资料它不理解问题也不会调用工具去解决问题。我早期做过一个客服问答机器人用的就是典型的检索式架构。文档库整理得再精细用户换个说法就查不到更别提帮我查一下订单然后退款这种需要多步操作的需求。现在回头想那个项目最大的价值就是让我深刻认识到没有推理能力和工具调用所谓的智能只能是看起来像智能的字符串匹配。2.2 ReAct范式出现推理和行动第一次被绑在一起真正让Agent脱离机械应答的是2022年底Google研究者提出的ReAct范式。这个名字是Reasoning推理 Acting行动的合体。核心思想很朴素让模型在每一个决策节点先输出一段思考再决定行动行动的结果回到上下文里继续下一轮思考。这个思考-行动-观察的循环就是后来几乎所有Agent框架的基因。ReAct的意义不在于它用了多复杂的技术而在于它把大模型的推理能力和外部行动能力第一次在系统层面打通了。以前的系统是模型生成文本程序去解析文本现在是模型自己决定要做什么系统帮它执行并反馈结果。模型不再被动地等用户输入而是可以主动地探索、验证、纠错。你自己搭一个极小规模的ReAct也很简单一个循环每次把当前任务历史行动记录工具描述拼成prompt发给模型模型返回一个JSON里面包含thought思考、action要调用的工具、action_input工具参数程序执行完工具把结果追加到上下文继续下一轮。我曾在本地用几百行Python实现过这个循环跑通的那一刻你会明显感觉到这个系统真的在思考着干活而不是在背答案。从工程角度看ReAct还带来一个关键影响Agent的行为轨迹变成了可审计的。每一轮思考、每一次工具调用、每一个返回结果都被记录在上下文里出了问题可以回溯这让Agent第一次具备了可调试性。2.3 从单Agent到多Agent协作复杂任务的拆分思路单Agent做到一定程度会遇到瓶颈。任务一旦涉及多个专业领域或者需要并行处理大量子任务一个Agent既要当产品经理又要当程序员又要当测试上下文很快就会塞满一个决策失误就会连锁崩盘。于是多Agent协作成了自然的选择。多Agent的核心思路是拆分。把一个大任务拆成多个子任务每个子任务由一个专门的Agent负责再通过一个协调机制把它们的结果汇总。典型的模式有两种一种是管理者-执行者模式一个主Agent负责任务分解和验收多个子Agent负责具体执行另一种是平级协作模式多个Agent各自负责一个模块通过消息传递共享进度。多Agent的难点也在这里。任务怎么拆才合理谁来决定某个子任务的结果是否合格Agent之间的上下文怎么隔离这些问题的答案远没有统一的共识。我自己实践下来的感受是如果单Agent能解决的事不要为了技术先进而上多Agent因为调试多个Agent之间协作问题的成本比单Agent的token消耗高一个数量级。对比维度单Agent多Agent上下文压力集中在一个上下文容易撑爆分散到各自上下文压力小任务复杂度上限中低复杂度合适适合复杂、可拆分的任务调试难度相对容易一条链路难多链路交互成本控制token消耗相对可控总token更高需精细调度适合场景明确单域任务跨域、长流程、需要并行处理3. 主流架构拆解今天搭Agent都在搭什么3.1 循环架构Plan-Act-ReflectAgent的主循环怎么写现在主流的Agent框架不管是LangChain还是自研的底层基本都是一个循环Plan规划- Act执行- Reflect反思。Plan阶段Agent根据任务目标制定行动计划Act阶段调用工具执行计划中的步骤Reflect阶段检查执行结果是否达到预期如果没有就调整计划重新执行。这个循环里最容易被忽视的是Reflect。很多初学的人搭Agent写个for循环让模型反复调用工具结果往往是调用-失败-再调用-再失败因为缺少一个真正意义上的反思机制。我在项目里会在每次工具调用之后强制模型回答三个问题结果是否符合预期如果不符合原因是什么下一步应该调整什么这三个答案会写回上下文作为下一轮Plan的输入。加了这一层之后Agent从盲目试错变成了有方向地收敛。循环的终止条件也要提前设计好。最简单的是设置最大迭代次数比如10轮超过就强制结束并输出当前最佳结果。更智能一点的做法是让模型自己判断任务是否完成输出一个done标志。但要注意模型判断完成这件事并不可靠我实际见过模型明明只做了70%的工作就宣布任务完成的情况。所以我的建议是双重校验模型说done的时候上层程序再至少做一次结果完整性检查。3.2 记忆模块设计短期上下文、长期记忆和工作记忆怎么分工记忆是Agent从一次性工具变成长期助手的关键。现在大家对记忆的讨论基本分成三个层级。短期上下文就是当前任务的对话历史存储在一个列表里每次请求都会发给模型。这个层级的痛点是token消耗历史堆得越长请求越贵延迟越高。长期记忆通常用向量数据库存把历史对话、用户偏好、任务结果做向量化需要时用语义检索召回最相关的片段而不是全部塞进上下文。工作记忆则是一个中间层存当前任务进度、已完成步骤、待办事项这类瞬时的状态信息。我踩过的一个大坑是把长期记忆也一股脑塞进上下文。有一次项目里的Agent运行了三天长期记忆库攒了几百条记录我图省事全部塞进prompt结果一次调用烧掉了几万token响应慢到没法用。后来改成提取-过滤-重排的召回策略先用向量检索召回top20条再用模型对召回结果做相关性过滤最后只保留最相关的5条放进去成本直接降了一个数量级效果反而更好因为干扰信息少了。记忆的更新策略也有很多讲究。什么时候把短期上下文沉淀到长期记忆我通常用两个条件一个是当前任务完成可以总结归档另一个是会话中出现明确的事实性信息比如用户说我住在杭州这类需要长期记住的内容。沉淀的时候还要做一步去重和冲突消解否则记忆库会被重复信息和矛盾信息污染。3.3 工具调用与Function CallingAgent的手是怎么长出来的工具调用是Agent落地最关键的一环。模型再聪明没有工具它就只是个建议生成器。Function Calling是OpenAI在2023年推出的能力核心是让模型在生成回复时不是直接输出文本而是输出一个结构化的函数调用请求包含函数名和参数。系统层拿到这个请求去执行对应函数把结果返回给模型模型再基于结果继续生成最终回复。但Function Calling不是银弹。我在多个模型上试过不同模型对函数描述的遵循程度差异很大。有些模型会在参数里凭空造出根本没在描述里出现过的值比如工具需要一个日期参数模型可能编一个2026年1月1日出来。应对办法有几个一是工具描述写得更狠明确写出参数的取值范围、格式示例、缺失时怎么处理二是在执行层做严格校验参数不合法就直接返回错误信息让模型自己纠正三是给工具返回结果加上结构化标记比如JSON Schema方便模型解析。工具注册中心也很重要。每个工具应该包含名称、描述、参数Schema、执行函数、返回格式、错误处理策略。Scout这套元信息还要支持动态加载因为工具会越来越多不可能每次改代码都重发。我现在做Agent框架工具都是通过装饰器注册的加一个新工具甚至不用重启服务热加载进去就行。提示给模型的工具描述里最重要的是什么时候该用这个工具。很多人只写这个工具能做什么不写在什么条件下应该调用它导致模型乱调工具。我在每个工具描述后面固定加一句当且仅当XX条件满足时才调用本工具否则不要调用效果立竿见影。3.4 Agent token是什么意思上下文预算和成本核算的基本单位网上经常有人问AI Agent token是什么意思我理解大家真正想问的是为什么Agent项目烧token烧得这么快以及这些token都花在哪了。Token是大模型处理文本的基本单位可以粗略理解成字的碎片1个token大概对应0.6到0.75个汉字。在Agent场景里token消耗来自四个部分系统提示词每次调用都要带固定消耗、对话历史每轮都追加线性增长、工具返回结果通常是消耗大头一个真实业务接口返回几十KB很常见、模型输出思考过程和最终结果都要计费。我算过一次实际的账。一个流程相对复杂的Agent任务跑了8轮循环每轮上下文大约从2000 token增长到8000 token模型输出平均500 token工具结果平均3000 token。总消耗大概是2.5万token左右。如果用的是主流大模型的API按输出输入平均价计算单次任务成本在几毛到一两块钱之间。看起来不贵但如果这个Agent跑在自动化流程里一天执行几千次账单会很可观。更让人头疼的是token导致的上下文窗口溢出。大多数模型的上下文窗口是128K或200K看似很大但工具结果一旦膨胀很容易就会把窗口塞满。我的应对方案有三层一是对工具结果做前置压缩返回之前先截断或摘要只保留跟当前任务相关的字段二是做历史裁剪超过一定轮数后把早期对话做摘要压缩而不是全部保留原文三是监控token用量在达到阈值前主动触发记忆归档上下文重置的流程。4. 工程落地用Django和Rust把Agent变成能用的服务4.1 模型选型与开发环境先别急着上框架很多人一开始学AI Agent就上LangChain我的建议是反过来先裸手写一个最小Agent理解原理再上框架。选型时先确定模型再定框架。如果你主要用OpenAI系的模型那生态最成熟Function Calling支持也最好直接选OpenAI系就好。如果需要私有化部署或者成本敏感可以看看开源的Qwen系列和Llama系列现在国产开源模型在中文场景表现相当能打很多Agent项目用Qwen跑工具调用已经可以做到和商用模型差不多的效果。开发语言上如果只是做应用层AgentPython依然是首选。生态齐全调试方便团队招人也容易。但如果你要做的是高并发的Agent服务、Runtime层或者对响应延迟极其敏感的场景Rust会是一个值得严肃考虑的选项。我后面单独展开说Rust的取舍。开发环境方面我强烈建议在本地先把核心逻辑跑通再上云。本地开发用conda维护Python环境模型API key放进环境变量工具函数先写mock版本不依赖真实的外部服务。这样可以极大加快迭代速度不会因为外部接口限流、网络抖动卡住开发进度。4.2 用Django把Agent包成Web服务的最短路径Agent本身是一个算法逻辑它需要被包成服务才能被外部系统调用。我在实际项目中试过FastAPI和Django两种方案最终选择Django的主要原因是项目里已经有用户体系、数据库模型和后台管理需求再引入一套独立的Agent服务框架反而增加运维成本。Django的异步视图配合Daphne或Uvicorn跑Agent这种以IO密集型为主的逻辑没什么压力。一个标准的Django Agent集成方案大概是这样的用Celery或DRQ处理异步任务把Agent运行过程放到后台队列前端通过轮询或WebSocket拿进度。因为Agent任务往往要跑十几秒甚至几分钟同步HTTP请求会超时。伪代码示例这里是Python/Django方向from celery import shared_task from django.http import JsonResponse shared_task(bindTrue, max_retries3) def run_agent_task(self, task_input: dict): agent build_agent(task_input[assistant_id]) result agent.run(task_input[message]) if not result.is_success: raise self.retry(excresult.error, countdown5) return result.to_dict() def start_agent_api(request): task run_agent_task.delay({ assistant_id: request.POST[assistant_id], message: request.POST[message] }) return JsonResponse({task_id: task.id, status: running})这里有个细节值得注意Agent的中间状态怎么暴露给前端。我建议用Redis流或WebSocket把Agent的token消耗、当前步骤、工具调用记录都实时推给前端用户体验会比干等一个转圈好得多。另外Django的ORM可以直接复用已有的用户数据、订单数据Agent在做任务时可以直接通过ORM查库不需要额外再去调一个数据服务API这是用Django这类全栈框架做Agent时最大的隐藏优势。4.3 用Rust写Agent高性能选项和它的代价网上现在关于基于Rust语言AI Agent的讨论越来越多。Rust在Agent领域的机会我认为主要在三个层面一是作为嵌入式的Agent Runtime部署在边缘设备上二是作为高并发网关层承接大量的Agent请求并进行路由、限流、负载均衡三是直接写Agent的核心循环把token计算、上下文管理、工具调度都放在极低延迟的内存操作里。Rust的优势是性能和无GC。Agent的循环本质上是高频的上下文组装和状态更新用Rust写可以减少GC停顿内存占用也更可控。Rust的类型系统还能把工具调用的参数校验、状态转换错误在编译期就挡掉一批这在可靠性要求高的场景很有价值。但代价也很明显开发效率远低于Python生态里Agent相关的库还在早期团队要招到熟练的Rust工程师难度不小。我的看法是如果你做的是To C产品需要支撑几千上万的并发Agent请求可以考虑用Rust重写Agent Runtime层但应用逻辑和业务编排继续用Python或TypeScript。全链路Rust目前来看除非你的团队本身就是Rust团队否则不太建议。毕竟Agent的迭代速度太快框架层天天在变用Python你可以今天换个库明天就能接上Rust改一轮依赖可能就得半天。对比维度Python典型框架Rust开发效率极高较低学习曲线陡运行性能中等IO密集场景够用强无GC停顿生态成熟度Agent框架非常丰富起步阶段可选库少并发能力依赖异步框架原生并发优势部署体积依赖多镜像大单二进制部署极简适用场景应用层Agent、快速验证Runtime层、高并发服务、边缘部署4.4 部署到云上的坑与工程化建议Agent项目部署到云上和普通Web服务不一样最大的坑是状态管理。Web服务是无状态的请求处理完就结束了Agent是有状态的它有记忆、有循环、有工具调用。你不可能把Agent的上下文存在进程内存里因为进程一重启就丢了如果部署在多实例后面负载均衡把同一个用户的请求分到不同实例Agent的记忆就乱了。我在读阿里云AI Agent白皮书时感受最深的一点白皮书里反复在强调Agent工程化不只是把代码放上服务器而是要做会话状态存储、记忆库拆分、模型服务弹性伸缩、可观测性建设这四个层面的工程化。我把白皮书里的建议和自己的实践结合了一下总结出几条落地经验。第一会话状态必须外置。用Redis存短期上下文用PostgreSQL或向量数据库存长期记忆进程保持无状态才能水平扩展。第二模型API要做降级和容灾。现在大模型API偶尔会变慢或者报错Agent的高延迟放大了这个问题所以务必要有超时、重试和熔断机制。第三Agent的日志必须结构化。每一轮的思考内容、工具调用参数、返回结果、token用量都要打成结构化日志否则线上出了问题根本没法排查。第四成本监控和告警要做早。API账单突然飙升往往不是用户变多了而是Agent陷入了循环疯狂调用工具。提示上线前一定要做两件事。第一件压测工具调用的最大次数。设计一个恶意输入让Agent在理论上可以无限循环看看你的终止条件是否能拦住。第二件给每个用户设置单日token预算上限超过就强制降级这个机制关键时刻能救你的钱包。5. 常见问题与排查实录我在生产环境踩过的坑5.1 Agent陷入死循环计划永远在生成行动永远不执行这是我遇到过最让人抓狂的问题。Agent明明已经生成了正确的行动计划却在执行阶段反复出错然后它不去修正执行反而回去重新生成一个新的计划。结果就是计划换了一个又一个工具一个没调token倒是烧了几万。排查思路是先看日志里每轮循环的思考部分确认模型的意图到底是什么。如果思考里全是我需要先……我应该……但没有对应的行动记录说明模型被计划本身困住了。解决办法有几个一是把下一步必须调用工具写进系统提示词强调没有新信息的情况下不要重复规划二是强制要求模型每个回合必须先调用一个工具再输出总结用结构去约束行为三是降低任务复杂度一个Agent只做一件事把任务拆得更细就不会因为太复杂而陷入空转。5.2 上下文越用越贵token预算失控怎么救Agent项目跑起来之后费用涨得最凶的一定是token。我见过一个小项目上线两周账单一万二一看日志才发现是对话历史没有截断每个请求都把从第一天开始的所有对话加上工具结果全发给模型。救火分几步第一步加历史滚动窗口只保留最近20轮对话第二步对更早的对话做摘要用一段话概括那部分内容第三步对工具返回做字段过滤只保留任务需要的字段实在需要完整数据就存到业务库里不带进上下文。这个组合拳打下来同一个Agent任务的token消耗能减少60%到75%而且因为上下文更干净模型的表现往往反而更好了。5.3 工具调用不稳定参数幻觉和返回格式漂移工具调用最常见的两个问题模型编造参数和工具返回格式不稳定。参数幻觉比如工具需要用户ID模型可能直接填一个看起来像ID的字符串12345但这个用户根本不存在。解决思路是在工具执行层做严格校验校验不通过不要硬执行把错误信息返回给模型让它自查。另外要在工具描述里明确不要猜测参数值如果不知道就向用户询问。返回格式漂移是另一个隐蔽问题。同一个工具上次返回的是JSON数组这次可能是带markdown的字符串模型解析时就会出错。我的解决办法是在工具执行层做标准化所有工具的返回都统一转成规范JSON再进入上下文并且用版本号标记格式一旦格式变化可以在上层感知到。5.4 并发上不去限流、重试和排队策略生产环境中高并发会把Agent的短板全暴露出来。模型API的并发限制最先被撞到几十个Agent同时请求API直接开始限流报错。我的做法是做一个本地API网关层把所有对模型API的请求统一排队用信号量控制并发数同时对不同优先级的任务分配不同的配额。比如用户主动提问的优先级高后台批量任务的优先级低。重试策略也要分情况。网络问题可以立即重试但碰到限流错误直接重试只会加重问题。我改成指数退避加抖动第一次失败等1秒第二次2秒最多到30秒。实测下来重试成功率显著上升而且不会雪崩式打爆模型API。下面是我在生产环境整理的一张排查速查表希望能帮你少走点弯路症状可能原因快速排查方法修复手段Agent反复规划不执行任务过复杂/提示词约束弱查看每轮思考日志是否有action强制每轮调工具拆分任务token消耗异常飙升历史未裁剪/工具返回过大看单次请求token明细滚动窗口、摘要压缩、字段过滤工具返回解析失败返回格式不统一直接curl工具接口看raw响应执行层统一为规范JSON模型编造参数工具描述不明确/缺少校验抽查失败日志里的工具参数提示词强化Schema严格校验API频繁限流并发超限/重试策略不当看API日志的限流状态码网关层排队指数退避多实例导致Agent记忆错乱会话状态存在进程内存检查不同实例日志是否记忆不一致Redis外置会话状态Agent宣布完成但结果缺失模型对完成判断过于乐观人工复核完成节点的输出双重校验模型done规则检查6. 学习路线与个人沉淀从零开始到能交付项目6.1 一份可执行的学习路线图如果你现在准备系统性学习AI Agent我建议按这个路线走每一步都有明确产出避免学了理论却不会动手。第一步掌握提示工程基础。先学会写结构化的system prompt理解零样本、少样本、思维链这些概念。产出能写一个稳定输出JSON的提示词。第二步利用Function Calling。选择一家模型API熟悉它的工具调用协议写一个能调天气API或计算器的Agent。产出一个最简Agent脚本这个阶段很多东西就通了。第三步动手实现ReAct循环。不依赖框架自己写大概率能跑通循环。产出一个能自动查资料并总结答案的Agent。第四步用框架搭建应用。LangChain或LlamaIndex都可以体会框架在上下文管理、工具注册上的便利。产出接入了至少3个工具的Agent应用。第五步做多Agent协作。用AutoGen或CrewAI搭一个两个角色的协作场景比如产品经理Agent程序员Agent。产出一个多Agent协作demo。第六步工程化上线。把Agent包成FastAPI或Django服务加Redis记忆、celery队列、结构化日志部署到云环境。产出一个能持续运行的Agent服务。这个路线最快一个月可以走完慢的话两个月也足够了。关键是每一步都要动手不要只读文档不写代码。6.2 我在几个项目里沉淀下来的几点体会第一个体会Agent项目的成败多半不取决于模型选得多好而取决于边界设计。哪些话让模型说哪些事让代码做这个边界一定要画清楚。模型擅长的是理解和生成不擅长的是精确计算、严格校验、状态持久化这些都应该用代码实现不要让模型去做。第二个体会调试Agent的方式和调试普通程序完全不同你要调试的是一套行为不是一行代码。我给团队立的规矩是任何Agent的反馈都要有日志日志里要有思考内容、行动内容、观察内容三要素。缺了任何一环报错了根本无从查起。第三个体会别追求全自动。现在的Agent远没到可以完全无人值守的程度高阶的用法是让人和Agent各司其职Agent负责体力活人负责关键决策和质量把关。我做一个客服场景的Agent设计时就让它在退款金额超过一定阈值时必须转人工确认这样既降低了风险也容易让业务方接受。第四个体会成本意识要从第一天就有。我见过太多Agent项目Demo跑得很好一上线就被token账单击穿。建议从开发起就记token账每个任务要花多少钱心中有数压不下去就优化。这套习惯养成了做任何Agent项目都会越来越从容。
阅读完成 · 觉得有帮助？
