工程化与部署

是什么

把 Agent 从脚本变成稳定、可观测、可扩展、可控成本的服务：API 化、异步化、缓存、限流、降级、灰度。

为什么需要

Demo 跑通 ≠ 生产可用。真实流量下会暴露：同步阻塞、成本失控、依赖超时、单点故障。部署意识决定 Agent 能否真正产生价值。

核心实践

• 服务化：提供同步 API（短任务）与异步任务（长任务 + 回调/轮询），避免请求挂死。
• 并发与排队：用队列（如消息队列）削峰，限制并发调用模型的数量。
• 限流与配额：按用户/租户限流，防止单用户拖垮全局。
• 语义缓存：相同/相似问题命中缓存，直接返回，省 token 又提速。
• 降级兜底：模型不可用时，回退到规则/小模型/静态话术，保证可用性。
• 成本看板：按功能、用户、模型维度统计 token 与费用，定位浪费。

最小范式（语义缓存）

def answer(query):
    hit = cache.get(embed(query), threshold=0.95)   # 语义相似即命中
    if hit:
        return hit, "cache"
    ans = run_agent(query)
    cache.put(embed(query), ans)
    return ans, "fresh"

成本优化清单

• 长上下文用便宜模型做路由/摘要，贵模型只做关键决策。
• 精确控制 max_tokens，避免模型滔滔不绝。
• RAG 只召回必要 chunk，减少输入 token。
• 高频问答开启语义缓存。

常见陷阱

• 同步阻塞调用：用户请求一直等待 Agent 跑完，超时即失败。长任务务必异步化。
• 无超时：模型/工具调用不设超时，一个慢依赖拖垮整条链路。
• 成本黑盒：上线后才发现每天烧掉大量 token，却说不清花在哪。
• 单点故障：Agent 强依赖某个不可控外部 API，对方抖动即全线不可用。

参考

• VitePress 之外的后端部署文档（FastAPI / 消息队列 / 网关）
• 各云厂商 LLM 网关与限流文档
• 语义缓存（如 GPTCache）相关项目文档