应用构建
应用构建关注如何把模型能力变成可验证、可维护、可治理的系统。模型 API 只是入口；真实应用还需要消息结构、输出校验、工具执行、上下文管理、检索、权限和评测。
快速开始¶
一个最小应用可以按下面的顺序搭建：
模型 API
-> Messages 与输出格式
-> Function Calling 或其他外部能力
-> Prompt / Context 组装
-> RAG 或 Agent 循环
-> 任务评测、安全控制和观测
先用固定输入验证 应用基础，再把模型输出交给确定性的程序校验。只有当单步调用无法满足任务时，才加入检索、工具或 Agent 循环；每增加一种能力，都要增加相应的失败处理、权限边界和评测样例。
构建基础¶
应用基础包括 模型 API、Messages、Structured Output、Function Calling 和 API 供应商配置。消息应保留角色、来源和版本；结构化输出必须在服务端解析和校验；工具调用必须由程序检查参数、权限和副作用，不能直接执行模型生成的文本。
构建范式¶
提示词工程 解决任务描述、示例和输出约束的问题；上下文工程 解决如何选择、压缩和组织模型真正需要的信息；约束工程 则负责状态、重试、权限、终止条件和观测。三者分别作用于输入表达、上下文供给和运行环境，不能互相替代。
RAG 与 Agent¶
当模型需要外部知识时，使用 检索增强生成，并验证检索结果是否真正支持答案。RAG 的数据版本、分块、Embedding、召回、重排和引用链路都应可追踪。
当任务需要动态选择多个动作时，再进入 智能体。Agent 需要工具 schema、执行循环、预算、权限和终止条件；Harness 必须在模型决策和外部副作用之间设置确定性的校验层。
评测与发布¶
上线前用代表性任务集评估正确率、格式解析率、任务成功率、引用正确性、工具选择、延迟、token 成本和失败恢复。正常样例之外，必须覆盖空输入、超长输入、工具失败、检索无结果、提示词注入和权限不足等路径。
发布时固定模型、提示词、工具 schema、检索索引、数据版本和服务配置。保留请求 ID、版本和指标之间的关联，但对提示词、用户数据和工具结果做最小化记录与脱敏。应用安全问题集中见 安全问题。
案例：知识库问答¶
用户提问后，系统先识别任务类型，再从固定版本的知识库召回候选片段，重排后将带来源的上下文交给模型。模型输出必须包含答案和引用，服务端验证引用存在且覆盖论断；无相关结果时返回“未找到依据”，而不是让模型自行补全。