工具
工具的分类 工具类型 调用方向 作用对象 感知工具 Agent 主动调用 获取信息 执行工具 Agent 主动调用 改变世界 协作工具 Agent 主动调用 驱动其他 Agent 或人类 用户沟通工具 Agent 主动调用 向用户传递信息 事件触发工具 Agent 注册、外部触发 驱动 Agent 开始执行 工具的设计的通用原则 工具的表现形式 专用代码工具：结构化的函数调用，确定性高、可测试，但每个工具会占据数百个 token，且数量膨胀会破坏 KV Cache。 skill+通用工具：用自然语言编写的 Skill 文档来描述操作流程，Agent 通过终端或代码解释器来执行，只需少量的通用工具就能覆盖大量场景 怎么选择专用代码工具还是 skill+通用工具？ 参数复杂度：涉及嵌套对象、多字段联合校验、复杂类型约束 工具变更频率： 模型能力： 工具的粒度：分离还是整合 粒度过细会导致工具数量激增，增加 LLM 的选择负担；粒度过粗又会使单个工具过于复杂。当工具数量过多时（比如超过 100 个），即使是最先进的大语言模型也容易在工具选择上...
H.264 与“闭眼抽帧”学习笔记
在 PPT、网页操作、数据看板这类屏幕录制视频里，不一定要先把每一帧都解码成图像再判断页面变化，而是可以先观察 H.264 压缩码流里的数据包大小变化。编码器本来就已经分析过相邻画面的差异；如果画面很容易预测，压缩数据通常很小，如果画面突然大面积变化，压缩数据往往会明显变大。 所以所谓“闭眼抽帧”，不是完全不处理视频，而是在候选检测阶段不看像素画面，只看压缩数据的时间变化；等找到可能的换页位置后，再解码少量代表帧。 一、为什么这个问题可以从编码数据里找线索 DataAgent 的视频理解任务里，视频内容通常是界面操作、PPT 或类似页面讲解。这类视频有一个很明显的特点：大部分时间画面是静止的，只有在换页、弹窗、表格加载、动画出现时才发生大面积变化。 如果按固定间隔抽帧，会遇到两个问题：一是同一个静止页面会被抽出很多重复帧；二是停留时间很短但重要的页面可能被错过。传统做法是解码所有帧，然后用像素差、直方图、SSIM、感知哈希或视觉模型比较前后画面。这样当然可行，但成本比较高。 H.264 给了另一条线索。它的压缩依赖预测：能从当前画面内部或前后参考画面预测出来的内容，就不需要完整保...
ASR 方案学习笔记
这份笔记主要记录我对 DataAgent 赛题中视频 briefing 转写方案的理解。原始方案看起来并不复杂：先把视频里的旁白转成文字，再交给后面的 Agent 去理解任务、操作页面。但真正影响效果的地方不只是“选一个更强的 ASR 模型”，而是语言判断、模型规模、领域上下文、文本归一化和评测口径这些细节如何配合。 一、这个 ASR 模块解决什么问题 DataAgent 的部分任务会给一段 briefing 视频。视频旁白通常会告诉 Agent 当前页面状态、需要操作的表或字段、要关注哪些信息、哪些是干扰项，以及最终要完成什么操作。对 Agent 来说，这段旁白相当于任务说明书；如果转写错了，后面的理解和执行都会被带偏。 整个链路可以简化成： 1briefing 视频 -> 抽取音频 -> ASR 转写 -> 文本后处理 -> DataAgent 执行 这里的 ASR 指 Automatic Speech Recognition，也就是自动语音识别。它负责把语音变成文字。Whisper 则是 OpenAI 发布的一系列 ASR 模型，是实现 ASR 的具...
上下文工程
参考：《AI Agents in Depth》第 2 章：上下文工程 上下文布局、状态栏和压缩技术 放什么，怎么放，怎么压缩 1. 什么是上下文工程 上下文（Context）是模型在某一次推理时实际看到的全部信息，包括系统提示词、工具定义、用户消息、模型之前的回复、工具执行结果、按需加载的 Skill、当前状态摘要等。 提示词（Prompt）只是上下文的一部分。Prompt Engineering 主要解决“指令怎么写”，Context Engineering 则解决一个更完整的问题： 在每一个决策点，应该让 Agent 看到什么信息、以什么结构看到、哪些信息应当保留或删除，以及如何兼顾正确性、成本、延迟与安全。 从形式上看，模型每一步的输出可以理解为： $$ y_t = f_{\theta}(c_t) $$ 其中 $\theta$ 是模型参数，决定模型具备的通用知识与推理能力；$c_t$ 是第 $t$ 步的上下文，决定模型此刻能依据哪些信息做决策。模型参数与上下文不是二选一：模型参数提供能力，Context 为能力提供任务条件和外部事实。 “Context 决定 A...
Milvus 从零到面试：RAG 向量数据库原理、架构、索引与选型
一句话回答 Milvus 是一个面向大规模向量检索的开源、云原生数据库。它把向量、标量元数据和索引作为可持久化、可过滤、可扩缩容的数据来管理，适合为 RAG、语义搜索、推荐和多模态检索提供低延迟 ANN 召回。 面试时可以先给出下面这条主线： 文档切块 → Embedding → 写入 Milvus → 对 Query 做 Embedding → 向量 ANN + 元数据过滤/BM25 → 融合与 Rerank → 组装上下文 → LLM 生成。 需要先强调一个容易加分的结论： RAG 不一定必须使用专用向量数据库。 小规模、静态、单机数据可以用 NumPy/Faiss；已有 PostgreSQL 可以先用 pgvector；已有 Elasticsearch 且强依赖全文检索时可以直接做混合搜索。只有当数据量、并发、过滤、实时更新、持久化、高可用或独立扩缩容需求上来后，专用向量数据库的价值才明显。 为什么需要“向量数据库” 这个问题最好从传统关系数据库擅长什么讲起。 MySQL、PostgreSQL 等关系数据库主要面向结构化数据和精确查询。一条典型 SQL 可能是： 1...
RAG 混合检索
一句话回答 混合检索（Hybrid Search）通常是把关键词/稀疏检索与语义/稠密检索并行执行，再通过分数融合或排序融合合并候选集，最后用 Reranker 精排。 稀疏检索擅长精确匹配：专有名词、型号、错误码、人名、数字。 稠密检索擅长语义匹配：同义表达、口语化问题、没有共享关键词的相关文本。 混合检索的目标不是简单地“多查一次”，而是利用两类检索器的互补性，提高 Recall@K，并在精排后提高最终答案质量。 面试时可以先给出下面这条主线： Query 预处理 → 稀疏检索与稠密检索并行召回 → 候选去重与融合 → Reranker 精排 → 上下文组装 → LLM 生成。 为什么需要混合检索 只用一种检索器会有明显盲区。 查询 BM25/关键词检索 向量检索 ORA-01555、iPhone 15 Pro Max 通常很好，能精确命中关键词 可能因罕见 token 或向量平滑而漏召回 “合同到期后还能续多久”与“协议期满可延长三个月” 词面重合少，可能漏召回 能利用语义相近性命中 带数字、版本号、缩写的查询 更稳定 容易忽略数字或细粒度差异...
在 Codex 中接入 GPT + DeepSeek，并配置 DeepSeek 子代理
本文记录一次完整的 OpenCodex 实践过程，目标是让 Codex 同时使用 OpenAI 和 DeepSeek，并让 DeepSeek V4-Flash 作为 Codex 的默认子代理。 1. 为什么需要 OpenCodex 如果只是想在 GPT 和 DeepSeek 之间切换，其实不需要 OpenCodex。 OpenCodex 更有价值的地方在于，它可以在本地启动一个代理，将不同 Provider 的模型统一接入 Codex。 最终形成类似： 1234567 ┌── GPT-5.6 Sol │Codex ── OpenCodex ─┼── GPT-5.6 Terra │ ├── DeepSeek V4-Flash │ └── DeepSeek V4-Pro 进一步还可以配置： 12345主代理：GPT │ ├── 子代理 → Dee...
记忆系统
该笔记是对于开源项目 ai-agent-book中第三章的内容的个人思考与总结笔记。 本章主线任务是回答Agent 应该记住什么、怎样存、怎样更新、怎样检索，以及如何判断记忆系统真的有用 与第二章的上下文管理不同，本章的记忆系统是一个长期的、跨会话的记忆系统，主要用于存储和检索 Agent 的长期记忆。如何让 Agent 在对话结束后仍然记住用户、记住知识。 持久化记忆体系 作者认为，持久化记忆体系可以分成两个部分： 一个是用户记忆，另一个是知识库。用户记忆是 Agent 对用户的偏好，信息的画像，是个体尺度 另一个是知识库，是某个领域的群体所共享的知识，是群体尺度，比如一个行业的法规体系、一家公司内部的操作流程、一个技术领域的专业文档 记忆能力的评估：三层次框架 第一层：基础回忆 第二层：多会话检索 第三层：主动服务 记忆系统的设计可以拆成三个独立的维度——放哪里、怎么存、存什么 分类体系 回答的问题 具体类别 记忆层次（本章开头） 存在哪里？ 轨迹（当前会话）、用户长期记忆（跨会话）、业务状态（任务阶段） 存储格式（“四种存储格式”一节） 怎么存？ Simp...
文本编码与tokenizer
文本编码 ASCII编码 标准 ASCII 使用 7 个二进制位，共能表示 128 个字符。 因为 7 位二进制的组合数量是： $$ 2^7 = 128 $$ 编号范围是： $$ 0 \sim 127 $$ 注意，0 到 127 一共有 128 个数，不是 127 个。 例如： A 的 ASCII 码是 65 a 的 ASCII 码是 97 0 的 ASCII 码是 48 ASCII 码 127 是删除控制符 DEL 之所以常说 ASCII 占一个字节，是因为计算机通常以 8 位为一个字节： 10xxxxxxx 标准 ASCII 实际只使用低 7 位，最高位通常为 0。 因此： 编码 位数 编码范围 可表示数量 标准 ASCII 7 位 0～127 128 个 一个字节 8 位 0～255 256 种状态 后来有些编码使用了第 8 位，把范围扩展到 0～255，通常被称为“扩展 ASCII”。但扩展部分并没有完全统一，不同编码页对应的字符可能不同。 一句话记忆： 最大编号是 127，但字符数量是 128，因为还包括编号 0。 无法表示中文等...
开源模型调用
开源模型调用 使用 Hugging Face 的 transformers 库可以比较方便地调用开源大语言模型。为了先把调用链路跑通，这里尽量选择一个小模型： Qwen/Qwen2.5-0.5B-Instruct 这个模型只有 0.5B 参数，适合本地学习和调试。它的能力不能和 7B、14B 甚至更大的模型相比，但胜在下载快、显存占用低、启动成本小。 为什么先选小模型 刚开始学习开源模型调用时，不建议一上来就跑很大的模型，原因是： 大模型对显存要求更高，环境问题会掩盖调用逻辑本身。 小模型启动快，适合反复调试 prompt、tokenizer 和采样参数。 如果只是学习 tokenizer -> model.generate -> decode 这条链路，0.5B 或 1.5B 已经足够。 小模型可以在很多普通 GPU 甚至 CPU 上跑通，虽然 CPU 会慢一些。 模型权重大致显存可以这样估算： $$ \text{显存} \approx \text{参数量} \times \text{每个参数占用字节数} $$ 以 0.5B 参数为例： 精度 每个...