核心要点
最直接：调用云端 API（OpenAI、通义、DeepSeek 等）或本地/私有部署推理（vLLM、Ollama），由网络/进程边界拿到模型输出
工程化：用 SDK 与编排框架（LangChain、LlamaIndex、Spring AI）封装 Prompt、记忆、检索与链路，减少胶水代码
让模型"动手"：Function Calling / 工具调用让模型按需回调你定义的函数；MCP 作为标准协议让模型以统一方式接入外部工具与数据源
让模型"知情"与"对齐业务"：RAG 接私有知识库提供事实依据，结构化输出（JSON / Schema 约束）把回答对接到下游业务系统
标准回答
集成的本质集成就是让程序把输入交给模型、再把模型输出可靠地用到业务里。按由浅入深可分为几类方式。一、直接调用 API 或本地推理最简单的是 HTTP 调用云厂商的模型 API（OpenAI、通义千问、DeepSeek 等），传入 Prompt 拿回文本。对数据合规或成本敏感的场景，可用vLLM、Ollama等本地/私有化推理服务自托管模型，接口形态类似但部署与运维在自己手里。二、用 SDK 与编排框架直接拼字符串很快会失控，于是用LangChain、LlamaIndex、Spring AI 263等框架统一管理 Prompt 模板、对话记忆、检索、链式/Agent 编排，把重复的胶水逻辑沉淀下来。 三、Function Calling 与 MCP341
Function Calling / 工具调用让模型在需要时输出"调用某函数及参数"的意图，由你的程序执行真实逻辑（查库、下单、算数）再把结果回喂模型。MCP（Model Context Protocol） 则把"模型如何接工具与数据源"标准化，一次实现的工具可被不同模型/客户端复用，降低重复对接成本。四、RAG 接知识与结构化输出
RAG在生成前检索私有知识，把相关片段拼进 Prompt，让回答有事实依据、可溯源。结构化输出用 JSON Schema 等约束模型只产出固定格式，便于下游系统直接解析入库，避免解析自由文本。工程要点无论哪种方式都要处理：同步还是 流式返回（流式可先吐字降感知延迟）、超时与重试、并发与限流、成本控制与降级（高峰或故障切更小模型或缓存）、以及全链路可观测（记录 Prompt、token、延迟、错误以便排障与优化）。
常见误区
⚠️ 常见踩坑
把集成简单理解为"调个 API 拿字符串"，忽视工程化外围：不做超时/重试和限流，模型抖动就拖垮整个请求链路；用正则硬解自由文本而不用结构化输出，格式一变就崩；不做成本与降级预案，高峰直接打爆配额；缺少日志与可观测，线上出问题无法定位。集成的难点不在调通，而在稳定、可控、可观测。
追问
追问 1：什么时候该选本地/私有部署，而不是直接用云 API？
当数据合规与隐私要求高（如不能把数据出域）、需要稳定可控的长期成本、对延迟和可用性要自主掌控，或要在专有数据上做深度定制时，倾向用 vLLM、Ollama 等自托管推理。代价是要自己承担 GPU 资源、部署运维和模型升级。反之，若追求快速上线、模型能力领先、流量波动大且不愿运维，云 API 更划算。常见做法是两者混合：核心敏感链路私有化，长尾或高能力需求走云 API。
追问 2：Function Calling 和 MCP 有什么区别与联系？
Function Calling 是模型层面的能力：模型能根据上下文决定调用哪个函数、给出参数，但函数的注册、执行、对接还是各自实现，换个应用要重写。MCP 是更上层的标准协议：它规定了工具与数据源如何被描述、发现和调用，让一个 MCP server 暴露的工具能被不同模型与客户端复用。两者互补——模型用 Function Calling 的能力发起调用，MCP 解决"工具生态如何标准化复用"的工程问题。
追问 3：流式返回（streaming）在集成中解决什么问题，要注意什么？
流式让模型边生成边返回 token，用户能立刻看到首字，大幅降低长回答的感知延迟，体验更接近"打字"。注意点：要正确处理分块协议（如 SSE）和半截 JSON 在结构化场景下的拼接；错误可能发生在流中途，需要能中断与回收；做可观测时要在流结束后再统计完整 token 与延迟；并发流会占用更多连接资源，要结合限流与超时一起设计。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习