百度后端 Go / Agent 一面：会话恢复、记忆冲突与评测
本场面试题
- SessionMessage 与 Transcript 分别保存什么，是否持久化？
- 长期记忆怎样检索和处理冲突？
- Reason Agent、Worker 与后端编排层怎样通信？
- 上下文怎样压缩，保留的最近消息本身超出窗口时怎么办？
- Agent 权限控制怎样做？
- 怎样证明 Agent 新版本优于旧版本？
- 按直播 ID 分表后，怎样查询用户点过赞的直播？
面经与参考答法
百度后端 Go / Agent 一面：会话恢复、记忆冲突与评测
这场百度后端 Go / Agent 一面围绕自动化红队 Agent 连续追问，从 Session、任务状态和长期记忆深入到权限、扩缩容、评测，最后设计高并发直播点赞系统。原记录没有明确面试日期。
本页选录以下十三组技术主题，未收录自我介绍、实习时间地点和岗位偏好；未展开 Reason Agent 具体调用哪些工具、Graph 是否是 Agent、Intent 是否等于传统用户意图识别、最近保留八条消息是否也参与全量摘要，以及万级直播间批写后的数据库总吞吐追问。短答为教学补充，不代表作者的实际实现或现场回答。
（1）自动化红队 Agent 的架构应该怎样介绍？
关联知识点待核实。
先说明测试目标和授权范围，再画出任务入口、规划器、攻击用例/工具、被测环境、状态存储、判分器和审计链路。红队 Agent 必须在隔离环境运行，限制目标、工具和速率；发现结果还要去重、复现和人工确认，避免把模型猜测当成漏洞。
（2）SessionMessage 与 Transcript 分别保存什么，是否持久化？
Transcript 是追加式原始事件日志，保留用户消息、模型动作、工具调用与结果；SessionMessage 是当前模型可见的窗口；检查点保存任务阶段、待办、关键状态和外部操作 ID。三者分离后既能审计重放，也能控制上下文长度。
延伸阅读：Agent 会话、检查点与任务状态存储。
（3）会话中断后怎样恢复，同时避免重新加载全部历史？
关联知识点待核实。
从最近检查点恢复结构化状态，加载已确认摘要和少量近期事件；需要细节时再按引用读取原始 Transcript。恢复前校验版本、权限和外部工具状态，对结果未知的副作用先查询再继续，不能简单重跑整条链路。
（4）TodoStore 怎样设计？提醒轮数如何确定？
关联知识点待核实。
TodoStore 应记录任务项、所有者、依赖、状态、更新时间和完成证据，由运行时在关键事件后更新。提醒阈值不能凭经验固定为五轮，应从真实轨迹统计“无进展步数”的分布，并按任务类型、工具延迟和误报成本设阈值；中位数更抗长尾，但最终要用漏提醒与误提醒指标验证。
（5）长期记忆怎样检索和处理冲突？
长期记忆应携带来源、时间、作用域、置信度和版本。检索先做用户与场景过滤，再做语义匹配；“喜欢简短”与后来“喜欢详细”冲突时，以更新且明确的用户表达覆盖当前值，同时保留历史以便审计，不应把两条矛盾偏好一起注入模型。
延伸阅读：遗忘策略、冲突处理与记忆更新。
（6）什么时候拆成 Agent，什么时候只是普通工具？
关联知识点待核实。
输入输出明确、步骤确定、无需自主决策的能力应做工具；需要根据中间结果动态规划、可独立拥有上下文或权限的长任务才考虑 Agent。多 Agent 增加通信、成本和一致性问题，默认优先单 Agent 加确定性工作流。
（7）Reason Agent、Worker 与后端编排层怎样通信？
让后端成为状态机和真相源：Agent 输出经过 Schema 校验后写入事件或任务状态，编排层根据确定规则触发下一步。Agent 负责语义判断，后端负责权限、幂等、并发和终态；格式校验失败只修复当前输出，不应重跑整个任务。
延伸阅读：多智能体消息、协议与状态同步、Agent 工具契约、Schema 与错误语义。
（8）上下文怎样压缩，保留的最近消息本身超出窗口时怎么办？
近期消息通常包含当前指代和未完成动作，但保留条数不应固定。先按 Token 预算保护目标、约束和关键工具结果，再动态选择近期事件；若单条结果已经过长，应外置正文、保留摘要与引用，而不是强行塞入窗口。
延伸阅读：会话摘要、压缩与记忆提炼。
（9）Agent 权限控制怎样做？
权限由服务端基于用户、任务和资源做判定，模型只能提出请求。工具按只读、可逆写入和高风险不可逆操作分级；高风险动作要求显式确认，凭证按最小权限短期下发，所有授权决定和执行结果进入审计日志。
延伸阅读：最小权限、授权与工具调用确认。
（10）多 Pod 部署时怎样管理内存 Session？
关联知识点待核实。
生产环境不应依赖粘性会话保存唯一状态，应将检查点放入共享持久化存储，并用租约或版本号控制并发更新。若使用一致性哈希做路由，应配置虚拟节点和迁移机制；扩缩容期间仍需共享状态兜底，不能把路由稳定性当成数据可靠性。
（11）怎样证明 Agent 新版本优于旧版本？
固定版本化测试集，比较任务成功率、严重失败率、工具选择与参数正确率、无效步骤、Token 和延迟，并按场景分层。LLM Judge 需要明确 rubric、参考证据和校准样本；大规模线上数据可先用规则和异常指标筛选，再对高风险或代表性样本抽样评审，控制评测成本。
延伸阅读：智能体性能评估、成功率、质量、延迟、成本与业务指标。
（12）直播点赞系统怎样设计表和事务？
关联知识点待核实。
至少区分点赞关系表与直播聚合计数。关系表用用户与直播的唯一约束保证幂等；计数可通过事务内更新、Outbox/消息队列异步聚合或定期校准。热点直播避免所有请求竞争同一行，可先在缓存或分片计数器累加，再批量落库，并明确最终一致性边界。
（13）按直播 ID 分表后，怎样查询用户点过赞的直播？
单一 live_id 分片只优化直播维度查询，会让用户维度变成全分片扫描。可建立按 user_id 分片的反向索引或专用查询表，通过事件异步双写并用对账修复；系统设计前应先列出两类访问模式，再决定主表与派生表。
延伸阅读：分库分表、读写分离与扩展。