8月11日2026 · 星期二

@dotey

Anthropic 今天宣布，一个未公开的研究版 Claude 在尝试证明黎曼猜想的过程中，虽然没能证明猜想本身，却在一个相关问题上取得了重大突破： 它把黎曼 ζ 函数的非平凡零点落在临界线上的已知比例下界，从 41.6% 提高到了 67.2%。 黎曼猜想是数学界最著名的未解难题之一，1859 年提出，至今 167 年无人能证明或推翻。它的核心主张是：黎曼 ζ 函数的所有非平凡零点都落在复平面上一条特定的竖直线上，数学家称之为“临界线”。 如果这个猜想成立，素数的分布就有了一种深层的规律性。这个问题列在克雷数学研究所的七大千禧年问题之中，悬赏 100 万美元。 既然全面证明太难，数学家们退而求其次： 能不能至少证明有多大比例的零点确实在这条线上？ 这个方向上的进展，过去 80 年是这样的： - 1942 年 Selberg 首次证明有正比例的零点在线上，但比例很小； - 1974 年 Levinson 证明至少三分之一； - 1989 年 Conrey 推到五分之二； - 此后又经历了几代数学家的努力，到 2020 年 Pratt 等人才把这个数字推到 41.7%。 换句话说，从 33% 到 41.7%，人类花了将近 50 年。Claude 一步跳到 67.2%，跨度接近 26 个百分点，是这个问题历史上最大的一次单步提升。 Claude 的发现建立在前人的工作之上。它结合了 Baluyot、Goldston、Suriajaya 和 Turnage-Butterbaugh 近年发表的一系列成果，以及数学家 Bombieri 在 2000 年的一篇论文。这些工作本身已经为突破铺好了路，而 Claude 找到了把它们拼在一起的方法。 Anthropic 的两位数学家 Levent Alpöge 和 Ralph Furman 审查验证了 Claude 的证明，外部专家 Brian Conrey 和 Dan Goldston 也在短时间内审阅了论文。Claude 还用 Lean（一种形式化证明语言）写出了可机器验证的证明。 过程本身和结果一样有故事。Anthropic 的一位员工 Jarred Sumner（不是数学家）在 Claude Code 中对 Claude 说了一句“认真试试黎曼猜想”，然后就把数学决策交给了模型。 Claude 先生成了 650 个想法，全部失败。被鼓励再试一次后，它花了一天半时间协调大约 60 个子智能体（subagent），运行了 2400 条命令，写了数百个 Python 脚本。这些子智能体之间分工明确：2 个负责核心数学思路，13 个为它们提供想法，30 个尝试但未能提出新思路，13 个做验证，2 个帮忙写论文。 整个过程中 Jarred 的参与基本限于给 Claude 打气，发的消息大多是“继续”和“相信自己”。 Anthropic 说，这种鼓励似乎帮助 Claude 克服了“我真的能在这种级别的问题上有所推进吗”的自我怀疑。 这已经是 Claude 今年第二次在数学领域搞出大新闻了。三周前，Anthropic 的数学家 Levent Alpöge 用 Claude Fable 5 找到了 Jacobian 猜想（Jacobian Conjecture）的反例，推翻了这个 87 年历史的代数几何猜想的一般形式。那次的反例简洁到人类数学家一天之内就能手动验证。 两次事件有一个共同点：Claude 做的不是解题，而是原创性的数学研究，是在数学家们几十年没能推进的前沿问题上找到了新路径。 Anthropic 也明确表示，Claude 使用的技术不太可能直接导向黎曼猜想的最终证明，但这个结果展示了 AI 模型在数学能力上的进步速度。 Anthropic 公布了 Claude 的完整论文、Lean 形式化证明、简明证明笔记，以及 Claude 自己描述思路演化过程的附录，都可以在 Anthropic 官网的研究页面找到。

@OpenAI串推 2 条

We've used GPT-5.6-Cyber extensively in real-world vulnerability research, including work that uncovered previously unknown vulnerabilities in popular open-source software like Chrome’s v8 engine.

Advanced capabilities require strong safeguards. That’s why access is limited to approved defenders, with additional controls and monitoring for higher-risk cybersecurity work. https://openai.com/index/expanding-daybreak-as-the-cyber-defense-window-narrows

@dotey 转推了

@dotey

转译自 Lenny Rachitsky 我从 Cursor 人才主管 Adam Ward (@wardadamp) 那里学到的最大收获： 1. 前线部署工程师 (FDE，forward deployed engineer) 是目前科技界最抢手的职位。 他们必须具备深厚的技术功底，同时又能和销售团队打好配合，在公司高管面前从容自信。他们要把复杂的产品转化为实际的商业结果，帮助客户优化 AI 账单，而不是仅仅在“最大化消耗 Token” 上做文章。 Adam 将这股热潮与当年的移动端工程师招聘潮相提并论——只不过，当年那股热潮持续演进了两年，而“现在，一切都发生在几天或几周之内”。 2. 传统的招聘漏斗，被 Adam 戏称为“死亡漏斗” (funnel of doom)，其实是个专门打造平庸团队的机制。 标准的招聘漏斗是这样的：联系 100 个人，20 个回复，每一轮面试淘汰掉一批，最后录用剩下的人。 但这套玩法建立在一个漏洞百出的前提上：最先回复你的那 100 个人，根本不是行业里最顶尖的 20%，他们可能只是那天碰巧心情不好、想换工作而已。等到候选人走到漏斗最底端时，你其实已经是在一个“矮子里拔将军”的池子里挑人了。 即便你的面试流程再严苛，最终拼凑出的也只是个平庸的团队。 3. 破局之道在于：把每一次招聘都当成“高管猎聘” (executive search) 来对待。 这意味着你需要严谨地界定岗位需求 (rigorous scoping)——对这个特定岗位而言，什么是“优秀”？ 这意味着你要精心绘制候选人图谱 (deliberate candidate mapping)——全世界最适合这个岗位的 50 个人到底是谁？ 这还意味着你要穷追不舍 (relentless pursuit)——锁定这 50 个人，死死咬住不放。这种视角的转变，意味着你要从确立“卓越支柱” (pillar of excellence) 开始招人，而不是一开始就撒一张盲目的大网。 4. 现在的“新危险区”出现在候选人签下 Offer 之后。 候选人接了 Offer 又毁约的趋势正在上升，而且资深人才从签约到入职之间往往有几周的空档期。因此，Cursor 把“接受 Offer 后”的这段时间当成一场专门的战役来打。 他们会组织新入职的员工一起聚餐，在入职第一天前就把笔记本电脑寄过去，在任何人正式打卡上班前，就让他们感受到社区的归属感。这不仅能确保大家准时报到，还能让他们在入职后更快地进入工作状态。 5. 实战考察 (work trials) 是预测一个人能否胜任工作的最佳指标。 研究早就反复证明了这一点，但目前行业的默认面试形式，依然是隔着桌子进行一轮又一轮的一对一聊天。Cursor 则会安排长时间的现场实战体验，让候选人与团队肩并肩，共同推进一个真实的（或者高度还原的）项目。 这种形式能同时传递出三层信号：技术能力、核心价值观以及协作默契度，同时也给了候选人自己做决定、双向奔赴的数据依据。Cursor 曾经做过一个实验，试着取消实战考察，结果团队对招进来的人信心大跌。于是，他们果断把实战考察加了回来。 6. 跑去问你的人脉圈“你认识的最牛的工程师是谁？”——这是一个陷阱。 相反，你应该根据你界定的岗位需求，抛出极其具体的问题：“在你合作过的所有产品工程师里，谁和设计师配合得最默契？”或者“谁能把一个技术框架转化成产品，而且比你见过的任何人都做得好？”——因为具体的提示词 (prompts) 才能让人脑海中迅速跳出确切的名字。 当有几个你信任的人，都不约而同地提到同一个人时（“Lenny 提到了他，Sally 也提到了他”），你就可以通过这种交叉验证，锁定那个你要放进“全球 50 强候选人”名单里的目标了。 7. 明确岗位需求 (scoping the role) 是大多数招聘流程中最被忽视、投入最少的一步。 “我一看到牛人就能认出来”——这绝对是个错觉。如果你不在前期花时间去明确、并给这个岗位在特定公司所需的技能、经验和特质排个序 (stack-rank)，你就根本不会有针对性的招聘策略，没法给出打动人的说辞，也设计不出真正有效的评估方法。后续所有的流程，其实都源于这最开始的一步。 另外，要抵制住“看名企光环”的捷径诱惑：在合适的时间、在某家大厂的优秀团队待过，这仅仅是“有可能”代表他很优秀；如果你直接照搬别人的用人标准，那你其实就是在给一个你本就觉得千疮百孔的招聘流程“抬轿子”。 8. 当顶尖候选人告诉你“现在时机不对”时，试着降低你的要求：“我不是要面试你——我只是希望能有下一次交流。” Adam 会默默埋下种子——比如喝杯咖啡、邀请参观办公室、或者把他介绍给一位对他的工作极其着迷的团队成员——这些种子会在几周、几个月甚至几年后开花结果。因为如果你选择了沉默，想着“秋天再联系”，那最好的结果也就是在没人抢走他的情况下，你碰巧捡了个漏。 在 Cursor，寻找一个热情的引荐人，所花费的心力几乎和写一封招募邮件一样多，因为一旦别人无视了你的第一条消息，再无视你的第二条、第三条就会变得越来越容易。 Cursor 还会巧妙地利用“主场优势” (home games)，把接触的重点放在一起吃顿饭上——“这既能让人卸下防备，又能拉近关系”——以及邀请对方参观办公室，刻意营造出那种大学校园导览时让人觉得“这里就像家一样”的直觉。 9. 促成签约 (closing) 是一项团队运动，而且从第一次对话就开始了。 当 Cursor 正在跟进一位高素质的候选人时，团队会针对这个人召开每日站会 (daily standups)：我们对他的动机有了什么新了解？他提出了哪些顾虑？团队里谁最适合去解答这些疑虑？ 每一位核心候选人都会有一个专属的 Slack 频道。所谓的“促单签约”，不应该感觉像是一次生硬的销售推销，而应该是整个流程中持续为你解答疑虑后，水到渠成的自然结果。 10. 用心是不花钱的，但它却是招聘中最大的“不公平优势” (unfair advantage)。 Adam 说，纵观整个招聘领域的历史，决定候选人满意度得分的最关键因素，就是让他们感觉到这家公司是真心实意想要你。 因此，Cursor 会精心设计每一个接触点 (touchpoints)：谁来迎接候选人，谁在午餐时坐在他们旁边，哪位面试官能和他们聊聊小众爱好——这一切都是精心挑选的，绝不是谁日程表有空就拉谁来凑数。 要让这种“用心”可持续，你需要转变一下思维：你是在为这个岗位招那“唯一的一个人”，而不是在招 10 个人。“不要把精力分散在 10 个人身上；把所有的专注都留给那唯一的 1 个。”

@dotey

Anthropic 宣布将给 Claude 的输出内容加上机器可读的标记，包括文本中嵌入的隐形水印，以及生成文件中附加的数字签名元数据。8 月 2 日起（也就是上周），所有新发布的 Claude 模型已经开始执行这套标记机制。 这是 Anthropic 为遵守欧盟 AI 法案第 50 条签署的透明度行为准则。但执行范围不限于欧盟，全球所有使用 Claude 的地方都会生效。 具体来说有两层标记。 第一层是文本水印：Claude 生成文字时，会在文本中织入人眼不可见的水印，不影响阅读体验和内容质量。这个水印的特点是“跟着文字走”，你把 Claude 写的一段话复制粘贴到邮件、文档或博客里，水印依然在，一定程度的编辑修改后也可能保留。 第二层是文件元数据：Claude 生成 SVG、PNG、JPG 等文件时，会附加符合 C2PA 标准的签名元数据。C2PA 是 Adobe、微软、Google 等公司共同推动的内容溯源开放协议，OpenAI 和 Google 的图像生成工具已经在用。 覆盖面很广。API、Claude 官网、Claude Code、Claude Cowork、Claude Tag，所有产品线都适用。通过 AWS、Google Cloud 或 Microsoft Foundry 调用 Claude 时，文本水印同样生效，但文件元数据取决于各云平台的功能支持。 在此之前，Claude 一直没有公开部署过文本水印。OpenAI 此前开发过文本水印方案，但出于各种考虑一直没上线。Anthropic 这次直接在文本层面落地水印，算是 AI 大模型厂商中走得比较靠前的一步。 对于用 Claude 写东西的人来说，一个直接的影响是：你用 Claude 起草的邮件、报告、文章，里面都会携带可被机器检测的水印。Anthropic 表示正在开发配套的检测工具，未来第三方也能检测。 不过限制也很实际。检测到水印只能说明内容“可能经过 Claude 处理”，不能确认 Claude 是原始作者，因为很多人用它润色、翻译、总结已有内容。反过来也一样，检测不到水印不代表内容不是 AI 写的，文本被大量改写后水印会消失，太短的文本信号不够可靠，文件经过格式转换或截图也会丢失元数据。 8 月 2 日之前发布的现有 Claude 模型，Anthropic 正在补充标记功能，具体时间表还没公布。如果你基于 Claude API 构建产品，Anthropic 建议你独立评估欧盟 AI 法案第 50 条对自己的合规要求。 相关文档：https://support.claude.com/en/articles/16266773-how-claude-marks-ai-generated-content --- From twitter --- bruh, you’re like a dude wearing full camo in downtown nyc. you are the watermark. that’s the load-bearing part and is worth sitting with. > 引用 @M1Astra: Anthropic says new Claude models will embed invisible watermarks in all generated text, everywhere Claude is offered. > > The watermark is part of the text, it isn't metadata: "it will travel with the text when it's copied and pasted elsewhere, and may persist through some editing." > > This starts with models launched on or after August 2, 2026, under an EU AI Act code Anthropic signed. Anthropic is still working on adding it to current models. The rollout is worldwide.

@Alibaba_Qwen

👀 Seeing is just the beginning. With Qwen-MM-Plugins, turn your favorite agent harness multimodal-native — read images, videos & documents, edit videos, work with 3D/CAD, and more. From multimodal models → multimodal agents. 🚀 Watch it in action: https://github.com/QwenLM/Qwen-MM-Plugins

@Pluvio9yte

赛博菩萨 Cloudflare 刚推出了 Kitesurf，给 Agent 专门做的浏览器引擎，跑在 Workers 上 Kitesurf 遵循 Chrome DevTools 协议，因此，任何能够操作 Chrome 的代理程序，都可以用来操作 Kitesurf。 如果你有下列的应用场景 • 需要Agent浏览网页星界 • 用 Claude Code / 自己脚本做 Playwright 自动化 • 批量监控、抓公开页、截图验收 那 Kitesurf 的用处是：把Agent 的眼睛从昂贵 Chrome 换成更便宜、更好扩的一层基建。 现在beta还是免费的，地址 http://kitesurf.cloudflare.app

@GitHub_Daily

让 Agent 做重复性任务，目前比较好的方式通过 Skill，但比较费劲要一步步写操作流程。 最近微软开源了 Skill Recorder，通过把操作录一遍，AI 自动还原成意图和步骤。 我们还可以进行编辑修改，没问题后，再转成 Agent 能复用的 Skill。 在录屏时，还能开麦克风一边录屏一边口头描述，录完就让 AI 分析整段操作。 GitHub：http://github.com/microsoft/skill-recorder 生成的 Skill 会用 Agent 自带的工具来执行，从一次操作示范里归纳出通用流程。 经常要给 AI 写 Skill 操作指令的朋友可以试试，录一次比写半天文档快多了。

@realmadhuguru

if you love intelligence, you set it free

@dotey 转推了

@lifesinger

Anthropic 的产品，为什么这么厉害。 刚看了公众号《海外独角兽》的最新文章。非常不错，强烈推荐。 Anthropic 公司里有个 Labs 团队。 Labs 团队会围绕不同的技术判断播下大量种子，再把它们放进 Anthropic 内部的真实工作环境里生长。有些很快因为需求不足而枯萎，有些因模型能力的季节还没到，暂时进入休眠。只有极少数能在反复的 Dogfooding 中逐渐扎根。 　 最终，一个产品只有在内部目标用户中跑出足够好的周活和留存，才有机会对外发布。Anthropic 现在同时运行着几百个原型，其中绝大多数永远都不会面世。 Claude Tag 最早也是这样一个内部实验。它经历了几个月的真实使用和反复打磨，先改变了 Anthropic 自己的工作方式，直到今年 6 月才正式对外发布。

@LangChain 转推了

@hwchase17

💻How to build a web browsing agent Stagehand v4 is an SDK to let agents browse the web from @browserbase We created a tutorial to show how you could use Stagehand with Managed Deep Agents to create a production ready web browsing agent https://youtu.be/O0hkpChFBkM

@bibryam 转推了

@Aurimas_Gr

𝗔𝗜 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 is a must have in your tool belt as an AI Engineer. 𝗧𝗿𝗮𝗰𝗶𝗻𝗴 sits at the core of it, why is it important? Tracing and instrumentation of software have been around for decades now. With AI systems resembling regular software even more, we are now moving the practice here as well (with a few key differences). Let’s look into the process of tracing from a perspective of a naive RAG system. 𝘍𝘦𝘸 𝘥𝘦𝘧𝘪𝘯𝘪𝘵𝘪𝘰𝘯𝘴: 𝘼) An Orchestrator in the GenAI system application is the central piece of software that orchestrates the end-to-end process. Think of apps using LangChain, LlamaIndex or Haystack. 𝘽) Trace is the end-to-end application flow from the entry point till the answer is produced, it is composed of smaller pieces called spans. 𝘾) Span is a smaller piece of the application flow that represents an atomic action like a function call or a database query. They can be sequential, or run in parallel. ℹ️ As part of span we capture general metadata like start and end time, inputs and outputs of the span. On top of this metadata we track information specific to the GenAI system elements. What might a trace look like for a naive RAG system? 𝟭. A query that has been submitted to the chat application. 𝟮. The query is embedded into a vector. ✅ Additional metadata like input token count is persisted with the span so that we can estimate the cost of the procedure. 𝟯. ANN lookup performed against the Vector DB to retrieve the most relevant context. ✅ Additional metadata about the query is persisted as part of the span together with the retrieved pieces of context and their relevance. 𝟰. A prompt is constructed from the system prompt and retrieved context. 𝟱. The prompt is passed to the LLM to construct the answer. ✅ Additional metadata about input and output token count is captured together with the span so that we can estimate the cost of the procedure. 𝘞𝘩𝘺 𝘪𝘴 𝘵𝘳𝘢𝘤𝘪𝘯𝘨 𝘰𝘧 𝘎𝘦𝘯𝘈𝘐 𝘴𝘺𝘴𝘵𝘦𝘮𝘴 𝘪𝘮𝘱𝘰𝘳𝘵𝘢𝘯𝘵? - These applications are usually complex chains, errors can happen in different steps of your application. E.g. Embedding of query is taking longer than expected or you have reached API limits of LLM provider. - Cost for calling LLM APIs will be variable depending on the length of inputs and produced outputs. You would usually trace this information and analyze it to help forecast expenses. - GenAI systems are non-deterministic and will deteriorate over time. They need to be evaluated on span level rather than input/output of the entire system so that you can tune each piece separately. - … Are you tracing your Agents? Let me know in the comments 👇