AI 产品为什么又需要 BFF：前端别直接拼模型上下文，权限和路由也别四处分散
这两年我越来越觉得，AI 产品里的 BFF 又变得重要了。但它重要，不是因为我们突然怀念传统前后端分层，而是因为很多团队在 AI 功能早期图快，把会话拼装、模型选择、权限裁剪和供应商切换都散落在不同地方，后面一扩展就开始失控。
最常见的失控方式是这样的：
- 前端自己拼一部分上下文
- 工作流层再补一部分业务状态
- 模型调用层偷偷加一部分默认参数
- 权限和脱敏逻辑在好几个地方各做一遍
最后谁都能改一点，但谁也说不清一条请求到底带着什么上下文去找模型。
我现在更愿意让 BFF 先做“收口”而不是“多做事”
AI 场景里的 BFF 最重要的价值，不是替业务写更多逻辑，而是先把几件一定会分散的东西收拢起来：
- 前端会话状态
- 用户身份与权限
- 模型调用所需的统一上下文
- 供应商路由和超时策略
- 基础脱敏和审计字段
这层如果不明确，前端、工作流和模型层很快都会开始各自补洞。
前端最不该直接做的，是拼最终模型输入
我现在特别反对前端直接把“最终送给模型的上下文”拼好。因为前端可以负责交互状态，但它不应该承担这几类决定：
- 哪些上下文字段属于当前用户可见范围
- 哪些内部元数据应该进模型，哪些只应该进审计日志
- 当前场景到底该走哪个模型和哪个模板版本
这些判断一旦分散在前端里，后面做权限收缩、日志对齐和 Prompt 版本切换会很痛苦。
我更喜欢前端只提交一个相对干净的请求：
type ChatRequest = {
sessionId: string;
userInput: string;
attachmentIds: string[];
scene: 'chat' | 'review' | 'rewrite';
};
然后由 BFF 在服务端补齐真正要送往工作流和模型层的上下文。
模型路由放在 BFF，比散在业务里稳得多
我越来越不想让每个业务服务自己决定：
- 用哪个供应商
- 超时多长
- 失败后切不切备用模型
- 哪些场景该走便宜模型，哪些该走强模型
这些决策如果分散在不同服务里，后面成本控制和问题排查都会非常碎。
放在 BFF 的好处是，你至少可以统一处理：
- 路由规则
- 成本配额
- 超时和重试
- 降级策略
这样当某个供应商波动时，你不需要满系统去找谁偷偷写了自己的切换逻辑。
权限裁剪和脱敏也更适合在这层先做
AI 请求里最危险的一件事，是把不该带给模型的内容带进去了。前端当然可以做一部分隐藏，但真正可靠的权限裁剪，我更愿意放在 BFF 做。原因很简单：
- BFF 离用户身份最近
- 也最接近最终模型输入
- 可以同时做审计记录
如果这件事前端做一半、模型层再补一半，最后最容易出现的就是“大家都以为别人已经处理过了”。
BFF 不该变成第二个工作流引擎
当然，我也不赞成把所有业务流程都塞进 BFF。它不该做的是：
- 管整条任务编排
- 持有复杂步骤状态
- 承担业务真相
这些更适合在工作流层或业务服务层做。BFF 更适合扮演一个很清楚的角色：把来自前端的请求收干净，再以一致的方式交给后面的编排层。
我对 AI 场景里 BFF 的判断
AI 产品里的 BFF，价值在于收束复杂度，而不是重复传统后端职责。只要系统开始同时面对前端会话、模型路由、权限裁剪和多供应商切换，就需要一层来统一这些会四处散开的东西。
它最好的状态不是“什么都懂”，而是“把本来容易分散的边界收拢成一处”。这件事一旦做好，前端会轻很多，工作流也会清楚很多，排查问题时更不会像在不同层里拼一张已经碎掉的图。