智汇AI

模型额度、Agent 工作流与能源底座 - 2026-07-13

Mon, 13 Jul 2026 00:00:00 GMT

今日主线

今天这批 follow-builders 内容有三条主线。第一，GPT-5.6 Sol 和 Claude Fable 5 都在围绕付费访问、额度、成本和社区沟通继续调整，模型能力之外，产品可用性开始变成用户最敏感的问题。第二，Agentic coding 不是只停在“能写代码”，它开始进入会议转 PRD、并行实验、企业模型路由、eval 和数据控制这些真实工作流。第三，No Priors 这期把 AI compute 的电力问题拉到核能层面：如果算力需求继续上升，能源会成为 AI 产业绕不开的底座。

重点解读

Thibault Sottiaux 对 Codex 和 ChatGPT Work 的说明，是今天最具体的产品信号。他说 GPT-5.6 Sol 做了推理优化，会把节省下来的成本反映到订阅里，带来大约 10% 的额外可用量；同时，团队发现把 Sol 上下文限制从 GPT-5.5 的 272k 提到 372k 后，实际扣量比预期更高，所以先回退到 272k，并继续调整 reasoning effort、多 agent 和 auto-review 的消耗。这个信息比单纯说“模型变强”更重要：用户真正关心的是模型能不能稳定用、扣量是否可预期、长任务是否值得交给它。

Claude 官方也在做相似的访问管理：Fable 5 对所有付费计划继续开放到 7 月 19 日，Claude Code 的周额度也继续保持 50% 上调。另一条说明补充说，用户最多可以把每周额度的一半用在 Fable 5 上，之后可以继续用 usage credits，或者切到其他模型。这说明前沿模型的竞争正在从“谁最强”转向“谁能让用户持续、可控地用”。

企业 AI 层的讨论也更清楚了。Guillermo Rauch 说，企业应该把模型当成自己机器里的一个齿轮，而不是把大脑外包出去：数据、eval、模型选择、软件层都要掌握在自己手里。Aaron Levie 的说法和这个方向一致：当所有公司都能访问前沿智能，真正有价值的是怎么把企业自己的决策、洞察、流程模式和最佳实践沉淀进 AI 工作流里。换句话说，模型本身会越来越通用，企业自己的 workflow、trace、eval 和信息复利会变得更值钱。

No Priors 这期和 Valar Atomics 创始人 Isaiah Taylor 聊核能。节目一开始就把问题讲得很直接：AI compute 正在推高美国电力需求，而核能如果要真正成为答案，就不能只停留在建模、仿真和审批里，要走向硬件迭代、制造化和规模化。Taylor 的核心判断是，能源是商品，价格下降会创造需求；如果能把核裂变做成更像制造业的产品，AI 产业的能源瓶颈才可能被系统性缓解。

X Builders 全量记录

1. Swyx @swyx

Swyx 今天两条都偏研究和内容分发。一条用很口语化的方式谈 introspection / backpropagation 和多次 rollout 的差别，大意是光做多次尝试但不根据优势信号改进，不能算真正学习；另一条是补充 Latent Space 的 writeup。前者和 agent / RL 讨论有关，信息量在于提醒大家：多跑几次不等于会变聪明，关键是反馈怎么进入下一轮。

2. Thibault Sottiaux @thsottiaux

Thibault 今天三条都围绕 GPT-5.6 Sol 的订阅和额度。核心是：Sol 会继续留在 Go、Plus、Pro、Team、Edu 等付费订阅里，直到更好的模型上线；同时 Codex 和 ChatGPT Work 的推理优化、上下文限制、reasoning effort、多 agent 和 auto-review 消耗都在被重新校准。对开发者来说，这不是小修小补，而是前沿模型进入高频工作流后必须面对的运营问题：强模型不仅要强，还要让用户知道自己能用多久、会怎么扣量。

3. Peter Yang @petergyang

Peter 今天的三条重点在社区沟通。他观察到很多人可能都在用 GPT-5.6 Sol，而 Terra / Luna 的使用占比可能很低；另外两条讲的是公司在社区情绪转差时，反而应该更透明、更像真人一样沟通，而不是更少说话、更企业腔。他还拿 OpenAI 的沟通方式和 Anthropic 做对比。这里值得记的是：模型产品已经像开发者基础设施一样，需要公开、及时、能解释取舍的沟通。

4. Cat Wu @_catwu

Cat Wu 发了一条很短的“Enjoy!”并引用了外部内容。单看这条信息量不大，但她本身在 Claude Code / Anthropic cowork 相关方向上，属于值得持续跟踪的 builder。这里按全量沉淀保留。

5. Amjad Masad @amasad

Amjad 的两条很有 builder 味道。他一边让 Replit 的 computer use 模型和自己新写的棋类引擎对弈，一边说自己在 Replit 上 fine-tune 一个 Qwen-8B 模型下棋，同时开了三个并行分支做不同实验。他的判断是，模型做 ML 工作的能力已经比以前强很多，有直觉的人即使不是传统 ML 背景，也能带着模型做出有意思的实验。这是 AI 编程从写应用代码往研究/实验自动化扩展的一个小信号。

6. Guillermo Rauch @rauchg

Guillermo 这条是今天企业 AI 层最清楚的一句话：把模型变成你自己机器里的一个齿轮。AI SDK、open Agent API、AI Gateway、ZDR inference 这些词背后是同一个判断：企业和创业公司不能把数据、eval、模型选择和软件层都交出去。越到 agent 时代，谁掌握工作流和评估闭环，谁才有长期控制权。

7. Aaron Levie @levie

Aaron Levie 讨论的是企业 IP 在 AI 时代怎么继续产生价值。他认为，当每家公司都能用上前沿智能时，真正的问题反而更突出：如何把企业自己的决策、洞察、工作流模式和最佳实践嵌入 AI；如何做 workflow eval；如何在不同智能层级之间路由模型；如何捕捉 trace，让信息价值随着 AI 能力一起复利。这是 applied AI layer 的机会所在。

8. Garry Tan @garrytan

Garry Tan 今天这条主要是公共安全技术和政治讨论，不是 AI 主线。按不过滤要求保留：他的观点是，出于文化战和表态目的关闭公共安全技术，会带来真实安全代价。

9. Matt Turck @mattturck

Matt 今天一条是偏玩笑的体育内容，另一条和 agentic coding 有关：当大家说“任何人现在都能用 agentic coding tool 做应用”时，他用了一个反应图表达怀疑或复杂心情。它不是系统性论证，但反映了一个社区情绪：agentic coding 正在降低门槛，同时也让人担心“能做 demo”和“能做产品”之间的差距被低估。

10. Zara Zhang @zarazhangrui

Zara 的“meeting transcript as PRD”是今天最实用的一条工作流信号：她和同事讨论一个功能实现，把会议记录发给 Codex，然后让它按讨论内容做原型。她总结得很直接：会议就是 prompt。另一条“Passion is the biggest moat”更像个人判断。放在一起看，重点是 Agentic coding 的输入正在从精心写 prompt，变成会议、讨论、上下文这些自然工作材料。

11. Nikunj Kothari @nikunj

Nikunj 今天三条里，第一条最相关。他说很多人在旧金山会讲自己有很多 subagents 在循环、token 跑得很猛，但当被问到到底在为谁、做什么时，回答反而不清楚。他的提醒很朴素：AI 时代也不能替代方向感，token 多不等于事情重要。后两条分别是提醒出去走走，以及说 outbound sales 这种能力会越来越重要，按全量沉淀保留。

12. Peter Steinberger @steipete

Peter 今天三条都和自己的多机器、多会话工作流有关。他说自己大概把工作分散在 5 台机器上，通过 Jump Desktop 操作；还提到 Mac Studio 能承受的 session 数量，以及周末做了一点界面 facelift。它们不是模型发布，但很贴近 AI power user 的真实状态：多 agent、多 session、多设备已经变成一部分人的日常工作方式。

13. Dan Shipper @danshipper

Dan 今天三条都比较短，偏转发和轻量评论。一条说某个结果相当可疑，一条说 capitalism stays winning，另一条说 extremely relatable。信息量不高，但作为 follow-builders 的原始抓取内容完整保留。

14. Sam Altman @sama

Sam Altman 这条是一个很直接的 Sol builder 激励：他想看大家用 GPT-5.6 Sol 做了什么有意思的东西，并会给最酷的作品送一个 OpenAI archives 里的特别礼物。这是产品增长和开发者生态动作，不是技术细节；但它说明 OpenAI 想把 Sol 的讨论从 benchmark 和额度，推向“真实作品展示”。

15. Claude @claudeai

Claude 官方两条说明 Fable 5 访问继续延期：所有付费计划继续开放到 7 月 19 日，Claude Code 周额度继续保持 50% 上调；同时用户最多可把每周额度的一半用于 Fable 5，之后可以用 credits 或切换到其他模型。这和 OpenAI Sol 的额度调整放在一起看，说明前沿模型可用性已经进入精细化运营阶段。

Blog 全量记录

今天 follow-builders 输出里没有新增 blog。这里不额外补外部网页。

Podcast 全量记录

1. No Priors：How Nuclear Will Unlock Energy Abundance with Valar Atomics Founder Isaiah Taylor

这期播客把 AI compute 的能源问题讲得很硬。Valar Atomics 创始人 Isaiah Taylor 的核心观点是：核能如果要支撑未来 AI 和工业需求，不能继续主要停留在建模、仿真和大型工程审批里，而要走向硬件迭代、制造化、规模化和更便宜的能量供给。他还强调，能源价格下降会创造新需求，这和 AI 算力需求增长是同一条产业链上的问题。节目里提到他们做出了由核反应堆供电的 AI 芯片演示，以及 TRISO 反应堆相关进展。对 AI 从业者来说，这期不是能源科普，而是在提醒：模型和 agent 的上限最终会碰到电力、制造、监管和基础设施。

今日沉淀结论

今天所有内容放在一起看，AI 的关注点正在从单一模型能力扩展到三层：第一层是模型服务本身，Sol 和 Fable 5 的额度、价格、访问边界会直接影响用户体验；第二层是真实工作流，会议记录、subagents、多会话、企业 eval 和模型路由正在把 agent 拉进日常生产；第三层是底座，算力增长最终要回到能源、硬件和基础设施。Generated through the Follow Builders skill: https://github.com/zarazhangrui/follow-builders

Sol 模型热度升温，Agent 需求扩散 - 2026-07-12

Sun, 12 Jul 2026 00:00:00 GMT

今日主线

今天这批内容有三条真正值得抓住的线。第一，GPT-5.6 Sol 继续被推到 coding 和前端场景里，OpenAI 相关成员、Sam Altman 和 builder 都在围绕它的速度、成本、前端质量和接入方式发声。第二，Swyx 和 Aaron Levie 都在讲同一个反直觉判断：AI 让软件生产更便宜后，需求可能不是下降，而是被放大。第三，No Priors 访谈 Booking.com CEO Glenn Fogel，核心不是“AI 会不会做旅行”，而是旅行 agent 真要落地，必须处理库存、合作伙伴、监管、出错后的连锁反应这些脏活。

重点解读

GPT-5.6 Sol 今天的信号比较集中。Thibault Sottiaux 直接把 Sol 的卖点压到几个很具体的产品问题上：更快、更省 token、后端更强、前端更好，并且少写乱用 useEffect 的代码。他还给出一套把 GPT-5.6 Sol 接进 Claude Code 工作流的方式。Zara Zhang 的反馈更短，但方向一致：她认为 Sol 的前端表现很好。Sam Altman 则从模型地位和使用成本侧面补了一刀，称很多 benchmark 显示 Sol 可能是当前最强模型，也提到 Fable 在某种使用水平下吃掉了 30% 成本。放在一起看，Sol 不是单纯模型宣传，它正在被推成更适合长任务、coding agent 和真实工程工作流的模型。

Swyx 和 Aaron Levie 的两条内容可以放在一起看。Swyx 用 Jevons paradox 解释 agentic engineering：当 coding agent 让知识工作的单位成本下降，总工作需求可能会上升。Aaron Levie 讲得更直白：软件岗位没有按“AI 替代”的剧本消失，反而因为软件生产变便宜，企业想做更多软件项目，仍需要懂系统的人长期维护、决策和运营。这个判断很重要，因为它把“AI 是否替代人”换成了另一个问题：当生产成本下降，哪些工作会被重新打开。

No Priors 这期和 Booking.com CEO Glenn Fogel 聊 AI 旅行。Fogel 的基本结论是：旅行 agent 很有价值，因为复杂行程本来就痛苦，AI 能记住偏好、比较方案、在航班酒店和行程之间来回推演。但他也反复强调，旅行不是把库存放进数据库就完事。真正难的是合作伙伴关系、全球监管、酒店和物业系统、异常天气或航班变更后的连锁处理。也就是说，AI travel 的壁垒不只在聊天界面，而在能不能处理真实世界的复杂执行。

X Builders 全量记录

1. Swyx @swyx

Swyx 这条是今天最清楚的“AI 需求扩张”观点。他说如果你只从软件需求理解 Jevons paradox，可能还没完全意识到它对更广义知识工作的影响：coding agent 把单位劳动成本打下来后，真正上升的可能是总工作量和对更好知识工作的需求。他把 coding 发生的事称为一个前兆，而不是例外。原帖如下：

2. Thibault Sottiaux @thsottiaux

Thibault 今天两条都围绕 GPT-5.6 Sol。第一条直接回应用户对速度、代码质量、前端能力的抱怨，强调 Sol 更快、更省 token、后端强、前端好，也少出现一些常见 React 代码坏味道。第二条给出一个把 GPT-5.6 Sol 接进 Claude Code 风格工作流的 CLIProxyAPI / alias 玩法，重点是让不装 Codex app 的人也能试到 Sol。这两条合起来说明，Sol 正在被当作 coding agent 模型来推，而不是只放在聊天窗口里展示。原帖如下：

3. Peter Yang @petergyang

Peter 今天三条都是阿根廷比赛相关，不是 AI 主线。按全量沉淀要求保留在这里，主要价值是说明这批 follow-builders 输出里混有明显生活化/体育内容，不适合作为短视频主题。原帖如下：

4. Guillermo Rauch @rauchg

Guillermo 这条是很短的“Easy money (Swiss francs)”式评论，信息量不高，也不是 AI 主线。按原始抓取结果保留。原帖如下：

5. Aaron Levie @levie

Aaron Levie 讲的是 AI 与软件岗位的反直觉关系。他认为软件岗位没有按“被 AI 替代”的方向走，是因为软件生产成本下降后，人们反而想生产更多软件。企业会启动更多项目，但只要工作没有完全自动化，就仍需要人来决定做什么、维护系统、长期运营和更新。他把这个逻辑推广到其他知识工作：agent 带来的可能是更多供给和需求，而不是简单替代。原帖如下：

6. Garry Tan @garrytan

Garry Tan 今天两条主要是加州建设和创业心态，不是 AI 主线。第一条谈 CEQA 改革和住房建设，第二条是偏 founder 心态的表达：很多事可能出错，但更有意思的问题是如果事情做成会怎样。按全量要求保留。原帖如下：

7. Matt Turck @mattturck

Matt Turck 这条也是阿根廷比赛评论，不是 AI 主线。由于他同时也是 MAD Podcast 主理人，账号本身常和 AI / data 内容相关，但这条具体内容没有可沉淀的 AI 信息。原帖如下：

8. Zara Zhang @zarazhangrui

Zara 的反馈很短，但和今天 Sol 主线对上了：她认为 5.6 Sol 的前端能力很好。这条价值在于它是 builder 使用侧的即时反馈，不是官方 benchmark。原帖如下：

9. Nikunj Kothari @nikunj

Nikunj 这条也是足球相关，不是 AI 主线。按全量抓取内容保留。原帖如下：

10. Sam Altman @sama

Sam 今天两条都和模型竞争有关。第一条说很多 benchmark 显示 5.6 Sol 可能是现在世界上最好的模型，但他用了比较调侃的方式表达。第二条提到在某种使用水平下，Fable 吃掉了 30% 成本。两条合起来看，一个在讲模型位置，一个在暗示成本结构仍是前沿模型部署绕不开的问题。原帖如下：

Blog 全量记录

今天 follow-builders 输出里没有 blog 新内容。

Podcast 全量记录

1. No Priors：Travel Through the Lens of AI with Booking.com CEO Glenn Fogel

这期访谈最值得记住的是 Glenn Fogel 对 AI travel 的边界判断。他承认 personalized travel agent 是非常自然的方向：复杂家庭行程、里程和现金选择、多目的地、酒店、餐厅、突发变更，这些都适合交给 AI 先做大量推演。但他也强调，旅行行业不是一个“模型接个库存库”就能打穿的领域。真正难的是全球监管、酒店和物业方协作、供应关系、异常情况处理，以及用户最终确认权。换句话说，AI 会改造旅行入口，但真正的护城河会在执行层。节目来源：No Priors / YouTube

今日沉淀结论

今天所有内容放在一起看，主线不是一个单点发布，而是 AI 正在进入三个更真实的层面：模型层，GPT-5.6 Sol 被推向 coding 和 frontend 工作流；工作层，agentic engineering 可能让软件需求继续变大；应用层，旅行 agent 这种看起来简单的场景，真正难点在执行、关系和责任边界。非 AI 的体育、政策和生活内容也已按要求完整保留。

Generated through the Follow Builders skill: https://github.com/zarazhangrui/follow-builders

MagenticLite 深度分析 - 2026-07-12

Sun, 12 Jul 2026 00:00:00 GMT

原始链接

GitHub 仓库：microsoft/magentic-ui

Microsoft Research 发布文章：MagenticLite, MagenticBrain, Fara1.5: An agentic experience optimized for small models

Fara1.5 技术文章：Fara1.5 - A family of frontier computer use agent models

透明说明：MagenticLite Transparency Note

相关论文：Magentic-UI: Towards Human-in-the-loop Agentic Systems

为什么今天选它

今天的候选里，有几类东西都值得看：AI agent harness 的资料库、agent memory 综述、近期 human-in-the-loop 论文，还有 MagenticLite。最后选 MagenticLite，原因很简单：它不是再讲“agent 应该会规划、会用工具”这种老话，而是把一个能跑的 browser/file-system agent 拆到模型、harness、沙箱、人机交互、评测几层一起做。

这也避开了《智汇AI》最近几篇的重复。前几天已经写过 Browser Harness、Loop Engineering、Agents' Last Exam、Hermes Agent。MagenticLite 仍然是 harness 主题，但它的核心问题换了：如果不用最大模型，能不能靠更合适的执行系统，让小模型完成真实浏览器任务？

图 1：MagenticLite、MagenticBrain、Fara1.5 三个组件来自同一次 Microsoft Research 发布。来源：Microsoft Research

图 1 很直接：MagenticLite 是应用和执行体验；MagenticBrain 是负责推理、写代码、调度的 14B 编排模型；Fara1.5 是专门做浏览器操作的 computer-use model。这个拆法比“一个大模型加一堆工具”更像真实产品架构。

它解决的不是“会不会点网页”，而是“能不能受控地做事”

MagenticLite 面向的是浏览器和本地文件系统之间的连续任务，比如查资料、填表、预约、整理本地文件。GitHub README 里写得很明确：它可以跨 browser 和 file system 工作，也会在关键动作前停下来让人确认，并把浏览器会话放在 Quicksand 沙箱里，避免 agent 直接碰到主机环境。

这点值得重视。很多 computer-use agent 的演示看起来像“模型能操作鼠标键盘”，但产品真正卡住的地方是三件事：

任务会跑很久，上下文会变脏。

网页里有登录、付款、提交表单这类不可逆动作。

模型错一步，用户很难知道它为什么错、错在哪里。

MagenticLite 的答案不是让模型更“聪明”，而是给模型一个更窄、更稳的工作台：编排模型只做规划、工具选择、代码和委派；浏览器模型只做视觉观察和单步动作；harness 负责压缩上下文、暂停恢复、关键点审批和沙箱隔离。

核心循环：Fara1.5 只做一步，循环很多次

Fara1.5 的 loop 是 observe-think-act。每一步，它看最近三张浏览器截图和对话历史，然后输出一次思考和一个原子动作。动作包括鼠标键盘、网页动作，也包括记住事实、询问用户、结束任务这类 context management 动作。

图 2：Fara1.5 的 observe-think-act loop。来源：Microsoft Research Fara1.5 技术文章

这张图说明了一个常被忽略的问题：browser agent 不应该一次性“规划完整网页操作”。网页状态一直在变，弹窗、表单校验、登录页、加载延迟都会打断计划。Fara1.5 把动作压到单步，harness 再反复喂回新的截图和历史。它牺牲了一点速度，换来更强的可纠错性。

这里的新东西不是 ReAct 本身。observe-think-act 很像 ReAct 的 GUI 版本。真正有价值的是三点：

输入不是 DOM 树，而是截图和对话历史，更接近人类看网页的方式。

动作空间里放进了 memorise、ask_user、finish 这类元动作，说明“上下文管理”和“请求人介入”已经变成 agent loop 的一部分。

每步只执行一个动作，减少了长链操作里一次性犯大错的机会。

MagenticBrain：小模型能编排，前提是训练时就待在同一个 harness 里

Microsoft Research 说 MagenticBrain 是 14B 参数的 orchestration model，负责把自然语言请求拆成计划、选择工具、写代码、在需要时把浏览器任务委派给 Fara1.5。关键点不是“14B 也能推理”，而是它在 MagenticLite harness 里端到端训练，训练时见到的工具 schema 和执行环境就是推理时用的那套。

这和常见 agent 设计差别很大。很多团队先拿通用模型，再在外面套工具调用、prompt、路由和重试。这样能快，但模型其实没有学过你的真实运行环境，只是在临场猜格式。MagenticBrain 的思路更像把“harness 行为”也纳入训练分布：模型不是只学知识，而是学怎么在这个系统里做事。

我认为这是 MagenticLite 最值得沉淀的地方。小模型路线如果只比参数和榜单，很容易变成缩水版大模型。MagenticLite 的路径是：缩小模型负责的范围，把环境、工具、委派关系和上下文整理做得更明确。

训练数据：用合成环境补上真实网页不能训练的部分

Fara1.5 没有只靠公开网页轨迹。公开网页能训练搜索和比较，但很难训练登录、发邮件、提交表单、订票这类动作，因为这些任务要账号、可能不可逆，也可能触碰真实用户数据。Microsoft 用 FaraGen1.5 做合成环境，把邮件、日历、媒体平台、ML 实验、市场等场景放进沙箱，再用 solver 和 verifier 过滤轨迹。

图 3：FaraGen1.5 用环境、solver、verifier 生成并筛选 computer-use 轨迹。来源：Microsoft Research Fara1.5 技术文章

这张图里最重要的是 verifier。它不是只看最后有没有成功，还检查三件事：轨迹是否符合任务意图、是否有多余或绕路动作、遇到缺信息/任务不明确/不可逆动作时是否正确请求用户。换句话说，它把“好 agent”从结果正确扩展到过程可控。

这对产品落地很有启发。很多 agent 评测只看 success rate，最后会鼓励模型赌一把。真实产品不能这样。一个会停下来问用户的 agent，可能比一个盲目提交表单但偶尔成功的 agent 更可用。

效果数据：小模型进步明显，但别只看榜单

Fara1.5 的数据不错。Microsoft Research 报告称，Fara1.5-9B 在 Online-Mind2Web 上达到 63.4%，相比 Fara-7B 的 34.1% 提升很大；在 WebVoyager 上从 73.5% 提到 86.6%。Fara1.5-27B 在 Online-Mind2Web 上达到 72.0%，WebVoyager 为 88.6%。

图 4：Fara1.5-9B 相比 Fara-7B 在多个 benchmark 上提升。来源：Microsoft Research Fara1.5 技术文章

但这些数字要谨慎读。WebVoyager、Online-Mind2Web 这类 benchmark 能说明模型在网页任务上变强了，却不能完整代表真实用户任务。真实任务里会有登录状态、支付风险、公司权限、隐私数据、网页改版、慢加载、弹窗、反爬和多标签页状态。Microsoft 自己的透明说明也提醒：MagenticLite 是研究原型，不建议在没有进一步测试的情况下用于商业或真实高风险场景。

所以这次发布的价值不在于“9B 打赢谁”，而在于它给了一个比较完整的工程假设：小模型 agent 的上限，不只由模型参数决定，还由 action space、训练轨迹、harness、上下文压缩、用户审批和沙箱共同决定。

和常见 agent 设计相比，新在哪里

常见 agent 设计大致是：一个大模型，接一组工具，外面套 planning prompt、memory、reflection、retry，再加一点日志。MagenticLite 不是完全推翻这个模式，但把几个薄弱点做实了。

第一，它把编排和浏览器操作拆开。MagenticBrain 负责计划、代码、工具和委派；Fara1.5 负责视觉网页动作。这样做的好处是每个模型训练目标更窄，harness 也更容易判断什么时候该委派。

第二，它把人在环放进系统协议里，而不是失败后的补丁。Magentic-UI 论文里提到 co-planning、co-tasking、action approval、answer verification、memory、multi-tasking。这里的人不是旁观者，而是 multi-agent team 里的一个特殊角色。agent 可以把某些步骤委派给用户，用户也可以暂停、接管浏览器、修改计划、恢复执行。

第三，它把 memory 收窄为“可复用计划”。这不是最通用的 agent memory，但很实用。用户完成过一次任务后，可以把执行轨迹总结成计划，下次相似任务直接复用。它没有试图一口吃掉个人偏好、事实记忆、长期关系和世界知识，而是先解决重复任务的 workflow memory。

第四，安全不是一句“有 guardrail”。GitHub README 和透明说明都强调关键动作前暂停、人类监督、Quicksand 沙箱、研究用途限制。Fara1.5 的训练和评测里也把 critical points 单独处理，包括缺少用户信息、任务不明确、不可逆动作未获批准。

哪些地方只是工程包装

MagenticLite 也有不少熟悉的东西。observe-think-act 不是新范式，multi-agent orchestration 也不是新概念，plan editor 和审批流程在企业自动化产品里早就有类似形态。它的“新”不在单个模块，而在组合方式。

如果把它拆开看，每个模块都能找到前身：ReAct、AutoGen/Magentic-One、browser-use agent、workflow memory、human approval、sandbox。真正值得学的是它把这些模块放在同一个任务闭环里，并且用训练数据和执行环境对齐它们。也就是说，它不是发明了所有零件，而是把零件之间的接口做得更像产品。

这也意味着复刻 MagenticLite 不能只抄 UI。只做一个漂亮的浏览器控制台，没有专门动作空间、上下文压缩、关键点识别、轨迹验证和沙箱，最后还是会退回“模型在网页上裸奔”。

可复用的方法论

第一，先定义 agent 的受控动作空间，再谈模型能力。好的 agent 不是想做什么都能做，而是每一步能被观察、回放、暂停、验证。

第二，把用户介入设计成正常路径。不要等失败才问用户。计划阶段让用户修正方向，执行阶段允许接管，关键动作前必须确认，结束后提供可验证轨迹。

第三，小模型要配窄职责。一个 9B browser model 可以很强，但前提是它只需要看截图、思考一步、执行一步。编排、代码、文件、浏览器不要全压给一个模型。

第四，memory 不必一开始就做成“人格记忆”。从可复用计划开始更稳。重复任务、固定流程、可检查结果，才是 agent memory 最容易落地的地方。

第五，评测要同时看结果和过程。success rate 很重要，但真实 agent 还要看有没有绕路、有没有该问不问、有没有误触不可逆动作、有没有把用户带到无法理解的状态。

风险和没验证清楚的问题

MagenticLite 仍然是研究原型。透明说明里明确写到，它不建议在没有进一步测试的情况下用于商业或真实场景，也不适合高风险决策。它主要用英语设计和测试，其他语言表现需要单独评估。

它还有几个问题没完全回答：

小模型在长任务里靠上下文压缩能撑多久？压缩错了，后面的行动会被污染。

合成环境训练出来的能力，迁移到真实企业系统时会掉多少？企业网页通常权限复杂、状态隐蔽、流程定制重。

人在环会不会变成频繁打断？审批太少不安全，审批太多又没人愿意用。

关键点识别能不能覆盖 prompt injection、伪造按钮、恶意网页文案这类对抗场景？

计划记忆会不会复用过头？网页变了、政策变了、用户偏好变了，旧计划可能变成错误捷径。

今日沉淀

小模型 agent 的关键不是“缩水”，而是缩小职责边界。

Harness 是 agent 产品的运行时，不是 prompt 外壳。

人在环要变成协议，不能只当兜底客服。

Browser agent 的 memory，先从可复用计划做起。

评测 agent，要同时评结果、过程和该停不停。

Agent 支付基础设施成形 - 2026-07-11

Sat, 11 Jul 2026 00:00:00 GMT

今日主线

这轮 follow-builders 的新内容集中在一件事：AI agent 正在从“帮你找答案”走向“帮你完成交易”。The MAD Podcast 这期和 Stripe 的 Head of Data and AI Emily Sense 聊 agentic commerce，她的判断很直接：一年前 agent 买东西还偏假设，现在已经有基础设施、商家和平台在真实接入。重点不只是让 agent 自动下单，而是让商品目录、价格、授权、支付凭证、风控和商家结算都能被 AI 表面调用。

重点解读

Stripe 的判断是，agentic commerce 不是单一路径，而是一条光谱。一端是完全自主的 agent：自己发现服务、判断是否购买、完成交易；另一端是人在 AI 应用里找商品，AI 给出答案，并把购买按钮放进流程里。Google 的 AI Mode 和 Gemini、Copilot、ChatGPT、Meta 广告里的 checkout，都是这种变化的早期形态。

真正难的地方不是“让模型推荐商品”，而是交易基础设施。商家要能暴露产品目录、库存和价格；消费者要能授权 agent 代为支付；agent 要能安全地执行交易。Emily Sense 提到 Stripe 的 Agentic Commerce Suite、catalog 暴露、shared payment token、Radar 风控和 Link wallet guardrails，核心都是为了解决一个问题：让 agent 能花钱，但不能乱花钱，也不能拿到不该拿的底层凭证。

这期里最值得警惕的信号是 token theft。Emily Sense 说，在 AI 领域，攻击者不一定要偷钱或账号，偷 token 就能获得价值；她提到 AI 公司里超过六分之一的新注册存在这类滥用。这个判断很重要，因为 AI 应用的支付、试用、额度和 API 调用，本质上都会变成新的风控对象。以后企业做 AI 产品，不只是防盗刷，还要防“薅 token”。

另一个长期信号是商业模式会变。传统 SaaS 的 per-seat pricing 在 agent 场景下会变得别扭，因为 agent 不一定按人头工作。它可能替一个团队跑任务、替一个商家处理采购，甚至被赋予买东西、卖东西、赚利润的目标。也就是说，Agent 不只是用户界面里的助手，正在变成新的经济行为主体。

X Builders 全量记录

本轮 follow-builders 输出中没有可用 X builder/tweet 内容，因此没有 X embed 可写入。

Blog 全量记录

本轮 follow-builders 输出中没有 blog 更新。

Podcast 全量记录

1. The MAD Podcast with Matt Turck：Stripe's AI Chief: How AI Agents Will Buy, Sell, and Pay

这期内容的基本结论是：agentic commerce 已经从概念进入基础设施建设期。Stripe 看到的方向不是“AI 帮你点一下购买按钮”这么简单，而是 agent 能在授权边界内发现商品、比较选择、完成支付，并和商家系统对接。最先落地的地方可能不是完全自主交易，而是 AI 搜索、AI 应用、广告和 checkout 混在一起的半自动购买流程。真正影响后续速度的，是消费者信任、商家目录标准、支付凭证安全、风控评分和新的定价方式。来源：The MAD Podcast with Matt Turck

今日沉淀结论

这条内容值得单独沉淀，是因为它把 AI agent 从“工作流工具”推到了“交易参与者”。当 agent 可以被授权花钱，产品形态、支付风控、商家获客和 SaaS 定价都会被重新改写。下一阶段的关键问题不是 agent 会不会买东西，而是谁能提供让它安全买、可控买、可结算买的基础设施。

Generated through the Follow Builders skill: https://github.com/zarazhangrui/follow-builders

SelfMem 深度分析 - 2026-07-11

Sat, 11 Jul 2026 00:00:00 GMT

原始链接

论文页面：SelfMem: Self-Optimizing Memory for AI Agents

PDF：arXiv PDF

DOI：10.48550/arXiv.2607.03726

论文 HTML 原图来源：arXiv HTML

今天为什么选 SelfMem

今天看了几个近期活跃的 Agent 方向：Orca 把多个 coding agent 放进并行 worktree，Rowboat 做本地长期工作记忆，agent-device 给移动端和真实设备测试补上“眼睛和手”，OpenConnector 解决 agent 调工具时的授权和动作目录问题。这些都很实用，但更像产品形态或基础设施。

SelfMem 值得单独写，是因为它碰的是更底层的问题：Agent 长期运行时，记忆到底该由人写规则来管，还是让 Agent 在受控环境里自己学会“该记什么、该删什么、该回源查什么”。这和最近几天写过的 harness、loop、评测不同，焦点落在 memory policy 本身。

它解决的问题：不是记住更多，而是记得更会取舍

很多 Agent 记忆方案会在三条路里选一条：全量上下文、RAG 检索、摘要/画像/知识图谱。问题是长任务里信息有新旧、有稳定和临时、有事实和偏好。把所有东西塞进上下文很贵，压缩会丢细节，RAG 又常常只在提问时捞几个片段，没形成可维护的工作记忆。

SelfMem 的核心判断很朴素：记忆不是一个静态仓库，而是一套可被检查和修订的策略。论文把这句话画成“教 Agent 钓鱼，而不是直接给鱼”。

SelfMem Figure 1

图 1 来自论文 HTML 原图。它表达的是 SelfMem 的出发点：不要预先规定一种固定记忆格式，而是给 Agent 原则、工具和反馈，让它自己学习记忆取舍。

系统怎么运作

SelfMem 把系统拆成两层。第一层是不可变的原始对话记录，论文实现里用 SQLite 表保存 turn_index、role、time_anchor、content 等字段。它是事实来源，Agent 只能读，不能改。第二层是 Agent 管理的 memory workspace，里面可以是用户画像、偏好、项目状态、时间线，也可以是 Agent 自己整理出来的策略笔记。

Agent 不直接“生成一份总结”就结束，而是在工具循环里做几类动作：读原始 transcript，读当前 memory，写入或修订 memory，检查 memory 质量，必要时做 self-test。检查项包括来源是否可靠、事实是否过期、是否有矛盾、摘要是否太粗、以后是否容易检索。

SelfMem Figure 2

图 2 是 SelfMem 的主流程。左边保留原始 transcript，中间是 memory action space，右边是 Agent 生成的可用记忆。关键不在 SQLite，也不在某个具体工具名，而在这个闭环：inspect -> write -> review -> revise。记忆第一次写错并不可怕，可怕的是系统没有让它发现错误和修正错误的地方。

回答问题时，SelfMem 会同时使用最终 memory workspace 和从原始 transcript 找回来的相关片段。这样可以避免两种极端：只靠记忆导致事实失真，只靠检索又缺少长期结构。

它和常见 Agent 记忆方案的区别

RAG 的强项是便宜、直接、可扩展，但它通常是“提问时检索”，不是“长期维护记忆”。SelfMem 不是否定 RAG，而是把 RAG 放回一个更大的记忆管理过程里：哪些内容该长期保存，哪些内容该临时回源查，由 Agent 根据反馈决定。

MemGPT、MemoryBank、Mem0、A-Mem 都比普通 RAG 更接近 Agent 记忆。MemGPT 让模型在不同记忆层之间搬运信息，MemoryBank 做长期用户记忆，Mem0 更偏生产化抽取和检索，A-Mem 允许 Agent 写、索引、链接记忆。SelfMem 往前推了一步：不只让 Agent 操作记忆，还让它调整“记忆策略”本身。

但这里也别夸过头。SelfMem 仍然依赖人设计好的 harness：原始记录怎么存、工具能做什么、review 看哪些风险、反馈怎么给，都是系统边界。真正新的地方，是把 memory policy 暴露给模型，让模型在工具反馈下修订策略。工程包装的部分，是 SQLite、工具接口、review checklist 这些实现形式。

实验结果怎么看

论文在 BEAM 长对话记忆评测上比较了 RAG、Full context、Compression、LoCoMo、ReadAgent、MemoryBank、MemGPT、A-Mem、Mem0 和 SelfMem。测试覆盖 100K、500K、1M token 三个规模，问题类型包括信息抽取、多轮推理、时间推理、偏好、更新、摘要等。

主表里，SelfMem 在三个规模上都拿到最高 Score 和 Pass0.5。100K 时 Score 是 0.504，RAG 是 0.339；500K 时 SelfMem 是 0.487，RAG 是 0.346；1M 时 SelfMem 是 0.454，RAG 是 0.320。论文还给了成本：1M token 规模下，SelfMem 成本为 2.004 美元，Mem0 是 18.830 美元，RAG 是 1.843 美元。也就是说 SelfMem 不是最便宜，但比很多重型记忆系统更准、更省。

SelfMem Figure 3

图 3 来自论文的 BEAM 分问题类型结果。它比较重要，因为它说明 SelfMem 的优势不只来自某一类题。论文报告称，SelfMem 在 100K 规模下 10 类问题中拿下 9 类最佳，500K 下 8 类最佳，1M 下 7 类最佳。对 Agent 产品来说，这比单一总分更有参考价值，因为真实用户问的问题不会只落在一种记忆模式里。

更有意思的是策略优化

SelfMem 不只构造记忆，还测试了“记忆策略能不能继续被优化”。论文把 conversation 0-8 用作训练反馈，把 conversation 9-19 作为 held-out 测试。Agent 看不到测试答案，只能根据训练分数和记忆工具诊断，生成新的策略说明。

SelfMem Figure 4

图 4 显示默认策略的 held-out 分数是 0.472，最终 Agent 合成策略到 0.497，搜索过程中最好的策略到 0.510。这里最值得注意的不是涨了多少，而是最强策略并不出现在最多迭代或最多训练样本时。换句话说，记忆优化不是“跑越久越好”，而是需要找到合适的程序性规则：哪些事实长期保存，哪些事实保持可回源，哪些摘要必须带来源，哪些细节不能提前压扁。

对产品和研发的启发

第一，长期记忆不要只做成资料库。真正难的是“记忆治理”：过期事实怎么降级，稳定偏好怎么保留，冲突信息怎么提示，重要细节怎么回源。

第二，原始记录要当作事实底座保留。SelfMem 的 transcript store 很关键，因为 memory workspace 可以错、可以改、可以压缩，但原始证据不能跟着一起变形。

第三，把诊断反馈做成工具，而不是只靠提示词提醒。比如“这个记忆有没有来源”“是否和旧记忆冲突”“未来能不能检索到”，这些都可以变成 Agent loop 里的显式检查。

第四，memory 和 eval 要一起设计。没有长周期、多类型、带成本的评测，团队很容易把“记得多”误判成“记得好”。SelfMem 的结果提醒我们，记忆系统至少要同时看正确率、成本、请求次数、缓存利用和可审计性。

风险和没验证的地方

SelfMem 目前主要在 BEAM 上验证，论文自己也说还需要更多 long-horizon benchmark、模型家族和真实部署场景验证。策略优化实验只在 100K 规模做了，500K 和 1M 下能否稳定优化，还没有结果。

它还依赖模型自己判断记忆质量。review 工具能降低风险，但不能保证 Agent 不会把错误事实写得很自信。真实产品里还要考虑隐私、用户可见性、删除权、团队共享记忆、多 Agent 同时写 memory 时的冲突处理。

还有一点现实问题：我在 arXiv 页面没有看到作者提供代码链接。论文给了相当多流程和指标，但如果没有可复现实装，外部团队要判断它在自己业务里的成本和收益，还需要重做一遍 harness。

今日沉淀

长期记忆的难点不是容量，是取舍。

好的 Agent memory 应该能回源、能审计、能修订。

记忆策略本身可以成为 Agent 优化对象。

RAG 适合找证据，不等于长期工作记忆。

做 Agent 产品时，要把 memory、loop、eval 放在同一个设计里看。

模型发布周，Agent 入口开打 - 2026-07-11

Sat, 11 Jul 2026 00:00:00 GMT

今日主线

今天这批内容的主线很集中：模型发布周不是单纯比谁的模型更聪明，而是在抢 Agent 的工作入口。OpenAI 这边把 GPT-5.6 Sol、ChatGPT Work 和 Codex 放在一起推，Gemini 团队公开整理用户对 Workspace、tool calling、MCP 的反馈，Box 用自己的复杂文档 eval 测 Sol，Replit 和 Anthropic 相关 builder 也在谈 coding agent、runtime 和未知问题管理。另一条线是开放模型和价格压力，大家开始意识到“够聪明、够快、够便宜”会比单点 benchmark 更影响真实采用。

重点解读

Thibault Sottiaux 的两条 Codex 更新最能代表今天的气氛：GPT-5.6 Sol 发布后，OpenAI 给 ChatGPT Work 和 Codex 重置额度，让用户有空间试更大的任务。这不是普通促销，而是把模型能力直接推向工作场景。Sam Altman 也说 Codex 是新 work product 的核心，这说明 coding agent 正从一个工具按钮，变成 OpenAI 想要占住的工作入口。

Josh Woodward 公开整理 Gemini 用户反馈，重点集中在 Workspace、tool calling、Projects、MCP 等真实工作流需求上。这个信号很明确：用户已经不满足于单次问答，他们要的是模型接入工具、上下文和日常生产系统。

Podcast 里 Jürgen Schmidhuber 的观点给这轮模型热降了温。他认为真正的 AGI 不能只在屏幕里完成，机器人硬件和真实世界能力仍然是短板；同时，开放模型追赶和算力降价会压缩闭源模型公司的定价空间。这和今天 X 上关于模型发布、开放模型速度、企业 eval 的讨论放在一起看，很有参考价值。

X Builders 全量记录

1. Swyx @swyx

Swyx 今天三条都偏 builder 生态观察。一条说前沿模型在需要发邮件时经常倾向使用 Resend，像是 AEO 做得很好；一条把 Greptile 和 OpenAI 的新动作联系起来，调侃早期争议后来可能成了更大产品方向的影子；最后一条是轻量社区梗。核心可记的是：AI 工具会改变“默认被模型选择”的产品分发路径。

2. Josh Woodward @joshwoodward

Josh Woodward 说 Gemini 在 12 小时内收到 1400+ 条反馈，他正在整理 Top 10 需求和团队进展。能看到的关键词是 Workspace integrations、tool calling、Projects、MCP 这些真实工作流能力。这里的重点不是反馈数量，而是用户把模型产品往“能接工具、能进日常工作系统”的方向推。

3. Thibault Sottiaux @thsottiaux

Thibault 连发三条 OpenAI / Codex 相关更新：为庆祝 GPT-5.6 Sol 发布，ChatGPT Work 和 Codex 的使用额度会在 24 小时内重置两次；随后又说用户会先拿到一次完整重置；中间还有一条 3D 内容展示。这里最值得记的是额度策略：OpenAI 想让用户真的去试更复杂、更长的工作任务，而不是只看模型发布说明。

4. Peter Yang @petergyang

Peter 今天一条是世界杯相关，属于非 AI 主线；一条是对 OpenAI 发布的称赞和反馈，核心是 OpenAI 比其他实验室更有机会把 agent 工作方式推向主流，因为 ChatGPT 已经有图片、实时语音、浏览器、computer use 和插件入口；另一条也是足球内容。真正值得沉淀的是第二条：Agent 的胜负不只在模型，而在入口、交互和已有用户习惯。

5. Nan Yu @thenanyu

Nan Yu 今天三条都比较短：一条把 ChatGPT Codex 和 Adeptus Astartes 放在一起玩梗；两条吐槽融资视频里大数字和炫技表达。它们不是 AI 产品主线，但反映 builder 圈对“夸张传播”的疲劳感。

6. Madhu Guru @realmadhuguru

Madhu Guru 宣布加入 Meta 做 AI 产品。他的判断很直接：软件工程 agent 已经明显改变了开发，但大多数复杂系统里的 agent 还处在早期，普通人还没有真正感受到 AI agent 的力量。这条和今天的 Codex、Gemini、runtime 讨论连在一起看，说明 agent 竞争正在从开发者场景向更多复杂系统扩散。

7. Amanda Askell @AmandaAskell

Amanda 两条都在讲纽约建筑倒塌的个人记忆和事实校正，属于生活化内容，不是 AI 主线。按全量沉淀要求保留。

8. Thariq @trq212

Thariq 的第一条很值得记：agentic coding 的核心技能之一，是减少未知数。这比“让 agent 多写代码”更接近真实工程经验。第二条是转发 Fable 相关可用性。放在一起看，Anthropic / Claude Code 生态里的重点仍然是让 agent 在复杂代码库里更可控、更能推进任务。

9. Amjad Masad @amasad

Amjad Masad 今天三条都和 AI 产品落地有关。他说 AI 让 coding 更灵活，但 Replit 反而在让 runtime 更刚性：更多 formal specs、更确定的系统、更有韧性的基础设施。另一条判断 LLM 市场已经变得更动态，反对单一模型公司会垄断的看法；第三条鼓励用户试 Fable in Replit。核心信号是：agent 越能快速生成和修改代码，底层 runtime 越要稳定。

10. Guillermo Rauch @rauchg

Guillermo Rauch 今天谈的是模型市场。他说开放模型会变得非常快，并判断 Meta Spark 1.1、Grok 4.5、GLM 5.2 可能显著挤占 token 市场份额，因为多数 agentic tasks 需要的是“足够高的智能 + 快速度”。这条很关键：模型竞争正在从“最强”走向“高性价比、低延迟、可大规模跑任务”。

11. Alex Albert @alexalbert__

Alex Albert 转发 More Fable，信息量不大，但和 Thariq、Amjad 的 Fable/Replit 线索呼应：Anthropic 相关模型和 coding agent 工具正在继续放量。

12. Aaron Levie @levie

Aaron Levie 一条讨论模型共享后的竞争优势：当行业智能越来越多来自相同模型，企业真正的差异会转向流程、数据、产品集成和分发。另一条是 Box 对 GPT-5.6 系列的评估，重点是 Sol 在 Box AI Complex Work eval 里，相比 GPT-5.5 在复杂文档和数据任务上有明显提升。企业不会只看榜单，而会看模型能不能在自己的文档集里给出可校验结果。

13. Garry Tan @garrytan

Garry Tan 提到 Meta Muse Spark 1.1 在 OpenClaw 上表现很好，并点名早期版本 Hornbill。这条和今天的模型发布周主线相关：除了 OpenAI，新模型和开放/半开放模型也在快速进入 builder 的实际工具链。

14. Matt Turck @mattturck

Matt 今天三条都是世界杯 / 巴黎相关，属于非 AI 主线。按“不过滤”要求完整保留。

15. Nikunj Kothari @nikunj

Nikunj 一条用生活化方式解释这周模型发布局势：GPT-5.6 有 Sol、Terra、Luna 三个版本，Sol 最强，还要通过政府安全评估；另一条是电气工程相关轻松内容。第一条说明模型发布节奏已经复杂到需要“面向普通人解释版本、能力、限制和放量方式”。

16. Peter Steinberger @steipete

Peter 今天三条都是短转发和活动相关：称赞某个内容很强、说会做 livestream、以及祝贺别人做出好东西。原帖信息量有限，但保留为全量记录。

17. Dan Shipper @danshipper

Dan Shipper 今天三条：一条 Every 内部/内容梗，一条吐槽“developers don't do work”的说法，另一条转发 GPT-5.6 Sol 作为知识工作标准的内容。它们都围绕 AI 工作方式的叙事，尤其第三条和今天的 Sol / knowledge work 主线直接相关。

18. Aditya Agarwal @adityaag

Aditya 两条都来自 South Park Commons 访谈内容，讲 Gagan Shux 从申请印度空军到登上 ISS 的经历。不是 AI 主线，但属于 builder 内容，保留记录。

19. Sam Altman @sama

Sam Altman 今天三条里，一条是对 Fidji 个人情况的祝福，不展开；一条明确说 Codex 是新 work product 的核心，Codex 不会消失；另一条说企业对 AI 成本的担忧已经被听到，5.6 Sol、Terra、Luna 在 dollars-per-task 上是重要进步。这三条连起来看，OpenAI 今天的关键词是工作产品、Codex 和单位任务成本。

Blog 全量记录

今天 follow-builders 输出里没有 blog 更新。

Podcast 全量记录

1. Unsupervised Learning：Ep 90: AI Pioneer Jürgen Schmidhuber on the State of AI Today

这期 podcast 的核心观点很清楚：Schmidhuber 对 AI 技术长期乐观，但对当前模型公司的商业结构更谨慎。他认为真正的 AGI 不能只在屏幕里完成，机器人硬件和真实世界能力还远弱于人类身体；他也认为当前数据中心和 GPU 投入可能被高估，因为开放模型追赶和未来算力降价会持续压缩闭源模型的定价空间。对今天的模型发布周来说，这是一盆有用的冷水：模型能力会继续进步，但护城河不一定在模型本身。

今日沉淀结论

今天所有内容放在一起看，主线不是“又有几个模型发布了”，而是模型正在被拉进真实工作：Codex 要成为 work product 核心，Gemini 用户在要工具和 Workspace，企业用自己的 eval 评估 Sol，Replit 强调 runtime 稳定，开放模型在速度和价格上继续施压。下一轮 AI 产品竞争，很可能不是单点能力，而是谁能把模型、工具、运行环境和成本控制接成一个稳定工作入口。

Generated through the Follow Builders skill: https://github.com/zarazhangrui/follow-builders