【三年面试五年模拟】2026-09-16 字节跳动 Agent 秋招一面全解析：从 Harness、记忆与并发到算法题的系统化解析

写在前面

欢迎大家关注Rocky的公众号：WeThinkIn

欢迎大家关注Rocky的知乎：Rocky Ding

《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源：【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book，欢迎大家Star～

Rocky最新撰写的10万字AI Agent（AI智能体）深入浅出全维度解析文章： 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

AIGC/LLM/AI Agent算法岗/开发岗求职面试内推学习社群 （涵盖AIGC、LLM大模型、AI Agent、传统深度学习、自动驾驶、机器学习、计算机视觉、自然语言处理、强化学习、大数据挖掘、具身智能、元宇宙、AGI等AI行业最新面试干货经验与核心知识）欢迎大家加入：https://t.zsxq.com/33pJ0

大家好，我是Rocky。

核心导读

这份面经表面上覆盖项目深挖、数据库、算法和反问，主线却非常集中：面试官持续追问 Agent 如何从"能调用模型"走向"可恢复、可验证、可控制的工程系统"。问题先从企业 AI 助手的会话记忆、文档自动更新和 RocketMQ 链路切入，再延伸到 Agent Harness、Computer Use、AI Coding 工作流，最后用数据库索引、二叉树子结构和无限序列求交检查基础功底。

阅读时可以抓住一个统一判断：模型负责在上下文中提出下一步决策，Harness 负责提供状态、工具、权限、资源和验收边界。 滑动窗口与摘要压缩解决输入预算，版本号与 CAS 解决异步更新，队列与背压解决吞吐，执行循环决定如何根据工具结果推进任务，确定性验证器则负责判断是否真的完成。后面的数据库和算法题，考察的是同样的工程习惯------先定义语义和边界，再给出复杂度、失败模式与可验证实现。

准备这 30 个问题时，需要把设计方法与个人经历分开：架构可以讨论不同方案，项目贡献、上线指标和工具使用经历则应给出真实证据。

面试主线：从模型调用到可靠执行

Agent 岗位的一面往往不满足于"知道几个框架名词"。面试官需要确认候选人能否把模型输出接入真实业务：上下文是否超预算，工具是否越权或重复产生副作用，异步任务是否乱序覆盖，长任务是否可以恢复，Computer Use 是否有执行后验收，以及算法实现能否处理极端输入。

因此，回答不能停留在概念定义。一个完整答案至少要交代四件事：任务和成功标准是什么；系统由哪些确定性边界与概率性决策组成；异常、并发和资源限制如何处理；最后用什么日志、测试或业务状态证明结果。后文的每个回答都沿着这个框架展开。

核心思路：把 Agent 看成受约束的执行闭环

可以把整场面试压缩成下面这条链路：

text 复制代码

目标与权限 -> Context Builder -> 模型决策 -> 工具/环境执行
      -> Observation 与状态更新 -> 验证器 -> 继续、重试、重规划或人工接管

上下文不是无限聊天记录，而是按预算投影出的工作视图；记忆不是向量库里的"永久真相"，而是带作用域、来源和时效的可纠正状态；并发不是启动更多协程，而是在模型配额、下游容量、延迟和成本约束下分配资源。只要坚持"外部状态可恢复、动作受策略控制、完成由事实验收"，不同框架和产品的差异就能落到可测指标上。

项目

实习项目拷打

回答：

实习项目深挖的核心，是证明自己理解了系统为什么这样设计，并能用证据界定个人贡献。围绕企业 AI 助手，可以按"业务目标、执行链路、个人负责模块、困难与取舍、验证结果"展开。没有真实经历或测量数据的部分，应明确属于设计方案或实验观察，不能编成上线成绩。

首先明确用户与任务：服务谁，解决查知识、查业务状态还是执行业务操作的问题；哪些请求需要 RAG，哪些需要调用确定性业务接口。随后解释链路：鉴权与租户识别、上下文组装、检索或工具路由、工具执行、结果校验、响应与审计。文档更新是独立的数据管道，需要解释如何把更新后的文档版本稳定提供给在线问答。

个人贡献应落在可追问的模块上。例如，会话状态如何保存，摘要何时触发，文档事件怎样去重，旧任务怎样防止覆盖新版本，工具失败怎样恢复。每个设计都说明替代方案及代价：固定轮数为何不够，分布式锁为何不能独自保证正确性，为什么采用异步更新，以及异步带来多长的可见性延迟。

评估需要基线、固定样本集和故障样本。知识问答看答案正确性、引用支持率和权限隔离；执行任务看真实业务完成率、重复副作用、恢复率；系统看 P95 延迟、每次成功任务成本和索引更新延迟。线上观测与离线实验分别报告，并标明样本量和测试条件。长任务还应保存 checkpoint、工具回执和未完成步骤，支持取消、回放与恢复。

企业 AI 助手项目中，基于滑动窗口和摘要压缩的会话记忆是怎么实现的？

回答：

把会话记忆设计成可恢复的任务状态，而不是不断拼接的聊天字符串。 一个实用结构由近期完整消息、结构化摘要和外部历史存储组成：近期完整消息保留指代与工具交互细节；摘要保留目标、硬约束、已确认事实、关键决策和待办；历史消息与大型产物保存在外部，需要时按权限回读。

每条消息记录 session_id、message_id、seq、role、tool_call_id、token_count。摘要记录 summary_version、covered_until_seq、facts、constraints、decisions、pending_tasks、evidence_ids。原始日志追加保存；摘要是日志的派生视图，不能成为事实的唯一存储。

每次请求先计算上下文预算，预留生成与工具返回空间，再装入固定指令、当前请求、状态摘要、相关证据和近期消息。其预算约束为：

T f i x e d + T s u m m a r y + T r e c e n t + T e v i d e n c e + T o u t p u t + T r e s e r v e ≤ C . T_{\mathrm{fixed}}+T_{\mathrm{summary}}+T_{\mathrm{recent}}+T_{\mathrm{evidence}}+T_{\mathrm{output}}+T_{\mathrm{reserve}}\le C. Tfixed+Tsummary+Trecent+Tevidence+Toutput+Treserve≤C.

其中 C C C 是当前模型的上下文上限。工具定义、图片等也需要计入实际输入预算，不能只数聊天文字。

接近预算时，选择已经结束的消息段压缩；不能把工具调用和对应结果截成不合法的消息序列。基于旧摘要与新增历史生成新摘要，对数字、实体、否定条件、权限和待办做校验。提交时用摘要版本与覆盖序号做 CAS，若另一个任务已经提交新版本，则重新读取并合并，防止较旧摘要覆盖较新状态。并发会话写入还需明确串行化或分支语义。

摘要保存证据指针，大型日志与文件只保留有意义的摘录及引用。RAG、工具描述和历史消息共享预算；过量工具输出应通过分页、字段投影、去重和产物引用治理。任务跨阶段时写入 checkpoint，用户撤销授权或修改目标时更新结构化状态，不能让旧摘要覆盖最新指令。

图 1：原始日志、结构化摘要和近期消息承担不同职责。模型看到的是预算内的工作视图；任务恢复和事实核对仍要依赖可回读的持久记录。

验证至少包含长对话回放、事实冲突、压缩后继续调用工具、并发摘要和会话恢复。记录事实保真率、任务成功率、约束违反率、Token 消耗与压缩延迟。压缩率只有结合后续任务表现才有意义。

3.1 滑动窗口大小是怎么确定的，大概设置多少轮？

回答：

应以 Token 预算为硬约束，以轮数作为便于理解的辅助参数。一次用户问答可能只有几十个 Token，也可能包含数万 Token 的日志和多个工具结果，固定"保留十轮"无法稳定限制开销。

先扣除固定指令、工具定义、摘要、证据、输出预算与安全余量，得到近期历史预算。倒序装入完整交互单元，达到预算即停止；若最近一轮本身超限，需压缩工具输出或提取文件片段，不能简单丢掉当前任务。

可以把最近 4、8、12 轮作为离线消融的候选起点，但这些是实验配置，不是业界标准或项目实测值。对短咨询、长任务、代码调试分别评测指代正确率、任务成功率、关键约束保留率、P95 延迟与费用，选择满足质量目标的最小有效窗口。对于必须逐字比较的代码或合同条款，应按任务显式保留，而不是寄希望于"多留几轮"。

自动压缩可采用高低水位：达到高水位触发，压缩到较低目标，给下一轮工具返回留空间，避免连续抖动。水位也需要随模型、输出长度和业务风险校准。

3.2 哪些场景适合滑动窗口，哪些场景更适合直接通过摘要进行上下文压缩？

回答：

滑动窗口适合依赖最近几轮的局部任务，例如补齐表单、确认订单条件、连续修改一段代码和定位当前报错。它保留完整消息，语义损失小，但早期目标容易滑出窗口，长工具结果也会迅速占满预算。

摘要适合跨阶段、持续时间长的任务，例如多天排障、长报告研究、需求逐步收敛和多次工具执行。已完成探索可以收敛为结论、证据与待办，减少重复阅读。风险是摘要会漏掉否定、边界条件和精确数值，多次摘要还可能累积漂移。

生产系统通常采用组合方案：长期目标与硬约束独立保存，历史阶段用摘要，近期交互用完整消息，精确证据按需检索。对代码补丁、法律条款、财务数据、签名回执等内容，应保留可恢复原件与定位信息，摘要仅承担导航作用。纯滑窗和纯摘要各自都有信息盲区。

文档在线自动更新时，如何保证并发更新的幂等性，避免多个任务相互覆盖？

回答：

先区分两个问题：幂等性解决同一更新重复执行；版本控制解决不同更新乱序完成。 仅给任务加 Redis 锁，或者认为 MQ 不重复投递，都不足以保证最终文档正确。

更新事件携带租户、文档 ID、单调版本、事件 ID、内容哈希与处理流水线版本。用数据库唯一约束去重逻辑任务，例如 (tenant_id, doc_id, source_version, pipeline_version)。同一任务被重复投递时返回已有结果或恢复未完成步骤。内容哈希可判断内容相同，但不能直接当作可比较的新旧版本。

索引采用不可变代次：先为某一文档版本构建完整的切片、向量和关键词索引，校验成功后切换 active_generation。分块 ID 带代次，不能让任务边算边覆盖在线索引。在线查询固定读取一个代次，并在读路径执行权限检查。

发布通过数据库条件更新实现原子比较。下面示例假定 source_version 单调递增，且候选代次已经构建完毕：

sql 复制代码

UPDATE document_head
SET source_version = :candidate_version,
    active_generation = :ready_generation
WHERE tenant_id = :tenant_id
  AND doc_id = :doc_id
  AND source_version < :candidate_version;

影响行数为零时，读取当前状态，判断是重复发布还是已被新版本替代。若上游提供的是不可排序的 ETag，应在接入侧建立修订序号或按预期版本 CAS，不能对 ETag 做大小比较。不同模型/切片配置的重建还需独立的部署代次，不能只依赖文档版本判断。

文档状态变化与事件写入采用同一数据库事务的 outbox，或采用有事务回查的 RocketMQ 事务消息，解决"库已改但消息未发"的双写问题。消费者在业务状态持久化后确认消息；崩溃后允许重放，处理函数必须幂等。对外部副作用使用对方支持的幂等键，或建立执行记录与补偿流程。

图 2：候选索引构建完成后才参与发布竞争。即使 v11 比 v12 更晚完成，也不能覆盖已经发布的 v12；重复消息与不同版本乱序需要分别处理。

故障测试要包含：旧版本慢任务最后完成、消息重复、发布后确认前宕机、建索引中途失败、删除事件与更新乱序、租约过期后旧 worker 继续运行。删除也需要版本化墓碑；否则迟到更新可能把已删除文档复活。锁可以减少重复工作，CAS、版本与可恢复提交负责保证正确性。

4.1 RocketMQ 在文档自动更新链路中的哪个位置？

回答：

RocketMQ 位于"发现并持久化文档变化"与"执行耗时索引构建"之间。典型链路为：

text 复制代码

定时扫描 / Webhook / CDC
  -> 文档修订记录 + outbox
  -> outbox relay -> RocketMQ
  -> 消费者领取逻辑任务
  -> 拉取指定版本 -> 解析 -> 切片 -> Embedding / 关键词索引
  -> 校验候选代次 -> 原子发布指针 -> 确认消息

消息传文档 ID、版本、对象引用和 trace ID，通常不直接携带整份大文档。消费者必须取得事件指定的版本；如果只抓"当前最新内容"，却沿用旧事件的版本号，会把版本与正文对应关系弄错。

同一文档可以按 message group 做有序消费，减少版本竞争；不同文档并行处理。但不同消费者配置、重试、服务重启和下游并行阶段仍需版本校验，有序消息不能代替业务 CAS。失败处理包括有限重试、死信、人工恢复和可观测告警，重试不应无上限重复消耗 Embedding 配额。

4.2 为什么文档更新这里考虑使用 MQ，而不是直接在定时任务中处理？

回答：

定时任务适合发现变化，MQ 适合承接独立、耗时、可重试的异步工作。文档解析、Embedding 和索引写入耗时波动大，全部塞进扫描任务会使一次慢文档拖住后续扫描，部署重启也容易丢失进度。

MQ 带来的价值是持久化积压、削峰、消费者扩缩容、失败重试和生产消费解耦。扫描周期与处理时长可以分别控制，下游限流时通过消费者并发和背压稳定吞吐。需要同时监控积压数量、最老消息年龄、更新可见性延迟和失败率，仅看消费吞吐不能发现一直重试的旧文档。

代价是最终一致性、重复投递、乱序、运维和问题定位复杂度。低流量、任务很短、允许简单重跑的场景，数据库任务表配合定时 worker 就足够。选 MQ 应来自吞吐、可靠性与故障隔离需求，而不是架构层数越多越好。

你对业界其他 Agent / Agent Harness 有哪些了解？

回答：

Agent Harness 是模型之外负责执行的运行时：组装上下文、调度模型和工具、管理状态、处理取消与恢复、控制预算和权限、验证结果并记录轨迹。它和模型权重、单个 Prompt、工具协议处于不同层次。

可以按产品和架构比较：Claude Code 提供面向开发任务的完整执行环境；Pi 强调小而可扩展的终端编程 Harness；DeepSeek Harness 通过 Cordis 把模型适配、工具、会话和执行循环组织为插件；状态图类框架则更适合显式描述工作流节点和条件转移。MCP 提供工具与资源连接能力，但接入 MCP 本身并不自动完成任务编排与可靠性治理。

考察任何方案都应问清六件事：模型看到的上下文怎样生成；工具如何鉴权、校验和重试；任务状态怎样持久化；超时与用户取消怎样传播；结果怎样验证；故障怎样回放。生产系统还要限制并发、步数和费用，区分可重试读取与有副作用写入。

同一个模型换上不同 Harness，完成率和成本可能明显不同。 比较时应固定任务集、模型与工具权限，观察成功率、P95 延迟、每次成功任务成本、恢复能力和维护成本，避免把模型升级收益误记成框架收益。

5.1 展开介绍一下你了解的 DeepSeek Harness 和 Pi Agent。

回答：

DeepSeek Harness。 官方项目使用 dsh 名称，核心理念是 "Everything is a Plugin"，底层采用 Cordis。模型适配器、工具注册、会话日志乃至 Agent 循环本身都通过插件提供能力；插件通过共享上下文、类型化事件与生命周期机制协作。架构目标是把替换能力和扩展策略放在明确的组合点上，减少业务直接修改执行循环。

它的会话日志保存持久事件，运行时从日志派生模型历史；工具执行有执行前、执行中和执行后的扩展位置。工程上可以在这些位置接入工具策略、审计、遥测与模型路由。插件卸载时撤销注册或清理资源，不等于撤销已经发生的数据库写入、文件操作或外部业务交易，业务副作用仍需自己的补偿机制。

Pi Agent。 Pi 将自己定位为精简的终端 Coding Harness，默认核心工具包含 read、write、edit、bash，通过 TypeScript 扩展、Skills、Prompt Templates 等接入更多能力，并支持交互、程序调用与嵌入方式。它的价值是保留清楚的执行循环，让业务按需扩展；不能把第三方扩展具有的能力都描述为默认内置。

Pi 的上下文压缩是可检查的具体机制：在预算不足或手动触发时选择历史边界，生成结构化摘要，追加 CompactionEntry，使用 firstKeptEntryId 标识保留消息的起点。后续请求由摘要和保留的历史构造，原始会话日志不等于被物理删除；分支导航还可以生成分支摘要。具体阈值属于可配置、随版本变化的实现细节。

两者都能围绕"模型请求、工具执行、状态更新"的循环扩展。DeepSeek Harness 更突出可替换的插件组合与事件体系，Pi 更突出精简默认能力和工作流扩展。DeepSeek Harness 公开标注为 developer preview，选型时要固定版本、评估兼容性和迁移成本，不能因为官方开源就推断已经满足企业生产要求。

5.2 如果把这些 Harness 和你实习中的 Agent 项目结合，你会怎么做？是否有必要替换当前方案？

回答：

首先定位现有系统的瓶颈：是模型能力、检索质量、工具接口，还是执行状态不可恢复、上下文管理混乱、扩展成本过高。只有后几类问题直接属于 Harness 的主要职责。

接入采用适配方式：企业身份与权限、知识库和消息队列保留独立服务边界，把业务查询、文档读取和受控操作包装为稳定工具；Harness 负责上下文与执行循环。原有 tracing、预算、取消、审计与评测接到扩展点，避免让某个框架专有对象成为业务数据库的核心数据模型。

先选择低风险只读任务做离线回放，再在小流量场景灰度。固定模型、任务、工具和预算，对比任务成功率、工具错误、P95 延迟、成本、摘要后续接成功率与恢复时间。检查状态迁移、多租户隔离、模型供应商切换和框架升级是否可控。

如果现有方案任务边界清楚、运行稳定、扩展成本低，可以只吸收摘要、事件日志和工具中间件等设计。若框架确实能减少大量自建运行时维护，并在相同约束下提升指标，再逐模块替换。替换必须有回退路径，不能同时更换模型、检索、工具和 Harness 后再声称某一项带来了收益。

除了开源 Agent，你是否调研或使用过其他厂商的 Agent 产品？

回答：

应把"实际使用""读过公开文档""仅做过概念验证"分开说明。可以选择 Claude Code、IDE 内的 Agent 功能、企业流程平台或 Computer Use 产品作为案例，但只报告自己能展示的使用证据。

技术比较围绕完整执行链路：产品能读取哪些工作区内容；工具和权限如何配置；长任务怎样保留状态；失败后能否恢复；是否能用真实结果验收；数据是否出域；成本与并发限制如何影响业务。演示体验好不等于适合长期无人值守任务。

回答时拿同一任务作为对照，例如修复一个可复现的接口缺陷：是否主动定位依赖、补充关键测试、识别错误假设、限制改动范围、报告验证结果。避免只列产品名和个人喜好，把产品判断落到可重复的任务表现上。

6.1 介绍一下你了解的 Claude Code 上下文压缩机制。

回答：

公开说明中的核心行为是：接近上下文上限时管理历史内容，先清理较旧工具输出，再按需要总结对话；用户也可用 /compact 主动压缩并指定重点。/context 可以帮助观察空间占用。具体触发阈值和保留策略会变化，不应把某个历史版本的百分比说成永久契约。

压缩后的工作上下文保留摘要及需要继续执行的信息，降低旧消息对预算的占用。它是有损处理：早期细节和指令可能丢失，所以持久规则应写入 CLAUDE.md，任务状态、重要产物与证据应落盘。摘要并不等于长期记忆，也不等于把模型的 KV Cache 无损编码成更短文本。

需要区分三个机制：对话压缩改变下一次请求的内容；Prompt Caching 复用相同前缀的处理结果；模型内部 KV Cache 保存注意力计算所需的键和值。缓存命中不减少任务在逻辑上需要携带的信息，摘要则可能改变信息量与语义。

实际使用中，在阶段完成时记录目标、已验证结果、未完成项、文件位置、约束和下一步，再压缩；恢复后先检查关键状态。Skills 的按需加载和子任务上下文隔离也可以控制占用。公开文档只能支持公开行为的结论，不应把自己设计的摘要 Schema 当成 Claude Code 未公开的内部实现。

介绍一下你对 Computer Use 的了解情况。

回答：

Computer Use 让 Agent 通过屏幕观察和鼠标、键盘等动作操作已有图形界面。它适合缺少稳定 API 的桌面应用、跨应用工作流和部分旧系统。核心闭环是"观察界面、生成动作、执行、观察变化、验证目标"，模型负责提出动作，执行器负责把动作映射为真实系统操作。

图像中的按钮、坐标和文本是环境状态，不是可信指令。网页、邮件或图片可能包含诱导操作的内容，因此运行时需要限制权限、域名、文件范围和高风险动作，并记录轨迹以支持复核。

如果存在稳定 API、浏览器 DOM 或可访问性树，应优先使用可结构化定位和校验的接口；视觉交互作为必要补充。Computer Use 对窗口焦点、缩放、遮挡、异步加载和界面变化敏感，一次点击成功也不代表业务目标完成。

评估关注端到端任务完成率、动作错误率、恢复成功率、步数、延迟和成本。例如提交表单后，应检查服务端记录或可信回执，不能只凭模型说"已完成"。对于外部提交、付款和权限修改，应将确认放在执行前的确定性控制层。

7.1 Computer Use 操作本地电脑的大致实现机制是什么？

回答：

本地运行执行器，模型可以在本地或远端推理。执行器采集屏幕截图，也可读取可访问性树或应用状态；模型返回点击、输入、滚动、按键等结构化动作；执行器校验动作、坐标和权限后调用操作系统接口，再将新观察返回模型。

需要明确截图坐标与实际屏幕坐标的关系。若截图经过裁剪和缩放，则：

x s c r e e n = x 0 + x i m a g e W c r o p W i m a g e , y s c r e e n = y 0 + y i m a g e H c r o p H i m a g e . x_{\mathrm{screen}}=x_0+x_{\mathrm{image}}\frac{W_{\mathrm{crop}}}{W_{\mathrm{image}}},\qquad y_{\mathrm{screen}}=y_0+y_{\mathrm{image}}\frac{H_{\mathrm{crop}}}{H_{\mathrm{image}}}. xscreen=x0+ximageWimageWcrop,yscreen=y0+yimageHimageHcrop.

其中 ( x 0 , y 0 ) (x_0,y_0) (x0,y0) 是裁剪区域起点。还要处理 Retina/DPI、多显示器、窗口移动与缩放；屏幕状态改变后，旧截图中的坐标可能失效。

执行控制包括前台窗口确认、等待界面稳定、动作超时、步数预算、取消、重复操作检测和执行后验证。读取截图失败与点击超时不能同样重试，后者可能已经发生副作用。敏感动作应先读回状态，再决定是否重试。

macOS 通常涉及屏幕录制与辅助功能权限；其他系统使用各自的桌面自动化接口。凭据应由受控机制管理，截图和日志需考虑隐私。当地运行电脑并不意味着截图和文件不会发到远端，数据流向取决于推理与工具配置。

7.2 是否了解操作本地电脑和操作云端电脑两种方案？

回答：

两者主要区别是受控桌面的执行位置，不能与模型推理的位置混为一谈。

维度	本地电脑	云端或远程隔离桌面
可访问资源	用户本地文件、已登录应用、设备	预装应用、专用账号、显式挂载数据
运行状态	容易受用户抢焦点、休眠影响	环境更统一，可快照、重置和扩容
风险边界	误操作可能影响真实工作区	隔离更容易，但仍需防凭据泄露和越权
主要成本	终端适配与权限管理	虚拟机、会话维护、网络和并发成本
典型用途	个人工作流、本地专有应用	批量网页任务、自动化测试、可复现流程

云端桌面并不天然安全：共享账号、多租户状态残留、长期有效 cookie 和开放网络仍会带来风险。本地方案也可以使用独立用户、容器或虚拟机限制影响范围。

可以采用混合设计：控制平面统一管理任务和审计，本地或远端执行器只领取受限任务；文件按最小范围提供，模型只接收必要观察。选型依据应包括应用可用性、数据合规、交互稳定性、成本与恢复需求。

平时使用 AI Coding 工具开发时，遇到过哪些问题？

回答：

常见问题要连同定位和修复方式一起讲。以下是可以用真实项目替换的类别，不能把它们当作已经发生过的个人经历。

需求与上下文偏差。 模型可能只修表面报错，忽略调用方契约，或者读到旧接口说明。解决方法是先复现、确认验收条件、检查依赖与版本，再让工具基于实际仓库工作；长期约束写入项目说明，恢复会话后复核关键状态。

代码与依赖幻觉。 生成不存在的 API、错误的异步处理或过时配置。以已安装版本的类型定义、官方文档和可执行验证为准。避免仅通过静态阅读认定"看起来可以"。

验证盲区。 模型可能同时写出错误实现和迎合实现的测试，或用过度 mock 隐藏真实故障。测试应来自独立业务契约，关键算法使用参考实现或穷举对照，集成行为以真实依赖或合适的测试环境验证。

改动范围失控与并发冲突。 自动格式化、依赖升级或多 Agent 同时修改共享文件会扩大风险。用明确模块边界、独立工作区、提交差异审查和集成责任人控制变化。

长任务漂移与执行失败。 摘要丢约束、反复试同一命令、工具成功被误当成任务成功。为任务保存状态、失败记录和下一步，设置重试与总预算，并用业务验收判断结束。所有指标都应落到交付周期、缺陷与回归，不能只统计生成了多少代码。

你平时使用 AI Coding 工具的完整开发工作流是什么？

回答：

可以把流程组织成"明确目标、建立证据、受控实现、独立验证、持续反馈"，并用一个真实任务串联。下面是一套可落地的流程，而非对个人经历的代写。

明确输入输出、边界条件和验收标准，检查数据权限、部署约束与已有变更。缺陷先获得最小复现，需求先确认可观察的成功条件。
让 Agent 阅读目录、项目约定、相关模块、依赖版本与已有测试，形成影响范围。对复杂任务写出短计划和待验证假设；小改动不强行增加流程。
在独立分支或工作区中按小步骤实现。将相关文件、接口契约和失败日志提供给 Agent；有依赖的步骤顺序执行，独立调研或模块实现才并行。
按风险验证：语法和类型检查、针对性单测、必要集成测试、真实场景回放。关键算法用独立 oracle，界面用浏览器检查；测试通过之后仍查看代码差异、错误路径和边界。
由开发者确认数据迁移、权限、幂等、性能和依赖风险。发布按团队流程灰度、观测并保留回滚条件，结果回读而不是只看命令退出码。
把反复出现的规范、故障处理和验证命令沉淀为项目说明、自动化检查或 Skills，修复根因后再扩展自动执行范围。

衡量流程看需求到验收的时长、一次通过率、返工率、线上缺陷与人工接管次数。AI 可以承担更多执行工作，工程师仍需对问题定义、验证质量和交付负责。

八股

常见数据库有哪些类型？不同类型数据库之间有什么区别？

回答：

分类应区分数据模型、存储布局和查询负载，它们不是互斥维度。同一系统可以提供关系模型、列式分析和向量检索，不能仅靠"NoSQL/SQL"判断事务或一致性能力。

类型或侧重	主要数据与访问方式	典型适用任务	核心取舍
关系型数据库	表、约束、连接与事务	订单、账户、权限、业务状态	灵活查询与事务能力，扩展需结合分区和复制
键值存储	按 key 查询对象或值	缓存、会话、限流状态	访问简单，复杂关联通常由应用处理
文档数据库	JSON 类层次文档	结构多变的内容和应用对象	模型灵活，但跨文档约束需设计
宽列数据库	分区键、聚簇键与稀疏列	大规模按键访问和写入	需围绕查询预先设计键和数据冗余
列式分析数据库	按列组织、批量扫描与聚合	OLAP 报表和事件分析	压缩与扫描高效，小事务点更新未必占优
图数据库	点、边与路径遍历	多跳关系、风控关联	适合图查询，分布式遍历成本要评估
时序数据库	时间索引、保留策略和窗口聚合	指标、监控、设备数据	时间分区与压缩有优势，通用事务能力各异
检索与向量系统	倒排索引或近邻索引	全文搜索、语义召回	排序和近似召回能力，事务不应一概而论

宽列模型不等于分析型列式存储；Redis 等键值系统也可以提供丰富数据结构；向量能力既可以来自专用系统，也可以来自关系库扩展。对每种产品应具体检查一致性、事务范围、索引和故障恢复。

Agent 系统通常让关系库保存权威业务状态，缓存加速访问，检索系统保存可重建索引，对象存储保存大型产物。即使多个系统保存同一文档的不同表示，也必须明确谁是事实源、怎样同步版本和权限。CAP 描述网络分区时一致性与可用性的取舍，并不是给数据库贴"永久只能选两个"的标签。

MySQL 底层索引使用什么数据结构？

回答：

准确说法是：常用 InnoDB 普通索引和唯一索引采用 B+ 树结构；MySQL 的全部索引并非都只有这一种结构。 全文索引、空间索引和其他存储引擎的索引需要分别讨论；InnoDB 的自适应哈希索引也不等于把用户创建的 B+ 树索引替换成了哈希索引。

InnoDB 聚簇索引叶子保存完整记录，通常以主键组织；没有合适显式主键时，引擎按规则选择其他键或生成隐藏键。二级索引叶子保存二级索引键与聚簇键，查询非覆盖列时可能需要再查聚簇索引，称为回表。

复合索引按键元组排序，因此前导列约束会影响能否有效定位范围。覆盖索引可以减少回表；主键越宽，二级索引通常也越大。索引增加读效率，同时带来写入、页分裂、维护和存储成本，不能对每列都盲目建索引。

2.1 为什么 MySQL 索引使用 B+ 树，而不是其他树结构？

回答：

B+ 树适合基于页的持久化存储：内部节点集中保存分隔键和子页引用，扇出大、树高低；叶子按键有序并相连，既支持等值查找，也方便范围扫描和排序访问。

若扇出为 f f f、记录量为 N N N，高度可粗略理解为：

h = O ( log ⁡ f N ) . h=O(\log_f N). h=O(logfN).

这只是结构估算。实际页数还受键宽、叶子容量、填充率和页大小影响；根页及上层页可能已在 Buffer Pool，树高不能直接等同于每次查询的物理磁盘 I/O 次数。

与平衡二叉树相比，B+ 树每页能容纳更多分支，外存访问层数更少。与 B 树相比，数据集中在叶子使内部节点更紧凑，范围访问也更统一；B 树可能在内部节点命中单点查询，并非完全没有优势。哈希结构适合等值访问，但难以直接支持有序范围与排序。LSM 树更强调写入路径与后台合并，适用于另一组读写和空间放大取舍。

所以选择来自 OLTP 的页访问、范围查询、缓存和事务需求。SSD 减少了随机 I/O 的部分代价，但缓存局部性、页管理和写放大仍然影响表现。

算法

算法题：判断二叉树 B 是否为二叉树 A 的子结构。要求先描述解题思路，再进行代码实现。

回答：

先明确"子结构"与"完全相同的子树"的区别：B 要求存在的节点必须在 A 对应位置存在且值相同；B 没有要求的位置，A 可以继续有后代。通常约定空树 B 不是任何树的子结构。

分两层处理：外层枚举 A 中可能的起点，内层检查从某起点能否匹配 B。匹配时 B 为空返回真，表示该分支要求已经满足；若 B 非空而 A 为空或值不同，则返回假。外层的"空 B 为假"与内层"匹配完 B 为真"职责不同。

下面采用迭代写法，避免退化长链触发 Python 递归深度限制：

python 复制代码

from dataclasses import dataclass
from typing import Optional


@dataclass
class Node:
    val: int
    left: Optional["Node"] = None
    right: Optional["Node"] = None


def is_substructure(a: Optional[Node], b: Optional[Node]) -> bool:
    if a is None or b is None:
        return False

    def matches(start: Node, pattern: Node) -> bool:
        pairs = [(start, pattern)]
        while pairs:
            x, y = pairs.pop()
            if y is None:
                continue
            if x is None or x.val != y.val:
                return False
            pairs.append((x.left, y.left))
            pairs.append((x.right, y.right))
        return True

    candidates = [a]
    while candidates:
        node = candidates.pop()
        if matches(node, b):
            return True
        if node.right is not None:
            candidates.append(node.right)
        if node.left is not None:
            candidates.append(node.left)
    return False

设两树节点数为 n , m n,m n,m。最坏情况下每个起点检查多达 m m m 个节点，总时间为 O ( n m ) O(nm) O(nm)；深度优先栈的辅助空间上界为 O ( h A + h B ) O(h_A+h_B) O(hA+hB)，退化时不超过 O ( n + m ) O(n+m) O(n+m)。重复值多、末端才失败的树会接近最坏情况。

例如 A 是 1 -> 左孩子 2 -> 左孩子 3，B 是 2 -> 左孩子 3，匹配成立；B 只有节点 2 也成立，因为 A 的额外后代允许存在。若 B 要求 2 的右孩子为 3，而 A 只有左孩子 3，则不成立。直接把两树的遍历值序列做字符串包含判断，不能正确表达这种结构约束。

算法题：求两个有序 List 的相同元素。

回答：

先确认升序或降序、是否有重复，以及输出集合交集还是多重集合交集。以下假设两个输入均非递减，默认输出去重交集；如果要求重复次数取两个输入中出现次数的最小值，可切换 unique=False。

使用两个指针：值较小的一侧前进；相等时输出，并同时前进。因为输入有序，较小值不可能与另一侧当前位置之后的更大值相等，所以可以安全跳过。

python 复制代码

def intersect_sorted(a, b, unique=True):
    i = j = 0
    result = []
    while i < len(a) and j < len(b):
        if a[i] < b[j]:
            i += 1
        elif a[i] > b[j]:
            j += 1
        else:
            value = a[i]
            if not unique or not result or result[-1] != value:
                result.append(value)
            i += 1
            j += 1
    return result

例如 [1,2,2,4] 与 [2,2,3,4] 的集合交集为 [2,4]，多重集合交集为 [2,2,4]。空输入输出空列表；负数不改变算法。代码假定元素有一致的全序比较语义，不把 NaN 等特殊比较行为当作普通整数处理。

若 List 指链表，用节点指针推进；不能对链表反复按下标随机访问，否则可能破坏线性复杂度。若是有限迭代器，使用两个当前值就可以边读边输出，避免把输入整体载入内存。

2.1 分析当前实现的时间复杂度。

回答：

两个输入长度分别为 n , m n,m n,m。每轮循环至少推进一个指针，每个指针最多越过自己的整个输入，因此最坏时间为 O ( n + m ) O(n+m) O(n+m)。这个结论假定整数比较等基本操作视为常数；若元素是很长的字符串，还应计入比较成本。

除结果列表外，指针与当前值占用 O ( 1 ) O(1) O(1) 辅助空间。若输出包含 k k k 个元素，返回列表占用 O ( k ) O(k) O(k)；使用生成器逐个输出可减少本地结果缓存，但下游是否持久化结果需要另外计算。

对于长度极不均衡、且长输入支持随机访问的数组，也可对较短输入逐项二分，粗略为 O ( n log ⁡ m ) O(n\log m) O(nlogm)，或采用跳跃查找。是否更快取决于数据长度、重复情况、缓存与访问介质；双指针仍是顺序读取和链表场景的自然基线。

2.2 如果两个 List 变成无法整体排序的无限序列，应该如何处理？

回答：

要先定义无限流的有序性、交集时间范围和结果语义。对尚未到来的元素无法宣告它永远不会出现，所以无限流没有普通有限数组那样的"全部处理完成"。

如果两条流天然全局有序，可以维护两个当前值做流式归并，在发现相同值时输出；读取要配合异步等待和背压。若某条流停滞，或者无限重复同一值而不前进，某些更大值的判断可能永远不能完成。有序并不自动保证持续进展。

如果两条流任意无序，又要求"全历史、精确、无遗漏"的交集，在无界取值域下就必须保存可能在未来匹配的历史信息；最坏状态会随不同值数量增长。把状态移到外存可缓解内存压力，但不会使总状态变为常数。

工程上通常选择三种明确契约之一：限定事件时间窗口并使用 watermark 与允许迟到策略；将全历史状态落在可扩展的持久化 KV 中；或者在业务允许时采用近似过滤，再由精确存储复核。watermark 只在既定迟到假设下允许清理状态，过晚数据如何补偿或丢弃必须显式定义。

精确集合交集的基本流式状态可以用每个键两位标记表达，下面代码展示逻辑，字典只是演示性的内存实现：

python 复制代码

def intersect_events(events):
    seen = {}
    for side, value in events:
        if side not in ("A", "B"):
            raise ValueError("side must be A or B")
        bit = 1 if side == "A" else 2
        before = seen.get(value, 0)
        after = before | bit
        seen[value] = after
        if before != 3 and after == 3:
            yield value

该函数在某值第一次被两侧共同观察到时输出一次，之后保留状态防止重复输出。哈希访问平均按 O ( 1 ) O(1) O(1) 计，处理 N N N 条事件的期望时间为 O ( N ) O(N) O(N)，状态为 O ( D ) O(D) O(D)，其中 D D D 是历史不同值数量。生产中需按 key 分区，将状态更新、消费位点与输出通过事务或一致性 checkpoint 协调；否则故障重放可能造成漏发或重发。

2.3 使用 Bitmap 时，如果元素值范围非常大，会有什么问题？

回答：

普通 Bitmap 按取值域分配位置。若允许 U U U 个不同整数值，仅一个位图就约需：

M = ⌈ U 8 ⌉ bytes . M=\left\lceil\frac{U}{8}\right\rceil\ \text{bytes}. M=⌈8U⌉ bytes.

因此空间主要由取值范围决定，而不是当前元素数。完整 64 位无符号整数域的单个位图需要 2 61 2^{61} 261 字节，即 2 EiB；两条流和输出去重状态还会进一步增加空间。稀疏而跨度大的 ID 直接映射普通 Bitmap 很不经济。

可选方案包括 Hash Set、磁盘 KV、按范围分区的稀疏结构，以及 Roaring 等压缩位图。Roaring 根据局部密度采用不同容器，收益依赖分布，也要区分 32 位实现与 64 位扩展，不能保证任何稀疏大域都很省空间。

坐标压缩要求维护原值到紧凑 ID 的映射；在无限新值流中，这个映射本身仍会增长。Bloom Filter 可以作为候选过滤器，但存在假阳性，单独使用无法输出精确交集；需要回查真实集合。清理过期过滤状态还必须与窗口语义一致。

2.4 是否可以将两个无限序列拆成局部、分批处理？

回答：

可以分批调度，但分批不会消除跨批次的匹配依赖。任意取两边各一万条，求交集后只把交集带到下一轮，对无序全历史交集是不正确的。

反例：第一轮 A 为 [7]，B 为 [2]，交集为空；第二轮 A 为 [3]，B 为 [7]，当轮交集仍为空，但全历史交集包含 7。第一轮未匹配的 7 一旦被丢弃，第二轮就无法恢复它。

图 3：按批调度只改变处理节奏。对无序全历史交集，必须保留未来仍可能匹配的键；要释放状态，必须先定义可关闭的窗口或确定的排序边界。

正确做法取决于条件：

全局有序流按值边界处理，保留未匹配尾部与游标；只有确定另一条流已经越过某个值，才可以丢弃该值。相同条数的批次不代表相同值域。
无序全历史流将每批增量与持久化历史状态比较，按 key 哈希分区后由同一分区维护两侧出现标记。只保存交集不够，还需保存可能未来匹配的键及已输出状态。
窗口交集按照事件时间组织状态，在 watermark 和允许迟到规则满足时关闭窗口，明确超迟事件的处理策略。
对有结束边界的大型数据集，可用外部排序或哈希分桶，在同一桶内求交；这是一种有界批处理方案，不能直接证明无限全历史任务能用有界状态完成。

微批大小按吞吐、延迟和内存选择；业务正确性由窗口、排序边界和状态保留规则决定。检查点需把未匹配状态、去重状态、读取位点与输出进度一起纳入恢复设计。

反问

候选人：团队 Agent 目前主要负责什么垂类业务方向？

回答：

这是向招聘团队了解业务的问题，无法从题目确定该团队实际方向。不能把"字节"推导成必然做电商、广告或内部效率工具。

有效追问应落到任务形态：服务内部员工还是外部客户；主要做知识问答、代码开发、经营分析还是业务执行；Agent 能执行哪些真实动作；线上成功如何定义；目前最大瓶颈是模型、数据、工具、工程还是用户流程。

还可以了解岗位负责的边界：偏模型训练、Harness 与工具工程、业务集成还是评测平台，实习生能否参与完整反馈循环。团队若能清晰描述真实用户、任务指标、失败案例与迭代机制，比仅列举技术名词更能帮助判断岗位匹配度。

候选人：团队内部是否比较鼓励使用 AI Coding？

回答：

应由团队说明真实政策，不能替面试官作答。可以进一步问允许哪些工具、代码和数据能否发送外部服务、是否提供企业账号、怎样做权限控制，以及对生成代码是否有明确审查和测试要求。

成熟的支持通常体现为制度与基础设施：可用的开发环境、项目上下文、自动化测试、CI、代码评审与故障反馈。只说"鼓励使用"但缺少验收流程，并不保证能提高交付质量。

评价重点是团队是否把 AI 当作可验证的生产工具，是否允许沉淀可复用流程，并用交付质量和周期衡量效果，而非简单要求提高 AI 生成代码占比。

面试官：你现在使用 AI Coding 的工作流是怎么样的？

回答：

应把前面完整流程压缩成一个具体任务的叙述，展示实际执行证据。例如，以自己确实做过的接口缺陷为例：先获得稳定复现与预期行为，再让 Agent 阅读调用链和版本约束，完成小范围修改；随后运行与缺陷相关的测试以及必要集成检查，人工审查差异和错误路径，按团队流程发布并读回结果。

补充说明哪些步骤由自己判断，哪些交给 Agent：人负责需求、权限、方案取舍和最终验收；Agent 承担检索、代码修改、运行检查和整理证据。遇到误判时记录原因并修订项目说明或验证脚本，而不是只不断重写提示词。

回答里的工具名、耗时和收益都应来自真实经历。没有生产发布经历时，就说明完成到了本地或测试环境的哪一步，保持证据与结论一致。

面试官：有没有更 AI Native 的做法？

回答：

更 AI Native 的方式，是把需求、代码、工具、测试与反馈组织成 Agent 能持续执行和验证的环境。它的进步不由开了多少个聊天窗口决定，而取决于自动执行是否减少了人工搬运，并保持质量与控制能力。

可以从四个方向建设：把需求写成可执行验收条件，失败样本直接进入回归集；让 Agent 在受控工作区中完成阅读、实现、运行与修复闭环；把常见任务、项目规范和工具接口沉淀为 Skills 与稳定服务；把任务轨迹、失败类型、成本和人工接管记录回流到评测与流程改进。

多 Agent 适合独立模块实现、证据调研或交叉审查，需要明确文件所有权、隔离工作区和集成责任。模型之间意见一致不是正确性证明，独立测试与真实环境结果仍然必要。不能为了"多 Agent"制造额外协调成本。

自动化从低风险、可回滚、有明确验收的任务逐步扩大。代码生成、运行测试与诊断可以较高程度自动化；发布、权限修改和不可逆数据操作仍遵循明确授权和工程门禁。长期可积累的能力是任务契约、可执行工具、评测数据和故障恢复机制。

实验与证据：如何把面试回答变成可验证结论

这份材料中的设计建议应通过小型、独立的验证闭环落地。会话记忆可用长对话回放、事实冲突、并发摘要和恢复测试，记录事实保真率、约束违反率、任务成功率、Token 消耗与压缩延迟。文档更新应注入重复消息、旧版本慢任务、删除乱序、发布后宕机和租约过期等故障，检查最终活动代次、重复副作用和恢复时间。多 Agent 与 Computer Use 则应固定任务、模型、工具权限和预算，比较成功率、P95/P99、单位成功成本、恢复率和人工接管次数。

算法题需要独立 oracle，而不是只运行自己写出的测试。二叉树子结构可用穷举小树对照；有序列表交集应覆盖空输入、重复值、负数和长度极不均衡；无限序列问题要分别验证有序流、无序窗口、持久化状态和迟到事件。只有当实现、边界条件和验收脚本彼此独立时，复杂度结论才有可信度。

工程边界：设计方案需要什么证据

文中的架构讨论是可供验证的设计方案。能否满足生产要求，要结合实际业务数据、代码、模型版本、流量与故障测试判断。DeepSeek Harness、Pi、Claude Code 等产品的默认能力和阈值会随版本变化，选型时应锁定版本与配置，并验证状态恢复、扩展兼容性和权限隔离。面试中的团队垂类与内部工具政策，则应以团队明确提供的信息为准。

如果继续研究/落地，应该关注什么

第一，把任务契约、工具 schema、状态迁移和验收条件固化为可执行测试，让模型升级与 Harness 升级可以分别回归。第二，为每个外部副作用建立幂等键、版本和补偿路径，把"重试"从网络层动作提升为业务层语义。第三，将上下文、记忆、检索、工具和轨迹统一纳入成本与权限预算，避免局部优化造成整体失控。第四，为本地与云端 Computer Use 建立隔离工作区、短期凭据、动作前策略门和动作后真实状态校验。第五，在 AI Coding 中沉淀失败样本和可复现任务，让自动化程度随着证据增加而扩大。

术语与概念速查

概念	在本文中的工程含义
Harness	模型外的运行、治理、状态与验证环境
Context Builder	按任务、权限和 Token 预算组装当前上下文
CAS	用版本条件更新避免旧状态覆盖新状态
Outbox	在同一事务中记录状态变化和待发送事件，降低双写丢失
ReAct	Reasoning 与 Acting 交替的局部执行循环
Planner / Executor / Critic	分别负责拆解步骤、执行动作和验收反馈
Checkpoint	可恢复任务的目标、步骤、产物、错误和进度快照
Watermark	在迟到假设下关闭事件时间窗口并清理状态的边界
Computer Use	通过屏幕观察和结构化动作操作图形界面的执行方式

拓展思考：值得继续扩展研究与思考的创新点

真正有长期价值的方向，是把 Agent 的不确定性限制在可观察的局部：用结构化状态保存事实，用版本和幂等保证并发正确性，用工具回执和验证器判定完成，用评测轨迹驱动下一轮改进。多 Agent、长时记忆和 Computer Use 都可以接入同一闭环，但每增加一种能力，就要同步增加权限边界、成本预算、故障恢复和独立证据。对面试准备而言，掌握这套推理方式比背诵某个框架的宣传语更能应对追问；对生产系统而言，它决定了 Agent 能否从演示走到可靠交付。

【三年面试五年模拟】2026-09-16 字节跳动 Agent 秋招一面全解析：从 Harness、记忆与并发到算法题的系统化解析

写在前面

核心导读

面试主线：从模型调用到可靠执行

核心思路：把 Agent 看成受约束的执行闭环

项目

实习项目拷打

企业 AI 助手项目中，基于滑动窗口和摘要压缩的会话记忆是怎么实现的？

3.1 滑动窗口大小是怎么确定的，大概设置多少轮？

3.2 哪些场景适合滑动窗口，哪些场景更适合直接通过摘要进行上下文压缩？

文档在线自动更新时，如何保证并发更新的幂等性，避免多个任务相互覆盖？

4.1 RocketMQ 在文档自动更新链路中的哪个位置？

4.2 为什么文档更新这里考虑使用 MQ，而不是直接在定时任务中处理？

你对业界其他 Agent / Agent Harness 有哪些了解？

5.1 展开介绍一下你了解的 DeepSeek Harness 和 Pi Agent。

5.2 如果把这些 Harness 和你实习中的 Agent 项目结合，你会怎么做？是否有必要替换当前方案？

除了开源 Agent，你是否调研或使用过其他厂商的 Agent 产品？

6.1 介绍一下你了解的 Claude Code 上下文压缩机制。

介绍一下你对 Computer Use 的了解情况。

7.1 Computer Use 操作本地电脑的大致实现机制是什么？

7.2 是否了解操作本地电脑和操作云端电脑两种方案？

平时使用 AI Coding 工具开发时，遇到过哪些问题？

你平时使用 AI Coding 工具的完整开发工作流是什么？

八股

常见数据库有哪些类型？不同类型数据库之间有什么区别？

MySQL 底层索引使用什么数据结构？

2.1 为什么 MySQL 索引使用 B+ 树，而不是其他树结构？

算法

算法题：判断二叉树 B 是否为二叉树 A 的子结构。要求先描述解题思路，再进行代码实现。

算法题：求两个有序 List 的相同元素。

2.1 分析当前实现的时间复杂度。

2.2 如果两个 List 变成无法整体排序的无限序列，应该如何处理？

2.3 使用 Bitmap 时，如果元素值范围非常大，会有什么问题？

2.4 是否可以将两个无限序列拆成局部、分批处理？

反问

候选人：团队 Agent 目前主要负责什么垂类业务方向？

候选人：团队内部是否比较鼓励使用 AI Coding？

面试官：你现在使用 AI Coding 的工作流是怎么样的？

面试官：有没有更 AI Native 的做法？

实验与证据：如何把面试回答变成可验证结论

工程边界：设计方案需要什么证据

如果继续研究/落地，应该关注什么

术语与概念速查

拓展思考：值得继续扩展研究与思考的创新点

推荐阅读

1. 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

3. 入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识

4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

5. 深入浅出完整解析DeepSeek系列核心基础知识

6. 深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识

7. 深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识

8. 深入浅出完整解析Stable Diffusion（SD）核心基础知识

9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

10. 深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

11. 深入浅出完整解析ControlNet核心基础知识

12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

13. 深入浅出完整解析AIGC时代Transformer核心基础知识

14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

16. AIGC产业的深度思考与分析

17. AI算法工程师的独孤九剑秘籍

18. 深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识