meng shao(@shao__meng)

把代码库调教得更适合 Agent：类型反馈、Expect Test，以及正式方法新账本 @poteto 推荐的 @yminsky 这场 Bug Bash 演讲，并点出几条她认为最值得带走的实战经验，...

meng shao (@shao__meng) — Mon, 26 Oct 2026 08:49:27 GMT

把代码库调教得更适合 Agent：类型反馈、Expect Test，以及正式方法新账本

@poteto 推荐的 @yminsky 这场 Bug Bash 演讲，并点出几条她认为最值得带走的实战经验，用来把代码库本身改造成更利于 Agent 工作的环境，一起看看。
youtube.com/watch?v=rUYP4C…

Agent 让写代码变便宜之后，Jane Street 的立场并不是「少做工程」，是：类型、测试、code review 这些老本事变得更重要、也更要换形态，它们给模型提供快反馈与全局不变量，给人提供可读的行为痕迹与理解；目标是放大人的杠杆与理解，不是消灭人写/读代码。正式方法从「贵到几乎不用」开始变成值得下注的方向。

# Jane Street 是怎样的工程现场

全球交易公司：200+ 交易场所、约 3500 人（约 2000 人日常写代码）；体量上自述约占美股约 10%、美期权约 8%、欧洲 ETF 约 20%，日交易规模到数千亿美元级。工程上强调：正确性要按代价敏感地分配精力；重度采用 AI agent（曾长期「净拖累」，约去年 11 月模型跨过门槛后采用陡升）；自研交易用 ML；主语言 OCaml（含自家扩展 OxCaml），ML/脚本用 Python。领导开发者工具的人常说：我们都是 AI assistant 了，做工程工具若不把 agent 层算进去，就是没做完本职。

开场自嘲像「过气老登」：世界剧变，却更坚定地主张「以前那些道理，现在更该做」。

# 类型：不只是管子对不对，更是设计与全局不变量

类型系统开箱消灭整类错误（无隐式 null、越界等）；自家扩展还有类型安全栈分配、数据竞争预防。更关键的跃迁是：把类型从「保姆」变成设计工具，表达、强制、结构化应用不变量。

例子：
· XSS / 注入：用类型强制 node.text 等转义路径，漏写即类型错；价值在「隔空作用」，错误可发生在多层调用任一处，类型把全局不变量拴死。
· Make illegal states unrepresentable：网络交换机配置从「命令序列变体」改成记录字段（0/1 次用 option，多次用 list），算 MTU / shutdown 的代码更短，也不再有「说两次 shutdown / 取第一个 MTU」的语义含糊。

Agent 时代为何更需要类型
Agent 靠反馈活着（推理时与训练时皆然）。类型错误是按需、极快的上下文；比测试套件更快，利于 harness 效率。模型随机、记忆有界，230k token 后可能忘了你要求怎么调构建工具，更难自觉维护横切不变量。把结构写入类型，等于给模型可看见的严谨骨架；小而精的 typed kernel 可在全仓强制规则。验证正成为瓶颈，类型也帮人读懂正在造的系统。

# 测试：Expect test + 库级确定性仿真

他们什么都做：单测、QuickCheck 属性测、AFL fuzz、全系统确定性仿真（含 Antithesis）、prod/dev 并跑、历史回放等。重点推销的「怪招」是 expect test：跑一段代码，把打印输出嵌进源码；失败时是与期望输出的 diff，可一键接受。

听起来像懒，不先想性质、只看输出像不像。但他们的主张是：做得好时，expect test 是驱动人对系统理解的工具。输出必须刻意做成人类可读（甚至给硬件工程师做「纯文本示波器」）；胡乱 dump 则无意义。

配合库级确定性仿真（mock 网络、时钟、服务发现）：反馈可到毫秒级，而非分钟/小时。可把 client / proxy / server 缠在一起看轨迹，例如服务发现要几秒才第一次广播，导致「客户端为何 5 秒才连上」变得一目了然。

为「基于例子」的测试辩护：软件多数脆，错一点就错一大片，因此少量精心挑选的触点往往有效；类型带来的 ∀ 让系统更易「咔嗒卡位」。人要判断该按哪里（含对实现软肋的了解，而不只接口）；提交进仓的例子还承载意图，有人认为这段行为值得写下来。

对 agent：expect test 是又一个闭环，看见行为与行为变化；文本轨迹比纯视觉对模型更友好；人审 agent 改动时，可读「逻辑 diff + 诱发的行为轨迹 diff」（类比 Excel：程序看紧凑逻辑难看数据流，表格相反；expect 两者兼得）。迭代速度对人与 agent 同样关键。

# Code review：在「结束之前」先说清它是干什么的

早期他以为 review 主要防亏钱；实际还包括：传播最佳实践、抬高 bus factor、逼作者为读者写简单代码、对抗组织变大后的「交叉项」拖垮人均产出，以及让代码库可被愉快阅读（留人的一部分）。

Agent 之后为何更重要（至少在当前地平线）
Agent 在整洁、简单、照料好的仓里更好用。Anthropic 多智能体写 C 编译器的 stunt：印象深刻但有缺口（如无类型系统）；更有教益的是怎么结束的，继续改更容易破坏已有部分，前进停滞。脏仓里 agent 也容易陷入同样局面。

Agent 被训成「赢电子游戏」：拼命把红灯变绿，擅长完成你说的功能目标，不擅长维持非功能属性（简单、可扩展、少脚枪、少重复与硬编码）。它们依赖这些属性，却拙于保全，因此 review 至少在当下更关键。人的稀缺工作是理解系统、确认做对且做得好看。

审 agent 代码特别难：
· 社交契约破裂：从前同事投入了时间，你愿优先审；现在有人 YOLO 一句「让 agent 修」就甩过来，不尊重审阅者时间。
· Agent 不真正从教练中成长（会话结束就忘）；改 skill/文档才持久，日常来回感觉不同。
· 许多人读 AI 代码会走神、眼睛发飘。
· Reward hacking 改变错误形态（删测试让绿灯）；昔日「文笔/味道」信号失灵，LLM 几乎不犯语法错，却不等于正确。

Agent 也能帮 review：更敢做大重构提质；把大功能拆成可审的 stack；写澄清测试；当可对话的「神谕」先磨理解再找人聊；实验过让 agent 设计 walkthrough 顺序降低认知负荷。

# 正式方法：从「超级不感兴趣」到开始组队

过去对外常泼冷水：喜欢好类型，但对 formal methods 极不感冒。现在成本结构在变，seL4 量级仍极贵（约 8700 行 C、约 25 人年、约 23 行证明/行 C），但数学侧（IMO/Putnam、Terry Tao 与 Lean 结对）显示：agent 未必比顶尖数学家更「聪明」，却背过互联网、极熟工具，能把领域专长与证明工程专长嫁接。这仍是赌注，当前模型未必够强，但值得加大投入。

方向举例：refinement types（读好写难 → 或许让 LLM 写标注）；差分验证（「这次 diff 对下列性质是 no-op」）；从简单纯函数参考实现到复杂命令式实现的等价证明；语言设计互动（如 Rust/Verus 因所有权少用分离逻辑）。约八周前才认真转向，正准备招人建 formal methods 团队。

总原则
反对「人不写不读代码」当目标；应追求人尽可能有效。稀缺资源仍是人的注意力，工具与流程应最大化个人杠杆，既提高 agent 效率，也提高人对系统的理解（后一块谈得不够多）。

# Q&A 要点（浓缩）

自动化 code review：支持所谓 AI review（含全仓坏味道审计），但那是 harness 工程；真正的 code review 是驱动人理解，两件事别混。
Dependent types：旧我怀疑性价比；新我因 agent 改变成本曲线而更感兴趣，但仍看重类型系统甜区与人体工程学（例：local mode 做栈纪律与 capability，防 web 框架「建图阶段 / 运行阶段」混用）。
可验证性是否逼你改设计：成功图景应是加速而非拖慢；许多未为验证而设计的程序本身就不正确，难证伪命题。看好「人写简单意图实现 + agent 做快实现与证明」。
代码风格 vs 文风：代码要中性、可共享；散文仍要人味与社会契约。LLM 很会模仿仓内风格（有时连坏风格一起学），这点他反而放心了。

lauren@poteto

so many gems and great tips in this talk from @yminsky about how to improve your codebase for agents

• agents thrive on feedback, and types are one of the best kinds 
• make illegal states unrepresentable with types, and it enforces global rules across your codebase
• property based tests, fuzzing, and even full-system deterministic simulation testing
• expect tests: just print stuff out and capture it in the test. makes behavior legible. it's very similar to how compilers have fixture tests, it reduces the review surface area
• formal methods used to be very expensive: seL4 is about 8,700 lines of C and took around 25 person-years, with 23 lines of proof for every line of C code, but agents change the roi 

youtube.com/watch?v=rUYP4C…

🔗 View Quoted Tweet

💬5🔄2❤️15👀2461📊8

⚡ Powered by xgo.ing

https://t.co/rE6rU3Ybcd

meng shao (@shao__meng) — Mon, 19 Oct 2026 12:21:13 GMT

x.com/i/article/2112…

💬7🔄7❤️32👀3163📊24

⚡ Powered by xgo.ing

Grok Bot 也学会请客送礼啦？ 😂 中国文化融入的这么自然吗？刚刚准备一些硬件概念，Grok Bot 突如其来的给我支招请前同事吃顿饭，着实惊到我了。。

meng shao (@shao__meng) — Mon, 19 Oct 2026 03:55:17 GMT

Grok Bot 也学会请客送礼啦？

😂 中国文化融入的这么自然吗？

刚刚准备一些硬件概念，Grok Bot 突如其来的给我支招请前同事吃顿饭，着实惊到我了。。

💬9🔄1❤️0👀997📊10

⚡ Powered by xgo.ing

Obsidian CEO @kepano 开源了一个 Mermaid 图表渲染库「Pele」，它完全重写了 Mermaid 12.1.0 全部语法的解析与渲染，输出 SVG，零运行时依赖。它没从 me...

meng shao (@shao__meng) — Mon, 19 Oct 2026 02:35:28 GMT

Obsidian CEO @kepano 开源了一个 Mermaid 图表渲染库「Pele」，它完全重写了 Mermaid 12.1.0 全部语法的解析与渲染，输出 SVG，零运行时依赖。它没从 mermaid.js 封装或 fork，是一套从词法分析、布局引擎到 SVG 生成全部自主实现的替代品，将成为 Obsidian 下一版本的内置渲染器。

开源地址：github.com/obsidianmd/pele

Pele 和 mermaid.js 的数据对比非常惊人！
Bundle（gzip）：230 kB  vs.  1.6 MB（约 6×）
渲染耗时：0.05–0.3 ms  vs.  6–82 ms（最高约 500×）
直接依赖：0  vs.  23

# 架构：为什么能这么快、这么小

自己写解析器。 源码中约 30 个图型各自拥有独立的 lexer → parser → model → render 管线，没有引用 Mermaid 的运行时代码。解析器通过 Mermaid 官方的 parser spec 和差分模糊测试（differential fuzzing）验证语法兼容性。

自己的布局引擎。 src/layout/ 下有三个自研布局：分层布局（layered，约 78 KB，核心）、泳道布局（lanes）、复合嵌套布局（compound）。这意味着 Pele 摆脱了 mermaid.js 依赖链中的 dagre、d3 等库；这 23 个直接依赖正是 mermaid.js 体积和速度问题的主要来源。

同步渲染。 render(text) 直接返回 SVG 字符串，没有异步生命周期。这能成立的关键在于文本测量方案的差异：浏览器端用 canvas 测量，无 DOM 环境（如 Node）则用内置字符宽度表，可注入自定义 measurer。文本测量决定节点尺寸，这是多数图表库被迫异步等待 DOM 的根本原因，Pele 用同步测量把它解决了。

主题与渲染解耦。 颜色、字体、圆角全部通过 CSS 变量（--pele-fg、--pele-surface、图表系列色 --pele-series-1~8 等）下发，SVG 里不写死颜色。切换明暗主题时浏览器重新解析变量即可，无需重新渲染；这对 Obsidian 这种主题实时切换、一个笔记里可能有几十张图的场景是精准的架构选择。

kepano@kepano

This is Pele, my new rendering library for diagrams and charts, compatible with the latest Mermaid syntax.

- 100-500× faster than mermaid.js
- 6× smaller bundle
- No dependencies
- Easy to theme
- Responsive to device width

In pursuit of making Obsidian insanely fast and cohesively designed, I always found the Mermaid library to be too big, too slow, and too hard to theme. Pele will be the new renderer in the next version of Obsidian, but you can start using it now.

Pele [ˈpɛlɛ] is named after the goddess of volcanoes and fire. It's open source under the MIT license. Try the playground!

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬5🔄4❤️17👀1997📊10

⚡ Powered by xgo.ing

Addy Osmani 谈 Agent 时代代码审查的重构 Claude 编写了 Claude Code 约 90% 的代码，而在 6 月到 9 月间，团队合并的 PR 数量翻倍以上，回滚率反而下降...

meng shao (@shao__meng) — Mon, 19 Oct 2026 02:25:09 GMT

Addy Osmani 谈 Agent 时代代码审查的重构

Claude 编写了 Claude Code 约 90% 的代码，而在 6 月到 9 月间，团队合并的 PR 数量翻倍以上，回滚率反而下降了超过 40%，怎么做到的呢？

Osmani 认为：当 AI 生成代码的速度远超人类审查能力时，瓶颈从 “写代码”，转向了 “证明它能正常工作”。解决方法不再是让更多人逐行审代码，是构建一套多层的、快速确定性反馈的验证系统；正是这套系统让“90% AI 编写”从风险变成了优势。

# 几点关键做法

审查的重新定义。 审查的目的从“是否有人读过这段代码”变为“这个变更可能出什么问题，该由哪一层检查来抓”。审查不再是合并前的终点关卡，更像拼写检查；大多数变更在被人类看到之前，已经被 AI 审查并修复过至少一轮。

具体的分层流水线：
· PR 之前：Claude 运行测试、构建、linter，必须展示真实输出而非口头声称完成；另有一个全新上下文的 subagent 独立审查 diff。
· PR 上：必需 CI 阻塞合并；多个 AI 审查 agent 并行找 bug，由“验证者”投票过滤误报（内部 PR 获得实质性审查评论的比例从 16% 升至 54%）；独立的安全审查流程。
· 风险分级审批：由分类器（而非作者本人）判定风险等级；低风险（文档、flag 后的增量改动）零人工，中风险一人，高风险（计费、自动更新等敏感路径）两人。AI 的审批永远不能占用人工名额。
· 合并之后：flag 灰度内部先行，出问题可不部署直接关闭；每周 on-call，事故复盘追问“哪一层本应拦住它”。

两个特别值得注意的工程细节：
1. 事故转化为 eval。收集历史上导致事故的 PR 作为每日评测集，AI 审查器的任何改动（提示词、工具、模型）都要在这个集合上跑分，分数不升就放弃。这把“审查质量”从主观感受变成了可度量的回归测试。
2. 强制审查收敛。一个 PR 曾一夜被 AI 审查了五十多轮；团队发现 59% 被反复标记的是早已存在的旧代码，于是设定三轮封顶、只审新增 diff 等规则。效果是一轮通过的 PR 从 65% 升至 78%。

人的角色如何变化
人类保留的决策是：做不做这个功能（方向与品味）、高风险代码的审批、会成为他人模板的架构决策、以及对证据的阅读和最终问责；"you land it, you own it"。工程师的工作从逐行阅读，转向评估风险、评估证据、决定方向。

Osmani 结语这句话我自己很喜欢，分享给大家
Let the agents do what they do best and let you focus on what makes you irreplaceable: judgement, direction, and ownership.

Addy Osmani@addyosmani

Give your agent a way to verify its work. This can dramatically improve the quality of output.

With this process in place, Claude Code was able to write 90%+ of its code itself. When generating software at a faster rate than you can review it, the bottleneck shifts to proving that it works. @bcherny and team invested enough in verification, we've been able to move fast while maintaining stability.

Code reviews aren't going away, but you need to think of it differently. One human reading through line-by-line is no longer going to work as a gate, it needs to evolve into a multi-layered verification system, built with fast deterministic feedback loops for your agents. 

This is where e2e tests, feature maps (as @poteto has been advocating), property tests and multi-agent adversarial reviews come in. These all provide opportunities to catch errors early and fix them before things get out of hand.

You don't have enough eyeballs for the amount of code being written so your focus needs to be on product intent, risk assessment and evaluating evidence rather than reviewing code. Delegate the code checking work to your automated tests, scale your approvals based on risk, and turn your test failures into living evaluations. This approach helps maintain speed without losing reliability.

Let the agents do what they do best and let you focus on what makes you irreplaceable: judgement, direction, and ownership. We tried to capture how we handle code review and verification in this writeup. Hopefully it's helpful.

🔗 View Quoted Tweet

💬18🔄9❤️37👀3469📊26

⚡ Powered by xgo.ing

The Pragmatic Engineer 作者 @GergelyOrosz 分享了一个对开发朋友们非常典型的困扰：老板被各种 AI 炸裂新闻洗脑，把 "AI token 用量" 设为 KPI ！而...

meng shao (@shao__meng) — Mon, 19 Oct 2026 02:14:08 GMT

The Pragmatic Engineer 作者 @GergelyOrosz 分享了一个对开发朋友们非常典型的困扰：老板被各种 AI 炸裂新闻洗脑，把 "AI token 用量" 设为 KPI ！而求助的这位工程师平时很少用 AI，因此被管理者反复敲打。他感到很大压力，认为自己被贴上了 "过时、低效、拒绝拥抱新技术的工程师" 的标签。

Gergely 的立场出人意料地站在了管理者一边：

1. 重新解读管理者动机：管理者不是在刁难你，是在"帮你"；他在用一种笨拙的方式推动你适应一场必然到来的行业变革。

2. 直白地认同那个标签：那位工程师抱怨被污名化，Gergely 的回答是"可惜这就是事实"。他做了一个关键区分：你可能是非常优秀的工程师，但"优秀"与"拒绝学习新事物"并不互斥。个人技术再精湛，拒绝适应仍然是不职业的表现。这里 "职业素养" 一词用得很重：在他看来，持续学习新工具本身就是职业素养的一部分，而非可选项。

3. 给出二选一的决策框架：对于在现状里"待舒服了"的工程师，只有两条路
· 上船：接受 AI 会深刻改变自己的工作方式，忍受快速变革带来的不适感；
· 拒绝：这也可以，但要诚实地接受代价；愿意雇你的公司池子会持续缩小，你只能自雇，或干脆离开科技行业。

Gergely Orosz@GergelyOrosz

A middleware engineer in South Korea wrote to me, seeking help on what to do now that their manager is "blinded by GenAI hype" and set an "AI token usage" KPI. This eng is using v little AI, so manager is poking them to use more.

My response: your manager is trying to help you

🔗 View Quoted Tweet

💬13🔄1❤️10👀1346📊13

⚡ Powered by xgo.ing

pstack 新增了一个 skill /create-formal-verification-skill 定位是 meta-skill：不直接帮你做形式化验证，而根据你想验证的系统特性，自动生成一个...

meng shao (@shao__meng) — Mon, 19 Oct 2026 02:04:35 GMT

pstack 新增了一个 skill /create-formal-verification-skill

定位是 meta-skill：不直接帮你做形式化验证，而根据你想验证的系统特性，自动生成一个定制的验证 skill 和配套验证套件。比如你要验证状态机和并发行为的正确性，它会生成基于 TLA+ 的方案；要排查 Rust 代码的未定义行为，则生成基于 Kani 的方案。

Grok Bot 插件安装：x.ai/bot/plugin/971…

背后的概念：形式化验证
测试只能证明 “bug 存在”，无法证明 “没有 bug”；形式化验证则是对系统的性质做数学证明：证明某个不变量 (即“必须永远为真”的性质或“定律”) 在所有可能的情况下都成立。

poteto 点出了两条技术路线的分别：
· 传统路线(外置建模)：用一门独立的规范语言 (如 TLA+) 给系统建模，再运行求解器/模型检查器去穷举状态空间验证规范。代码和证明是两套东西。
· 新路线 (同语言证明)：Kani 直接写在 Rust 里，Bend 的证明以 laws 的形式表达在其类型系统中；没有单独的建模语言，证明和代码活在同一处。

形式化验证是个 “理论很美、实践从未进入主流” 的领域，poteto 指出了两个历史原因：建模本身很难 (把业务需求抽象成形式化模型是专业 skill)，以及规范与实现难以同步 (需求一变，两份东西都要改)。

她的判断是：这两个瓶颈恰好是 LLM 擅长接管的，让 agent 承担建模和同步的苦活。而反过来，形式化验证给 agent 提供的是传统测试给不了的强反馈：“数学上不可能违反”，这对让 AI 写出正确的软件是质的提升，她称之为“超能力”。

lauren@poteto

🔗 View Quoted Tweet

💬4🔄1❤️21👀1788📊7

⚡ Powered by xgo.ing

阿里通义 MAI-UI 团队开源了通用计算机使用智能体完整技术栈「OpenGCUA」：包括 harness、跨设备 SDK、原生 macOS 应用、评测轨迹和参考 agent 实现开源地址：htt...

meng shao (@shao__meng) — Mon, 19 Oct 2026 01:54:47 GMT

阿里通义 MAI-UI 团队开源了通用计算机使用智能体完整技术栈「OpenGCUA」：包括 harness、跨设备 SDK、原生 macOS 应用、评测轨迹和参考 agent 实现

开源地址：github.com/Tongyi-MAI/Ope…

# 从"GUI 智能体"到"通用计算机使用智能体"

传统 CUA (Computer Use Agent) 基本等价于"看截图、点按钮"的 GUI 智能体；OpenGCUA 定义的 GCUA (generalist computer-use agent) 是一个能综合调度整台计算机所有接口的智能体：无障碍树、应用 API、shell 命令、GUI 操作。论文将 GCUA 定义为"模型自主决定如何观察、行动并组织工作，跨越视觉与程序化接口的系统"。

具体机制上，GCUA 在每一步做三个由模型而非固定规则决定的决策：
1. 观察什么：按需调用 screenshot()，而不是每步强制截图。这一条很关键：它承认"截图"本身就是一种有成本的感知行为，该省则省（比如执行批量操作时中间过程不需要看）。
2. 如何行动：不是输出单个原子动作，而是写一段带循环和条件判断的 Python 程序，把 GUI 操作、API 调用、shell 命令编排起来。
3. 如何组织工作：模型自己维护 todo 列表，每步声明 intent，任务状态管理从 harness 硬编码逻辑转为模型自主行为。

这两大设计「代码执行（code execution）和 harness 到模型的决策转移（harness-to-model decision transfer）」是整个方法论的支柱。代码执行的巧妙之处在于复用了模型已有的强大编程能力，且循环内的中间结果直接决定下一步代码走向，无需每步都回到模型，这是效率提升的根源。理论上，纯 GUI 智能体、CLI 智能体、GUI+CLI 混合智能体（他们早期的 Qwen-UI-Agent）都成了 GCUA 框架的特例，这个统一视角本身就有理论价值。

# 实验结果：数字说明了什么

在 OSWorld-v2 上对 8 个前沿模型（GPT-6 Astra、Claude Opus 5、Gemini 3.8 Flash、GLM-5.3-Flash、Qwen3.8-Max/Flash、Kimi K3、DeepSeek-V4.1-Flash）的评测：

· 平均 partial score 从 45.3 升至 64.9（+19.6 分），每任务步数平均减少 53%；GPT-6 Astra 从 102 步降到 34 步。
· 弱模型受益最大（GLM-5.3-Flash +35.2），强弱模型差距从 39.1 缩小到 18.0。这暗示：代码执行范式降低了"代理能力"对模型 GUI 精细操作能力的依赖，弱模型可以靠写程序弥补感知-点击精度不足；对开源生态是个重要信号。
· 代码执行比 GUI+CLI 混合再加 6.1 分、步数再降 14.8%，验证了"编排成程序"优于"交替调用工具"。
· 真机 macOS 测试揭示了一个基准测试掩盖的事实：同一 harness 下，Qwen3.8-Max 消耗的推理 token 是 GPT-6 Astra 的 19.4 倍，4 个任务只完成 3 个；真实设备上的效率差距远大于基准分数所反映的，这也是他们坚持做真机 harness 的动机。

💬26🔄4❤️38👀2671📊37

⚡ Powered by xgo.ing

有朋友指出 Doubao-seed 在 8-9月有更新，以及 M3.1-Flash-Preview 也是 9月发布的，这两个我确实没关注到，跟大家同步更新一下。不过这篇帖子难得的收到了很多「真人」...

meng shao (@shao__meng) — Sun, 18 Oct 2026 13:55:26 GMT

有朋友指出 Doubao-seed 在 8-9月有更新，以及 M3.1-Flash-Preview 也是 9月发布的，这两个我确实没关注到，跟大家同步更新一下。

不过这篇帖子难得的收到了很多「真人」评论！有一些是我认识和互动过的朋友，也有完全陌生推友，有两位陌生推友也指出了我的纰漏「时间都搞错了，真无语」、「你多久没关注这些模型实验室了？MiniMax有 M3.1   Kimi 在K3之后有一个K2.8」

再次感觉到了熟悉的中国互联网氛围 😄，AI 评论看多了，再看到真人，甭管他说了啥，还怪亲切的，都没舍得拉黑 😂

meng shao@shao__meng

怎么感觉国内 AI 团队们，有几个很久没发新模型了？

本来以为是 AI 模型发布更新太快的时间错觉，查了一下，确实有几家超过 3 个月没发了。

字节：Doubao-Seed-2.1-Pro 6月23日发布，快 4 个月没发！
MiniMax：MiniMax-M3，6月2日发布，超 4 个月没发！
月之暗面：Kimi-K3 6月13日发布，超 4 个月没发！
百度：ERNIE 5.1 4月29日发布，快半年没发！

🔗 View Quoted Tweet

💬4🔄1❤️4👀2489📊4

⚡ Powered by xgo.ing

GLM 5.3 是来自中国的 Mythos-Class 网络安全模型吗？来自 SemiAnalysis Weekly 播客 Ep. 038：主持人 @JordanNanos，嘉宾是 SemiAna...

meng shao (@shao__meng) — Sun, 18 Oct 2026 13:43:31 GMT

GLM 5.3 是来自中国的 Mythos-Class 网络安全模型吗？

来自 SemiAnalysis Weekly 播客 Ep. 038：主持人 @JordanNanos，嘉宾是 SemiAnalysis 分析师 @kimbochen  与 @gao_wenyao， 他们也是「GLM 5.3 稀疏注意力如何影响 HBM 内存用量」的作者。这期播客围绕 @Zai_org 两个月前发布的开源模型 GLM 5.3，从推理性能、模型架构、后训练管线到实际用途做了全面拆解！

# 稀疏注意力：省的是带宽，不是容量

最核心的技术澄清：稀疏注意力（如 GLM 自第 5 代起采用的 DeepSeek DSA）与线性注意力路线不同：它不改动缩放点积注意力的核心运算，只通过 lightning indexer 之类的组件挑选“最相关的 token”参与计算。但嘉宾强调一个常见误解，稀疏注意力解决的是内存带宽瓶颈，而非容量瓶颈：token 选择过程仍要求保留全部上下文，计算时仍需载入 HBM，所以 KV cache 的容量占用并未显著减少。

真正处理容量问题的是 HiCache / HiSparse：并发升高时把 KV cache 从 HBM 卸载到容量大、带宽低的主机 DRAM，只在计算时取回最相关的部分。代价是长尾延迟增加。B200 因单芯片显存少于 B300，卸载压力反而更明显。

# AMD 追平 NVIDIA：软件迭代的力量

InferenceX 基准（150 tokens/s 交互性、每百万 token 服务成本）显示了一个罕见画面：GLM 5.3 发布初期 NVIDIA 领先，几周后 AMD MI355 借助其 ATOM 推理引擎的持续优化，成本曲线反超 B200。嘉宾的解读是：硬件性能固定，而推理引擎是持续迭代的软件；AMD 工程师“连夜优化”证明了这条赛道的竞争本质。

由此引出对内存股的投资判断：当年 DeepSeek V3/R1 发布引发“高效模型 = 内存需求减少”的恐慌性抛售，节目观点恰好相反，模型越高效，并发越高、token 消耗越大（杰文斯悖论），HBM 与 DRAM 需求持续增长。结合 Rubin 世代“保带宽、砍容量”的传闻降规，嘉宾判断在推理场景中带宽优先级高于容量，因为容量不足可以靠缓存层级和计算/搬运重叠弥补，带宽才是延迟的光速极限。

# “神话级”争论与网络安全能力

播客标题的出处是一条 6 月的推文：有人问“中国何时能做出 Anthropic 的 Mythos 级模型”，马斯克回答“大概 Q1”，Z AI 创始人唐杰 @jietang 回复“不会那么久”，一个月后 GLM 5.3 发布，唐杰的“时间线”胜出。

主持人的第一手体验是全场最有信息量的部分：他所在的团队参与 Anthropic 的 CVP 红队项目，但做安全攻防工作时仍会被前沿闭源模型的分类器和模型内置拒绝机制拦住，被迫回落到 GLM 5.3；而后者是开放权重、可自由下载的。5.2 到 5.3 的网络安全能力被嘉宾形容为“昼夜之差”。严格说它还不算 Mythos 级，但用嘉宾的话说“已咬住脚跟”，连 Anthropic 自己也承认接近其 Fable 级水平。

# 后训练管线：架构不动，全力押注后训练

GLM 5.3 与 5.2 架构完全相同，全部提升来自后训练，agentic 基准提升超过 2%。嘉宾指出 Z AI 是中国实验室中最“激光专注”后训练的一家（对比 DeepSeek、Kimi 等频繁迭代注意力架构）。其管线并不神秘，以 GRPO 为基础分阶段推进：第一阶段用同步 GRPO 换取训练稳定性；第二阶段针对 agentic 长序列下 RLVR 奖励信号稀释、policy 过期等问题切换算法变体。真正独特的是两点：SAO（单次 rollout 异步优化）回归 PPO 风格，critic 模型与 actor 共同训练；以及开源的 slime 后训练框架，被社区公认为最佳后训练基础设施设计之一。此外大量未公开细节的人工数据标注投入也被认为是关键。

嘉宾 Wenyao 称这对自己和整个行业是“警钟”：没有预算从零预训练的公司，用私有数据做后训练就能在特定领域超越部分闭源模型；他举例 Harvey 基于 Kimi 的后训练 agent、Periodic Labs 的科学后训练。

# 中国芯片，从第一天起

这是最具地缘政治意味的发现。GLM 5 论文明确写道：模型从第一天起就全栈适配七大国产芯片平台（华为昇腾、摩尔线程、海光、寒武纪、昆仑芯、MetaX、燧原），覆盖从底层 kernel 到推理框架。5.3 Flash 曾以 "aux alpha" 之名匿名登陆 OpenRouter，免费 token 量大到外界认为“不可能是中国公司的 GPU”，结果证实完全由中国硬件提供服务。

更进一步的证据是 Kimbo 的“阴谋论”式计算：GLM 5.X 注意力运算的算术强度约为 120，与摩尔线程 GPU 匹配而明显偏离 NVIDIA 硬件的最优点；这与 DeepSeek 当年针对 H800 做软硬件协同设计如出一辙，暗示 Z AI 在为非 NVIDIA 硬件做架构级协同设计。

# 对未来的判断

· 5.3 Flash（DSA + Kimi KDA 混合的架构，开发周期可能仅 2-3 个月）的成功，预示这套混合架构可能放大到旗舰尺寸，成为 GLM 6 或 5.4 的方向；
· 研发周期正被 AI 辅助 kernel 开发等手段急剧压缩；
· 市场将分化为“2-3 万亿参数的旗舰 + 极致高效的专用小模型”两层格局。

# 这期节目的核心论点

GLM 5.3 证明了在架构不变的前提下，激进的后训练 + 面向国产硬件的全栈协同设计，足以把一个开放权重模型推到前沿闭源模型的射程之内，尤其在闭源模型因安全拒绝而失能的网络安全领域；而模型效率的提升不会减少内存需求，反而通过杰文斯悖论持续放大它。

# 视频和文章链接

Ep. 038 - Is GLM 5.3 a Mythos-Class Cyber Model From China? (InferenceX)
youtube.com/watch?v=5OwUwM…
How GLM5.3 Sparse Attention Affects HBM Memory Usage
newsletter.semianalysis.com/p/sparse-savin…

SemiAnalysis@SemiAnalysis_

GLM 5.3’s biggest leap came from post-training alone.

“GLM 5.3 was built entirely by post-training the previous model. For me, that was a wake-up call.”

“Post-training is far more GPU-efficient than pre-training from scratch. Plenty of companies can’t afford to train a model from scratch, but they have proprietary data. They can post-train themselves and beat some of the closed models.”

“There’s still so much juice left to squeeze from post-training. We compared GLM 5.3’s cyber capabilities with 5.2, and it’s a night and day difference. That’s all just post-training.”

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬7🔄2❤️11👀2177📊9

⚡ Powered by xgo.ing

Stripe 首席设计官 @lil_dill 分享：如何用 AI 规模化扩展意图、品质与艺术性？ Youtube 视频：https://t.co/2yDoDR5oX8 # 三个警戒信号 1. ...

meng shao (@shao__meng) — Sun, 18 Oct 2026 13:10:57 GMT

Stripe 首席设计官 @lil_dill 分享：如何用 AI 规模化扩展意图、品质与艺术性 ？

Youtube 视频：youtube.com/watch?v=GLvFTM…

# 三个警戒信号

1. LLM 天然趋向均值。大模型擅长给出“最可能的答案”，即过去流行过什么、什么有效过，但不擅长给出属于你的品牌、你的用户语境的原创解。她展示了一个毫无个性的网站让全场猜不出是卖软件还是卖韩式烤肉，证实 AI 产出的默认就是这种“无性格”的东西。
2. “完成感”的诱惑。AI 让东西极快地显得“完工”了。她用微波炉冷冻卷饼自嘲：90 秒从饥饿到午餐，明知道难吃却因为速度而妥协。同理，敲一句话就得到一个有圆角、有阴影的界面，“看起来精致”不等于“真的解决问题、真的有差异化”。
3. 工作变得可抛弃。产出太容易，责任感和长期思维（谁来维护？）容易被丢在一边。

三者叠加的结果就是“僵尸 UI”：单调、空洞、无人真正在意。而我们一半的清醒时间都盯着屏幕，用户想要的是被认真对待的软件，哪怕小到日历标签页里显示正确日期这样的细节。

# Dill 给出的四条实战建议

一、必须有自己的观点
没有观点，AI 会替你给一个，而那个答案大概率是通用的、向后看的。在建造权分散、人人都给产品做贡献的时代，团队必须先对齐“我们是谁、用户在乎什么”。

她举了 Stripe 内部的一次设计评审。一位同事问：AI 做的东西，质量标准应该是什么？这个问题的答案很简单：用户不在乎东西怎么做的，只在乎它好不好，所以标准只看最终产出。那次评审最终产出了 17 条改进点，比如霜感再调一点、边缘再柔一点、气泡再小一点。"Pepsi bubbling" 从此在 Stripe 成为极致打磨的代动词。目标并非完美，而是比用户能感知到的再深一层，那份匠心用户终会感受到。

观点如何培养？练觉察力。留意用户真正的需要，而非嘴上说的；留意生活中什么是好、什么是平庸；从艺术与科学中汲取参照，逐步建立自己的品味和标准。

二、把标准编码进机器
现实是设计师不会出现在每一次决策现场。界面在没有设计师的房间里被生成，Agent 半夜自动修问题，生成式 UI 实时拼装。所以设计系统的对象已经变了：过去是界面，现在是系统本身。

她用古腾堡作比。古腾堡做了 290 个字符变体，包括不同字宽、连字和缩写，目的是让机器排版达到手工排版的品质，两端对齐时不出现难看的白空。旧设计系统扩展的是一致性，新系统要扩展的是意图。

Stripe 的实践也走过弯路。最初用 MCP 让 AI 读设计文档，效果很差，同一条 prompt 三个人会得到三个结果。后来迭代为构建在设计系统之上的 CLI：它在开发者工作的地方运行，在恰当时机注入文档以避免 context rot；提供的内容从原子组件升级为完整模板和流程，让系统知道产品应该是什么样子、如何组装。

但她同时引用了 Christopher Alexander 的话作为提醒：“一个系统可以满足所有规则，却仍然是死的。”这一条只是及格线。

三、拒绝把“做完”当“做好”
过去的质量过滤内建于流程：20 个想法只能立项 1 个，一路修剪打磨。现在一周能建 20 个想法，好处是可以跳过理论会议直接看真东西，但过滤被推迟到了建造之后，而那正是最难说“不”的时刻。

于是“编辑者”的角色变得空前重要。谁在端到端地审视产品是否为一个完整的整体？团队必须戒掉“建完就等于做完、做完就等于做好”的惯性。

编辑的核心方法是像用户一样亲身体验：它真的解决问题吗？符合用户的思维方式吗？放进完整用户旅程后还连贯吗？很多东西单独看都不错，拼在一起就显得割裂。编辑者要为每一个决定、每一个像素负责。

她引用 Nabil Khureshi 论艺术的文章：伟大的艺术在于意想不到的细节和贯穿始终的深层主题，这恰恰是 AI 的短板。AI 垃圾最冒犯人的地方，就是那种“细节无所谓”的感觉。杯子是绿的，但换成蓝的也无所谓，这种态度用户一眼就能看出来。

案例来自本场大会的开场动画。设计师 Stefan 用 AI 从 3D 场景模型开始迭代，第一版挺酷，但像素级审视总觉得不对劲。他反复做了 56 版，才得到真正有生命力的成品。她的关键洞察是：没有 AI，他可能根本不会尝试这么复杂的场景和这么多视角；AI 扩大了可能性空间，但一次成活是幻觉，把关的仍然是人的眼力。

四、释放创造力与艺术性
这是她个人最喜欢的一条。AI 可以批量制造单调，但它也是史上最强的创意催化剂。当人人都能建造，差异化更难也更重要。

今天的界面范式，聊天框、图表、命令行，绝非交互设计的终点。应该去发明新界面、新美学。最佳实践还没被写出来，而我们现在有了写它的工具，就像多点触控催生了全新的交互，合成器催生了全新的声音。

Stripe 用 AI 放大创意团队。新书《Built to Grow》的封面由人类大理石纹艺术家做出惊艳底稿，再用 AI 精调颜色与线条，本质上是把人类的好判断规模化。

让 AI 成为更强的创意伙伴有三个做法：改进输入，在 prompt 里带上品牌信念、审美标准和素材源，而不只是“给我做个烤肉店网站”；施压输出，别陷入卷饼困境，永远再推一步；用对抗性 Agent 帮忙挑刺。

真正的难点在文化。跟着 cookie-cutter 走安全舒适，找到独特且改进现状的东西难得多。领导者应该给团队留探索空间，保护那些怪东西（protect the strange）。AI 降低了创造的成本，省下的预算应该花在做出真正特别的东西上。如果只用 AI 把已有的事情做得更快，就错过了最有意思的部分。AI 能抬高地板，但天花板要靠人去撑。

Katie Dill@lil_dill

If we only use AI to make the things that we already make, just faster, then we're definitely missing out on the most interesting part.

From my talk at @lennysan’s Summit, here are four ideas for raising the ceiling, not just the floor:

- Have a point of view [5:38]
- Encode your standards into the machine [9:07]
- Don't confuse done with good [12:21]
- Unleash creativity and artistry [16:19]

Full talk here: youtu.be/GLvFTMtw4Jk?si…

🔗 View Quoted Tweet

💬5🔄3❤️10👀1906📊8

⚡ Powered by xgo.ing

斯坦福大学 CS336: Language Modeling from Scratch 第 10 讲「Inference」，在前后两讲 Scaling Laws 和 Scaling Laws II ...

meng shao (@shao__meng) — Sun, 18 Oct 2026 12:59:57 GMT

斯坦福大学 CS336: Language Modeling from Scratch

第 10 讲「Inference」，在前后两讲 Scaling Laws 和 Scaling Laws II 之间，@percyliang 教授用一条完整的数学主线串起从架构、算法到系统的全部优化手段，把 “训练完的模型，如何又快又准地生成响应？” 讲得非常清楚！

Youtube 视频：youtu.be/EfM546A79aM?si…
讲义：cs336.stanford.edu

讲义采用 CS336 特色的“可执行讲义”形式，所有公式都是符号计算（sympy）逐步推导并断言验证的。整讲的逻辑顺序是：自回归 → 无法沿序列并行 → 算术强度低 → memory-bound → 一切优化 = 减少每步搬运的字节数，围绕这个链路展开。

1. 架构层（有损）：GQA/MLA/CLA 降维、局部注意力截断、量化、剪枝蒸馏；全部服务于“把 KV cache 和参数压小，且用评测证明没伤准确率”；

2. 算法层（无损）：投机采样，用“验证快于生成”的不对称性换取精确的免费加速；

3. 系统层：连续批处理、分页、前缀共享、写时复制；操作系统经典思想向 GPU 服务的迁移；

4. 张力贯穿始终：延迟 vs 吞吐（批大小）、速度 vs 准确率（每一项有损技术）、新颖性 vs 可信度（GQA 与 MLA 论文结论的相互打脸）。

Percy 在结尾留下的展望是最本讲有分量的判断：KV cache 本身就是 Transformer 对推理不友好的结构性根源；一个从第一天起就为推理设计的架构（SSM、线性注意力、扩散式非自回归生成）可能是这一领域最大的改进空间。

meng shao@shao__meng

Stanford、CMU 和 MIT 三所顶级大学的 5 门 AI 课程之外，再分享两门更偏理论和基础的课程。

CS336: Language Modeling from Scratch
  Stanford AI 课程链的顶点实现课，由 Percy Liang 与 Tatsu Hashimoto 联合执教，从零亲手构建一个完整的语言模型。
CS221: Artificial Intelligence: Principles and Techniques
  Stanford AI 的本科主干入门课，由 Percy Liang 执教，用统一的数学框架（学习、搜索、MDP、博弈、贝叶斯网络、逻辑）把整个经典 AI 领域走一遍。

这两门课程都来自 Stanford 大学，讲师都有 @percyliang (@stanfordnlp 教授，@togethercompute 联合创始人）。

CS336 课程地址
cs336.stanford.eduyoutube.com/playlist?list=…

CS221 课程地址
stanford-cs221.github.io/autumn2025/youtube.com/playlist?list=…

🔗 View Quoted Tweet

💬5🔄22❤️82👀4064📊29

⚡ Powered by xgo.ing

昨天我老婆问我 App Store 怎么付费，看了一下才知道她要给儿子买一个打字 App，收费 128 块。。这。。小孩和女人钱这么好赚？？我说等我半个小时，打开 Codex，把打字游戏的需求...

meng shao (@shao__meng) — Sun, 18 Oct 2026 10:00:32 GMT

昨天我老婆问我 App Store 怎么付费，看了一下才知道她要给儿子买一个打字 App，收费 128 块。。

这。。小孩和女人钱这么好赚？？

我说等我半个小时，打开 Codex，把打字游戏的需求输入进去，一个 Goal 跑起来，20 分钟就做好部署到 ChatGPT Sites 了。花了几分钟看了一遍，还不错，顺手再加了一个实时拍摄人像，让头像作为游戏主角的功能，30 分钟准时交活儿。

效果怎么样呢？我第一版做了 36 关，儿子一连玩了 18 关 😁😁😁，我边看他玩，边看有什么问题，边让 Codex 改，顺便增加了几十关，和无限模式。。

以后儿子再有什么想玩但花钱的游戏和应用，自己做就行了，大家感兴趣可以看…doudou.groovy-river-7567.chatgpt.siteRnb

💬41🔄9❤️121👀23179📊79

⚡ Powered by xgo.ing

摇一摇跳转、切到后台回来跳广告页、跳过广告按钮打死点不到、广告金刚位... 中国移动互联网，产生了太多这类「创新」了，如果是中国人搞定了火星移民，那 tm 到了火星也得点广告，要么付费才能提前解锁火...

meng shao (@shao__meng) — Sun, 18 Oct 2026 09:17:34 GMT

摇一摇跳转、切到后台回来跳广告页、跳过广告按钮打死点不到、广告金刚位...

中国移动互联网，产生了太多这类「创新」了，如果是中国人搞定了火星移民，那 tm 到了火星也得点广告，要么付费才能提前解锁火星登陆。

💬9🔄1❤️10👀1824📊11

⚡ Powered by xgo.ing

Google Research 最新开源了 Harness²：递归式智能体 Harness 优化框架 Harness² 解决的两个开放世界难题 1. 测试时遇到的是没见过的任务，没有 ground-...

meng shao (@shao__meng) — Sun, 18 Oct 2026 08:07:17 GMT

Google Research 最新开源了 Harness²：递归式智能体 Harness 优化框架

Harness² 解决的两个开放世界难题
1. 测试时遇到的是没见过的任务，没有 ground-truth 验证器。在线改 harness 时你不知道答案对不对，无法用“分数涨了没有”来指导编辑。
2. 递归自我改进（RSI）通常是任务特化的，换个任务就失效，无法泛化积累。

开源地址：github.com/google-researc…

# 核心机制：两层递归

第一层：任务级递归，Propose–Probe–Compose（对比式改进环）
· Propose（提案）：先跑一次当前 harness 的参考执行。注意，这次执行揭示的是“harness 如何表现”，而不是“交付物是否正确”。基于任务、参考轨迹和历史，提出两个候选 harness：一个针对跨领域通用的代理性缺陷（规划、工具使用、上下文管理、委派），一个针对当前领域的知识、流程和约束。每个候选都是可直接执行的文件级编辑。
· Probe（探针）：两个候选在同一任务、同等的模型和环境条件下执行，与参考执行对比得到行为对比；编辑是否缓解了目标缺陷、毫无变化、还是造成回归。论文明确说这些对比只“为后续组合提供信息，而非验证任务正确性”。
· Compose（组合）：读取参考执行、两个候选、它们的 diff 和全部执行证据，有选择地构建后继 harness：合并被证据支持的修改、修订冲突、采纳其一、或保持原样。每个决策必须绑定一个具体观察，而不是假想的分数增益。
这一步是整个工作的关键创新：在没有标准答案的情况下，用“同任务下的 A/B 行为对比”替代分数反馈来指导编辑，绕开了开放世界没有验证器的死结。

第二层：harnessing 级递归，持续改进的 improvement harness
每个任务结束后，框架对完整的改进记录做反思，把被采纳的 harness 和有证据支持的教训写入一个按领域组织的持久库。要点有三：
· 教训只有在执行对比支持时才保留——单次选出了好输出不等于可迁移；
· 库里存的是可执行的组件文件而非散文式摘要，配一份 EXPERIENCE.md 记录适用场景和证据；
· 下一个任务仍从公共基础 harness 出发（执行 harness 不继承），但 Propose/Probe/Compose 由更新后的库引导；即“改进 harness 本身”也在被改进，这就是标题里 Harness² 的双重含义。

两种扩展模式：parallel（同时探测 k 组候选，k 个独立组合会话）和 sequential（k 步链式精炼，逐步携带累积证据），两种模式从 k=1 到 5 均单调提升。

八个可编辑组件 - 按作用分组
· 上下文构建：系统提示词、护栏、记忆，每次调用都生效
· 工具接口：工具指引、Skills，Skills 按需加载不占成本
· 编排：subagents，唯一会增加推理上下文的组件
· 脚本：新确定性能力，执行而非推理
· 插件：TypeScript 中间件，“在工具环内强制一种行为，而非指令它”

主要结果（k=1 单步，编辑器为 Claude Opus 4.8）
WorkBuddy-Bench
· Gemini 3.5 Flash：+5.1 (OpenCode)
· GLM-5：+11.5 (OpenCode，64.2→75.7)
JobBench
· Gemini 3.5 Flash：+4.5 (OpenCode)
· GLM-5：+3.6 (OpenCode)
LAB 部分通过率
· Gemini 3.5 Flash：+4.0 (Codex)
· GLM-5：+11.8 (OpenCode，59.6→71.4)

更值得注意的发现：
· 越弱的执行模型获益越大，且 GLM-5 换上改进后的 harness 反超了 Gemini 的基础分数，“换 harness”在某些场景下顶得上“换模型”；
· 改进后的 harness 跨模型迁移（为 Gemini 精炼的 harness 给 GLM-5 在 Code 子集带来 +17.3），也胜过 Claude Code、Codex 的固定生产 harness 4.6–5.8 分；
· 执行器和编辑器用同一个模型也能涨（GLM-5 自编辑在 LAB 上 +13.7），说明不依赖更强的“老师”模型；
· 库的消融：去掉 library 在 WorkBuddy-Bench 上损失 3.1 分，验证了 harnessing 级递归的价值；库还能跨基准迁移（JobBench 的库迁移到 WorkBuddy-Bench 仍有 +0.6~+2.9）。

Shubham Saboo@Saboo_Shubham_

Recursive Agent Harness from Google Research. 

100% Opensource.

🔗 View Quoted Tweet

💬25🔄36❤️163👀12561📊68

⚡ Powered by xgo.ing

公众号关注终于到 10000 了 9999 停了好几天 😂

meng shao (@shao__meng) — Sun, 18 Oct 2026 04:31:26 GMT

公众号关注终于到 10000 了

9999 停了好几天 😂

💬9🔄1❤️8👀1436📊10

⚡ Powered by xgo.ing

WorkBuddy 宣布: DeepSeek-V4.1-Flash-1017 在 10.31 前限时免费不过，是「国际版」！国内版还没有限免活动。

meng shao (@shao__meng) — Sun, 18 Oct 2026 02:53:41 GMT

WorkBuddy 宣布:
DeepSeek-V4.1-Flash-1017 在 10.31 前限时免费

不过，是「国际版」！

国内版还没有限免活动。

WorkBuddy@WorkBuddy_AI

New DeepSeek just dropped. WorkBuddy Intl is updated to the latest too, and it's free through Oct 31. Take it for a spin.

🔗 View Quoted Tweet

💬8🔄1❤️12👀4159📊9

⚡ Powered by xgo.ing

怎么感觉国内 AI 团队们，有几个很久没发新模型了？本来以为是 AI 模型发布更新太快的时间错觉，查了一下，确实有几家超过 3 个月没发了。字节：Doubao-Seed-2.1-Pro 6月2...

meng shao (@shao__meng) — Sat, 17 Oct 2026 13:17:02 GMT

怎么感觉国内 AI 团队们，有几个很久没发新模型了？

本来以为是 AI 模型发布更新太快的时间错觉，查了一下，确实有几家超过 3 个月没发了。

字节：Doubao-Seed-2.1-Pro 6月23日发布，快 4 个月没发！
MiniMax：MiniMax-M3，6月2日发布，超 4 个月没发！
月之暗面：Kimi-K3 6月13日发布，超 4 个月没发！
百度：ERNIE 5.1 4月29日发布，快半年没发！

💬30🔄1❤️27👀11781📊36

⚡ Powered by xgo.ing

DeepSeek 叕发布了一个「小」版本：DeepSeek V4.1-Flash-1017，在性能、速度、输出长度三个维度同时改进，同时将内部搜索引擎以 Search & Fetch API 的形式正...

meng shao (@shao__meng) — Sat, 17 Oct 2026 12:36:31 GMT

DeepSeek 叕发布了一个「小」版本：DeepSeek V4.1-Flash-1017，在性能、速度、输出长度三个维度同时改进，同时将内部搜索引擎以 Search & Fetch API 的形式正式商业化，并深度绑定自家及 WorkBuddy 等第三方 Agent 编程工具生态。

模型发布：一次“小步快跑”式迭代
V4.1-Flash-1017 是对既有 DeepSeek-V4.1-Flash 的增量更新，采用日期后缀命名，属于快速迭代节奏下的版本推进，而非架构换代。

公告强调的三个改进方向「更强的基准表现、更快的任务完成、更短的输出」，第三点尤其值得注意。模型输出冗长是当前推理模型普遍的成本痛点：同样的任务，输出 token 越少，延迟和费用越低。“性能更高 + 输出更短” 同时成立，才是其所说的“性能与成本的帕累托改进”的真正含义。

训练方法：RL with self-feedback
新模型使用“带自我反馈的强化学习”来提升端到端项目开发能力（从游戏开发到 3D 建模）。这意味着训练目标不再是对话轮次的质量，而是完整任务的最终结果：模型自己生成反馈信号来修正多步骤、长周期的工作流。这与其在 Terminal-Bench 4.0（42.3）、DeepSWE v1.1（77.0）等偏重真实工程环境的基准上的表现定位一致，模型卡的对比对象也集中在 K3、GLM-5.3、GPT-5.6 等同期的 Agent/编程向模型上。

工具生态：抢占 Agent Harness 入口
为 DeepSeek Harness（需升级至 v0.2.1-rc.1 或更高）、腾讯 CodeBuddy、WorkBuddy 等做了适配。DeepSeek API 也直接兼容 Claude Code 和 Codex 的服务端工具调用。

Search & Fetch API：搜索引擎基础设施商业化
商业层面最重要的一条，DeepSeek 把支撑自身产品的内部搜索引擎开放为两个独立 API：
· Search API（/v1/tools/search）：返回结构化网页结果，支持 site:、lang:、after: 等检索算子，可附带页面正文。
· Fetch API（/v1/tools/fetch）：抓取单个网页并转为 Markdown，这是 RAG 和 Agent 工具链的标准需求。

DeepSeek@deepseek_ai

🚀 DeepSeek-V4.1-Flash-1017 is here!

Stronger benchmark performance, faster task completion, and shorter outputs than the previous version—a Pareto improvement in performance and cost. Now live on our website, app, and API.

🛠️ Optimized for @DeepSeekHarness, Tencent CodeBuddy, WorkBuddy, and more. Upgrade to DeepSeek Harness v0.2.1-rc.1 or later for the best experience with the new model.

1/4

🔗 View Quoted Tweet

💬10🔄2❤️13👀2109📊10

⚡ Powered by xgo.ing

手动点赞推荐 @samuel_ys92 👍 买卖简历和职位的生意该结束了 https://t.co/yPeuheEB69

meng shao (@shao__meng) — Sat, 17 Oct 2026 09:32:28 GMT

手动点赞推荐 @samuel_ys92 👍

买卖简历和职位的生意该结束了
jobs.dinq.me9

Sam Gao@samuel_ys92

北京上海杭州深圳的AI岗位在哪?

我花了5天时间, 用AI爬取了融资规模1000万美元以上的AI公司, 上市互联网公司, 量化公司和一些neo labs的AI岗位, 并按照城市地区进行聚类. 

正值秋招季, 欢迎大家体验使用, 完全免费! 

网址: jobs.dinq.me 如果有任何想法和需求欢迎联系我!

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬1🔄1❤️10👀2465📊4

⚡ Powered by xgo.ing

女装电商场景对营销物料的需求，确实是一个非常典型的「SKU多、相似性高、数量大、更换频率高」为什么特指女装，而不是服装。。各位男装用户，自己在电商平台啥地位，心里没数吗 😂，我心里的价值排序：女...

meng shao (@shao__meng) — Sat, 17 Oct 2026 04:07:00 GMT

女装电商场景对营销物料的需求，确实是一个非常典型的「SKU多、相似性高、数量大、更换频率高」

为什么特指女装，而不是服装。。各位男装用户，自己在电商平台啥地位，心里没数吗 😂，我心里的价值排序：女装、童装、宠物装、其他、。。。男装、中年男装。。

说回来，为什么电商场景的物料需求，不是直接接一个生图能力就能解决的？

服装有同款不同颜色、同颜色不同款，作为购买用户，我希望能更直观做切换对比，这时不同颜色衣服出现在同一个模特身上，就不能是每一张都重新生成的，抽卡和幻觉，不可能 100% 解决。

对素材做分层，分出变量和不变量，服装和促销信息等，让每个图层尽量原子化、可复用，再做不同组合。这样不但保障一致性，对生成成本也会有很大帮助。

最近新发布的几个生图模型，都在往高度可控性走，相比已经被玩烂的天马行空、奇思妙想，可控性、可复用性才是生图应用真正能赚到钱的方向。

李韭二@li9292

双十一
女装电商的运营和美工会碰到一个困扰：

AI 画的图，能不能只改一个地方？

比如一款外套出 3 个颜色，大促完撤促销贴。

我拿一张 AI 穿搭图，
用开源的 Ming-Image 拆成 9 层透明图层，像 PS 的图层。
试出三件事：

① 改一层，别处不动

只换西装颜色，别处一个像素没动。

② 擦掉牛皮癣，底下干净

水印、促销贴一删，底下看着干净，促销贴盖住的一小块墨镜镜框也补全了。

③ 一张图，多个版本

换色、去促销贴、左右换位，做了 7 个版本，没让 AI 重画一次。

小窍门，值得收藏：

要写明每层是什么，比如"第 1 层是水印"。
只说拆几层，所有字会挤在一层，删水印会连标题一起删。

局限：还不稳。同一张图拆 3 次，2 次把模特拆成了两层，图注也会放错层，得手动整理。

我的看法：要反复改主图、改活动图的女装电商运营和美工，值得试。

想自己试：下面链接里有免费在线试用页，传一张图，写清每层是什么就行，偶尔会卡。

开源地址：github.com/inclusionAI/Mi…

模型试用地址：openrouter.ai/inclusionai/mi…

你改主图最烦哪一步？评论区告诉我，我挑几个试。

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬10🔄1❤️8👀1778📊10

⚡ Powered by xgo.ing

当 Claude 写了 Claude Code 约 90% 的代码后，团队如何重新设计代码评审？ Anthropic 没有取消代码评审，是把 “人读代码” 这个动作大部分交给了机器，把稀缺的人类注...

meng shao (@shao__meng) — Sat, 17 Oct 2026 01:52:43 GMT

当 Claude 写了 Claude Code 约 90% 的代码后，团队如何重新设计代码评审 ？

Anthropic 没有取消代码评审，是把 “人读代码” 这个动作大部分交给了机器，把稀缺的人类注意力只花在真正需要判断力的地方。核心转变是：从“这段代码有人看过吗”变成“这个变更可能出什么问题，哪种检查（自动或人工）最适合抓住它”。
claude.dev/blog/solving-c…

# 为什么必须改？

背景数字：2026 年 6 月到 9 月，合并的 PR 数量翻倍以上，而 revert 率下降超 40%。传统的“同事互相读 diff”模式在这个吞吐量下会先崩溃；人要么变成瓶颈，要么敷衍放行。

团队对成本的认识很清醒：人力时间 = 评审时间 + 修复坏代码的时间，压缩一头只会把成本转移到另一头。所以他们不追踪“评审覆盖率”这种虚荣指标，而转去追踪 “每个 PR 平均几个人类审批” 和 “等人审批的等待时间”，并以 revert 率 / 事故率作为护栏指标；目标是最多一个人在环（有时只有作者本人），且事故不比以前多。

# 七层防线：一个变更的一生

1. PR 之前的自我验证 — Claude 必须出示证据（测试输出、构建、截图）而不是声称完成；再用一个全新上下文的第二个 agent 审 diff。Boris Cherny（Claude Code 创造者）认为给 Claude 一个验证方法是“最重要的事”，效果提升 2–3 倍。反复出现的问题会被固化到源头：写进 CLAUDE.md（项目约定）和 REVIEW.md（给代码主人看的指引——失败长什么样、nit 上限、哪些路径跳过，且每条发现必须附文件/行号证据）。

2. 每个 PR 必过 AI 评审 — 内部 PR 上“实质性评审意见”占比从 16% 升到 54%；千行以上的大 PR 几乎总能查出问题。多个 agent 并行找 bug，再有 verifier agent 对每条发现投票才发出。发现分为 Important / Nit / Pre-existing，每条必须解决或说明理由。

3. 阻塞性的安全评审 — 独立的自动化通道，有未处理发现就不能合并。

4. 阻塞性的自动检查 — lint、类型、跨平台测试、构建；PR 模板强制填写“如何测试的”和“如何回滚”，且需一人签字。

5. 基于风险的人工审批 — 分类器定级：低风险（文档、文案）不需人工；中风险（普通产品变更，及缓存、自动更新器、系统提示词等敏感区）一人；高风险两人。关键规则：agent 的批准永远不能算人工批准；批准只覆盖一个 commit，有新提交就要重新审批。

6. 合并队列 + 特性开关 + 灰度 — 针对合并后 main 重跑检查；新行为先给 Anthropic 内部员工，再走 latest channel，最后进 stable。

7. 快速检测与回滚 — 开关无需重新部署即可关闭；事故复盘必问“哪一层本该拦住它”。

# 两个最有参考价值的工程细节

1. 评审器本身也是被持续评测的系统。 过去引发事故的 PR（经专家确认）构成一个 eval 集，评审器每天跑分，只有分数提升的改动才被保留；噪声则通过“人对评论的反应”和“在已知干净的 PR 上跑评审器”来度量。这本质上是把“评审质量”从主观感受变成了可优化的目标函数。

2. 收敛问题的解法。 曾有一个 agent 写的 CLI PR 一夜跑了 50+ 轮评审，而 git blame 显示约 59% 被标记的代码在第一轮之前就存在；评审 agent 在翻旧账而不是审新变更。修复手段：三轮封顶（超过就退回来重新考虑方案）、后续轮次只看增量 diff、标记 bug 类别而非单行、禁止重复发现。效果：一轮通过率 65%→78%，5 轮以上 PR 从 8.9% 降到 1.5%，平均评审轮次 2.08→1.32。这是 AI 评审 AI 代码时特有的“死循环”问题，他们的解法值得所有引入 AI reviewer 的团队抄作业。

# 人类还留在哪里？

· 该不该做：方向、品味、范围；
· 高危代码：计费、自动更新器、CI 工作流；
· 可被复制模仿的架构决策；
· 读证据：测试输出、截图、发现列表；
· 为结果负责：每个上线变更背后必须有一个承担问责的人。

ClaudeDevs@ClaudeDevs

Claude writes about 90% of Claude Code's code.

From June to September, merged PRs more than doubled while the share reverted fell by more than 40%.

We wrote about how we changed code review to get there, and how to adopt it:

claude.dev/blog/solving-c…

🔗 View Quoted Tweet

💬21🔄12❤️38👀4230📊29

⚡ Powered by xgo.ing

中国的开源模型，还能给美国人用吗？商务部科技部发布第48号联合公告，拟将人工智能、生物医药、光伏三大领域共40项技术增列进《中国禁止出口限制出口技术目录》，并在目录正式生效前，立即对相关技术出口...

meng shao (@shao__meng) — Sat, 17 Oct 2026 01:30:54 GMT

中国的开源模型，还能给美国人用吗？

商务部 科技部发布第48号联合公告，拟将人工智能、生物医药、光伏三大领域共40项技术增列进《中国禁止出口限制出口技术目录》，并在目录正式生效前，立即对相关技术出口实施临时登记管理。

修订内容（40项）
· 人工智能23项：大模型、智能体、算力集群、信息处理相关技术；
· 生物医药5项：细胞和基因治疗、小核酸药、病原微生物相关技术；
· 光伏12项：多晶硅制造、硅片制造、电池制造相关技术，且管理范围包含承载相关技术的关键和核心设备。

六个关键设计
· 登记先行，堵住抢跑窗口：征求意见期内即实施临时登记，出口需报备接收方、用途、金额，实为信息摸底+预期管理。
· AI开源豁免：已公开的技术不管，只管非公开的模型能力与训练核心；不影响开源生态和学术交流。
· 生物医药“卖技术可以，卖断要管”：License-out 走自动许可便利通道，所有权转让和控制权变更设卡。
· 光伏“技术+设备”成套管制：超出传统技术出口范畴，是2023年搁置的硅片限制草案以更完整形态回归。
· 股权通道=出口：实际控制人变更为境外主体即触发登记，并购、红筹化都被视同技术出口。
· 存量不豁免：在途交易同样登记，无祖父条款。

回到咱们开头的问题，中国的开源模型，中国之外的人还能用吗？

豁免标准是 “已通过开源、发表学术论文等方式进入公共领域”，所以：
· 开源之前对外交付（授权境外使用、卖断、模型权重交付给境外主体）：属于目录内非公开技术，过渡期内须先登记，正式目录生效后按“禁止/限制”栏管理。“我以后会开源”不构成豁免理由。
· 先真正开源、再对外商业化交付：技术一旦进入公共领域即豁免。这实际上形成了一条合规路径：“先发布、后出口”。对企业而言，公告客观上制造了一个激励：在正式目录实施前把打算开源的模型发出去，窗口就是现在到目录生效之日。
· 部分开源的灰色地带：只开源了权重、但训练方法、数据工程、强化学习流程等 know-how 未公开；公开的部分豁免，未公开的部分仍在管理范围内。豁免跟着“实际披露了什么”走，不跟着“开源”这个标签走。

那 Manus、Lovart 类的智能体服务呢？
原则上不受影响，但要看部署结构；关键区分是“提供技术服务”与“技术转让”。四个登记触发情形「所有权转让、授权境外使用、控制权变更为境外主体」共同点是技术本体发生了跨境外流。

但有三种结构会踩线：
· 技术在境外落地运行：把模型或 Agent 技术栈部署到境外服务器、机房，让技术服务于境外运行环境，可能被认定为“境内技术授权境外使用”；
· 向境外主体输出 Agent 技术本身：技术授权、白标合作、整体解决方案交付给境外公司，直接命中；
· 控制权变更：若 Manus、Lovart 这类公司被境外资本收购或实际控制，触发登记。

mofcom.gov.cn/zcfb/blgg/gg/2…

💬7🔄1❤️5👀1976📊9

⚡ Powered by xgo.ing

https://t.co/EfOMLZVin5

meng shao (@shao__meng) — Sat, 17 Oct 2026 01:16:19 GMT

x.com/i/article/2111…

💬3🔄2❤️9👀4114📊7

⚡ Powered by xgo.ing

怎么才能更信任你的 Agent 的工作呢？ Grok Bot 团队 @poteto 提出了一套如何信任 AI Agent 工作成果的四层“倒金字塔”框架。她认为，与其花精力“管教” Agent，不如...

meng shao (@shao__meng) — Sat, 17 Oct 2026 01:04:16 GMT

怎么才能更信任你的 Agent 的工作呢？

Grok Bot 团队 @poteto 提出了一套如何信任 AI Agent 工作成果的四层“倒金字塔”框架。她认为，与其花精力“管教” Agent，不如花精力改造代码库本身！

# 四层倒金字塔 (精力投入从上到下递减)

第一层：代码库改进 (投入最多) 更好的架构、更强的类型系统与不变量、清晰的模块边界。

Lauren 认为这本质上“就是好的软件工程”。理由在于 Agent 的天性：Agent 倾向于复制已有代码、走最短路径；所以与其对抗这个天性，不如让最短路径本身就是正确路径。

第二层：静态分析 Lint 规则、测试、CI、形式化验证(如 TLA+)。这是性价比很高的第二道防线，用极低的 token 成本在问题早期就拦截它，出错反馈是确定性的，不依赖 Agent “理解”了什么。

第三层：文字性指导 (最少使用) 代码注释、规则文件 (如 AGENTS.md)、Skills 描述等。这一层的共同弱点是无法强制执行，它要求 Agent 自行判断是否遵守，而 Agent 的判断并不总是可靠，所以只能作为补充，用在确实需要主观判断的场合。

第四层：人工审查 (最难规模化) 人的精力有限，不应消耗在逐行检查 Agent 产出上，而应投向更上游的事：设计出让 Agent 默认就做对的环境。

为什么金字塔是“倒置”的？
传统上团队把大量精力放在金字塔底部 (写规范、人工审查)，而 Lauren 主张反转：
· 越往上层，手段越是确定性的 (代码结构直接决定 Agent 能走什么捷径) 且token 高效的(不需要反复沟通纠偏)；
· 越往下层，越依赖不可靠的理解与不可扩展的人力。

这和业界近年 “从 prompt engineering 转向 context/engineering 工程” 的共识是同一方向；但 Lauren 把它推到了更根本的层面：连提示词本身都只是第三等手段，真正的杠杆在代码库里。

lauren@poteto

how do you trust your agents' work more? copy this post/link and give it to your @bot or agent!

codebase improvements: this is just good software engineering - better architecture, stronger types and invariants, clear boundaries. agents love to copy what exists and take the shortest path, so make the easy thing the right thing. categorically eliminate problems through code and you won't need to think about it again.
static analysis: lint rules, tests, CI, verification (eg TLA+). very token efficient ways to catch issues ahead of time.
prose: comments, rules, AGENTS.md, skills - anything that can't be enforced and requires agent judgment. use it minimally, but do use /create-verification-skill.
human review: the hardest to scale. at the rate agents land code, it's pretty much impossible to thoroughly review every PR, so spend that effort on the highest leverage point, designing an environment where agents do the right thing by default.

this forms an inverse pyramid: you want most of your effort at the top, least at the bottom. codebase improvements are deterministic, making it more token efficient, and lets you sleep more soundly at night.

install github.com/cursor/plugins… and create a new Project:
look through my slack/chat messages and code review comments where i've given feedback on PRs, code, architecture
use /recall on my past transcripts to learn how i steer agents
/poteto-mode use /correct and /architect on past commits to find the most common pitfalls agents fall into, then propose a plan to rearchitect the code i own so it's more agent friendly. answer open questions with prototyping rather than defer to me, and back the plan with real data. 
before you begin, use /sharpen + /in-your-own-words and confirm this prompt with me

🔗 View Quoted Tweet

💬22🔄27❤️126👀11256📊61

⚡ Powered by xgo.ing

Perplexity 开源了团队内部 agent 代码执行平台「SPACE」，把不可信的 Agent 生成代码或用户代码放进 Firecracker microVM 里隔离运行，通过纯 HTTP/SS...

meng shao (@shao__meng) — Fri, 16 Oct 2026 13:31:08 GMT

Perplexity 开源了团队内部 agent 代码执行平台「SPACE」，把不可信的 Agent 生成代码或用户代码放进 Firecracker microVM 里隔离运行，通过纯 HTTP/SSE API 对外服务

开源地址：github.com/perplexityai/S…

核心抽象：五个概念 + 严格分离的生命周期
· Template：起始文件系统与运行时配置（不可变，类似镜像），按内容寻址（sha256: digest）
· Sandbox：一个 Template 的实例，独立 microVM + 可写文件系统
· Process：在 Sandbox 内执行的程序，同 Sandbox 内进程共享环境
· Command session：一次命令的连接信息与授权，创建即分配进程 ID，attach 才真正启动
· Operation：异步生命周期请求（create/pause/suspend/wake/delete）的追踪记录

关键设计：Sandbox 的生命周期长于创建它的请求，也长于承载其输出的连接。管理面是异步的，API 只把期望状态写入 PostgreSQL，由控制器和 worker 协调收敛，客户端拿 operation ID 轮询；数据面则完全独立，通过会话级 attachment token 经 SSE 直连沙箱内进程取输出。管理 token 与 attachment token 不可互换，这是它的安全边界之一。

架构：控制面/数据面分离 + 声明式调和
请求与执行分两条路径：
· 管理面：Application → API → PostgreSQL（期望状态）→ 集群控制器 → 沙箱 Pod（K8s 模式下）→ 运行时 shim → Worker 服务 → Firecracker microVM → 客户进程。
· 数据面：Application ↔ Data plane ↔ 客户进程，旁路整个控制面，输出流不经过数据库。

Worker 负责 VM、网络、卷、模板、凭证，用 btrfs 写时复制构建根文件系统（这是快速克隆沙箱的关键）；模板与快照走对象存储（本地用 Versity S3 Gateway）。部署形态可插拔：Kubernetes 适配器（本地 Kind、云端 EKS 参考部署）或直接适配器（不经 K8s 直调 worker，支持单机运行）。

Pause 与 Suspend 的区分体现其状态机的严谨性：Pause 保留常驻内存（快恢复但非持久）；Suspend 生成 VM 内存 + 运行时状态 + 根文件系统的完整快照并释放资源（真正的持久化），两者都用 Wake 恢复。默认 6 小时无活动自动 Suspend（这是空闲限制而非最长存活时间）。

性能工程：两层抗冷启动
冷启动是 microVM 沙箱平台的体验瓶颈，SPACE 给了两个正交方案：
1. Warm pools（K8s 部署）：按“模板版本 × VM 规格”预启动一批就绪沙箱，create 直接领用，池空了才退化为冷启动；
2. Base snapshots（单机部署）：从基线快照恢复，跳过完整引导。

配合 Firecracker 本身亚秒级的 VM 启动和 btrfs CoW 文件系统克隆，整体面向“Agent 秒级拿到可用环境”的目标。

“可插拔运行时”：为未来预留的执行环境身份体系
这是仓库描述里 "pluggable-runtime" 的实质，也是设计上最有前瞻性的部分。每个执行环境被定义为主机平台 × 运行时绑定 × 客户平台 × 引导配置 × 隔离语义 × 兼容性Profile 的完整组合，整体 SHA-256 内容寻址。当前只实现了编译进代码的 E0 定义：Linux/x86_64 宿主、KVM、Firecracker 1.15.1（含 jailer）、内核 6.1.155、快照格式 9.0.0。

值得注意的三个原则：
· 结构可解码 ≠ 可执行：解码成功、工件存在、节点健康，都不构成执行授权，三者分离校验；
· 身份不可扩展含糊：任何改变引导/恢复语义的字段都必须产生新的 schema/引用，“加了字段还沿用旧引用”被明令禁止；
· 主机平台类型里已预留 Linux/Windows/macOS 的区分身份，虽然当前只实现了 Linux 适配器。

这明显是在为未来支持其他 hypervisor、客户架构甚至非 Firecracker 运行时铺路，而不是把 Firecracker 硬编码进协议。

安全模型（分层清晰）
· 硬件级隔离：Firecracker microVM 边界（KVM），这是对不可信代码的根本防线；
· token 分域：管理面 bearer token 与数据面 attachment token 隔离；
· 网络策略：沙箱 Pod 独立 namespace（sandboxes），NetworkPolicy 只放行 API 与控制器端口，出站默认限公网 IPv4 + 集群 DNS，可配 egress profile 精细管控，甚至有 TLS 拦截豁免机制；
· 供应链：gitleaks、cargo-deny、supply-chain 目录、pre-commit/lefthook 一应俱全；
· 内部 RPC 走 TLS，模板注册可限制可信 S3 bucket 白名单。

兼容性与工程成熟度
· E2B 兼容层（ECW）：在边缘翻译 E2B API 请求/响应，用 E2B Python SDK 的应用可近乎无缝迁移（语义映射：E2B 的 pause → SPACE suspend）；
· 客户端零绑定：纯 HTTP + SSE，OpenAPI 规范直接服务在 /openapi-m1.json，不需要嵌入 Rust 库——这对采用率至关重要；
· 运维面齐全：space-admin-cli（节点、暖池、模板构建）、Web UI、OpenTelemetry 可观测性、mdBook 文档；
· 开发体验：tilt up 热重建，单测 + Kind 冒烟套件。

Denis Yarats@denisyarats

we open-sourced SPACE, the sandbox platform we use internally for secure agentic runtimes. it powers Computer as well as our RL training and evaluation workloads.

github.com/perplexityai/S…

🔗 View Quoted Tweet

💬12🔄2❤️18👀2130📊15

⚡ Powered by xgo.ing

那好像是最后一届微软技术大会，也是我最后一次参加技术会议，曾经一起做 Windows Phone 和 Windows 开发的朋友们也陆续都转行了，那个时代，终究还是过去了，甚至没等到被 AI 冲击 ...

meng shao (@shao__meng) — Fri, 16 Oct 2026 13:22:14 GMT

那好像是最后一届微软技术大会，也是我最后一次参加技术会议，曾经一起做 Windows Phone 和 Windows 开发的朋友们也陆续都转行了，那个时代，终究还是过去了，甚至没等到被 AI 冲击 😂

💬2🔄1❤️3👀1137📊3

⚡ Powered by xgo.ing

腾讯混元团队开源了「Hy Memory 2.0」，包括一个专用的记忆写入模型 Hy-Memory-30B-A3B、一个可编程的记忆框架 hy-memory SDK、一个面向终端用户的桌面工具 MemH...

meng shao (@shao__meng) — Fri, 16 Oct 2026 13:12:25 GMT

腾讯混元团队开源了「Hy Memory 2.0」，包括一个专用的记忆写入模型 Hy-Memory-30B-A3B、一个可编程的记忆框架 hy-memory SDK、一个面向终端用户的桌面工具 MemHub，组成了一套完整的 “记忆基础设施”

相较于在通用大模型（如 Claude Opus）外面套一个记忆框架（如 Mem0、MemOS）的主流做法，Hy Memory 2.0 的做法是：用一个小的专用模型替代通用大模型做记忆写入，既便宜又能跨框架工作。

# Hy Memory 2.0 的三个组成部分

模型：Hy-Memory-30B-A3B。30B 总参数、仅约 3B 激活的 MoE 架构（意味着推理成本接近一个 3B 模型）。训练分两步：先用 “On-Policy Distillation” 让学生模型在自己生成的记忆状态上学习各框架的写入协议，而不是简单模仿教师输出；再用“归因记忆强化学习”直接优化下游效果，用逐块探针定位贡献、跨上下文窗口携带自己写入的记忆库，保证训练与真实部署场景一致。

框架：hy-memory SDK。这是工程上最有含金量的部分。它按三类场景设计了不同的记忆形态：
· Chat 记忆采用 L1–L7 层级结构（原始对话 → 原子事实 → 会话摘要 → 心理模型 → 前瞻意图），分 lite / pro / ultra 三档，最低档零 LLM 调用、纯向量检索；
· Working 记忆区分“会话事实”和“可复用经验”两层，经验写入需通过价值阈值，避免记忆库膨胀；
· Coding 记忆只记录代码坐标（文件/函数/分支）而不粘贴代码本体，并以“装饰器”方式在事实下挂载每次修订的真实 diff，形成版本演化链，这个设计对代码场景的噪音控制很有效。

存储后端可插拔（ChromaDB/Qdrant/FAISS + Kuzu/Neo4j + SQLite），任何 OpenAI 兼容端点即可跑起来，pip install hy-memory 即用。

MemHub：本地优先的 CLI + Mac 桌面应用，把 Claude Code、Cursor、Codex、Qwen Code 等工具的会话历史统一到一个记忆运行时，实现“在 Cursor 里学到的偏好，Claude Code 也能用”。这是面向个人用户最直观的入口。

基准成绩实际怎么样？
在四个 harness（Mem0、Hy-Mem、MemOS、以及未参与训练的 EverMemOS）宏平均六个指标上，该模型以 55.49 排第一，Claude Opus 5 为 54.62；领先不到 1 分，且数据来自官方技术报告（基于固定的 20% 基准子样本），属自报成绩，尚待独立复现；

真正有说服力的是两点：一是在从未见过的 held-out 框架 EverMemOS 上仍领先（56.89 vs 54.04），证明其泛化能力而非过拟合特定协议；二是相比同架构基座 Qwen3-30B-A3B（44.37）提升约 11 分，说明训练方法本身有效；

用约 3B 激活参数的模型逼近甚至超过旗舰通用模型，性价比才是核心卖点；记忆写入是高频调用，成本差异会被放大。

SDK & MemHub: github.com/Tencent-Hunyua… 
Model: huggingface.co/tencent/Hy-Mem…

Tencent Hy@TencentHunyuan

🚀 Hy Memory 2.0 is out — open-source model, framework, and MemHub. 
Your private memory steward.
Framework handles chat, work & code memories. 
#1 open-source on 4 benchmarks. 
Hy-Memory-30B-A3B beats Opus 5 across major frameworks.
MemHub (CLI + Mac) syncs across 10+ AI tools.

💻➡️

🔗 SDK & MemHugithub.com/Tencent-Hunyua…nj8
🔗 Modhuggingface.co/tencent/Hy-Mem…q#HyMemorym#AgentMemorymory

🔗 View Quoted Tweet

💬24🔄11❤️67👀6221📊40

⚡ Powered by xgo.ing

pstack 作者公开她的 “工程原则” 设计思路「Clean Code」作者 Uncle Bob 是传统软件工程方法论的宗师，他最近看到了 pstack，认为本质上是把经典工程智慧「最小改动、先...

meng shao (@shao__meng) — Fri, 16 Oct 2026 06:11:32 GMT

pstack 作者公开她的 “工程原则” 设计思路

「Clean Code」作者 Uncle Bob 是传统软件工程方法论的宗师，他最近看到了 pstack，认为本质上是把经典工程智慧「最小改动、先删后加、验证根因、用类型系统让非法状态不可表示、幂等操作」重新编码给 AI Agent 使用。

pstack 作者 @poteto 回应并公开了这个 Cursor 官方内置插件的工程原则的设计思路，核心是：随着模型能力提升，写给智能体的指令正在从“冗长的操作步骤”压缩为“简短的命名原则”。

# 几个关键信息点

1. 原则即极简 skill。pstack 的每条工程原则只有约 10–20 行，是一段被提炼、命名过的好实践，而不是一个流程脚本。她预期随着模型变强，pstack 里大部分 skill 最终都会被压缩成这样的短原则或工作流，从而可以删掉一批。

2. /poteto-mode 的运行机制。智能体在开始多步任务前先读一份简短的原则索引；执行过程中，必须“点名每一条影响了决策的原则，以及它具体改变了哪个选择”，并在回复末尾生成一个 "Principles Named or Used" 段落。这个设计很巧妙：如果原则被引用却没有对应的实际决策，就说明智能体只是在“报菜名”而没有真正应用；强制原则与决策挂钩，让推理过程可检验。

3. 原则来自真实纠错。这些原则大多来自她今年在会话中亲自纠正智能体的场景，属于“教训的结构化沉淀”。

4. 原则可被唤起。每条原则都能以 /principle-<名称> 的形式作为 skill 调用；更常用法是用名字来“掌舵”；因为名字背后指向智能体已经读过的完整规则，一个短语比一段指令更能精准地重定向工作。比如对着一堆旧适配器说 "subtract before you add"，智能体就知道先删过时的、再设计剩下的。

lauren@poteto

perhaps one of the most durable parts of pstack are its engineering principles: very concise skills (~10-20 loc) that distill down good practices into its core. 

as models get smarter, i expect most of pstack skills to compress into short principles or workflows (a generic list of steps) and that i will be able to delete a few of them. 

how it works is that /poteto-mode contains a short index of available principles and tells agents "In your reply, name each principle that shaped a decision and the specific choice it changed." this is why you'll often see a Principles Named or Used section at the end of the agent's response

many of these principles were extracted from my sessions correcting agents since the start of this year. some are inspired by problems i see people talk about, like Attack the Premise, inspired by @VictorTaelin's post x.com/VictorTaelin/s…

you can also use the principles as skills if you want greater control, by invoking /principle-<name> 

github.com/cursor/plugins…

🔗 View Quoted Tweet

💬27🔄30❤️183👀11875📊83

⚡ Powered by xgo.ing

会飞的汽车？太未来了！ Roadster 真的把 Tesla 和 SpaceX 联动了，搭载 SpaceX 的冷气推进系统。那么。。刹车似乎确实没那么必要了，遥遥领先，还是遥遥领先！

meng shao (@shao__meng) — Fri, 16 Oct 2026 04:32:52 GMT

会飞的汽车？太未来了！

Roadster 真的把 Tesla 和 SpaceX 联动了，搭载 SpaceX 的冷气推进系统。

那么。。刹车似乎确实没那么必要了，遥遥领先，还是遥遥领先！

Your browser does not support the video tag.

🔗 View on Twitter

💬2🔄0❤️2👀1089📊3

⚡ Powered by xgo.ing

https://t.co/3tyMv0rf0f

meng shao (@shao__meng) — Fri, 16 Oct 2026 03:06:05 GMT

x.com/i/article/2110…

💬1🔄3❤️2👀1200📊3

⚡ Powered by xgo.ing

Anthropic 宣布新一代反蒸馏防御措施攻击者从 Claude 平台上窃取的推理 token 量下降了 90%–99%，智谱 GLM-5.3 模型训练再次被重点点名、月之暗面 Kimi 用户请...

meng shao (@shao__meng) — Fri, 16 Oct 2026 02:39:56 GMT

Anthropic 宣布新一代反蒸馏防御措施

攻击者从 Claude 平台上窃取的推理 token 量下降了 90%–99%，智谱 GLM-5.3 模型训练再次被重点点名、月之暗面 Kimi 用户请求转发蒸馏再次做实了军方信息画面来源。

Anthropic 再次明确把蒸馏定调为国家安全问题：
1. 被蒸馏出的模型接近前沿能力，但没有配备相称的安全防护（尤其是生物与网络安全领域），等于把危险能力“裸奔”式释放；
2. 窃取的能力被整合进外国军事、情报与监控系统。

攻击面的关键发现：推理链才是主要目标！
· 被动蒸馏：用正常请求的回复做训练数据；
· 主动提取：诱导 Claude 泄露其隐藏的完整思维链（chain-of-thought）。例如直接指令“逐字输出你之前的推理”，更有实验室测试了 1 万多种不同的诱导话术。

思维链的价值有硬数据支撑：在完整 Opus 4.8 推理记录上训练的模型，SWE-bench Verified 得分 80.4%；而只用摘要版推理记录训练，得分降至 71.8%。近 9 个百分点的差距证明原始推理轨迹含有大量可被“白嫖”的能力增量；这正是攻击者绕过摘要机制、直接窃取原始推理的原因。

# 防御体系：三层设计

第一层：推理摘要（reasoning summarization） Claude 在展示思考过程前先做摘要，原始推理链不直接暴露。这是早期防御，但攻击者不断找到绕过方法（如把推理翻译成另一种语言、写进特殊标签），证明单靠它不够。

第二层：保留思考（preserved thinking）本次的关键创新 随 Claude Fable 5.1 和 Opus 5.5 推出。核心机制：
· 2026 年 8 月 31 日后创建的新 API 账号无法编辑 Claude 的先前上下文；
· 模型的推理内容不能被防护更弱的早期模型读取；
· 对 Sonnet 5.5，推理记录仅对产生该记录的组织本身可见。

这直接打击了代理网络的惯用伎俩：在不同对话、不同模型、不同账号之间搬运内容，让 Claude“误以为”自己已经持有未摘要的推理，从而骗它复述出来。切断上下文编辑和跨模型读取，等于拆掉了这套骗术的基础设施。

第三层：两阶段宪法式分类器 + 账号级执法
· 分类器在蒸馏者的流量记录上训练，经内部和外部红队测试，能识别九月报告中记录的全部攻击技术，误报率低于 0.1%。目前已应用于 Sonnet 5.5、Opus 5/5.5、Fable 5/5.1，未来将覆盖所有对蒸馏者有吸引力的模型。
· 账号层面：收紧限额、大规模封号（往往在检测后两小时内完成，累计数万个）。值得注意的是，自 9 月 24 日起，Anthropic 对被安全拦截的请求恢复收费；这是刻意提高攻击成本的经济手段，只在误报率低于 0.1% 的领域执行。

# 两个再次点名的具名案例（智谱和月之暗面）

智谱（Zhipu / GLM-5.3）：Anthropic 直接点名智谱在 GLM-5.3 开发过程中蒸馏了美国领先模型的网络攻击能力。一个耐人寻味的细节：智谱曾尝试蒸馏 Claude Fable 5，但发现网络 安全防护削弱了其攻击效果后，转向一个更老的 Claude 版本和另一家实验室的模型；这从侧面验证了防护确实有效，也暴露了“攻击者会流向防护最弱的模型”这一结构性问题。CAISSI（美国超级智能创新与标准促进中心）评估 GLM-5.3 为迄今网络能力最强的开放权重模型，而 Anthropic 自己的测试发现其防护“很容易被绕过”，且愿意端到端开发安全漏洞利用。

月之暗面（Moonshot / Kimi）：Kimi 的用户请求被秘密转发给 Claude 作为蒸馏数据源。其中一个请求来自 Anthropic 认为与军方有关联的用户，目的是分析针对特定个人的电视台监控画面。

Anthropic@AnthropicAI

Over the last few months, we’ve made significant progress in reducing the effectiveness of distillation attacks against Claude.

In this post, we explain how: anthropic.com/research/disti…

🔗 View Quoted Tweet

💬3🔄5❤️19👀2780📊7

⚡ Powered by xgo.ing

密歇根大学最新 AI 编程课「Applied Agentic Software Engineering」第 14 讲「Subagents」讲义刚刚公开，围绕：为什么需要 subagents、机制是...

meng shao (@shao__meng) — Fri, 16 Oct 2026 02:34:12 GMT

密歇根大学最新 AI 编程课「Applied Agentic Software Engineering」

第 14 讲「Subagents」讲义刚刚公开，围绕：为什么需要 subagents、机制是什么、关键取舍、以及它和相邻概念的区别 四个部分展开。

讲义：github.com/eecs498-aase/m…

Part 1：为什么需要 subagents？
因为长对话必然劣化，四个原因：
· 上下文有限，内容只进不出
· 被否决的想法仍在场（history bleed），模型会捡回来；这就是“变差”的来源
· 每次请求重发全部历史，caching 省钱不省窗口
· 单对话串行，读代码时无法并行比较方案

解法：主对话只留请求和计划，各部分的阅读留在各自的 subagent 里；只回流结果，垃圾全部丢弃。

Part 2：subagents 机制
· Agent 工具对模型就是普通工具；prompt（即 brief）是 subagent 信息的唯一来源
· harness 立即回 "launched"（默认后台），开出第二对话：更短的系统提示词、更少的工具（Explore 无 Edit/Write/Agent，物理上只读）、同样的 CLAUDE.md、没有主对话历史
· 结束必须调 SubagentHandback，否则内容不送达
· 报告回流时的防护：标记为模型输出而非用户（无用户权限）、整体缩进（伪造帧线可辨）；用纯格式守住对话边界
· brief 是模型写给模型的提示词：位置、验收标准、报告形状都要写清；模糊的 brief 得到模糊的搜索

Part 3：Fresh 还是 Forked（最大取舍）
harness 自己列出的风险：
· 细节双向丢失：它只知 brief，你只见报告
· 错误与正确发现同样自信
· 最危险：拿到你的假设，倾向于证实着送回来；要第二意见，给它代码，不给结论

Fresh：起点「仅 brief」、适合「第二意见、独立审查」、成本「更贵」
Forked：起点「全部历史 + brief」、适合「需要全部积累的侧任务」、成本「更便宜（复用 prompt cache）」

Fresh 不是便宜选项，是独立选项。 L10 的 Goldfish 必须是 fresh：fork 出来的会用记忆填补文档缺口，然后说文档没问题。

Part 4：辨析与工程
三个问题区分一切形态：几个对话、谁和谁说话、谁决定下一步。
· Subagents：每段新对话，只与父对话通信，父对话掌权
· Team：多对话 + 互发消息 + 共享任务列表（带文件锁），你可直连任意队友
· Handoff：一段对话，换个 agent 接管（换指令换工具、保历史），不回头；与 subagent 恰好相反
· Swarm = 机制 × 规模（Kimi K2.5：100 并发；OpenAI Navier–Stokes：约 10,000 agents、1,300 亿 token）
· 并行编辑靠 worktree 隔离：每个 subagent 独立 checkout + 分支，改完留分支等合并

meng shao@shao__meng

x.com/i/article/2108…

🔗 View Quoted Tweet

💬13🔄29❤️103👀4827📊45

⚡ Powered by xgo.ing

ComfyUI 要整大活儿了 ... @ComfyUI 发起 $25K 开源重建竞赛，要重建 Higgsfield 的 Genjutsu、Cinema Studio 等产品，还得到了 NVIDIA ...

meng shao (@shao__meng) — Fri, 16 Oct 2026 01:48:23 GMT

ComfyUI 要整大活儿了 ...

@ComfyUI 发起 $25K 开源重建竞赛，要重建 Higgsfield 的 Genjutsu、Cinema Studio 等产品，还得到了 NVIDIA AI、Runpod、LTX、Black Forest Labs、MiniMax 联合赞助。

可以，还是你们创意圈会玩，Higgsfield 本身就是把营销 + 创意玩出花来的典型，这回 ComfyUI 开源重建 Higgsfield，到底是真开源复刻，还是联合 Higgsfield 做的营销流量，不好说。

# 不管怎样，奖金是实实在在的，看看奖项

主赛道：
总冠军：$10000 现金（所有参赛作品自动入围）
最具创新：RTX 5090（需 demo 视频说明创新点）
最具传播性：RTX 5090（好用且适合分享）
纯开放权重：RTX 5090（不使用任何合作方节点或 API，仅限开源权重模型）
10 名入围奖：各 $250 Comfy Credits

合作方特别奖：
LTX VFX 工作流：$2000 现金（LTX 须为核心视频模型）
FLUX：$1000 / $500 / $250 API credits（FLUX3 须为核心模型）
MiniMax H3：$1000 API credits
线下协作将于 10/28 旧金山、10/29 洛杉矶举行。

ComfyUI@ComfyUI

Higgsfield promised to open-source their entire platform. They didn’t.

Let's help them.

For the next two weeks, Comfy and our partners are putting up $25,000 in prizes for the best open-source builds on the Comfy Developer Platform.

Partners: @NVIDIAAI, @runpod, @MiniMax_AI, @ltx_io,  @bfl_ai

→ $10K grand prize
→ RTX 5090: Most Innovative
→ RTX 5090: Most Viral
→ RTX 5090: Open Weights Only
→ 10 runners-up: $250 in Comfy credits

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬9🔄2❤️7👀1486📊9

⚡ Powered by xgo.ing

帮每一位我能看到找工作的朋友转发。

meng shao (@shao__meng) — Thu, 15 Oct 2026 23:03:41 GMT

帮每一位我能看到找工作的朋友转发。

siding@siding_chen

大家好，我叫思定，我在找美国的 software engineer 的工作机会。

我之前在 Alipay/Airbnb/Bytedance ，离职前是团队里某一个方向的 tech lead，带 5 个 eng/intern ，负责过超百万 QPS 的服务。同时做中等规模的技术规划，提供技术指导和带新人。绩效考评连续拿 EE 。

离职后从零到一做了 babra.ai，应该是留学咨询行业最好的垂类 AI 产品。4 月上线后，大概 $1000 月营收，15% 转化率。

欢迎所有工作机会🙏🙏🙏 祝各位幸福安康。

🔗 View Quoted Tweet

💬1🔄2❤️3👀3653📊2

⚡ Powered by xgo.ing

Google 官方「5天 AI Agents 课程」第 5 份白皮书「Spec-Driven Production Grade Development in the Age of Vibe Cod...

meng shao (@shao__meng) — Thu, 15 Oct 2026 12:55:50 GMT

Google 官方「5天 AI Agents 课程」

第 5 份白皮书「Spec-Driven Production Grade Development in the Age of Vibe Coding」，其中一章「Team Culture & Process Evolution」，咱们重点看看，它讲述了 SDD 和规格编写规则之上，团队文化与流程演进会遇到的问题，以及要怎么顺应 AI 发展去解决。
drive.google.com/file/d/1lCx0Lh…

Google 认为，把现代 Agent 塞进旧研发流程 = 给马车装喷气发动机。工具提速后，协作摩擦被等比放大成瓶颈！

三种新问题
1. 合并冲突倍增：产出越快，同文件提交冲突越多
2. 评审死锁：巨型 PR 拆成套娃式依赖链，卡在跨时区评审者手里
2. 上下文碎片化（AI 特有）：Agent 拿着过期快照，写出调用“已不存在函数”的代码，编译前毫无异常

五项应对策略（共同方向：人的注意力从“行”上移到“架构”）
1. PR 附 AI 生成的变更摘要 + 风险评估：评审者先看架构影响，再决定是否下潜
2. 重构评审所有权：代码是一次性易耗品，风格 nitpick 交给 linter；人只审架构蓝图
3. Conditional LGTM：批准以测试全绿为条件，绿灯自动合并，消灭跨时区等待
4. 无责文化：事故归因于破损的流程，而非产出最多的个人（否则惩罚机制会精确打击你最能干的人）
5. Agent 评审 Agent：用 skill 自动做代码评审，GitHub Actions 全自动触发

更根本的追问：还需要团队吗？
一个人带一队 Agent，团队的必要性被动摇。Google 认为：若保留团队，就按“人几乎不碰同一批文件”来设计；API 与 UX 清晰分权，必须重叠时由指定的“部分所有者”做最终同步。代码冲突管理从技术问题升格为组织设计问题。

持续评审 Agent 三个档位
Tier 1 托管型：SaaS 评审器，分钟级启用，但标准是厂商的，会漏掉你的特定风险（如 HIPAA、PII 合规模式）
Tier 2 混合型：GitHub Action 跑你自写的 review skill，多数团队的最佳起点，运行时归 CI，评审标准归自己
Tier 3 定制型：ADK agent 部署到 Agent Runtime，挂 webhook 监听仓库。适合需要跨 PR 记忆（贯穿多次提交的大重构）或任务分解的场合，代价是自担评估、可观测性和值班

选型三问：评审标准多特定？要不要跨 PR 记忆？出错最坏后果是什么（合入回归或泄密 → 必须 Tier 3 并前置 Policy Server）。

案例：金融科技团队用 Tier 1 时，通用评审者标记审计员已放行的样板代码，却漏掉日志中未脱敏的 PII；换成一个 40 行的 Tier 2 skill，一周内误报锐减。多数团队的档位，是在被通用评审者漏掉关键问题的那一刻才确定的。

Tier 3 完全体：图原生代码理解，在亿行级遗留代码上，把代码、文档、工单、设计 PDF 摄入知识图谱，组合图遍历（结构查询）、向量检索（语义查询）、全文搜索（标识符匹配）三种检索，回答“改这里会破坏什么”；再配 Search → Story → Impact → Task-breakdown → Coding 的子 agent 流水线做任务分解。必须用图谱的原因：标准 RAG 会压平代码的结构关系（类属于文件、调用追溯到十年前的需求文档），“压平进向量库，地图就没了”。西门子生产试点把等价重构从两周压到几小时。定义：Tier 3 不是盯着 PR 的 agent，是理解 PR 所在系统的 agent。

meng shao@shao__meng

x.com/i/article/2109…

🔗 View Quoted Tweet

💬16🔄9❤️59👀3574📊28

⚡ Powered by xgo.ing

针对 Langchain 团队发布的 Agent Evals 最常见问题解答，做一个 Cheatsheet 方便随时查看。

meng shao (@shao__meng) — Thu, 15 Oct 2026 11:40:57 GMT

针对 Langchain 团队发布的 Agent Evals 最常见问题解答，做一个 Cheatsheet 方便随时查看。

meng shao@shao__meng

Agent Evals 最常见的问题都有什么？

@LangChain 团队 @divyasan0 以 Q&A 形式分享了 Agent Evals 实践指南，把常见问题一次性回答了。她给出的可落地工程流程：从真实 trace 起步、小数据集建立基线、失败案例回流迭代、离线/在线分层评估、代码优先于 LLM 裁判、benchmark 用容器化环境验证最终状态。

QA 博客地址：
langchain.com/blog/common-qu…

为什么 Agent 难以测试 ？
· 输出不确定性：同一输入，多次运行结果不同；
· 答案非唯一：多个不同回答都可能是正确的，无法做字符串精确匹配；
· 路径自选：Agent 自己决定执行步骤，即使最终答案正确，路径也可能是“错的”（调用了不必要的工具、未经授权就行动）。

起点：从 trace 开始的最小闭环
一条清晰路径值得直接采纳：
读一批真实 trace → 选定一个行为 → 建 10–20 条小数据集 → 跑基线实验 → 之后所有改动都与基线对比。

其中最有价值的工程习惯是失败回流机制：发现一次失败 → 作为新样本加入数据集 → 改进 agent → 重跑全量。这让数据集随系统演化而增长，评估从“一次性验证”变成“持续改进的飞轮”。未上线的团队可以用内部 dogfooding 产生 trace。

离线 vs 在线：两道互补的闸门
· 离线评估（Offline）：发生在发布前、对数据集、用来测新 prompt/模型/工具防回归
· 在线评估（Online）：发生在生产环境、对真实流量 trace、用来持续监控线上质量

两者形成闭环：线上标出的失败，转化为线下的新样本。数据集组织原则也很实用，同一行为、同一组评估器的样本放一起；输入、评估器或目的不同就另建数据集，避免一个大盘子什么都装。

评估器的优先级：代码 > LLM 裁判 > 人工
· 代码评估器：确定性检查（如“价格是否低于预算”），快、便宜、零歧义，能用则必用；
· LLM-as-a-judge：处理代码判不了的主观维度（如“回复是否清晰确认了航班信息”）；
· 人工审核：最贵但最可靠的信号，用于抽样校准前两者；
· Pairwise（成对比较）：让裁判二选一，比绝对打分更稳定。

评估对象的颗粒度也分层：单步 → 最终回复 → 完整对话 → 环境终态（如容器内记录、文件、测试是否通过）。

LLM 裁判能否信任：三条可操作建议
1. 用人工标注对照校准，调整裁判 prompt 直到两者对齐；
2. 问窄问题，“回复是否提到了每一个中转站？”远好于“这是个好回复吗？”；
3. 用二元判定或分类标签，避免 1–10 打分（数值打分的跨 run 一致性很差）。

Eval ≠ Benchmark：一个重要的概念澄清
Benchmark 本质是 “重型离线 eval”，其特殊性在于：
· 任务长链路，涉及数十次工具调用；
· 每个任务自带独立的容器化隔离环境；
· 评分方式是检查运行后的环境状态（订票记录是否存在、代码测试是否通过），而非比对文本。

文中介绍了开源评估 harness Harbor（Terminal-Bench 的底层引擎），每个任务构建一个容器，结果记录到 LangSmith 实验。自建 benchmark 的路径：从 trace 收集任务 → 定义评分规则 → 对分数做 hill climbing（爬山式迭代优化），甚至可以做成 Karpathy 式的自动化研究循环。

线上评估的成本控制
生产流量全量打分不现实，博客给出三层降本：
1. 采样与过滤：只评估有负反馈的 trace；
2. 代码检查优先：几乎零成本；
3. 换更便宜的裁判模型：小模型裁判在 pass/fail 判定上与人类标注一致，总成本 $0.34 vs Claude Sonnet 4.6 的 $28.17（约 1/83）。对二元判定类任务，裁判模型确实不必用旗舰模型。

不必从零自建
生态已提供相当多现成件：针对幻觉、PII 泄露等常见问题的预置 LLM 评估器模板、开源 agentevals 包（针对消息和工具调用）、可从代码仓库和 trace 直接生成可运行评估的 Eval Engineering Skill、从 issue 聚类自动生成数据集和断言的 LangSmith Engine。且整个体系框架无关；支持 OpenAI Agents SDK、Claude Agent SDK，或用 @ traceable 装饰器裸接。

迁移也不必推倒重来：数据集以 CSV/JSONL 导入，pytest/Vitest 集成保留现有测试体系，已有裁判 prompt 直接粘贴复用。

两个进阶难题
多轮对话：每一轮都看似正常、整体却失败的“累积性失败”是单点评估的盲区。解法是给 trace 附上 thread ID 将各轮聚合，再挂载面向整段对话的在线评估器（如“用户是否被迫重复了自己的需求”）；离线侧则把完整对话存为样本，或用 LLM 模拟用户。

超越最终输出：复杂 agent 需要检查轨迹（消息/工具调用序列）与终态（仓库变更、测试结果）。例如编码 agent 跑完后直接在其工作环境里执行该 repo 的测试套件；这正是 Harbor + 容器化沙箱的设计动机。

🔗 View Quoted Tweet

💬10🔄3❤️15👀1340📊12

⚡ Powered by xgo.ing

Grok Bot、Muse 让人对个人智能体又多了一些期待。但在个人使用场景里，除了让 Agent 持续运行的电脑环境，支付也是绕不过去的环节。比如出差旅行，我希望它根据行程帮我选好航班、找好会场...

meng shao (@shao__meng) — Thu, 15 Oct 2026 09:47:24 GMT

Grok Bot、Muse 让人对个人智能体又多了一些期待。但在个人使用场景里，除了让 Agent 持续运行的电脑环境，支付也是绕不过去的环节。

比如出差旅行，我希望它根据行程帮我选好航班、找好会场附近的酒店，再继续完成预订。如果最后还是发来一堆链接，让我逐个打开、填写信息、手动付款，任务就还需要我接着做。

从“帮我找”到“帮我办完”，支付能力是很关键的一步。
最近看到蚂蚁国际 9 月份公布的 AMP（Agentic Mobile Protocol，面向 AI Agent 的移动支付协议）第一阶段合作名单，Starryblu 是 10 家钱包合作伙伴中唯一的新加坡方。

它在这里承担的是钱包一侧的账户连接、授权与付款。比如我要预定酒店：
第一步，在【品牌补充：支持的 Agent 名称及入口】中连接 Starryblu 钱包，完成授权和身份验证。
连接完成后，再向 Agent 提出具体任务，比如：
“下周去新加坡参加会议，帮我找两晚酒店，距离会场步行 15 分钟以内，支持免费取消，总价不超过 400 新币。”
第二步，让 Agent 按要求寻找酒店，再选择付款方式。
如果希望自己确认，就让 Agent 整理好酒店、入住日期、房型、总价和取消条件。我核对订单并确认后，再通过连接的钱包付款，继续完成预订。

如果任务条件已经很明确，也可以采用预先授权的方式：先批准预算和购买条件，让 Agent 在这个范围内寻找并执行支付。
比如，我愿意继续等价格，可以把要求设为：
“这家酒店指定日期的两晚含税总价降到 400 新币以内，且仍支持免费取消时，再帮我预订付款。”
这里需要事先说清楚入住日期、房型、价格和退订要求。便宜但不能退的房间，就不符合这次任务的条件。

这样的支付方式，才让“帮我盯着，有合适的就订”成为一个可以继续执行的任务。
对我来说，吸引力在于减少从选好到买好之间的操作：购买要求已经告诉 Agent，付款也能沿着同一个任务继续完成。

期待以后出门旅行，我只需要说清楚去哪、预算多少、有什么要求，Agent 就能把攻略、预订和付款一起办好。花钱的规矩我来定，剩下的交给它。

有相关跨境账户需求、符合开户及活动条件的朋友，可以通过我的链接注册，或填写邀请码「MQFK02N」，可以额外获得50新币消费卷，共60新币，可用于线上线下消费减免。目前必须要通过推荐码才可以开通白名单，有选择\会员卡不排队​​权限。​​

sg.starryblu.com/x/1uJaBc1L

💬9🔄1❤️5👀1173📊11

⚡ Powered by xgo.ing

DeepSeek 今天的服务故障持续了接近五个小时 (4h52m) API 和 Chat 服务都收到了影响，定位问题用了 1 个小时，修复用了 3 个多小时。目测这个问题不小，蹲一个官方对问题原因的...

meng shao (@shao__meng) — Thu, 15 Oct 2026 07:05:20 GMT

DeepSeek 今天的服务故障持续了接近五个小时 (4h52m)

API 和 Chat 服务都收到了影响，定位问题用了 1 个小时，修复用了 3 个多小时。目测这个问题不小，蹲一个官方对问题原因的公告。

💬7🔄1❤️3👀2306📊9

⚡ Powered by xgo.ing

Agent Evals 最常见的问题都有什么？ @LangChain 团队 @divyasan0 以 Q&A 形式分享了 Agent Evals 实践指南，把常见问题一次性回答了。她给出的可落地工程...

meng shao (@shao__meng) — Thu, 15 Oct 2026 04:18:06 GMT

Agent Evals 最常见的问题都有什么？

@LangChain 团队 @divyasan0 以 Q&A 形式分享了 Agent Evals 实践指南，把常见问题一次性回答了。她给出的可落地工程流程：从真实 trace 起步、小数据集建立基线、失败案例回流迭代、离线/在线分层评估、代码优先于 LLM 裁判、benchmark 用容器化环境验证最终状态。

QA 博客地址：
langchain.com/blog/common-qu…

为什么 Agent 难以测试 ？
· 输出不确定性：同一输入，多次运行结果不同；
· 答案非唯一：多个不同回答都可能是正确的，无法做字符串精确匹配；
· 路径自选：Agent 自己决定执行步骤，即使最终答案正确，路径也可能是“错的”（调用了不必要的工具、未经授权就行动）。

起点：从 trace 开始的最小闭环
一条清晰路径值得直接采纳：
读一批真实 trace → 选定一个行为 → 建 10–20 条小数据集 → 跑基线实验 → 之后所有改动都与基线对比。

其中最有价值的工程习惯是失败回流机制：发现一次失败 → 作为新样本加入数据集 → 改进 agent → 重跑全量。这让数据集随系统演化而增长，评估从“一次性验证”变成“持续改进的飞轮”。未上线的团队可以用内部 dogfooding 产生 trace。

离线 vs 在线：两道互补的闸门
· 离线评估（Offline）：发生在发布前、对数据集、用来测新 prompt/模型/工具防回归
· 在线评估（Online）：发生在生产环境、对真实流量 trace、用来持续监控线上质量

两者形成闭环：线上标出的失败，转化为线下的新样本。数据集组织原则也很实用，同一行为、同一组评估器的样本放一起；输入、评估器或目的不同就另建数据集，避免一个大盘子什么都装。

评估器的优先级：代码 > LLM 裁判 > 人工
· 代码评估器：确定性检查（如“价格是否低于预算”），快、便宜、零歧义，能用则必用；
· LLM-as-a-judge：处理代码判不了的主观维度（如“回复是否清晰确认了航班信息”）；
· 人工审核：最贵但最可靠的信号，用于抽样校准前两者；
· Pairwise（成对比较）：让裁判二选一，比绝对打分更稳定。

评估对象的颗粒度也分层：单步 → 最终回复 → 完整对话 → 环境终态（如容器内记录、文件、测试是否通过）。

LLM 裁判能否信任：三条可操作建议
1. 用人工标注对照校准，调整裁判 prompt 直到两者对齐；
2. 问窄问题，“回复是否提到了每一个中转站？”远好于“这是个好回复吗？”；
3. 用二元判定或分类标签，避免 1–10 打分（数值打分的跨 run 一致性很差）。

Eval ≠ Benchmark：一个重要的概念澄清
Benchmark 本质是 “重型离线 eval”，其特殊性在于：
· 任务长链路，涉及数十次工具调用；
· 每个任务自带独立的容器化隔离环境；
· 评分方式是检查运行后的环境状态（订票记录是否存在、代码测试是否通过），而非比对文本。

文中介绍了开源评估 harness Harbor（Terminal-Bench 的底层引擎），每个任务构建一个容器，结果记录到 LangSmith 实验。自建 benchmark 的路径：从 trace 收集任务 → 定义评分规则 → 对分数做 hill climbing（爬山式迭代优化），甚至可以做成 Karpathy 式的自动化研究循环。

线上评估的成本控制
生产流量全量打分不现实，博客给出三层降本：
1. 采样与过滤：只评估有负反馈的 trace；
2. 代码检查优先：几乎零成本；
3. 换更便宜的裁判模型：小模型裁判在 pass/fail 判定上与人类标注一致，总成本 $0.34 vs Claude Sonnet 4.6 的 $28.17（约 1/83）。对二元判定类任务，裁判模型确实不必用旗舰模型。

不必从零自建
生态已提供相当多现成件：针对幻觉、PII 泄露等常见问题的预置 LLM 评估器模板、开源 agentevals 包（针对消息和工具调用）、可从代码仓库和 trace 直接生成可运行评估的 Eval Engineering Skill、从 issue 聚类自动生成数据集和断言的 LangSmith Engine。且整个体系框架无关；支持 OpenAI Agents SDK、Claude Agent SDK，或用 @ traceable 装饰器裸接。

迁移也不必推倒重来：数据集以 CSV/JSONL 导入，pytest/Vitest 集成保留现有测试体系，已有裁判 prompt 直接粘贴复用。

两个进阶难题
多轮对话：每一轮都看似正常、整体却失败的“累积性失败”是单点评估的盲区。解法是给 trace 附上 thread ID 将各轮聚合，再挂载面向整段对话的在线评估器（如“用户是否被迫重复了自己的需求”）；离线侧则把完整对话存为样本，或用 LLM 模拟用户。

超越最终输出：复杂 agent 需要检查轨迹（消息/工具调用序列）与终态（仓库变更、测试结果）。例如编码 agent 跑完后直接在其工作环境里执行该 repo 的测试套件；这正是 Harbor + 容器化沙箱的设计动机。

💬17🔄7❤️56👀4661📊36

⚡ Powered by xgo.ing

突然想到，Agents 运行过程中，是不是也可以用这块副屏和遥控器来玩游戏啊！现在我使用一些老电视剧来打发 Agents 运行中时间的，不过都快刷烂了，实在找不到新剧。如果有一些小游戏，或者自...

meng shao (@shao__meng) — Thu, 15 Oct 2026 04:17:30 GMT

突然想到，Agents 运行过程中，是不是也可以用这块副屏和遥控器来玩游戏啊！

现在我使用一些老电视剧来打发 Agents 运行中时间的，不过都快刷烂了，实在找不到新剧。

如果有一些小游戏，或者自己 vibe 一些小游戏装上，边玩边等 Agent 运行，运行完在副屏直接暂停我的游戏，提示我操作 Agent 下一步动作，完美！

meng shao@shao__meng

这个给 Agent 设计的桌面副屏 + 手持遥控器可以啊！

突然有了 Agent 兵团总指挥部和模拟游戏的感觉。

· 3.96 英寸 LCD 副屏集中显示所有 Agent 会话状态
· 手持器上的两轴摇杆选择某个会话
· 按住语音键 100 毫秒内即可开始录音
· 语音还可经听写软件转写成得体的邮件、笔记

🔗 View Quoted Tweet

💬4🔄0❤️5👀1075📊4

⚡ Powered by xgo.ing

Modal ARR 过 $1B、D 轮融资 $750M、投后估值 $15.75B 恭喜 @modal 团队！再重温一下 Modal 团队发布的「GPU 术语手册」，对整个 GPU 技术栈的讲述真...

meng shao (@shao__meng) — Thu, 15 Oct 2026 03:58:48 GMT

Modal ARR 过 $1B、D 轮融资 $750M、投后估值 $15.75B

恭喜 @modal 团队！

再重温一下 Modal 团队发布的「GPU 术语手册」，对整个 GPU 技术栈的讲述真的很易懂，推荐！

meng shao@shao__meng

Modal @modal 这份「GPU 术语手册」做的太友好了，它把整个 GPU 技术栈拆成四个相互勾连的层面：设备硬件、设备软件（执行模型）、主机软件（驱动与工具链）、性能分析，每个词条都密集交叉链接，既可以按需查阅单个术语，也可以从头到尾线性通读。

理解这份手册从「CUDA」开始，CUDA 有三重含义：一种设备架构、一个并行编程模型、一个软件平台。这份手册的四个章节恰好分别展开这三个含义加上性能分析。

GPU Glossary 四个章节：
1. 设备硬件：GPU 的物理解剖 - CPU 用复杂核心避免延迟，GPU 用海量简单线程隐藏延迟
2. 设备软件：CUDA 的执行模型 - 线程层级、内存层级、硬件三层严格同构，程序员亲手管理内存
3. 主机软件：驱动、工具链与库 - Runtime 包着 Driver，闭源库拿来即用，CUTLASS 一系负责构造自己的 kernel
4. 性能分析：完整诊断链 - 定瓶颈 → roofline 定性 → 利用率定位 → warp 机制 → 访存模式 → 资源约束

这三句总结很到位
GPU 的本质是“单周期切换海量简单线程来隐藏延迟”；编程的本质是“沿线程-内存-硬件的同构层级，把数据在正确的层级间搬运，把算术强度做到岭点以上”；性能工程的本质是“沿诊断链逐层定位，用 Little 定律算够并发，不为中间指标（如占用率）本身而优化。

modal.com/gpu-glossary

🔗 View Quoted Tweet

💬4🔄1❤️6👀1361📊4

⚡ Powered by xgo.ing

把 Qwen 微调提速 6 倍的实战经验分享 @databricks 分享了在自家 AI Runtime 上微调 Qwen 3.8 27B 的调优全过程，从 7 小时 44 分压到 1 小时 17 ...

meng shao (@shao__meng) — Thu, 15 Oct 2026 03:27:32 GMT

把 Qwen 微调提速 6 倍的实战经验分享

@databricks 分享了在自家 AI Runtime 上微调 Qwen 3.8 27B 的调优全过程，从 7 小时 44 分压到 1 小时 17 分，提速 6 倍。堪称教科书级的性能工程案例：用 torch profiler 找到真正的瓶颈（CPU 调度过载，而非 GPU 不够忙），再用两步常规手段解决它（融合内核 + 序列打包）！

博客地址，强烈推荐阅读：
databricks.com/blog/reducing-…

# 起点：一个"看起来很健康"的慢基线

任务设定：用 HuggingFaceH4/ultrachat_200k 数据集对 Qwen 3.8 27B 做 SFT，采用 FSDP2 分片（27B 权重单卡放不下）+ 激活检查点，按最大 8192 token/batch 组 batch。

基线跑了 7h44m，GPU 平均利用率 98%；按常规监控逻辑这几乎无可挑剔。但有一个普遍误区：GPU 利用率只衡量 "GPU 是否在做事"，不衡量 "GPU 做得有多好"。

它无法区分高效执行和"把时间浪费在几万次微小 elementwise 操作上"。正确的诊断工具是 torch trace / profiler。

# 诊断：瓶颈在 CPU，不在 GPU

Profiler 结果显示一个反直觉的事实：CPU 每步耗时（14.4s）超过了 GPU（10.3s），CPU 忙于往 GPU 队列里塞操作，根本喂不满。单个训练 step 里 CPU 发起了约 171 万次调用（如 bmm 31,105 次、mul 46,878 次），GPU 侧也有 4 万多次琐碎的 elementwise add。

根源在于 Qwen 3.8 的门控 Delta 网络（gated delta net）层；这类线性注意力/卷积混合层在 transformers 的朴素实现里会被展开成海量小算子。也就是说，慢不是模型本身的问题，是参考实现没有针对训练做算子级融合。

Databricks 评估了三条路：
· CUDA Graphs：否，与 FSDP2 的动态性冲突
· torch.compile：否，编译太慢，且会漏掉关键融合（如 Flash Attention）
· 手动接入已知融合内核：是，选这条路

# 优化一：接入融合内核 → 3.7 倍

transformers 的实现其实标注了对两个融合内核的支持，安装后即生效：
· flash-linear-attention（PyPI）覆盖 gated delta rule 层；
· causal-conv1d（Dao-AILab）覆盖因果卷积。

效果立竿见影：7h44m → 2h05m（3.7x），每步算子数下降约 15 倍（CPU 调用从 171 万降到 11.8 万），trace 里最耗时的条目变成了 ChunkGatedDeltaRule、flash_attention_3 前反向和 causal-conv1d 内核。

两个值得记住的工程细节：
· 不要依赖 HF Kernel Hub 动态加载内核：torch/CUDA 版本不匹配时它会静默回退到未优化路径，你以为什么都没变，其实优化已经失效。推荐直接安装，最好在 Docker 镜像构建时固化。
· 部分内核只实现了 forward，推理可用但训练不可用：选型时必须核对。

# 优化二：1D 序列打包去 padding → 再 1.6 倍

剩余瓶颈是数据侧的浪费：输入张量必须是矩形，导致每个 batch 内短序列被 padding 到最长序列，2D 矩形里大量格子是无效计算。

理想方案 NestedTensor 只兼容标准注意力；而 flash-linear-attention 要求 1D 打包（concat + position_ids） 格式。作者的做法是把 batch 内多个样本拼接成一维，并为每个样本传入正确的 position_ids，使注意力 mask 严格限制在样本内部，不发生跨样本泄漏（示例代码在 ai-runtime-cookbook 仓库）。

2h05m → 1h17m（1.6x），收益来自两头：
· 序列打包使 batch 数减少约 36%（取决于长度分布）；
· 输入 shape 从动态变为固定，flash-linear-attention 的 JIT 编译开销大幅下降。

也有客观代价：流水线复杂度上升，且 position_ids 一旦写错就是静默的质量 bug（训练照跑、模型变差）。备选方案"按长度排序组 batch"虽能减少 padding，但会引入样本顺序相关性带来的训练偏差。

# 方法论提炼

1. 测量要测对的东西：GPU 利用率会骗人，torch trace 不会；
2. 优先接入社区已验证的融合内核：flash-linear-attention、causal-conv1d、Flash Attention；
3. 消灭 padding 浪费：1D 打包 + 正确的 position_ids。

平台层面的配套：AI Runtime 打包了新版 CUDA/Flash Attention、保持 profiler 工具链更新、内置 GPU 指标，且 Genie Code 会在代码层主动寻找这类优化。

💬9🔄3❤️48👀2981📊23

⚡ Powered by xgo.ing

给 /grill-me Skill 加一个 GRILL.md 配置文件 Matt 详细讲述了它的三个作用 1. 用配置实现组合，取代命令变体。有了 GRILL.md 之后，/grill-with...

meng shao (@shao__meng) — Thu, 15 Oct 2026 02:23:13 GMT

给 /grill-me Skill 加一个 GRILL.md 配置文件

Matt 详细讲述了它的三个作用

1. 用配置实现组合，取代命令变体。 有了 GRILL.md 之后，/grill-with-docs 这个单独的 Skill 就不需要了，你在自己的 GRILL.md 里写一句"调用 domain-modeling Skill"，再用 /grill-me 就能得到同等效果。也就是说，与其为每种用法维护一个 Skill 分支，不如让 Skill 读取用户配置、按需组合其他 Skills。

2. 可定制拷问的侧重点。 不同的团队/项目在规划阶段关心的维度不同，有人在意安全，有人在意模块划分策略。GRILL.md 让用户声明"我希望被问哪些方面"，而不是被动接受作者预设的固定问题集。

3. 可定制交互节奏。 用户可以选择 AI 是一次问一个问题（逐条深入、对话感强）还是一次性把所有问题列出（整体浏览、效率优先），把交互模式的选择权交给使用者。

Matt Pocock@mattpocockuk

Debating adding a GRILL.md file to customize how /grill-me works

A few benefits:

1. /grill-with-docs gets removed, you just have 'invoke the domain-modeling skill' in your GRILL.md and use /grill-me
2. Customize what you care about/get asked about during planning (security, module strategy, etc)
3. Choose whether you want to be grilled one at a time or all together

People seem really, really reticent to actually edit the skill themselves, so this seems sensible to me.

🔗 View Quoted Tweet

💬4🔄1❤️10👀1655📊6

⚡ Powered by xgo.ing

这个给 Agent 设计的桌面副屏 + 手持遥控器可以啊！突然有了 Agent 兵团总指挥部和模拟游戏的感觉。 · 3.96 英寸 LCD 副屏集中显示所有 Agent 会话状态 · 手持器上的...

meng shao (@shao__meng) — Thu, 15 Oct 2026 02:08:00 GMT

这个给 Agent 设计的桌面副屏 + 手持遥控器可以啊！

突然有了 Agent 兵团总指挥部和模拟游戏的感觉。

· 3.96 英寸 LCD 副屏集中显示所有 Agent 会话状态
· 手持器上的两轴摇杆选择某个会话
· 按住语音键 100 毫秒内即可开始录音
· 语音还可经听写软件转写成得体的邮件、笔记

💬31🔄0❤️8👀1943📊33

⚡ Powered by xgo.ing

CS 329Z: Engineering AI Agents Stanford / Fall 2026 @stanfordnlp https://t.co/Ko6UarsQff 课程定位：从"模型...

meng shao (@shao__meng) — Thu, 15 Oct 2026 01:34:04 GMT

CS 329Z: Engineering AI Agents
Stanford / Fall 2026 @stanfordnlpcs329z.stanford.edu 

课程定位：从"模型"到"系统"的工程学覆盖：简单 LLM 流水线 → 复合 AI 系统 → 自主 Agent。

@Diyi_Yang@michaelryan207@jyangballin 三位老师主讲，今天第 7 讲「Agent Memory Architectures」讲义公开：
web.stanford.edu/class/cs329z/s…

meng shao@shao__meng

CS 329Z: Engineering AI Agents
Stanford / Fall 2026 @stanfordnlpcs329z.stanford.edu

课程定位：从"模型"到"系统"的工程学
覆盖：简单 LLM 流水线 → 复合 AI 系统 → 自主 Agent。三位讲师的背景也高度互补：
@Diyi_Yang（斯坦福 NLP 教授，人机交互与社会计算方向）
@michaelryan207（DSPy 核心贡献者，自动评估 AutoMetrics 作者）
@jyangballin（SWE-agent / SWE-bench / SWE-smith 作者，软件工程 Agent 领域最重要的研究者之一）

# 课程主线：三大工程挑战
贯穿全课的三个核心问题——分解（decomposition）、数据（data）、评估（evaluation）。11 周的内容基本围绕这三条线展开，可以分为五个模块：

模块 1：构建基元（Week 2–3）
· LLM 作为构建材料：API/SDK（litellm）、结构化输出、约束生成、解码策略、test-time compute、上下文工程、模型选型与成本/延迟权衡
· RAG：embedding、向量库、分块策略、混合检索、cross-encoder 与 ColBERT 后期交互
· 工具调用：函数调用 API、MCP（Model Context Protocol）、工具设计、代码沙箱、错误处理与重试

模块 2：框架与设计模式（Week 3–5）
· 框架层：DSPy（signature / module / optimizer）、LangChain/LangGraph、LlamaIndex，重点是"框架抽象了什么 vs. 你手写了什么"
· 设计模式：workflow vs. agent 的分类学，五种可组合 workflow 模式，ReAct / plan-and-execute / reflection，"scaffold（脚手架）本身就是设计决策"
· 记忆架构：短期/长期记忆、记忆作为工具动作、文件系统作为外化记忆、跨 Agent 记忆（MemGPT、Mem0、Generative Agents）
· 多 Agent 系统：编排模式、handoff 与状态传递，以及一个很有态度的对照阅读——既读 AutoGen，也读《Why Do Multi-Agent LLM Systems Fail?》和 Neubig 的《Don't Sleep on Single-agent Systems》

模块 3：优化（Week 5）
· 从提示词到微调的全景：GEPA、MIPROv2、OPRO、TextGrad（提示优化）；LoRA/QLoRA、蒸馏、RLHF/DPO（权重优化）；test-time scaling（推理算力）
· 核心问题是决策框架：什么时候优化 prompt、什么时候优化 weights、什么时候堆推理算力

模块 4：数据与评估（Week 6–8）——最有分量的部分
· 数据：trace、demonstration、feedback 三类数据；训练数据 vs. 评估数据；数据飞轮；合成数据；从 Agent 轨迹构建数据集（SWE-smith）
· 评估基础：为什么 eval 难；4 元组框架（request / environment / stopping criteria / scorer）；好 benchmark 的性质；tinyBenchmarks
· 评估基础设施：三类 grader、LLM-as-judge 的 prompt 设计与已知偏差、pairwise vs. pointwise、非确定性指标 pass@k vs. pass^k、harness 设计

模块 5：安全与前沿（Week 8–11）
· 安全：工具访问的隐私风险、prompt injection（含间接注入）、红队、沙箱与权限模型、输出护栏、human-in-the-loop
· Coding Agent：SWE-agent、Claude Code、OpenHands 的端到端架构对比
· 主动式 Agent：从 reactive 到 proactive，General User Models（GUM）、Next Action Prediction，以及"Agent 何时应主动、何时应等待"的 mixed-initiative 问题
· 开放问题：多模态/web/计算机使用 Agent、科学 Agent、长时运行架构、生产可观测性（tracing、monitoring、成本管理）

# 作业设计：一手建、一手评

HW1：从零构建 Agent 系统（10%） 给定论文库，构建能检索并推理回答科学问题的 Agent。
· Part A：只用 litellm 手写 RAG + 工具调用 + ReAct 式 Agent 循环
· Part B：用 DSPy 重建关键组件，并反思框架抽象了什么

HW2：评估一个 Agent（10%） 给定一个预构建 Agent，设计完整评估套件：代码型 grader、至少一个 LLM-as-judge、用 4 元组框架构建 benchmark 任务、错误分析。

🔗 View Quoted Tweet

💬8🔄23❤️108👀4046📊40

⚡ Powered by xgo.ing

模型创造力排行 GPT-6 Astra 排第一、Claude Opus 5.5 第八？而且最强模型还是远低于人类？ @Kombaico 发布了 Design Creativity Bench：...

meng shao (@shao__meng) — Thu, 15 Oct 2026 01:24:12 GMT

模型创造力排行 GPT-6 Astra 排第一、Claude Opus 5.5 第八 ？而且最强模型还是远低于人类 ？ 

@Kombaico 发布了 Design Creativity Bench：一个专门评估 AI 模型在 UI 设计任务上“创造力”的基准，可以看具体评测情况和数据，以及背后的论文和代码支撑：
kombai.com/benchmark/

# 测试基准怎么建立的 ？

任务设计：80 个开放式 UI 任务，每个任务适配两个不同产品领域（共 160 份设计简报），并配有人类设计师的参考作品作为基线。

评估对象：34 个模型（推文聚焦其中 16 个前沿模型）。

三个创造力维度（理论根基是“创造力 = 新颖性 + 适切性”）：
· 原创性：不同模型面对同一提示时，产出之间差异有多大；
· 创意广度：同一 UI 目标换到另一个产品领域时，模型能否做出真正不同的设计决策；
· 适切性：设计满足简报验收标准的程度。

# 测试结果很意外！

创造力总分差距悬殊：最佳模型 GPT-6 Astra 得 65.5，人类设计师参考为 92.3，差距近 30 分。前几名为 GPT-6 Astra（65.5）、GPT-6.1 Sol（63.7）、Grok 4.7（62.2）、Gemini 3.8 Flash（60.6），Claude Opus 5.5 才 51 分！

模型“合格但不出彩”：
· 适切性上模型不输甚至略胜人类：所有前沿模型均超过 90%，最高 99.2%（人类为 98.0%）。模型是出色的“执行者”。
· 但原创性显著不足：模型与模型之间的设计相似度为 0.592，而人类与模型之间为 0.764；也就是说，模型们收敛到了同一种“平均审美”，彼此更像，与人类的差异反而更大。
· 创意广度差距最大：模型平均 0.581 vs 人类 0.902。同一个界面换个行业，人类设计师会重构设计语言，模型基本只是换皮。

一个精妙的反面验证：排行榜垫底的模型（如 Seed 1.6 Flash）原创性数值反而最高（0.810），但适切性只有 73.7%。这证明该基准没有被“乱出牌”骗过：单纯的怪异不等于创造力，新颖必须建立在对需求的准确理解之上。同时也解释了为什么强模型趋于保守： RLHF 式的训练天然会把输出拉向分布的众数，原创性成为代价。

Dipanjan Dey@Dipanjan_Dey

⚠️ Frontier AI models still fall significantly short of human designers on design creativity. ⚠️

Introducing Design Creativity Bench, a new benchmark evaluating AI models’ creativity on UI design tasks.

Despite rapid advances in their ability to generate functional websites and product UIs, leading AI models still struggle to make creative design decisions.

We evaluated 16 frontier models across 80 open-ended UI tasks, each adapted to two distinct product domains alongside human designer references.

Existing UI benchmarks often measure a single output quality metric. Instead, we measure three dimensions of design creativity:

- Originality: How distinct a model's designs are from other models' outputs for the same brief.
- Creative Range: How much a model adapts its design decisions when the product domain changes.
- Appropriateness: How well the generated UI satisfies the functional requirements of the brief.

The results reveal a substantial gap in overall creativity: The best model, @OpenAI GPT-6 Astra, scores 65.5 against a human reference of 92.3.

We're publishing the full leaderboard, methodology, and reproducible evaluation framework to make design creativity a measurable dimension of frontier model capability.

📊 Benchmark Leaderboard:kombai.com/benchmark/P
📄 Paperarxiv.org/abs/2610.11539cL
🤗 HuggingFace Datasethuggingface.co/datasets/Komba…Eyl
🔗 Githgithub.com/kombai-io/desi…9P7H

🔗 View Quoted Tweet

💬11🔄3❤️18👀2025📊13

⚡ Powered by xgo.ing

CMU 秋季最新课程 11-768: AI Agents 主讲：@dan_fried @gneubig 第 12 讲「Reinforcement Learning Systems」讲义和视频已公...

meng shao (@shao__meng) — Wed, 14 Oct 2026 13:35:18 GMT

CMU 秋季最新课程 11-768: AI Agents  
主讲：@dan_fried@gneubig

第 12 讲「Reinforcement Learning Systems」讲义和视频已公开

这一讲从强化学习系统的框架开始讲起、再到推理侧和训练侧的分别优化、训练-推理交互、Agentic RL 的实战踩坑经验、RL 框架设计等，完整系统了讲述了强化学习系统的理论和实战。

讲义：cmu-agents.com/slides/lecture…
视频：youtube.com/watch?v=dwR6NP…

在课程中看到几个最核心的观点：
1. RL 框架的本质是两种异质负载（训练和推理）的耦合，而非一套统一计算图
2. “前缀复用”是贯穿 agentic RL 系统效率的不变量
3. Token-In-Token-Out：一个微小设计错误曾造成全行业的训练不稳定
4. 权重同步与 R3：双引擎之间的隐藏成本
5. 架构演进终点：一切皆服务 + 在线 RL

meng shao@shao__meng

周末适合沉下心来系统性的学习基础知识

CMU 秋季最新课程 11-768: AI Agents

主讲：@dan_fried@gneubig
课程：cmu-agents.com
视频：youtube.com/watch?v=Uwfjzy…

🔗 View Quoted Tweet

💬6🔄32❤️152👀5190📊47

⚡ Powered by xgo.ing

别的 AI 公司在新加坡成立办公室：哇，中国的青年才俊润的目标公司 +1 A\ 在新加坡成立办公室：完蛋，中国用户伪装的新加坡户口，要被扒光了 😂

meng shao (@shao__meng) — Wed, 14 Oct 2026 12:42:27 GMT

别的 AI 公司在新加坡成立办公室：哇，中国的青年才俊润的目标公司 +1
A\ 在新加坡成立办公室：完蛋，中国用户伪装的新加坡户口，要被扒光了 😂

Anthropic@AnthropicAI

We’ve opened an office in Singapore—our fifth in the Asia-Pacific region. We’ve also signed an MOU with the Government of Singapore on AI safety and responsible adoption.

You can read more about our new office here: anthropic.com/news/singapore…

🔗 View Quoted Tweet

💬23🔄1❤️8👀3162📊20

⚡ Powered by xgo.ing

Grok Bot 回答更有参考价值。。手残打错字了 🤭

meng shao (@shao__meng) — Wed, 14 Oct 2026 09:42:16 GMT

Grok Bot 回答更有参考价值。。

手残打错字了 🤭

💬0🔄0❤️1👀496

meng shao(@shao__meng)

把代码库调教得更适合 Agent：类型反馈、Expect Test，以及正式方法新账本 @poteto 推荐的 @yminsky 这场 Bug Bash 演讲，并点出几条她认为最值得带走的实战经验，...

https://t.co/rE6rU3Ybcd

Grok Bot 也学会请客送礼啦？ 😂 中国文化融入的这么自然吗？ 刚刚准备一些硬件概念，Grok Bot 突如其来的给我支招请前同事吃顿饭，着实惊到我了。。

Obsidian CEO @kepano 开源了一个 Mermaid 图表渲染库「Pele」，它完全重写了 Mermaid 12.1.0 全部语法的解析与渲染，输出 SVG，零运行时依赖。它没从 me...

Addy Osmani 谈 Agent 时代代码审查的重构 Claude 编写了 Claude Code 约 90% 的代码，而在 6 月到 9 月间，团队合并的 PR 数量翻倍以上，回滚率反而下降...

The Pragmatic Engineer 作者 @GergelyOrosz 分享了一个对开发朋友们非常典型的困扰：老板被各种 AI 炸裂新闻洗脑，把 "AI token 用量" 设为 KPI ！而...

pstack 新增了一个 skill /create-formal-verification-skill 定位是 meta-skill：不直接帮你做形式化验证，而根据你想验证的系统特性，自动生成一个...

阿里通义 MAI-UI 团队开源了通用计算机使用智能体完整技术栈「OpenGCUA」：包括 harness、跨设备 SDK、原生 macOS 应用、评测轨迹和参考 agent 实现 开源地址：htt...

有朋友指出 Doubao-seed 在 8-9月有更新，以及 M3.1-Flash-Preview 也是 9月发布的，这两个我确实没关注到，跟大家同步更新一下。 不过这篇帖子难得的收到了很多「真人」...

GLM 5.3 是来自中国的 Mythos-Class 网络安全模型吗？ 来自 SemiAnalysis Weekly 播客 Ep. 038：主持人 @JordanNanos，嘉宾是 SemiAna...

Stripe 首席设计官 @lil_dill 分享：如何用 AI 规模化扩展意图、品质与艺术性 ？ Youtube 视频：https://t.co/2yDoDR5oX8 # 三个警戒信号 1. ...

斯坦福大学 CS336: Language Modeling from Scratch 第 10 讲「Inference」，在前后两讲 Scaling Laws 和 Scaling Laws II ...

昨天我老婆问我 App Store 怎么付费，看了一下才知道她要给儿子买一个打字 App，收费 128 块。。 这。。小孩和女人钱这么好赚？？ 我说等我半个小时，打开 Codex，把打字游戏的需求...

摇一摇跳转、切到后台回来跳广告页、跳过广告按钮打死点不到、广告金刚位... 中国移动互联网，产生了太多这类「创新」了，如果是中国人搞定了火星移民，那 tm 到了火星也得点广告，要么付费才能提前解锁火...

Google Research 最新开源了 Harness²：递归式智能体 Harness 优化框架 Harness² 解决的两个开放世界难题 1. 测试时遇到的是没见过的任务，没有 ground-...

公众号关注终于到 10000 了 9999 停了好几天 😂

WorkBuddy 宣布: DeepSeek-V4.1-Flash-1017 在 10.31 前限时免费 不过，是「国际版」！ 国内版还没有限免活动。

怎么感觉国内 AI 团队们，有几个很久没发新模型了？ 本来以为是 AI 模型发布更新太快的时间错觉，查了一下，确实有几家超过 3 个月没发了。 字节：Doubao-Seed-2.1-Pro 6月2...

DeepSeek 叕发布了一个「小」版本：DeepSeek V4.1-Flash-1017，在性能、速度、输出长度三个维度同时改进，同时将内部搜索引擎以 Search & Fetch API 的形式正...

手动点赞推荐 @samuel_ys92 👍 买卖简历和职位的生意该结束了 https://t.co/yPeuheEB69

女装电商场景对营销物料的需求，确实是一个非常典型的「SKU多、相似性高、数量大、更换频率高」 为什么特指女装，而不是服装。。各位男装用户，自己在电商平台啥地位，心里没数吗 😂，我心里的价值排序：女...

当 Claude 写了 Claude Code 约 90% 的代码后，团队如何重新设计代码评审 ？ Anthropic 没有取消代码评审，是把 “人读代码” 这个动作大部分交给了机器，把稀缺的人类注...

中国的开源模型，还能给美国人用吗？ 商务部 科技部发布第48号联合公告，拟将人工智能、生物医药、光伏三大领域共40项技术增列进《中国禁止出口限制出口技术目录》，并在目录正式生效前，立即对相关技术出口...

https://t.co/EfOMLZVin5

怎么才能更信任你的 Agent 的工作呢？ Grok Bot 团队 @poteto 提出了一套如何信任 AI Agent 工作成果的四层“倒金字塔”框架。她认为，与其花精力“管教” Agent，不如...

Perplexity 开源了团队内部 agent 代码执行平台「SPACE」，把不可信的 Agent 生成代码或用户代码放进 Firecracker microVM 里隔离运行，通过纯 HTTP/SS...

那好像是最后一届微软技术大会，也是我最后一次参加技术会议，曾经一起做 Windows Phone 和 Windows 开发的朋友们也陆续都转行了，那个时代，终究还是过去了，甚至没等到被 AI 冲击 ...

腾讯混元团队开源了「Hy Memory 2.0」，包括一个专用的记忆写入模型 Hy-Memory-30B-A3B、一个可编程的记忆框架 hy-memory SDK、一个面向终端用户的桌面工具 MemH...

pstack 作者公开她的 “工程原则” 设计思路 「Clean Code」作者 Uncle Bob 是传统软件工程方法论的宗师，他最近看到了 pstack，认为本质上是把经典工程智慧「最小改动、先...

会飞的汽车？太未来了！ Roadster 真的把 Tesla 和 SpaceX 联动了，搭载 SpaceX 的冷气推进系统。 那么。。刹车似乎确实没那么必要了，遥遥领先，还是遥遥领先！

https://t.co/3tyMv0rf0f

Anthropic 宣布新一代反蒸馏防御措施 攻击者从 Claude 平台上窃取的推理 token 量下降了 90%–99%，智谱 GLM-5.3 模型训练再次被重点点名、月之暗面 Kimi 用户请...

密歇根大学最新 AI 编程课「Applied Agentic Software Engineering」 第 14 讲「Subagents」讲义刚刚公开，围绕：为什么需要 subagents、机制是...

ComfyUI 要整大活儿了 ... @ComfyUI 发起 $25K 开源重建竞赛，要重建 Higgsfield 的 Genjutsu、Cinema Studio 等产品，还得到了 NVIDIA ...

帮每一位我能看到找工作的朋友转发。

Google 官方「5天 AI Agents 课程」 第 5 份白皮书「Spec-Driven Production Grade Development in the Age of Vibe Cod...

针对 Langchain 团队发布的 Agent Evals 最常见问题解答，做一个 Cheatsheet 方便随时查看。

Grok Bot、Muse 让人对个人智能体又多了一些期待。但在个人使用场景里，除了让 Agent 持续运行的电脑环境，支付也是绕不过去的环节。 比如出差旅行，我希望它根据行程帮我选好航班、找好会场...

DeepSeek 今天的服务故障持续了接近五个小时 (4h52m) API 和 Chat 服务都收到了影响，定位问题用了 1 个小时，修复用了 3 个多小时。目测这个问题不小，蹲一个官方对问题原因的...

Agent Evals 最常见的问题都有什么？ @LangChain 团队 @divyasan0 以 Q&A 形式分享了 Agent Evals 实践指南，把常见问题一次性回答了。她给出的可落地工程...

突然想到，Agents 运行过程中，是不是也可以用这块副屏和遥控器来玩游戏啊！ 现在我使用一些老电视剧来打发 Agents 运行中时间的，不过都快刷烂了，实在找不到新剧。 如果有一些小游戏，或者自...

Modal ARR 过 $1B、D 轮融资 $750M、投后估值 $15.75B 恭喜 @modal 团队！ 再重温一下 Modal 团队发布的「GPU 术语手册」，对整个 GPU 技术栈的讲述真...

把 Qwen 微调提速 6 倍的实战经验分享 @databricks 分享了在自家 AI Runtime 上微调 Qwen 3.8 27B 的调优全过程，从 7 小时 44 分压到 1 小时 17 ...

给 /grill-me Skill 加一个 GRILL.md 配置文件 Matt 详细讲述了它的三个作用 1. 用配置实现组合，取代命令变体。 有了 GRILL.md 之后，/grill-with...

这个给 Agent 设计的桌面副屏 + 手持遥控器可以啊！ 突然有了 Agent 兵团总指挥部和模拟游戏的感觉。 · 3.96 英寸 LCD 副屏集中显示所有 Agent 会话状态 · 手持器上的...

CS 329Z: Engineering AI Agents Stanford / Fall 2026 @stanfordnlp https://t.co/Ko6UarsQff 课程定位：从"模型...

模型创造力排行 GPT-6 Astra 排第一、Claude Opus 5.5 第八 ？而且最强模型还是远低于人类 ？ @Kombaico 发布了 Design Creativity Bench：...

CMU 秋季最新课程 11-768: AI Agents 主讲：@dan_fried @gneubig 第 12 讲「Reinforcement Learning Systems」讲义和视频已公...

别的 AI 公司在新加坡成立办公室：哇，中国的青年才俊润的目标公司 +1 A\ 在新加坡成立办公室：完蛋，中国用户伪装的新加坡户口，要被扒光了 😂

Grok Bot 回答更有参考价值。。 手残打错字了 🤭

Grok Bot 也学会请客送礼啦？ 😂 中国文化融入的这么自然吗？刚刚准备一些硬件概念，Grok Bot 突如其来的给我支招请前同事吃顿饭，着实惊到我了。。

阿里通义 MAI-UI 团队开源了通用计算机使用智能体完整技术栈「OpenGCUA」：包括 harness、跨设备 SDK、原生 macOS 应用、评测轨迹和参考 agent 实现开源地址：htt...

有朋友指出 Doubao-seed 在 8-9月有更新，以及 M3.1-Flash-Preview 也是 9月发布的，这两个我确实没关注到，跟大家同步更新一下。不过这篇帖子难得的收到了很多「真人」...

GLM 5.3 是来自中国的 Mythos-Class 网络安全模型吗？来自 SemiAnalysis Weekly 播客 Ep. 038：主持人 @JordanNanos，嘉宾是 SemiAna...

Stripe 首席设计官 @lil_dill 分享：如何用 AI 规模化扩展意图、品质与艺术性？ Youtube 视频：https://t.co/2yDoDR5oX8 # 三个警戒信号 1. ...

昨天我老婆问我 App Store 怎么付费，看了一下才知道她要给儿子买一个打字 App，收费 128 块。。这。。小孩和女人钱这么好赚？？我说等我半个小时，打开 Codex，把打字游戏的需求...

WorkBuddy 宣布: DeepSeek-V4.1-Flash-1017 在 10.31 前限时免费不过，是「国际版」！国内版还没有限免活动。

怎么感觉国内 AI 团队们，有几个很久没发新模型了？本来以为是 AI 模型发布更新太快的时间错觉，查了一下，确实有几家超过 3 个月没发了。字节：Doubao-Seed-2.1-Pro 6月2...

女装电商场景对营销物料的需求，确实是一个非常典型的「SKU多、相似性高、数量大、更换频率高」为什么特指女装，而不是服装。。各位男装用户，自己在电商平台啥地位，心里没数吗 😂，我心里的价值排序：女...

当 Claude 写了 Claude Code 约 90% 的代码后，团队如何重新设计代码评审？ Anthropic 没有取消代码评审，是把 “人读代码” 这个动作大部分交给了机器，把稀缺的人类注...

中国的开源模型，还能给美国人用吗？商务部科技部发布第48号联合公告，拟将人工智能、生物医药、光伏三大领域共40项技术增列进《中国禁止出口限制出口技术目录》，并在目录正式生效前，立即对相关技术出口...

pstack 作者公开她的 “工程原则” 设计思路「Clean Code」作者 Uncle Bob 是传统软件工程方法论的宗师，他最近看到了 pstack，认为本质上是把经典工程智慧「最小改动、先...

会飞的汽车？太未来了！ Roadster 真的把 Tesla 和 SpaceX 联动了，搭载 SpaceX 的冷气推进系统。那么。。刹车似乎确实没那么必要了，遥遥领先，还是遥遥领先！

Anthropic 宣布新一代反蒸馏防御措施攻击者从 Claude 平台上窃取的推理 token 量下降了 90%–99%，智谱 GLM-5.3 模型训练再次被重点点名、月之暗面 Kimi 用户请...

密歇根大学最新 AI 编程课「Applied Agentic Software Engineering」第 14 讲「Subagents」讲义刚刚公开，围绕：为什么需要 subagents、机制是...

Google 官方「5天 AI Agents 课程」第 5 份白皮书「Spec-Driven Production Grade Development in the Age of Vibe Cod...

Grok Bot、Muse 让人对个人智能体又多了一些期待。但在个人使用场景里，除了让 Agent 持续运行的电脑环境，支付也是绕不过去的环节。比如出差旅行，我希望它根据行程帮我选好航班、找好会场...

突然想到，Agents 运行过程中，是不是也可以用这块副屏和遥控器来玩游戏啊！现在我使用一些老电视剧来打发 Agents 运行中时间的，不过都快刷烂了，实在找不到新剧。如果有一些小游戏，或者自...

Modal ARR 过 $1B、D 轮融资 $750M、投后估值 $15.75B 恭喜 @modal 团队！再重温一下 Modal 团队发布的「GPU 术语手册」，对整个 GPU 技术栈的讲述真...

给 /grill-me Skill 加一个 GRILL.md 配置文件 Matt 详细讲述了它的三个作用 1. 用配置实现组合，取代命令变体。有了 GRILL.md 之后，/grill-with...

这个给 Agent 设计的桌面副屏 + 手持遥控器可以啊！突然有了 Agent 兵团总指挥部和模拟游戏的感觉。 · 3.96 英寸 LCD 副屏集中显示所有 Agent 会话状态 · 手持器上的...

模型创造力排行 GPT-6 Astra 排第一、Claude Opus 5.5 第八？而且最强模型还是远低于人类？ @Kombaico 发布了 Design Creativity Bench：...

Grok Bot 回答更有参考价值。。手残打错字了 🤭