简历与项目讲解
2026/10/23About 14 min
简历技术点详解
简历上出现的每个技术词，这里都能找到三件事：是什么、你在项目里怎么用的、适合什么场景（以及不适合什么场景）。 原则：简历上写了的词，面试官都可能让你「展开讲讲」。这份文档就是你的底稿。
目录：一、设计模式 → 二、Agent 与大模型 → 三、RAG 与知识 → 四、Python 技术栈 → 五、存储 → 六、Java 技术栈 → 七、中间件与数据同步 → 八、工程与部署 → 九、前端 → 十、旧项目里的概念
二、Agent 与大模型
| 词 | 是什么 | 项目里 |
|---|---|---|
| Agent 运行时 | 驱动模型「思考 → 调工具 → 看结果 → 再思考」循环的程序，以及围绕它的上下文、工具、取消、压缩等机制。也叫 harness | core/agent/orchestrator.py |
| 单循环 / 主循环 | 整个 Agent 就是一个循环：请求模型，模型要调工具就执行并把结果回填，不调了就结束 | 见 01 文档 4.3 节伪代码 |
| Function Calling / Tool Use | 模型按 JSON Schema 输出结构化的工具调用，由程序执行，结果再喂回模型 | 所有工具 |
| 子 agent | 主 agent 把一个子任务交给另一个独立上下文的 agent 去做，只拿回结论，不污染主上下文 | tools/agent_tool.py |
| MCP | Model Context Protocol，Anthropic 2024 年底提出的工具接入标准协议 | 接入企业信息查询服务 |
| Skill | 一个目录 + SKILL.md，写着做某类事情的方法和脚本；平时只露名字，用到时才读全文 | 生成 Word / PPT / Excel / HTML |
| CLI 连接器 | 把飞书、企微、CRM 等外部系统包装成命令行工具，Agent 在沙箱里调用 | lark / wecom / xbb / mes 等 |
| 上下文工程 | 决定每一轮让模型看到什么：放什么、什么时候放、怎么省、怎么隔离 | prompt 分层、按需加载、压缩、子 agent |
| Prompt 缓存 | 供应商缓存请求的公共前缀，命中部分大幅降价、首字更快；前缀变一个字就失效 | 分层 prompt 结构，缓存命中率约 35% → 90% |
| 上下文压缩 | 对话快超出模型窗口时，把旧历史总结成摘要，保留最近几轮 | 下一次请求超窗口 85% 触发 |
| 工具按需加载 | 低频工具平时只给名字不给参数说明，模型搜索后才激活 | deferred + ToolSearch |
| 打转检测 | 发现模型反复用几乎相同的参数调同一个工具，先提醒、再拦截 | 按工具名分桶 + 近似重复判定 |
| Memory 分层 | 不同性质的信息存在不同地方、用不同方式注入 | 见下表 |
| 模型网关层 | 所有模型调用的统一入口，屏蔽供应商差异，集中做限流、计费、重试、兜底、熔断 | core/llm/client.py 的 LLMClient |
| 动态切换 / 热生效 | 模型和参数存在数据库里，配置中心改完下一次请求就生效，不用发版 | AI 配置中心（gateway） |
| SSE | Server-Sent Events，服务端通过一个 HTTP 长连接持续往浏览器推消息，单向 | 对话流式输出 |
| 断线重连重放 | 事件存在 Redis Stream 里，重连时从头读一遍，前端从头渲染 | completion_stream.py |
| 进程内无状态 | 任何需要跨请求保留的状态都放 Redis / PG，不放进程内存，所以任意副本都能处理任意请求 | 多副本部署的前提 |
| 水平扩展 | 加机器 / 加副本来提升处理能力（对比垂直扩展：换更强的机器） | Docker Swarm 多副本 |
| 分级控制（取消 / 停止 / 插话） | 取消 = 整个作废；停止 = 这一轮到此为止，结果保留；插话 = 生成中追加一句，下一轮模型能看到 | 01 文档 5.9 节 |
Memory 分层（简历里那条的展开）
先对上业界通用的说法（简历用的是这套词）：
| 业界术语 | 含义 | 我们对应的记忆 |
|---|---|---|
| 短期记忆（Short-term / Working） | 当前会话里的上下文 | 消息历史、压缩摘要、对话笔记 |
| 长期 · 语义记忆（Semantic） | 事实和知识 | 项目记忆、组织画像、企业经验、知识图谱事实 |
| 长期 · 程序性记忆（Procedural） | 怎么做事的经验和规则 | 工具习惯（工具用法、偏好、资料去向） |
| 长期 · 情景记忆（Episodic） | 过去发生过的具体经历 | 历史会话摘要（我们用得少，可不主动提） |
- Mem0：开源记忆层，核心流程是「对话后用模型抽取候选记忆 → 和已有记忆比对，决定新增 / 更新 / 删除 / 不变 → 检索时按相关性召回」。我们的项目记忆就是这个流程（已有内容变了就更新那一条，不重复新增）。
- LangGraph：把记忆分成线程内的短期记忆（checkpointer）和跨线程的长期记忆（store，按 namespace 隔离），我们按个人 / 组织 / 项目隔离是同一个思路。
- Letta（原 MemGPT）：把上下文窗口当「内存」、外部存储当「硬盘」，由 Agent 自己调工具在两者之间换入换出 —— 对应我们的「工具召回」。
下面是项目里的具体设计：
入层判据（三个问题）：
- 会不会变？ 不变的事实 → 知识图谱；会变的偏好、约定 → 记忆表。
- 需不需要关系查询？ 需要「从 A 走到 B」→ 图谱（这是图唯一不可替代的能力）；只要读出来贴进 prompt → 记忆表。
- 谁写的？ 系统从资料里自动抽取 → 图谱（带置信度、可重新抽取）；用户明说的、Agent 从失败里学的 → 记忆表。
| 记忆 | 内容 | 怎么来 | 怎么注入 | 归属 |
|---|---|---|---|---|
| 工具习惯 | 工具怎么用不出错、同类任务偏好哪个工具、该去哪找资料 | 对话后异步学习；用户也可手动记录 | 偏好常驻；工具用法「目录 + 召回」（第一次用某工具时附上经验目录） | 个人 / 组织 |
| 项目记忆 | 项目里已经说定的决策、事实、约定 | 项目对话每轮结束后异步提取，每次最多 5 条，必须能指到原话 | 目录（最多 15 条摘要）+ 按需展开 | 项目 |
| 组织画像 | 组织是谁（行业、规模、业务） | 管理员填写优先；上传资料后汇总 | 工具召回 | 组织 |
| 企业经验 | 术语、指标口径、流程 | 生成候选，经审核 | 工具召回 | 组织 |
| 事实 | 人、组织、事件及其关系 | 对话后 / 资料上传后抽取到 Neo4j | 工具召回 | 组织 |
三种注入方式：
- 常驻：每次对话都放进 prompt（只放最小、最常用的）；
- 目录 + 召回：先给标题和一句话摘要，模型觉得相关再用工具展开全文（渐进式披露）；
- 工具召回：完全不预先给，模型需要时自己查。
为什么异步：记忆提取要额外调一次模型，放在对话结束后的后台任务里，不让用户等。
安全点：目录里的文字会去掉特殊符号、限制长度，防止一条记忆变成影响其他成员的「指令」（记忆注入攻击）。
三、RAG 与知识
| 词 | 是什么 | 适合 / 注意 |
|---|---|---|
| RAG | Retrieval-Augmented Generation，先检索相关资料，再让模型基于资料回答 | 解决模型不知道企业私有知识、减少幻觉 |
| Agentic RAG | 检索作为一个工具交给 Agent，由模型决定查不查、查几次、换什么关键词 | 比「每次固定先检索一次」灵活；我们用的是这种 |
| 文档解析 | 把 PDF / Office / 音频 / 图片转成文本（markdown） | 难点：表格、扫描件（OCR）、图片里的文字、音频转写 |
| 切分（Chunking） | 把长文档切成小段再向量化 | 太大检索不准，太小丢上下文；常见按标题结构 + 长度切，带重叠 |
| 向量化（Embedding） | 用模型把文本转成一串数字（向量），语义相近的文本向量也相近 | 换 embedding 模型要全量重建索引 |
| 稠密向量检索 | 按语义相似度找（余弦相似度） | 擅长同义表达；不擅长精确匹配（型号、编码、人名） |
| BM25 / 稀疏向量 | 传统关键词检索算法，看词频和逆文档频率 | 擅长精确匹配；不懂同义词 |
| 混合检索 | 两种一起查，再融合排序 | 互补；我们在 Qdrant 里同时存稠密向量和 BM25 稀疏向量 |
| RRF | Reciprocal Rank Fusion，按排名融合：score = Σ 1/(k + 排名)，k 通常取 60 | 不需要两种分数在同一量纲，简单稳健 |
| 重排序（Rerank） | 先粗召回几十条，再用一个更准但更慢的模型对「问题 + 每条结果」逐一打分重排 | 准确率明显提升；成本是多一次模型调用 |
| 权限过滤 | 检索时按 payload 过滤（个人 / 组织 / 项目可见范围） | 必须在检索时过滤，而不是检索后再删（否则可能召回结果全被删光） |
| 知识图谱 | 实体（节点）+ 关系（边）组成的网络，存在 Neo4j | 适合关系类问题（谁负责什么、A 和 B 什么关系） |
| 图谱抽取 | 用模型从文本里抽取实体和关系写入图谱 | 难点：实体去重（同一个人不同叫法） |
| Text2Cypher | 用模型把自然语言问题转成 Cypher 查询语句 | 要限制只读、加超时、加 LIMIT |
| 渐进式披露 | 先给目录 → 再给摘要 → 最后给全文 | 我们的知识库工具就是这三步 |
四、Python 技术栈
| 词 | 是什么 | 项目里 / 适合 |
|---|---|---|
| Flask | 轻量 Python Web 框架，同步（WSGI） | 后端主框架；用应用工厂按 APP_SCOPE 拆三个服务 |
| Flask-RESTX | Flask 上做 REST API + 自动生成 Swagger 文档 | 接口定义 |
| Gunicorn | Python 的 WSGI 服务器，多进程 | 生产部署，配 gevent worker |
| gevent | 协程库，通过 monkey-patch 把阻塞 IO 变成协作式切换，同步代码也能高并发 | 大量 IO（等模型、等网络）用它扛并发 |
| SQLAlchemy 2.x | Python 最主流的 ORM，也可以写原生 SQL | 所有 PG 访问 |
| Alembic | SQLAlchemy 的数据库迁移工具（类似 Java 的 Flyway / Liquibase） | 所有表结构变更 |
| Celery | 分布式异步任务队列 | 文档解析、记忆提取、定时任务 |
| Pydantic | 运行时数据校验 | 模型 / 工具配置定义，配置错了启动就报错 |
| uv | 新一代 Python 包管理器，Rust 写的，非常快 | 依赖管理 + 锁版本 |
| asyncio | Python 标准库的异步框架（async / await） | FastAPI 的基础 |
| FastAPI | 异步 Web 框架，基于 Starlette + Pydantic | 见 03 文档 |
| ruff | Rust 写的 Python 代码检查和格式化工具 | 提交前检查 |
五、存储
| 词 | 是什么 | 项目里 / 适合 |
|---|---|---|
| PostgreSQL | 功能最全的开源关系数据库 | 所有业务数据 |
| jsonb | PG 的二进制 JSON 类型，可建索引 | 卡片状态、运行日志、AI 配置；适合字段经常变、结构不固定的数据 |
| Redis Stream | Redis 的持久化消息流，有 ID、可回放、支持消费者组 | 对话事件流 |
| Redis ZSet | 有序集合，按分数排序 | 滑动窗口限流、并发信号量、定时任务调度 |
| Lua 脚本 | 在 Redis 里原子执行一段逻辑 | 限流的「判断 + 写入」必须原子 |
| 分布式锁 | 多个进程 / 机器之间互斥 | SET NX PX + Lua 释放 |
| Qdrant | Rust 写的向量数据库，支持稠密 + 稀疏向量、payload 过滤 | 文档片段、图谱节点的向量检索 |
| Neo4j | 图数据库，查询语言 Cypher | 知识图谱 |
| MySQL | 老本行 | 见 02 文档 |
| Elasticsearch | 基于倒排索引的搜索引擎 | 旧项目里分担 MySQL 的全文搜索压力 |
六、Java 技术栈（旧项目）
| 词 | 是什么 | 适合 / 你的经历 |
|---|---|---|
| Spring Boot | 约定优于配置的 Spring 快速开发框架，自动配置 + 内嵌容器 | 所有 Java 项目 |
| Spring Cloud | 微服务全家桶 | 内容服务平台、采编平台 |
| Nacos | 阿里开源的注册中心 + 配置中心 | 服务发现、配置热更新 |
| OpenFeign | 声明式 HTTP 客户端，写个接口加注解就能调远程服务 | 服务间调用 |
| Spring Cloud Gateway | 微服务网关：路由、鉴权、限流 | 统一入口 |
| MyBatis Plus | MyBatis 增强，内置通用 CRUD、分页、条件构造器 | DAO 层 |
| ruoyi（若依） | 国内流行的开源后台管理脚手架（权限、菜单、代码生成） | 采编平台基于它搭建 |
| Redisson | Redis 的 Java 客户端，提供分布式锁（看门狗续期）、分布式集合等 | 内容服务平台 |
| JetCache | 阿里开源的缓存框架，支持本地 + 远程两级缓存、注解式 | 采编平台替换 Redisson 做缓存（准备好当时遇到的具体问题） |
| JVM 调优 | 调整堆大小、GC 收集器和参数，排查内存泄漏 / 频繁 GC | 准备一个完整案例：现象 → 工具（jstat / jmap / MAT / arthas）→ 原因 → 调整 → 效果 |
| JMM | Java 内存模型：主内存 / 工作内存、happens-before、volatile 语义 | 并发八股 |
七、中间件与数据同步
| 词 | 是什么 | 适合 / 你的经历 |
|---|---|---|
| Kafka | 分布式消息队列，高吞吐、持久化、分区有序 | 采编平台数据转发、数据服务平台 |
| Canal | 阿里开源，伪装成 MySQL 从库读 binlog，实现数据变更订阅 | 数据服务平台接入 MySQL 数据源 |
| Debezium | 开源 CDC（变更数据捕获）工具，支持 MySQL / PG 等多种数据库，通常跑在 Kafka Connect 上 | 数据服务平台接入其他数据源 |
| CDC | Change Data Capture，捕获数据库的增删改并实时同步到下游 | 数据同步、缓存更新、搜索索引同步 |
| Nginx | 反向代理、负载均衡、静态资源 | 旧项目 |
| HAProxy | 高性能 TCP / HTTP 负载均衡 | 现项目按路径分流到三个服务，按用户做粘性 |
八、工程与部署
| 词 | 是什么 | 项目里 |
|---|---|---|
| Docker | 容器化，把应用和依赖打包成镜像 | 所有服务 |
| buildx 多架构构建 | 一次构建同时产出 amd64 和 arm64 镜像 | 客户服务器架构不一 |
| Docker Swarm | Docker 自带的容器编排，比 K8s 轻量 | 生产集群，docker stack deploy |
| 滚动发布 | 逐个替换旧容器；start-first = 新容器起来后再停旧的，零中断 | 每次发版 |
| Kubernetes | 主流容器编排平台 | 旧项目 |
| Jenkins | CI/CD 流水线 | 旧项目 |
| Prometheus + Grafana | 指标采集 + 可视化看板 + 告警 | 旧项目的服务监控 |
| Claude Code / Codex | AI 编程助手 | 日常开发 |
被问「为什么用 Swarm 不用 K8s」：服务数量少、团队小，Swarm 用 compose 文件就能部署，学习和运维成本低；滚动发布、多副本、服务发现这些需要的能力它都有。规模上来、需要自动扩缩容和更复杂的调度再上 K8s。
九、前端（全栈部分，入门八股见 06 文档）
| 词 | 是什么 | 项目里 |
|---|---|---|
| React | 组件化的前端 UI 库 | 三个前端都基于它 |
| Next.js | React 的全栈框架，支持服务端渲染、文件路由、API 路由 | 产品前端、运营后台、AI 配置中心 |
| Tailwind CSS | 原子化 CSS，直接在 class 里写样式 | 运营后台、AI 配置中心 |
| antd | 蚂蚁的 React 组件库 | 产品前端 |
| TypeScript | 带类型的 JavaScript | 所有前端 |
十、旧项目里的概念
| 词 | 是什么 | 适合 / 注意 |
|---|---|---|
| BPMN | 业务流程建模标准，用图描述流程（开始、任务、网关、结束），引擎（Camunda / Flowable）按图执行 | 智能助手平台用来编排大模型应用流程；适合审批流、固定业务流 |
| 可插拔组件 | 每个能力做成符合统一接口的组件，按需组合 | 见设计模式第 10 条 |
| JSON Schema | 用 JSON 描述 JSON 数据结构的标准（字段类型、必填、取值范围） | 采编平台用它适配多变的内容结构；大模型的 function calling 参数定义用的也是 JSON Schema，可以借这个点把老经验和 AI 联系起来 |
| SSO 单点登录 | 一次登录访问多个系统（CAS、OAuth2、OIDC） | 采编平台；现项目的 OEM 合作方也走 SSO |
| RBAC 权限系统 | 用户 → 角色 → 权限 | 采编平台新增的权限系统 |
| 物理多租户 vs 逻辑多租户 | 物理：每个租户一套库 / 表，隔离好但冗余大、扩容难；逻辑：所有租户共用表，用 tenant_id 区分 | 内容服务平台从物理改逻辑；现项目也是逻辑多租户（按组织 / 用户过滤） |
| 规则引擎 | 把业务规则从代码里抽出来变成可配置的规则（条件 → 动作） | 内容服务平台自研的轻量规则引擎；对应现在的「配置中心热生效」思路 |
| VuePress | Vue 驱动的静态站点生成器 | 个人博客 |
| Cloudflare | CDN + DNS + 安全代理 | 博客代理 |