Lucien

[Lydia Hallie ✨ @lydiahallie]

Setting my subagent model to Opus has helped me save so much usage on Fable 5.1. It really likes to spawn subagents but mine rarely need Fable-level reasoning

`CLAUDE_CODE_SUBAGENT_MODEL=opus`

[0xSero @0xSero]

Pi agent deep dive, this is a live session.

Enjoy! I think there's a lot of good info in there

[宝玉 @dotey]

为了节约上下文 handoff 新开 Session，这在半年一年前是很好的实践，现在没太有必要，因为 codex 自己上下文压缩做的很好了，或者 /compact 一下继续就足够了。

当然如果关系不大的任务，还是新开 Session 更好。

当然除此之外 handoff 还是适用于跨 Agent session 的，比如 Claude Code 里面没完成的 session 让 Codex 继续。

不过我更习惯于 Claude Code 里面用 Fable 5 写技术方案文档，然后反复 Review、修改后把文档交给 Codex，配合 /goal 让它按照文档执行推进。

当然设置好严格的验收标准也很有必要，否则它会偷懒。

之前一个迁移任务没有设置验收标准，它就给我交付了一个差强人意的，离我要求的还有比较大差距。（参���图1）

重新加上了验收标准：UI 界面像素要和原版完全一致，那么它每一步都会截图对比像素差异，直到完全一致（或者可以忽略的差异）

[David Pan @davep]

Everyone is writing about agent loops right now. Including us at Cursor, because they're so powerful. But here's a prediction: a year from now, nobody will be talking about them.

Not because they weren't useful. Because they'll work right out of the box. Batteries included. No instructions necessary.

Feels a lot like prompt engineering two years ago. It was incredibly important. People wrote courses on it. Now you just talk to your agent like a normal person.

That's the strange thing about AI right now. You learn something critical, get huge gains, and before long it's the new normal and something else is the bottleneck. So the alpha isn't what you know. It's how fast you learn it, and how easily you can let it go.

[宝玉 @dotey]

Codex 操作浏览器有两种模式，一种是 Chrome 插件，一种是内置浏览器。用了一段时间之后，我总结一下两者的差异和各自适合的场景。

【1】先说一个被低估的用法：拿 Codex 当爬虫

传统爬虫用 requests 或者 Playwright 无头模式去请求页面，现在风控越来越严，指纹检测、行为分析、验证码轮番上阵，很多网站一看你是程���化请求直接拦截。Codex 的浏览器不一样，它操作的是真实浏览器，有完整的渲染引擎、真实的用户代理、正常的 JavaScript 执行环境，在网站看来就是一个普通用户在浏览页面。

配合 /goal 模式，你设定一个目标（比如“把这个网站上所有产品的名称、价格、评分抓下来存成 CSV”），Codex 会自己规划步骤、翻页、处理异常，不需要你一步步指挥。这比自己写爬虫脚本省事得多。

但 Codex 有两种浏览器模式，特性完全不同，选对了事半功倍。

【2】Chrome 插件模式：能力强，但吃资源

用 @Chrome 调用的 Chrome 插件模式，核心优势是一个字：登录态共享。

它直接运行在你自己的 Chrome 浏览器里，继承你所有的 Cookie、登录会话、已安装的扩展。那些需要登录才能访问的内容，比如付费订阅的文章、企业内部的管理后台、CRM 系统里的客户数据、需要登录的社交平台，Chrome 插件都能直接访问，因为对网站来说，就是你本人在操作浏览器。

Codex 在 Chrome 里工作时会把任务放进独立的标签页分组，不会打断你正在看的页面。它还支持 DevTools 协议，能抓性能数据、看网络请求、调试 Console 错误。

但代价也很明显：资源消耗相当大。Chrome 本身就是内存大户，每个标签页都是独立进程。Codex 的 Chrome 插件在上面再加一层操控逻辑，截图、DOM 解析、指令交互全在跑，内存和 CPU 占用会非常高。机器配置不行的话（比如 8G 内存的笔记本），跑起来能明显感觉到卡顿，拿来做批量爬虫任务就更难受了。长时间运行还容���出现截图延迟、状态不同步的问题。

另外 Chrome 插件目前只支持 macOS 和 Windows，Linux 用户暂时用不了。它也不支持无头模式，Chrome 窗口必须保持打开状态。

适合的场景：需要登录态的短期任务。比如登录某个平台抓一批数据、在内部工具上批量操作、从 CRM 导出信息。

【3】内置浏览器模式：轻快，但有局限

用 @Browser 调用的内置浏览器，是 Codex 自带的沙盒浏览器环境。

它最大的优势是轻量。不需要启动整个 Chrome，资源消耗小很多，响应速度快，适合需要频繁操作浏览器的场景。

但它有一个根本性的限制：没有你的登录态。不继承 Cookie、不继承浏览器扩展、不继承已保存的会话。打开一个需要登录的页面，你得在内置浏览器里重新登录。而且有些反爬严格的网站，对这种非标准浏览器环境的检测更敏感。我试过在内置浏览器里登录 X，反复失败，��概率是因为 X 的风控识别出了异常的浏览器指纹。

内置浏览器真正出彩的地方是前端开发调试。它有一个标记模式（Annotation Mode），你可以直接在渲染好的页面上选中某个元素或者框选一个区域，写上“这个按钮往上移”“字体加粗”“这个间距太大了”之类的批注，Codex 会把这些批注当作可执行指令来处理。这比用文字描述“第三行第二个按钮的 margin-top 减少 8px”直观太多了。

配合 Developer Mode，内置浏览器还能跑性能分析、抓网络请求、看 Console 输出，对本地开发服务器的调试非常友好。

适合的场景：公开页面的数据抓取、本地开发调试、不需要登录态的网页操作。

【4】怎么选

简单说：需要登录的用 Chrome 插件，不需要登录的用内置浏览器。如果你的机器配置有限又需要大量抓取公开数据，内置浏览器是更好的选择。如果目标网站必须登录才能看到内容，或者反爬很严需要真实浏览器指纹，那只能用 Chrome 插件，但要有心理准备面对资源消耗。

Codex 自己也会根据任务判断应该用哪种浏览器。它的优先���是：有专用插件（比如 Jira、GitHub 的集成）就用插件，需要登录态就用 Chrome，其余情况用内置浏览器。

当然浏览器的用途远不止爬虫。我觉得内置浏览器做前端调试的体验比很多专门工具都好，标记模式配合 Codex 的理解能力，几乎是“指哪改哪”。Chrome 插件在自动化操作企业内部工具方面也很实用，比如定期从后台导数据、批量更新记录。这些场景还有不少值得挖掘的空间，大家可以根据自己的实际需求去试试。

[宝玉 @dotey]

之所以研究 Claude Design，是因为最近摸索出一套不错的开发模式：

1. 先用 Claude Design 去设计 App 的 UI 和 UX，第一版本越简单越好。

Claude Design 交付的结果是 HTML + CSS + React + data.js，通过 CSS 一下就可以看清楚设计系统的颜色系统、尺寸规范，通过 React 可以看清楚组件结构，通过 data 可以知道数据结构什么样子。

这几个组合可比 figma 对于 AI 来说友好多了，尤其是 data.jsx，这是一般的设计 App 不会有的，但对开发特别重要的。

还有一个优势就是交付的结果都是文本格式的，可以一起提交到 git 做版本管理，用 git diff 就可以清楚的让 AI 知道设计稿修改了什么。

2. 把 Claude Design 生成设计稿交给 Claude Opus 4.8 去实现一�� MVP，第一个版本只实现 UI 功能，告诉它技术栈（比如 AppKit 而不是 SwiftUI），通过几个小版本的迭代，让它逐步完善。比如第一个版本只是主界面

之所以不用 GPT，是因为 Opus 在 UI 实现上比 GPT 好太多，同样的设计稿，GPT 实现的各种细节问题的，不能很好的遵守设计稿。

之所以不一下子实现太多功能，是因为功能越少 Agent 越容易聚焦，做出来效果越好。所以怎么拆分版本，也是用好 Coding Agent 的一种能力。

非 UI 的功能，用什么模型没有那么大差别，所以我也会用 Codex 配合非 UI 工作。

3. 每次生成一个版本，要让它可以运行，无论是 Agent 还是人都是需要即时反馈的，有了反馈才知道方向对不对，才知道下一步要做什么。

人在测试的时候，能发现各种问题，代码问题就让 Agent 去修改，UI 设计有问题不是马上修改代码，而是要去 Claude Design 去修改设计稿，设计稿修改完了，把设计稿下载回去，替换本地的设计稿文件。

设计稿替换后，让 Agent 去 git diff 分析一下变更，给它个截图，都不用多说它就知道怎么改了。

4. 版本稳定后继续新一轮迭代

当设计的功能做完之后，不一定是要马上去设计新的功能，而是可以重新审查一下实现的代码，重构优化一下。

比如我在第一版实现后，让 Opus 4.8 去做了性能分析，看性能问题在哪，然后告诉我当前用 NSScrollView，内容一多就内存暴涨，建议 NSTableView。

我心想这不应该是一开始就该考虑到的么！不管怎么样亡羊补牢也不算晚。

性能优化完就继续加功能，更新设计稿，让 Agent 参考新设计稿优化功能。

---

再回来说研究 Claude Design 的事，因为反复 Claude Design 修改，同步到本地，然后这一步让我后来很烦，因为需要在本地和 Claude Design 网页切换，还要导出下载到本地，解压缩替换。

于是我就想能不能在本地就可以重现 Claude Design 直接集成到本地 Agent，所以我去研究了 Claude Design，然后发现完全可以本地跑起来，只是本地 Agent 在工具调用上有些差异，以及不方便直接在设计稿上标记编辑。

上周正好 Codex 发布了直接调试 iOS 的功能，它��了标记修改的功能，然后我灵机一动，这不正好可以代替 Claude Design 的标记修改功能么。（图2）

问题是 GPT 5.5 模型设计能力不够，在 Codex 里面设计效果也不会好。

接着 Cursor 也发布了网页标记功能，这下正好，Cursor 里面可以用 Opus 4.8，做成 Skill 就可以本地运行了，还可以在 Cursor 内置浏览器中，直接标记、评论修改。

好在 Claude Code 的核心逻辑都在浏览器前端，他们在网页上做了个 Harness，这给了我分析的便利，耐心一点就可以分析出所有的 Prompt、内置 Skills、初始组件，再针对 Cursor 的工具做一些兼容就可以跑起来了。（图3）

测试对比了一下和在 Claude Design 上跑的效果差不多。（图4）

归根结底，还是 Claude Desktop 太拉胯了，Claude Design 本应该集成在 Claude Desktop 的，不然也不需要我这么折腾。

当然不折腾下我也没机会学习 Claude Design 优秀的设计，��的很棒，接下来会系列更新我的学习心得。

推荐去试试最终的 Skill，让你本地就可以跑 Claude Design：
https://t.co/d2EaYV6q7j

[宝玉 @dotey]

你不能指望一个模型在什么地方都是最强的，要像渣男一样才能用好 AI：去爱很多模型，去发掘他们的优秀点，东食西宿，组合着用

Opus 4.8 在写作不太行，但是在 UI 设计，UI 实现比 GPT-5.5 要好很多，推荐你多用用 Claude Design，然后把 Claude Design 设计好的结果分别给 GPT-5.5 和 Opus 4.8 去实现一下看看差异。

然后系统设计和计划方面，质量也是很高的，一个复杂一点任务通常要先做 Plan、做系统设计，这方面 Opus 4.8 也是非常好的。

另外和你用的 Agent 有关系，每个模型都有自己的特性，需要重新设计提示词反复调优，如果你在 Claude Code 和 Cursor 里面用 Opus 4.8，除了写作，其他任务的效果是没有什么问题的。

[Google AI Developers @googleaidevs]

Speed up your Gemma 4 workflows by up to 3x with Multi-Token Prediction (MTP) drafters.

Standard LLM inference is fundamentally memory-bandwidth bound, creating a latency bottleneck as billions of parameters travel from VRAM just to generate a single token. We're working to ease this bottleneck with MTP drafters for @googlegemma 4.

[Adam.GPT @TheRealAdamG]

https://t.co/pmkDoTe9Ug

**NEW: GPT-5.5 Prompting Guide**

"GPT-5.5 works best when prompts define the outcome and leave room for the model to choose an efficient solution path. Compared with earlier models, you can often use shorter, more outcome-oriented prompts: describe what good looks like, what constraints matter, what evidence is available, and what the final answer should contain.

Avoid carrying over every instruction from an older prompt stack. Legacy prompts often over-specify the process because earlier models needed more help staying on track. With GPT-5.5, that can add noise, narrow the model’s search space, or lead to overly mechanical answers.

For more detail on GPT-5.5 behavior changes, start with the Using GPT-5.5 guide. This guide focuses on prompt changes that follow from those behavior changes.

The patterns here are starting points. Adapt them to your product surface, tools, evals, and user experience goals."

[Martin Fowler @martinfowler]

NEW POST

Thoughtworks internal IT use a workflow for agentic programming called Structured-Prompt-Driven Development (SPDD). @WeiZhang595190 and Jessie Jie Xia describe how this works with a simple example plus details in a github project.

https://t.co/6cHnSPWr6L

[Uncle Bob Martin @unclebobmartin]

@garybernhardt AI will not replace programmers. Software engineers, who know how to wrangle AIs, will replace “vibe“ programmers. And when those software engineers meet Dykstra in heaven, he will smile and give them all hugs.

[GitHub @github]

Starting June 1st, GitHub Copilot will move to a usage-based billing model as GitHub Copilot supports more agentic and advanced workflows.

In early May, you'll see a preview bill experience, giving visibility into projected costs before the transition.

👉 Read more about the upcoming change: https://t.co/4IC9VNHwhk

[宝玉 @dotey]

作者画的这图效果挺好，不过好像没提供提示词，我仿照着写了一个 GPT Image 2 的提示词模板：
> 请创作一张关于「【数学概念/知识点】」的数学可视化信息图，目标是帮助读者直观理解：它是什么、为什么成立、几何/结构直觉是什么、在不同场景下如何表现。画面要像高质量数学讲义 + 手绘教育海报，优雅、清晰、信息丰富，但不要杂乱。
>
> 视觉风格：竖版或横版均可，干净的浅色纸张背景，深蓝标题，黑色/深灰正文���条，搭配少量优雅的蓝色、青绿色、金色、红色强调色。使用圆角卡片、细线边框、编号标签、手绘箭头、局部放大框和总结栏。整体要美观、平衡、有学术感，让人一眼看懂这个概念的“结构”和“为什么”。

[陆三金 @threeaus]

Anthropic 的哲学家@AmandaAskell 最近参加了一个访谈，在访谈中她分享了自己探索好奇领域的一个方法。

提示词大概是：

我希望你从「xx」领域里选一个大概研究生水平的概念。然后我希望你通过写一个寓言的方式，间接地把这个概念完整讲出来。最好一直到快结尾时，人才会慢慢意识到这个概念究竟是什么。然后在故事之后，再补一段解释，把你刚才真正要讲的概念说清楚。

[宝玉 @dotey]

这个通过寓言故事学习概念的提示词真的很棒，我做了一点点小调整，方便你使用

--- 提示词 ---

我在学习：【Agent Harness】 这个概念。

我希望你通过写一个寓言的方式，间接地把这个概念完整讲出来。最好一直到快结尾时，人才会慢慢意识到这个概念究竟是什么。然后在故事之后，再补一段解释，把你刚才真正要讲的概念说清楚。

---- 实际结果 ---

玉室里的先生

很久以前，青云山里有一间密封的玉室。

玉室没有门，没有窗，墙壁厚达三尺。里面住着一位先生。没有人知道他��哪里来，只知道他极其聪明——天文地理、治国用兵、农桑水利，什么都懂。

但他有一个问题：他看不见外面，听不到外面，也走不出去。

第一个找到玉室的是齐国。齐国的做法很简单：在墙上凿了一个小洞，派人对着洞大喊问题，然后等先生把答案写在竹简上，从洞里递出来。

一开始效果还行。"今年麦子什么时候种？"先生答了，齐国照做，收成不错。

但问题很快就来了。齐国问："北边的敌军怎么打？"先生答了一套方略，头头是道。齐国照做，大败。

齐国大怒，觉得先生是骗子。但事后复盘才发现：先生根本不知道齐国的兵力有多少，不知道地形是山地还是平原，不知道敌军用的是骑兵还是步兵。他在玉室里凭空��出来的方略，只是"一般来说应该这么打"。

而齐国从头到尾，只问了一句"怎么打"。

楚国也找到了一间一模一样的玉室，里面住着一位同样聪明的先生。

楚国有个年轻的官员叫沈括。沈括第一次去玉室的时候，也只是对着洞喊话。先生的回答聪明但空泛，和齐国的经历差不多。

沈括没有骂先生。他想了三天，然后开始做一件奇怪的事。

他先派了两个识字的文吏，常驻在玉室旁边。一个负责把问题写清楚，连同所有背景材料一起整理好，从洞里递进去。另一个负责把先生递出来的答案仔细誊抄，遇到看不懂的地方，再递回去追问。

仅这一步，效果就明显不同。先生开始给出具体的、能用的建议。

但沈括没有停下来。他发现先生经常说"需要看看地图""要知道土壤的情况"，可先生看不见任何东西。于是沈括���安排了一批人，专门负责把地图、账册、田间观察的记录做成文字描述，送进玉室。

先生有了"眼睛"。

然后沈括注意到另一个问题。先生会说"把河堤往东移二十丈"，但先生自己动不了。说完就说完了。于是沈括组建了一支执行队，他们的职责是：接收先生的指令，去现场执行，然后把执行结果——成功的、失败的、意外的——全部记录下来，再送回玉室。

先生有了"手脚"，而且能知道手脚做了什么。

到这一步，楚国已经靠先生解决了好几个棘手问题。但沈括又发现了一个麻烦：先生偶尔会说错。他会用一种极其自信的口吻说出明显离谱的话。比如他声称某种草药能治疫病，但楚国的医官翻遍药典，找不到这种草药——先生编了一个不存在的东西，还说得言之凿凿。

沈括的做法很务实。他不要求先生不犯错，他在外面加了一层校验：每次先生给出关键建议，都有专人去交叉核实。能核实的才采纳，核实不了的标记存疑。先生的错误从流程上被拦截了，不需要先生自己改正。

先生有了"免疫系统"。

还有一个问题更微妙。先生每次回答问题的时候，并不记得上次说过什么。同一个问题问两遍，可能得到两个矛盾的答案。沈括发现先生的"记忆"是断裂的。

于是他安排了一个专职的记录官。这个人的工作只有一件事：把历次和先生的对话全部整理成册，每次递新问题进去的时候，连同之前相关的记录一起送进去。先生拿到的不再只是一个孤立的问题，而是一个问题连同它的全部历史。

先生有了"记忆"。

几年后，周边的国家都听说了玉室的事情。很多国家纷纷去找自己的玉室。他们都找到了——每间玉室里的先生都一样聪明，一样什么都看不见，一样走不出去。

但结果天差地别。

有的国家只凿了一个洞，全靠喊。先生说什么他们做���么，做砸了就骂先生蠢。 有的国家给先生递了一些材料，但执行全靠将军们自己理解，先生永远不知道自己的方案最后被执行成了什么样。 有的国家什么都做了，唯独没有安排校验。先生一本正经地胡说八道的时候，全国上下照单全收。

只有楚国，围绕先生搭建了一整套体系：感知、行动、校验、记忆。先生还是那个先生，但在楚国，他像是拥有了一副完整的身体。

有一天，沈括的学生问他："老师，先生到底有多聪明？"
沈括想了想，说："我不知道他有多聪明。我只知道一件事——他的聪明能发挥出几成，从来不取决于他自己。取决于我们在外面给他造了一副什么样的身体。"
学生又问："那我们做的这些事情，叫什么？"

沈括说："我管它叫'造身体的学问'。先生是脑子，我们造的是眼耳手脚、筋骨血脉。脑子谁都一样，谁的身体造得好，谁的先生���更有用。"

这个寓言在说什么

"玉室里的先生"就是大��言模型（LLM）。

它极其聪明，但它是一个封闭系统——没有感知，没有行动能力，没有持久记忆，也没有自我纠错的机制。你给它什么输入，它就基于这些输入来"想"，然后输出一段文字。仅此而已。

沈括围绕先生搭建的那套体系，在今天有一个专门的名字：Harness。

故事里的每个角色都对应着 Harness 的一个组件：

文吏（感知层）：负责把外部信息整理好，送进模型的上下文窗口。这包括 system prompt 的设计、上下文的组装、用户输入的预处理。模型的"视野"取决于你往上下文里塞了什么。

执行队（行动层）：模型说"执行这个命令"或者"调用这个 API"，但它自己做不了。Harness 负责接收模型的工具调用指令，真正去执行，再把结果反馈回来，形成一个"思考→行动→观察→再思考"的循环。

校验官（容错层）：模型会产生幻觉，会犯错。Harness 不指���模型自己不犯错，而是在外部设置护栏——linter、测试、交叉验证、结构化输出校验——从流程上拦截错误。

记录官（记忆层）：模型的上下文窗口是有限的，而且每次对话之间默认没有记忆。Harness 负责管理短期记忆（当前对话中哪些信息该保留、哪些该丢弃）、长期记忆（跨对话的持久化信息）和项目级知识（主动为模型准备的文档、规范、历史记录）。

而沈括做的事——设计、搭建、持续改进这整套体系——就是 Harness Engineering。

故事里最关键的一句话是沈括说的那句：先生的聪明能发挥几成，从来不取决于他自己，取决于外面给他造了什么样的身体。

翻译成今天的话就是：模型能力是地板，Harness 质量才是天花板。 同一个模型，套上不同的 Harness，表现可以天差地别。Claude Code 和 OpenClaw 用的是同一个 Claude 模型，但因为 Harness 不同，一个是程序员的身体，一个是项目经理的身体，能做的事情完全不一样。

这就是为什么越来越多的人意识到：在 Agent 时代，真正决定产品好坏的，往往不是你选了哪个模型，而是你围绕模型搭建了什么样的体系。

[Aiden Bai @aidenybai]

Introducing Expect

Let agents test your code in a real browser

1. Run Claude Code / Codex to QA your app
2. Watch a video of every bug found
3. Fix and repeat until passing

Run as a CLI or agent skill. Fully open source

[Sawyer Hood @sawyerhood]

Introducing the new dev-browser cli.

The fastest way for an agent to use a browser is to let it write code.

Just `npm i -g dev-browser` and tell your agent to "use dev-browser"

[Thariq @trq212]

We just released Claude Code channels, which allows you to control your Claude Code session through select MCPs, starting with Telegram and Discord.

Use this to message Claude Code directly from your phone.

[Google Cloud Tech @GoogleCloudTech]

https://t.co/Nhzbmwl85W

[Boris Cherny @bcherny]

Released today: /loop

/loop is a powerful new way to schedule recurring tasks, for up to 3 days at a time

eg. “/loop babysit all my PRs. Auto-fix build issues and when comments come in, use a worktree agent to fix them”

eg. “/loop every morning use the Slack MCP to give me a summary of top posts I was tagged in”

Let us know what you think!