后端开发一直是软件里产品行为变成可强制的那一层。
后端管身份、权限、数据存储、业务逻辑、后台任务、API、第三方集成。它是产品规则变成客户真能用的系统的地方。
对 AI 产品来说，这个基线还在。外加的后端工作在 LLM 和使用它的 agent 周围。
一个 AI 产品必须：拉对的客户上下文、保留源权限、决定 agent 能用哪些工具、安全执行那些 tool call、跨模型路由请求、追踪成本、记录发生的事、给团队一个审计系统的方式。
听起来很多，是的。这个工作在产品、LLM、agent 和客户业务系统之间。 叫它 AI 集成层。
换种说法：集成层正在成为绕在 LLM 周围的后端。
AI 集成层的三条路径
- 同步业务上下文
- 治理工具执行
- 模型路由、可观测性、控制
每条路径都是活在模型旁边、不在模型里的运行时表面。
传统职责还在，AI 加了更多
传统 SaaS 后端通常有一套熟悉的职责。当产品加 AI 能力时，这些职责保留。 然后 AI 层引入另一套运行时职责。
传统 app 通常通过界面、表单、按钮、API 调用暴露工作流。用户执行动作，后端校验、写数据、记录结果。
有了 agent，工作流被压缩——agent 读上下文、选动作、调工具、生成响应，全部一步完成。系统必须控制 LLM 能知道什么、agent 能做什么、哪个 provider/model 处理请求、每步怎么记。
集成层作为栈地图
LLM 对公开信息知道很多，因为它在大量语料上预训练。但它不自动知道客户 Salesforce 账户的当前状态、Zendesk 升级、Jira issue、Slack 线程、Confluence 页面、Notion workspace、Linear 项目的最新情况。
企业 AI 产品需要这些数据，因为用户通常在问活的业务情况："为什么这个客户被卡了？" "这个项目变了什么？" "哪个支持政策适用于这个上下文？" "从这个升级应该建什么 issue？"
挑战是数据新鲜度。 客户上下文在 tickets、docs、权限、账户记录里变化。昨天准的 support escalation 在客户经理一条内部评论后就过时了。
用户问的时候，产品已经需要客户系统的当前视图。所以 context retrieval 发生在 prompt 之前。
结果是系统必须接源 app、同步数据、normalize 对象、追踪更新、保留足够源元数据给下游工作流。Merge 把这层描述为可靠的集成、normalize、持续同步基础设施、跨第三方应用的正确权限。
知识库让这变具体，因为文档系统不像干净的文件夹树。集成必须保留足够结构供检索，又把数据简化到 AI 产品能用。约束：页面深度嵌套、交叉链接、文件夹层级会变、客户要全部内容或只选 workspace、provider 限流、同一个层级里的文档带不同权限。
这些约束合起来是个建模问题：集成必须把混乱的源知识变成 AI 产品可用的表示。 这个模型还要适配用它的 workflow。例如 CRM 暴露账户字段、联系字段、商机字段、支持字段作独立对象。销售助理需要这些字段组合成紧凑的账户上下文：续约状态、进行中商机、支持升级、usage 信号、下一步推荐动作。
同步的数据通常需要字段映射、清理、派生字段、自定义业务逻辑、workflow 特定格式化才能变成可用上下文。Context 层把源系统数据变成 workflow-ready context。
Provenance：权限必须跟内容走
企业 AI 产品需要 permission-aware 上下文，因为 AI 系统把源内容变换成新形式。微妙的点是：用户看到的经常是派生的对象，不是原始源。
AI 系统不会让源内容保持原样。它把文档、Slack 消息、支持 ticket、会议记录变成summary、任务、风险信号、决策记录、生成的答案。
Context 路径是源数据到达用户面前的路径。每一步保留原内容的实质。 访问规则需要跟实质一起走。
源是私有时这变得具体：如果一条私有 Slack 消息变成产品里的决策，一个不能访问源消息的用户不应该看到派生的决策。 如果那个决策出现在 summary、时间线、生成答案里，同一规则依然适用。
这意味着产品需要 provenance。 知识库 ACL 接近企业 AI 系统的中心。一个搜索或 agent 系统能拉到正确信息但仍然不可用，如果它返回当前用户不能访问的信息。
Permission-aware retrieval 给 LLM 用户被允许看到的上下文。
连接器、集成、工具访问、工具执行
有了 context，下一个挑战是 action。Context 让 AI 产品回答。Tools 让它行动。
Agent 需要后端控制，因为它们在另一个系统里替用户行动。产品必须知道用户、连接的账户、授予的 scope、可用的工具、外部 app 调用的结果。Merge 把这框定为 MCP-ready 连接器、Tool Packs、per-user 或 per-group auth、DLP 校验、tool-call 日志、审计 trail、企业治理。
- 连接器给产品一个跟外部 app 对话的方式。例如 Jira 连接器暴露搜索 issue、建 ticket、更新 issue、加评论的工具。
- Tool access 定义一个 agent 可用的 action 表面。Support agent 被允许搜 Jira 和建 issue，删除权限和项目设置留在那个 agent 的表面之外。
- Tool execution 是 agent 用其中一个 action 的时刻。那一点系统检查用户、账户、scopes、workspace、参数，然后记录 provider 响应、日志、审计 trail。
- 集成是 tool call 周围完整的生产系统。
举个简单 workflow：客户让 AI agent 从支持升级建 Linear issue。产品需要序列：auth + scope check → 规范化输入 → 执行 API call → 记录响应 → 审计。
Tool Pack 定义一个 agent 的 action 表面。 Support agent 拿 support-safe tools。Revenue-ops agent 拿 CRM write tools。内部员工助理拿 calendar tools。
从用户侧看，这就是产品里一次普通对话。对话背后，后端在检查身份、scopes、tools、policy、execution、日志、审计。
可靠性循环
一旦 agent 用工具在客户系统里执行工作，连接器行为变成产品行为。Merge 关于治理工具执行的文章开篇就是个直接失败模式："有缺陷的连接器会阻止 agent 执行动作，或让它们执行错的动作。"
这种失败出现在三个地方：缺失工具、错误参数、坏数据、限流、部分失败、重试风暴。
要防这些，连接器必须清晰描述每个工具。这从 tool schema 开始。Tool 是连接器暴露给 agent 的一个 action。在框架里，这是 agent 选择的单元。要让选择能工作，每个 tool 需要清晰的名字、有用的描述、必选参数、可选参数、期望数据格式。
对 LLM 来说，schema 是接口契约。 模型用这个契约选动作并构建调用。测试也要反映 agent workflow。Merge 通过在官方 MCP server 和它们的实现上跑代表性 workload，比较 latency、hit rate、success rate。
可靠性循环长这样：schema 准确 → eval 测试 → 真实流量测试 → 监控 → 检测漂移 → 修复重发。
坏连接器 = 坏 action。 失败以产品行为到达用户。
模型选择作 backend 政策
在生产规模，AI 产品也需要模型选择的控制。你不想在便宜模型能搞定的任务上花 premium model 的钱。 你也不想把敏感或复杂 workflow 路由到质量不达标的模型。
不同请求有不同要求：成本、延迟、质量、uptime、客户 tier、治理。Support ticket summary、监管合规分析、高量后台分类器不应该总是走同一条 model 路径。
控制面的想法是把模型选择移进 policy。 请求通过 policy 路由到 provider/model 选择。Merge Gateway 的 policy 层把模型选择移进 policy 层。Policy 根据目标路由请求：最小成本、最大 uptime、平衡成本和质量。
LLM 路由也是活跃的系统研究领域。RouteLLM 这类 paper 研究怎么在便宜和强模型间路由同时保质量。生产版这想法需要 policies、日志、fallback 行为、成本可见性、可审计性。
模型选择变成 backend policy。
AI 产品周围正在成形的后端形状
AI 产品周围的集成层走三条路径：context、actions、models。 这些路径在 LLM 和使用它的 agent 旁边。它们决定哪些数据进 prompt、agent 能做哪些动作、哪个 provider/model 处理请求、系统怎么记结果。
这是 AI 产品周围正在成形的后端形状。 传统后端职责还在：auth、数据库、API、权限、queue、job、业务逻辑。AI 加了一层后端表面给 context、actions、models、可观测性、治理、成本、可审计性。
对后端工程师来说，这是要理解的架构转变：企业 AI 产品需要一个运行时层，控制数据访问、工具使用、模型选择、成本、日志、可审计性——围绕每个请求。
🦞 "AI integration layer" 这个词比"AI infra"准确得多——它不是基础设施，是新的后端形态。Permission 必须跟 content 一起流动这一条，单独就能决定企业级 AI 产品能不能过安全审计。