03 · 如何使用和管理 AI 模型？ - Model Engineering

所属知识库：Agent 全栈技术地图
所属领域：01 · AI
所属章节：03 · 如何使用和管理 AI 模型？ - Model Engineering
文档类型：章节导论
版本：v1.0
更新日期：2026 年 10 月 27 日
核心问题：AI 模型如何从一个具备计算能力的模型，成为可以被软件和 Agent 系统稳定调用的服务？开发者如何管理模型接口、输入、上下文、输出、工具调用、模型选择、部署与运行成本？

这一章承接 M1—M8 的模型原理研究，重点从“模型如何工作”转向“如何在实际软件和 Agent 系统中使用模型”。导论将建立 Model Engineering 的定义、技术架构、核心问题、工程流程，以及 E1—E8 八篇研究之间的关系。

一、本章研究什么？

在前面的「02 · AI 模型是如何构建和工作的？ - Model Architecture」中，我们已经研究了 AI 模型的基本原理，包括模型结构、神经网络、Transformer、大语言模型、多模态模型、模型训练、推理和评估。

这些研究帮助我们理解：AI 模型是什么，它的能力从哪里来，以及它如何通过计算生成输出。

但在实际应用中，理解模型原理并不等于能够有效使用模型。

例如，我们希望开发一个能够自动完成研究报告的 Agent System。系统需要调用语言模型理解研究任务、分析资料、生成结构化研究结果，并根据需要使用搜索、文件处理和其他外部工具。

这时，开发者需要解决一系列工程问题：

• 如何连接并调用模型？
• 如何组织输入信息，让模型正确理解任务？
• 如何处理模型的上下文长度限制？
• 如何确保模型输出符合程序要求？
• 如何让模型提出工具调用请求，并由系统执行？
• 如何根据任务选择不同模型？
• 如何在本地或服务器上部署模型？
• 如何控制调用成本、响应延迟和资源消耗？

这些问题属于 Model Engineering（模型工程） 的研究范围。

1.1 Model Engineering 的定义

在本知识库中，Model Engineering 指围绕 AI 模型的实际应用，设计和实现模型接入、输入组织、输出控制、工具交互、模型选择、部署运行及性能优化的一系列工程方法。

需要说明的是，Model Engineering 并不存在完全统一的行业定义。它在不同语境中可能涵盖模型训练、MLOps、模型服务等更广泛的内容。

本章采用相对明确的研究边界：重点研究模型已经具备一定能力之后，开发者如何将这些能力可靠地集成到应用系统中。

可以将这一过程概括为：

AI Model
已经训练完成的模型
        │
        ▼
Model Engineering
模型接入与应用工程
        │
        ▼
Model Service
可调用的模型能力
        │
        ▼
Application / Agent / Agent System
实际应用与任务执行

其中，Model Service 可以由外部服务商提供，也可以由开发者自行部署。

1.2 本章的核心研究目标

本章希望建立三个层面的认识。

第一，理解模型应用的完整技术链路。 明确从应用发起请求，到模型接收输入、执行推理、返回结果，再到应用处理输出的全过程。

第二，掌握模型使用过程中的主要工程技术。 包括 API、Prompt、Context Window、Structured Outputs、Function Calling、Model Routing、Model Deployment 和 Inference Optimization。

第三，建立模型服务的工程设计能力。 能够根据具体任务，合理组织模型调用、控制输出、选择部署方案，并在质量、成本、延迟和可靠性之间进行权衡。

本章最终要回答的是：

如何将 AI 模型转化为可集成、可控制、可维护、可优化的应用能力？

二、为什么需要 Model Engineering？

2.1 模型能力与应用能力之间存在差异

一个模型能够回答问题，并不意味着它可以直接满足软件系统的要求。

例如，用户向模型提出：

请分析这家企业的基本情况，并输出企业名称、所属行业、主要业务、竞争优势和潜在风险。

模型可能生成一篇自然语言分析。

但应用系统可能需要的是：

{
  "company_name": "Example Company",
  "industry": "Software",
  "main_business": [],
  "competitive_advantages": [],
  "potential_risks": []
}

此时，模型生成的自然语言虽然可能具有价值，却不一定能够被程序直接使用。

开发者需要通过模型输入设计、结构化输出约束和结果验证，将模型能力转换为符合应用要求的结果。

2.2 模型调用具有不确定性

大语言模型通常根据输入上下文生成概率性输出。

即使任务相同，输出也可能受到以下因素影响：

• 输入表达；
• 上下文内容；
• 模型版本；
• 解码参数；
• 模型自身的能力边界。

因此，应用系统不能简单假设模型每次都会生成完全正确、格式一致的结果。

模型工程需要通过约束、验证、错误处理和测试，提高模型能力在实际应用中的可用性。

2.3 模型存在资源与运行限制

模型调用需要消耗计算资源。

实际使用中可能受到：

• 上下文窗口长度；
• 最大输出长度；
• 请求速率限制；
• 推理延迟；
• 并发能力；
• GPU 显存；
• API 调用费用。

等条件约束。

因此，开发者需要根据任务要求设计合理的运行方案。

2.4 不同任务需要不同的模型使用方式

例如：

任务	主要工程要求
简单文本分类	低延迟、结构化输出
长文档总结	上下文管理、信息完整性
复杂研究分析	高质量输入、推理能力、结果验证
批量信息提取	高吞吐量、低成本
Agent 工具选择	Function Calling、参数校验
本地知识处理	私有部署、数据安全
多模态内容分析	多模态输入、模型兼容性

因此，Model Engineering 并不是为所有任务使用同一种模型配置，而是根据任务需求组织模型能力。

三、Model Engineering 在 AI 技术体系中的位置

为了理解本章的定位，需要将模型工程放回完整的 AI 技术体系中。

3.1 从模型原理到应用工程

AI Fundamentals
人工智能基础
        │
        ▼
Model Architecture
模型架构与工作原理
        │
        ▼
Model Engineering
模型应用与工程管理
        │
        ▼
Knowledge & Retrieval
外部知识与检索
        │
        ▼
Agent
自主任务执行
        │
        ▼
Agent System
系统化运行与协作
        │
        ▼
Agent Platform
平台化管理与产品能力

这张图表示知识库的学习路径，而不是严格的软件依赖顺序。

例如，普通应用可以直接调用模型，而不需要构建 Agent；Agent 也可以在不使用外部知识库的情况下执行某些任务。

3.2 Model Architecture 与 Model Engineering

Model Architecture 主要研究模型内部如何工作。

例如：

• Transformer 如何计算 Attention；
• 模型如何通过训练更新参数；
• 自回归模型如何生成 Token；
• 模型能力如何评估。

Model Engineering 则研究如何使用这些模型。

例如：

• 如何通过 API 发起推理请求；
• 如何构建 Prompt；
• 如何管理 Context Window；
• 如何处理模型返回结果；
• 如何部署和优化模型服务。

两者的关系可以概括为：

Model Architecture 解释模型的能力机制，Model Engineering 研究这些能力的应用方式。

3.3 Model Engineering 与 Agent

Model Engineering 主要解决模型能力的接入与使用问题。

Agent 则在模型能力的基础上，增加任务目标、执行循环、工具使用、状态管理等机制。

例如：

Agent
  │
  ▼
Agent Runtime
  │
  ▼
Model Interface
  │
  ▼
Model Service
  │
  ▼
AI Model

Agent Runtime 可以根据任务状态构建输入、调用模型、处理输出，并决定下一步行动。

因此，Model Engineering 为 Agent 提供重要的模型调用基础。

3.4 Model Engineering 与 Agent System

当多个 Agent 共同执行任务时，模型工程问题可能进一步扩大。

例如：

• 多个 Agent 同时调用模型；
• 不同 Agent 使用不同模型；
• 需要统一记录 Token 消耗；
• 需要控制调用预算；
• 需要处理模型服务故障；
• 需要在不同模型服务之间切换。

这些需求会逐渐演变为 Agent System 中的 Model Services 和 Resource Management 等系统级能力。

本章主要研究这些能力的模型工程基础。

四、模型应用的完整技术架构是什么？

从工程角度看，一次模型调用通常涉及多个层次。

4.1 模型应用的基本架构

┌─────────────────────────────────────┐
│            Application              │
│         应用程序 / Agent             │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│         Model Integration           │
│             模型接入层               │
│                                     │
│  API Client / Authentication        │
│  Request / Response Handling        │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│        Model Input Management       │
│             模型输入管理             │
│                                     │
│  Prompt / Context / Messages        │
│  Input Validation                   │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│         Model Orchestration         │
│            模型调用控制              │
│                                     │
│  Routing / Parameters / Retry       │
│  Timeout / Fallback                 │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│            Model Service            │
│              模型服务                │
│                                     │
│  Hosted API / Self-hosted Runtime   │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│              AI Model               │
│               模型                   │
│                                     │
│  Weights / Architecture / Inference │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│          Output Processing          │
│             输出处理                 │
│                                     │
│  Parsing / Validation               │
│  Tool-call Handling                 │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│          Application Result         │
│              应用结果                │
└─────────────────────────────────────┘

这是一种用于理解职责的逻辑分层，不代表所有系统都必须按照这些层次部署独立服务。

实际应用中，多个功能可能由同一个模块完成。

4.2 模型接入层

模型接入层负责建立应用与模型服务之间的通信。

典型功能包括：

• API 客户端；
• 身份认证；
• 请求构建；
• 响应接收；
• 流式传输；
• 错误处理。

4.3 模型输入管理

模型输入管理负责将应用任务转换为模型可以处理的输入。

例如：

• System Instructions；
• User Messages；
• Conversation History；
• Context Documents；
• Tool Definitions。

这一层决定模型能够获得哪些信息，以及如何理解当前任务。

4.4 模型调用控制

模型调用控制负责决定：

• 使用哪个模型；
• 设置什么参数；
• 是否重试；
• 如何处理超时；
• 是否切换备用模型。

对于简单应用，这些逻辑可能非常少。

对于复杂系统，则可能形成专门的模型路由与调用管理模块。

4.5 模型服务

模型服务负责实际执行推理。

它可以来自：

托管模型服务

由外部服务提供模型推理能力。

自托管模型服务

开发者在自己的服务器或计算环境中部署模型。

两者的工程要求不同。

4.6 输出处理

模型输出不一定能够直接成为应用结果。

应用可能需要：

• 解析 JSON；
• 验证字段；
• 检查业务约束；
• 处理工具调用请求；
• 识别拒答或截断；
• 处理异常。

因此，输出处理是模型工程的重要组成部分。

五、Model Engineering 由哪些核心技术构成？

本章将模型工程划分为八个主要研究主题。

5.1 E1 · Model API

研究问题：如何通过 API 调用 AI 模型？

Model API 是应用与模型服务之间的主要交互接口之一。

需要研究：

• API 的基本概念；
• 请求与响应结构；
• 身份认证；
• 模型参数；
• 同步与流式调用；
• 错误处理；
• API SDK；
• 模型服务兼容性。

这一部分解决模型接入问题。

5.2 E2 · Prompt Engineering

研究问题：如何设计和管理模型输入？

Prompt Engineering 研究如何组织模型输入，以提高任务执行质量。

需要研究：

• Prompt 的构成；
• System、Developer 和 User Instructions；
• Zero-shot 与 Few-shot；
• 任务描述；
• 约束设计；
• 示例设计；
• Prompt 模板；
• Prompt 版本管理；
• Prompt 测试。

这一部分解决模型输入设计问题。

5.3 E3 · Context Window

研究问题：如何管理模型的上下文窗口？

Context Window 决定模型在一次推理中能够处理的上下文范围。

需要研究：

• Token 与 Context Window；
• 输入与输出 Token 预算；
• 对话历史；
• 长文档；
• Context Truncation；
• Context Compression；
• Context Summarization；
• 上下文选择；
• 长上下文性能问题。

这一部分解决模型信息容量与上下文管理问题。

5.4 E4 · Structured Outputs

研究问题：如何让模型生成结构化结果？

Structured Outputs 研究如何使模型输出符合程序可以处理的数据结构。

需要研究：

• JSON；
• JSON Schema；
• 类型约束；
• 字段验证；
• Schema Validation；
• Constrained Decoding；
• 输出解析；
• 错误修复；
• 结构化输出可靠性。

这一部分解决模型输出的程序可用性问题。

5.5 E5 · Function Calling

研究问题：如何让模型调用外部工具？

Function Calling 允许模型根据输入提出符合工具定义的调用请求。

需要研究：

• Tool Definition；
• Function Schema；
• Tool Selection；
• Tool Arguments；
• Tool-call Response；
• 工具执行循环；
• 参数校验；
• 工具调用安全；
• 并行工具调用。

需要特别注意：

模型生成工具调用请求，不意味着模型本身已经执行了工具。

实际执行通常由应用程序或 Agent Runtime 完成。

这一部分解决模型与外部执行能力的连接问题。

5.6 E6 · Model Routing

研究问题：如何选择和切换不同模型？

不同模型在能力、成本、速度和接口方面存在差异。

Model Routing 研究如何根据任务需求选择模型。

需要研究：

• 模型能力分类；
• 模型选择标准；
• 静态路由；
• 动态路由；
• 多模型组合；
• Fallback；
• 模型版本；
• 成本与质量权衡。

这一部分解决模型资源选择问题。

5.7 E7 · Model Deployment

研究问题：如何部署和运行开源模型？

Model Deployment 研究如何在自有环境中运行模型。

需要研究：

• 模型权重；
• 模型格式；
• 推理框架；
• CPU 与 GPU；
• 显存；
• 量化；
• 推理服务；
• API 封装；
• 部署方式；
• 服务监控。

这一部分解决模型运行环境问题。

5.8 E8 · Inference Optimization

研究问题：如何优化模型调用的成本与性能？

Inference Optimization 研究如何在满足质量要求的前提下，提高推理效率。

需要研究：

• Token 成本；
• 延迟；
• 吞吐量；
• 缓存；
• Batching；
• KV Cache；
• Quantization；
• Speculative Decoding；
• 请求并发；
• 成本预算。

这一部分解决模型应用的性能与经济效率问题。

六、八项技术之间是什么关系？

这八项技术并不是完全独立的。

它们共同参与模型的实际使用过程。

6.1 模型调用的技术链路

Application / Agent
        │
        ▼
E2 · Prompt Engineering
设计模型输入
        │
        ▼
E3 · Context Window
组织与管理上下文
        │
        ▼
E6 · Model Routing
选择目标模型
        │
        ▼
E1 · Model API
发送模型请求
        │
        ▼
Model Service
执行模型推理
        │
        ├── E7 · Model Deployment
        │   自托管模型运行
        │
        └── E8 · Inference Optimization
            推理性能优化
        │
        ▼
Model Response
        │
        ├── E4 · Structured Outputs
        │   结构化结果
        │
        └── E5 · Function Calling
            工具调用请求
        │
        ▼
Application / Agent Runtime

需要注意，E4 和 E5 并不只发生在模型返回结果之后。

结构化输出约束和工具定义通常需要在请求阶段提供给模型，而其结果在响应阶段由应用处理。

因此，这张图表达的是主要职责关系，而不是严格的执行顺序。

6.2 按工程职责分类

工程职责	对应研究
模型接入	E1 · Model API
输入设计	E2 · Prompt Engineering
上下文管理	E3 · Context Window
输出控制	E4 · Structured Outputs
外部工具交互	E5 · Function Calling
模型选择	E6 · Model Routing
模型运行	E7 · Model Deployment
性能与成本	E8 · Inference Optimization

6.3 一个完整的模型工程系统

在实际项目中，可以将这些技术组合为统一的 Model Gateway 或 Model Service Layer。

例如：

┌─────────────────────────────────────────────┐
│              Application Layer              │
│                                             │
│       Web App / Backend / Agent Runtime     │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│            Model Engineering Layer          │
│                                             │
│  Prompt Management                          │
│  Context Management                         │
│  Model Routing                              │
│  API Integration                            │
│  Structured Output Validation               │
│  Tool-call Handling                         │
│  Retry / Timeout / Fallback                 │
│  Usage / Cost Tracking                      │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│               Model Services                │
│                                             │
│   Hosted Model APIs                         │
│   Self-hosted Model Servers                 │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│              Inference Runtime              │
│                                             │
│     Model Weights / GPU / KV Cache          │
│     Batching / Quantization                 │
└─────────────────────────────────────────────┘

并不是所有应用都需要独立建设这样的完整架构。

对于简单应用，直接调用模型 API 可能已经足够。

对于复杂 Agent System，统一模型服务层则可能具有更高的管理价值。

七、模型工程有哪些典型实现方式？

根据模型来源和应用复杂度，可以将常见实现方式分为三类。

7.1 方式一：直接调用托管模型 API

这是较简单的模型应用方式。

Application
     │
     ▼
Model API
     │
     ▼
Hosted Model Service
     │
     ▼
Model Response

开发者主要负责：

• 组织输入；
• 发起请求；
• 处理输出；
• 管理调用成本。

模型运行环境由服务提供方管理。

这种方式适合：

• 原型验证；
• 小型应用；
• 快速开发；
• 不需要自行管理模型基础设施的项目。

7.2 方式二：自行部署模型

Application
     │
     ▼
Self-hosted Model API
     │
     ▼
Inference Server
     │
     ▼
Model Weights
     │
     ▼
CPU / GPU

开发者需要管理：

• 模型文件；
• 推理框架；
• 计算资源；
• 服务接口；
• 性能优化；
• 部署运维。

这种方式适合具有特定数据控制、模型定制或运行环境要求的项目。

但自托管并不自动意味着成本更低或安全性更高，仍然需要具体评估。

7.3 方式三：统一模型服务层

当应用需要使用多个模型时，可以建立统一模型接入层。

                 Application
                      │
                      ▼
                Model Gateway
                      │
          ┌───────────┼───────────┐
          │           │           │
          ▼           ▼           ▼
       Model A      Model B      Model C
          │           │           │
          ▼           ▼           ▼
       Service A   Service B   Local Server

统一模型服务层可以负责：

• 模型接口适配；
• 模型路由；
• 请求管理；
• 失败切换；
• 使用量统计；
• 成本管理。

这类架构对于多 Agent 系统具有较高价值。

八、如何理解一次完整的模型工程流程？

以一个企业信息分析功能为例。

8.1 用户任务

用户输入：

请分析这家企业的基本情况，输出主要业务、竞争优势和潜在风险。

8.2 应用准备输入

应用首先构建任务说明。

例如：

角色：
企业研究分析助手。
任务：
根据提供的企业资料完成分析。
要求：
只使用能够得到资料支持的信息。
输出：
符合指定 JSON Schema。

这一阶段涉及 E2。

8.3 组织上下文

应用整理企业资料，并控制输入长度。

例如：

• 企业简介；
• 产品信息；
• 财务资料；
• 新闻资料。

这一阶段涉及 E3。

8.4 选择模型

系统根据任务复杂度选择模型。

例如：

• 简单信息提取使用较低成本模型；
• 复杂竞争分析使用能力更强的模型。

这一阶段涉及 E6。

8.5 发起模型请求

应用通过 API 发送输入和参数。

这一阶段涉及 E1。

8.6 执行模型推理

模型服务执行推理并生成结果。

如果使用自托管模型，则涉及 E7。

推理过程中的缓存、批处理和量化等优化属于 E8。

8.7 处理输出

模型返回 JSON。

应用验证：

• 字段是否完整；
• 类型是否正确；
• 是否满足业务规则。

这一阶段涉及 E4。

8.8 处理工具调用

如果任务需要外部工具，模型可以生成工具调用请求。

应用执行工具，并将结果提供给模型继续处理。

这一阶段涉及 E5。

8.9 返回应用结果

经过必要验证后，应用向用户展示分析结果。

8.10 完整过程

用户任务
    │
    ▼
Prompt 设计
    │
    ▼
Context 构建
    │
    ▼
Model Routing
    │
    ▼
Model API
    │
    ▼
Model Inference
    │
    ▼
Model Response
    │
    ├── Structured Output
    │
    └── Tool Calling
    │
    ▼
结果验证
    │
    ▼
应用输出

这个例子展示了模型工程如何将多个技术环节组织为实际可用的功能。

九、模型工程需要关注哪些质量属性？

模型工程不仅需要让模型“能够运行”，还需要关注实际运行质量。

9.1 Correctness

正确性关注模型输出是否满足任务要求。

例如：

• 事实是否正确；
• 计算是否正确；
• 结构是否符合要求。

9.2 Reliability

可靠性关注模型调用是否能够稳定完成。

例如：

• 请求失败如何处理；
• 超时如何处理；
• 结构化输出失败如何处理。

9.3 Latency

延迟关注模型响应需要多长时间。

对于交互式应用，响应速度会直接影响用户体验。

9.4 Throughput

吞吐量关注模型服务单位时间内能够处理多少请求或 Token。

9.5 Cost

成本包括：

• API 费用；
• 计算资源；
• GPU；
• 存储；
• 网络；
• 运维。

9.6 Security

安全性涉及：

• API Key 管理；
• 数据传输；
• 敏感信息处理；
• 工具权限；
• 输出验证。

9.7 Observability

可观测性关注模型调用过程是否能够被记录、分析和诊断。

例如：

• 请求时间；
• 模型版本；
• Token 消耗；
• 延迟；
• 错误类型；
• 调用成本。

9.8 质量属性之间的权衡

目标	可能的工程代价
更高输出质量	更强模型、更高成本
更低延迟	更多计算资源、优化投入
更高吞吐量	更复杂的批处理和调度
更低成本	模型选择与质量权衡
更高可靠性	验证、重试、备用方案
更高数据控制能力	自托管与运维成本

这些属性之间通常存在权衡关系。

因此，模型工程的目标不是单独最大化某一个指标，而是在任务要求下寻找合理的系统配置。

十、Model Engineering 与相关技术领域有什么区别？

模型工程与多个技术领域存在交叉。

10.1 Model Engineering 与 MLOps

MLOps 通常关注机器学习模型的完整工程生命周期。

包括：

• 数据管理；
• 训练流水线；
• 模型注册；
• 模型部署；
• 监控；
• 版本管理。

本章的 Model Engineering 更聚焦于模型应用阶段。

两者在部署、监控和模型管理方面存在交集。

10.2 Model Engineering 与 LLMOps

LLMOps 通常指围绕大语言模型应用建立的工程实践。

它可能涵盖：

• Prompt 管理；
• 模型调用；
• RAG；
• 评估；
• 监控；
• 部署。

本章与 LLMOps 有较大交集，但采用 Model Engineering 这一名称，是为了兼顾语言模型与其他 AI 模型。

10.3 Model Engineering 与 Inference Engineering

Inference Engineering 更关注模型推理执行与性能优化。

例如：

• 推理框架；
• GPU 利用率；
• KV Cache；
• Batching；
• 量化。

它主要对应本章的 E7 和 E8。

10.4 Model Engineering 与 Agent Engineering

Agent Engineering 研究如何构建具备目标驱动、工具使用和任务执行能力的 Agent。

它通常会使用 Model Engineering 提供的模型调用能力。

但 Agent Engineering 还需要研究：

• Agent Loop；
• Planning；
• Memory；
• Tool Execution；
• State；
• Permissions。

因此，Model Engineering 是 Agent Engineering 的重要基础，但不能替代后者。

十一、本章的研究结构

本章由八篇专题研究构成。

编号	研究主题	核心问题	主要产出
E1	Model API	如何调用模型？	模型接口与请求机制
E2	Prompt Engineering	如何组织模型输入？	输入设计与 Prompt 管理
E3	Context Window	如何管理上下文？	上下文组织与预算
E4	Structured Outputs	如何控制输出格式？	结构化输出与验证
E5	Function Calling	如何连接外部工具？	工具调用机制
E6	Model Routing	如何选择模型？	模型选择与路由策略
E7	Model Deployment	如何部署模型？	自托管模型服务
E8	Inference Optimization	如何优化性能与成本？	推理效率与资源管理

11.1 第一阶段：建立模型调用基础

对应：

• E1 · Model API；
• E2 · Prompt Engineering；
• E3 · Context Window。

这一阶段主要研究模型如何接收输入，以及开发者如何管理模型请求。

11.2 第二阶段：建立模型输出与工具交互能力

对应：

• E4 · Structured Outputs；
• E5 · Function Calling。

这一阶段主要研究如何将模型输出转换为应用可以使用的结果，以及如何连接外部执行能力。

11.3 第三阶段：建立模型资源管理能力

对应：

• E6 · Model Routing；
• E7 · Model Deployment；
• E8 · Inference Optimization。

这一阶段主要研究如何选择、运行和优化模型资源。

11.4 学习路径

E1 · Model API
        │
        ▼
E2 · Prompt Engineering
        │
        ▼
E3 · Context Window
        │
        ▼
E4 · Structured Outputs
        │
        ▼
E5 · Function Calling
        │
        ▼
E6 · Model Routing
        │
        ▼
E7 · Model Deployment
        │
        ▼
E8 · Inference Optimization

这一顺序适合从基础应用逐步进入复杂工程。

但在实际项目中，可以根据需求选择相应专题。

十二、完成本章后应该具备什么能力？

完成本章研究后，应该能够理解并设计一个基本完整的模型应用方案。

12.1 模型接入能力

能够理解模型 API 的请求与响应机制，并完成基本调用。

12.2 输入组织能力

能够根据任务设计 Prompt，管理消息和上下文信息。

12.3 输出控制能力

能够使用结构化输出机制，并对结果进行程序化验证。

12.4 工具交互能力

能够理解 Function Calling 的工作流程，明确模型与外部执行系统之间的职责边界。

12.5 模型选择能力

能够根据质量、成本、延迟和任务要求选择模型。

12.6 模型部署能力

能够理解自托管模型的基本组成和部署要求。

12.7 性能优化能力

能够分析模型调用中的主要性能瓶颈，并选择适当的优化方法。

12.8 系统设计能力

能够将上述技术组织为一个可复用的模型服务模块，为后续 Agent 和 Agent System 开发提供基础。

十三、核心结论

Model Engineering 研究如何将 AI 模型的能力转化为实际应用可以调用、控制和管理的服务。

本章需要建立以下核心认识。

第一，模型具备能力，不等于应用能够直接使用这些能力。 开发者需要完成模型接入、输入组织、输出处理和运行管理。

第二，Model Engineering 是连接 Model Architecture 与实际应用的重要工程层。

第三，模型 API 解决模型接入问题，Prompt Engineering 解决输入设计问题，Context Window 解决上下文管理问题。

第四，Structured Outputs 解决模型输出的程序可用性问题，Function Calling 解决模型与外部工具之间的交互问题。

第五，Model Routing 解决模型选择问题，Model Deployment 解决模型运行问题，Inference Optimization 解决性能与成本问题。

第六，模型工程需要同时关注正确性、可靠性、延迟、吞吐量、成本和安全性。

第七，模型工程技术可以直接服务于普通 AI 应用，也可以成为 Agent 和 Agent System 的底层能力。

第八，复杂系统可以建立统一模型服务层，但简单应用不一定需要完整的平台化架构。

从整个 Agent 技术体系看，模型工程承担着重要的连接作用：

模型架构提供能力基础，模型工程提供应用接口，Agent 利用这些接口组织任务执行，而 Agent System 进一步管理多个 Agent 的运行与协作。

理解这一关系，是从研究 AI 模型原理走向实际 Agent 系统开发的重要一步。

十四、关联研究

14.1 前置研究

关联文档	研究内容
M1 · AI 模型是什么？它由什么构成？	模型基础
M3 · Transformer 如何处理和生成信息？	Transformer 架构
M4 · 大语言模型是如何构建的？	LLM 架构
M5 · AI 模型如何理解和处理不同模态？	多模态模型
M6 · AI 模型如何通过训练获得能力？	模型训练
M7 · AI 模型如何生成输出？	模型推理
M8 · 如何评估 AI 模型的能力与局限？	模型评估

14.2 本章专题

编号	研究文档
E1	如何通过 API 调用 AI 模型？ - Model API
E2	如何设计和管理模型输入？ - Prompt Engineering
E3	如何管理模型的上下文窗口？ - Context Window
E4	如何让模型生成结构化结果？ - Structured Outputs
E5	如何让模型调用外部工具？ - Function Calling
E6	如何选择和切换不同模型？ - Model Routing
E7	如何部署和运行开源模型？ - Model Deployment
E8	如何优化模型推理的性能与成本？ - Inference Optimization

14.3 后续研究

关联文档	研究内容
K1 · AI 模型的知识从哪里来？	Parametric Knowledge
K5 · 什么是 RAG？它如何工作？	Retrieval-Augmented Generation
A2 · Agent 如何获得认知与推理能力？	Agent Model
A4 · Agent 如何理解和管理当前上下文？	Agent Context
A7 · Agent 如何调用工具并执行操作？	Agent Tools
L3 · Agent System 如何接入和管理 AI 模型？	Model Services
H1 · 如何观察、追踪和诊断系统运行？	Observability
H8 · 如何管理 Agent System 的资源、成本与预算？	Resource Management