背景你说懂这些理论的东西有没有用呢我觉得还是要掌握一些不然人人都会用AI做东西都会用AI生成代码去提效那么你去面试你的竞争力在哪长得比别人帅还是token比别人多面试官根据什么来选你而不是选别人我觉得这方面就需要我们多去掌握一些平时可能不会去思考的东西目的就是将来某一天你跟面试官面对面坐一起的时候他问你啥你不会只是笑一笑然后说一句我不知道这篇文章一共八个部分22个问题建议看之前泡杯咖啡静下心来慢慢看1. LLM 底层认知Q1. 请解释一下 LLM 的上下文窗口是什么以及 Lost-in-the-Middle 现象是怎么发生的上下文窗口是 LLM 一次能处理的最大 Token 数量由 Transformer 架构中的注意力机制决定。窗口内的 Token 之间通过 Self-Attention 相互可见窗口之外的信息模型无法感知。Lost-in-the-Middle 现象是指当输入上下文很长时模型对开头和结尾的信息利用率最高而对中间部分的信息利用率显著下降模型在信息位于文档开头或结尾时准确率约有 70-80%但位于中间时可能降到 40-50%。原因注意力分布不均匀模型倾向于关注序列早期primacy bias和近期recency bias的内容中间部分容易被稀释。如何预防关键信息前置/后置System Prompt 放在最前面重要指令放开头最新信息放末尾结构化 Prompt用 Markdown/XML 标签帮助模型感知内容边界滑动窗口 摘要长对话定期做 Summarization把中间部分压缩后放到开头RAG 结果排序检索到的文档按相关性重排序最相关的放首尾自适应裁剪优先丢弃中间部分的低价值历史对话Q2. Temperature、Top-P、Top-K 这三个参数有什么区别在实际部署中怎么调核心区别参数作用数值含义Temperature控制概率分布的平滑度越低越确定性0 greedy越高越随机Top-P (Nucleus Sampling)累积概率超过 P 的最小 token 集合0.9 取累积概率 90% 的 token 候选集Top-K只保留概率最高的 K 个 tokenK40 表示只从概率前 40 的 token 中采样实际调参建议场景TemperatureTop-PTop-K代码生成 / 函数调用00.20.91.0不启用事实问答 (RAG)00.30.9不启用创意写作 / 头脑风暴0.70.90.90.954050客服回复标准化0.10.30.85不启用Agent Tool Selection00.1不启用不启用建议Agent 的 Tool Calling 阶段建议 Temperature 接近 0确保工具选择稳定减少幻觉调用生成回复阶段可以略微提升 Temperature让表达更自然不要同时使用 Top-P 和 Top-K通常选 Top-P 更通用线上建议做 0.050.1 粒度的 A/B 测试来微调Q3. 模型幻觉是怎么产生的Agent 场景下如何缓解幻觉的根源数据层面预训练数据中的错误 / 矛盾信息被模型内化架构层面模型本质是“下一个 Token 预测”不是事实数据库对齐层面RLHF 鼓励模型“有帮助”有时会压制“我不知道”知识截止模型训练后的新知识它只能“猜”Agent 场景下的幻觉风险比纯文本严重得多工具幻觉模型调用了一个实际不存在的工具或参数参数幻觉给工具传入正确的参数名但参数值不存在如传入一个假的城市代码结果幻觉工具返回了数据但模型在总结时曲解了数据行动幻觉模型认为已经调用了工具但实际上没有自以为做了行动但没执行缓解手段手段原理Tool Calling 结构化输出让模型输出结构化 JSON 而非自由文本约束解码 (Grammar Guidance)用 JSON Schema / GBNF 约束模型输出Retrieval-Augmented Generation给模型提供事实上下文减少编造需求Self-Consistency / 多路验证多次推理取多数答案引用溯源要求模型标注信息来源无法溯源的弃用Confidence Scoring让模型给出置信度低分的不展示Human-in-the-Loop关键决策支付、删除由人工确认2. Agent 架构与模式Q4. 手写一个 ReAct Agent 的核心循环max_iterations的作用防止无限循环和Token爆炸Agent可能出现不断调用工具的死循环每次循环都会消耗 Token没有上限的话可能一次对话消耗数百万Token并行Tool Calling怎么实现如果工具之间没有依赖关系可以让 LLM 在一次推理中生成多个 tool_call然后 concurrently 执行。类似 Promise.all / asyncio.gatherQ5. ReAct 和 Plan-and-Execute 有什么区别各自适用什么场景维度ReActPlan-and-Execute执行方式边想边做逐步推理先制定完整计划再逐步执行灵活性高随时可改方向低计划制定后不易变可解释性中间推理步骤可见计划 执行步骤清晰长任务表现容易跑偏或死循环结构清晰适合长流程规划开销无显式规划成本计划阶段需要额外 Token错误恢复天然支持随时可调整需要重规划机制场景选择场景推荐模式原因单步问答 / 简单查询ReAct不需要规划查完即答多步工具调用如订票ReAct每一步依赖上一步结果需要动态决策复杂文档生成如周报Plan-and-Execute先定结构再填充保证完整性代码修改 / 多文件重构Plan-and-Execute需要先理解整体再做修改未知探索任务如做研究ReAct中间发现可能改变方向故障排查 / DebugReAct逐步缩小范围灵活调整实际生产中最常用的是两者的混合——初始化时先生成一个 High-Level Plan但在执行每个步骤时用 ReAct 的模式做细粒度决策遇到阻塞时允许重规划。这就是Plan-and-Solve ReAct 混合模式。Q6. 你设计过Multi-Agent系统吗讲讲你如何决定什么时候拆成多 Agent以及 Agent 之间怎么通信什么时候该拆成多Agent角色冲突单个 Agent 既要严格检查又要创意回答角色矛盾知识域隔离需要访问不同的数据源/工具集放一起导致 Tool 选择准确率下降需要不同推理策略一个 Agent 需要严谨的逐步推理另一个需要快速直觉判断跨系统边界需要调用不同权限域的资源可观测性要求需要分别追踪每个环节的耗时和成功率多Agent的缺点多Agent增加了延迟、Token成本、协调复杂度3个以上Agent的对话系统协调成本指数级上升一个 Agent 好 Prompt 能解决的问题拆成多 Agent 是过度设计Agent 通信模式建议Agent之间的消息需要结构化协议不能纯文本对话要定义消息 Schema需要超时机制一个 Agent 卡住不能阻塞整个系统建议引入共享上下文一个全局的黑板 / 共享 Memory降低重复传递信息的 Token 成本Q7. Agent死循环Tool Loop的检测和恢复策略有哪些死循环的典型表现反复调用同一个工具传入不同参数但语义一样A 工具和 B 工具互相调用把对方的输出当成自己的输入持续报错→重试→报错→重试推理阶段不断「自我质疑」不产生行动检测策略恢复策略策略做法适用场景Prompt Intervention插入一条 system message 提示 Agent 换个方向轻微死循环上下文截断丢弃中间部分的冗余对话Agent 积累了过多上下文强制摘要让另一个 LLM 压缩当前进展重新启动循环严重死循环降级策略退化为简单的问答模式停止工具调用无法恢复时Human Handoff转人工处理以上都失败时工程兜底生产环境必须配置绝对兜底——达到最大轮次或 Token 预算上限后强制结束并回复“当前无法完成请尝试简化您的需求”或转人工。3. Tool Calling与函数调用Q8. 怎么定义一个“好的”工具踩过哪些坑典型不好的工具定义不好的原因是描述太模糊参数名意义不明模型不知道什么时候该用正确的定义关键踩坑经验坑现象解决描述太短模型不知道什么时候用这个工具写清楚“何时调用 / 何时不要调用”参数名太短q / id / val 模型不知道填什么用完整语义的名词缺少类型约束传入字符串 123 但 API 要数字严格标注 JSON Schema 类型枚举值不全模型自己编造不在枚举里的值enum字段约束缺少默认值模型不传可选参数导致不确定性给合理默认值没有边界描述用户问非技术问题也调了知识库在 Description 中声明排除场景工具太多Agent 一次选错工具的几率上升工具超过 20 个需做分组/层级暴露工具竞食两个工具功能重叠模型反复纠结保证工具职责互斥工程原则工具定义的 Description 是在给模型写说明书写清楚这是什么、什么时候用、什么时候不用、参数是什么意思。把工具定义当成API文档来写宁可啰嗦不能模糊Q9. 工具调用失败了怎么办你的错误处理策略是什么分层错误处理策略代码实现关键认知工具错误信息是 Agent 的“新 Observation”输入给 LLM 之后的 LLM 行为决定了 Agent 是否智能一个好的 Agent 会分析错误原因并修正参数重试Q10. 如果给 Agent 注册了 30 个工具Tool Selection 准确率下降怎么办这是Agent工程中非常实际的问题——模型在太多工具中选对的难度会指数级上升。优化策略工具分组基于意图的预路由动态工具注册Tool Embedding 检索工具聚合Composite Tool把多个细粒度工具封装成一个粗粒度工具内部做二次路由比如一般来说工具数从 5 个增加到 20 个Tool Calling 准确率从约 95% 下降到约 75-80%。分组到每级 5-8 个可以恢复到 90%4. Prompt EngineeringQ11. 你如何设计和迭代一个 System Prompt遇到过什么反直觉的问题System Prompt 设计方法论示例架构反直觉的踩坑经验坑与反直觉点原因对策越短的 System Prompt 效果越好长 Prompt 稀释了关键指令删除所有非关键内容重要的放前 20%说「不要做 X」有时反而触发 X模型关注到负面描述的 Token用正向引导替代负面禁止放尾部的规则常被忽略Lost-in-the-Middle 现象最重要的规则放最前面具体指令比抽象原则有效“回答不超过 3 点”比“要简洁”有效用可量化的约束长 Prompt 大幅增加 Token 成本每次对话都要带 System Prompt定期评估“每条规则是否值得它的 Token”Q12. 你怎么设计 Prompt 来防止 Agent 被用户注入攻击Prompt InjectionPrompt Injection 在 Agent 场景下特别危险因为 Agent 有工具调用能力攻击者可能诱使 Agent 执行删除数据、泄露信息等操作防御策略分层防御Prompt 级别的具体实现额外的工程手段对用户输入做特殊字符转义如将转义为实体在 Agent 的 Tool Execution 层再做一次参数校验不信任任何来自 LLM 的内容关键操作支付、删除、写操作的 Tool 在执行前先调用一个Permission Check Tool做前置审批5. RAG 与记忆管理Q13. 你设计过 RAG 系统吗讲一下 Chunk 策略是怎么选的Chunking 策略决策树关键参数参数推荐值说明Chunk Size256512 tokens太小信息不完整太大检索噪声多Overlap10%20% of chunk size避免关键信息正好被切在边界Embedding Modelada-002 / bge-large / text-embedding-3-small领域特定数据建议微调或选更大型号Top-K Retrieval35答案需要的信息通常来自 3-5 个块踩过的坑没有 Overlap→ 一些关键信息恰好在两个 Chunk 的边界被截断检索不到Chunk 太大→ 一个 Chunk 包含多个主题检索到但模型不知道该用哪部分只做单层检索→ 加一层 Rerank 可以显著提升 Top-K 的质量不区分文档类型统一参数→ 代码和自然语言文档应该用完全不同的 Chunk 策略进阶Q14. Agent 的上下文窗口满了怎么办你的压缩策略是什么上下文窗口满了是不能回避的问题特别是长对话 Agent。分层压缩策略Token 预算分配策略核心原则最新的信息保留最完整中间的要压缩关键事实结构化提取不要等到满了才处理每次对话后会做增量压缩6. 评估与可观测性Q15. 你怎么评估一个 Agent 好不好Eval 体系怎么搭建Agent Eval 三层体系Eval数据集构建Eval 工作流Q16. 你的 Agent 在生产环境出问题了怎么排查Agent 排障的难点在于你不能像 Debug 代码那样去 Debug Agent因为每次输出都可能不同。排查工具箱一站式排查流程没有 Tracing 的 Agent 系统就是盲人摸象在 Agent 上线前必须先接入Tracing工具LangSmith / LangFuse这是最重要的基础设施投资。7. 安全与护栏Q17. 你给 Agent 设计过安全护栏吗怎么防止 Agent 做它不该做的事Agent调数据库DELETE 怎么办分层安全模型Defense in Depth编码实现示例Agent调数据库DELETE 怎么办System Prompt 明确禁止“执行非只读 SQL”数据库 Tool 内部做 SQL 解析检测到 DELETE / DROP / TRUNCATE 直接拒绝写操作类 Tool 需要用户二次确认 操作审计日志8. 工程落地与场景题Q18. 设计一个Android技术顾问 Agent你会怎么设计架构系统架构工具定义Tool用途权限search_android_doc搜索官方 Android 文档只读search_tech_wiki搜索内部技术 Wiki只读search_gitlab_code搜索 GitLab 仓库代码只读search_issue搜索 Bug / 需求只读read_file_content读取文件内容了解上下文只读summarize对长文本做摘要无副作用generate_code_snippet生成代码片段只输出文本刻意不开放的工具modify_code: 不开放Agent 不做代码修改delete_file: 不开放deploy: 不开放边界处理非技术问题意图分类器检测到非 Android 技术问题 → 礼貌拒绝公司内部信息Agent 需要确认用户有权限访问该信息否则说没有权限不确定的答案必须说这个我不确定并给出查找方向代码安全性生成的代码片段必须包含注释说明风险和适用版本成本控制简单问题用 Claude Haiku / GPT-4o-mini 处理复杂问题才升级到旗舰模型RAG 检索结果的缓存相同问题直接命中缓存设置单次对话 Token 上限防止预算失控Q19. 你要把一个 AI Agent 部署到线上要考虑哪些问题画一个部署架构部署关注点清单延迟 (Latency)LLM 调用的 P50 / P95 / P99 耗时监控流式输出Streaming减少首 Token 等待时间RB-Tree 缓存相同请求直接返回缓存结果对简单问题做模型降级Claude Sonnet → Claude Haiku成本 (Cost)Token 用量监控 预算告警缓存策略减少重复调用Prompt 压缩降低每次调用的 Token 数长对话的自动摘要压缩可靠性 (Reliability)LLM API 的重试 降级主模型挂了 → 备用模型每个 Agent 步骤设置超时 → 超时触发降级健康检查Health Check/ping → 快速检测 Agent 是否健康限流Rate Limiting防单个用户刷量可观测性 (Observability)全链路 Tracing每步的耗时 / Token / 工具调用业务指标监控成功率 / 用户满意度 / 工具准确率异常告警Token 激增 / 成功率骤降 / 延迟飙升日志保留Agent 的 Thought 过程是 Debug 的核心依据安全 (Security)用户鉴权JWT / API Key工具调用权限控制输入输出安全检查审计日志所有操作可追溯Q20. 你如何控制Agent的调用成本用户一次对话花了10万Token怎么办成本控制应该是系统设计的一部分而不是出了问题再去查。事前预防措施效果每轮对话 Token 上限如 20K防止单次失控最大推理轮次如 10 步防止 Tool Loop 消耗模型分层简单→小模型复杂→大模型降低 50-70% 成本缓存命中相同的 RAG 查询直接返回降低检索成本Prompt 瘦身去掉非关键指令用短名称每轮节省 5-10%工具分组只暴露当前需要的减少 Tool Definition 占用的窗口事中监控事后分析每日常规Token 用量报表按用户 / 对话 / Agent 分类识别CPUCost Per User最高的用户——是正常使用还是滥用识别异常的 Token Spike,突然暴涨通常意味着 Bug事后按照以下问题排查是不是 Agent 陷入了 Tool Loop是不是有工具返回了巨量数据是不是用户的问题是 LLM 无法处理的是不是 System Prompt 或 Tool Definition 太大然后针对根因做修复加轮次上限、工具返回结果截断、Prompt 瘦身Q21. 如果你现在要在 Android 手机上实现一个本地 AI助手Agent你会怎么做整体架构端侧模型的取舍不要期望端侧模型能像 GPT-4 一样推理端侧做意图分类 简单问答 工具路由云端做复杂推理 长文本生成关键数据通讯录/短信绝不离开设备实现要点Agent 作为一个Foreground Service运行常驻后台用Notification 快捷回复作为交互入口Tool Calling 通过Android 原生 API实现用DataStore / Room做会话持久化需要Privacy Sandbox级别的权限管控端侧 Agent 的工具举例Tool实现权限query_contactsContentResolver.query(ContactsContract)READ_CONTACTSread_calendar_eventsContentResolver.query(CalendarContract)READ_CALENDARsend_notificationNotificationManager.notify()POST_NOTIFICATIONSsearch_filesMediaStore或 SAF文件访问权限take_screenshotMediaProjection屏幕录制权限open_appPackageManager.getLaunchIntentForPackage()无特殊权限web_search网络 API 调用INTERNETQ22. 在 Agent 场景下你怎么测一个非确定性系统核心认知Agent 的测试不是传统“对或错”的测试而是统计学的“在多少情况下表现可接受”分层测试策略自动化评估工具关键指标不要求 100% 准确不可能因为 LLM 有概率性设定 SLOService Level Objective如 Tool Selection 准确率 ≥ 90持续监控每次模型升级 / Prompt 修改后回归测试异常检测如果成功率突然从 92% 降到 85%说明有回归问题收个尾我觉得现在用AI跟开车有点相似开车现在基本谁都会开挂个档踩个油门没啥难度但是如果车出点问题爆胎了你会换胎吗车子开一半熄火了你能知道是什么原因吗甚至之前我看到一视频里面有人玻璃水都不知道往哪个洞洞眼里面灌也不知道是不是真的AI也是如此会用AI的人很多但懂AI的人很少当所有人都在用AI写周报、做PPT、画图的时候你如果能理解ReAct循环为什么能防死循环、知道如何优化Lost-in-the-Middle现象那么你就不再是AI的用户了而是AI的工程师资料展示下面是我整理的AI大模型 学习资料和工具包 预览适合收藏后按主题逐步学习
22道AI Agent 工程师必会的面试题，别啥都不会就出去找工作
背景你说懂这些理论的东西有没有用呢我觉得还是要掌握一些不然人人都会用AI做东西都会用AI生成代码去提效那么你去面试你的竞争力在哪长得比别人帅还是token比别人多面试官根据什么来选你而不是选别人我觉得这方面就需要我们多去掌握一些平时可能不会去思考的东西目的就是将来某一天你跟面试官面对面坐一起的时候他问你啥你不会只是笑一笑然后说一句我不知道这篇文章一共八个部分22个问题建议看之前泡杯咖啡静下心来慢慢看1. LLM 底层认知Q1. 请解释一下 LLM 的上下文窗口是什么以及 Lost-in-the-Middle 现象是怎么发生的上下文窗口是 LLM 一次能处理的最大 Token 数量由 Transformer 架构中的注意力机制决定。窗口内的 Token 之间通过 Self-Attention 相互可见窗口之外的信息模型无法感知。Lost-in-the-Middle 现象是指当输入上下文很长时模型对开头和结尾的信息利用率最高而对中间部分的信息利用率显著下降模型在信息位于文档开头或结尾时准确率约有 70-80%但位于中间时可能降到 40-50%。原因注意力分布不均匀模型倾向于关注序列早期primacy bias和近期recency bias的内容中间部分容易被稀释。如何预防关键信息前置/后置System Prompt 放在最前面重要指令放开头最新信息放末尾结构化 Prompt用 Markdown/XML 标签帮助模型感知内容边界滑动窗口 摘要长对话定期做 Summarization把中间部分压缩后放到开头RAG 结果排序检索到的文档按相关性重排序最相关的放首尾自适应裁剪优先丢弃中间部分的低价值历史对话Q2. Temperature、Top-P、Top-K 这三个参数有什么区别在实际部署中怎么调核心区别参数作用数值含义Temperature控制概率分布的平滑度越低越确定性0 greedy越高越随机Top-P (Nucleus Sampling)累积概率超过 P 的最小 token 集合0.9 取累积概率 90% 的 token 候选集Top-K只保留概率最高的 K 个 tokenK40 表示只从概率前 40 的 token 中采样实际调参建议场景TemperatureTop-PTop-K代码生成 / 函数调用00.20.91.0不启用事实问答 (RAG)00.30.9不启用创意写作 / 头脑风暴0.70.90.90.954050客服回复标准化0.10.30.85不启用Agent Tool Selection00.1不启用不启用建议Agent 的 Tool Calling 阶段建议 Temperature 接近 0确保工具选择稳定减少幻觉调用生成回复阶段可以略微提升 Temperature让表达更自然不要同时使用 Top-P 和 Top-K通常选 Top-P 更通用线上建议做 0.050.1 粒度的 A/B 测试来微调Q3. 模型幻觉是怎么产生的Agent 场景下如何缓解幻觉的根源数据层面预训练数据中的错误 / 矛盾信息被模型内化架构层面模型本质是“下一个 Token 预测”不是事实数据库对齐层面RLHF 鼓励模型“有帮助”有时会压制“我不知道”知识截止模型训练后的新知识它只能“猜”Agent 场景下的幻觉风险比纯文本严重得多工具幻觉模型调用了一个实际不存在的工具或参数参数幻觉给工具传入正确的参数名但参数值不存在如传入一个假的城市代码结果幻觉工具返回了数据但模型在总结时曲解了数据行动幻觉模型认为已经调用了工具但实际上没有自以为做了行动但没执行缓解手段手段原理Tool Calling 结构化输出让模型输出结构化 JSON 而非自由文本约束解码 (Grammar Guidance)用 JSON Schema / GBNF 约束模型输出Retrieval-Augmented Generation给模型提供事实上下文减少编造需求Self-Consistency / 多路验证多次推理取多数答案引用溯源要求模型标注信息来源无法溯源的弃用Confidence Scoring让模型给出置信度低分的不展示Human-in-the-Loop关键决策支付、删除由人工确认2. Agent 架构与模式Q4. 手写一个 ReAct Agent 的核心循环max_iterations的作用防止无限循环和Token爆炸Agent可能出现不断调用工具的死循环每次循环都会消耗 Token没有上限的话可能一次对话消耗数百万Token并行Tool Calling怎么实现如果工具之间没有依赖关系可以让 LLM 在一次推理中生成多个 tool_call然后 concurrently 执行。类似 Promise.all / asyncio.gatherQ5. ReAct 和 Plan-and-Execute 有什么区别各自适用什么场景维度ReActPlan-and-Execute执行方式边想边做逐步推理先制定完整计划再逐步执行灵活性高随时可改方向低计划制定后不易变可解释性中间推理步骤可见计划 执行步骤清晰长任务表现容易跑偏或死循环结构清晰适合长流程规划开销无显式规划成本计划阶段需要额外 Token错误恢复天然支持随时可调整需要重规划机制场景选择场景推荐模式原因单步问答 / 简单查询ReAct不需要规划查完即答多步工具调用如订票ReAct每一步依赖上一步结果需要动态决策复杂文档生成如周报Plan-and-Execute先定结构再填充保证完整性代码修改 / 多文件重构Plan-and-Execute需要先理解整体再做修改未知探索任务如做研究ReAct中间发现可能改变方向故障排查 / DebugReAct逐步缩小范围灵活调整实际生产中最常用的是两者的混合——初始化时先生成一个 High-Level Plan但在执行每个步骤时用 ReAct 的模式做细粒度决策遇到阻塞时允许重规划。这就是Plan-and-Solve ReAct 混合模式。Q6. 你设计过Multi-Agent系统吗讲讲你如何决定什么时候拆成多 Agent以及 Agent 之间怎么通信什么时候该拆成多Agent角色冲突单个 Agent 既要严格检查又要创意回答角色矛盾知识域隔离需要访问不同的数据源/工具集放一起导致 Tool 选择准确率下降需要不同推理策略一个 Agent 需要严谨的逐步推理另一个需要快速直觉判断跨系统边界需要调用不同权限域的资源可观测性要求需要分别追踪每个环节的耗时和成功率多Agent的缺点多Agent增加了延迟、Token成本、协调复杂度3个以上Agent的对话系统协调成本指数级上升一个 Agent 好 Prompt 能解决的问题拆成多 Agent 是过度设计Agent 通信模式建议Agent之间的消息需要结构化协议不能纯文本对话要定义消息 Schema需要超时机制一个 Agent 卡住不能阻塞整个系统建议引入共享上下文一个全局的黑板 / 共享 Memory降低重复传递信息的 Token 成本Q7. Agent死循环Tool Loop的检测和恢复策略有哪些死循环的典型表现反复调用同一个工具传入不同参数但语义一样A 工具和 B 工具互相调用把对方的输出当成自己的输入持续报错→重试→报错→重试推理阶段不断「自我质疑」不产生行动检测策略恢复策略策略做法适用场景Prompt Intervention插入一条 system message 提示 Agent 换个方向轻微死循环上下文截断丢弃中间部分的冗余对话Agent 积累了过多上下文强制摘要让另一个 LLM 压缩当前进展重新启动循环严重死循环降级策略退化为简单的问答模式停止工具调用无法恢复时Human Handoff转人工处理以上都失败时工程兜底生产环境必须配置绝对兜底——达到最大轮次或 Token 预算上限后强制结束并回复“当前无法完成请尝试简化您的需求”或转人工。3. Tool Calling与函数调用Q8. 怎么定义一个“好的”工具踩过哪些坑典型不好的工具定义不好的原因是描述太模糊参数名意义不明模型不知道什么时候该用正确的定义关键踩坑经验坑现象解决描述太短模型不知道什么时候用这个工具写清楚“何时调用 / 何时不要调用”参数名太短q / id / val 模型不知道填什么用完整语义的名词缺少类型约束传入字符串 123 但 API 要数字严格标注 JSON Schema 类型枚举值不全模型自己编造不在枚举里的值enum字段约束缺少默认值模型不传可选参数导致不确定性给合理默认值没有边界描述用户问非技术问题也调了知识库在 Description 中声明排除场景工具太多Agent 一次选错工具的几率上升工具超过 20 个需做分组/层级暴露工具竞食两个工具功能重叠模型反复纠结保证工具职责互斥工程原则工具定义的 Description 是在给模型写说明书写清楚这是什么、什么时候用、什么时候不用、参数是什么意思。把工具定义当成API文档来写宁可啰嗦不能模糊Q9. 工具调用失败了怎么办你的错误处理策略是什么分层错误处理策略代码实现关键认知工具错误信息是 Agent 的“新 Observation”输入给 LLM 之后的 LLM 行为决定了 Agent 是否智能一个好的 Agent 会分析错误原因并修正参数重试Q10. 如果给 Agent 注册了 30 个工具Tool Selection 准确率下降怎么办这是Agent工程中非常实际的问题——模型在太多工具中选对的难度会指数级上升。优化策略工具分组基于意图的预路由动态工具注册Tool Embedding 检索工具聚合Composite Tool把多个细粒度工具封装成一个粗粒度工具内部做二次路由比如一般来说工具数从 5 个增加到 20 个Tool Calling 准确率从约 95% 下降到约 75-80%。分组到每级 5-8 个可以恢复到 90%4. Prompt EngineeringQ11. 你如何设计和迭代一个 System Prompt遇到过什么反直觉的问题System Prompt 设计方法论示例架构反直觉的踩坑经验坑与反直觉点原因对策越短的 System Prompt 效果越好长 Prompt 稀释了关键指令删除所有非关键内容重要的放前 20%说「不要做 X」有时反而触发 X模型关注到负面描述的 Token用正向引导替代负面禁止放尾部的规则常被忽略Lost-in-the-Middle 现象最重要的规则放最前面具体指令比抽象原则有效“回答不超过 3 点”比“要简洁”有效用可量化的约束长 Prompt 大幅增加 Token 成本每次对话都要带 System Prompt定期评估“每条规则是否值得它的 Token”Q12. 你怎么设计 Prompt 来防止 Agent 被用户注入攻击Prompt InjectionPrompt Injection 在 Agent 场景下特别危险因为 Agent 有工具调用能力攻击者可能诱使 Agent 执行删除数据、泄露信息等操作防御策略分层防御Prompt 级别的具体实现额外的工程手段对用户输入做特殊字符转义如将转义为实体在 Agent 的 Tool Execution 层再做一次参数校验不信任任何来自 LLM 的内容关键操作支付、删除、写操作的 Tool 在执行前先调用一个Permission Check Tool做前置审批5. RAG 与记忆管理Q13. 你设计过 RAG 系统吗讲一下 Chunk 策略是怎么选的Chunking 策略决策树关键参数参数推荐值说明Chunk Size256512 tokens太小信息不完整太大检索噪声多Overlap10%20% of chunk size避免关键信息正好被切在边界Embedding Modelada-002 / bge-large / text-embedding-3-small领域特定数据建议微调或选更大型号Top-K Retrieval35答案需要的信息通常来自 3-5 个块踩过的坑没有 Overlap→ 一些关键信息恰好在两个 Chunk 的边界被截断检索不到Chunk 太大→ 一个 Chunk 包含多个主题检索到但模型不知道该用哪部分只做单层检索→ 加一层 Rerank 可以显著提升 Top-K 的质量不区分文档类型统一参数→ 代码和自然语言文档应该用完全不同的 Chunk 策略进阶Q14. Agent 的上下文窗口满了怎么办你的压缩策略是什么上下文窗口满了是不能回避的问题特别是长对话 Agent。分层压缩策略Token 预算分配策略核心原则最新的信息保留最完整中间的要压缩关键事实结构化提取不要等到满了才处理每次对话后会做增量压缩6. 评估与可观测性Q15. 你怎么评估一个 Agent 好不好Eval 体系怎么搭建Agent Eval 三层体系Eval数据集构建Eval 工作流Q16. 你的 Agent 在生产环境出问题了怎么排查Agent 排障的难点在于你不能像 Debug 代码那样去 Debug Agent因为每次输出都可能不同。排查工具箱一站式排查流程没有 Tracing 的 Agent 系统就是盲人摸象在 Agent 上线前必须先接入Tracing工具LangSmith / LangFuse这是最重要的基础设施投资。7. 安全与护栏Q17. 你给 Agent 设计过安全护栏吗怎么防止 Agent 做它不该做的事Agent调数据库DELETE 怎么办分层安全模型Defense in Depth编码实现示例Agent调数据库DELETE 怎么办System Prompt 明确禁止“执行非只读 SQL”数据库 Tool 内部做 SQL 解析检测到 DELETE / DROP / TRUNCATE 直接拒绝写操作类 Tool 需要用户二次确认 操作审计日志8. 工程落地与场景题Q18. 设计一个Android技术顾问 Agent你会怎么设计架构系统架构工具定义Tool用途权限search_android_doc搜索官方 Android 文档只读search_tech_wiki搜索内部技术 Wiki只读search_gitlab_code搜索 GitLab 仓库代码只读search_issue搜索 Bug / 需求只读read_file_content读取文件内容了解上下文只读summarize对长文本做摘要无副作用generate_code_snippet生成代码片段只输出文本刻意不开放的工具modify_code: 不开放Agent 不做代码修改delete_file: 不开放deploy: 不开放边界处理非技术问题意图分类器检测到非 Android 技术问题 → 礼貌拒绝公司内部信息Agent 需要确认用户有权限访问该信息否则说没有权限不确定的答案必须说这个我不确定并给出查找方向代码安全性生成的代码片段必须包含注释说明风险和适用版本成本控制简单问题用 Claude Haiku / GPT-4o-mini 处理复杂问题才升级到旗舰模型RAG 检索结果的缓存相同问题直接命中缓存设置单次对话 Token 上限防止预算失控Q19. 你要把一个 AI Agent 部署到线上要考虑哪些问题画一个部署架构部署关注点清单延迟 (Latency)LLM 调用的 P50 / P95 / P99 耗时监控流式输出Streaming减少首 Token 等待时间RB-Tree 缓存相同请求直接返回缓存结果对简单问题做模型降级Claude Sonnet → Claude Haiku成本 (Cost)Token 用量监控 预算告警缓存策略减少重复调用Prompt 压缩降低每次调用的 Token 数长对话的自动摘要压缩可靠性 (Reliability)LLM API 的重试 降级主模型挂了 → 备用模型每个 Agent 步骤设置超时 → 超时触发降级健康检查Health Check/ping → 快速检测 Agent 是否健康限流Rate Limiting防单个用户刷量可观测性 (Observability)全链路 Tracing每步的耗时 / Token / 工具调用业务指标监控成功率 / 用户满意度 / 工具准确率异常告警Token 激增 / 成功率骤降 / 延迟飙升日志保留Agent 的 Thought 过程是 Debug 的核心依据安全 (Security)用户鉴权JWT / API Key工具调用权限控制输入输出安全检查审计日志所有操作可追溯Q20. 你如何控制Agent的调用成本用户一次对话花了10万Token怎么办成本控制应该是系统设计的一部分而不是出了问题再去查。事前预防措施效果每轮对话 Token 上限如 20K防止单次失控最大推理轮次如 10 步防止 Tool Loop 消耗模型分层简单→小模型复杂→大模型降低 50-70% 成本缓存命中相同的 RAG 查询直接返回降低检索成本Prompt 瘦身去掉非关键指令用短名称每轮节省 5-10%工具分组只暴露当前需要的减少 Tool Definition 占用的窗口事中监控事后分析每日常规Token 用量报表按用户 / 对话 / Agent 分类识别CPUCost Per User最高的用户——是正常使用还是滥用识别异常的 Token Spike,突然暴涨通常意味着 Bug事后按照以下问题排查是不是 Agent 陷入了 Tool Loop是不是有工具返回了巨量数据是不是用户的问题是 LLM 无法处理的是不是 System Prompt 或 Tool Definition 太大然后针对根因做修复加轮次上限、工具返回结果截断、Prompt 瘦身Q21. 如果你现在要在 Android 手机上实现一个本地 AI助手Agent你会怎么做整体架构端侧模型的取舍不要期望端侧模型能像 GPT-4 一样推理端侧做意图分类 简单问答 工具路由云端做复杂推理 长文本生成关键数据通讯录/短信绝不离开设备实现要点Agent 作为一个Foreground Service运行常驻后台用Notification 快捷回复作为交互入口Tool Calling 通过Android 原生 API实现用DataStore / Room做会话持久化需要Privacy Sandbox级别的权限管控端侧 Agent 的工具举例Tool实现权限query_contactsContentResolver.query(ContactsContract)READ_CONTACTSread_calendar_eventsContentResolver.query(CalendarContract)READ_CALENDARsend_notificationNotificationManager.notify()POST_NOTIFICATIONSsearch_filesMediaStore或 SAF文件访问权限take_screenshotMediaProjection屏幕录制权限open_appPackageManager.getLaunchIntentForPackage()无特殊权限web_search网络 API 调用INTERNETQ22. 在 Agent 场景下你怎么测一个非确定性系统核心认知Agent 的测试不是传统“对或错”的测试而是统计学的“在多少情况下表现可接受”分层测试策略自动化评估工具关键指标不要求 100% 准确不可能因为 LLM 有概率性设定 SLOService Level Objective如 Tool Selection 准确率 ≥ 90持续监控每次模型升级 / Prompt 修改后回归测试异常检测如果成功率突然从 92% 降到 85%说明有回归问题收个尾我觉得现在用AI跟开车有点相似开车现在基本谁都会开挂个档踩个油门没啥难度但是如果车出点问题爆胎了你会换胎吗车子开一半熄火了你能知道是什么原因吗甚至之前我看到一视频里面有人玻璃水都不知道往哪个洞洞眼里面灌也不知道是不是真的AI也是如此会用AI的人很多但懂AI的人很少当所有人都在用AI写周报、做PPT、画图的时候你如果能理解ReAct循环为什么能防死循环、知道如何优化Lost-in-the-Middle现象那么你就不再是AI的用户了而是AI的工程师资料展示下面是我整理的AI大模型 学习资料和工具包 预览适合收藏后按主题逐步学习