核心要点
用 SDK 和框架降低胶水代码：LangChain、LlamaIndex、Spring AI 可封装 Prompt、对话、检索、工具调用和链路编排。
用工具调用让模型连接业务动作：Function Calling 负责结构化调用意图，MCP 负责标准化接入外部工具和数据源。
用 RAG 与结构化输出进入生产系统：RAG 补私有知识，JSON Schema 等结构化输出让下游系统能稳定解析。
简要回答
程序与大模型集成不只是“调一个 API”。候选人可以按五层回答：模型服务接入、SDK/框架封装、工具调用/MCP、RAG 接知识、结构化输出对接业务；最后补上流式、超时重试、限流、降级、成本和可观测这些生产必备能力。
标准回答
一、先给出结论和背景
- 集成的本质：集成就是让程序把输入交给模型、再把模型输出可靠地用到业务里。按由浅入深可分为几类方式。
- 直接调用 API 或本地推理：最简单的是 HTTP 调用云厂商的模型 API（OpenAI、通义千问、DeepSeek 等），传入 Prompt 拿回文本。对数据合规或成本敏感的场景，可用 vLLM、Ollama 等本地/私有化推理服务自托管模型，接口形态类似但部署与运维在自己手里。
二、拆开关键步骤和判断点
- 用 SDK 与编排框架：直接拼字符串很快会失控，于是用 LangChain、LlamaIndex、Spring AI 等框架统一管理 Prompt 模板、对话记忆、检索、链式/Agent 编排，把重复的胶水逻辑沉淀下来。
- Function Calling / 工具调用：让模型在需要时输出“调用某函数及参数”的意图，由你的程序执行真实逻辑（查库、下单、算数）再把结果回喂模型。**MCP（Model Context Protocol）**则把“模型如何接工具与数据源”标准化，一次实现的工具可被不同模型/客户端复用，降低重复对接成本。
三、补上落地边界和取舍
- RAG：在生成前检索私有知识，把相关片段拼进 Prompt，让回答有事实依据、可溯源。结构化输出用 JSON Schema 等约束模型只产出固定格式，便于下游系统直接解析入库，避免解析自由文本。
- 工程要点：无论哪种方式都要处理：同步还是流式返回（流式可先吐字降感知延迟）、超时与重试、并发与限流、成本控制与降级（高峰或故障切更小模型或缓存）、以及全链路可观测（记录 Prompt、token、延迟、错误以便排障与优化）。
常见误区
⚠️ 常见踩坑
误区一：把集成理解成“调个 API 拿字符串”。真正上线时，超时、重试、限流、流式中断、日志追踪和成本控制都会影响稳定性；只会调通 demo，不等于能支撑业务。
误区二：用正则硬解析自由文本。模型输出稍微换个说法，下游解析就可能崩；需要结构化输出、schema 校验和失败重试，关键链路还要保留人工兜底或降级方案。
追问
追问 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 与延迟；并发流会占用更多连接资源，要结合限流与超时一起设计。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习