工程化
这一类题最能区分“做过 Demo”和“做过系统”。面试官会借它判断你是否有把 Agent 放进真实业务环境的能力，因为一聊到评估、监控、安全、放量和恢复，纸上方案和真实上线经验的差别会非常明显。
这一页建议按“上线前怎么卡、上线后怎么看、出问题怎么收”这条线来读。先用短答版记住核心结论，再用深答版补分层评估、发布门禁、告警设计、回滚和人工接管这些运行机制，这样你回答工程题时更像在讲一个可上线系统，而不是在列 checklist。
高频题
1. Agent 怎么做评估？
题目：传统服务能看接口正确率，Agent 这么开放，评估该怎么做？
面试官想听什么：你是否知道 Agent 评估不能只盯最终答案，而要分层看过程和结果。
短答版：我会做分层评估。底层看工具正确性和权限边界，中层看任务链路是否按预期推进，高层看最终任务完成质量；不能只看一句最终回答像不像对。
深答版：
展开深答版
这题的本质是建立 Agent 的评估分层。Agent 是开放系统，同一个任务可能走出不同路径，所以如果你只看最终答案，很难知道问题到底出在工具层、规划层、状态层还是模型决策层。
真正稳的评估应该至少拆成三层：底层看工具正确性和权限边界，中层看链路推进是否稳定、阶段是否按预期收敛，高层才看最终任务质量和用户价值。也就是说，Agent 评估不能只看“答得像不像对的”，还要看“过程是不是可靠的”。
工程上，分层评估确实会增加数据集、日志和标注成本，但它能显著提升迭代效率。你可以记成：
Agent 评估要同时看过程和结果。追问方向：离线评估和线上监控分别适合抓什么问题？
2. Agent 上线后最该监控什么？
题目：如果只能先打几类核心监控，你会优先监控哪些指标？
面试官想听什么：你是否知道生产环境里哪些信号最能反映 Agent 是否真的可用。
短答版：我会先盯任务完成率、工具失败率、人工接管率、延迟、token 成本和高风险操作触发情况。这些指标能同时反映质量、效率和风险。
深答版：
展开深答版
这题的核心判断是，Agent 监控必须同时覆盖结果、过程和风险。只看平均响应时间远远不够，因为一个 Agent 可能响应很快但任务经常失败，也可能看起来完成率不错，但成本失控、人工接管飙升。
所以更高价值的核心指标通常是任务完成率、工具失败率、人工接管率、延迟、token 成本和高风险操作触发情况。前几项更接近业务价值和链路健康，后几项更接近系统可运营性和安全边界。
工程上，第一阶段先打少量高价值指标，比一口气采集海量日志更实用。你可以记成：
Agent 监控不是只盯快不快，而是盯成没成、稳不稳、危险不危险。追问方向：为什么只看平均响应时间对 Agent 不够？
3. Agent 的安全边界怎么做？
题目：如果 Agent 能读文件、跑命令、访问网络，怎么避免越权？
面试官想听什么：你是否把安全理解成系统级防线，而不是“写一个很严格的系统提示词”。
短答版：核心是把边界放在运行时，而不是 prompt。常见做法包括工具白名单、参数校验、人工确认、沙箱执行、审计日志和最小权限原则，安全要做成分层防线。
深答版：
展开深答版
这题的本质是安全边界必须系统化。只要 Agent 能读文件、跑命令、访问网络，它就已经具备高风险能力，所以你必须默认它会遇到模型误判、输入污染、工具描述歧义和恶意外部内容。
安全不是一条规则，而是一层层防线叠起来的结果。工具暴露范围、参数约束、执行沙箱、人工确认、操作审计、最小权限和异常回滚，这些共同组成真正的系统边界。靠系统提示词说“不要做危险动作”，只能算软提醒，不能算安全设计。
工程上，这些护栏会牺牲一点自动化流畅度，但换来可控性和上线资格。你可以记成：
安全边界要落在运行时，不要落在文案里。追问方向：Prompt Injection 为什么本质上是“输入污染问题”，不只是提示词问题？
4. Agent 的成本怎么控？
题目：如果系统功能可以跑，但 token 成本太高，你优先从哪下手？
面试官想听什么：你是否知道成本控制要从结构入手，而不是一句“换便宜模型”。
短答版：我会先找大头，通常是长上下文、无效重试、低价值大模型调用和召回冗余。然后再用模型路由、上下文裁剪、缓存和更稳的失败处理去收缩成本。
深答版：
展开深答版
这题的核心判断是，成本问题通常首先是系统设计问题，而不只是模型价格问题。很多 Agent 成本高，并不是因为模型单价太贵，而是因为上下文太长、计划过度、无效重试太多、低价值节点也在用最强模型，或者召回和回写信息严重冗余。
所以控成本的第一步不是盲目降模型，而是先找到成本大头。要先搞清楚钱花在哪一层，是上下文、是链路长度、是工具重试，还是模型路由失衡。只有定位了主因，后面再谈缓存、裁剪、模型分层、批处理和失败治理才有意义。
工程上，把昂贵调用留给高价值节点，往往比统一降配更有效。你可以记成：
先找成本大头，再谈模型降配。追问方向：为什么“多模型路由”通常比“一把梭哈最强模型”更适合生产？
5. Agent 出错后怎么恢复？
题目：如果任务中途失败，怎么避免整条链路从头再来？
面试官想听什么：你是否意识到“恢复能力”是生产系统和 demo 的分水岭。
短答版：工程上要有可恢复状态，而不是只有最终自然语言答案。常见做法包括持久化中间状态、保存工具结果、明确阶段边界和支持人工接管。
深答版：
展开深答版
这题本质是在谈系统有没有连续运营能力。Demo 可以失败就从头再跑，但生产系统如果每次异常都重来，不仅成本高，很多外部操作还可能已经产生副作用，根本不能简单重放。
所以恢复能力的关键不是“失败后还能回答一句话”，而是系统是否保存了足够的中间状态。阶段边界、工具结果、任务快照、执行轨迹、人工介入点，这些都属于运行时设计，它们决定了系统能不能断点续跑、能不能局部回滚、能不能交给人接手。
工程上，恢复能力会增加状态管理复杂度，但这是生产系统和 demo 的分水岭。你可以记成：
能恢复，才算能上线。追问方向：如果没有状态持久化，哪些故障会特别难排查？
扩展题
6. Agent 发布前要设哪些门禁？
题目：如果一个 Agent 功能准备上线，你会设置哪些 release guardrails，避免“能跑但不敢发”？
面试官想听什么：你是否知道上线不是点按钮，而是先定义哪些风险绝对不能带进生产。
短答版：我会把门禁分成质量、安全、成本和回退四层。至少要有关键用例回放通过、高风险工具受控、成本没有明显漂移、失败时能快速止损，不满足就不放量。
深答版：
展开深答版
这题核心不是“上线前多测一点”，而是把上线标准做成明确门槛。Agent 的问题常常是看起来能回答，但一进真实流量就可能在权限、成本、链路稳定性和危险动作上失控，所以门禁必须覆盖最容易出事故的点。
一个实用的思路是按质量、安全、成本和回退四层设门禁。比如关键任务集回放必须通过，高风险工具必须受控，异常率和预算不能明显漂移，版本必须可切回。门禁不是越多越好，但该卡死的点必须是硬条件，而不是讨论题。
工程上，把门禁做成发布流程里的自动化检查，才是可持续的做法。把上线标准留到人工拍板时再争，通常说明系统还没准备好进入生产。
追问方向：哪些指标适合做硬门禁，哪些更适合上线后持续观察？
7. 回放评估为什么重要？
题目：为什么很多团队会做 replay-based evaluation，而不是只靠人工 spot check？
面试官想听什么：你是否理解回放评估的价值在于复现实流量、定位回归，而不只是多跑一轮测试。
短答版：因为 Agent 的问题很多出在线上真实输入分布，人工抽查覆盖太差。回放评估能把历史任务按新版本重跑，对比成功率、轨迹、成本和风险信号，抓回归更稳。
深答版：
展开深答版
这题本质是在谈评估数据是否贴近生产。静态题库适合做底线检查，但 Agent 很多退化其实来自真实用户输入分布、上下文噪声和工具响应不稳定，这些靠人工 spot check 很难覆盖。
回放评估的价值不在于百分百还原线上，而在于用可复现的历史样本比较新旧版本，重点看成功率变化、关键步骤偏移、成本上涨和高风险操作触发是否异常。也就是说，它是“用真实历史做稳定对比”，而不是“多跑一次测试”。
工程上，回放体系需要保存输入、上下文快照和工具响应，建设成本不低，但它能显著降低“改了一点小东西却把旧场景打坏”的风险。只比最终回答文本，往往看不出真正的决策退化。
追问方向：如果工具返回具有时效性，回放评估怎么避免失真？
8. Agent 告警应该怎么设计？
题目：Agent 系统的告警要怎么做，才能既能早发现问题，又不把值班人淹没？
面试官想听什么：你是否知道告警设计的重点是可行动，而不是把所有异常都推给人。
短答版：我会按可行动性设计告警。优先报任务完成率突降、高风险操作异常、工具连续失败、人工接管飙升这类必须处理的信号，低价值抖动进看板不直接打人。
深答版：
展开深答版
这题核心是告警不是日志搬运。Agent 的异常非常多，如果什么都告，最后没人信告警；但如果只告基础设施，又抓不到真正影响业务的链路退化。
一个好告警至少要满足三点：和用户影响强相关、能定位到责任层、收到后有明确动作。任务成功率突降、高风险操作异常、关键工具连续失败、人工接管飙升，这些通常更值得直接打人；普通重试、轻微波动和长尾噪声，更适合先沉到报表。
工程上，告警设计的重点是可行动性，而不是覆盖面。Agent 很常见的情况是“接口都正常，但任务一直做错”，所以不能照搬传统服务的监控思路。
追问方向：任务完成率和模型输出质量难以实时判断时，告警阈值怎么设？
9. Agent 的审计能力要做到什么程度？
题目：如果用户投诉 Agent 做了不该做的事，你认为系统至少要具备哪些 auditability 能力？
面试官想听什么：你是否把审计理解成可追责、可解释、可复盘，而不是简单留一份聊天记录。
短答版：至少要能回答四件事：谁触发的、当时看到了什么、调用了哪些工具、为什么落成了这个结果。也就是输入、关键决策、执行动作和版本信息都要能追到。
深答版：
展开深答版
这题本质是在谈系统出了事以后能不能说清楚。Agent 一旦接入外部工具，问题就不再只是“答错一句话”，还可能涉及误操作、越权和责任归属，所以审计必须覆盖请求身份、上下文快照、模型版本、工具调用参数、人工确认点和最终结果。
但审计也不等于无限制记录一切。你还要处理隐私、存储成本和敏感信息脱敏，所以真正重要的是保留“能复盘决策链的最小必要证据”，而不是机械堆日志。
工程上，审计越完整，排障和合规越稳，但治理成本也会上升。真正危险的情况不是日志太少，而是只有最终输出，没有过程证据，出了事根本说不清。
追问方向：审计日志和普通观测日志的边界应该怎么划？
10. 回滚设计为什么不能只靠重新部署旧版本？
题目：如果新版本 Agent 上线后效果变差，为什么“把代码回滚”往往还不够？
面试官想听什么：你是否意识到 Agent 的状态、配置、提示词、工具协议都可能让回滚变复杂。
短答版：因为 Agent 行为不只由代码决定，还受 prompt、模型版本、工具 schema、策略配置和中间状态影响。真正的 rollback design 要能一起切回这些依赖，并处理已经进行中的任务。
深答版：
展开深答版
这题核心是 Agent 的运行面比传统服务更宽。很多事故不是代码 bug，而是 prompt 更新、模型切换、工具 schema 变化、策略阈值调整或者记忆污染导致的，所以只回滚应用镜像，行为未必能真正回到旧状态。
回滚至少要覆盖代码、配置、模型版本、工具协议，以及在途任务如何处理。老任务是继续按旧规则跑、统一终止，还是迁移到新版本，都要提前设计。否则系统看起来回滚了，行为其实还停在新版本的半路上。
工程上，回滚面做得越完整，系统越稳，但配置治理和兼容成本也会上升。把“重新 deploy”当成完整回滚，是 Agent 场景里很常见的假恢复。
追问方向：如果新旧版本的工具参数结构不兼容，回滚时最容易踩什么坑？
11. Agent 为什么适合做版本化放量？
题目：Agent 新能力上线时，你会怎么做 versioned rollout，而不是一次性全量替换？
面试官想听什么：你是否知道 Agent 质量波动大，发布策略本身就是风险控制手段。
短答版：我会做版本化放量，按用户组、场景或流量比例逐步开。核心不是只看整体成功率，而是比较新旧版本在关键场景、成本和风险触发上的差异，随时能停。
深答版：
展开深答版
这题本质是在谈把不确定性关进小范围。Agent 很容易在某些场景变好、另一些场景变差，所以一次性全量替换会把问题直接扩散到全站，尤其在高风险或高价值场景上代价更大。
版本化放量的关键，不只是“慢慢开”，而是保留对照组，按用户组、场景或流量比例逐步扩大，持续比较新旧版本在成功率、成本和风险触发上的真实差异。没有对照，灰度就很难说明问题。
工程上，多版本并行会增加路由和观测复杂度，但它换来的是更低的事故半径和更强的比较能力。只看全局平均指标，很容易把局部高价值场景的问题冲掉。
追问方向：按用户分桶、按场景分桶、按流量比例分桶，各自适合什么情况？
12. 人工接管和恢复演练该怎么准备？
题目：怎么判断一个 Agent 系统真的具备 human handoff 和 recovery readiness，而不是文档里写了“必要时人工介入”？
面试官想听什么：你是否理解人工接管不是兜底口号，而是要提前设计入口、上下文和操作流程。
短答版：关键看三件事：什么时候交给人、交给人时能看到什么、接手后怎么继续处理。没有明确触发条件、上下文摘要和演练过的 SOP，人工接管通常只是写在方案里。
深答版：
展开深答版
这题核心是在谈恢复准备度，而不是恢复意愿。很多团队口头上都说“失败就转人工”，但真正出事时，人拿不到上下文、不知道前面发生了什么、也没有安全的补救动作，最后只是把故障换个方式放大。
所以人工接管至少要包含几样东西：什么时候交给人、交给人时能看到什么、能做哪些安全动作、接手后怎样继续推进，以及什么时候能重新回到自动流。没有这些，所谓 handoff 只是方案文档里的安慰句。
工程上，这套机制会增加流程设计和培训成本，但它直接决定事故时能否把损失压住。人工接管不是一个按钮，而是一套经过演练的运行机制。
追问方向：哪些故障最适合直接转人工，哪些更适合自动重试或自动回滚？
13. 一个 Agent 系统要上线，最少需要哪些工程化能力？
题目：如果一个 Agent Demo 已经能跑通任务了，你会用什么标准判断它是否具备最基本的上线条件？
面试官想听什么：你是否真的把 Agent 当成生产系统看，能说出“效果之外”的最低工程底座，而不是只讨论模型和提示词。
短答版：我会把它当成上线前的最低门槛清单来看：能不能观测、能不能限权、出错能不能停住、变更后能不能验证、上线后能不能回滚。Demo 能跑，只说明路径打通了；上线要求的是这些底座已经齐了。
深答版：
展开深答版
这题的核心不是列一串“最佳实践名词”，而是给出一套最低上线门槛。也就是说，你要回答的不是“理想中的生产系统还能补什么”，而是“少了哪些底座，这个系统今天就不该上”。一个能上线的 Agent 系统，首先要能被看见，也就是具备基本可观测性。你至少要知道它调用了什么模型、做了哪些工具动作、在哪个阶段变慢、在哪一步失败，否则出了问题只能靠猜。对 Agent 来说，这比普通接口更重要，因为它的执行链路更长、分支更多、失败模式更复杂。
第二层是边界控制。只要 Agent 能动文件、调接口、写数据，权限模型和安全护栏就不是可选项。你得清楚哪些动作能自动做，哪些动作必须审批，哪些输入会被拒绝，哪些工具只能读不能写。没有这个边界，系统越强，风险越高。第三层是失败治理，也就是错误时能不能停住、能不能恢复、能不能转人工，而不是任由它在异常路径上继续放大错误。
再往后才是持续运营能力，包括离线评估、回归检测、版本发布、灰度和回滚。Agent 不像静态规则系统，一次提示词改动、一次模型升级、一次工具 schema 变化，都可能引入行为漂移。如果你没有持续验证和回滚机制，上线本身就是在拿真实用户做实验。也就是说，这题更像是在问上线前的“五道闸门”，而不是泛泛地谈工程化意识。
面试里可以这样收口：
Agent 上线的门槛不是跑通 happy path，而是异常路径也有观测、有边界、有回退。追问方向：如果团队资源有限，你会优先把哪两项工程能力补齐，再允许系统进入小流量灰度？
14. 为什么很多 Agent Demo 能跑，但一上生产就不稳定？
题目：很多 Agent Demo 在演示环境里效果很好，为什么一进真实流量、真实权限和真实异常场景就开始不稳定？
面试官想听什么：你是否理解 Demo 验证的是“能不能跑通”，而生产系统要求的是“在噪声、长尾和异常里还能不能被控制住”。
短答版：因为 Demo 验证的是“在被挑平的环境里能不能跑通”，生产暴露的却是噪声、长尾、异常、权限收缩和状态耦合。很多系统不是到了生产突然变笨，而是原本就没经过这些失败模式的检验。
深答版：
展开深答版
这题的关键不是泛泛地说“生产更复杂”，而是说清楚生产到底把哪些隐藏问题暴露出来。Demo 通常验证的是 happy path：样本是挑过的，工具是通的，权限是宽的，流程是短的，人工也盯着看。它证明的是“这个思路可行”，不是“这个系统已经扛过真实世界”。一旦进入真实流量，用户表达会脏、任务目标会漂、上下文会不完整，模型和工具的组合错误会迅速放大。
Agent 比传统接口更容易暴露这种问题，因为它的执行链更长、决策点更多。一次输出波动，可能只是文案差一点；但一次工具误调用、一次状态写错、一次检索误命中，可能就会把错误传播到下一步，甚至写进外部系统。所以很多 Demo 看起来“智能”，本质上是因为场景被压平了，真实世界里的状态耦合、权限限制和异常分支还没出现。
生产不稳定还有一个常见原因是，Demo 阶段根本没有覆盖真正的失败模式。比如输入脏数据、工具超时、外部权限收紧、状态恢复错位、知识版本漂移、人工接管链路缺失。这些问题在演示环境里可能一次都碰不到，但线上只要碰到一次，就会把系统脆弱性放大出来。再加上很多团队缺乏可观测和回退设计，出了问题之后既看不清错误发生在哪一层，也没有办法快速停掉、切回旧版本、转人工或限制高风险动作，于是每一次线上问题都会变成“先猜原因，再赌修复”。
面试里可以把它总结成一句：
Demo 证明能力存在，生产要求能力在噪声、约束和异常下仍然可控。很多 Agent 不是不会做事，而是没有被设计成在出错时还能安全地做事。追问方向：如果你只能补一类能力来把 Demo 推向小流量试运行，你会先补可观测性、权限护栏还是人工接管？为什么？
15. Agent 成本为什么不能只看 token？
题目：如果团队只盯着 token 单价和月度 token 消耗来控制 Agent 成本，你为什么会说这还远远不够？
面试官想听什么：你是否理解 Agent 的真实成本是“模型调用成本 + 工具链成本 + 失败返工成本 + 风险成本”的系统账，而不是单一 API 账单。
短答版：因为 token 只是最显眼的一层。Agent 真正的成本还包括工具调用、检索和存储、长链路重试、人工接管、错误写入后的修复、以及为了压住风险而付出的工程治理成本。只看 token，容易把“账单便宜但总拥有成本更高”的方案误判成最优。
深答版：
展开深答版
这题本质上是在考你有没有把 Agent 当成完整执行系统看。很多团队一提成本，立刻只看模型单价、上下文长度和请求量，因为这些最容易量化。但 Agent 和普通问答不一样，它会调工具、走多步、失败重试、写外部系统，甚至触发人工介入。也就是说，token 成本只是入口账，不是全链路账。
一个表面上 token 更省的方案，可能因为检索更差、重试更多、人工兜底更频繁，最后总体成本反而更高。反过来，一个单次推理稍贵的方案，如果能显著减少无效调用、降低返工、减少事故和人工处理量，整体可能更便宜。所以看成本不能只看“每次调用多少钱”，还要看“为了把任务稳定做成，系统总共付出了多少钱”。
对生产 Agent 来说，最贵的往往不是多花了几点 token，而是错误动作带来的放大成本。比如写错工单、误发消息、错误审批、污染知识库，这些后续修复成本远高于模型调用本身。再往上，还有延迟带来的转化损失、人工审核的人力占用、可观测和回滚机制的建设成本。这些都是 Agent 的真实成本组成部分。
面试里可以收口成一句：
Agent 成本不能只算推理账，还要算执行账、返工账和事故账。便宜的 token 不等于便宜的系统。追问方向：如果两个方案一个 token 成本低、一个人工接管率低，你会怎么设计比较口径来做取舍？
16. 为什么 Agent 的线上监控不能只看成功率？
题目：如果线上监控面板只放一个“任务成功率”，为什么你会觉得这远远不够？
面试官想听什么：你是否理解 Agent 的失败不只是“成”或“败”，还包括成本失控、错误升级、风险触发、人工兜底和用户信任下降这些隐藏退化。
短答版：因为成功率只能看到结果层，很多关键问题会被平均值掩盖，比如重试次数暴涨、成本变高、延迟拉长、人工接管上升、危险动作增多、答案质量下降但还没完全失败。Agent 监控要看过程质量，不只是终局状态。
深答版：
展开深答版
这题核心在于 Agent 的退化往往不是断崖式失败，而是缓慢变差。很多任务最后仍然能“成功结束”，但它可能已经多重试了三次、多调用了两个工具、把延迟拉长了一倍，或者转了人工才收尾。如果你只看成功率，这些问题在报表里几乎是隐形的，但它们已经在吞成本、吞体验、吞运营能力。
对 Agent 来说，过程指标和结果指标同样重要。你至少要知道一次任务走了多少步、调用了哪些工具、在哪个阶段最常失败、重试是否集中在某个环节、是否出现高风险动作触发增加、人工接管率是否上升、同类场景下新版本是否比旧版本更贵更慢。这些都不一定立刻把成功率打下来，但它们往往是事故前的早期信号。
还有一个常见陷阱是平均值掩盖结构性问题。整体成功率看着没掉，可能是低风险场景撑住了数据，高价值场景却在恶化；也可能是系统通过更多人工兜底把结果维持住了，但自动化能力其实在下降。所以监控不能只看一个全局成功率，还要分场景、分版本、分链路阶段看。
面试里可以收口成一句：
成功率只能告诉你系统最后有没有摔倒，不能告诉你它是不是已经开始踉跄。Agent 的监控价值，在于尽早看到退化过程，而不是等失败结果出现。追问方向：如果你只能再补 3 个线上指标到成功率旁边，你会优先放哪 3 个？为什么？
17. 为什么 Agent 的回滚不能只回滚代码，还要回滚 prompt、配置和知识版本？
题目：如果新版本 Agent 上线后效果变差，为什么你会说“回滚代码”往往只是恢复动作的一部分？
面试官想听什么：你是否理解 Agent 行为是多层依赖共同决定的，回滚要覆盖行为面，而不只是应用二进制或镜像版本。
短答版：因为 Agent 的行为不只由代码决定，还受 prompt、模型版本、路由策略、工具 schema、权限配置和知识库版本影响。只回滚代码，常常会得到“程序回去了，行为没回去”的假恢复。真正的回滚要能把一整套行为依赖切回一致状态。
深答版：
展开深答版
这题核心在于 Agent 系统的“行为定义面”比传统服务宽得多。传统接口回滚代码，通常已经能恢复大部分逻辑；但 Agent 场景里，代码只是其中一层。一次 prompt 微调、一次模型路由切换、一次工具参数结构变化、一次知识库更新，都可能明显改变最终行为。也就是说，用户感知到的“这个 Agent 变了”，不一定来自代码本身。
所以线上出问题时，如果只把应用镜像切回旧版本，而 prompt 还是新的、模型还是新的、知识索引还是新的、路由阈值还是新的，你得到的可能只是一个“旧代码 + 新依赖”的混合状态。这种状态往往最难排查，因为它既不像完整新版本，也不像完整旧版本。系统看似已经回滚，实际上行为面仍处在漂移区间。
真正成熟的回滚设计，应该至少让你能回答几个问题：当前请求使用的是哪版 prompt、哪版模型策略、哪版工具协议、哪版知识集；出问题后，哪些层需要联动切回；在途任务怎么处理；旧版本是否能兼容新状态。否则所谓回滚，只是把“恢复动作”变成了一次新的不确定实验。
面试里可以收口成一句：
Agent 的回滚目标不是把代码退回去，而是把行为依赖退回到一个经过验证的一致版本。只回滚代码，很多时候只是恢复了一半。追问方向：如果知识库版本已经更新，但代码要先回滚到旧版，你会优先处理哪层兼容问题，避免出现“旧代码读新知识”的错配？
18. 为什么 Agent 的权限设计不能只分“可用/不可用”两档？
题目：如果一个 Agent 需要访问很多工具和系统，为什么你不会只做一个“这个工具能不能用”的二元权限开关？
面试官想听什么：你是否理解 Agent 权限设计要分动作级别、范围级别、条件级别和审批级别，而不是粗暴地给全开或全关。
短答版：因为 Agent 的风险不是“有没有权限”，而是“在什么条件下、对什么对象、以什么强度执行什么动作”。只做可用/不可用两档，要么限制过死，要么放权过大。更合理的是按读写、对象范围、风险等级、审批条件做分层授权。
深答版：
展开深答版
这题本质上在考你有没有把权限当成行为约束系统看，而不是一个布尔开关。传统系统里，“有没有权限调用某接口”很多时候已经够用；但 Agent 的问题在于，它会自己组合动作、决定时机、选择参数，所以同一个工具在不同调用方式下，风险可能完全不同。一个只读查询和一个批量删除，技术上可能都是同一套接口，但工程风险不是一个级别。
所以权限至少要分几层。第一层是动作层，读、写、删、批量操作要分开。第二层是范围层，能访问哪些对象、哪些目录、哪些库表、哪些业务实体。第三层是条件层，比如只有在某类任务、某个置信度、某种用户角色下才能触发。第四层是审批层，高风险动作要不要人工确认、要不要双重校验、要不要限流和审计。只有这样，权限才真正约束的是“行为面”，而不是一个空泛的“工具可用”。
如果只做二元开关，实际效果通常很糟。全关，Agent 基本做不了事；全开，它就可能在错误上下文里做出本不该做的动作。更糟的是，很多事故不是因为系统本来不该有这个能力，而是因为能力边界太粗，没有把低风险调用和高风险调用拆开。权限设计做得细，不是为了麻烦，而是为了让系统在有用和可控之间找到工程平衡。
面试里可以收口成一句：
Agent 权限设计控制的不是“有没有工具”，而是“能在什么边界内怎么用工具”。没有分层权限，就只有瘫痪和裸奔两种状态。追问方向：如果同一个工具既支持“查一条记录”也支持“批量修改全库”，你会怎么拆权限模型避免误用？
19. 为什么 Agent 的故障排查要按“模型层 / 工具层 / 状态层 / 知识层”分层做？
题目：一个 Agent 任务失败了，很多团队第一反应是“模型不行”或者“prompt 不对”。为什么更成熟的排查方式应该按模型层、工具层、状态层、知识层分层定位，而不是把所有问题都归结到模型输出？
面试官想听什么：他想看你是否具备生产级诊断思维。重点不是会不会调 prompt，而是你能不能把一次失败拆成不同责任面，避免把模型当成黑盒背锅器。优秀候选人会讲“分层排障”的价值：定位更快、责任更清晰、修复更稳定、复盘更可积累。
短答版：因为 Agent 失败通常不是一个点坏了，而是多层耦合出了问题。分层排查的价值是更快定位根因、分清责任面，避免把工具、状态或知识问题一股脑修成 prompt 问题。
深答版：
展开深答版
Agent 系统比普通 LLM 调用更难排障，核心原因在于它不是单一推理过程，而是“模型决策 + 外部执行 + 状态流转 + 知识注入”的耦合系统。任务失败时，最后暴露出来的往往只是一个表面现象，比如“答案错了”“步骤卡住了”“结果不完整”。但这个现象可能来自完全不同的根因。如果团队没有分层诊断框架，就会习惯性把所有锅甩给模型和 prompt，这是最常见、也最低效的排查方式。
模型层关注的是模型本身有没有正确理解任务、是否做出了合理选择、输出格式是否稳定、是否出现幻觉或错误决策。比如明明工具返回了可用数据，但模型总结错了；或者模型没有遵循工具调用约束，擅自跳过检索直接回答。这类问题才属于典型的模型层问题。修复路径通常是 prompt 约束、schema 收紧、模型切换、样本增强或策略改写。
工具层关注的是执行器和外部系统。比如 API 超时、参数映射错误、工具返回空数据、权限不足、重试策略错误、写操作副作用没收敛、第三方限流等。很多表面看起来像“模型没答对”，其实是工具根本没成功执行，或者执行结果不可信。如果没有把工具调用日志、输入输出、耗时、错误码和重试链路单独打出来，团队会误以为模型在胡说，实际上是工具链在掉链子。
状态层是 Agent 系统最容易被忽视的一层。任务为什么重复执行、为什么中断后恢复错位、为什么多轮后上下文越来越乱、为什么同一请求前后结果不一致，很多都不是模型问题，而是状态管理问题。这里包含会话状态、任务进度、临时变量、记忆写入、幂等标识、checkpoint、人工接管标志等。状态层一旦设计模糊，系统就会出现“局部看都对，整体跑不稳”的症状，而这种问题只调 prompt 基本无解。
知识层则对应 RAG、规则库、业务配置、知识版本和数据权限。用户问的问题答错了，不一定是模型推理差，也可能是根本没召回正确文档、召回的是旧版本、文档切分有问题、索引尚未更新、知识权限过滤错误，甚至知识源本身就不适合被检索。如果没有把知识层单独拿出来诊断，团队就会一直在模型层做无效优化。
分层排查的真正价值，不只是“分类更漂亮”，而是让诊断具备工程闭环。一次失败事件，应该能落到某一层或多层的明确证据上：模型层看 prompt、response、decision trace；工具层看 tool call、返回码、延迟、重试；状态层看 checkpoint、上下文快照、状态变更日志；知识层看 query、召回结果、文档版本、过滤条件。这样复盘结论才能变成可执行改进，而不是一句模糊的“模型效果一般”。
所以生产级 Agent 团队通常会建立分层观测面板和分层责任边界。先问是模型没想对，还是工具没跑通，还是状态没接稳，还是知识没供对。只有这样，修复动作才会收敛，系统也才可能稳定迭代。否则你看到的会是所有问题最后都变成“再改改 prompt 试试”，这基本说明系统还没有真正进入工程化阶段。
追问方向：分层日志应该怎么设计才便于排查？一次故障跨多层时怎么定主因？模型层和知识层的边界怎么区分？线上观测里哪些指标最能帮助快速判断问题落在哪一层？