真实面经题目 · 原创解析

构建复杂 LLM Agent 时最主要的挑战是什么,如何处理可靠性、规划、工具调用和可观测性?

这题考复杂 Agent 的生产可靠性理解。高质量回答要说明最大的挑战不是“会不会用框架”,而是 LLM 非确定性、规划漂移、工具误调用、上下文污染、循环失控、成本延迟和问题定位困难,并给出工程化治理方案。

出现于:字节跳动 · AI 应用开发

60 秒回答模板

构建复杂 LLM Agent 时,最主要的挑战是可靠性和可控性。Agent 不只是回答文本,它会拆任务、调用工具、读取外部数据甚至改变业务状态;而 LLM 输出天然有不确定性,所以同一个任务可能出现不同计划、错误参数、重复调用、陷入循环或忽略工具结果。复杂度越高,链路越长,问题越难定位:一次失败可能来自意图识别、上下文污染、planner 选错步骤、工具描述歧义、参数 schema 不严、工具服务超时、权限不足或最终总结幻觉。 治理要分层。规划层要把任务拆成有限状态或工作流,明确开始、步骤、停止条件、重试预算和失败出口;不要让模型无限自由规划。工具层要有清晰的工具描述、严格 schema、权限校验、幂等键、超时、熔断、重试和降级;高风险动作要 dry-run、用户确认或人工审批。上下文层要做 token budget、短期记忆、长期记忆、RAG 证据、工具结果和用户输入的优先级管理,避免过期记忆或无关证据污染决策。 可观测性是复杂 Agent 能上线的前提。每次运行要记录 trace:用户目标、上下文摘要、计划、候选工具、最终工具、参数、工具返回、重试、成本、耗时和最终答案。评测不能只看最终回答,要看任务成功率、工具选择准确率、参数合法率、循环率、人工接管率、P95 延迟、单任务成本和安全拦截。最后用历史 badcase 建回归集,持续改 prompt、planner、工具描述、schema 和降级策略。

考点 框架不是答案
难度 真实面经题
回答目标 让面试官看到你理解复杂 Agent 的真实难点在生产可靠性、边界控制和可观测闭环,而不是停留在框架名词。

深入解析

01

可靠性是核心挑战

复杂 Agent 的失败不只是答错一句话,而可能执行错误工具、修改错误对象或给用户虚假完成状态。LLM 非确定性会放大规划、填参和解释环节的不稳定性,所以可靠性必须靠运行时约束和评测闭环保障。

02

规划要有边界

让模型完全自由规划容易出现路径漂移、步骤遗漏、重复调用和无限循环。工程上可以用状态机、workflow、Plan-and-Execute、任务模板或步骤校验器约束关键流程,并设置最大步数、重试预算和明确停止条件。

03

工具调用要治理

工具越多,越容易出现工具描述冲突、近义工具误选、参数漏填和副作用失控。每个工具都要有适用条件、禁用条件、输入输出 schema、权限、超时、错误语义和幂等要求;执行前必须经过系统校验。

04

上下文会污染决策

Agent 同时使用用户输入、历史对话、记忆、RAG 证据和工具结果。旧记忆、无关检索片段、失败工具结果或过长上下文都可能误导下一步计划。需要按任务目标做优先级、摘要、过期、引用和冲突处理。

05

观测决定能否排障

复杂 Agent 失败时,只看最终回答没有意义。必须记录从用户目标到每一步计划、工具候选、参数、工具返回、重试和最终输出的 trace。这样才能判断问题在模型、planner、工具描述、参数生成还是工具服务。

06

评测要看过程指标

Agent 评测不能只看人工满意度。还要看任务完成率、工具选择准确率、参数校验通过率、无效调用率、循环率、失败恢复率、人工接管率、P95 延迟、token 成本和安全违规率,才能支撑上线决策。

易错点

  • 只列 Agent 框架名字,不解释复杂 Agent 为什么不稳定。
  • 把可靠性问题都归因于模型能力,忽略 planner、工具、上下文和服务治理。
  • 没有设置最大步数、重试预算、停止条件和人工接管,导致循环失控。
  • 只评估最终回答,不评估工具选择、参数合法性、成本、延迟和安全拦截。
  • 忽略 trace 和日志,导致线上失败无法复现也无法回归。

面试官追问

如何避免 Agent 陷入无限循环?

设置最大 step、最大工具调用次数、总超时、重复动作检测、无进展检测和停止判定。连续失败时应触发降级、澄清或人工接管,而不是让模型继续尝试相同动作。

工具描述写清楚为什么重要?

模型主要靠工具名称、描述和 schema 判断是否调用。如果描述重叠或禁用条件不清,模型会把相似工具混用。好的描述应说明适用场景、不要使用的场景、参数含义、返回语义和错误处理方式。

复杂 Agent 的 badcase 如何复盘?

先按 trace 定位失败阶段,再归类为意图错误、规划错误、工具选择错误、参数错误、工具服务错误、上下文污染或最终回答错误。每类代表样本要进入回归集,并对应修改 prompt、planner、schema、工具服务或降级策略。

多 Agent 是否一定比单 Agent 更好?

不一定。多 Agent 可以分工,但会带来通信成本、状态同步、责任边界、冲突解决和延迟成本。任务边界清晰、角色能力差异明显时才适合拆分;否则单 Agent 加 workflow 可能更稳定。