AI 应用面试百题精讲（下）：工具集成 · 评测部署
每题结构：答（面试可说的口径）+ Review（纠偏、补强、追问点）。Review 里的坑往往比标准话术更值得先记。
系列导航
- 本篇：（下）工具集成 · 评测部署
- （上）大模型 · Python · Prompt
- （中）RAG · Agent
七、工具调用与系统集成
Q73. 什么是 Function Calling？它为什么重要？
答： Function Calling 就是让模型不要只输出自然语言，而是按预定义的参数结构告诉系统「我想调用哪个函数、传什么参数」。它的重要性在于把模型从「只能聊天」变成「可以驱动系统能力」的入口，同时也让参数校验、审计和权限控制变得更可做。
Review： 结构化调用意图让校验/审计成为可能。模型只「提议」，执行必须在你的沙箱里。
Q74. MCP 的价值主要体现在哪？
答： 它的价值在于把原来零散、各写各的工具接入方式标准化，让模型应用可以更一致地接资源、接工具、接上下文能力。对企业来说，这样做的好处是接入成本更低、复用性更强、治理边界更清楚。简单说，MCP 不直接提升模型智商，但能提升整个工具生态的可组合性。
Review： 提升可组合性与治理，不提升模型智商。别吹成「新一代智能」。
Q75. 设计工具 Schema 时，最重要的原则是什么？
答： 我会强调四个原则：语义清晰、参数最小化、边界明确、可校验。工具描述一定要让模型知道这个工具能干什么、不能干什么、什么时候该调用；参数不要把不必要的自由度放给模型；返回值要尽量结构化，方便后续判断。Schema 设计得越清楚，模型误用工具的概率就越低。
Review： 清晰、最小参数、可校验。工具 description 要当产品文案迭代。
Q76. 为什么智能体工具必须做权限分级？
答： 因为读操作和写操作、查询操作和对外执行操作、低风险动作和高风险动作，本来就不应该由同一套权限控制。权限分级可以避免模型在一次错误判断后直接造成不可逆后果。对高风险工具，我通常会加白名单、参数校验、二次确认甚至人工审批。
Review： 读写/对外执行分级。高风险：白名单、二次确认、审批流。
Q77. 智能体调用外部 API 时，为什么要考虑幂等性？
答： 因为网络超时、重试、重复调用在分布式系统里很常见。如果一个创建订单、发消息、提交工单的接口不具备幂等性，智能体一旦重试就可能产生重复操作。面试里可以直接说，模型调用工具和普通服务调用一样，最终还是要回到分布式系统的基本原则上来。
Review： 超时重试会放大副作用。创建类工具必须幂等键——分布式基本功。
Q78. 让智能体读写文件、改代码时，安全上要注意什么？
答： 核心是最小权限原则和可审计原则。首先只开放必要目录和必要动作，不要默认全盘可写；其次要区分扫描、读取、修改、删除这几类风险；再就是高风险动作必须先列出影响范围并确认。因为一旦把文件系统作为工具暴露给智能体，它面对的就不是「文本生成」，而是真实的系统副作用。
Review： 最小权限 + 审计。区分读/改/删；先展示 diff 再应用。
Q79. 浏览器自动化在智能体里适合哪些场景？风险是什么？
答： 它适合处理必须基于页面交互的任务，比如后台录入、网页测试、抓取动态页面信息、流程演示。风险主要在于页面结构容易变、登录态容易失效、动作不可预测、以及可能误触真实业务按钮。我的看法是，浏览器自动化应该优先用于低风险、可回放、可验证的任务，而不是直接拿去做高风险生产操作。
Review： 适合低风险可回放任务。生产误点按钮是真实事故模式。
Q80. 为什么很多智能体任务要改成异步任务或后台任务？
答： 因为有些任务天然就不是秒级完成的，比如全库检索、批量生成文档、多步工具链执行、长时间网页操作。如果硬塞进一次同步请求里，用户体验差，服务资源也会被长时间占住。把它做成异步任务后，可以让前端先拿到任务 ID，再轮询状态或接收回调，整体系统会更稳。
Review： 长链路异步化。返回任务 ID + 状态/回调；别把多分钟 Agent 塞进一次 HTTP。
Q81. AI 应用为什么特别需要缓存和限流？
答： 因为模型调用贵、慢，而且下游依赖通常也多。缓存可以减少重复请求成本，比如重复问答、重复检索、重复 embedding；限流则是防止用户突发流量把模型配额、线程池和下游工具一起冲垮。对 AI 系统来说，缓存和限流不只是性能优化，更是成本治理和稳定性治理。
Review： 成本与稳定性手段。语义缓存比字符串缓存更有用，但要注意失效与权限。
Q82. AI 应用接企业内部系统时，最大的挑战通常是什么？
答： 通常不是「怎么调 API」，而是权限、数据口径、幂等、审计、流程边界和责任归属。企业系统往往有严格的主数据定义和操作约束，如果智能体绕过这些规则，效果再聪明也落不了地。所以我会把企业集成理解为「把 AI 放进原有治理体系」，而不是「让 AI 凌驾于原有系统之上」。
Review： 挑战在治理：权限、口径、责任。AI 要嵌入原有体系，而不是绕过。
八、多智能体、记忆与工作流编排
Q83. 短期记忆和长期记忆的本质区别是什么？
答： 短期记忆服务的是当前任务，强调即时性和相关性，比如这一轮会话、当前计划、中间观察结果。长期记忆服务的是跨任务复用，强调稳定性和持续价值，比如用户偏好、组织术语、项目约定。它们的区别不只是保存时间长短，更在于「是否值得跨会话保留」。
Review： 区别在「是否值得跨会话保留」，不单是 TTL。
Q84. 为什么记忆不能什么都存？
答： 因为什么都存会把噪声、错误和隐私风险一起放大。记忆系统最怕两件事，一是把临时信息当长期事实，二是把未经验证的信息反复带入后续任务。好的记忆写入策略应该是少而准，只保留跨会话真正有价值、且可信度足够高的信息。
Review： 少而准；未验证信息不要升格为长期事实。隐私与错误记忆是双风险。
Q85. 什么时候值得用多智能体协作？
答： 当任务天然存在角色分工、不同阶段需要不同能力、或者并行执行能显著节省时间时，多智能体才有意义。比如研究、编码、审查、汇报四类任务明显不同，就可以拆成不同代理协作。反过来说，如果一个代理已经能清楚完成，就没必要为了「看起来高级」硬上多智能体。
Review： 有天然分工再上多 Agent。为酷而上 = 复杂度税。
Q86. 多智能体之间应该怎么通信才更稳？
答： 我更倾向于让它们传递结构化消息，而不是随意长篇对话。比如明确任务目标、输入、输出格式、状态、是否完成、需要谁接力。因为代理一多，上下文漂移和责任不清会非常快地放大，所以通信协议越明确，系统越稳定。
Review： 结构化消息 > 闲聊式互聊。协议不清，漂移与甩锅极快。
Q87. 工作流引擎和 Agent 框架分别适合干什么？
答： 工作流引擎适合做固定流程编排、状态流转、重试补偿、定时任务和可视化流程管理；Agent 框架更适合处理开放决策、工具选择和动态规划。我的经验是，生产环境里经常是工作流做骨架，Agent 做局部高自由度决策，两者并不是互斥关系。
Review： 工作流骨架 + Agent 局部决策——生产常见形态。与 Q60 同一判断框架。
Q88. 什么是事件驱动的 AI 工作流？
答： 就是把 AI 任务的启动和推进建立在事件上，比如用户上传文档、工单状态变化、数据库有新增记录、某个任务执行完成后触发下一步。这样做的好处是系统更解耦，也更适合长链路、多步骤和异步场景。很多真正上线的 AI 业务，并不是一轮对话解决全部，而是由多个事件逐步推进。
Review： 事件驱动适合长链路。上传/工单变更触发，而不是一切塞进一轮聊天。
Q89. 什么场景其实不适合用智能体？
答： 如果流程固定、规则明确、结果格式稳定、出错成本又高，那我通常更建议用普通程序或工作流，而不是智能体。比如固定报表生成、标准字段映射、明确规则审批，这类事情不需要让模型自由发挥。判断是否适合用智能体，一个很实用的标准就是：这件事到底需要动态决策，还是只是流程自动化。
Review： 固定规则、高错误成本 → 别用 Agent。这题考的是克制，不是堆概念。
Q90. 做 Agent 产品时，除了准确率，还应该关注哪些业务指标？
答： 我会关注任务完成率、人工接管率、平均步数、单任务成本、总耗时、工具成功率、重复调用率、用户复用率和最终业务转化。因为智能体不是纯模型评测题，真正上线后更重要的是它到底有没有帮业务完成任务、有没有把人工成本降下来。
Review： 业务指标：完成率、接管率、成本、步数。准确率只是其一。
九、评测、安全、部署与面试实战
Q91. AI 应用应该怎么做评测？
答： 我一般会把评测分成离线集评测和线上真实反馈两部分。离线评测负责可重复、可对比，适合看不同提示词、不同检索策略、不同模型的差异；线上评测负责看真实用户是否买账，包括点击、追问、人工接管和满意度。只有离线没有线上，容易脱离真实业务；只有线上没有离线，又很难快速定位问题。
Review： 离线可复现 + 线上真反馈，两边都要。只有一边会盲区很大。
Q92. 离线评测和在线评测的区别是什么？
答： 离线评测用固定数据集，优点是稳定、可复现、方便做 A/B 对比；缺点是可能覆盖不到真实世界的复杂输入。在线评测直接看线上效果，优点是最贴近真实业务，缺点是成本更高、变量更多。我的做法一般是离线先筛方案，线上再灰度验证。
Review： 离线筛方案，线上灰度。变量多时先固定评测集。
Q93. AI 应用的时延一般从哪些地方优化？
答： 通常从四个方向优化：第一，减少无效上下文和不必要步骤；第二，优化检索和工具链路，比如并发化、缓存化；第三，模型侧选更合适的尺寸、量化和流式输出；第四，网络侧减少跨区域和重复连接。时延优化不能只盯模型本身，很多时候真正慢的是检索、工具和串行编排。
Review： 慢点常在检索、工具与串行编排，不在「模型算得慢」。流式改善体感 ≠ 降低总时延。
Q94. AI 应用怎么做成本优化？
答： 核心思路是少调、少传、少生成、调对模型。比如能缓存就缓存，能先做轻量分类就不要一上来用大模型，能缩短上下文就不要把整份文档塞进去，能用小模型做初筛就不要所有环节都上最贵的模型。成本优化本质上不是「压榨模型」，而是让系统分层处理不同复杂度的问题。
Review： 少调、少传、少生成、调对模型。路由 + 缓存 + 裁上下文是组合拳。
Q95. AI 应用里的安全问题一般分哪几类？
答： 常见可以分成输入安全、输出安全、工具安全、数据安全和模型安全。输入安全包括提示注入和恶意内容；输出安全包括违规回答、事实错误、泄露敏感信息；工具安全涉及越权调用和危险操作；数据安全涉及隐私、权限和审计；模型安全还包括供应链、模型投毒和越狱风险。面试里如果能从「系统安全」而不是只从「内容安全」去答，会更完整。
Review： 从系统安全答，不只有内容审核。工具越权与数据出域常被漏。
Q96. 企业做 AI 应用时，数据隐私和合规通常要关注什么？
答： 首先要明确哪些数据能进模型、哪些必须脱敏、哪些不能离开内网；其次要有日志审计和权限控制，保证谁看了什么、谁调用了什么都能追踪；再就是供应商合规、数据保留期限和跨境传输要求。简单说，企业不是不能做 AI，而是必须在数据治理框架内做 AI。
Review： 什么能进模型、脱敏、审计、出境。合规是框架，不是口号。
Q97. 开源模型和闭源模型应该怎么选？
答： 如果业务更看重效果上线快、通用能力强、无需自己维护底层推理，闭源模型通常更省事；如果更看重数据可控、成本可控、可私有化和深度定制，开源模型更有优势。面试里我一般不会说谁绝对更好，而是会从能力、成本、时延、合规和可控性几个维度做取舍。
Review： 按能力/成本/时延/合规/可控性取舍。混合：网关后面多模型。
Q98. 一个生产级 AI 应用的部署架构应该考虑哪些点？
答： 我会重点考虑模型接入方式、服务拆分、缓存层、队列层、检索层、存储层、鉴权层、监控告警和灰度发布。除此之外，还要考虑多模型切换、故障降级、限流熔断、日志审计和弹性扩缩容。生产级架构的关键不是「能跑起来」，而是高峰能扛住、出错能止损、上线能回滚。
Review： 能扛高峰、能止损、能回滚。多模型切换与降级要设计进去。
Q99. AI 应用线上出事故时，你一般怎么排查？
答： 我会先判断是全局问题还是局部问题，再按链路拆分：请求入口、权限校验、检索、工具、模型调用、后处理、前端展示。然后结合日志、trace、指标看是质量下降、时延升高还是错误率升高。AI 事故很容易被误判成「模型不行」，但很多时候其实是索引没更新、外部工具超时、提示词改坏了，或者上下文拼装出了问题。
Review： 先分全局/局部，再按链路拆。很多「模型不行」其实是索引、提示词或工具问题。
Q100. 面试里如果让你介绍一个 “AI 应用或智能体项目 ”，你会怎么讲？
答： 我会按「业务目标、系统架构、关键难点、核心取舍、效果数据、线上问题与优化」这六部分来讲。先说这个项目解决了什么业务问题，再说整体链路是模型、检索、工具和业务系统怎么协同的，然后重点讲我真正负责的难点，比如提示词、RAG、工具治理、时延优化或安全控制。最后补上结果，比如完成率、时延、成本、人工节省比例，以及我做过哪些迭代优化。这样讲能让面试官快速判断我不是只会调 API，而是真的做过完整系统。
Review： 六段结构可用。务必准备 2–3 个真实权衡与踩坑；没有数据的「成功项目」很虚。
下一篇见系列导航。若你只想先背高频题，优先：Q6/Q10/Q40/Q45–Q52/Q60/Q65/Q68/Q94/Q100。
下一篇见系列导航。若只想先抓高频：Q6 / Q10 / Q40 / Q45–Q52 / Q60 / Q65 / Q68 / Q94 / Q100。