把 AI 智能体从 Demo 推到线上最让我意外的事情不是模型能力而是基础设施。过去一年多我们团队陆续接了十几个智能体项目有做客服自动应答的有做数据分析的有帮运营写周报的。Demo 阶段全都跑得挺顺可真要一上线问题就全冒出来了并发上来之后实例怎么扩会话记忆放哪儿工具调用超时了怎么重试一个死循环的智能体把账单价钱跑穿怎么办。折腾了几个月我们干脆盘了盘需求做了一个专门为 AI 智能体设计的按需运行平台项目代号就叫 Agent Droplets 服务器。它不是一台物理服务器而是一套“面向智能体会话的云基础设施”按事件拉起独立运行实例、用完自动销毁、状态通过事件流保存开发者只需要定义智能体行为和工具集剩下执行、调度、容错、观测都交给平台。这篇文章不是官方文档复读而是把设计和上线过程中那些真实的取舍、踩过的坑、以及“为什么这样设计”讲清楚。如果你正在考虑把智能体从脚本升级成长期运行的线上服务或者正在纠结要不要自建一套智能体调度平台那这篇应该能帮你省不少弯路。1. 为什么拿普通虚拟机跑智能体总是不得劲Agent 工作负载的真实画像1.1 传统服务的假设在智能体这里全部失效我先说结论智能体本质上不是“网站”不是“API 服务”也不是“定时任务”它是一个被事件驱动的、有上下文状态的、会主动调用外部工具的短时计算流程。最开始我们也偷懒直接把智能体进程挂在一台常驻虚拟机上24 小时跑个 Python 服务监听消息。第一版 demo 没什么问题可一旦放真实流量就非常别扭。常驻虚拟机天然假设流量是相对平稳的每个请求昂进来处理完返回响应服务器一直活着等下一个。但智能体的流量是按会话、按事件触发的波动极其剧烈。上午十点可能只有 3 个活跃会话下午搞活动突然涌进 300 个每个会话内部还要为了回答一个问题连续做十几次工具调用。这种负载跑在固定资源池上要么闲时白掏钱要么忙时疯狂排队。而且智能体的计算特点和普通请求很不一样。普通 web 请求通常一两秒就结束CPU 和内存的占用相对规律。智能体不同它在等大模型推理响应的时候基本不占 CPU等结果一回来立刻进入工具执行阶段可能又要调数据库、抓网页、算表格一下子就飙起来。你很难用“QPS”去衡量它唯一合理的衡量单位是“活跃会话数”以及“一个会话内产生了多少次工具调用”。1.2 会话状态最容易被低估的麻烦另一个让我非常头大的点是状态管理。普通服务是无状态的数据库再存一份就行。智能体天然必须有状态聊到一半它得记得刚刚说过什么执行到第三步它得知道第一步查出来的订单 ID用户中断了一次下次回来还得能接着上一段继续。我们最早把状态直接存在进程内存里结果服务一重启所有会话全断了用户骂声一片。后来换数据库把整段会话历史当一个大 JSON 存进去又出现并发写覆盖、拉取慢、历史长了大模型输入超限这些问题。状态不是一个“存下来”这么简单的事状态是智能体的命根子它的保存方式直接决定了系统能不能续跑、能不能调试、能不能回滚。我们当时的判断是需要一种“按会话生命周期来设计的运行模型”。智能体会话一旦触发平台给它起一个隔离的运行环境环境里加载好工具、系统提示词、历史状态执行完一步立刻把这一步的事件追加到持久化存储整个会话结束或者闲置超时运行实例可以销毁但状态留着随时可以重新拉起继续跑。这就是 Agent Droplets 的原始出发点。一张表可以很直白地看出差别维度传统长驻服务智能体会话负载运行周期常驻以月计按事件启动一般只有几十秒到几十分钟资源特征相对平稳的并发突发、间歇等待和计算交替出现状态特性无状态或依赖数据库强上下文必须支持中途续跑外部依赖数据库、缓存、外部 API大模型接口、各种工具 API、数据库且工具调用频繁成本颗粒度按实例/按月按会话/按步骤最合理故障方式崩溃、超时、过载死循环、反复调用同一工具、状态错乱看这张表你就能明白为什么我们最后没有选择“在虚拟机上堆智能体进程”而是专门做了一个平台层。虚拟机能解决“算力从哪来”但解决不了“会话怎么管理”“状态怎么续”“工具调用怎么隔离”这些问题。2. Agent Droplets 的形态按需启动、自动销毁、状态可续的架构拆解2.1 不是云主机不是 PaaS是“智能体执行器”Agent Droplets 服务器这个名字关键在 Droplets。我们内部约定一个 droplet 就是一个“智能体运行实例的虚拟化单元”。当某个事件触发一个智能体会话调度器就创建一个 droplet分配内存、CPU、容器环境的隔离边界、配置好的模型调用凭证和工具权限。它在只够完成当前这一步或当前这一段会话的时间内存活干完就销毁绝不赖着不走。有人会问这是不是就是 Serverless 容器接近但不完全一样。普通的 Serverless 函数是“无状态、单次执行”智能体需要多步推理、记忆上下文、工具调用链路这些都要在 droplet 内部被编排好。所以我们在 droplet 之上封装了三个核心组件调度控制面、沙箱运行时、状态总线。三者配合才让“按需启动、自动销毁、状态可续跑”真正成立。2.2 调度控制面负责拉起、排队、回收调度控制面是平台的入口它接收三类触发HTTP 回调、消息队列事件、定时任务。每次触发都会携带会话 ID控制面根据会话 ID 判断这是新会话还是已有状态需要继续执行的分支如果是续跑它会先把历史事件从状态总线拉出来组装成上下文再分配 droplet。控制面另一个关键职责是配额管理。我们不允许一个用户无限拉起 droplet。每个账号有并发上限有事件速率限制有全局超时。这些参数不是拍脑袋定的而是来自我们对真实故障的复盘后面我会专门讲那些故障。控制面还有一个容易被忽略的功能回收。一个 droplet 到了闲置阈值必须回收到了会话最大时长必须回收外呼 API 连续失败达到次数也会触发熔断回收。回收不是粗暴杀进程而是先通知 agent 保存检查点再销毁实例保证下一次还能从状态总线里续上。2.3 沙箱运行时让工具调用不失控智能体的核心动作是工具调用。工具包括查订单库的 SQL、调内部 HTTP API、外呼某个搜索结果页面、读写文件、甚至模拟浏览器操作。这些动作涉及权限、密钥、网络边界绝不能让它直接在宿主环境里裸奔。我们的做法是每个 droplet 运行在轻量级容器段中给最小化系统权限外部网络访问走代理网关网关做域名白名单和协议白名单敏感密钥不写进环境变量明文而是通过密钥注入组件在运行时注入到进程内部。也就是说智能体自己拿不到明文密钥它只能通过平台封装的工具令牌去调外部服务。一个特别容易踩的坑是智能体在调用工具之后的返回结果往往很长数据量很大如果直接把原始返回值塞回上下文很快就把大模型的输入窗口塞爆了。我们在运行时里做了返回体压缩和截断策略大结果先存对象存储上下文里只放摘要和引用地址等智能体真正需要全量数据时再按需拉取。这个设计一开始不觉得重要后续在长会话场景里救了我们很多次。2.4 状态总线事件流追加而不是整表覆盖说到状态这可能是 Agent Droplets 和普通容器平台最不一样的地方。我们没用常规的关系型数据库去存“当前会话状态”而是把状态设计成一条持续追加的事件流。每个会话产生的事件包括user_input用户发来的原始消息。model_call大模型推理的请求和响应摘要。tool_call工具调用名称、参数摘要、返回结果摘要。checkpoint平台定期打的状态快照。system_event超时、重试、配额命中、熔断。事件流按会话 ID 分片存储写入采用追加模式不存在“修改某一行”的需求。要恢复一个会话时从最近的 checkpoint 开始往后重放事件就能精确还原到任意一步。这种设计带来了三个好处一是并发安全不会出现两个人同时改一条会话记录的冲突二是可调试每步都留痕出了错能精确知道是哪一步、哪个工具、哪次模型调用导致的三是可回退如果新版本智能体跑出了坏结果可以直接在同一事件流上分叉回退到上一个 checkpoint 再试。创建一个 AgentRuntime 的配置大概长这样apiVersion: droplets.agent/v1 kind: AgentRuntime metadata: name: customer-service-agent namespace: production spec: runtime: image: runtime-agent-base memoryLimit: 512Mi cpuLimit: 1 lifecycle: trigger: message idleTimeoutSeconds: 60 maxSessionMinutes: 30 state: store: event-bus checkpointEverySteps: 5 ttl: 7d tools: - order.query - order.batch_query - customer.lookup policies: maxConcurrencyPerSession: 1 stepTimeoutSeconds: 15 maxToolCallsPerStep: 4 fatalErrorRetries: 2这个配置描述了一个客服智能体的运行定义每条新消息触发一个 droplet单会话内不并发闲置 60 秒自动回收每条消息处理时长最多 30 分钟状态保留 7 天每 5 步打一次快照每一步超时 15 秒每一步最多调用 4 次工具。这些默认值背后是对“失控比稀疏更可怕”的深刻理解。3. 上线前补齐的三个关键细节冷启动、配额限制和状态续跑3.1 冷启动用户没有耐心等一个 8 秒的“联网思考”智能体平台的冷启动体验直接影响产品口碑。用户在聊天框里发一条消息如果三秒没反应很多人就已经关页面了。而智能体的冷启动原本是重操作要拉起容器加载运行库拼装系统提示词恢复历史状态建立大模型连接池初始化各种工具客户端。这套流程如果每次实时做一遍少说也要五六秒。我们的解法分两层热池和快启。热池里常驻一批已经初始化好的基础运行时实例镜像已经加载完毕工具注册表已经填充事件流连接已经建立。新的 droplet 不是从零创建而是从热池里拿一个实例把会话 ID 和状态检查点绑定上去允许用户代码在进程内完成。快启层的优化更细模型上下文拼接复用模板历史事件重放做了并行预取工具客户端延迟初始化只在第一次真正调用时才创建连接。实测优化之后绝大多数会话在 1 到 2 秒内可以开始处理第一条消息如果状态较长会额外慢一点但核心链路不会因为等待基础环境而抖动。值得说的是热池不是越大越好。热池里的空闲实例也在吃内存太多会浪费成本。我们的策略是根据近 5 分钟活跃会话量的预测动态调整热池大小高峰期提前扩容低谷期自动收缩。这块逻辑目前还在持续调优但方向明确按活跃会话趋势来预测而不是按固定数量配置。3.2 配额给失控智能体准备好“保险丝”智能体失控这件事我们上线第一周就撞上了。某开发者写了一个循环调用工具的逻辑智能体在一个会话里反复查询订单接口每分钟打几十次。要不是监控报警系统差点把业务数据库拖垮。从那以后配额和熔断成了最高优先级的设计。现在的配额模型分三层第一层是账号级并发数。比如每个正常账号最多同时运行 20 个活跃 droplet超出的排队等待。这一层是控制整体资源池不被单一账号打爆。第二层是会话内速率。每个会话内部工具调用频率、模型调用频率分别做令牌桶限流。如果某个行为超过了每分钟 30 次工具调用的阈值平台直接中断该步骤返回一个 quota_hit 事件而不是让循环继续烧钱。第三层是全局时长预算。每个会话有累计处理时长上限每条消息有步骤超时上限。国债时长用完会话自动终止并要求开发者介入。这一层特别重要——智能体不像普通程序有明确的“结束”概念它天然倾向于继续对话、继续尝试没有预算它就能永远跑下去。配套的还有循环检测启发式当同一个工具、相同参数前缀在一个会话中连续出现多次时平台会标记并暂停该 session提示开发者确认是否为死循环。这个启发式不完美会有误伤但在真正出 bug 时它能大幅降低损失。3.3 状态续跑从“存会话”到“重放会话”的思路转换上线前我们犯过一个比较大的设计错误我们最初想用云数据库存“会话快照”每次对话结束后覆盖写一条最新状态。看起来很简单但立刻遇到问题并发写覆盖、半写状态、长上下文恢复慢以及无法回答“为什么智能体这一步做出了这个决定”。后来切换成事件流模型一切顺了很多。每个事件只做追加不做修改天然有审计能力。不同的会话分支也能表达——假如同一个会话有两个候选分支每个分支都是基于同一段父事件流的延伸最终可以选一条作为最终结果提交。事件流存得久了还会有存储成本问题所以我们又加入了分层保留策略热事件保留 24 小时用于实时调试快照保留 7 天用于一般续跑线上需要长期归档的会话再转到对象存储做冷存。目前看这种“事件流 快照 冷存”的组合在成本、延展性、可恢复性之间是比较均衡的取舍。状态续跑的代码侧用法也很直接调用方只需指定会话标识即可droplets-cli invoke customer-service-agent \ --session 0d6a04b2-1c3e-4f89-9c2a \ --input 继续之前的订单查询平台自动判断该会话是全新触发还是续跑续跑时不需要调用方自己去组装历史上下文这对前端同学非常友好。4. 跑起来之后的账单、超时和循环风暴运维侧的真实情况与治理对策4.1 一次被 200 个容器冲垮的账单教训Agent Droplets 上线后第二周我们的开发环境突然出现了几百个并发 droplet 同时被拉起的情况。查了半天发现是某个开发者在调试时为每条消息都创建了全新会话而且业务侧代码在异常时反复重试每个重试都会触发一个新的智能体会话。结果就是一分钟内200 个 droplet 同时运行账单快速上升风控部门都被惊动了。这件事让我深刻明白一件事智能体基础设施给的自由度越大用户滥用造成的破坏就越大必须提供“强制安全默认值”。现在新创建的 AgentRuntime 配置文件如果开发者什么都没填平台会自动套上一组安全默认值配置项默认值为什么这么设单会话最大并发1防止同一会话并行导致状态错乱账号并发上限20防止单个账号打爆整个池单步骤超时15 秒模型或工具卡住能快速暴露单会话总时长30 分钟防止长尾会话无限占用资源工具调用速率30 次/分钟防止循环刷工具接口失败重试次数2防止无限重试放大人为故障这些默认值上线后被骂了一阵“太严格”但跑了一个月再也没有出现过账单失控或会话泛滥的事故。我始终认为智能体平台的默认值应该宁可严格、不能宽松开发者有特殊需要可以显式调高但决不能默认放开。4.2 工具调用超时和重试表面是网络问题深层是设计问题运维过程中我们反复和“工具调用超时”打交道。智能体调用一个内部 API本来 100 毫秒就好结果对方服务偶发 5 秒才返回智能体就会陷入等待等待太久触发步骤超时重试之后又是同样结果整个会话看起来像卡死了一样。后来我们做了两件事。第一件所有工具调用都走统一网关网关负责设置合理的上游超时默认 8 秒并把重试策略统一收口只有幂等工具才允许自动重试非幂等工具失败后必须返回错误事件、由智能体自行决策。第二件在状态事件流里拆分明细计时把模型等待时间、工具调用时间、内部编排时间分开统计这样定位问题能一眼看出瓶颈在哪而不是每次都要盲猜。比如一个典型的事件记录{ session_id: 0d6a04b2-1c3e-4f89-9c2a, event_type: tool_call, step_index: 7, tool_name: order.query, status: timeout, latency_ms: 8520, retry_count: 0, quota_remaining: 12, memory_peak_mb: 168, ts: 1730503200 }把这样的结构打成结构化日志之后再配合查询面板我们可以按会话追出每一个工具调用的耗时分布也可以在巡检时直接发现“某个上游接口的调用失败率突然攀升”不用等用户投诉才知道系统出了故障。4.3 日志切分一个步骤里发生了什么必须拆开看智能体日志最让人头疼的地方是模型输出、工具返回、代码内部逻辑全都混在一次执行里。如果按普通应用那样统一打到一个日志流排查问题基本等于大海捞针。我们把每个步骤的埋点拆成了三类独立通道模型轨迹记录发送给模型的上下文长度、模型返回内容摘要、推理耗时。工具轨迹记录工具名、入参摘要、出参摘要、耗时、状态码。编排轨迹记录智能体代码内部的决策路径包括条件分支、错误捕获、重试动作。三类通道分别用不同的标签做索引但共享同一个会话 ID 和步序号。当问题发生时先看编排轨迹确认代码走了哪条路再看工具轨迹确认外部调用是否正常最后才需要看模型轨迹确认是不是大模型理解偏了。这套设计不需要什么高深技术但非常管用它是我们调试智能体问题时最重要的利器。5. 什么场景适合放在 Agent Droplets 上以及什么时候我建议你再想想5.1 适合这里的人事件驱动、会话型、需要工具的智能体上线踩了这么多坑同时服务了内部多个智能体项目之后我们对“什么场景适合用这套基础设施”有了比较清晰的判断。最适合的场景首先是对话型助手。客服、售前、售后、内网知识问答这些智能体天然是事件驱动的用户来了消息才需要启动会话会话有上下文需要调内部系统查数据完成后可闲置可销毁。放在 Agent Droplets 上成本是弹性的用户不聊就不产生成本聊起来也能扛住并发。其次是自动化的任务分解型智能体。比如给运营写周报它会先拉数、再总结、再排版比如做竞品分析它会先列关键词、再检索网页、再汇总结论。这类任务的特点是步骤多、耗时长中间会有大量等待状态续跑的价值非常明显。写一半断了也不怕回去能从检查点继续执行。我们还有一拨用户在平台上面跑多租户的智能体服务也就是开发者把自己的智能体包成 API 卖给下游客户。对他们来说按会话计费、资源隔离、配额治理是一站式的这比自己在云上搭一套省心太多。5.2 不适合硬套的场景密集计算和长驻流式任务也有两类场景我不建议硬塞进来。第一类是纯密集计算任务。比如对几百万行日志做聚合分析或者跑批量推理评分。这些任务没有会话上下文也不需要外部工具编排用专用计算集群更高效。在 Agent Droplets 上跑纯计算既浪费了状态总线的能力也受单会话时长上限的制约属于用错工具。第二类是长时间流式监听任务。比如一个智能体要持续监听某个消息队列实时处理每一条流式记录并保持会话永不结束。这在产品形态上更像常驻消费者更适合用常规的流处理框架把智能体只作为其中的一个处理节点来调用而不是让整个消费进程在 droplet 里长期挂机。第三类其实是“不适合直接裸跑”高权限敏感操作型智能体。比如能直接改数据库、能执行资金操作的智能体。不是平台不支持而是这类场景必须有严格的人机复确认机制不能纯靠智能体自主决策。我们建议这类业务在工具层再加一道审批策略否则一旦智能体误判损失无法挽回。5.3 给准备自建平台的人一份实践清单最后分享一份针对“要不要自建”的实践清单。如果你只是做一个内部小工具那没必要搭建完整平台用脚本加队列就能跑。但如果你想把智能体产品化、规模化至少要确认下面这几点没有漏状态管理别贪图省事。会话状态请优先考虑事件流或至少是 append-only 设计而不是覆盖式数据库否则并发、审计、回退全都会成为问题。所有外部出口必须统一收口。智能体访问任何外部系统都走统一网关统一超时、统一鉴权、统一日志不要放任智能体代码自己拼 HTTP 请求。默认配额必须保守。并发上限、速率限制、时间预算全部要有默认值上线前先评估业务峰值再决定是否调宽别把“改成高并发”当成标准动作。日志必须能按步骤还原。模型调用、工具调用、编排决策分轨记录并且保证每一条都带会话 ID否则出问题你既无法定位也无法复盘。可续跑是底线能力。无论你用什么架构都要保证一个会话中断后能基于已保存状态恢复而不是强制用户重来一遍。我个人在实际操作中的体会是智能体本身就是个“不可完全预测的系统”基础设施能做的不是让智能体永远不出错而是让出错时损失可控、恢复要快、账算得清。Agent Droplets 服务器走到今天核心原则没有变过——按会话给你独立的运行单元按事件保存完整状态按默认值兜住各种意外。这个思路我可以很确定地说比单纯搞一堆虚拟机挂个调度器靠谱得多。如果你正好也在做类似的基础设施选型欢迎聊聊你在智能体上线时碰到过哪些坑尤其是那些“日志里根本看不出来”的诡异问题——我们交换一下案例可能比读十份文档都值。