最近很多后端面试会出现 AI 应用、智能体、模型接口这类项目。候选人容易把它讲成“调用大模型生成答案”。面试官真正会追的是：上下文怎么组织？模型调用失败怎么办？工具参数错了怎么办？回答质量怎么控制？成本和响应时间怎么压？
AI 后端的核心不是模型名字，而是把不稳定的模型能力接进可控的业务系统。
先讲业务链路，不要先讲模型
一个好的开场可以是：用户提出问题后，系统先做权限和场景判断，再检索相关资料或准备上下文，然后调用模型生成结构化结果，最后做格式校验、敏感内容检查和日志记录。如果需要工具调用，还要限制模型能调用哪些工具，以及每个工具的参数格式。
这样讲能让面试官听出你把模型当作系统组件，而不是把整个系统交给模型自由发挥。
上下文管理要有取舍
大模型输入长度有限，而且输入越长，成本和延迟越高。面试里可以讲上下文怎么筛选：只放当前任务相关信息，历史对话做摘要，长文档先检索再截取关键片段，重复或低价值内容不放进模型输入。
如果业务要求准确性，还要说明资料不足时怎么办。更稳的设计是让模型在证据不足时拒答或转人工，而不是强行生成。面试官通常会更认可这种边界感。
工具调用要防失控
智能体项目最容易被追问工具调用。工具不是越多越好，权限也不能完全交给模型。回答里可以讲：工具按场景白名单开放；调用前校验参数；调用后校验结果；连续失败要停止；关键写操作需要二次确认或业务规则兜底。
比如模型想查询订单，可以只允许读取当前用户自己的订单；模型想创建任务，必须参数完整且通过权限检查；外部系统返回异常时，不能让模型编造成功结果。这些细节比说“用了某个框架”更有价值。
成本和延迟是后端职责
AI 应用上线后，模型调用费用和响应时间都会变成后端问题。可以讲缓存高频问题、简单问题走规则或小模型、复杂任务异步处理、流式返回降低等待感、限制最大输入长度、记录每次调用的耗时和文本消耗。
还要讲降级：模型服务不可用时，是否返回固定答案、转人工、只展示检索结果，还是提示稍后重试。不同业务容忍度不同，不能一概而论。
一段项目表达
可以这样说：我负责的是 AI 问答后端链路，不只是接模型接口。用户问题进来后先做权限和场景识别，再检索相关资料并压缩上下文；模型输出要求固定格式，后端会做字段校验和敏感内容检查。工具调用采用白名单，参数必须经过后端校验，失败时记录链路日志并返回可解释错误。上线后主要看回答可用率、拒答率、平均响应时间、模型调用成本、工具失败率和用户追问率。
这类回答能体现 AI 后端岗位真正需要的能力：在模型能力之外，建立稳定、可控、可观察的工程系统。
AI 后端要讲可控性
AI 后端项目的重点不是“我调用了模型”，而是模型行为如何被系统约束。工具调用、上下文、成本、延迟、失败兜底，都是后端需要负责的部分。
上下文拼接：风险是太长、混入无关信息，后端设计是摘要、裁剪、权限过滤，验证方式是看 token 和命中资料。工具调用：风险是参数错或越权，后端设计是schema 校验和权限校验，验证方式是记录工具入参出参。
- 模型失败：风险是超时或返回不可用，后端设计是重试、降级、人工兜底，验证方式是失败率和耗时。
- 成本控制：风险是单次对话成本过高，后端设计是缓存、模型分层、限额，验证方式是按用户和功能统计成本。
这类文章可以更强调工程边界：模型是能力源，后端系统负责把能力变成可控、可观测、可恢复的产品功能。