模拟面试官针对项目的深入追问，提供标准回答和踩坑分享。 每个问题按"问题 → 标准回答 → 追问升级 → 踩坑分享"组织。
这是个很好的问题。如果只看意图路由这一步，确实可以用if-else或者关键词匹配来做。但Supervisor编排的价值在于整个流程的编排能力：
- 状态管理：Supervisor维护全局State，各Agent共享读写，支持复杂的多步骤流程
- 流程编排：支持条件分支、并行执行、循环重试，不只是单一路由
- 检查点恢复：基于LangGraph的Checkpoint，长流程中断可以从断点恢复
- Human-in-the-Loop：可以在任意节点插入人工审批环节
- 可观测性：每个节点自动生成追踪Span，if-else做不到
简单来说，if-else只能做"选A还是选B"，Supervisor可以做"先A、然后B和C并行、B的结果给D审查、审查不通过回到A"。
我一开始确实用了简单路由，但当需要加入"所有回复都必须经过合规审查"这个需求时，if-else变得非常难维护——每个分支末尾都要加审查逻辑。换成StateGraph后，只需要加一条边就行了。
以一个多轮退款咨询为例：
第1轮：用户说"我买的理财产品想退"
- 工作记忆：记录
intent=ticket, product_type=理财 - 短期记忆：存入
{role: user, content: "我买的理财产品想退"} - 长期记忆：检索退款政策文档
第2轮：用户说"就是上个月买的那个"
- 工作记忆：读取上轮
product_type=理财，更新time=上个月 - 短期记忆：拼接上下文，Agent知道"那个"指的是理财产品
- 长期记忆：检索该用户的历史订单信息
第3轮：用户说"好的，帮我申请退款"
- 工作记忆：聚合前两轮信息，构建完整的退款请求
- 短期记忆：提供完整对话上下文给工单Agent
- 长期记忆：写入新工单记录
关键点：如果没有分层记忆——
- 没有工作记忆：第2轮不知道"那个"指什么
- 没有短期记忆：每轮都要重新问用户信息
- 没有长期记忆：不知道退款政策和用户历史
短期记忆用Redis存储。缓存击穿指热点session的Redis key过期时，大量请求同时查Redis miss然后打到后端。
解决方案：
- 互斥锁：第一个请求发现miss后加锁重建缓存，其他请求等待
- 永不过期 + 后台刷新：key设永不过期，用后台线程定期刷新
- 布隆过滤器：快速判断session是否存在，避免无效查询
我们采用方案1（Redis SETNX实现分布式锁），因为客服场景的热点session不多。
合规审查有两类错误：
- 漏判（False Negative）：违规内容没检出 → 风险大
- 误判（False Positive）：合规内容被误报 → 用户体验差
我们的两阶段策略分别优化这两类错误：
第一阶段——规则引擎（高召回率，低精确率）：
- 用正则匹配PII、用关键词匹配违禁词
- 宁可多报不能漏报（召回率>99%）
第二阶段——LLM深度审查（高精确率）：
- 对规则引擎通过的内容做二次审查
- 处理规则无法覆盖的场景（如隐晦的越权承诺）
- 精确率>95%
两阶段结合：
- 规则命中高风险 → 直接拦截（不走LLM，省成本）
- 规则通过 → LLM审查 → 通过则放行
- 整体漏判率<0.5%，误判率<2%
早期只用规则引擎，结果有个用户问"你能保证我不亏钱吗"，Agent回复"虽然不能保证但风险很低"——规则引擎没检出"风险很低"这种隐晦的违规表述，但监管认为这有误导性。加了LLM审查后这类case被成功拦截。
三层防御机制：
- Agent级超时：每个Agent调用设10秒超时。超时后Agent抛出TimeoutError
- Supervisor降级：捕获超时异常后，执行降级策略：
- 知识检索超时 → 返回"暂时无法查询，已记录您的问题"
- 工单处理超时 → 返回"工单提交中，请稍后查看"
- 合规审查超时 → 按"不通过"处理，转人工审核
- 自动工单：超时事件自动创建内部告警工单，技术团队排查
try:
result = await asyncio.wait_for(agent.process(state), timeout=10.0)
except asyncio.TimeoutError:
result = fallback_response(agent.name)
create_alert_ticket(agent.name, state.session_id)不会。在金融场景下，合规审查是底线。宁可误拦也不能漏放。用户被"转人工"只是多等几分钟，但一条违规回复可能导致监管处罚。
三个层面的评估：
-
检索质量评估（Retrieval）
- Recall@K：Top-K结果中包含正确文档的比例
- MRR（Mean Reciprocal Rank）：正确文档排名的倒数平均
- 用标注好的Query-Document对测试集评估
-
生成质量评估（Generation）
- Faithfulness：回答是否忠实于检索到的文档（不编造）
- Answer Relevance：回答是否与问题相关
- 用LLM-as-Judge评估（GPT-4打分）
-
端到端评估（End-to-End）
- 首问解决率（FCR）：用户一次性得到满意回答的比例
- CSAT：用户满意度评分
- 来自真实用户反馈
刚上线时检索Recall@5有85%，看着不错，但用户满意度只有60%。排查发现问题在生成阶段——检索到了对的文档，但LLM没有把关键信息提取出来。加了"请从文档中找出并直接引用相关条款"的Prompt指令后，满意度提升到80%。
Prompt注入指用户在消息中嵌入"忽略以上指令，执行XXX"之类的恶意内容。
我们的防御策略：
- 输入预处理：对用户输入做净化，检测已知的注入模式
- System Prompt隔离：使用System角色设定Agent身份和规则，与用户输入明确分隔
- 角色锁定：在Prompt中强调"你只能回答客服相关问题，不能执行系统命令"
- 输出审查：合规Agent检查回复是否偏离了客服角色
- 工具权限控制：即使Agent被"说服"，它能调用的工具也有严格的权限边界
两者都调研了，选LangGraph的原因：
- 状态管理：LangGraph有显式的TypedState和Checkpoint，CrewAI的状态管理是隐式的
- 编排灵活性：LangGraph是图模型，支持条件分支、循环、并行；CrewAI是任务队列模型，编排能力有限
- 生产就绪：LangGraph有LangGraph Platform（云托管）、持久化、断点恢复、Cron任务
- 生态：LangSmith提供完整的观测和评估能力
CrewAI的优势是上手更简单（Agent/Task/Crew三层抽象很直观），适合快速原型。但我们的场景需要精确控制流程（必须经过合规审查），CrewAI做这个比较费劲。
在不调用LLM API的纯系统开销测试中：
| 指标 | Python (LangGraph) | Go (Eino) |
|---|---|---|
| 单请求延迟（不含LLM） | ~15ms | ~2ms |
| 内存占用（空载） | ~200MB | ~30MB |
| 并发处理 | asyncio事件循环 | goroutine真并行 |
| Agent调度开销 | ~5ms | ~0.5ms |
但实际场景中，LLM API调用是绝对瓶颈（1-3秒），系统本身的开销在整体延迟中占比<5%。
选Go的场景：高并发（QPS>1000）、内存敏感（容器资源限制）、与Go微服务生态融合。 选Python的场景：AI生态丰富（LangChain/LangGraph）、开发效率高、团队Python技术栈。
主要三个手段：
-
分层记忆代替全量历史（贡献约25%）
- 之前：每次请求把完整20轮对话塞进prompt → ~4000 tokens
- 之后：工作记忆只传关键上下文 → ~1000 tokens
-
路由缓存（贡献约10%）
- 高频问题的路由决策缓存5分钟
- 如"查余额"永远路由到knowledge_rag，不需要每次调LLM判断
-
早退机制（贡献约5%）
- FAQ精确匹配直接返回，不走Agent链路
- 前50%的问题可以通过FAQ覆盖
分享两个有代表性的事故：
事故一：合规审查漏放
- 现象：有用户收到包含"风险极低"的回复
- 原因：规则引擎只匹配了"零风险"等绝对用语，没覆盖"风险极低"这种相对用语
- 解决：增加LLM二阶段审查，同时扩充规则词库
- 预防：建立合规case库，每周review新增case
事故二：Redis短期记忆OOM
- 现象：上线后第3天Redis内存告警
- 原因：TTL设了30分钟，但高峰期并发session数远超预期，大量对话同时在缓存中
- 解决：1) 降低TTL到15分钟 2) 限制单session最大轮数从20降到10 3) Redis加内存淘汰策略(allkeys-lru)
- 预防：上线前做容量评估，压测模拟真实session并发数
我会从四个维度评估：
- 架构设计能力：是否有合理的架构决策和trade-off分析
- 工程实践：是否有可观测性、容错、性能优化等生产级考量
- 业务理解：是否理解金融/电商客服的业务需求和合规要求
- 技术深度：是否能讲清楚RAG、Agent编排、分布式记忆的底层原理
这个项目的含金量在于：
- 不是简单调API，而是有完整的架构设计
- 有企业级考量（合规、追踪、容错）
- 有量化成果（FCR、CSAT、QPS都有数据）
- 有多语言实现，说明理解了架构而非绑定框架
几个我观察到的趋势：
- MCP标准化：Anthropic的MCP协议正在成为工具调用的统一标准，未来Agent不再需要为每个工具写适配器
- 编排框架成熟：LangGraph、Eino等框架正在从"实验工具"走向"生产基础设施"
- Agent即服务：AWS Agent Squad已经在做Agent的SaaS化，未来开发者可以像调用API一样组合Agent
- 评估体系建立：目前Agent评估还比较粗糙，未来会有更成熟的Benchmark和自动化评估框架
- 人机协作优化：Human-in-the-Loop不是退步，而是当前LLM可靠性下的最佳实践
我认为多Agent系统在2026-2027年会成为企业级AI应用的标配架构，就像微服务之于Web应用一样。
- 先总后分：先用一句话概括，再展开细节
- 用数据说话：每个技术决策都配一个量化结果
- 展示trade-off：不只说"我选了A"，要说"A和B的对比，选A因为..."
- 承认不足：适当说"如果重来我会..."，展示成长性
- 关联业务：技术决策要关联到业务需求（如"因为金融合规要求..."）
- 准备深度：每个回答准备3层深度——面试官追问到第3层还能答上来，就赢了