智能驾驶5年 | DevOps高级工程师 已落地2个生产级 AI Agent（持续迭代） 公开学习 & 分享 Agent / Inference / Infra
Shanghai
Joined December 2023
- Tweets546
- Following240
- Followers870
- Likes528
Pinned Tweet
做AI Agent已经半年了，从最初的懵懂到现在可以交付生产级的Agent。在这个过程中，对Agent的理解逐渐加深。
现在回看，对Agent理解的一个转折点是在微信公众号上看了不少“三元同学”写的文章，逐渐对上下文等概念有了清晰的理解。后来，买了她在Sitor上面的课程，系统学习了Agent。在这些基础打牢后，现在吸收理解包括AI Inference，Agent评测这些知识就更容易了，也是体会一把知识的飞轮。
如果大家对AI Agent感兴趣，可以在公众号上关注“三元同学”，下面附一些我感觉不错的文章：
1.mp.weixin.qq.com/s/h5QyZ07G7…
2. mp.weixin.qq.com/s/ViQU8mCuL…
3. mp.weixin.qq.com/s/N1WgUN8dd…
对AI感兴趣的朋友可以多交流交流。
想系统性学习大模型，包括LLM内部结构，训练，推理等过程。可以看看纳米老师这个学习网站，里面包括了比较完整的学习路线。
我的网站nano-ai.tech现在有这些内容
按顺序学，基本能把大模型从头到尾走一遍
先看全景：大模型学习路线图
从 Transformer 到 DeepSeek-V4，8 个阶段、51 个知识点
nano-ai.tech/map
第一步：图解大模型
大模型是怎么推理的 → nano-ai.tech/matrix
大模型是怎么训练的 → nano-ai.tech/training
Agent 是怎么工作的 → nano-ai.tech/agent
第二步：从零手写大模型
用代码复现一遍，从 GPT-2 写到 LLaMA
推理篇 15 篇、训练篇 5 篇、进阶篇 5 篇，均已完结
nano-ai.tech/articles
第三步：大模型论文研读
读原始论文，现在有 Switch Transformer（MoE）三篇解读
nano-ai.tech/papers
建议的学法：
先在路线图上看清楚要学什么
再用图解把每一步的计算看懂
然后自己动手写一遍
最后回到论文，看原作者是怎么想的
nano-ai.tech/?v=2全部免费，持续更新。
Jerry Fang retweeted
10月25日，我生日。
想和大家分享一下过去这一年：从加拿大到新加坡，再到中国；从实验室、初创公司的实习生，到代理 CEO，再到创业未果，最后为爱发电，投身开源。
关于在初创公司的那段神奇经历，之前已经分享过，这里就不赘述了，我会把那篇推文发到评论区。那段经历对我最大的帮助，是让我意识到：AI 就是这个时代最大的杠杆。
也是从那时候起，我看到了 agent infra 的未来，想围绕这个方向创业，于是尝试申请了一些创业营。坦白说，体验不算美好。
我对自己想做的项目一直很有信心。我相信，AI 时代的产品和基础设施，一定要围绕 agent 重新设计。这想法算不上超前，但当时我看到的绝大多数所谓「agent native」产品，骨子里依然是 99% human-centric。
半年前，我就在 GitHub org 的介绍里写下了这两句话：
"⏳ Ephemerality: Scaling multi-agent development beyond imagination.
⚡ Ephemeral workspaces. Durable results. Massive parallelism."
那时候，我就相信 multi-agent、cloud、ephemeral computing 背后藏着一个万亿美元级别的市场。但相信的人寥寥无几。
第一个转折，是认识了一位多大的校友。他很看好我的项目，帮我介绍了奇绩创业营的面试机会。5月初，我去参加了面试。
快问快答环节，我答得一塌糊涂，这个锅主要在我自己。
但我对奇绩创坛的专业性也非常失望，评委对相关技术的理解比较有限，也没什么耐心听我把东西讲完，差不多一半的问题都在让我现场把钱和商业模式算出来。 一直高位者的态度审视着我，其实他可能鸡毛都不懂🤡。
这也是我最想不通的地方：如果创业营、天使轮，就要求项目已经能赚钱，那早期投资承担的风险到底是什么？融30万美元，还要给自己找个爹一样管着，我确实不太喜欢。真到了商业模式成熟、盈利稳定的阶段，我可能会先去找银行聊聊贷款。
得出一个结论，国内VC就是那种穷养孩子的父母，但却望子成龙，希望赚大钱之后来孝顺他们🤣。
折腾了将近两个月后，我决定先把东西做出来，开始 all in 研发 Ephemeral Sandbox，也就是 LayerFS 的前身。
说实话，一开始做开源，我也没那么自信。毕竟那时候，我最好的项目也只有 8 颗星。怕大家不喜欢，发布前瞎折腾，怎么做出个好看的UI吸引眼球。
这里很感谢董科含的 VC Eric，把我介绍给了 @ktwu01 koutian 大佬，把我拉进了很多技术交流群。后来又和灵台的黄老板@zesenhuang、圆姐玩到了一起，得到了很多支持和鼓励。
在灵台微信群分享 Ephemeral Sandbox，应该是我这一年最重要的转折点。因为在那里，我遇到了田老师。
我刚把项目，以及 ephemeral computing、agent runtime substrate、multi-agent 这些想法分享出来，田老师就很感兴趣，马上给我打了电话，和我聊技术。
回头看，最初选择 OverlayFS，确实让我走了一段弯路。后来，田老师建议我试试 FUSE，又介绍我认识了 JuiceFS 和 PingCAP 相关项目的一些老师。在不断交流、学习和实践的过程中，LayerFS 的技术路线和整体形态才逐渐清晰起来。
转向 FUSE 后，项目的进展就像坐上了火箭。CAS、CDC、CoW 等设计也在那个阶段逐步成形。于是，我新开了 LayerFS，希望把它做成 Ephemeral Sandbox 存储层的进阶版本。
做完第一个小版本后，9月1日，我开始 build in public。
这个过程中，很感谢在快手做存储的高老师，给了我加入 delta encoding 的建议；也感谢 Nydus 的作者、OPPO 的付老师给我的鼓励。我还向 PingCAP 的齐老师和 Mike 老师请教了很多云端存储方面的知识。这些交流，让我对技术路线的理解越来越清楚，也给了我继续做下去的信心。
当然，质疑也一直没断过。
来 X 上 build in public 之后，我也找过一些做 agent 项目的人，聊后面能否考虑LayerFS当作存储和sandbox层。得到的反馈，大部分还是觉得我这个不靠谱：可能觉得我没资历，不知道从哪里冒出来，就要挑战这么底层这么困难的东西。
回顾过去一年，得到的大概是 10% 的看好，和 90% 的不看好。
非常感谢那 10% 的人，在项目还很早、我也没什么拿得出手的成绩时，愿意认真听我讲，给我信心和鼓励。
但我也感谢那 90% 的人。因为大半年前，我就已经相信自己一定会成功，一定能颠覆 agent filesystem 和 sandbox。越多人不认可，我反而越觉得，我的想法越超前，这条路上的竞争还没有那么大，值得继续往下走。
年初，我给自己起过一个挺不成熟的网名：best vibe coder of the year。
现在看，有点中二，但也藏着我当时的野心和决心。
四天前，LayerFS v1.0.0 发布了，让我更有底气继续往下走。我也越来越相信，这样的底层项目值得做几十年，也能做几十年。
应用端的项目会换一轮又一轮，我想把这层基础设施一直做下去，熬过一轮又一轮热潮。一个项目最终有多大价值，要看热潮过去之后。
最后，用几个关键词总结这一年：
勇敢，永远相信自己，不服输，不放弃。
Jerry Fang retweeted
用claude做了一个新栏目：Agent入门实践
nano-ai.tech/agent/
很多人觉得 Agent 很复杂
其实拆开看，它就是一个 while 循环：
调模型，执行工具，把结果写回上下文，再调模型
难懂的地方在于
你看不到上下文在循环里是怎么变的
这个栏目就是把它画出来，一格一格播给你看
怎么用：
左边栏选章节，一共 10 章
从一次 LLM 调用讲到一个完整的 coding agent
每章中间有一个播放器
点「播放」自动走，点「下一格」手动走
播放器左边是代码，黄色高亮的是当前执行到的那一行
右边是此刻的上下文
每种角色一个颜色：system、user、assistant、工具结果
刚加进来的那一块会亮黄
外框变成黄色，表示这一刻整个上下文正在发给模型
播放器下面是 token 计量条，每调用一次模型就多一条。
浅色是重发的历史，深色是这一圈新加的
看完你就明白，为什么 Agent 跑久了又贵又慢
10 章分别是：
一次调用、工具调用、Agent Loop、上下文窗口
规划、记忆、MCP 与 Skills、子 Agent、失败模式、实战拆解
建议先看第 3 章 Agent Loop
看懂这十几行代码，后面每一章都是在它上面加东西
想深入 Agent Infra，别只盯着 Prompt 和框架。
我落地过 2 个生产级 Agent。在这些项目中，我发现最难的不是模型本身，而是重试、状态管理、沙箱隔离和监控这些工程问题。Agent 能不能在生产环境中稳定运行，很大程度上取决于底层 Infra。
我把Agent Infra的学习之路拆成了 6 步，从 Runtime 一直到生产平台。下面是完整的学习路径。
开始前先说清楚 4 件事。
•这是一份公开的学习计划，大约按 6 个月的节奏走。重点是吃透，不比速度。
•Agent Infra 不是 AI Infra。这里不讲 CUDA，也不讲训练和推理。
•已经熟悉 Runtime 的人，可以跳过第 1 步。
•第 2 步最容易被低估。
6 步依次是 Runtime、可靠性、编排、沙箱、可观测与评估、生产平台。
1. 先自己写一个 Agent Runtime
目标：不依赖现成框架，搞懂 Agent 是如何完成一个用户任务的。
学什么：从零写一个 Agent Loop，也就是"思考、调用工具、拿到结果、再思考"这一圈。然后学 Tool Calling、Context Engineering、Streaming、State 和 MCP。可以跟着三元同学的 Super Agent 实战课走一遍，也可以跟着Datawhale的hello-agents做一遍（hello-agents链接：github.com/datawhalechina/he…）。我这里只分享整体思路，不贴课程里的代码。
有个捷径是读 Pi 的源码。重点看 Loop、消息结构、消息发出的时机、session、缓存、compact、hook 和 MCP。底层的 LLM 封装可以跳过。
怎么练：搭一个最小的 Loop，跑通一个需要多个工具的任务。再对照 Pi 画一张图，标出消息什么时候发出、session 怎么存、什么时候触发 compact。
验收：你能讲清一次工具调用从头到尾发生了什么。只会调 SDK 可不算过关。
2. 可靠性靠设计，不用先学分布式
目标：进程挂了、网络断了，没跑完的任务还能接着跑。
我的结论是，入门不必先学分布式。可靠性是设计出来的。
学什么：HTTP、SSE 和 WebSocket，进程、线程和协程，还有队列、状态机、超时、重试和幂等。资料先看 System Design 101。MIT 6.1800 和 6.5840 挑需要的部分补。DDIA 先别硬啃。
怎么练：写一个能恢复的小型任务执行系统。杀掉进程再重新启动，做了一半的任务要能接着跑。
我特别看重两点。第一，重新启动一个Agent进程，任务也能接着跑。第二，失败要如实上报，不能当成成功吞掉。
验收：重启以后任务不丢失，重试不会造成重复的业务副作用，任务状态能对得上。
3. 从一个 Loop 升级到编排多个 Agent
目标：从管一个 Loop，升级到管多个子任务和多个 Agent。
学什么：Subagent 的任务分发、结果收集和上下文隔离，异步任务与并发控制，目标拆解与结果对齐，以及更高层的多 Agent 编排工具。
怎么练：把一个任务拆成 3 个子任务，跑通后汇总结果。再故意让其中一个子任务失败，看编排层能不能把整个任务收住。
验收：你能说清哪些工作该交给子 Agent，哪些该留在主 Loop。
4. 危险操作一律放进沙箱
目标：工具可以读写文件、执行命令。出了事，坏掉的是沙箱，不是宿主机。
学什么：入门阶段会用 k8s 调度就够了。入门可以先从 Container + Volume 搭建隔离环境，再逐步了解文件系统隔离、资源限制、网络策略和权限控制。
怎么练：给 Agent 配一个独立的沙箱，故意把里面的目录写坏。确认宿主机没有受影响，任务状态也还能恢复。
验收：危险操作默认在沙箱里执行。权限写在 Tool Definition 里，不靠 Prompt 求模型"小心一点"。
5. 先看得见 Agent 在做什么，再让它变好
目标：看得见 Agent 在做什么，并且能持续改进。
学什么：直接看 Langfuse。可观测（Observability）的核心，把轨迹、工具调用、耗时和失败原因都存下来。评估（Evaluation）是一条"先优化、再验证"的流水线，不是偶尔手动测两个用例。
怎么练：接入 tracing。固定 10 到 20 个用例做回归测试。每次改了 Prompt、工具或编排，都用同一套评估看结果变好还是变差。
验收：出了问题，能定位到是哪一步、哪个工具。每次改动都有改动前后的对比。
6. 把前 5 步拼成能上线的平台
目标：把前面几块拼成一个能上线的平台，而不是一堆 Demo 脚本。
学什么：读 FenixAgent的源码。编排、调度和 Agent 协议对接，都是生产里绕不开的脏活。
怎么练：对照 FenixAgent列一份缺口清单，包括调度、协议、多租户和配额，然后按优先级补。别一上来就把整套系统重写。
验收：别人照着文档，就能把你的服务启动起来并跑通。不能只在你自己的电脑上能跑。
做产品但是苦于做产品宣传视频的朋友，你们的福音来了，使用这个skill配上OpenRouter上限时免费的Minimax模型，可以更方便的做一个产品宣传视频。
挖槽？！花叔这个 huashu-motion skills 是真的绝 🤯
我之前也用过不少 motion skill，没一个能做到这个效果
这次真的就一句话：“给我的项目做个产品宣传片
它直接给 Pi Agent Desktop 出了一整支 30 秒的片子”
最离谱的是模型用的是 MiniMax M3.1 Flash，现在在 OpenRouter 上免费爽用
搭配 Claude Code 开 Ultra Code，模型这块一分钱没花
花叔用的是 Opus 5.5，我用免费模型跑出来的片子也一点不虚 😭
装上只要一行：
npx skills add alchaincyf/huashu-motion
Jerry Fang retweeted
## SpaceX越来越像一家AI算力公司
SpaceX 2026 年第三季度营收 145.8 亿美元，同比增长 161%，净利润 44 亿美元，去年同期还亏 11 亿。这是它上市以来第一次季度盈利。
撑起这份财报的是 AI。超级智能业务单季收入 76 亿美元，同比增长 830%，占总营收 52%，首次超过 Starlink 所在的通信业务。通信业务当季 52.48 亿美元，航天业务 17.67 亿美元。
推动 AI 收入的一个具体来源是算力租赁。路透社报道，SpaceX 正向 Anthropic、Google 和 Reflection AI 等企业提供数据中心算力。截至 9 月底，其名义算力容量为 1.7 吉瓦，6 月底是 1.4 吉瓦，去年同期 0.6 吉瓦。
支出同样在涨。第三季度资本开支 195.93 亿美元，其中约 164 亿用于 AI 基础设施，超过当季全部营收。第四季度预计进一步增加到 350 亿至 400 亿美元。
#SpaceX #AI算力 #财报
最近看到一个新开源项目：LayerFS。
很多人一听「给 Agent 用的文件系统」，第一反应可能是：不就是给 Agent 挂个盘吗？
但 LayerFS 想解决的远不止这个。
当多个 Agent 同时修改一个项目时，怎么隔离工作空间、保存历史，以及处理冲突？
LayerFS 尝试直接在文件系统这一层解决这些问题。
几个设计挺有意思：
Agent 执行 Bash 时，可以按需挂载临时 Workspace，执行后提交修改，再卸载。
Fork 一个分支不需要复制整个项目，多个 Agent 可以基于同一份文件独立工作。
文件修改可以形成 Commit，随时查看历史、回退或者创建新分支。
多个 Agent 的修改发生冲突时，有明确的冲突处理机制，而不是直接互相覆盖。
存储优化也值得一提：官方测试中，157 个文件系统快照只占用了约 100 MB，比 Btrfs + zstd 节省了约 95% 的空间。
说白了，它有点像给每个 Agent 一本可以随时 Fork 的笔记本。
每个 Agent 各写各的，写完还能合并，遇到冲突也能知道问题出在哪里。
我觉得，对于多 Agent 并行开发来说，文件系统层的状态管理可能是一个值得关注的方向。
GitHub：github.com/Ephemeral-AI-Lab/…
做 Agent Runtime、Sandbox、可恢复执行的朋友，可以关注一下。
LayerFS v1.0.0 is out 🎉 Open-source (MIT)
Recursive filesystem for AI agents.
6 core ideas:
1. Ephemeral computing: agents spend ~80% thinking, so each Bash call mounts a Workspace, then commits
2. Decentralized agents: every agent commits to one Store, no DB server
3. Multiagent coordination: every tool call is a Commit; same-file clashes refused
4. Recursive filesystem: forks copy no files, at any depth
5. Ultra storage: dedup, then compression: 10 copies → 0.31
6. Instant bootstrap: ignored files stay in every Commit. ~5 min install vs 0.05 s mount
And 4 more:
7. Auto checkpoints: fork from any step
8. Append-only objects: content-addressed, never rewritten
9. .lww: lockfiles and caches take the newest edit
10. Big file, small edit: a write keeps only its bytes
Here are our links:
github: github.com/Ephemeral-AI-Lab/…
website: layerfs.ai/
Watch the video below, and have Fun!!!
Jerry Fang retweeted
LayerFS v1.0.0 is out 🎉 Open-source (MIT)
Recursive filesystem for AI agents.
6 core ideas:
1. Ephemeral computing: agents spend ~80% thinking, so each Bash call mounts a Workspace, then commits
2. Decentralized agents: every agent commits to one Store, no DB server
3. Multiagent coordination: every tool call is a Commit; same-file clashes refused
4. Recursive filesystem: forks copy no files, at any depth
5. Ultra storage: dedup, then compression: 10 copies → 0.31
6. Instant bootstrap: ignored files stay in every Commit. ~5 min install vs 0.05 s mount
And 4 more:
7. Auto checkpoints: fork from any step
8. Append-only objects: content-addressed, never rewritten
9. .lww: lockfiles and caches take the newest edit
10. Big file, small edit: a write keeps only its bytes
Here are our links:
github: github.com/Ephemeral-AI-Lab/…
website: layerfs.ai/
Watch the video below, and have Fun!!!
从0搭建一个Agent（1）：Agent Loop + Tool System
在Sitor上跟着“Super Agent实战课”完成了前两章的学习（Agent Loop + Tool System）。在这里做一下总结，希望能帮刚入门 Agent 的朋友少踩一些坑。
具体如何从0搭建一个Agent在这个系列中因为已经有Sitor上的“Super Agent实战课”的付费课程和Datawhale的hello-agents这样的开源学习资料，所以不会详细阐述，这个系列主要讲解在这个过程中需要注意的一些点。
第一，在使用模型API前先做一个Mock Model。
从0搭建一个Mock Model可以帮助我们更好的理解LanguageModelV3 接口，知道generateText 和 streamText是如何实现的以及它们之间的区别。
当然，既然是Mock Model，模型的回复就做的简单一些。
第二，在Agent Loop中需要加层层保护。
Agent Loop 的核心是：模型思考，调工具，拿结果，再思考。
但是如果不做好层层保护的话，在生产端的Agent Loop很难稳定运行。尤其是下面三种防护要格外注意：
1.循环检测：我们不希望模型在不断做事，但没有任何进展，尤其是下面两种情况：
（1）通用重复：同一个工具，同样的参数，同样的返回结果，然后反复调用；
（2）乒乓循环：两个操作来回交替，A→B→A→B，看起来是在“做事”，但实际毫无进展。
2.API容错：针对不同的API错误，采取不同的应对策略，而不是使用统一try-catch方案。关键是对API的报错做一个分类，对不同的类别采取对应的措施。
3.Token预算：我们不希望随着Agent的狂奔，消耗的金额不受控制。因此，设定一个token的预算对于控制整体成本是一道保险。
第三，模型和Agent Loop对于工具的关注角度是不同的。
模型关注的是怎么调用这些工具，想知道name, description, parameters等参数；
但是Agent Loop还需要知道工具A和其他工具能否并行执行，这些工具会不会改状态，结果会不会过长等等。这些模型不会关注，但是关乎到整个Agent的执行稳定性和效率，因此需要格外注意。
第四，理解如果不做工具的延迟加载，为什么工具越多，模型检索到正确的工具的概率可能会下降。
Jerry Fang retweeted
整理了《从零手写大模型之从GPT-2到LLaMA》学习教程
GPT-2到LLaMA，中间隔了4年
最关键的改动，集中在4个零件上
手写完GPT-2之后，我一直卡在一个问题上：
2019年的GPT-2
和今天的LLaMA、Qwen、DeepSeek，到底差在哪？
带着这个问题，我把LLaMA的结构拆开
一个零件一个零件对着GPT-2去学
学下来发现，骨架还是那个Transformer
真正变的是几个关键零件
每一篇都用同一个小例子“猫吃鱼”贯穿到底
数字小到可以手算，配套代码也能直接跑
看完可以自己跟着练一遍
最后整理成了这5篇：
01 RMSNorm：简化归一化
02 SwiGLU：升级前馈网络
03 RoPE：旋转位置编码
04 GQA：分组查询注意力
05 LLaMA：组装完整模型
对我自己来说，这一段是承上启下：
手写GPT-2，让我搞懂了Transformer怎么跑
学完零件替换，才算明白现代大模型为什么长这样
整理好的完整版放在这里
如果你也是从GPT-2入门的，可以直接接着看：
nano-ai.tech/series/gpt2-to-…
现在使用AI辅助自学真的是效率能提高很多，你可以不断让AI以自己能理解的说法/例子来讲解这些复杂的概念直到自己能理解。
AI是一个“不厌其烦”的老师，感觉回答不对劲就重开一个对话😊。
对LLM感兴趣的可以跟着纳米老师一起学习，大家加油👏
想了解大模型是如何训练和推理的朋友可以关注纳米AI的这个总结。
每一篇帖子中，纳米根据自己的理解讲解了训练或推理的一个知识点，因此大家可以根据自己的需要查看对应的帖子。
「从零手写大模型」系列完结了
nano-ai.tech/articles/
推理篇 15 篇，训练篇 5 篇，共 20 篇
从模型的基本结构
到如何生成文字，再到损失、梯度与参数更新
把学习过程整理成了一套完整笔记
每一篇都有可练习的代码示例
📖 推理篇 · 15 篇
01｜LLM From Scratch：整体大纲路线
02｜Tokenizer：分词器
03｜Embedding：嵌入层
04｜Positional Encoding：位置编码
05｜Self-Attention：自注意力机制
06｜Multi-Head Attention：多头注意力机制
07｜Residual Connection：残差连接
08｜LayerNorm：层归一化
09｜FFN：前馈神经网络
10｜Activation Function：激活函数
11｜Transformer Block：Transformer 模块
12｜Transformer Stack：Transformer 堆叠
13｜Loading Pretrained Weights：加载预训练权重
14｜Text Generation：文本生成
15｜Interpretability：可解释性
🛠 训练篇 · 5 篇
01｜Loss Function：损失函数
02｜Backpropagation：反向传播
03｜Gradient Descent：梯度下降
04｜Adam Optimizer：Adam 优化器
05｜Learning Rate Scheduling：学习率调度
推理篇，理解模型如何一步步算出下一个 token
训练篇，理解模型如何从误差中学习、更新参数
欢迎一起学习、交流，也欢迎指出笔记里的问题
如果你正在做 Agent，或者准备 Agent 相关岗位的面试，RAG 和记忆系统都是绕不开的知识点。很多人觉得 RAG 已经落后了，没有人使用了，但实际上，它是一种上下文管理策略，在很多现实的业务中，会将Agent与RAG结合，从而满足业务的需求。同时，在Agent的使用中，我们还需要考虑记忆的存储、检索和更新。
对于RAG来说，它不单单是"向量库 + 检索"，在真正落地过程中，问题往往出在切块、召回、排序和记忆管理上。
我最近梳理了一下这块的知识，整理了一份 RAG 与 Agent 记忆系统的学习路线，从"检索"到"记忆"，欢迎收藏，保存，我也会继续分享在这个领域的学习心得。
完整路线：
1.RAG 基础：理解“文档加载→分块→embedding→向量存储→检索→注入上下文”的完整流程。理论部分可以先看 2020 年 Lewis 等人那篇 RAG 原始论文（arxiv.org/abs/2005.11401），重点带着下面三个问题来看这篇论文：
•Introduction：为什么需要 RAG？传统参数化语言模型有哪些局限？
•Methods：RAG 如何将 Retriever 和 Generator 结合起来？
•Experiments：如何验证检索增强确实改善了知识密集型任务的效果？
2.文档检索：理解什么样的文档格式适合RAG，理解为什么代码检索不适合使用RAG。
3.分块：知道为什么需要分块，以及几种主流的分块策略（包括固定大小分块，递归分块，语义分块等）
推荐看一下一篇分块相关的文章：premai.io/blog/rag-chunking-…
4.Embedding 与向量检索：理解 Embedding 模型、余弦相似度，以及 ANN 近似检索（比如 HNSW 索引）。
5.存储（向量数据库的选型）：了解 sqlite-vec、Milvus、pgvector 这类工具的区别。知道在当前场景下，哪一款向量数据库最合适。
6.混合检索与 Rerank：理解“语义相似不等于任务相关“。向量检索 + BM25 关键词检索结合，再用 Reranker（Cross-Encoder）重新排序。要时刻记住：检索不是"搜到就行"，而是"搜到对的"。
7.索引更新：理解“全量重建”和“增量更新”两种策略，知道每一种策略适用于什么样的场景。
8.短期记忆：也就是 Context 管理，包括对话历史裁剪、摘要压缩，以及在上下文窗口有限的情况下保留关键信息。
9.长期记忆：跨 Session 保存用户偏好、事实和经验。
10.记忆的写入、更新与遗忘：什么时候该写入记忆，怎么处理冲突和过时的信息。可以看arxiv.org/abs/2304.03442这篇文章。
Jerry Fang retweeted
之前和 Yifan 聊 Multi-Agent Harness，听到了一个很有意思的设计。
他想让多个 Coding Agent 基于同一份项目状态协作，但不依赖 Git Worktree 来隔离每个 Agent。
他的思路是把沙箱隔离粒度缩小到每次 Tool Call。
每次工具调用都有独立的临时 Workspace，执行完可以保存为 Commit，也可以直接丢弃。底层通过 Zero-copy fork、COW 和内容去重，让不同 Agent 共享已有文件状态。
我第一反应是：你干脆重新发明 Git 吧。
但看完他的 LayerFS 设计文档，发现还真有点东西。
现在常见的 Agent 沙箱主要按 Task 隔离，而他希望做到 Tool Call 级别，让每一步操作都能独立执行、追溯、回滚和分叉。
这样不仅能支持更细粒度的多 Agent 协作，还能让 Agent 从任意保留的中间状态继续探索其他方案。
更有意思的是，他说这个想法半年前就写进 README 了。
