Blackbox
面向企业应用提供模型推理 API、模型路由与专用部署。
Blackbox 当前面向企业应用提供模型推理服务，通过统一聊天接口配置模型、路由、流式输出和工具调用，并提供专用部署路线。
Blackbox 能做什么
现行官网重点已转为企业推理平台。接入时应以当前 API 文档和模型目录为准，不把早期编程助手或 GPU IDE 的界面入口当作现行推理服务操作说明。
通过聊天接口请求模型
请求带 Authorization、model 和 messages，将系统、用户、助手及工具消息组成会话。返回包含生成内容、停止原因和用量，应用应明确处理成功与中断。
按需要启用流式输出
stream 可通过 Server-Sent Events 分段返回结果。适合需要逐步显示文本的应用，但客户端仍需处理连接中断和最终结束状态。
传入工具定义并接收调用
tools 使用函数名称、描述和 JSON Schema 声明参数，tool_choice 控制是否允许或要求调用。模型返回 tool_calls 后，仍由接入应用检查参数并执行相应功能。
约束格式并查看路由与用量
response_format 用于结构化输出，provider 与 models 可参与路由配置；响应提供实际模型、提供方及 token 用量。接入时记录实际返回，而不是只假设请求模型就是最终执行路径。
- 核心用途
- 模型推理、流式与工具调用
- 可完成的工作
- 应用对话、结构提取、工具助手
- 如何开始
- 获取 API key 并发送聊天请求
- 使用条件
- 模型能力、路由和加密路线需分别确认
如何使用 Blackbox
- 确认当前模型和接入条件
从当前模型目录及 API 文档确定目标模型、端点和账号条件；不要照搬旧编程助手教程中的入口。
- 在后端配置 key 和消息
用 Bearer API key 设置请求头，提供 model 与 messages。密钥保存在后端配置，不写入公开页面或客户端源码。
- 发送最小请求并检查响应
先关闭流式发一个小请求，检查 choices、finish_reason、model、provider 与 usage；确认错误处理后再增加功能。
- 逐项加入格式、流式或工具
按应用需要加入 response_format、stream 或 tools，每增加一项都检查返回结构与失败路径，再用于实际业务。
为应用加入模型对话
适合：应用开发者
- 准备输入
- 后端服务、API key 与消息结构
- 操作方法
- 编辑建议：先发送单轮小请求，验证响应，再逐步加入会话和流式处理。
- 预期交付物
- 可展示的模型答复
- 人工检查
- 检查停止原因、错误和用量是否正确处理。
把材料转为结构化字段
适合：数据应用开发者
- 准备输入
- 有限文本与预期字段格式
- 操作方法
- 编辑建议：配置输出结构并在程序中校验，缺字段时交回人工或重试策略。
- 预期交付物
- 可被程序读取的数据草稿
- 人工检查
- 核对必填字段、类型与原文一致性。
连接一个受控业务工具
适合：智能体开发者
- 准备输入
- 工具定义、参数结构与执行权限
- 操作方法
- 编辑建议：先用只读工具测试 tool_calls，再为写入增加独立确认。
- 预期交付物
- 模型提出的工具调用与结果
- 人工检查
- 检查函数名、参数、权限及工具返回关联。
界面与参考图片
开始前需要了解
统一接口不代表所有模型能力相同
文档提供多模态、工具、搜索引用和推理等字段，具体模型和提供方支持仍需确认，不能把接口字段当作所有模型通用承诺。
工具调用不会自动替应用执行业务
模型返回函数名和参数；接入方仍需校验、执行并回传结果，特别是写入或支付等动作应由应用控制权限。
加密与部署承诺需对应具体路线
官网宣传企业加密推理与专用部署，但普通聊天 API 示例本身不能证明已采用相同加密或专属环境。处理敏感数据前应核对所选方案和专门配置。
模型能力、路由和加密路线需分别确认
账号权限、费用与可用功能请以官方入口的当前说明为准。重要结果应先检查，再用于实际工作。
常见问题
现在的 Blackbox 仍以旧编程助手界面为主吗？
当前主站重点是企业推理平台与部署，接入指南应以现行模型目录和 API 文档为准。
支持像聊天接口一样传消息吗？
支持 model 与 messages 请求结构，返回 choices、停止原因和 token 用量；需要有效 API key。
开启 tools 后会自动运行我的函数吗？
不会仅靠声明就完成应用侧执行。接口返回工具调用，接入应用需验证参数并调用实际功能。
普通接口示例是否自动启用了端到端加密路线？
不能据此推断。当前文档另有加密模型说明，需按相应服务和配置确认，不能把官网总宣传直接套到每次调用。
