7月AI后端架构回顾从推理网关到Agent编排的关键技术决策复盘月度盘点不是流水账而是把散落的决策点串成一条可复用的经验链。一、开篇为什么需要月度技术复盘技术团队最容易陷入的误区是做完就忘。一个月经手四五个技术决策每个决策当时都经过了充分讨论但如果不做结构化沉淀三个月后面对类似场景还得从头再来。7月份围绕AI后端架构团队在推理网关、模型路由、Agent编排和成本优化四个方向上做了大量实践。本文将这些决策串联成一条完整的技术演进链路重点分析每个节点的tradeoff逻辑和下个月的演进方向。本文假设读者已有基本的LLM应用后端开发经验重点放在架构决策的方法论层面。二、核心决策链路的四阶段回顾2.1 推理网关统一入口的架构收益与代价7月落地的推理网关方案核心决策是将所有模型调用统一收敛到一个网关层而不是让各业务服务直连模型API。关键tradeoff总结决策维度直连模式网关模式模型切换成本高每个服务改配置低网关统一路由横切关注点散落各服务集中治理单点风险无网关自身高可用网络延迟0ms额外开销2~5ms代理延迟运维复杂度低中等实际落地中推理网关的投入产出比在模型数量超过3个、业务方超过5个时开始显著为正。早期团队如果只有12个模型、12个业务方不建议过早引入网关层。生产级配置示例基于APISIX网关的推理路由插件# apisix-inference-routes.yaml routes: - id: inference-gateway uri: /v1/inference/* upstream: type: chash hash_on: header key: X-Model-Name nodes: gpt-proxy.internal:8080: 1 claude-proxy.internal:8080: 1 open-source-cluster.internal:8080: 2 plugins: limit-req: rate: 1000 burst: 200 key: http_x_api_key prometheus: prefer_name: true proxy-rewrite: regex_uri: - ^/v1/inference/(.*) - /$12.2 模型路由从静态配置到动态决策推理网关之上7月重点打磨了模型路由层。核心演进是从配置文件写死模型映射升级到基于请求特征的动态路由。路由策略的四个维度// 模型路由决策核心逻辑 public class ModelRouter { public RouteDecision route(InferenceRequest request) { // 第一优先级任务类型匹配 TaskProfile task TaskClassifier.classify(request.getPrompt()); // 第二优先级延迟要求 if (request.getMaxLatencyMs() 500) { return RouteDecision.fastPath(task); } // 第三优先级成本预算 if (request.getBudgetTier() BudgetTier.LOW) { return RouteDecision.costOptimized(task); } // 第四优先级质量要求 if (request.getQualityRequirement() QualityLevel.PREMIUM) { return RouteDecision.premiumModel(task); } return RouteDecision.defaultRoute(task); } }7月实践的核心认知路由决策的准确性不取决于规则数量而取决于任务分类的精度。投入时间做Prompt意图分类比堆叠20条路由规则更有效。2.3 Agent编排从单次调用到多步协作Agent编排是7月复杂度跃升最大的模块。核心问题不是能不能调通而是编排的可靠性如何保证。实践中沉淀的Agent编排模式┌─────────────────────────────────────────────────┐ │ Agent编排器Orchestrator │ │ │ │ ┌─────────┐ ┌─────────┐ ┌───────────────┐ │ │ │ Planner │──▶│Executor │──▶│ Validator │ │ │ │ 任务规划 │ │ 工具调用 │ │ 结果校验重试 │ │ │ └─────────┘ └─────────┘ └───────────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────────────────────────────────────┐ │ │ │ 共享上下文Context Store │ │ │ └──────────────────────────────────────────┘ │ └─────────────────────────────────────────────────┘编排可靠性三板斧步骤级超时与重试每个Agent步骤独立超时默认30s失败自动重试重试时携带错误上下文检查点机制关键步骤完成后写入检查点编排器重启后可以从断点恢复兜底策略每个Agent步骤配置降级方案如优先Claude → 降级GPT-4o-mini → 最后规则引擎# Agent编排的步骤定义基于LangGraph的简化示例 from langgraph.graph import StateGraph, END class AgentState(TypedDict): task: str plan: list[Step] current_step: int context: dict checkpoints: list[str] def planner(state: AgentState) - AgentState: 规划步骤 state[plan] decompose_task(state[task]) return state def executor_with_retry(state: AgentState, max_retries: int 3): 带重试的执行器 step state[plan][state[current_step]] for attempt in range(max_retries): try: result execute_step(step, state[context], timeout30, fallback_modelgpt-4o-mini) state[context][step.id] result state[checkpoints].append(fstep_{step.id}_done) state[current_step] 1 return state except Exception as e: state[context][ferror_{attempt}] str(e) raise MaxRetryExceededError(step.id) graph StateGraph(AgentState) graph.add_node(plan, planner) graph.add_node(execute, executor_with_retry) graph.add_edge(plan, execute) graph.add_conditional_edges(execute, lambda s: END if s[current_step] len(s[plan]) else execute )2.4 成本优化从被动观察到主动控制7月成本优化最大的认知转变成本优化不应该是一个独立环节而应该嵌入到推理网关的每一次路由决策中。核心实践成本优化嵌入架构 请求进入 → 推理网关 │ ├─ 语义缓存命中 → 直接返回成本 0 │ ├─ 任务分类 → 低复杂度任务 → 路由到低成本模型 │ ├─ 批处理队列 → 非实时请求 → 合并批处理降低30%成本 │ ├─ 实时监控 → 单次成本超阈值 → 触发告警 │ └─ 日终结算 → 成本归因到业务线 → 推动业务优化Prompt三、各决策点的关联影响分析这四层决策不是孤立的它们之间存在强耦合网关层决策 ──影响──▶ 路由层灵活性 │ ▼ 编排层复杂度 ──影响──▶ 成本模型精度 │ ▼ 网关层监控指标设计举个例子如果推理网关选择了按模型维度做负载均衡那么路由层就无法按任务特征做细粒度调度——因为请求在网关层就已经被分流了。7月踩坑总结网关和路由的职责边界模糊最初将路由逻辑写在网关层导致路由策略变更需要重启网关。后来将路由独立为无状态服务网关只做透传。编排层的重试风暴Agent步骤失败后的重试没有做全局限制曾出现过一次任务触发300次模型调用的异常。解决方式是引入全局步数上限和token消耗上限。成本归因的粒度选择按请求维度过细存储开销大按业务线维度过粗无法定位问题Prompt。最终选择按业务线 任务类型做二维归因。四、8月演进方向预测基于7月的实践和行业动态8月重点关注三个方向方向一推理网关的智能化升级当前网关是规则驱动的8月尝试引入轻量级模型做请求预处理在网关上做请求的自动分类、敏感内容过滤、Prompt质量评分方向二Agent编排的标准化参考OpenAI的Agent SDK和Anthropic的Tool Use规范制定团队内部的Agent接口标准让不同业务线的Agent可以互相调用方向三成本优化自动化7月已做到成本可见8月目标是成本可预测基于历史数据建立成本预测模型预算超支前自动预警五、总结7月的AI后端架构实践可以浓缩为一条主线从能用到可控。推理网关解决的是接入可控模型路由解决的是质量可控Agent编排解决的是流程可控成本优化解决的是预算可控。回头看这四个模块的演进顺序是合理的。如果在推理网关还没做扎实的时候就跳去做Agent编排就会出现上层花哨、下层脆弱的问题。8月继续沿着这条路走——在可控的基础上追求智能可控。