AI推理指南

模型交互与 API

应用与模型之间的契约：请求如何组织、输出如何被约束成机器可用的形式、模型如何调用工具，以及让整体保持可移植的那些 API 接口。

一个请求的组成

消息与角色：system 消息设定长期有效的指令，user 消息承载输入，assistant 消息承载模型之前的回合。模型看到的是提交的整个列表，而不只是最新那个问题。
模板与预填：应用通过带动态插槽的模板拼装提示词；预先写好 assistant 回合的开头，可以引导格式和语气。
上下文管理：窗口是有限的，因此长对话会被截断或摘要。你丢掉的内容会改变答案，所以这条策略必须是有意为之的。
对服务端的影响：提示词结构是一项性能决策。把稳定内容（系统提示词、示例）放在前面、把易变内容放在末尾，正是让 prefix caching 生效的关键；参见服务优化。

提示词技巧本身（zero-shot、few-shot 示例、思维链、角色设定）以模式目录的形式收录在模式中。

推理参数

每个请求都带有一些旋钮，它们会重塑输出分布和输出契约：

采样

temperature、top_p、top_k，以及可选的 seed。低 temperature 适合抽取、分类和代码；较高的值适合发散构思和创意写作。

长度与停止

max_tokens 限制生成量和花费；stop 序列让生成提前结束。两者改变的不只是成本，还有结果本身。

塑形与内省

repetition、presence、frequency 惩罚；用 logit_bias 提升或禁止特定 token；用 logprobs 获取置信度信号；用 n 或 best_of 获取多个候选。

参数的支持情况和确切语义因服务商和运行时而异。这些设置与可复现性之间的关系，在非确定性中有深入讨论。

结构化输出

流水线需要的是 JSON 而不是散文。有两类技术可以做到：

校验并重试

按 schema 解析响应，失败时重新提问（即 Instructor 模式）。它适用于任何 API，包括托管服务，但每次失败的尝试都要付出延迟和 token 成本。

受约束解码

在每一步屏蔽非法 token，使得只可能产出符合 schema 的输出（Outlines、XGrammar、Guidance；已内置于 vLLM 和 SGLang，托管服务商则以 JSON schema 模式对外提供）。它保证结构，但语法合法的答案在语义上仍可能是错的。

不带 schema 的纯“JSON 模式”只承诺产出可解析的 JSON，而不是你要的那份 JSON；更好的做法是强制 schema，并在应用层再校验具体取值。

function calling 与 MCP

function calling

你描述可用的工具（名称、用途、参数 schema）；模型输出一次结构化调用而不是散文；你的代码执行它，并把结果作为一条新消息返回；模型再带着真实数据继续。它本质上仍是产出受约束格式的下一个 token 预测，因此 schema 质量和工具描述决定了可靠性。把它包进“规划-执行-评估”的循环，就是智能体底层的机制；参见智能体模式。开放模型对它的支持程度和质量参差不齐，请在你的运行时上验证。

Model Context Protocol

MCP 规范了助手访问外部系统的方式：宿主应用运行 MCP 客户端，连接到一个个 MCP 服务器，每个服务器通过统一协议在本地或远程暴露工具、数据资源和提示词。这样就不必为每个应用、每项服务各写一套定制集成，协议的任一侧都只需写一次。一个宿主可以同时挂接多个服务器。

兼容的 API 接口

自托管引擎和网关会模仿主流服务商的 HTTP API，因此现有 SDK 只要改一下 base URL 就能工作。正是这一点让应用可以在托管后端和自托管后端之间保持可移植。

兼容 OpenAI

提供 chat completions 和模型列表端点；通过 stream 标志启用流式输出
事实标准：vLLM、SGLang 以及大多数网关都提供它
覆盖 base URL，把官方 SDK 指向你的端点；自托管服务器的 API key 往往只是一个占位符

兼容 Anthropic

Messages 风格的端点；通过 x-api-key 加上 anthropic-version 请求头进行鉴权
系统提示词是顶层字段，工具调用以带类型的内容块形式返回
高级能力（prompt caching、extended thinking、图像和文档输入）在开源后端上只被部分复现

兼容性是一个程度问题，而不是一种保证：参数覆盖范围和功能支持因后端而异，因此在更换端点之前，请实测你所依赖的那些具体功能。

AI Inference Guide

AI推理指南

一个请求的组成

消息与角色：system 消息设定长期有效的指令，user 消息承载输入，assistant 消息承载模型之前的回合。模型看到的是提交的整个列表，而不只是最新那个问题。

模板与预填：应用通过带动态插槽的模板拼装提示词；预先写好 assistant 回合的开头，可以引导格式和语气。

上下文管理：窗口是有限的，因此长对话会被截断或摘要。你丢掉的内容会改变答案，所以这条策略必须是有意为之的。

对服务端的影响：提示词结构是一项性能决策。把稳定内容（系统提示词、示例）放在前面、把易变内容放在末尾，正是让 prefix caching 生效的关键；参见服务优化。

提示词技巧本身（zero-shot、few-shot 示例、思维链、角色设定）以模式目录的形式收录在模式中。

推理参数

每个请求都带有一些旋钮，它们会重塑输出分布和输出契约：

采样

temperature、top_p、top_k，以及可选的 seed。低 temperature 适合抽取、分类和代码；较高的值适合发散构思和创意写作。

长度与停止

max_tokens 限制生成量和花费；stop 序列让生成提前结束。两者改变的不只是成本，还有结果本身。

塑形与内省

repetition、presence、frequency 惩罚；用 logit_bias 提升或禁止特定 token；用 logprobs 获取置信度信号；用 n 或 best_of 获取多个候选。

参数的支持情况和确切语义因服务商和运行时而异。这些设置与可复现性之间的关系，在非确定性中有深入讨论。

结构化输出

流水线需要的是 JSON 而不是散文。有两类技术可以做到：

校验并重试

按 schema 解析响应，失败时重新提问（即 Instructor 模式）。它适用于任何 API，包括托管服务，但每次失败的尝试都要付出延迟和 token 成本。

受约束解码

不带 schema 的纯“JSON 模式”只承诺产出可解析的 JSON，而不是你要的那份 JSON；更好的做法是强制 schema，并在应用层再校验具体取值。

function calling 与 MCP

function calling

Model Context Protocol

兼容的 API 接口

兼容 OpenAI

提供 chat completions 和模型列表端点；通过 stream 标志启用流式输出
事实标准：vLLM、SGLang 以及大多数网关都提供它
覆盖 base URL，把官方 SDK 指向你的端点；自托管服务器的 API key 往往只是一个占位符

兼容 Anthropic

Messages 风格的端点；通过 x-api-key 加上 anthropic-version 请求头进行鉴权
系统提示词是顶层字段，工具调用以带类型的内容块形式返回
高级能力（prompt caching、extended thinking、图像和文档输入）在开源后端上只被部分复现

兼容性是一个程度问题，而不是一种保证：参数覆盖范围和功能支持因后端而异，因此在更换端点之前，请实测你所依赖的那些具体功能。