生产化与系统设计

从「能跑」到「稳跑」的分水岭。高定级题都在这里：兜底体系、成本延迟、流式、断点续跑。

一、设计一个企业智能客服 Agent（四层）

• 接入层：多渠道（Web/App/企微）、会话管理、用户上下文
• 决策层：意图识别 → 路由（能直接答 / 查知识库 / 调订单系统 / 转人工）→ 兜底策略
• 工具层：MCP 统一封装（订单查询、退换货策略、工单创建）、权限与埋点
• 数据层：FAQ 知识库（RAG）、用户/订单数据源、会话记忆存储

鲁棒性：工具失败重试降级、情绪识别升级人工（严重情绪不硬聊）、安全边界（退款/删数据等高危动作规则拦截 + 人工确认）。

为什么是 Supervisor 模式：5 个部门专家 → 清晰分类可扩展，下季度加「账单专家」= 加一个节点。

二、完整兜底体系（三层，不能说只 try-catch）

1. 工具层：try-catch → 结构化错误返回
2. 推理层：最大迭代次数 + 循环检测熔断，防死循环
3. 规划层：失败后让 Agent 反思重规划（换路径）→ 仍失败走降级

配套三级：重试（指数退避）→ 降级（部分结果/默认值）→ 人工兜底（HITL）。达到阈值自动终止，输出最优结果 + 风险提示，或转人工审核，保证服务不中断。

三、成本与延迟控制

• 模型分级（贵模型只做关键推理）
• 缓存（语义缓存：相同/相似 query 命中缓存）
• 工具结果压缩（减少上下文 token）
• 批处理/异步（低实时任务走队列）
• 控制 ReAct 步数与多 Agent 层数（每多一步 = 多一次往返 + 多一份 token）
• 检索 K 值压缩

多 Agent 成本账：每多一个 Agent/一次路由 = token 成倍 + 延迟增加——这也是「能用单 Agent 别硬上多 Agent」的工程理由。

四、流式输出（节点结果怎么实时推前端）

• 后端 FastAPI + SSE；LangGraph 用 astream_events(..., version="v2") 捕获 on_chat_model_stream（token 级）和各节点完成事件，转发给前端 EventSource
• 难点：每个节点的中间结果（「正在研究→正在撰写→审核中」）要打点成结构化事件（node 名 + 阶段 + 进度），而不是只推最终答案

SSE vs WebSocket：WebSocket 双向全双工，SSE 单向服务端推送——Agent 进度是服务端到客户端的单向流，SSE 更轻、原生支持重连，够用不必上 WS。

五、Checkpoint / 断点续跑

graph.compile(checkpointer=PostgresSaver.from_conn_string(...))

按 thread_id 存状态快照；中断（HITL interrupt）后可用同一 thread_id 恢复继续跑。临时 checkpoint 可用 Redis，永久业务状态落 PG。

部署选型：

• LangGraph Platform（托管）：自带 checkpoint/retry/横向扩缩
• 自托管：FastAPI + LangGraph + PG checkpointer

决定因素：数据主权 / 成本 / 已有基建。

六、生产化 Checklist

• 死循环兜底（迭代上限 + 超时）
• 工具失败的结构化错误 + 降级
• 评测体系（离线集 + 在线指标）挂 CI
• 全链路 trace（路由决策、工具调用、token 消耗）
• 成本与延迟监控（模型分级 + 缓存）
• 安全边界（权限最小化 + 高危操作人工确认）