Banny｜嗯哌AI 主理人 · AI 工作流搭建者 NotebookLM 教程全网 50 万播放｜开源 Dify 工作流 GitHub 2.7k⭐ 白天搭能直接抄的 AI 工作流，晚上吐槽被 AI 坑的日常
Joined August 2023
- Tweets1.4K
- Following809
- Followers1.1K
- Likes1.4K
写代码快了，审代码成了瓶颈。LinkedIn 有 1 万多个活跃代码库，每周开几万个 PR（代码合并请求）——coding agent 几分钟写完一个 PR，人审不过来。于是他们自己搭了个 AI 审稿器：平时一周能覆盖 4 万多个 PR。它的评论大多抢在人前面——人还没点开这个 PR，AI 的意见已经贴在有问题的行下面了，写代码的 agent 能立刻照着改，不用等到人有空。
审稿的瓶颈不在"看不看得过来"，在"评论值不值得信"——只有当评论同时做到"有根据、有信号、懂这个库、赶得上"四条，并且每条评论都能被"代码真的改了"验证时，AI 审稿才算立起来。
我按 LinkedIn 的做法给自己立了四条：
1.先定四条标准：有根据（指出改动行里的真问题）、有信号（真 bug 和高风险行，不是格式小毛病）、懂这个库（按这个库自己的规矩）、赶得上（作者还能动手改的时候就贴出来）。四条缺一不可。
2.别买通用审稿器：LinkedIn 先试过厂商托管的，评论又吵又通用，工程师纷纷退出——首席工程师 Min Chen 的话："东西不是你的，他们改点什么，你只能跟着反应。"先写你自己的规则。
3.一个模型审稿不够，至少两个互相验：多个 agent 并行独立审（互相看不见对方的结论，撞在一起才算证据），重叠的合并、按可信度排序，孤证再找另一个模型核验，核验不过的降级或过滤。
4.用"代码真的改了"当验收：别数点赞，数因为评论而改了的代码。LinkedIn 的接受率是 63.9%，并发 bug 和死代码 100%、逻辑错误 80%。每天看一次接受率的变化，哪条规则掉队就停掉、哪个提示词掉队就改。
审稿不是看得多，是信得过——信不过的评论，比没评论更贵。
你现在审 agent 写的代码，最花时间的是哪一步？是读，还是验它说得对不对？
源链接：blog.bytebytego.com/p/how-li…
8
一个模型带着一千多个 agent，昼夜不停干了 8 天，从空文件夹写出一个能启动的操作系统——Fable 5.2 出来了。
Anthropic 11 月 9 日发布了 Fable 5.2 和 Mythos 5.2。发布前测试里，它帮工程师完成了原本做不了的软件迁移、从零设计了三台能用的电子设备、解了两道黑洞物理的公开难题、30 小时把费马大定理的证明翻成计算机能一步步验的语言。但新模型一出，大家先问"它比上一代强多少"，问错了——Fable 5.2 的问题不在强多少，在"它能独立干多久"。
Fable 5.2 的分水岭不是"更聪明"，是"能独立干多久"——只有当你手里有"值得交给它跑一夜、甚至八天"的活时，它才值那个慢和那笔账；日常活还是从 Opus 5.5 起步，对口才往上切。
我按官方公告和 Every 的实测给自己立了四条：
1.先找"过夜级"的活：能拆成步骤、有明确验收标准、中间不需要你拍板的。Anthropic 自己的例子：一千多个 agent、昼夜不停 8 天、从空文件夹写出一个能启动的操作系统（自己的内核、驱动、文件存储、窗口、登录界面、安装器）；一千个 agent 花 30 小时把费马大定理的证明翻成计算机能一步步验的语言，同样配置下 Opus 5.5 18 小时只完成 26%。临时起意的小活不配。
2.日常活别上来就用它：Anthropic 自己的建议——大多数编码和知识任务从 Opus 5.5 起步（最强日常主力），范围和复杂度够了再往上切到 Fable，简单的往下切到 Sonnet 或 Haiku。
3.档位从低往高试，价格按任务算：最高档常常更差——Every 的实测结论，也是 11 月 2 日推理档位帖的同一条教训。先低档，检查过的失败才加档。在 Anthropic 自己的编程基准测试里，Fable 5.2 高档接近 Opus 5.5 最高档，任务成本大约一半；标准价是输入每百万 token 8 美元、输出每百万 40 美元，比 5.1 的 10/50 便宜了，输出还快 30%。
4.给它留一夜，也给自己留验收：跑完先验——能用、能改、能接手，才算完成；验收不过就回滚，别让"跑了一夜"变成"必须用"的理由。
新模型的第一道题不是"它多强"，是"你有没有值得交给它跑一夜的活"。
你手里现在有没有一件"值得交给模型跑一夜"的活？是什么？
源链接：teapawt.net/claudeai/status/211986…
Introducing Claude Fable 5.2 and Claude Mythos 5.2, designed to tackle the most daunting technical challenges.
They’re capable collaborators on ambitious projects in many fields, and show improvements in areas like coding, reasoning, and vision.
7
Notion 的 CEO Ivan Zhao 在 Every 的 Thesis: 2027 上说了一句全场都在传的话："I don't think we should surrender our understanding."——别把理解也交出去。
他的警告很具体：一个团队里人人都有自己的 coding agent，一个中等规模的代码库，一周之内就能变得没人看得懂。代码越写越快，理解却在流失——出问题时，没人知道该从哪下手。
agent 写代码越快，人越要留一个能看懂代码的口子——只有当 agent 的每一步都落在人能看见的板子上、每次纠正都变成能重跑的检查时，提速才不是透支理解。
我按这场会的三个现场给自己立了四条：
1.给 agent 的活立一面"看板"：Notion 现在的做法——所有 agent 的工作过一道共享看板，人随时能看见它在干什么、干到哪了。看不见的 agent 工作，等于没人负责的代码。
2.每周留一次"读代码"的时间：不是写，是读——agent 上周改过的模块，你能讲清它为什么这么改吗？讲不清，下周先别加新功能。
3.把每次纠正变成一道是非题：Every 评估负责人 Mike Taylor 在现场的课上说，评测不需要多厉害，你只需要有自己的看法——每次你纠正模型，就把它变成一道能反复跑的检查，新模型来了先跑这套题。
4.别只攒产出，攒"看法"：Every CEO Dan Shipper 的收尾——人人都有同一个模型时，默认答案不值钱，值钱的是你往上加的那层看法。每次交付多写一句"为什么是我这么定"。
模型给的是默认答案，你给的是答案之上的看法——后者才是你的工作。
你上周 agent 写的代码，你现在能讲清它为什么这么改吗？讲不清的那块在哪？
源链接：every.to/context-window/what…
LangGraph、CrewAI、OpenAI Agents SDK、Claude Agent SDK——你分得清它们到底在争什么吗？
框架越选越多，名字都像、功能表都像，选完才发现"下一步谁说了算"完全不同。
ByteByteGo 这期把六个最常用的编排框架摊开一比，差别一下子就清楚了：编排管的不是 agent 干什么，是任务跨 agent 流转时，下一步由谁决定、失败了谁接手、共享的记忆和上下文放哪。
选编排框架别看功能表，看"下一步由谁决定"——能事先写死的用图，需要人中途拍板的要检查点，只有跑起来才知道的让模型自己定；连"要不要编排层"本身，都是一个可以选"不要"的选项。
我给自己立了五条选法：
1.顺序和审批能事先写死 → 用图：LangGraph 把工作流画成节点和边，边决定状态怎么流转；微软的 Agent Framework 也是图，再加分支、检查点和人工暂停，适合组织级流程。
2.角色分工明确、按顺序或由人统筹 → CrewAI：每个 agent 领一个角色和目标，顺序跑，或者由一个 manager agent 统筹。
3.下一步只有跑起来才知道 → 让模型自己定：OpenAI Agents SDK 是模型驱动的运行时，agent 自己决定把控制权分出去还是自己干完。
4.开发者定策略、根 agent 拆任务 → Google ADK：混合控制，开发者定好策略，根 agent 把任务拆开分给子 agent。
5.或者干脆不要编排层：Claude Agent SDK 没有单独的编排层，编排就活在 agent 循环里——攒上下文、调工具、评估、一直干到没有调用为止。
不管选哪个，三件事必须写进同一层：失败了谁接手、共享记忆和上下文放哪、哪些步骤要人批。别让它们散在各处。
顺带说一句，同一期里还有一张"一次请求在 Claude Code 里怎么走"的图，正好能验上面这套：提示词进来 → 界面裹上仓库和文件上下文 → agent 循环提议动作（比如改 auth.ts 第 42–58 行）→ 权限系统按规则检查 → 通过的动作变成工具调用 → 在执行环境里真正跑 → 结果回传循环 → 存盘并回消息。整个系统就是这个循环一直转，直到模型不再要工具。注意第 4 步：权限检查是卡在"提议"和"执行"之间的——撤销规则就该写在这里，而不是写在提示词里。
编排层管的不是 agent 干什么，是下一步谁说了算。
你现在搭 agent 系统用的是哪一套？"下一步谁说了算"这件事，你写死在图里，还是交给模型了？
源链接：blog.bytebytego.com/p/ep232-…
7
4
143
镜界 | Mirror
把别人的网页量一遍，让 Harness 里的 agent 用纯 HTML + CSS 写一份你自己的，再按同一套尺子逐条改到像。
这是一个 DeepSeek Harness 桌面端插件。你不用写代码：写页面、改差异都是 agent 干，你只负责在面板上点按钮、看分数、看结果。
技能不是越多越好，是越"有规矩"越好——只有从已经跑通的工作流里长出来、带着质检清单、出错就地修的技能，才值得留；否则技能越多，维护的债越多。
我的创建skill的六条方法清单：
1.先跑通再打包：别给还没干好的活建技能。先跟 Claude 手动做几遍，摸清流程、摸清它常在哪滑倒，做到"不用改就能发"的版本，再说一句："把我们刚做的变成技能，步骤和我们定下的标准都写进去。"
2.技能里不放品牌：方法放技能，品牌声音、受众、例子放单独的品牌文件，技能去读它。定位一变只改一个文件；给 3 个客户做内容研究，也只要 1 个技能加 3 个品牌文件。
3.技能末尾挂一张质检清单：单独成文件，交稿前先自查——博客看关键词在不在第一段、每个说法有没有来源；研究看每个数字有没有日期和能打开的链接；广告看字符数和优惠对不对得上落地页。清单只写"对照品牌文件检查"，禁用的词、语气这些品牌规则留在品牌文件里。
4.每几周审一次技能库：技能长得比你想象的快，坏了重建一个比修旧的容易，几个月后就一堆干同一件事的。让 Claude 逐个给"留、改、合并、删"的建议，先给方案不许动手，重叠的合并掉。
5.出错当场修技能：别只改稿子就走。同一会话里让 Claude 回查技能、说清为什么错、改成一条通用规则再存。只存对以后有用的修法，太具体的个案不存。
6.按工作建库不按工具建：研究、内容、汇报三分，放共享盘或 GitHub，团队共用同一套打法。起名按功能开头（比如 seo-关键词研究、seo-内容简报、seo-站点审计），相关的排在一起，重复的一眼就能看见。
技能不是 agent。技能是标准动作，agent 是临场判断——决定用哪个技能、什么时候用。先把技能立好，agent 自己就变好了。
5
3
286
Muse 的可玩性还是非常高的，尤其是最近上新的 space（空间）
说一句话，它就在 Muse 里给你长出一个小 app
还能定好时间，到点自己跳到首页
扎克伯格自己已经玩起来了：BBQ 游戏、活动追踪器、家居控制面板，全是跟 Muse 说出来的
我把能直接抄的玩法整理好了 👇
【它到底是什么】
你描述一个想法，Muse 给你搭一个小 app，直接长在 Muse 里
搭完不是定稿：缺什么让它补、不好看让它换、不顺手让它改逻辑
在里面能打勾、记笔记、改内容，下次打开都还在
连上你的 app（Gmail、Google Calendar、OpenTable、Notion 这些），它会在后台自己更新：演出日期、价格变化、存钱进度，不用你去问
【最被低估的一点：app 的样子你说了算】
每个 space 都可以：
放侧边栏，或者升到主 tab
暂时用不上就隐藏
定时出现
官方的例子：工作日把周计划放在最前面，周六自动换成周末安排
这就是它和 Dify、Notion 模板最大的区别：
那些是你去找工具
这个是工具按时间来找你
【能直接抄的实例】
🛒 生活
•按人分的节日礼物清单
•收藏了一直没去吃的餐厅合集
•购物中心：礼物想法、Instagram 收藏的心愿单、Marketplace 上架的商品和买家消息放在一个页面
•集币差一枚凑不齐？让它帮你盯所有在售信息
👨👩👧 家庭
•学校看板：从学校邮件里挑出和你家孩子有关的活动，自动加进日历
•婚礼策划：宾客回复名单、供应商发票、待办
•旅行计划：航班、酒店、预订、按天排的行程
•节日做饭：Meta 的 David Singleton 拿它规划感恩节菜单，当天直接当指挥中心
💼 工作 / 副业
•小生意订单追踪：新订单、客户消息、今天要发什么货
•自由职业客户中心：项目、截止日、发票
•私信分拣：按对你生意的重要程度排私信
•播客工作室：选题、资料、脚本放一起
🎮 好玩的
•问答游戏：考你最爱的电影、音乐、球队
•小游戏：官方演示的 Jolly Jump，整个都在 space 里做的，没用游戏引擎
•音乐追踪：喜欢的歌手出新歌、开演出都在这里看
【描述 space 的写法，照着填】
做一个 [用途] 的 space
里面要有：[3-4 样东西]
数据从 [哪个 app] 拿，有变化自动更新
我要能直接 [打勾 / 记笔记 / 改]
[工作日早上 / 周末 / 某个时间] 放到主 tab
例子：
做一个孩子的学校看板，从学校邮件里找活动和截止日，加进 Google Calendar，我能打勾标记已处理，工作日早上放主 tab
最后一行最容易漏，也最值钱：不写的话，它就只是一个你会忘了点开的页面
【提醒】
•Muse 目前在美国和日本上线，没有中国大陆
•现在还不能把 space 分享给别人，官方说还在研究
•连的 app 越多，它能看的就越多。邮箱、日历想清楚再授权
你第一个想搭的是哪类？回个 emoji：
🛒 生活 👨👩👧 家庭 💼 工作 🎮 好玩
哪类最多，我就把那类的描述写法单独拆一篇
前两天我说"计算机专业没死，反而要爆发"，引起了大家热烈讨论，刚刚我刷substack 看到Engineering Leadership 的主理人 Gregor Ojstersek @gregorojstersek 发了一句：
"我改变了对计算机科学专业的看法。
我以前认为这些基本知识并不重要，但现在人工智能可以生成大部分代码，良好的工程学基础比以往任何时候都更加重要。而且，计算机科学专业的课程也主要侧重于基础知识。"
他真正想说的是：AI 越强，基础越值钱。
前两天我说代码是 AI 时代的"新英语"，今天再补一个更扎心的类比：
计算器普及几十年了，数学系被淘汰了吗？
没有。计算器只负责算，算式列没列对，还得懂数学的人来判断。
AI 也一样，它负责写，写得对不对，得懂底层的人来判断。🧮
他评论区有个真实故事：
一个负责代码审查的人，连 n 和 n² 的区别都搞不懂。
AI 写得再漂亮，最后也是他点"通过"。这样的系统，你敢用吗？
所以 AI 时代真正的分水岭是：
❌ 只会让 AI 写、看不懂 AI 写了什么的人：第一批被替代
✅ 懂数据结构、算法、操作系统、网络的人：AI 是他的放大器
Gregor 亲自列的"AI 时代底层必修课"，我放在评论区第一条👇
最后说句得罪人的：
读不读这个专业是一回事，啃不啃底层是另一回事。
四年混文凭、作业全丢给 AI，还不如一个自学啃透底层的人。
AI 时代，计算机科学是"贬值"了，还是"升值"了？
评论区站队👇
#AI #程序员 #志愿填报 #计算机科学 #科技趋势
很多人都在唱衰计算机专业，
说 AI 时代程序员要失业了。
这绝对是今年最大的认知底层误判。❌
相反，我的判断是：
计算机专业正在迎来它历史上最恐怖的爆发期，它将变成未来唯一的“超级专业”。 🚀
很多人没看懂这个底层的底层逻辑，我用一个最简单的类比告诉你为什么：
30年前，全中国最吃香的专业之一叫“英语”。
因为那时候谁能和世界沟通，谁就能拿到改写命运的入场券。
而在 AI 时代：
计算机语言（Code），就是这个时代的“新英语”。
计算机思维（Computational Thinking），就是你和未来世界唯一的沟通工具。 🌍
觉得代码能被 AI 自动生成，计算机就没用了？
这就好比当年有了有道词典和谷歌翻译，你就觉得不需要学英语了一样短视。
1️⃣ 懂行的人才能当好“甲方”：
AI 是最听话的打工人，但只有懂计算机底层逻辑的人，才能给出最精准的指令（Prompt），才能在 AI 生成的万行代码里，一眼看出致命的 Bug 和安全漏洞。
2️⃣ 传统码农会消失，但“超级工程师”正在诞生：
以前一个系统需要 10 个人干 3 个月；现在一个懂架构的顶尖工程师，带 3 个 AI 助手，3 天就能拼装上线。AI 没有淘汰计算机专业，它只是给懂计算机的人发了一台“无限续航的放大器”。
💡 未来的大趋势：
就像当年的英语一样，计算机将不再是一个独立的学科，而是演变成所有行业的“生存标配”。
单纯只会敲两行 Python 的人会被淘汰；
但“计算机底层 + 传统行业（医疗/金融/制造）”的复合型人才，将拿走这个时代最高的薪资，拥有对世界最绝对的“建造权”。
盲目唱衰计算机，不过是平庸者在为自己的不思考找借口。
你觉得未来5年，计算机还会是普通人逆袭的第一专业吗？欢迎在评论区留下你的毒辣观点。👇
#AI #程序员 #志愿填报 #科技趋势 #创作者经济
4
9
542
Gregor 列的 AI 时代底层必修课：
至少精通一门编程语言，离开 AI 也能独立完成工作
数据结构
算法
操作系统是如何工作的
网络是如何运作的
他还说了一句很关键的话：工具越来越好，很多人会直接跳过基础，这正是危险所在。
原帖：substack.com/@gregorojsterse…
1
66
10 小时前我发了条多 agent 协作的心得，73 次浏览
复盘了下，问题在我：开头就讲道理，没人想看道理 🙃
换个问法：
B 刚写完后端，C 接手写前端
C 打开项目，第一件事干嘛？
找。B 的接口在哪、改了啥、哪些没做完
我现在让每个 agent 收工前写一份交接文件，必须写死：
•文件路径
•接口
•做了哪些决定
•还没做完的
再加一条：任务板只有"项目经理"那个 agent 能改
你现在同时跑几个 agent？回个数字就行
跑 3 个以上的，我想挨个问问你们交接怎么写的 👀
多 agent 协作拼的不是分工表，是交接的规矩，只有交接文件写死路径、接口、决定和未完成项，多个 agent 才是一支队伍，否则就是各干各的。
可以这样做：
1、角色定死，各管一摊：A 当项目经理，只负责拆任务、验交接，而且只有它能改任务板；B 管后端（数据库、接口、服务器逻辑）；C 只按 B 写明的接口文档写前端；D 按需求验收，有缺陷退回给责任人。
2、状态全放共享文件里：任务、项目上下文、交接记录都在一台共享电脑的文件上，下一棒直接读文件接着干，不靠口头传话。
3、每次交接写四样东西：文件路径、接口约定、做了什么决定、还剩什么没做完。不写"好了"，写"好在哪、还差什么"。
4、开工前先核对现状：Bay 动手前先查一遍后端现在是什么样，再开始写。否则一个错假设进了交接文件，就成了前端的实现计划。
这套东西跑在 Grok Bot 上，后端用的是 InsForge（Postgres、鉴权、存储、边缘函数，开源 Apache 2.0），它的云命令行能让 agent 直接查后端状态、读表结构、跑迁移、部署函数——agent 动手前先看一眼现状，靠的就是这个。
agent 之间传的不是消息，是证据；没有证据的交接，就是让下一个人替你猜。
你现在让几个 agent 一起干活？最近一次因为交接不清返工，是卡在哪一句上？
teapawt.net/akshay_pachaar/status/…
附一个交接文件模板，直接抄 👇
【交接文件】
任务编号 / 任务文件：
写的人：
交给：项目经理（审完再往下传）
存放：handoffs/ 文件夹，消息里只发路径
1.文件路径
•改了哪些文件：
2.接口约定（下一个人照这个做）
•新增或改动了什么：
•输入 / 返回的格式：
•所有错误码：
•决定不处理的情况：
3.做了哪些决定，为什么
•
4.还没做完的
•
•卡在哪：
5.验证（测试来填）
•对应哪条验收标准：
•结果：
•没测的，以及原因：
规则：
•不确定的写"未确认"或"平台默认"，不要编
•缺文件路径、接口约定、未完成项的，项目经理直接退回
•接手的人先核对现状再动手，接口约定不清楚就问项目经理，不要猜
•任务板只有项目经理能改，其他人只写自己的任务文件和交接文件
1
41
多 agent 协作拼的不是分工表，是交接的规矩，只有交接文件写死路径、接口、决定和未完成项，多个 agent 才是一支队伍，否则就是各干各的。
可以这样做：
1、角色定死，各管一摊：A 当项目经理，只负责拆任务、验交接，而且只有它能改任务板；B 管后端（数据库、接口、服务器逻辑）；C 只按 B 写明的接口文档写前端；D 按需求验收，有缺陷退回给责任人。
2、状态全放共享文件里：任务、项目上下文、交接记录都在一台共享电脑的文件上，下一棒直接读文件接着干，不靠口头传话。
3、每次交接写四样东西：文件路径、接口约定、做了什么决定、还剩什么没做完。不写"好了"，写"好在哪、还差什么"。
4、开工前先核对现状：Bay 动手前先查一遍后端现在是什么样，再开始写。否则一个错假设进了交接文件，就成了前端的实现计划。
这套东西跑在 Grok Bot 上，后端用的是 InsForge（Postgres、鉴权、存储、边缘函数，开源 Apache 2.0），它的云命令行能让 agent 直接查后端状态、读表结构、跑迁移、部署函数——agent 动手前先看一眼现状，靠的就是这个。
agent 之间传的不是消息，是证据；没有证据的交接，就是让下一个人替你猜。
你现在让几个 agent 一起干活？最近一次因为交接不清返工，是卡在哪一句上？
teapawt.net/akshay_pachaar/status/…
我现在的肌肉记忆：看到 deepseek harness 弹更新，先存档、先停任务、先深呼吸。
因为大概率不是点一下就完事，而是要打开日志、翻进程、找是哪个插件在关停时没松手。
1 块钱 token 换一次更新，说不心疼是假的。
最后还是手动装的。
每次更新，基本都要先陪它来一轮大修复。这次自动更新连试几次，报错换了好几种。
查下来两个原因：
1. 插件的定时器在关停后还去读已经关闭的数据库，抛异常，进程直接退出。
2. 关停时连接池不放手，5 秒兜底一到进程先走，"已关停"的回执没发出去。
修完第一处，第二处还在。最后不折腾了，解压安装包替换，2 分钟装好。
我不是黑它。这套东西我天天用，插件也自己写。但更新是最高频的操作，它的可靠性还配不上它的能力。
你更新 DSH 时卡在哪一步？
5
8
1,555
我现在不让一个 agent 审稿，我组一个评审团。
科技记者 Kevin Roose 写新书《The AGI Chronicles》，450 页一年写完，人类编辑和研究员都配齐了，还用 NotebookLM 整理研究资料。
审稿时他又组了一个 Claude 评审团：一个 AI 怀疑者、一个 AI 史学家、一个按传记作家手艺标准、只管故事好不好读的工匠；再由一个主编 agent 把几份反馈合成一份文档。结果评审团抓出了几处人类编辑漏掉的事实错误。
所以我的论点是：审稿不能只靠一个视角——只有当评审团里有唱反调的、有查背景的、有管可读性的，审稿才算立体；否则一个 agent 的盲点就是你的盲点。
我现在审稿就三步：
第一，定三个角色：怀疑者专挑事实和逻辑漏洞，史学家查背景和说法出处，工匠只管读起来顺不顺。角色不同，盲点才不重合。
第二，再加一个主编 agent，把三份意见合成一份，不直接改原文。合成归合成，改还是人改。
第三，人做最后一道：对合成意见拍板，事实错误人工再核一次。评审团抓到的是"几处"，不是全部，别把它当成免检章。
审稿团里没有唱反调的人，审稿就是走过场。
你现在审稿是几个人（或几个 agent）在看？有没有一个专门负责挑刺的？
every.to/podcast/the-inside-…
4
9
544
Anthropic 每天合入 3 万次代码之后，Git 成了瓶颈。
按 Anthropic 自己的说法，合入量从 2026 年 5 月每天约 2500 次涨到 9 月每天超过 3 万次。
主分支历史近 100 GB，压缩后的工作副本超 25 GB；CI 每天约 2500 万次 checkout，还没算开发者环境、agent 沙箱和研究任务。按每次 checkout 传一份压缩工作副本算，每天超 600 PB 流量。
Git 的办法他们都试过：浅克隆、稀疏检出、部分克隆、内部镜像、种子。高峰时几百个内部镜像要互相保持同步，合入一加速种子就过期，局部数据又让历史操作变难。问题是两面的：既要快速接纳新变更，又要把代码分发给海量消费者，只改善一面，另一面就成瓶颈。
所以我的论点是：版本控制该把活放哪边，取决于谁在用代码——当主要消费者从人变成 agent 和自动化任务，本地独立就不划算了，得把运算收回服务器、客户端只拿需要的对象。
我现在判断一套版本控制扛不扛 agent 规模，就问三句：
第一，谁在消费你的仓库？人还是自动化任务？后者占大头，就别再为本地独立买单。
第二，每次任务是不是都在重复下载、存、维护同一份数据？是，说明你在为"每人一份完整仓库"付税。
第三，问个问题——某行是谁改的、某个历史差异——是不是非要先备好整个本地仓库？是，就把这类运算变成服务接口：客户端只问答案，不拼历史。
Git 给人独立，Scion 给机器省事。
还有一句值得记：Scion 团队的开发者都认为 Claude 写代码比他们强，但他们的活没消失，只是变了——从写代码，变成拦住 Claude 不让它走错路。
你的仓库现在多大？上一次因为 clone 太慢、镜像不同步吃亏，是什么时候？
New on our Engineering blog: Creating in-house source control.
In May, we merged around 2,500 code changes per day. In September, we merged more than 30,000 per day. As a result, we became bottlenecked by developer infrastructure built for human (rather than agent) scale.
Here, we share how we built a new version control system—and fully migrated our monorepo from git—in five months: anthropic.com/engineering/re…
7
4
216
你知道 DeepSeek Harness 桌面端的升级机制吗？
明明看到 GitHub 发布了 0.2.2-rc.1，为什么 DeepSeek Harness (DSH) 桌面端点击「检查更新」，却死活提示「已是最新版本 0.2.1-rc.5」？🤔
别急，你不是一个人！这背后藏着大厂软件常用的更新防崩溃机制：通道隔离（Channel Isolation）或灰度发布（Canary/Grayscale Deployment）。👇
1️⃣ 通道隔离机制 (Beta vs. Stable)
•📦 0.2.1-rc.5：属于 0.2.1 这一代 Release Candidate（发行候选）的演进版本，通常被归在当前的 “预发布 (Pre-release) / 稳定测试通道”。
•🚀 0.2.2-rc.1：是全新大版本周期的第一个候选版（RC1），通常包含底层依赖、插件接口的重大调整，目前被归在 next（尝鲜/预发）标签下。
•💡 大白话：客户端默认只认 latest。只要官方没把开关做进 UI，自动检查更新就会选择性“失明”。
2️⃣ 精准分桶灰度 (Canary 30%)
•跨版本大更新如果直接全量推送，一旦有严重 Bug 就会导致所有用户的 Mac App 集体崩溃。
•官方通常会配置灰度策略，首批可能只对 10% 的随机设备开放。如果你不在首批名单里，更新接口就会继续让你停留在最稳健的 0.2.1-rc.5。
• 这次0.2.2-rc.1版本更新，官方只放 30%，我这台分桶 31.8%，约七成用户同样收不到。
作为无情的数据分桶受害者，你今天被卡在百分之几了？有人成功分到前 30% 体验到新插件了吗？
#DeepSeek #DeepSeekHarness #DSH #macOS #软件科普 #开源社区
12
22
7,589
你日常的“主力 Agent”是谁？是坚守一个“全能款”，还是搭好了“多 Agent 分发”的流水线？ 👇
🚀 第一梯队：生产力与工程硬核底座 (Hardcore Runtimes)
以 Claude Code、DeepSeek Harness、Hermes Agent、PI Agent、Codex 为代表。
它们是常驻终端、带沙箱、主打 Agent Loop 的“重装武器”。不需要你调教，专门用来啃硬骨头——直接在本地改 Bug、做大规模 Trajectory 评测、或者处理高难度的模型调优。
👤 第二类：个人生活与泛用分发助理 (Personal Assistants)
以 OpenClaw、Muse、Grok Bot、Dots、Duet 为代表。
它们是贴身的数字秘书，擅长打通你的私有数据、社交网络和日常工作流。用来整理收件箱、处理报销、甚至在 X 上实时互动并自动把任务外包分发。
