企业官网建设流程全解析

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消耗高一个数量级。

3. 主流架构拆解：今天搭Agent都在搭什么

3.1 循环架构Plan-Act-Reflect：Agent的主循环怎么写

现在主流的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 Calling：Agent的"手"是怎么长出来的

工具调用是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跑工具调用已经可以做到和商用模型差不多的效果。

开发语言上，如果只是做应用层Agent，Python依然是首选。生态齐全，调试方便，团队招人也容易。但如果你要做的是高并发的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(bind=True, max_retries=3) 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(exc=result.error, countdown=5) 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改一轮依赖可能就得半天。

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。

下面是我在生产环境整理的一张排查速查表，希望能帮你少走点弯路：

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项目都会越来越从容。