CS146S 那个 Agent 架构讲座像一盆冰水浇醒我。接着几条推全在戳一个点：当 Agent 能自己写、跑、测、回滚，我们还在那点 PR、填 CR 表格，是不是在用马车缰绳勒自动驾驶汽车？
收集区间：2026-10-11 – 2026-10-18（JST），共 5 条。
Agent 怎么落地
斯坦福新课教你怎么让 Agent 真正 7×24 自动跑起来
🚨斯坦福 CS146S 刚刚放出了一个 45 分钟的硬核讲座实录 毫无保留地教你如何真正搭出一台 7×24 小时完全自动化运行的 Agent： 从底层的无状态休眠与事件唤醒机制、到主从多 Agent 任务解耦、上下文指针化压缩，以及那些没人告诉你的工业级 Harness 调度逻辑。 市面上那些动辄几千刀的 Agent 架构课， 干货密度可能连他头 10 分钟的一半都达不到。 而且最爽的是：完全开源免费。 不管你是刚接触自主Agent ，还是像我一样天天在终端和容器里死磕系统调度… 看完这个，你会用一种全新的架构师视角去重塑你的 AI 系统。 强烈建议码住。 以后你每次设计自动化 Agent 架构的时候，都会回来翻看无数遍。 https://x.com/leerob/status/2108650243365736855/video/1
这是在说什么
跳表（Skip List）是种链表升级版，像地铁快线+站站停组合，这里指 Agent 任务调度时跳过空闲状态直接唤醒；上下文指针化压缩，就是不传整段对话历史，只传关键句的内存地址——类似微信聊天里只发「见第3条」而不是把前 200 条重发一遍。这课讲的是怎么让 Agent 不卡死、不爆内存、不互相抢活干。
我们能学到什么
- 别先堆 LLM，先搭好事件驱动+无状态休眠的底座
- 多 Agent 解耦不是分角色，而是按‘谁该对哪个错误负责’来切
- Harness 不是监控面板，是让失败任务能被其他 Agent 接手重试的胶水
Agent 不需要 PR 流程，人类那套 Git infra 正在被重写
围绕 Pull Request 和代码 review 的一切，都是最初设计给人用的： 所以现阶段非常别扭，实际上是 Agent 完成了一切，人在整个过程中的假装 review ，复制黏贴，甚至 PR 政治斗争，完全拖慢了 Agent 的节奏。 事实上，对于 Agent 来说，拥有对代码 diff 的上帝视角，它不需要 PR 来停下脚步展示做了什么，为什么这样做。 成千上万个 Opus 5.5 subagent，不需要可怜的人类。 所以 Anthorpic 重塑了 git，这几十年来为人类开发者做的整套 infra 一定也会迅速改变。
这是在说什么
CDN 是内容分发网络，像全国快递前置仓；Cache-Control 是 HTTP 头，告诉浏览器‘这张图 1 小时内别再问服务器要’；这里类比的是：Agent 天然自带缓存、预热、就近执行能力，PR 这种‘先打包、再提交、等人批’的流程，对它就像给高铁修绿皮车站。Anthropic 重写 Git，本质是让每次 diff 都自带可执行上下文和回滚快照。
我们能学到什么
- 新项目 Git workflow 直接从 trunk-based development + auto-merge 开始
- PR 描述模板里删掉‘请 reviewer 注意’，换成‘本次变更触发的 3 个自动验证结果’
- 把 CI/CD pipeline 拆成 agent-native 的 event-driven chain，而不是 shell 脚本串行
Code Review 别背八股
大厂真人代码评审其实多数走形式，连边界检查都难全覆盖
看到有一些关于AI code review的争吵 其实大厂真人CR作用不大 原因是： 你要CR的代码是别人用了好几天 绞尽脑汁认真写的 你仅凭短时间是看不出太多问题 最多只能看出一些常规问题 比如命名不规范、边界没处理、少个判空 再深一点的逻辑漏洞、设计问题，基本看不出来 而且这个工作不在你的KPI里 所以多少有点走过场的意思 想起一个比较搞笑的瞬间 以前腾讯的CR平台有个BUG 就是自己发出CR，这个评审人可以填自己 当时有些人 为了快速合并代码，走编译平台发布测试 直接自己发CR，自己通过的操作.......
这是在说什么
按常理理解是：人脑短期记忆有限，看别人写了几天的代码，就像让你快速听懂一段没字幕的方言播客。命名、空指针这些规则类问题还能扫一眼，但模块耦合度高不高、状态机有没有漏分支，靠人工 CR 基本靠运气。更别说没人考核你 CR 质量，KPI 只盯你合没合并。
我们能学到什么
- 把 CR 时间省下来，加到单元测试覆盖率和 contract test 上
- CR checklist 必须带自动化检查项（比如 ‘是否调用了已标记 deprecated 的函数’）
- 发现有人自己给自己 CR，就该立刻关掉那个平台的自评开关
不 review 代码，反而可能提升质量？这是个正经工程问题
旧文新读，与其讨论有没有 code review，不如直接试试真别 review 了，研究一下不 review code 如何控制项目质量，这是一个很有挑战性但解决之后结果上限很高的工程问题（不仅仅是软件工程）
这是在说什么
这条不是鼓吹放任不管，而是说：与其把质量押在‘人眼能不能看出 bug’上，不如押在‘代码能不能自己证明它没错’上。比如用 property-based testing 生成千组边界输入，或用 formal spec 工具验证状态迁移合法性。这比让三个人各看一遍同一段代码更可靠。
我们能学到什么
- 把‘必须有 CR’改成‘必须有可复现的验证证据’
- 优先建轻量级 pre-commit hook，自动拒收没覆盖新增路径的 PR
- 质量目标不是‘零 bug’，而是‘bug 出现后 2 分钟内自动 rollback’
岗位现实
人类 Reviewer 也管中窥豹，AI 幻觉不该是‘有人审就安全’
即使有人 Review 也不代表可以站在全局角度审视 AI 代码。人类一样会管中窥豹，一叶障目。 参与过集体（完全由人类）开发的大型项目，这种体验会更加明显。功能不断累加，你只能相信其他人开发的部分，而不是妄想一个人能掌握全局。 “有人的介入就能避免问题。”已经变成新的 AI 幻觉。
这是在说什么
B+ 树是数据库索引常用结构，像图书馆目录柜——只存关键页码，不存全文；这里类比的是：每个开发者只掌握自己模块的‘目录’，没人真记得所有接口的副作用。所以指望人类 Reviewer 全局把关，就像指望图书管理员光看目录就发现某本书被偷偷篡改了内容。
我们能学到什么
- 强制要求每个 PR 关联变更影响图（哪怕只是 auto-gen 的 call graph）
- 新人 onboarding 时第一周不写代码，只画他要改模块的依赖快照
- 把‘全局视角’从人脑转移到可观测性工具链里