从零到一开发技术名词大全:从需求分析到 AI Agent 工程

适合人群: 编程初学者、Java 后端开发学习者、全栈开发者、AI Agent 工程初学者。
开发一个完整的软件项目,会遇到非常多陌生的技术名词。
刚开始可能只是想写一个简单的 Java 程序,后来逐渐接触 Maven、Spring Boot、MySQL、Redis、Docker、Git、REST API。
再往后开始开发 AI 应用,又会遇到 LLM、Token、Embedding、RAG、MCP、Agent Loop、Harness、DAG、Scheduler 等概念。
这些名词有些是技术,有些是工具,有些是架构思想,还有些只是描述某种开发流程的术语。
如果没有一张完整的知识地图,很容易出现一种情况:每个词都好像听过,但不知道它们之间有什么关系。
因此,这篇文章按照一个软件项目从零到一的开发过程,整理常见技术名词。
我们以 Java 后端开发 + 全栈项目 + AI Agent 工程 为主线,尽量解释每个概念的含义、用途和相互关系。
一、产品设计与需求分析:项目从哪里开始?
写代码之前,首先需要明确要做什么。
这一阶段会接触到产品、需求、原型和项目管理相关术语。
| 名词 | 英文全称或含义 | 解释 |
|---|---|---|
| PRD | Product Requirements Document | 产品需求文档,描述产品功能、业务规则和需求 |
| BRD | Business Requirements Document | 业务需求文档,主要描述业务目标和商业价值 |
| MRD | Market Requirements Document | 市场需求文档,分析市场、用户和产品机会 |
| User Story | 用户故事 | 从用户角度描述希望完成什么事情 |
| Use Case | 用例 | 描述用户与系统完成某个目标的交互过程 |
| Acceptance Criteria | 验收标准 | 判断一个功能是否真正完成的具体条件 |
| MVP | Minimum Viable Product | 最小可行产品,先实现核心价值,再逐步完善 |
| POC | Proof of Concept | 概念验证,验证某种技术或方案是否可行 |
| Prototype | 原型 | 用于展示产品交互和设计思路的初步模型 |
| Wireframe | 线框图 | 页面布局的低保真草图 |
| Mockup | 视觉稿 | 更接近最终视觉效果的静态界面设计 |
| UI | User Interface | 用户界面,用户看到和操作的部分 |
| UX | User Experience | 用户体验,关注使用过程是否方便、自然 |
| Scope | 项目范围 | 明确本次开发包含什么、不包含什么 |
| Functional Requirement | 功能需求 | 系统需要实现什么功能 |
| Non-functional Requirement | 非功能需求 | 系统在性能、安全、稳定性等方面需要达到什么要求 |
| User Flow | 用户流程 | 用户从开始到完成某项操作的路径 |
| Roadmap | 产品路线图 | 产品未来阶段的功能和发展规划 |
| Backlog | 待办需求池 | 尚未完成或尚未排期的需求集合 |
| Sprint | 迭代周期 | 敏捷开发中一个固定周期的工作阶段 |
举个例子
假设我们准备开发 MyCoder,一个 AI 编程助手。
PRD 可能描述:
用户可以通过命令行输入自然语言任务,Agent 能够读取本地文件、分析代码、调用工具,并在执行危险操作前请求用户确认。
接下来:
- MVP:先实现命令行输入、模型调用和文件读取。
- POC:验证模型是否能够正确生成工具调用参数。
- Prototype:先做一个简单交互原型。
- Acceptance Criteria:输入一个文件路径后,程序能够读取并展示文件内容。
- Roadmap:后续增加代码编辑、Git 操作、项目记忆和多 Agent 协作。
这些名词并不是编码技术,但它们决定项目究竟应该如何开始。
二、软件开发基础:先认识开发环境
这是从零开始写代码时最先遇到的一组名词。
| 名词 | 全称 | 解释 |
|---|---|---|
| IDE | Integrated Development Environment | 集成开发环境,例如 IntelliJ IDEA |
| Editor | Code Editor | 代码编辑器,例如 VS Code |
| Terminal | 终端 | 用于输入命令和查看程序输出的窗口 |
| CLI | Command-Line Interface | 命令行交互方式 |
| GUI | Graphical User Interface | 图形化交互界面 |
| CMD | Command Prompt | Windows 命令提示符 |
| PowerShell | PowerShell | Windows 的命令行和脚本环境 |
| Shell | Shell | 接收和执行命令的程序或环境 |
| SDK | Software Development Kit | 软件开发工具包,通常包含 API、库、工具和文档 |
| API | Application Programming Interface | 应用程序编程接口,规定程序之间如何交互 |
| Library | 库 | 提供可复用功能的代码集合 |
| Framework | 框架 | 提供应用程序结构和运行约定的开发基础 |
| Plugin | 插件 | 为已有系统增加功能的扩展组件 |
| Dependency | 依赖 | 项目运行或编译时需要的外部库或模块 |
| Package Manager | 包管理器 | 管理依赖包,例如 npm |
| Build Tool | 构建工具 | 管理编译、依赖、打包等过程,例如 Maven |
| Compiler | 编译器 | 将源代码转换成目标代码的程序 |
| Interpreter | 解释器 | 执行或解释程序代码的运行环境 |
| Runtime | 运行时 | 程序运行时所依赖的环境或执行机制 |
| Environment | 环境 | 程序运行所需的配置和资源集合 |
| Configuration | 配置 | 控制程序行为的参数 |
| Environment Variable | 环境变量 | 从操作系统环境中读取的配置 |
.env |
环境变量文件 | 常用于存放开发环境配置和密钥引用 |
Library 和 Framework 有什么区别?
这是非常常见的面试和开发问题。
Library(库):你主动调用它。
例如:
java
ObjectMapper mapper = new ObjectMapper();
String json = mapper.writeValueAsString(user);
这里你主动调用 Jackson 完成 JSON 转换。
Framework(框架):它按照约定组织和调用你的代码。
例如 Spring Boot 会通过框架机制管理 Bean、处理请求、组织应用生命周期。
简单记忆:
- Library:我调用它。
- Framework:它在约定的生命周期中调用我的代码。
这是一种帮助理解的简化说法,实际框架也包含大量可主动调用的库式 API。
三、Java 开发基础:JDK、JVM、Maven 等
如果主要使用 Java 开发后端,这些名词必须掌握。
| 名词 | 全称 | 解释 |
|---|---|---|
| JDK | Java Development Kit | Java 开发工具包,包含编译和开发所需工具 |
| JRE | Java Runtime Environment | Java 运行环境,传统概念上包含运行 Java 程序所需组件 |
| JVM | Java Virtual Machine | Java 虚拟机,负责执行 Java 字节码 |
| Bytecode | 字节码 | Java 编译后生成的中间代码 |
| Class | 类 | Java 中描述对象属性和行为的结构 |
| Object | 对象 | 类创建出来的实例 |
| Interface | 接口 | 定义行为契约 |
| Abstract Class | 抽象类 | 不能直接实例化、用于抽象共性行为的类 |
| Annotation | 注解 | 为代码提供元信息,例如 @Override、@Component |
| Reflection | 反射 | 程序运行时检查和操作类、方法、字段等信息 |
| Generics | 泛型 | 让类、接口和方法能够处理不同类型的数据,同时保留类型约束 |
| Exception | 异常 | 描述程序运行中发生的错误或异常情况 |
| Garbage Collection | GC,垃圾回收 | 自动回收不再使用的对象占用的内存 |
| Heap | 堆 | JVM 中主要用于对象分配的内存区域 |
| Stack | 栈 | 用于保存方法调用帧和局部变量等信息的内存区域 |
| ClassLoader | 类加载器 | 负责加载 Java 类 |
| JAR | Java Archive | Java 程序及资源的归档、分发格式 |
| WAR | Web Application Archive | Java Web 应用的一种传统打包格式 |
| Classpath | 类路径 | JVM 或编译器查找类和资源的位置 |
Maven 和 Gradle 是什么?
它们都是 Java 项目常见的构建与依赖管理工具。
Maven: 使用 pom.xml 描述依赖、插件和构建规则。
Gradle: 使用 Gradle 构建脚本配置项目,支持灵活的构建逻辑。
例如,一个项目需要使用 Jackson,就可以在 Maven 的 pom.xml 中声明依赖,而不必手动下载 JAR 包并配置类路径。
还会遇到哪些 Java 库?
| 名称 | 主要用途 |
|---|---|
| Spring Boot | 快速构建 Spring 应用 |
| Spring MVC | 构建 Web 请求处理流程 |
| Spring Security | 认证和授权安全框架 |
| MyBatis | SQL 映射框架 |
| Hibernate | ORM 框架 |
| JPA | Java 持久化规范 |
| Lombok | 减少部分样板代码 |
| HikariCP | 数据库连接池 |
| Flyway | 数据库版本迁移 |
| Jackson | JSON 序列化和反序列化 |
| OkHttp | HTTP 网络请求 |
| Picocli | Java 命令行参数解析 |
| JLine 3 | Java 交互式终端 |
| SLF4J | 日志门面 |
| Logback | 常见日志实现 |
| JUnit | Java 单元测试框架 |
| Mockito | Mock 对象和模拟依赖 |
| Testcontainers | 使用容器进行集成测试 |
注意:这些库不需要全部引入项目。技术选型要根据实际需求决定。
四、软件架构:如何组织一个项目?
项目越来越大时,不能将所有代码写在一个类里,需要考虑架构。
| 名词 | 解释 |
|---|---|
| Architecture | 架构,系统整体结构与设计方案 |
| System Design | 系统设计,围绕业务和技术约束设计系统 |
| Monolith | 单体架构,应用主要作为一个整体部署 |
| Microservices | 微服务,将系统拆分成多个相对独立的服务 |
| Client-Server | 客户端与服务端架构 |
| Layered Architecture | 分层架构,将系统按职责划分为不同层 |
| MVC | Model-View-Controller,模型、视图、控制器模式 |
| DDD | Domain-Driven Design,领域驱动设计 |
| Clean Architecture | 整洁架构,强调业务规则与外部技术实现之间的边界 |
| Hexagonal Architecture | 六边形架构,也叫端口与适配器架构 |
| Event-Driven Architecture | 事件驱动架构,以事件推动系统之间的协作 |
| Middleware | 中间件,位于请求处理流程中、提供通用能力的组件 |
| IoC | Inversion of Control,控制反转 |
| DI | Dependency Injection,依赖注入 |
| AOP | Aspect-Oriented Programming,面向切面编程 |
| Module | 模块,具有明确职责的功能单元 |
| Component | 组件,可独立组合和复用的功能单元 |
| Service | 服务,通常负责某类业务能力 |
| Gateway | 网关,统一处理外部请求并转发到内部服务 |
| Adapter | 适配器,让接口不同的组件能够协同工作 |
| Repository | 仓储,封装领域对象的持久化访问方式 |
DTO、VO、PO、DAO 又是什么?
这些名称经常出现在 Java 后端代码中。
| 名词 | 全称 | 作用 |
|---|---|---|
| DTO | Data Transfer Object | 在不同层或服务之间传输数据 |
| VO | View Object / Value Object | 根据项目语境表示展示对象或值对象 |
| PO | Persistent Object | 常用于表示与持久化数据对应的对象 |
| Entity | 实体 | 表示具有身份标识的业务对象或数据库实体 |
| DAO | Data Access Object | 封装数据访问逻辑 |
注意:这些缩写在不同项目中的定义可能有所差异,尤其是 VO、PO。不要只凭类名就判断其具体职责,要看项目约定和代码实现。
常见设计原则
| 名词 | 解释 |
|---|---|
| SOLID | 面向对象设计的五项原则 |
| SRP | 单一职责原则,一个模块尽量只有一个主要变化原因 |
| OCP | 开闭原则,对扩展开放,对修改关闭 |
| LSP | 里氏替换原则,子类型应能够替代父类型 |
| ISP | 接口隔离原则,接口应尽量小而专一 |
| DIP | 依赖倒置原则,高层模块不应直接依赖底层实现细节 |
| DRY | Don't Repeat Yourself,避免重复逻辑 |
| KISS | Keep It Simple,尽量保持设计简单 |
| YAGNI | You Aren't Gonna Need It,不要提前实现尚未需要的功能 |
| Technical Debt | 技术债,短期开发选择导致的未来维护成本 |
五、前端开发:HTML、CSS、JavaScript、React
即使主要做后端,也需要理解前后端如何协作。
| 名词 | 解释 |
|---|---|
| HTML | 页面结构与语义 |
| CSS | 页面样式和布局 |
| JavaScript | 浏览器中的主要编程语言之一 |
| TypeScript | 在 JavaScript 基础上增加静态类型系统 |
| Node.js | JavaScript 服务端运行环境 |
| npm | Node.js 常用包管理工具 |
| pnpm | 高效的 Node.js 包管理工具 |
| Yarn | JavaScript 包管理工具 |
| Vite | 前端开发服务器和构建工具 |
| Webpack | 模块打包工具 |
| React | 用于构建用户界面的 JavaScript 库 |
| Vue | 渐进式 JavaScript 框架 |
| Component | 组件,页面中可复用的 UI 单元 |
| Props | 组件从外部接收的数据 |
| State | 组件内部管理的状态 |
| Hook | React 中用于复用状态与其他能力的机制 |
| Router | 路由,决定不同 URL 对应什么页面 |
| SPA | Single Page Application,单页应用 |
| CSR | Client-Side Rendering,客户端渲染 |
| SSR | Server-Side Rendering,服务端渲染 |
| Bundler | 打包工具,将模块组织成可交付资源 |
| Proxy | 代理,将请求转发到其他服务器 |
前后端如何配合?
例如用户点击登录按钮:
text
用户点击登录
|
v
React 获取输入内容
|
v
JavaScript 发送 HTTP 请求
|
v
Java 后端接收请求
|
v
验证账号和密码
|
v
查询 MySQL
|
v
返回 JSON
|
v
React 更新页面状态
前端不应该直接连接数据库,而是通过后端提供的 API 与业务系统交互。
六、网络通信:HTTP、TCP、REST API
网络通信是前后端开发和 LLM API 接入的基础。
| 名词 | 解释 |
|---|---|
| TCP | 面向连接、可靠传输的传输层协议 |
| UDP | 无连接的数据报传输协议 |
| IP | 网络层寻址与数据传输协议 |
| DNS | 将域名解析为 IP 地址等记录的系统 |
| HTTP | 超文本传输协议 |
| HTTPS | 通过 TLS 保护的 HTTP 通信 |
| TLS | 提供加密、完整性保护和身份验证能力的安全协议 |
| URL | 统一资源定位符 |
| URI | 统一资源标识符 |
| Request | 请求 |
| Response | 响应 |
| Header | 请求或响应头 |
| Body | 请求或响应主体 |
| GET | 常用于获取资源 |
| POST | 常用于提交数据或创建资源 |
| PUT | 常用于整体替换资源 |
| PATCH | 常用于部分更新资源 |
| DELETE | 常用于删除资源 |
| Status Code | HTTP 状态码 |
| REST | 一种以资源为中心的 API 架构风格 |
| RESTful API | 遵循 REST 风格设计的 API |
| RPC | Remote Procedure Call,远程过程调用 |
| WebSocket | 支持双向实时通信的协议 |
| SSE | Server-Sent Events,服务端向客户端持续推送事件 |
| CORS | 跨域资源共享机制 |
| Cookie | 浏览器保存并按规则发送给服务器的数据 |
| Session | 服务端用于管理用户会话的机制 |
| JWT | JSON Web Token,一种令牌格式 |
| OAuth 2.0 | 授权框架 |
| Rate Limiting | 限流,控制单位时间内的请求数量 |
HTTP 状态码需要认识哪些?
| 状态码 | 含义 |
|---|---|
| 200 | 请求成功 |
| 201 | 资源创建成功 |
| 204 | 请求成功,但无响应主体 |
| 301 | 永久重定向 |
| 302 | 临时重定向 |
| 400 | 请求参数或格式有问题 |
| 401 | 未通过身份认证 |
| 403 | 没有权限访问 |
| 404 | 资源不存在 |
| 405 | 请求方法不被允许 |
| 409 | 请求与当前资源状态冲突 |
| 429 | 请求过多,触发限流 |
| 500 | 服务器内部错误 |
| 502 | 网关收到无效响应 |
| 503 | 服务暂时不可用 |
| 504 | 网关等待上游响应超时 |
特别注意:401 和 403 不一样。401 主要表示尚未通过身份认证,403 表示已经识别身份但不允许访问相应资源。
七、数据库:MySQL、Redis、索引和事务
数据库负责持久化保存业务数据。
1. 关系型数据库基础
| 名词 | 解释 |
|---|---|
| RDBMS | Relational Database Management System,关系型数据库管理系统 |
| SQL | Structured Query Language,结构化查询语言 |
| Database | 数据库 |
| Table | 表 |
| Row | 行,一条记录 |
| Column | 列,一个字段 |
| Schema | 数据库结构或命名空间,具体含义取决于数据库 |
| Primary Key | 主键,标识一条记录 |
| Foreign Key | 外键,表达表之间的引用关系 |
| Unique Constraint | 唯一约束 |
| Index | 索引,加速数据查询的数据结构 |
| Composite Index | 联合索引 |
| Covering Index | 覆盖索引 |
| Full Table Scan | 全表扫描 |
| Query Plan | 查询执行计划 |
| Slow Query | 慢查询 |
| Normalization | 数据库规范化 |
| Denormalization | 反规范化,出于性能或业务考虑有意冗余数据 |
SQL 常见分类
| 类型 | 作用 | 常见语句 |
|---|---|---|
| DDL | 定义数据库结构 | CREATE、ALTER、DROP |
| DML | 修改数据 | INSERT、UPDATE、DELETE |
| DQL | 查询数据 | SELECT |
| DCL | 管理权限 | GRANT、REVOKE |
| TCL | 管理事务 | COMMIT、ROLLBACK |
2. 事务相关概念
事务是数据库中非常重要的概念。
例如转账:
text
账户 A 扣除 100 元
|
v
账户 B 增加 100 元
两步应该作为一个完整的业务操作处理,避免出现 A 扣款成功但 B 没有收到钱的情况。
| 名词 | 解释 |
|---|---|
| Transaction | 事务,一组需要按事务规则执行的操作 |
| ACID | 原子性、一致性、隔离性、持久性 |
| Atomicity | 原子性,要么全部成功,要么全部回滚 |
| Consistency | 一致性,事务前后满足约束条件 |
| Isolation | 隔离性,并发事务之间相互隔离的程度 |
| Durability | 持久性,已提交的数据具备持久保存能力 |
| Isolation Level | 事务隔离级别 |
| Dirty Read | 脏读 |
| Non-repeatable Read | 不可重复读 |
| Phantom Read | 幻读 |
| MVCC | Multi-Version Concurrency Control,多版本并发控制 |
| Lock | 锁 |
| Optimistic Lock | 乐观锁 |
| Pessimistic Lock | 悲观锁 |
3. Redis 与缓存
Redis 是常见的内存数据结构存储系统,常用于缓存、计数、排行榜、会话数据和分布式协调等场景。
| 名词 | 解释 |
|---|---|
| Cache | 缓存 |
| Cache Hit | 缓存命中 |
| Cache Miss | 缓存未命中 |
| TTL | Time To Live,过期时间 |
| Eviction | 淘汰策略 |
| Key-Value | 键值数据结构 |
| Persistence | 持久化 |
| RDB | Redis 的快照持久化方式 |
| AOF | Redis 的追加日志持久化方式 |
| Pub/Sub | 发布订阅 |
| Pipeline | 批量发送命令,减少通信开销 |
| Distributed Lock | 分布式锁 |
缓存常见问题:
| 名词 | 解释 |
|---|---|
| Cache Penetration | 缓存穿透,查询持续访问缓存和数据库中都不存在的数据 |
| Cache Breakdown | 缓存击穿,热点数据失效后大量请求同时访问数据库 |
| Cache Avalanche | 缓存雪崩,大量缓存同时失效或缓存服务出现故障 |
4. 消息队列 MQ
MQ 是 Message Queue 的简称,消息队列主要用于服务之间的异步通信和解耦。
常见技术:Kafka、RabbitMQ、RocketMQ。
| 名词 | 解释 |
|---|---|
| Message Queue | 消息队列 |
| Producer | 生产者,发送消息 |
| Consumer | 消费者,处理消息 |
| Topic | 消息主题 |
| Queue | 消息队列 |
| Partition | 分区,常用于提高并行处理能力 |
| Offset | 消息在分区中的位置 |
| Consumer Group | 消费者组 |
| ACK | Acknowledgement,确认机制 |
| Retry | 重试 |
| Dead Letter Queue | 死信队列 |
| Idempotency | 幂等性,多次执行相同操作不会产生重复的业务效果 |
| Eventual Consistency | 最终一致性,不同数据副本在一段时间后达到一致 |
例如,用户下单后,不需要让订单服务同步等待邮件服务发送邮件,可以将发送通知的任务交给消息队列异步处理。
八、Git 与团队协作开发
多人开发项目时,Git 是最常见的版本控制工具之一。
| 名词 | 解释 |
|---|---|
| Git | 分布式版本控制系统 |
| Repository / Repo | 代码仓库 |
| Working Tree | 工作区 |
| Staging Area | 暂存区 |
| Commit | 提交一次版本记录 |
| Branch | 分支 |
| Merge | 合并分支 |
| Rebase | 变基,重新整理提交的基础位置 |
| Cherry-pick | 选择性应用某个提交 |
| Tag | 标签,常用于标记版本 |
| Conflict | 合并冲突 |
| Pull | 获取并整合远程更新 |
| Push | 推送本地提交到远程仓库 |
| Clone | 克隆仓库 |
| Fork | 派生一个独立仓库 |
| PR | Pull Request,合并请求 |
| MR | Merge Request,合并请求 |
| Code Review | 代码审查 |
| Release | 发布版本 |
| Semantic Versioning | 语义化版本,例如 1.2.3 |
一个典型协作流程
text
克隆代码仓库
|
v
创建功能分支
|
v
编写代码
|
v
本地测试
|
v
Commit
|
v
Push
|
v
创建 PR / MR
|
v
Code Review
|
v
合并主分支
需要区分 Git 和 GitHub:
- Git 是版本控制工具。
- GitHub 是提供代码托管和协作功能的平台。
- GitLab、Gitee 等也是代码托管和协作平台。
九、测试与代码质量
代码能够运行,不代表代码没有问题。
软件开发需要通过测试验证功能、稳定性和边界情况。
| 名词 | 解释 |
|---|---|
| Test Case | 测试用例 |
| Unit Test | 单元测试,验证一个较小的代码单元 |
| Integration Test | 集成测试,验证多个组件之间的协作 |
| System Test | 系统测试,验证整个系统 |
| E2E Test | End-to-End Test,端到端测试 |
| Regression Test | 回归测试,确保修改没有破坏已有功能 |
| Smoke Test | 冒烟测试,快速检查核心功能是否可用 |
| API Test | 接口测试 |
| Load Test | 负载测试 |
| Stress Test | 压力测试 |
| Soak Test | 长时间稳定性测试 |
| Mock | 模拟对象或依赖 |
| Stub | 提供预设响应的替身 |
| Spy | 记录调用情况的测试替身 |
| Fixture | 测试所需的预置数据或环境 |
| Test Coverage | 测试覆盖率 |
| Assertion | 断言,判断实际结果是否符合预期 |
| Lint | 静态检查代码风格和常见问题 |
| Static Analysis | 静态代码分析 |
| Refactoring | 重构,在尽量保持外部行为不变的情况下改善内部结构 |
常见测试工具
- JUnit:Java 单元测试。
- Mockito:模拟外部依赖。
- Postman:手动测试 HTTP API。
- Apifox:API 设计、调试和管理。
- Testcontainers:通过容器启动真实依赖服务进行测试。
- JaCoCo:Java 测试覆盖率工具。
十、DevOps:构建、部署与运维
开发完成之后,还要让程序能够在服务器上运行。
这就涉及 DevOps。
DevOps 可以理解为开发(Development)与运维(Operations)的协作文化和实践。
| 名词 | 解释 |
|---|---|
| DevOps | 开发与运维协作理念及实践 |
| CI | Continuous Integration,持续集成 |
| CD | Continuous Delivery / Deployment,持续交付或持续部署 |
| Pipeline | 流水线,自动化执行的一系列步骤 |
| Build | 构建 |
| Artifact | 构建产物,例如 JAR、镜像 |
| Deploy | 部署 |
| Release | 发布 |
| Rollback | 回滚 |
| Environment | 环境,如开发、测试、生产环境 |
| Docker | 容器化平台 |
| Image | 镜像,容器运行所使用的模板 |
| Container | 容器,镜像启动后的运行实例 |
| Dockerfile | 定义镜像构建步骤的文件 |
| Registry | 镜像仓库 |
| Docker Compose | 定义和管理多容器应用 |
| Kubernetes / K8s | 容器编排平台 |
| Pod | Kubernetes 中最小的可部署单元 |
| Deployment | 管理应用 Pod 副本和更新的资源 |
| Service | 为一组 Pod 提供稳定访问入口 |
| Ingress | 管理进入集群的 HTTP/HTTPS 流量的资源 |
| ConfigMap | Kubernetes 中存储非敏感配置的资源 |
| Secret | Kubernetes 中存储敏感配置的资源 |
常见部署流程
text
开发者提交代码
|
v
Git 仓库
|
v
CI Pipeline
|
v
编译 + 测试
|
v
构建 Docker Image
|
v
推送 Registry
|
v
部署到服务器 / Kubernetes
|
v
服务运行
常见部署策略
| 名词 | 解释 |
|---|---|
| Rolling Update | 滚动更新,逐步替换旧版本实例 |
| Blue-Green Deployment | 蓝绿部署,准备新旧两套环境后切换流量 |
| Canary Release | 灰度发布,先让一部分流量访问新版本 |
| Feature Flag | 功能开关,可控制某项功能是否对用户开放 |
| Health Check | 健康检查 |
| Readiness Probe | 就绪探针,检查实例是否准备好接收流量 |
| Liveness Probe | 存活探针,检查实例是否仍在正常运行 |
十一、监控、日志与可观测性
程序上线后,需要知道它运行得怎么样。
例如:
- 为什么接口突然变慢?
- 为什么数据库连接池耗尽?
- 哪个服务发生了异常?
- 一个请求经过了哪些服务?
- Agent 为什么连续调用工具失败?
这就涉及 Observability。
| 名词 | 解释 |
|---|---|
| Observability | 可观测性,通过外部数据了解系统内部运行情况 |
| Logging | 日志记录 |
| Metrics | 指标数据 |
| Tracing | 链路追踪 |
| Trace | 一次请求或任务的完整追踪记录 |
| Span | Trace 中的一段操作 |
| Latency | 延迟 |
| Throughput | 吞吐量 |
| QPS | Queries Per Second,每秒查询数 |
| TPS | Transactions Per Second,每秒事务数 |
| Error Rate | 错误率 |
| P50 / P95 / P99 | 延迟分位数指标 |
| Alert | 告警 |
| Dashboard | 监控仪表盘 |
| SLI | Service Level Indicator,服务质量指标 |
| SLO | Service Level Objective,服务质量目标 |
| SLA | Service Level Agreement,服务等级协议 |
常见工具:
| 工具 | 作用 |
|---|---|
| Prometheus | 指标采集和存储 |
| Grafana | 指标可视化和监控面板 |
| ELK | Elasticsearch、Logstash、Kibana 的常见日志处理组合 |
| OpenTelemetry | 可观测性数据的采集与传输标准及工具生态 |
| Jaeger | 分布式链路追踪 |
| Loki | 日志聚合系统 |
Logs、Metrics、Traces 有什么区别?
- Logs:发生了什么事情?
- Metrics:系统整体表现如何?
- Traces:一个请求经过了哪些环节?
三者结合,才能更有效地定位线上问题。
十二、系统安全:开发时必须认识的概念
安全不是最后才补充的功能,而是从项目设计阶段就应该考虑的问题。
| 名词 | 解释 |
|---|---|
| Authentication | 身份认证,确认你是谁 |
| Authorization | 权限授权,确认你能做什么 |
| RBAC | Role-Based Access Control,基于角色的访问控制 |
| ACL | Access Control List,访问控制列表 |
| Least Privilege | 最小权限原则 |
| Encryption | 加密,保护数据机密性 |
| Hash | 哈希,将数据映射为固定长度摘要 |
| Salt | 盐值,用于增强密码哈希抵抗攻击的能力 |
| Secret Management | 密钥管理 |
| Audit Log | 审计日志 |
| Rate Limit | 限流 |
| Sandbox | 沙箱,限制程序运行权限和影响范围 |
| Input Validation | 输入校验 |
| SQL Injection | SQL 注入 |
| XSS | 跨站脚本攻击 |
| CSRF | 跨站请求伪造 |
| SSRF | 服务端请求伪造 |
| Path Traversal | 路径遍历攻击 |
| Command Injection | 命令注入 |
| Prompt Injection | 提示词注入,诱导模型违反预期指令或使用不可信内容执行操作 |
身份认证和权限授权的区别
例如,一个用户登录系统:
- 用户提供账号和密码。
- 系统确认用户身份,这叫 Authentication。
- 用户尝试访问管理员页面。
- 系统检查是否具备管理员权限,这叫 Authorization。
可以记忆为:
认证解决你是谁,授权解决你能做什么。
十三、分布式系统:服务越来越多之后
当一个应用从单机发展到多个服务、多个实例,就会出现更多复杂问题。
| 名词 | 解释 |
|---|---|
| Distributed System | 分布式系统,由多个独立节点协作完成任务 |
| Load Balancer | 负载均衡器,将请求分配到多个实例 |
| Service Discovery | 服务发现,找到可用服务实例 |
| API Gateway | API 网关,统一处理和转发外部请求 |
| Reverse Proxy | 反向代理,代替客户端访问后端服务 |
| Forward Proxy | 正向代理,代替客户端访问外部资源 |
| RPC | 远程过程调用 |
| gRPC | 基于 HTTP/2 和 Protocol Buffers 的 RPC 框架 |
| Protobuf | Protocol Buffers,结构化数据序列化格式 |
| Circuit Breaker | 熔断器,故障时暂时阻止对下游的调用 |
| Retry | 重试 |
| Timeout | 超时控制 |
| Bulkhead | 舱壁隔离,将资源划分为独立部分,避免故障扩散 |
| Failover | 故障切换 |
| Replication | 副本复制 |
| Sharding | 分片,通常指将数据拆分到不同节点 |
| Distributed Lock | 分布式锁 |
| CAP | 分布式系统中关于一致性、可用性与分区容错的理论讨论 |
| Consistency | 一致性 |
| Availability | 可用性 |
| Partition Tolerance | 分区容错性 |
为什么需要熔断、重试和超时?
假设服务 A 调用服务 B:
text
用户请求
|
v
服务 A
|
v
服务 B
如果 B 突然响应很慢,A 可能不断等待,最终自己的线程资源也被占满。
因此需要:
- Timeout:不能无限等待。
- Retry:遇到可恢复故障时可以重试。
- Circuit Breaker:下游持续故障时暂时停止调用。
- Bulkhead:隔离资源,防止一个故障影响全部功能。
这些机制在后端工程和 Agent 调用外部工具时都非常重要。
十四、LLM 大语言模型:AI 应用基础知识
进入 AI 应用开发之后,会遇到一批新的技术名词。
1. 模型基础
| 名词 | 解释 |
|---|---|
| LLM | Large Language Model,大语言模型 |
| Model | 模型 |
| Model Provider | 模型服务提供商 |
| Inference | 推理,使用训练好的模型生成结果 |
| Token | 模型处理文本的基本单位 |
| Tokenizer | 将文本转换成 Token 的工具 |
| Context Window | 上下文窗口,模型一次处理输入和输出所受的上下文长度限制 |
| Prompt | 提供给模型的提示内容 |
| System Prompt | 系统级指令 |
| Developer Message | 开发者指令 |
| User Message | 用户消息 |
| Assistant Message | 助手消息 |
| Temperature | 控制生成随机性的一种参数 |
| Top-p | 核采样参数 |
| Logits | 模型输出层中尚未归一化的分数 |
| Sampling | 根据概率分布选择输出 Token |
| Fine-tuning | 微调,通过额外训练调整模型行为 |
| Pre-training | 预训练 |
| Quantization | 量化,使用更低精度表示模型参数等数据 |
| Model Routing | 模型路由,根据任务选择模型 |
| Fallback | 回退,主方案不可用时切换到备用方案 |
Token 和字符有什么区别?
Token 不是简单等于一个汉字或一个英文单词。
不同模型的分词规则不同,同一段文本在不同模型中的 Token 数量也可能不同。
因此,调用模型时需要关注 Token 使用量和上下文窗口。
2. 模型 API 调用
| 名词 | 解释 |
|---|---|
| Chat Completion | 基于对话消息生成回答的接口模式 |
| Messages API | 通过消息列表与模型交互的 API 形式 |
| Streaming | 流式输出,模型生成内容时逐步返回 |
| Non-streaming | 非流式输出,通常等待完整结果后返回 |
| Structured Output | 结构化输出,让模型按照指定数据格式返回 |
| JSON Mode | 尽可能约束模型生成 JSON 的一种模式 |
| Function Calling | 函数调用能力,模型提出调用函数或工具的请求 |
| Tool Calling | 工具调用能力,模型请求运行外部工具 |
| Tool Result | 工具执行结果 |
| Tool Schema | 工具参数结构定义 |
| Multimodal | 多模态,处理文本、图像、音频等多种数据 |
| Vision Model | 具备图像理解能力的模型 |
| STT | Speech-to-Text,语音转文本 |
| TTS | Text-to-Speech,文本转语音 |
注意:Function Calling 不等于模型自己执行了函数。通常是模型生成结构化调用请求,应用程序负责验证并真正执行。
3. RAG 与知识增强
| 名词 | 解释 |
|---|---|
| RAG | Retrieval-Augmented Generation,检索增强生成 |
| Embedding | 嵌入,将文本等数据转换为向量表示 |
| Vector | 向量 |
| Vector Database | 向量数据库 |
| Vector Search | 向量检索 |
| Similarity Search | 相似度检索 |
| ANN | Approximate Nearest Neighbor,近似最近邻搜索 |
| Cosine Similarity | 余弦相似度 |
| Chunk | 文本切片 |
| Chunking | 将文档切分为片段 |
| Indexing | 索引构建 |
| BM25 | 常见的关键词相关性检索算法 |
| Hybrid Search | 混合检索,结合关键词与向量检索 |
| Metadata Filtering | 根据元数据筛选检索结果 |
| Reranking | 重排序,重新评估候选检索结果的相关性 |
| Retrieval | 检索 |
| Knowledge Base | 知识库 |
| Wiki | 关联和维护知识的组织方式 |
| Grounding | 基于可验证资料约束模型回答 |
| Hallucination | 幻觉,模型生成缺乏事实依据或不正确的内容 |
一条典型的 RAG 流程
text
上传文档
|
v
文档解析
|
v
文本切分 Chunking
|
v
Embedding 向量化
|
v
存入向量数据库
|
v
用户提出问题
|
v
检索相关内容
|
v
Reranking 重排序
|
v
将相关内容加入 Prompt
|
v
LLM 生成答案
RAG 不等于向量数据库。向量数据库只是常见实现方案之一,实际系统也可以使用关键词检索、全文检索、数据库查询等方式。
十五、Agent 工程:从模型调用到真正的智能体
这是 AI 工程中最值得重点学习的一部分。
LLM 能够理解和生成文本,但如果要让它真正执行任务,还需要运行时、工具系统、安全机制和上下文管理等工程能力。
| 名词 | 解释 |
|---|---|
| Agent | 智能体,通过模型和工具等能力完成目标的系统 |
| Agent Runtime | Agent 运行时,负责管理 Agent 的执行过程 |
| Agent Loop | Agent 循环,组织模型决策、工具执行和结果反馈 |
| Harness | Agent 的运行与控制环境,通常涵盖循环、工具、权限、上下文等 |
| Tool | 工具,提供外部操作能力 |
| Tool Calling | 模型请求执行工具的机制 |
| Tool Registry | 工具注册表,管理可用工具 |
| Tool Executor | 工具执行器,负责调用具体工具 |
| Tool Schema | 工具参数定义 |
| Hook | 钩子,在预定义生命周期事件发生时触发扩展逻辑 |
| Middleware | 中间件,在请求或执行链路中统一处理通用逻辑 |
| Skill | 技能,通常封装某类任务的知识、流程或操作指导 |
| Memory | 记忆系统,保存和检索有价值的信息 |
| Short-term Memory | 短期记忆,管理当前任务或会话上下文 |
| Long-term Memory | 长期记忆,跨会话保存信息 |
| Context Management | 上下文管理 |
| Context Compression | 上下文压缩,减少上下文占用 |
| Planning | 规划,将目标拆分为多个步骤 |
| ReAct | Reasoning + Acting,结合推理与行动的 Agent 模式 |
| Plan-and-Execute | 先规划再执行的 Agent 模式 |
| Reflection | 反思,根据执行结果评估和改进方案 |
| Self-correction | 自我纠错 |
| Multi-Agent | 多智能体系统 |
| Supervisor | 监督者或协调者 Agent |
| Delegation | 任务委派 |
| Handoff | 将任务或控制权交接给另一个 Agent |
| Blackboard | 黑板系统,多个 Agent 通过共享工作区协同 |
| Orchestration | 编排,组织多个组件或 Agent 协作 |
| Human-in-the-loop | 人在回路中,关键环节由用户参与决策 |
| Approval | 审批,执行敏感操作前请求授权 |
| Guardrail | 护栏,限制和规范模型或 Agent 的行为 |
| Sandbox | 沙箱,为工具或代码提供隔离执行环境 |
| Checkpoint | 检查点,保存任务执行到某个阶段的状态 |
| Resume | 恢复,从中断位置或保存状态继续执行 |
| Interruption | 中断,暂停或停止正在运行的任务 |
| Trace | 追踪,记录一次 Agent 执行的过程 |
| Agent Evaluation | Agent 评测,衡量任务完成质量和运行表现 |
Tool、Skill、Hook 有什么区别?
它们虽然都可以出现在 Agent 系统中,但职责不同。
- Tool:Agent 能够调用什么能力?
- Skill:Agent 应该如何完成某类任务?
- Hook:运行时在什么时机自动执行额外逻辑?
例如:
text
用户要求修改 Java 文件
|
v
Agent 读取相关 Skill
|
v
Agent 决定调用 edit_file Tool
|
v
PreToolUse Hook 检查权限
|
v
Tool Executor 执行修改
|
v
PostToolUse Hook 记录结果
|
v
Agent 根据结果继续执行
Harness 和 Agent Runtime 有什么区别?
两个概念经常同时出现,但不同项目的定义边界可能不同。
可以将 Agent Runtime 理解为负责执行和管理 Agent 的运行机制。
Harness 的范围通常更广,还会涉及:
- 上下文管理。
- 工具注册和执行。
- 权限控制。
- 生命周期钩子。
- 沙箱。
- 中断与恢复。
- 日志、追踪和评测。
因此可以把 Harness 看成围绕 Agent 建立的一套完整工程控制环境。
十六、Graph、DAG、Workflow、Scheduler:复杂任务如何编排?
当 Agent 需要完成多个任务、并行调用多个 Agent,就会遇到任务编排相关概念。
| 名词 | 解释 |
|---|---|
| Graph | 图,由节点和边组成 |
| Node / Vertex | 节点 |
| Edge | 边,表示节点之间的连接 |
| Directed Graph | 有向图,边存在方向 |
| Undirected Graph | 无向图,边没有方向 |
| Cycle | 环,存在一条路径可以回到原节点 |
| DAG | Directed Acyclic Graph,有向无环图 |
| Topological Sort | 拓扑排序,计算满足依赖关系的节点顺序 |
| Indegree | 入度,指向某节点的边的数量 |
| Outdegree | 出度,从某节点指出去的边的数量 |
| Dependency | 依赖 |
| Dependency Graph | 依赖关系图 |
| Workflow | 工作流,描述任务的业务步骤和流转规则 |
| Scheduler | 调度器,决定任务何时执行 |
| Executor | 执行器,真正执行任务 |
| Queue | 队列,保存待执行任务 |
| Concurrency | 并发,多个任务在同一时间段内推进 |
| Parallelism | 并行,多个任务在同一时刻真正同时执行 |
| Fan-out | 扇出,一个任务分发出多个子任务 |
| Fan-in | 扇入,多个任务结果汇总到一起 |
| State Machine | 状态机,使用状态和事件管理流程 |
| State Transition | 状态转换 |
| Callback | 回调,在某个事件或操作完成时执行的函数 |
| Event | 事件,系统中发生的某件事情 |
| Event Loop | 事件循环,持续检查和处理待执行事件的机制 |
一个 DAG 示例
text
A:分析需求
|
+----+----+
| |
v v
B:代码分析 C:数据分析
| |
+----+----+
|
v
D:生成报告
在这个流程中:
- DAG 描述任务依赖关系。
- Workflow 描述完整业务步骤。
- Scheduler 决定哪些任务可以开始。
- Executor 真正执行任务。
- B 和 C 如果没有相互依赖,就有机会并行执行。
Agent Loop 和 DAG 的关系
Agent Loop 解决:
当前 Agent 下一步应该做什么?
DAG 解决:
多个任务之间有什么依赖关系?
它们可以结合:
text
DAG 工作流
|
+-------+-------+
| |
Agent A Agent B
| |
Agent Loop Agent Loop
| |
+-------+-------+
|
Agent C
|
Agent Loop
每个 Agent 内部可以运行自己的 Agent Loop,而外部 DAG 负责组织多个 Agent 之间的任务依赖。
十七、MCP 与 Agent 工具生态
当 Agent 需要接入外部工具、文件系统、数据库和第三方服务时,还会接触到 MCP。
| 名词 | 解释 |
|---|---|
| MCP | Model Context Protocol,模型上下文协议 |
| MCP Client | MCP 客户端,主动连接和使用 MCP Server |
| MCP Server | MCP 服务端,向客户端提供约定的能力 |
| Tool | 可被调用的工具 |
| Resource | MCP 中可供客户端读取的资源 |
| Prompt | MCP 中可以提供给客户端使用的提示模板 |
| Transport | 传输方式 |
| stdio | 标准输入输出通信方式 |
| SSE | Server-Sent Events,一种服务端事件推送技术;需结合具体 MCP 版本理解传输方案 |
| JSON-RPC | 基于 JSON 的远程过程调用协议格式 |
| Capability | 能力声明 |
| Protocol | 协议,规定系统之间如何通信 |
例如,Agent 本身并不需要直接实现所有能力。
它可以通过 MCP Server 接入:
text
Agent
|
v
MCP Client
|
+------ MCP Server:文件系统
|
+------ MCP Server:Git
|
+------ MCP Server:数据库
|
+------ MCP Server:外部服务
MCP 的价值之一是提供标准化的连接方式,降低不同 Agent 应用与外部工具之间的集成成本。
但 MCP 不等于 Agent,它也不等于 Tool Registry 或 Agent Runtime。
十八、技术名词之间最容易混淆的对照表
最后整理一些特别容易混淆的概念。
| 容易混淆的概念 | 核心区别 |
|---|---|
| API vs SDK | API 是接口约定;SDK 是帮助开发者使用服务的一套工具包 |
| Library vs Framework | 库通常由应用主动调用;框架会按其生命周期组织和调用代码 |
| JDK vs JVM | JDK 是开发工具包;JVM 是执行 Java 字节码的虚拟机 |
| CMD vs PowerShell vs CLI | CMD、PowerShell 是命令环境;CLI 是交互方式 |
| Picocli vs JLine | Picocli 解析命令;JLine 提供交互式终端能力 |
| OkHttp vs Jackson | OkHttp 负责网络通信;Jackson 负责 JSON 数据转换 |
| MySQL vs Redis | MySQL 常用于关系型持久化;Redis 常用于内存数据结构存储 |
| SQL vs ORM | SQL 是数据库查询语言;ORM 是对象关系映射技术 |
| Git vs GitHub | Git 是版本控制工具;GitHub 是代码托管和协作平台 |
| Docker vs Kubernetes | Docker 用于构建和运行容器;Kubernetes 负责容器编排 |
| Authentication vs Authorization | 身份认证 vs 权限授权 |
| Wiki vs RAG | Wiki 组织知识;RAG 检索资料并增强模型生成 |
| RAG vs Vector Database | RAG 是应用架构;向量数据库是可能使用的存储与检索组件 |
| Embedding vs Token | Embedding 是向量表示;Token 是模型处理文本的基本单位 |
| LLM vs Agent | LLM 是模型;Agent 是围绕模型构建的任务执行系统 |
| Tool vs Skill | Tool 提供执行能力;Skill 提供完成任务的方法和指导 |
| Tool vs Hook | Tool 通常由 Agent 请求调用;Hook 由运行时生命周期事件触发 |
| Agent Loop vs DAG | Agent Loop 管迭代决策;DAG 管任务依赖 |
| Graph vs DAG | Graph 是通用图;DAG 是有向无环图 |
| DAG vs Workflow | DAG 描述依赖结构;Workflow 描述业务流程 |
| Workflow vs Scheduler | Workflow 定义流程;Scheduler 安排执行 |
| Scheduler vs Executor | Scheduler 决定何时执行;Executor 负责真正执行 |
| Logging vs Metrics vs Tracing | 日志记录事件;指标衡量整体表现;追踪还原调用路径 |
| CI vs CD | CI 关注持续集成;CD 指持续交付或持续部署,具体含义依上下文而定 |
十九、从零到一开发,应该按照什么顺序学习?
看到这么多名词,不建议一口气全部学习。
更好的方式是按照实际开发过程,边做项目边掌握。
| 阶段 | 建议掌握的技术 | 需要达到的能力 |
|---|---|---|
| 第一阶段:基础 | Java、JDK、JVM、Git、Maven、IDE | 能够独立创建和运行项目 |
| 第二阶段:后端 | Spring Boot、HTTP、REST API、Jackson | 能够构建后端接口 |
| 第三阶段:数据库 | MySQL、SQL、Redis、事务、索引 | 能够持久化和管理业务数据 |
| 第四阶段:工程化 | JUnit、Mockito、Docker、CI/CD | 能够测试和部署项目 |
| 第五阶段:全栈 | HTML、CSS、TypeScript、React、Vite | 能够构建前后端协作应用 |
| 第六阶段:AI 基础 | LLM、Prompt、Token、API、Streaming | 能够接入大语言模型 |
| 第七阶段:RAG | Embedding、Chunk、Vector DB、Reranking | 能够构建知识检索系统 |
| 第八阶段:Agent | Agent Loop、Tool、Hook、Memory、Harness | 能够构建具备工具执行能力的 Agent |
| 第九阶段:高级编排 | DAG、Workflow、Scheduler、Multi-Agent | 能够构建复杂任务协作系统 |
| 第十阶段:工程质量 | Observability、Evaluation、Guardrail、Sandbox | 能够提升系统的可靠性和安全性 |
最后:遇到一个陌生技术名词,应该怎么学习?
不要只记住中文翻译。
例如遇到 Scheduler,不要只记住它叫调度器。
可以按照下面五个问题去理解:
- 它是什么? 它属于哪一个技术领域?
- 为什么需要它? 没有它会出现什么问题?
- 它怎么工作? 内部的基本流程是什么?
- 它与什么有关? 容易和哪些技术混淆?
- 如何实践? 能否通过一个最小 Demo 验证它?
以 Scheduler 为例:
- 是什么:任务调度器。
- 为什么需要:多个任务之间存在依赖,需要决定执行时机。
- 怎么工作:检查任务状态、依赖和资源,再安排执行。
- 相关概念:DAG、Workflow、Executor、Queue。
- 如何实践:编写一个简单的 DAG 任务调度器,让两个无依赖任务并行执行。
这比单纯背名词有效得多。
真正理解一个技术,不是知道它的英文全称,而是知道它在整个系统中负责什么,为什么需要它,以及它如何和其他组件配合。
这份技术名词大全可以作为开发时的长期索引。实际学习时不需要从头到尾背诵,而是在项目中遇到对应问题时,再回到相关章节深入理解。