1. 从“裸跑”到“编队”：Agent 管理的核心痛点拆解
1.1 为什么单个 Agent 跑得挺好，上百个就崩了
我最早接触 Agent 编排是在一个自动化内容处理的场景里，当时只有三四个 Agent 各干各的活，写个脚本轮询调用就完事了。后来业务扩张，Agent 数量涨到几十个，问题立刻暴露出来：有的 Agent 卡死没人管，有的重复消费同一条任务，日志散落在十几个终端窗口里根本对不上号。这时候我才意识到，Agent 的“裸跑”模式本质上和早期手工部署服务是一回事——单机跑个进程没问题，一旦规模上去，没有统一的调度、生命周期管理和可观测性，运维成本会指数级上升。
所谓“裸跑”，指的是 Agent 进程直接启动，没有编排层介入，任务分发靠硬编码或简单队列，状态追踪靠翻日志文件。这种模式在 Agent 数量少于十个、任务类型单一的时候还能凑合，但只要满足以下任意一个条件，就必须引入编排层：
- Agent 数量超过 10 个，且需要动态扩缩容
- 任务之间存在依赖关系，需要按顺序或并行编排
- 需要统一收集 Agent 的运行指标和日志
- 多个 Agent 需要共享上下文或记忆存储
- 需要对 Agent 的权限和资源消耗做隔离
Google 开源的 AX 项目，核心思路就是把 Kubernetes 那套声明式管理理念搬到 Agent 编排上。你不再手动去启动每个 Agent，而是写一份类似 YAML 的配置文件，描述你期望的状态——要几个 Agent、每个 Agent 用什么模型、分配多少资源、任务队列怎么接——然后 AX 的控制平面负责把实际状态收敛到期望状态。这个思路和 kubectl apply 的逻辑完全一致，用过 K8s 的人上手会非常快。
1.2 AX 到底解决了哪些具体问题
我把 AX 解决的问题归纳为四个层面，这也是我在实际项目中感受最深的痛点：
第一是生命周期管理。裸跑模式下，Agent 进程挂了就挂了，除非你写了额外的守护脚本。AX 把每个 Agent 抽象成一个受管资源，控制平面持续监控其健康状态，异常退出自动重启，版本更新支持滚动替换。这就像 Deployment 管理 Pod 一样，你声明要 3 个副本，挂了一个就补一个。
第二是任务分发与负载均衡。多个 Agent 消费同一个任务队列时，裸跑模式容易出现重复消费或者某个 Agent 饿死的情况。AX 内置了任务路由层，支持轮询、最少负载、一致性哈希等策略，保证任务均匀分配。对于有状态 Agent，还支持会话粘性，同一个用户的任务始终路由到同一个 Agent 实例。
第三是可观测性。这是我认为 AX 最有价值的部分。它统一采集每个 Agent 的调用次数、Token 消耗、响应延迟、错误率等指标，并且支持按 Agent 维度、任务维度、时间维度聚合。以前我要写一堆脚本去解析日志算 Token 消耗，现在直接看面板就行。日志也做了结构化处理，每条 Agent 调用记录都带 trace ID，排查问题的时候可以完整还原一次任务在多个 Agent 之间的流转路径。
第四是资源隔离与配额。不同 Agent 可能用不同的模型，成本差异巨大。AX 支持给每个 Agent 或每个任务队列设置资源配额，比如限制某个 Agent 每分钟最多调用多少次、每天最多消耗多少 Token。超额后可以选择排队、降级到便宜模型或者直接拒绝。这个功能在多团队共用一套 Agent 基础设施时特别重要，能有效防止某个团队的任务把资源吃光。
1.3 和 Kubernetes 的类比到底靠不靠谱
标题里说“像 kubectl 一样管住上百个 Agent”，这个类比不是营销话术，而是架构层面的真实映射。我整理了一张对照表，方便理解 AX 的设计逻辑：
| Kubernetes 概念 | AX 对应概念 | 作用说明 |
|---|---|---|
| Pod | Agent 实例 | 最小运行单元，一个 Agent 进程 |
| Deployment | Agent 编排配置 | 声明副本数、镜像版本、资源限制 |
| Service | Agent 服务端点 | 提供稳定的访问入口，屏蔽实例变化 |
| ConfigMap | Agent 配置 | 模型参数、提示词模板、工具配置 |
| HPA | 自动扩缩容策略 | 根据队列深度或延迟自动调整副本数 |
| Namespace | 项目/团队隔离 | 不同团队的 Agent 互不干扰 |
| kubectl | ax 命令行工具 | apply、get、logs、scale 等操作 |
这个类比的意义在于：如果你团队里有人用过 K8s，他几乎不需要额外学习就能理解 AX 的使用方式。声明式配置、期望状态收敛、控制循环这些概念是相通的。但也要注意，Agent 和容器有本质区别——Agent 是有状态的、会调用外部 API、会产生非确定性输出，所以 AX 在任务路由和状态管理上做了很多 K8s 没有的设计。
2. AX 核心架构与关键组件解析
2.1 控制平面与数据平面的分工
AX 的架构分成控制平面和数据平面两层，这个划分和 K8s 一致，但具体职责有所不同。
控制平面负责三件事：一是维护期望状态，也就是你通过配置文件声明的 Agent 编排规则；二是运行控制循环，持续对比实际状态和期望状态，发现偏差就触发纠正动作；三是提供 API 和命令行入口，让你可以查询状态、修改配置、查看日志。控制平面本身是无状态的，可以多副本部署保证高可用，状态数据存在外部的键值存储里。
数据平面就是实际运行 Agent 进程的地方。每个数据平面节点上跑着一个 Agent 运行时，负责启动、监控、停止本节点上的 Agent 实例。数据平面节点可以横向扩展，Agent 调度器会根据资源占用和亲和性规则把 Agent 分配到合适的节点上。
我实测下来，控制平面用 2 核 4G 的机器就够跑上百个 Agent 的编排，瓶颈主要在数据平面——每个 Agent 实例的内存占用取决于你用的模型和框架，如果是本地推理那资源消耗会大很多，如果是调用远程 API 那单节点跑几十个 Agent 没问题。
2.2 Agent 编排配置文件的写法
AX 的配置文件格式是 YAML，结构和 K8s 的 Deployment 非常像。我拿一个实际用过的配置举例：
apiVersion: ax/v1 kind: AgentDeployment metadata: name: content-processor namespace: marketing-team spec: replicas: 5 agentTemplate: spec: framework: langchain model: provider: openai name: gpt-4o-mini maxTokens: 4096 tools: - name: web-search config: maxResults: 5 - name: file-reader config: allowedPaths: - /data/input systemPrompt: | 你是一个内容处理助手，负责对输入的文章进行摘要和分类。 输出格式要求为 JSON，包含 summary 和 category 两个字段。 resources: requests: memory: "512Mi" cpu: "250m" limits: memory: "1Gi" cpu: "500m" quota: maxRequestsPerMinute: 60 maxTokensPerDay: 500000 taskQueue: name: content-tasks routingStrategy: least-loaded sessionAffinity: true autoscaling: enabled: true minReplicas: 2 maxReplicas: 20 metrics: - type: queue-depth targetValue: 10这份配置声明了：在 marketing-team 命名空间下运行一个叫 content-processor 的 Agent 编排，初始 5 个副本，用 LangChain 框架和 gpt-4o-mini 模型，挂载了搜索和文件读取两个工具，设置了资源限制和配额，任务队列用最少负载路由并开启会话粘性，自动扩缩容根据队列深度在 2 到 20 个副本之间调整。
写这份配置的时候有几个坑我踩过：systemPrompt 里的缩进必须严格用空格，YAML 对 Tab 零容忍；quota 的单位要看清，maxTokensPerDay 是每天重置还是滚动 24 小时，文档里写的是自然日重置；autoscaling 的 targetValue 需要根据实际任务处理速度调，设太小会导致频繁扩缩容，设太大又起不到削峰作用。
2.3 任务路由与状态管理机制
任务路由是 AX 区别于普通容器编排的核心。Agent 处理的任务通常是有状态的——比如一个多轮对话任务，同一个用户的前后请求必须路由到同一个 Agent 实例，否则上下文就丢了。AX 的会话粘性通过任务元数据里的 session ID 实现，路由层对 session ID 做一致性哈希，保证同一会话始终落在同一个实例上。
对于无状态任务，AX 支持三种路由策略：
- 轮询：按顺序依次分发，实现简单，适合任务处理时间均匀的场景
- 最少负载：优先发给当前队列最短的 Agent，适合任务处理时间差异大的场景
- 随机：随机选择，适合任务量极大且对延迟不敏感的场景
我大部分场景用的是最少负载，因为 Agent 调用外部 API 的延迟波动很大，轮询容易导致某些实例堆积。但最少负载需要路由层实时收集每个实例的队列深度，有一定的心跳开销，Agent 数量超过 500 个时建议改用轮询加随机抖动的混合策略。
状态管理方面，AX 把 Agent 的状态分成三类：会话状态存在外部 Redis 里，支持过期时间；任务状态存在任务队列的元数据里，记录任务的执行阶段和结果；Agent 实例状态由控制平面维护，包括健康状态、当前负载、版本号等。这个分层设计的好处是 Agent 实例本身可以无状态化，随时替换或重启，不会丢数据。
3. 从零搭建 AX 管理上百个 Agent 的实操过程
3.1 环境准备与 AX 安装
我是在一台 8 核 16G 的 Linux 机器上搭的测试环境，操作系统是 Ubuntu 22.04。AX 的安装方式有好几种，我选的是二进制安装，因为最干净、依赖最少。
首先确认系统版本和架构：
uname -a # Linux ax-test 5.15.0-91-generic #101-Ubuntu SMP x86_64 GNU/Linux然后下载对应架构的 AX 二进制包。这里注意，AX 的发布包分 amd64 和 arm64 两个版本，下载错了会报“无法执行二进制文件”。下载后解压并放到 PATH 里：
tar -xzf ax-v0.8.2-linux-amd64.tar.gz sudo mv ax /usr/local/bin/ ax version # ax version 0.8.2 (build: 2024-11-15)接下来初始化 AX 的控制平面。AX 需要一个存储后端来保存编排状态，默认用的是内置的 SQLite，适合测试环境；生产环境建议换成 etcd 或 PostgreSQL。初始化命令：
ax init --storage sqlite --data-dir /var/lib/ax执行后会生成默认配置文件/etc/ax/ax.conf，里面包含控制平面监听地址、存储连接串、日志级别等。我改了两个地方：把日志级别从 info 调到 warn，减少日志量；把控制平面监听地址从 127.0.0.1 改成 0.0.0.0，方便从其他机器访问。
启动控制平面：
ax server start --config /etc/ax/ax.conf看到输出AX control plane listening on 0.0.0.0:8443就说明启动成功了。这时候可以用ax get nodes查看数据平面节点，初始状态下是空的，因为还没注册任何工作节点。
3.2 注册数据平面节点与 Agent 运行时
数据平面节点需要运行 AX 的 Agent 运行时，并向控制平面注册。我在同一台机器上先跑一个节点做测试：
ax node join --server https://127.0.0.1:8443 --token <join-token>join-token 在控制平面启动时会打印在日志里，也可以用ax token create重新生成。注册成功后，ax get nodes应该能看到这个节点，状态是 Ready。
节点上需要预装 Agent 运行时依赖。AX 支持多种 Agent 框架，我用的是 LangChain，所以节点上要装 Python 3.10+ 和 langchain 包。这里有个细节：AX 的 Agent 运行时和业务 Agent 是分离的，运行时负责进程管理、健康检查、日志采集，业务 Agent 就是一个普通的 Python 脚本，通过标准输入输出或 HTTP 接口和运行时通信。这种设计让 Agent 开发者不需要关心编排逻辑，专注业务实现就行。
我写了一个最简单的测试 Agent 来验证链路：
# test_agent.py import json import sys def handle_task(task): return { "task_id": task["task_id"], "result": f"processed: {task['payload']}", "status": "success" } if __name__ == "__main__": for line in sys.stdin: task = json.loads(line) result = handle_task(task) print(json.dumps(result), flush=True)这个 Agent 从标准输入读任务，处理后从标准输出返回结果。AX 运行时负责把任务队列里的消息喂给它，并把输出写回结果队列。
3.3 部署第一个 Agent 编排并验证
有了节点和 Agent 脚本，接下来写编排配置并部署。我把上面的配置文件保存为content-processor.yaml，然后执行：
ax apply -f content-processor.yaml输出agentdeployment.ax/content-processor created表示创建成功。用ax get agentdeployments -n marketing-team查看状态：
NAME READY REPLICAS AGE content-processor 5/5 5 30sREADY 显示 5/5 说明五个副本都启动成功了。这时候可以往任务队列里发消息测试：
ax task submit --queue content-tasks --payload '{"text": "这是一篇测试文章"}'然后用ax logs -n marketing-team content-processor --tail 20查看 Agent 的处理日志。如果看到processed: 这是一篇测试文章就说明整条链路通了。
我实测下来，从零到跑通第一个编排大概花了 20 分钟，主要时间花在装 Python 依赖上。如果节点上已经有现成的 Python 环境，10 分钟以内能搞定。
3.4 扩展到上百个 Agent 的调优经验
跑通单个编排后，我开始往上百个 Agent 的规模压。这个过程踩了不少坑，挑几个关键的讲。
第一个坑是控制平面的存储瓶颈。用 SQLite 的时候，Agent 数量超过 50 个后，控制平面的状态写入开始变慢，ax get命令响应时间从毫秒级涨到秒级。换成 PostgreSQL 后问题解决，因为 SQLite 的写锁是库级别的，并发写入会互相阻塞。生产环境直接上 PostgreSQL 或 etcd，别用 SQLite。
第二个坑是心跳风暴。每个 Agent 实例默认每 5 秒向控制平面发一次心跳，100 个实例就是每秒 20 次请求。控制平面单副本处理不过来，导致心跳超时误判。解决办法有两个：一是把心跳间隔调到 15 秒，二是控制平面部署 3 个副本做负载均衡。我两个都做了，心跳压力降了一个数量级。
第三个坑是任务队列的消费者竞争。多个 Agent 实例消费同一个队列时，如果队列实现用的是数据库轮询，高并发下会出现大量空轮询。AX 默认用的是 Redis 作为队列后端，支持阻塞读取，没有空轮询问题。但如果你的环境只能用数据库队列，记得把轮询间隔调大，并且给队列表加合适的索引。
第四个坑是日志采集的磁盘占用。100 个 Agent 每天产生的日志量很可观，如果不做轮转，磁盘很快满。AX 的日志采集支持按大小和时间轮转，我配置的是单文件最大 100MB、保留 7 天。另外建议把日志级别调到 warn，info 级别的日志在规模上去后基本没人看。
调优后的配置参数我整理成了一张表：
| 参数 | 默认值 | 调优值 | 说明 |
|---|---|---|---|
| 心跳间隔 | 5s | 15s | 降低控制平面压力 |
| 控制平面副本数 | 1 | 3 | 高可用和负载均衡 |
| 存储后端 | SQLite | PostgreSQL | 并发写入性能 |
| 日志级别 | info | warn | 减少日志量 |
| 日志轮转大小 | 无限制 | 100MB | 防止磁盘写满 |
| 日志保留天数 | 无限制 | 7天 | 控制存储成本 |
| 任务队列后端 | 数据库 | Redis | 支持阻塞读取 |
| 自动扩缩容冷却时间 | 30s | 120s | 防止频繁扩缩 |
4. 常见问题排查与避坑指南
4.1 Agent 启动失败的五种典型原因
Agent 副本起不来是最常见的问题，我遇到过的情况基本归为五类：
第一类是镜像或脚本路径错误。AX 运行时根据配置里的 framework 字段去找对应的启动脚本，如果路径写错了会报agent runtime not found。排查方法是登录到数据平面节点，手动执行一遍启动命令，看具体报什么错。
第二类是依赖缺失。比如 Agent 脚本 import 了一个没装的 Python 包，运行时启动后立刻退出。AX 会把退出原因记录在 Agent 实例的事件里，用ax describe agent <name>可以看到。我一般会在 Agent 脚本开头加一个依赖检查，缺什么直接打印出来。
第三类是资源不足。节点内存不够时，Agent 实例会被 OOM Killer 杀掉。用ax get nodes看节点的可分配资源，用ax describe node <name>看已分配资源。如果 requests 设得太高，调度器会找不到合适的节点，实例一直处于 Pending 状态。
第四类是配额超限。如果 Agent 的 quota 设置得太小，启动时的初始化调用就可能超限，导致实例反复重启。排查方法是看 Agent 事件里有没有quota exceeded关键字。
第五类是网络问题。Agent 需要访问外部 API 时，如果节点没有外网访问权限或者 DNS 解析失败，Agent 会启动超时。这个用ax exec进入 Agent 容器里 curl 一下外部地址就能确认。
4.2 任务堆积与延迟飙升的排查思路
任务堆积是规模上去后最容易出现的问题，表现是队列深度持续增长、任务延迟越来越高。排查思路我总结成三步：
第一步，确认是 Agent 处理慢还是任务来得太多。看两个指标：任务到达速率和 Agent 处理速率。如果到达速率远大于处理速率，说明需要扩容；如果两者差不多但队列还在涨，说明有 Agent 卡住了。
第二步，定位卡住的 Agent。用ax top agents -n <namespace>看每个 Agent 实例的当前任务数和平均处理时间。如果某个实例的任务数远高于其他实例，可能是路由策略有问题；如果所有实例的处理时间都变长了，可能是外部 API 限流或网络抖动。
第三步，检查外部依赖。Agent 处理任务通常要调用外部 API，如果 API 响应变慢，Agent 的处理时间自然变长。AX 的调用链追踪可以显示每个任务在各个阶段的耗时，一眼就能看出瓶颈在哪个环节。
我遇到过一次典型的任务堆积：队列深度从 10 涨到 500 只用了 5 分钟。排查发现是某个 Agent 调用的外部搜索 API 开始返回 429 限流错误，Agent 的重试逻辑写得不好，每次重试等 30 秒，导致大量任务卡在重试阶段。解决办法是给外部调用加熔断和降级，限流时快速失败并切换到备用搜索源。
4.3 常见问题速查表
| 现象 | 可能原因 | 排查命令 | 解决方法 |
|---|---|---|---|
| Agent 实例 Pending | 资源不足或调度失败 | ax describe agent <name> | 降低 requests 或扩容节点 |
| Agent 反复重启 | 依赖缺失或配额超限 | ax logs <name> --previous | 补依赖或调大配额 |
| 任务延迟飙升 | 外部 API 限流或网络抖动 | ax top agents | 加熔断降级或扩容 |
| 队列深度持续增长 | 处理速率跟不上到达速率 | ax get queue <name> | 开启自动扩缩容 |
| 控制平面响应慢 | 存储瓶颈或心跳风暴 | ax server metrics | 换存储后端或调心跳间隔 |
| 日志磁盘写满 | 日志未轮转 | df -h | 配置日志轮转和保留策略 |
| 会话上下文丢失 | 会话粘性未开启 | ax describe queue <name> | 开启 sessionAffinity |
| Token 消耗异常高 | 提示词过长或重复调用 | ax quota show | 优化提示词或加缓存 |
4.4 几个容易被忽略的实操细节
关于命名空间隔离。AX 的命名空间不只是逻辑隔离，还影响资源配额和网络策略。我建议按团队或项目划分命名空间，每个命名空间设置独立的资源配额，防止互相影响。跨命名空间的 Agent 调用需要显式授权，默认是禁止的。
关于配置版本管理。AX 的编排配置支持版本历史，每次ax apply都会生成一个新版本。回滚用ax rollout undo，和 K8s 的kubectl rollout undo一样。我习惯把配置文件放在 Git 仓库里管理，每次变更走 PR 流程，这样出了问题能快速定位是哪次变更引入的。
关于灰度发布。Agent 的提示词或模型变更风险很高，建议用灰度发布。AX 支持在同一个编排里运行多个版本的 Agent，通过任务标签路由到不同版本。比如先让 10% 的任务走新版本，观察指标正常后再逐步扩大比例。
关于成本控制。这是 Agent 场景特有的问题。K8s 管的是 CPU 和内存，AX 还要管 Token 消耗。我建议给每个 Agent 设置 Token 配额，并且开启用量告警。另外，对于简单的分类、提取任务，用便宜的小模型就够了，没必要全部上大模型。AX 支持在任务级别指定模型，可以根据任务复杂度动态选择。
关于安全边界。Agent 会调用外部工具，工具权限必须严格控制。AX 的工具配置里可以限制文件访问路径、网络访问域名、命令执行白名单。我见过因为 Agent 工具配置不当导致敏感文件被读取的案例，所以工具权限这块一定要最小化授权。
5. 从单机脚本到 AX 编排的迁移心得
5.1 什么样的项目适合迁移到 AX
不是所有 Agent 项目都需要 AX。我判断的标准是：如果你开始手动 SSH 到服务器上重启 Agent 进程，或者需要写脚本去解析日志统计 Token 消耗，那就该考虑迁移了。具体来说，满足以下任意两条就值得迁移：
- Agent 数量超过 10 个，且还在增长
- 需要 7x24 稳定运行，不能接受手动重启
- 多个团队成员需要共用 Agent 基础设施
- 需要对 Agent 的调用成本和性能做精细化管理
- 任务类型复杂，需要灵活的路由和编排策略
如果只是个人做实验，三五个 Agent 跑着玩，那用脚本管着就行，上 AX 反而增加复杂度。
5.2 迁移过程中的平滑过渡策略
我迁移的时候没有一刀切，而是分了三步走：
第一步，把无状态 Agent 先迁。无状态 Agent 不依赖会话上下文，迁移风险最低。迁过去之后跑一段时间，验证 AX 的调度、日志、监控都正常。
第二步，把有状态 Agent 的会话存储外置。有状态 Agent 迁移前，先把会话数据从进程内存挪到 Redis 或数据库里。这样 Agent 实例就可以随时替换，不会丢上下文。这一步是迁移的关键，做完之后有状态 Agent 的迁移和无状态就没区别了。
第三步，把任务队列从自建切换到 AX 托管。自建队列通常和业务代码耦合较深，切换时要做好双写和灰度。我当时的做法是新旧队列并行跑一周，对比两边的任务处理结果，确认一致后再切流量。
整个迁移过程花了两周，期间新旧系统并行，没有影响线上业务。迁移完成后，运维工作量大概减少了 70%，以前每天要花一两个小时看日志、重启进程，现在基本不用管。
5.3 规模上去之后的新挑战
上百个 Agent 跑起来之后，新的挑战不是运维层面的，而是治理层面的。我遇到的主要有三个：
一是 Agent 的版本碎片化。不同团队在不同时间部署的 Agent 用了不同版本的提示词和模型，行为不一致。解决办法是建立 Agent 模板库，把常用的 Agent 配置标准化，新 Agent 从模板创建，减少随意性。
二是任务优先级混乱。所有任务挤在一个队列里，重要的任务被不重要的任务堵住。AX 支持多队列和优先级，我把任务分成高、中、低三个优先级，高优先级队列单独分配 Agent 资源，保证关键任务不被影响。
三是成本归属不清。多个团队共用 Agent 基础设施，月底算账的时候说不清谁用了多少。AX 的配额和用量统计支持按命名空间聚合，我按团队划分命名空间，每个月的 Token 消耗一目了然，成本分摊有了依据。
5.4 我个人的几条经验总结
最后分享几条我在实际使用中体会比较深的经验，不一定对所有人适用，但至少能帮你少走点弯路。
别一上来就追求全自动扩缩容。自动扩缩容听起来很美，但参数调不好反而添乱。我建议先手动设置一个固定的副本数，跑一段时间摸清任务的峰谷规律，再根据实际数据配置扩缩容策略。我一开始把 targetValue 设成 5，结果任务稍微一多就扩容，扩完又马上缩，来回折腾。后来改成 20，稳定多了。
日志和指标要分开存储。日志数据量大、查询频率低，适合存对象存储或冷存储；指标数据量小、查询频率高，适合存时序数据库。我一开始把两者混在一起存，查询慢不说，存储成本还高。分开之后，指标查询秒级返回，日志按需拉取，成本降了一半。
给 Agent 起名字要规范。上百个 Agent 如果名字起得随意，后面排查问题的时候根本找不到。我建议用团队-功能-版本的格式，比如marketing-content-v2、support-ticket-v1。名字里带版本号，灰度发布和回滚的时候特别方便。
定期做故障演练。我每个月会手动杀掉几个 Agent 实例，验证自动恢复是否正常；也会模拟外部 API 超时，验证熔断降级是否生效。这些演练看起来多余，但真出问题的时候能救命。有一次外部搜索 API 大面积故障，因为之前演练过降级流程，系统自动切到备用源，业务基本没感知。
别忽视冷启动问题。Agent 实例刚启动时，模型加载、工具初始化都需要时间，这期间处理任务会很慢。AX 支持预热池，保持一定数量的空闲实例随时待命。对于延迟敏感的场景，预热池是必须的。我配置的是最少 2 个预热实例，任务高峰时新实例启动的延迟从 30 秒降到了 5 秒以内。
成本优化是个持续过程。我每个季度会 review 一次 Agent 的 Token 消耗，看看有没有优化空间。常见的优化点包括：压缩提示词、缓存重复调用结果、对简单任务降级到小模型、合并相似任务批量处理。这些优化加起来，我负责的 Agent 集群月度成本降了大概 40%。
