百度大模型研发工程师二面：全程 Agent 架构大局观 + 状态机手撕

《面试题目》

1. 解释什么是「Agent 应用」？一个面向 C 端的 Agent 应用包括哪些架构和模块？从用户交互到任务执行到结果输出，完整的模块划分是什么？
2. 你觉得当前的 Agent 系统最大的工程挑战是什么？是上下文管理？工具调用可靠性？成本控制？评测体系？还是别的？如果你有无限资源，你会优先解决哪个问题？
3. 如何理解 Prompt Engineering → Context Engineering → Harness Engineering 的演进？三者有什么区别？
4. 如果让你设计一个通用 Agent Runtime，要兼容 OpenAI、Anthropic、国产模型等多个厂商的 API，你怎么设计？怎么抽象？
5. Agent 在 C 端大规模部署的时候 Token 成本很高，你怎么控制成本？有哪些具体的优化策略？
6. 如果 Agent 需要生成代码并在沙箱里执行，你怎么设计安全的沙箱环境？有哪些必须考虑的安全风险？
7. Agent 的上下文越来越长，快超过 Context Window 时一般怎么处理？
8. 如果让你设计上下文压缩方案，你会保留哪些信息？丢弃哪些？
9. 长期记忆和短期记忆怎么实现？存储方案分别是什么？
10. 如果记忆冲突了怎么办？怎么判断哪条记忆更可信？
11. 多 Agent 协作时，Agent 之间怎么通信？用过消息队列吗？还是共享内存？
12. 多 Agent 并行执行时，怎么管理不同任务的执行状态？最终输出怎么汇总？
13. 主 Agent 和子 Agent 之间怎么同步状态？
14. 如果某一个子 Agent 挂了，怎么处理？怎么保证任务不丢失？
15. 你怎么评估 Agent 平台的效果与可靠性？关注哪些指标？
16. 如何通过 Agent 实现研发效能提升？具体怎么做？
17. 你们这套 Agent 方案是业务提效还是可复制给全公司？推广的难点在哪？
18. 一个需求直接由 Agent 交付有什么问题？出过风险吗？怎么解决？
19. Agent 自动回滚的触发条件是什么？阈值怎么衡量和配置？
20. 你怎么理解 Agent 和普通大模型调用的本质区别？除了工具调用，Agent 还多了哪些能力？
21. 如果 Agent 调用外部服务超时了，超时时间怎么设置？重试策略是什么？重试会不会导致重复操作？
22. 在电商场景下，Agent 如何保证库存扣减的准确性？幂等怎么设计？
23. 你们的 Agent 系统怎么处理分布式事务？Saga 模式？TCC？还是别的方案？
24. 如果让你设计一个「智能客服 Agent」来处理退换货，你会怎么设计？涉及哪些工具？
25. 你们的 Agent 和传统 API 服务有什么区别？在部署、监控、运维上有什么不同？
26. 你怎么做 Agent 的监控和告警？关注哪些指标？告警阈值怎么设置？
27. 如果 Agent 服务挂了，怎么保证用户无感知？有没有做熔断、降级、限流？
28. 你怎么做 Agent 的灰度发布？怎么保证新版本不出问题？
29. 如果 Agent 生成了违规内容，你怎么检测和拦截？
30. 多模态在 Agent 中能做什么？比如用户上传截图，Agent 怎么理解？
31. 如果让你设计一个企业知识问答 Agent，对接飞书／钉钉／邮件，整体方案怎么做？
32. 手撕题：实现一个有限状态机（FST）来管理 Agent 的状态。追问：状态数量扩展到 50 个怎么维护、会不会爆炸？状态之间有并发跳转怎么处理？

《参考解析》

Agent 应用的模块划分，按「一次请求的完整生命周期」讲：接入层（会话、鉴权、限流）、编排层（Planner／Router，决定单步还是多步、走哪个技能）、执行层（工具注册与调用、MCP 适配、沙箱）、上下文层（会话历史、检索、记忆读写、压缩）、模型层（多厂商 Provider 抽象、路由与降级）、产出层（流式输出、引用与审计），再加可观测性、评测与成本账。回答时最好画一条数据流：用户输入 → 意图识别 → 规划 → 工具执行 → 结果回灌 → 生成 → 输出落库，并说明每一步的失败边界与兜底者。顺着这条线再谈能力演进就顺了：Prompt Engineering 解决「模型不知道该干什么」，Context Engineering 解决「模型看到了什么」，Harness Engineering 则是模型之外那层工程骨架（工具契约、状态机、重试校验、审批回滚、评测灰度），越往后越承认模型不可靠、把确定性交回代码——能写代码判断的绝不让模型判断。

通用 Runtime 的抽象点在「消息与工具」而不是「厂商」：上层只认统一的内部协议（消息角色、内容块、工具调用与结果、usage、结束原因），每家厂商 SDK 只写在 Provider 适配器里做双向转换，并补齐各家差异（工具调用格式、是否支持并行调用与结构化输出、缓存字段、思考等级参数）。再往上要有能力声明表（支持哪些特性）加路由策略（成本、延迟、可用性），配降级链、超时、重试与熔断；模型名与参数走配置中心而不是散落在调用点。会话状态与上下文拼装留在 Runtime 内，Provider 层保持无状态可替换，这样换模型不改业务代码，也才能对同一 Prompt 做跨厂商效果对比。

上下文压缩与记忆要做分层，不能只靠「摘要一下」：短期上下文按优先级保留——系统约束与工具契约永不丢，最近 N 轮原文保留，早期历史压成结构化摘要，工具返回只留结论与关键字段（大结果落盘存引用，需要时再取回）。摘要要有固定格式（目标、已完成、待办、已知约束、关键事实），每次压缩后校验关键信息没丢，逼近窗口前提前压缩而不是等报错。长期记忆分事实型（用户偏好、身份、稳定画像）与情景型（历史任务与结论），前者存结构化库或 KV，后者走向量库加元数据过滤；写入要有准入（避免噪声污染）、过期与覆盖策略、去重合并。记忆冲突时按「显式来源优先于模型推断、时间近优先于旧、可信来源优先于闲聊」排序，冲突不可解就让用户确认一次，而不是悄悄选一条。

多 Agent 协作，先想清楚「为什么不是一个大 Agent」：拆分要按职责与上下文隔离，而不是按角色热闹。通信通常走消息队列或共享任务表（有状态、可重放），共享内存只适合同进程；每个子任务要有唯一 ID、状态机（pending／running／succeeded／failed／canceled）、超时与心跳，主 Agent 只订阅状态、汇总结果，不做长阻塞等待。子 Agent 挂掉靠「任务落库 + 可见性超时 + 至少一次重投」保证不丢，重投必须配合幂等键，否则会重复扣库存、重复发通知；汇总时要处理冲突（同字段多来源取更可信或让模型裁）并保留证据链。再加一条：并发度要限流，否则上游模型和下游工具会一起被打爆。

可靠性与评测：Agent 的运维和传统服务不是一回事：超时按「工具自身 SLA × 重试次数」倒推设置，重试要区分可重试（超时、5xx）与不可重试（参数错、4xx），写操作必须带幂等键或走「先查状态再执行」。监控指标分层：请求层（QPS、P95 延迟、错误率、流式中断率）、模型层（Token 与成本、缓存命中、限流降级次数）、工具层（调用成功率、平均步数、回环次数）、质量层（任务完成率、拒答率、用户反馈、违规拦截率）。评测用固定评测集跑确定性指标加模型评审，低分 Case 回流成回归样本；灰度按用户或会话分桶，先看完成率与成本有没有退化；熔断降级到「只答不调工具」这类保守模式；违规内容走输入过滤加输出审核双闸，全程留审计日志。

状态机手撕：先画状态与转移，再写表驱动实现：能过面试的写法是 Map<state, Map<event, nextState>> 加 transition(state, event)，非法转移抛错或返回错误码，配 onEnter 钩子做副作用。追问的扩展点是：状态到 50 个时不要写 if-else 树，改成配置化转移表（YAML 定义 + 校验：连通性、终态不可出、无歧义转移），必要时用分层状态机让父状态共享转移；并发跳转要给每次转移带版本号做乐观锁，或用单线程事件循环／实例锁串行化，冲突就拒绝并重新决策；再加超时转移（长时间无事件回到兜底态）与审计日志，这套东西才真能管 Agent 的生命周期。