AI智能体应用开发面试题（2026-06-16-005000）
【面试题】1. 大模型的Temperature参数怎么设置？不同场景下你用什么值？为什么？
【标准答案】
Temperature控制输出的随机性，本质是在softmax层调节概率分布的平滑程度。
我的设置原则：
Temperature=0：确定性场景，比如信息抽取、数据格式转换、代码生成。要的是稳定输出，同样的输入必须得到同样的结果。缺点是输出会很"机械"，缺乏多样性。
Temperature=0.3-0.5：对话场景、客服问答、知识问答。保留一点点随机性，回答自然但不离谱，不会每次都一模一样。
Temperature=0.7-0.9：创意写作、头脑风暴、文案生成。这时候需要发散性思维，让模型多给几种可能性。
Temperature>1.0：几乎不用。输出太发散，质量失控，除非是故意要"天马行空"的创意场景。
实际项目里我的默认配置是：RAG问答用0.2，Agent工具调用用0（保证参数稳定），创意文案用0.7。核心逻辑是：涉及结构化输出和决策的场景，Temperature越低越好；涉及创意的场景，可以适当调高。
【面试题】2. Structured Output（结构化输出）怎么做？让模型输出JSON有哪些坑？
【标准答案】
三种主流方式：
方式一：Function Calling——最推荐。在tools里定义参数Schema，模型会按Schema输出，参数校验由API层面保证。适合需要稳定JSON输出的场景。
方式二：Constrained Decoding——部分模型支持，比如用Guidance或者vLLM的guided decoding，强制模型只输出符合Schema的token。最稳定，但需要自部署模型。
方式三：Prompt约束——在提示词里写"你必须输出JSON，格式如下..."，然后后处理解析。最不稳定，模型经常多输出解释性文字或者格式错误。
常见的坑：
- 模型输出JSON前喜欢加```json标记，后处理要去掉
- 嵌套层级太深的Schema，模型容易填错
- 枚举类型的字段，模型会自创新值
- 数值字段有时候会输出字符串
我的做法：关键业务用Function Calling，Prompt里只做兜底提示，后处理加Schema校验（用Pydantic），校验失败就要求模型修正后重试，最多3次。
【面试题】3. 用户说"你上次答应帮我XX"，但Agent不记得了，这种场景怎么处理？
【标准答案】
这是典型的跨会话记忆问题。用户说的"上次"可能是几小时前、几天前，甚至跨了设备。
我的方案分三层：
第一层：会话续接检测——用户说"上次"、"之前"、"之前说的"这些关键词时，先检索该用户的历史会话摘要，找到最相关的1-2个会话，把摘要注入当前上下文。
第二层：长期记忆检索——用向量数据库存储用户的历史对话摘要。用户ID+时间窗口作为检索条件，召回相关的历史交互。
第三层：结构化承诺记录——当Agent承诺做某事时（比如"明天帮你查"），把这个承诺结构化存储（用户ID、承诺内容、截止时间），而不是靠模型去"记"。
实际案例：一个个人助理Agent，我设计了"承诺追踪"模块——每次Agent承诺用户的任务都会记录到数据库，用户下次问"你答应我什么来着"，直接查库返回，而不是让模型回忆。
关键是要承认"我不记得"——与其瞎编，不如诚实回答"抱歉，我这边没有找到您说的那次对话记录，能提醒我一下具体是什么事吗？"
【面试题】4. 多智能体协作时，如果两个Agent给出了冲突的建议，怎么处理？
【标准答案】
这是多Agent系统的核心难题。我的处理方案：
方案一：仲裁Agent——引入一个专门的仲裁Agent，接收多个Agent的建议，做最终决策。仲裁Agent的Prompt里明确："你要权衡不同建议的利弊，给出最终方案"。
方案二：投票机制——奇数个Agent（3个或5个），每个给方案+置信度，加权投票。置信度可以用模型输出的logprobs或者让模型自己打分。
方案三：人工介入——冲突超过阈值（比如2个Agent建议完全相反），推给人工决策，不要让系统自动选。
实际项目里的做法：我设计过一个投资决策系统，3个Agent分别从"风险"、"收益"、"合规"三个角度给建议，一个仲裁Agent综合三方意见。关键是Prompt设计：每个专家Agent只能从自己的专业角度发言，不能越界，这样减少冲突的概率。
冲突本身不是坏事——说明系统在多角度思考。但最终决策必须有明确的规则，不能模棱两可。
【面试题】5. 智能体调用外部API时，怎么保证安全？API Key怎么管理？
【标准答案】
安全是Agent系统的红线，分三个层面：
第一层：API Key隔离——绝对不能把API Key硬编码在代码里，更不能出现在Prompt里。用环境变量或密钥管理服务（AWS Secrets Manager、Azure Key Vault）存储，运行时动态注入。
第二层：最小权限原则——Agent调用的API Key只给最小权限。比如只查订单的接口，就不要给写权限；只读数据库的Agent，数据库账号就不要给写权限。
第三层：调用审计——每次外部API调用都记录日志（调了什么接口、传了什么参数、返回了什么），出问题能追溯。敏感操作（支付、删除）要二次确认。
工程实践上：
- API调用走后端代理，前端和Agent只能调内部接口，不能直接碰外部API
- 敏感参数（用户手机号、身份证）在日志里脱敏
- 生产环境和测试环境的API Key分开
我见过最严重的问题：有人把AWS密钥写到了Prompt里，用户通过Prompt Injection拿到了密钥，直接把整个云环境掏空。这个教训让我对所有敏感信息的管理都极其严格。
【面试题】6. RAG系统召回的相关文档太多（比如50条），全部塞给模型会超Token，怎么处理？
【标准答案】
这是典型的"召回过多"问题。我的处理流程：
第一步：粗筛——向量检索时限制top_k=20，不要一上来就拉100条。粗筛阶段宁可漏一点，也不能把噪声全放进来。
第二步：精排——用Rerank模型对20条结果做重排序，取top 5-8。Rerank模型（BGE-reranker、Cohere Rerank）专门做这个，比纯向量检索准。
第三步：上下文压缩——如果还是超，对每条文档做摘要压缩，只保留和问题相关的句子。LangChain有ContextualCompressionRetriever，可以集成。
第四步：动态截断——按token数截断，把最相关的文档优先放进去，塞不下的直接丢。
实际案例：一个法律文档问答，每次检索可能返回几十个法条。我用BGE-reranker精排后只取top 5，同时把每条法条压缩成"适用场景+核心规定"两句话，Token占用从8000压到2000，效果反而更好——噪声少了，模型更能聚焦。
关键原则：相关性>完整性。给模型50条半相关文档，不如给5条高度相关的。
【面试题】7. 智能体的回复太长、太啰嗦，用户体验不好，怎么优化？
【标准答案】
这是Prompt设计问题，三个优化方向：
第一：明确长度约束——在System Prompt里写："你的回答控制在200字以内，不要展开背景解释，直接给结论和关键理由"。甚至可以指定"分点列出，每点不超过30字"。
第二：格式引导——用Few-shot给范例，让模型模仿简洁风格。比如给一个"问题-简洁回答"的范例，模型就会往这个方向收敛。
第三：后处理截断——模型输出后，如果超过阈值，自动截断并加"...详细内容请联系客服"。这是兜底方案。
深层原因：模型默认倾向"表现欲"，想展示自己知道得多。你要在Prompt里明确："用户要的是快速答案，不是百科全书"。
实际项目里的做法：我在客服Agent的Prompt里加了三条规则——"不说正确的废话"、"不主动补充用户没问的信息"、"回答完直接结束，不要问还有什么可以帮您"。用户满意度明显提升。
【面试题】8. 一个智能体项目从0到1，你会怎么拆解开发阶段？每个阶段的交付物是什么？
【标准答案】
我分四个阶段：
第一阶段：需求澄清（1周）
- 明确业务场景、用户群体、成功指标
- 输出：PRD文档、边界case清单、评估标准
第二阶段：原型验证（2周）
- 用Dify或LangChain快速搭MVP
- 核心功能跑通，非功能需求先不管
- 输出：可演示的原型、初步测试用例
第三阶段：工程化开发（4-6周）
- 重构代码架构，加异常处理、日志、监控
- 接入企业系统（SSO、权限、数据源）
- 输出：生产级代码、部署文档、运维手册
第四阶段：灰度上线与迭代（持续）
- 先给小范围用户试用
- 收集反馈，快速迭代
- 输出：用户反馈报告、迭代计划
关键经验：
- 不要在第一阶段花太多时间争论细节，快速进原型阶段，用实际Demo对齐认知
- 原型阶段不要追求完美，能跑通核心流程就行
- 工程化阶段才是真正的"交付"，前面都是验证
【面试题】9. 如何让智能体支持多轮对话中的"追问"和"指代消解"？比如用户先问"张三的订单状态"，然后追问"他的收货地址呢"？
【标准答案】
多轮对话的核心是上下文理解和状态管理。
指代消解——用户说"他"、"那个"、"之前说的"，要把这些指代词还原成具体实体。做法：
- 维护一个"当前焦点实体"列表，记录最近提到的实体（姓名、订单号、产品名等）
- 用户提问时，检测是否包含指代词
- 如果包含，从焦点实体列表里匹配最相关的，替换到当前问题里
追问处理——用户追问往往省略了主语或背景。做法：
- 把上一轮的完整问题+答案作为上下文传入
- 在Prompt里加一句："如果用户的问题不完整，根据上下文补全后再回答"
实际实现：我一般用一个"对话状态追踪器"模块，每轮对话都更新当前状态（用户意图、涉及实体、待解决问题），新问题来的时候先做状态融合，再给LLM。
工程上可以用LangChain的RunnableWithMessageHistory，或者自己维护一个消息列表，关键是不要只把最后一条用户消息发给模型，要带足够的历史上下文。
【面试题】10. 如果面试官问你"你觉得做Agent项目和传统软件开发有什么本质区别"，你怎么回答？
【标准答案】
这道题考察的是你对Agent本质的理解，我会从四个维度回答：
第一：确定性 vs 概率性 传统软件是确定性系统，输入相同输出必相同。Agent是概率性系统，同样的输入可能得到不同输出。这意味着Agent开发的核心工作不是写逻辑，而是调教模型行为——通过Prompt、Few-shot、约束来"驯服"模型的随机性。
第二：调试方式不同 传统软件调试靠断点、日志、单元测试。Agent调试靠分析"为什么模型做出了这个决定"，需要看Prompt、看输入、看模型输出的logprobs。Agent出了bug，可能不是代码写错了，是Prompt写的不对，或者训练数据有偏差。
第三：迭代方式不同 传统软件改需求=改代码。Agent改需求往往=改Prompt、调参数、加Few-shot示例。迭代成本低，但可控性也低——你不知道改一个Prompt会不会破坏其他case。
第四：评估方式不同 传统软件有单元测试覆盖就够。Agent需要用评估集、人工抽检、用户反馈来持续监控质量。Agent的"正确性"往往没有标准答案，需要定义评估标准。
总结：做Agent要有"驯兽师"思维——你不能精确控制模型的行为，只能通过训练和引导让它大概率做对。这需要一套全新的开发、测试、运维方法论。
生成时间：2026-06-16 00:50题目数量：10道覆盖方向：模型参数调优 / 结构化输出 / 跨会话记忆 / 多Agent冲突处理 / API安全 / RAG召回优化 / 输出优化 / 项目管理 / 多轮对话 / Agent本质认知