一、为什么要给 RAG 一张图 1.1 纯向量检索的两个短板 向量 RAG 的标准流程大家都熟：文档切块（chunk）、每块算嵌入（embedding）、问题也算嵌入、按余弦相似度捞回最相近的几块，塞进 prompt 让 LLM 作答。这套流程在课程里先跑了一遍：NetApp 的 10-K 文件，Item 1 章节切成 254 块，全部写入 Neo4j 并建好向量索引，套上 LangChain 的

一张四行的太阳镜库存表，字段是 id / name / description / price / stock。顾客问：「有 100 美元以下、还有货的圆框墨镜吗？」表里没有「圆框」这一列，这个词埋在 description 的自由文本里；有没有货在 stock 列，贵不贵在 price 列。开发者当然可以把「查描述 → 查库存 → 查价格」这三步写死进代码，但下一个顾客问「我上个月退的那副处理好

一、先做出原型，再谈评估 1.1 别空想几周，先做个能跑的 构建 Agentic 系统最难的地方在于，你没法提前知道它在哪些输入上会工作得很好、在哪些输入上会翻车，也就不知道力气该往哪儿使。所以常见的建议是：先做一个快而糙的原型，跑一遍，看它在哪里表现不如意，再集中精力改进。反过来，坐在那里推演几周该怎么做，通常是更差的选择。 关键前提是：这个原型要安全、负责任地做，不能泄漏数据，在这个底线上越快

本文内容整理自吴恩达（Andrew Ng）《Agentic AI》课程模块3「工具使用」 LLM 只会生成文本 token，它凭什么能查数据库、发日历邀请、跑一段 Python？答案是它压根不执行任何东西。工具使用（tool use）的真实链路是：LLM 按约定格式输出一个调用请求，宿主代码解析这个请求、真正执行函数、把返回值写回对话历史，LLM 再基于这段历史继续生成。「请求—执行—回填」这个三

一、反射设计模式：让 Agent 审视自己的输出 1.1 从人类反思到 LLM 反思 人写东西很少一遍到位。草稿写完回头看，会发现日期不明确、用词不准、漏了签名，改完再发。这个「写完 → 审视 → 修改」的过程就是反思（reflection）。 LLM 也能走同样的流程。与其让它一次生成最终答案，不如分两步：先生成初稿，再让它以另一个提示词审视初稿、指出问题、写出改进稿。课程里用邮件举过例子：约朋

为了方便解释 Android Binder 框架运行逻辑，将整个 binder 单独抽出来，使其可以独立编译、分析和运行。 一、为什么 Android 选了 Binder Linux 上做跨进程通信有不少现成方案：管道、Unix domain socket、共享内存、System V IPC。Android 选择 Binder，主要原因有两个。 安全性。传统 Unix IPC 不要求调用方自证身份

本文内容整理自吴恩达（Andrew Ng）《Agentic AI》课程模块1（共 8 节） 一、从一次性单向生成到 Agentic 工作流 1.1 一次生成的问题（直接调用裸模型思考） 今天大多数人用 LLM（大语言模型，接收提示、逐词生成文本的模型）的方式，相当于要求一个人从第一句写到最后一句，中途不许回头、不许查资料、不许改。人在这种约束下写不出好东西，因为输出顺序必须一次就对。 模型也一样。

一、面试题：广播如何跨进程 1.1 题目的真实问法 听上去在考 BroadcastReceiver，实际问的是四大组件的底层通信机制——广播只是四个组件里被挑出来的那一个，换成 Activity 启动、bindService、ContentProvider 查询，答案的骨架完全一样。 只回答「广播走 Binder」拿不到分。面试官想听的是这条链路上有哪几站、每一站由谁完成、哪几步跨了进程。 1.2