工作知识库

Appearance

AI智能体应用开发面试题 ​

生成时间：2026-06-13 00:45
题数：10道
适用：1-3年经验岗位

【面试题】1. 在大模型API调用中，如何处理Token限制和成本控制？请结合实战经验谈谈你的做法。 ​

【标准答案】 我从三个层面控制： 第一，输入侧做压缩。长上下文先走摘要链路，用LLM把原始文档压到核心信息再进主链路；对话历史用滑动窗口+重要性打分，只保留最近N轮和高价值历史。 第二，输出侧设上限。max_tokens按场景定，比如分类任务设小，创作任务设大；用streaming模式，前端展示同时后台做截断保护。 第三，成本监控。按trace_id打点，记录每次调用的input/output token数，聚合到用户/功能维度；设置日级/月级预算告警，超阈值自动降级到小模型或走缓存。 实际项目中这套方案把平均token消耗降了60%，成本可控。

【面试题】2. 你用LangChain开发过Agent，说一下ReAct和Plan-and-Execute两种模式的区别，什么场景选哪个？ ​

【标准答案】 ReAct是每一步都决策：Thought→Action→Observation→Thought，循环直到给出答案。优点是灵活，能应对动态变化；缺点是步骤多、延迟高、容易中途跑偏，适合需要实时交互、步骤不确定的场景，比如客服、数据探索。

Plan-and-Execute是先做规划再执行：LLM先生成完整执行计划，然后按步骤调用工具。优点是可控性强、可审计、失败可重试单步；缺点是规划能力依赖模型，计划质量不稳定，适合流程相对固定、可预定义的场景，比如报表生成、ETL流水线。

我实际选型逻辑：用户能接受等待→Plan-and-Execute；需要实时反馈→ReAct；两者结合→先用Plan生成大纲，执行时允许ReAct式的动态调整。

【面试题】3. RAG系统上线后效果不好，你会从哪几个维度排查和优化？ ​

【标准答案】 我按"召回→排序→生成"三阶段排查：

召回层：看检索命中率，用标注query测top-k准确率；检查chunk_size是否合理，太大丢失精度、太小丢失上下文；embedding模型是否匹配业务域，通用模型对专业术语效果差就换fine-tuned版本；混合检索（向量+关键词+SQL）补全单一向量检索的短板。

排序层：召回结果是否经过rerank，直接用vector score容易误导；是否引入业务权重（时效性、权威性）；是否做过negative sampling优化。

生成层：context是否真正被模型"看到"，有些模型长上下文会注意力衰减；prompt是否明确要求"基于给定资料回答、不瞎编"；是否加了citation要求倒逼模型用原文。

我做过一个项目，光把chunk_size从500调到200、加rerank，准确率从62%提到84%。

【面试题】4. 多智能体协作（Multi-Agent）架构，你踩过什么坑？怎么解决的？ ​

【标准答案】 最大坑是"对话爆炸"——Agent之间来回聊天，token消耗高、还容易死循环。我的解法：

  1. 强制结构化输出，每个Agent的输出必须是JSON Schema，不能自由文本，这样下游Agent解析稳定；
  2. 设最大轮次上限，比如2个Agent之间最多交互3轮，超了就强制终止并上报人工；
  3. 引入仲裁者（Arbiter）角色，不是所有Agent对等协作，而是有一个协调者做最终决策，减少P2P通信。

第二个坑是状态共享混乱。解决方案是用共享黑板（Blackboard）模式，所有Agent读写同一个状态对象，而不是通过消息传递状态，这样可调试、可回滚。

第三个坑是某个Agent失败导致整条链路挂掉。加了断路器模式，单Agent失败有fallback策略，比如降级到规则引擎或直接返回"需要人工处理"。

【面试题】5. 你如何给Agent设计记忆系统？短期记忆和长期记忆分别怎么实现？ ​

【标准答案】 短期记忆用对话缓冲区：最近N轮对话存在内存/Redis，每次请求带进去。关键是做"记忆压缩"——超过窗口的旧对话用LLM摘要成一段文字，释放token空间。我一般设窗口20轮，超出的每5轮触发一次压缩。

长期记忆用向量库：把历史对话、用户偏好、项目上下文embedding后存向量数据库（我常用Qdrant或Chroma），每次对话前做相关性检索，把最相关的Top-K段记忆注入prompt。

还有一个实战技巧：用户显式说"记住xxx"时，我把它结构化存到Key-Value存储（Redis/SQLite），比如user:123:prefers = "不喜欢营销电话"，这种精确记忆用检索不如直接KV靠谱。

这三层结合：短期保连贯性、长期保个性化、KV保精确事实，效果比单用一种好很多。

【面试题】6. Dify和LangChain你都用过，说说它们的定位和选型逻辑。什么情况用哪个？ ​

【标准答案】 Dify是低代码平台，定位是"快速交付业务应用"。优势：可视化工作流、开箱即用的RAG/工具调用、权限管理和多租户支持。适合：非技术人员要参与配置、需要快速上线MVP、团队没有很强的工程能力。

LangChain是开发框架，定位是"灵活构建复杂Agent逻辑"。优势：完全可编程、和现有代码库深度集成、自定义程度高。适合：需要复杂状态管理、要和内部系统深度集成、对性能/成本有精细控制需求。

我的选型逻辑：

  • PoC/内部工具 → Dify，一周搭出来
  • 核心业务系统 → LangChain，可控可优化
  • 两者结合 → Dify做前端和工作流编排，背后接LangChain写的复杂Agent服务

实际上我们生产环境是Dify做业务流程编排，复杂逻辑节点调用自研的LangChain Agent服务，取长补短。

【面试题】7. 你做过的最有挑战的Agent项目是什么？遇到的最大技术难点是什么？怎么解决的？ ​

【标准答案】 最有挑战的是给金融机构做研报分析Agent，输入是几十份PDF研报（每份50-100页），输出是结构化投资观点。

最大难点：PDF解析质量差，表格、公式、多栏排版经常乱；研报专业术语多，通用embedding召回不准；输出要求高度结构化（JSON Schema），模型容易漏字段或格式错误。

解决方案：

  1. PDF解析用PyMuPDF+LayOutParser组合，保留版面信息，表格单独提取；
  2. 用金融领域语料fine-tune embedding模型（用研报标题-正文对），召回准确率从68%提到87%；
  3. 输出结构化用"多次生成+校验"模式：第一次生成→schema校验→失败则把错误信息反馈给模型重新生成，最多重试3次，最终准确率达到95%；
  4. 整个流程用Celery做异步任务队列，支持批量处理。

这个项目让我深刻理解到：Agent不只是调LLM，工程链路的质量决定最终效果。

【面试题】8. 工具调用（Function Calling）失败率高，你如何从Agent侧和工具侧分别优化？ ​

【标准答案】 Agent侧优化：

  1. 工具描述（docstring）要极其清晰，我要求每个工具的description写"能做什么+不能做什么+参数示例"，模型才能准确判断是否调用；
  2. 参数提取不稳定→用structured output（response_format=json_schema）强制模型输出符合schema，再传给工具；
  3. 失败重试策略：网络超时重试3次、参数错误尝试让模型修正后再调用、工具返回空结果时自动调整参数再试。

工具侧优化：

  1. 工具本身要做输入校验和友好错误提示，不能只返回"500错误"，而要返回"缺少必需参数xxx"；
  2. 工具执行时间长的要做异步+轮询，不能让Agent一直阻塞；
  3. 工具返回结果要精简，大结果先摘要再返回给模型，避免填爆上下文。

我实际做法是：工具调用封装一层Adapter，统一做日志、重试、结果裁剪，Agent侧代码干净很多。

【面试题】9. 说说你对Agent"对齐"和"安全"的理解。生产环境中你做过哪些安全措施？ ​

【标准答案】 对齐是确保Agent行为符合人类意图和价值观，安全是防止Agent被滥用或产生有害输出。

我做过的安全措施：

  1. 输入过滤：敏感词检测、SQL注入检测、Prompt Injection检测（比如用户试图让Agent"忽略之前指令"的攻击）；
  2. 输出过滤：LLM输出经过内容安全审核（调用内容安全API），违规则拦截并告警；
  3. 权限隔离：Agent调用的工具按最小权限原则设计，比如"发送邮件"工具只能发给定制白名单地址，不能任意发送；
  4. 操作确认：高风险操作（删除数据、发送对外消息）要求人工确认或二次校验；
  5. 审计日志：每次工具调用、每次LLM输出都记录trace，出问题能回溯；
  6. 速率限制：防止用户恶意刷接口导致成本爆炸，按用户/API Key设QPS和日调用上限。

最核心的一点：不要把Agent当成完全自主的系统，关键决策点必须有人工介入的抓手。

【面试题】10. 如果让你从0到1设计一个企业知识库问答Agent，你会怎么规划技术选型和实施路径？ ​

【标准答案】 技术选型：

  • LLM：问答质量优先选GPT-4o或DeepSeek-V3，成本敏感用DeepSeek-V2.5；
  • 向量数据库：Qdrant（生产级、部署简单）或Chroma（快速起步）；
  • 框架：Dify（要快速交付）或LangChain（要深度定制）；
  • Embedding：业务域专业→fine-tune；通用→用text-embedding-3-large或bge-large-zh；
  • 解析：Unstructured或PyMuPDF处理多格式文档。

实施路径（6周）： Week 1-2：MVP，支持单文档上传+问答，验证RAG基本链路； Week 3-4：多文档、权限管理、来源引用，达到内部试用标准； Week 5：接入企业SSO、操作日志、成本监控，达到上线标准； Week 6：灰度发布，收集用户反馈，迭代优化。

关键风险预判：PDF解析质量、回答幻觉、权限隔离。我的对策是早期就引入人工审核机制，badcase进入标注库持续迭代。

这个规划的核心是：先验证价值再完善功能，避免一开始就做复杂系统。

本题库由AI智能体应用开发面试题生成器自动生成，聚焦1-3年经验岗位核心考点。