面灵AI→

Awaken AI Agent 一面:图编排、幻觉治理与效果判定

轮次
一面
时间
2026-10
来源
牛客网

《面试题目》

  1. 第一个实习的 agent 项目是什么背景、解决了什么问题、为什么做 agent?
  2. 讲一下全流程,你负责的部分是什么?
  3. 这个图节点是怎么设计的?
  4. 如果跳步了怎么办,你是怎么保证它的稳定性的?
  5. 幻觉如何治理?
  6. 评测指标是什么?评测集多少?构建评测集的依据是什么?
  7. 为什么用 LangGraph,选型上为什么不用单 agent?
  8. 如果让你在这个编排好的图上再添加一些业务,你会怎么做?
  9. 前置校验和后置校验是怎么做的?
  10. 上下文怎么设计,为什么?
  11. 成本控制怎么做,执行失败怎么办?
  12. 如果执行到一半中断了怎么办?
  13. 如何知道用户是否满意,根据什么判断 agent 是否在用户层面上真的有效?
  14. 手撕:网格游戏。

《参考解析》

为什么做 agent 而不是一次调用:判断标准是「任务是否需要根据中间结果决定下一步」。如果需要多步查询、需要调用外部工具、需要在信息不足时主动追问,那单次调用做不了,才值得上 agent。反过来,如果流程固定、输入输出明确,用 workflow 或一次调用更快更稳更便宜。回答这题要给具体的不行场景,比如「用户问题里同时涉及两个系统,必须先查 A 才能知道去 B 查什么」。

图节点设计:节点粒度按「一个可独立验证的步骤」来切——检索、工具调用、校验、生成、反思。边分两类:确定性边(固定下一步)和条件边(按当前状态路由)。设计要点:每个节点有明确的输入输出 schema、每个节点可单独重放、状态(state)只存必要字段且不可变更新。这样出错时能定位到具体节点并只重跑那一段。

跳步与稳定性:跳步的根因通常是模型自己「认为」某步已完成,或者状态机没有强制约束。防法:用状态前置条件——每个节点执行前检查必需字段是否就绪,不满足就回退到缺失的那一步;用图结构而不是提示词来保证顺序(提示词里写「先做 A 再做 B」是不可靠的);给每一步留 trace,事后能复现。

幻觉治理:分层治理才有工程感。输入侧:检索到的材料不足时明确告知模型「没有依据就说不知道」,并带上出处。生成侧:要求结构化输出(结论 + 证据引用),用 schema 约束。校验侧:生成后做一次「论断-证据」对齐检查,引用不存在或不支持该论断就重写或降级。兜底层:高风险动作(写操作、金额、对外发送)必须人工确认或二次校验。真正治不了的是「材料本身错」,那要在数据源层面解决。

评测集怎么建:从真实日志采样 + 人工构造边界样本。规模不在多而在覆盖率:按意图分类、按难度分层(单步/多步/需追问/无解)、按输入形式分层(规范问法、口语、含错别字、多轮带指代)。每条样本要有期望行为而不只是期望答案——该追问的必须追问,该拒答的必须拒答,否则模型学会「硬答」反而更糟。

为什么用 LangGraph:核心是「把控制流从提示词里拿出来」。链式框架(LangChain 的 LCEL)适合线性流程;单 agent + 工具循环适合工具少、边界模糊的场景;LangGraph 提供显式状态机、条件边、可中断可恢复(checkpoint)、可回放,适合步骤明确但需要分支和重试的任务。选型理由要落到项目需求上:我们的流程有分支、要人工介入、要能从中断处恢复。

怎么扩展新业务:如果架构合理,扩展应该是「加一个子图 + 注册路由」,而不是改主流程。具体做法:新业务作为一个独立节点或子图,声明它的输入输出契约,主图通过路由器按意图分派;共享的状态字段只增不改,避免影响已有节点。评估方式是加回归用例,确保新业务不影响旧路径。

前后置校验:前置是「该不该执行」——参数是否齐全、权限是否具备、前置依赖是否满足;后置是「执行结果能不能用」——格式、值域、与预期的偏差、是否需要重试。两者的区别常被混淆:前置失败应该拦截并告知用户,后置失败应该重试或降级。

上下文与成本:上下文分层(系统提示 + 任务包 + 检索材料 + 历史摘要),长历史做滚动摘要而不是全量保留;工具描述按当前意图裁剪;稳定前缀利用 prompt caching。成本控制的具体手段:优先小模型做分类和抽取、限制最大轮次、失败快速止损、对同一请求做缓存。

执行中断怎么办:靠 checkpoint——每完成一个节点就把状态持久化,中断后从最后一个完成节点恢复,而不是从头重跑。要注意副作用幂等:已经调用过的外部写操作不能重复执行,用幂等键标记。

怎么判断 agent 真的有效:不能只看「回答得不错」。指标分三层:任务层(完成率、平均轮次)、交互层(追问率、用户重新提问率、会话时长)、业务层(转人工率、采纳率、后续动作转化)。最硬的是用户是否还需要人工接手——把「同一用户同一问题在 agent 之后又找人处理」的比例当作失败率的代理指标。