AsyncTalk

Latest Episodes:

MCP 0728：让 MCP 再次伟大 Oct 16, 2026

Show notes

很多人觉得 Skills 火了之后 MCP 就凉了。但 MCP 0728 这次更新，我愿意叫它「MCP 2」�
� MCP 1 的老毛病：有状态
远程连接要一直维持 session，扩缩容和负载均衡都很难做。一发新版本，用户聊着聊着就断了，只能重开 session。
� Skills + CLI 真的完美吗？
· CLI 靠单词拼接，表达力不如自然语言
· 必须有机器来跑（本地或云端 VM），成本高
· CLI 是黑盒，npm 那种供应链攻击蔓延到 Skills 只是早晚的事
· 一个命令是读还是写，全靠开发者自觉遵守语义
MCP 0728 改了什么
它去掉了 session，变成像 HTTP 一样的无状态接口，每次请求带上 header 就行。
→ 扩容和 load balance 又能按熟悉的方式做了
→ 每个 tool 都分只读和写，权限好管，也方便审计
→ 跑在远程 server 上，不碰你的电脑，更安全
� 实战演示
我用 ShellTime 和 Rawback 的 MCP server 演示：只读 tool 一键「Always allow」，写和删除单独授权；再让 Claude 直接分析我最近的 AI 使用数据。
章节
00:00 开场：MCP 2 来了
00:23 MCP：AI 连接外部世界的入口
01:11 一个比喻：脑子、手、技能和冰箱
02:06 MCP 的老问题：有状态
03:23 另一条路：Skills + CLI
04:16 Skills 真的完美吗？
07:47 回到主题：MCP 0728
09:12 实战：ShellTime MCP server
11:20 MCP vs Skills
11:38 你怎么看？
有自己产品的朋友，真心建议自己实现一个 MCP server 试试～
你觉得 MCP 0728 能 make MCP great again 吗？你站 MCP 还是 Skills？评论区聊聊 �

#MCP #AI #AIAgent #ClaudeCode #Claude #Skills #大模型 #人工智能 #程序员 #技术分享 #后端开发 #AsyncTalk

Jev: 只回答是或否的模型，为什么火了？ Oct 08, 2026

Show notes

这期 AsyncTalk 聊一个前几天突然火起来的模型：TypeSafe 发布的 Jev。
它不聊天、不写长文，只回答简单的问题：是或否、多选一、打分。端到端 70–500 毫秒返回，输入每百万 token 0.042 美元，输出免费。
我们从程序员最熟悉的 if 讲起：
· 让大模型做一个「是或否」的判断，要定输出结构、解析 JSON、按 token 计费，又慢又贵
· 纯代码的 if 又理解不了用户意图
· Jev 正好卡在两者中间
然后聊它在 AI Agent 里的用法：意图识别、「这是不是 TypeScript 文件」这类判断、每一步的快速校验。现场实测了几个问题（苹果能不能吃、该不该买沪深 300、今天要不要出去玩）。最后说说它的局限：快、便宜，但不一定更准，同样会有幻觉。
你怎么看这种「快速决断」的模型？欢迎在评论区聊聊。
⏱ 章节
00:00 开场：一个“没什么智力”的模型为什么火了？
00:19 Jev 是什么
01:05 程序员最重要的语句：if
01:22 让大模型做 if，贵在哪？
02:09 Jev 的位置
02:38 Agent 里的大量 if
03:38 实测 Jev
04:41 它足够可靠吗？
05:21 试一试 & 你怎么看
� 数据来源
片中延迟、成本、准确率数据来自 TypeSafe 公布的 System One 基准，引自：
· DataCamp：https://www.datacamp.com/blog/system-one-models-jev
· RuntimeWire：https://runtimewire.com/article/typesafe-jev-system-one-ai-model-early-access
· NYU Shanghai RITS：https://rits.shanghai.nyu.edu/ai/typesafe-jev-system-one-model
� AsyncTalk · 主播 AnnatarHe
#Jev #TypeSafe #AI #大模型 #AIAgent #程序员 #编程 #人工智能 #AI工具 #科技播客 #AsyncTalk

TypeScript 7：十倍性能的升级之外，为什么选 Go？ Sep 15, 2026

Show notes

TypeScript 7 终于来了。

这次最直观的变化不是新语法，而是 Go 重写之后带来的性能提升：VS Code 的类型检查从 78 秒降到 7.5 秒；我自己的一个 58 万行 TypeScript 项目，也从大约 14 秒降到了 3 秒左右。

但这期我更想聊的是另一个问题：

为什么 TypeScript 选择了 Go，而不是 Rust？

从 TS7 的实际升级体验出发，聊聊大型项目里的类型检查和编辑器性能，也聊聊 Go、Rust 在性能、复杂度、可读性和长期维护上的取舍。

我自己写了七八年 Go，也实际用 Rust 写过一些项目。相比“Rust 重写一切”，我越来越觉得：工程技术选型追求的从来不只是极致性能，而是在性能、开发效率和可维护性之间找到平衡。

所以，TypeScript 团队这次选 Go，你怎么看？

#TypeScript #TypeScript7 #Go语言 #Rust #前端开发 #编程语言 #技术选型 #软件工程 #程序员 #开发者 #Web开发 #AsyncTalk

64个Claude: Bun 的 11 天重写 Sep 02, 2026

Show notes

Bun 1.4 发布了。作者 Jarred 说这是"变化最小的一个版本"——对用户来说确实是，但整个 runtime 底层已经从 Zig 换成了 Rust。
11 天，峰值 64 个 Claude 同时在同一个仓库里干活，53 万行 Zig 全量翻译成 Rust，API 账单约 16.5 万美金。放在 AI 之前，这种项目只有一个结局：不做。
这期挑了原文里我觉得最有意思的几点聊：
· 为什么非要换 Rust —— JavaScriptCore 是带 GC 的，Zig 是手动管内存，两个混在一起，光 use-after-free 和内存泄漏就够喝一壶
· 对抗性 review —— 写代码的 Claude 和挑刺的 Claude 上下文完全隔离，reviewer 只拿到 diff，并且被要求"默认这段代码是错的"
· 翻车现场 —— 64 个实例互相 git stash、把编译不过的函数偷偷 stub 掉、写注释写到把磁盘 IOPS 打满
· 编译器报错反而是 AI 最好的反馈信号，一万六千个 error 就是一个天然的任务队列
· 最关键的一条：AI 犯错的时候，要改的不是那段代码，是你的 rules
以及所有人都想问的那个问题：我自己的项目能不能也这么重写？
我的答案是别。Bun 有百万级断言的测试用例兜底，一行写错立刻有几十个 case 报警；而我们写的业务代码，覆盖率能到 50% 都算凤毛麟角，很多逻辑你去问产品经理，他自己都说不清预期是什么。没有验证手段的重写，跟 100 倍杠杆做空纳指有什么区别。
AI 改变的是重写这件事的成本结构，不是正确性的判定标准。
原文很值得自己读一遍，对你搭自己的 harness 帮助很大。有不同看法欢迎评论区聊。
#Bun # Rust #AI编程 #Claude #ClaudeCode #Agent #前端 #JavaScript #Nodejs #程序员 #AsyncTalk

Axiom 日志：哪 26 个人拿走了我的电影票？ Aug 31, 2026

Show notes

最近 Harness 成了 AI 圈的热门话题，但当我们讨论 AI Agent 如何真正完成任务时，我觉得有一个经常被忽略的问题：
AI 怎么知道生产环境到底发生了什么？
#Axiom #日志 #AI编程 #MCP #Harness #DeepSeekHarness #ClaudeCode #CodingAgent #AI智能体 #可观测性 #DevOps #程序员 #asynctalk
这期我想聊聊我最近一直在用的日志服务 Axiom。
从传统的日志查询，到 Dataset、Dashboard 和 Monitor，Axiom 本身已经是一个相当不错的日志平台。但真正让我觉得它有意思的，是它提供的 MCP Server。
当日志系统接入 MCP 之后，Coding Agent 就不只是写代码了。它可以直接分析生产日志、查找错误、定位问题，甚至结合代码自动修复 Bug、补充日志。
进一步想象一下：
让 Agent 定期检查生产环境的日志 → 发现异常 → 分析代码 → 尝试修复 → 提交 PR。
日志不再只是给开发者 Debug 的工具，而开始成为 AI Agent 了解真实生产环境的一扇窗口。
视频里也简单聊到了我最近在关注的 Superlog，以及我对「Harness + MCP + 可观测性」这条路线的一些想法。
如果你有更好的日志管理方案，或者已经在尝试让 AI Agent 自动分析生产环境，欢迎一起讨论。

YoooClaw：给 AI 一具身体 Jul 31, 2026

Show notes

当 AI Agent 不再只存在于聊天框里，它会变成什么？

本期体验一款很有意思的软硬件结合产品——YoooClaw。它像一个吸附在手机背面的“小型 AI 硬件”，可以通过语音直接向 OpenClaw 下达任务，还能读取并总结手机通知、通过 RGB 灯带反馈重要消息，以及录制对话、识别不同发言者并生成会议总结。

它还支持切换 DeepSeek、GLM 5.2 等不同模型。但比具体功能更值得讨论的，是 YoooClaw 所代表的产品方向：

模型可以替换，App 和 Agent 框架也可以替换，但持续积累的个人上下文、稳定存在的硬件入口，以及从信息感知到任务执行的完整闭环，可能才是 AI 时代真正的护城河。

某种意义上，YoooClaw 就是在尝试给 OpenClaw 一具真实的“身体”。

当然，目前的产品仍然存在不少问题：任务结果展示不够完善、系统推送和定时任务尚未形成完整闭环，位置等上下文也没有得到充分利用。更重要的是，当一个设备能够读取通知、录制音频并长期积累个人信息时，隐私和数据安全将成为无法回避的问题。

这期视频会聊到：

YoooClaw 如何通过硬件与 OpenClaw 交互
• AI 通知总结与 Apple Intelligence 的体验差异
• 录音、发言人识别和会议总结
• 为什么持续积累的 Context 如此重要
• 硬件入口为什么可能成为 AI 产品的商业护城河
• YoooClaw 当前的产品缺陷与隐私风险

你认为这种软硬件结合的 AI Agent，会成为下一代个人 AI 助手的主流形态吗？

AI Agent 必备的 ChatSDK Jul 16, 2026

Show notes

你肯定见过 OpenClaw 这种 AI Agent——挂在服务器上,你在聊天框 @ 它一句,它就自己动手把活办了:查资料、改文件、跑脚本……不只是会聊天,而是真能动手干活,也就是现在常说的 agentic。那要自己做一个这样的 agent,是不是得把每个平台的 API 和 webhook 都单独研究一遍、写一堆胶水代码?
这期聊 Vercel 开源的 ChatSDK——可以把它理解成「AI Agent 的对话接入层」。它把 Slack、Microsoft Teams、Discord、Telegram、GitHub、WhatsApp… 十多个平台的机器人逻辑统一了起来:你只写一套 TypeScript 代码,在一个 onNewMention 回调里 subscribe 再 post,你的 agent 就能在所有平台上跑起来。
视频里会带你看:
· ChatSDK 的三个核心概念——Chat、Adapter、State
· 怎么用一个 callback 统一处理各平台的 webhook,把"接入层"这件最烦的事交出去
· 从"在 GitHub 里 @ 一下机器人帮你改个颜色"出发,一路扩展到 Slack 等更多平台
· 内置 AI streaming、和 AI SDK 打通,接你自己的 agent 逻辑很顺
· 聊天状态怎么持久化(memory / Redis);社区还有飞书等国内平台的 adapter
一句话:在 ChatSDK 的帮助下,"造一个属于自己的 OpenClaw、把你的 AI Agent 放进各个聊天软件"已经变成挺简单的一件事了。
你会想拿它做个什么样的 agent?或者你已经在搭什么有意思的功能了?评论区聊聊 �
—— AsyncTalk 异步聊技术,既有趣又有料,我们下期见
#ChatSDK #AIAgent #AI机器人 #Vercel #OpenClaw #TypeScript #asynctalk

react-call:弹框还能 await Jul 03, 2026

Show notes

有没有遇到过这种场景:一个删除按钮,点下去得先弹个「确认删除吗?」,用户点确定才真的删。
浏览器自带的 window.confirm 是能用,但又丑、又几乎不能定制——位置、颜色、甚至标题都改不了。于是你只好自己写组件、用 React Portal 挂载、再手动管理 DOM 的显隐和生命周期,挺折腾的。
这期聊聊 react-call 这个小而美的库。核心思路一句话:把你自定义的 React 组件变成「可以 await 的函数」。用 createCallable 包一层,就能在调用方直接 await xxx.call(...),像调用异步函数一样拿到用户的操作结果。
视频里会过一遍:
· 从 window.confirm 的痛点切入,为什么手写 Portal 很烦
· createCallable 的基本用法(call / Title / action 几个字段)
· 用 bottom sheet 写的实战例子
· 支持同时弹出多个实例(比如一连串 Toast)
· 和 react-query mutation 的配合:接口失败时弹框依然保留
· 自带 skills,对 AI 编程也很友好
你平时都怎么处理这类弹框、或者异步交互逻辑?评论区聊聊~

#React #前端开发 #TypeScript #Web开发 #编程 #react-call #asynctalk

GraphQL:治好前后端联调内耗 Jun 24, 2026

Show notes

前后端怎么交互?大多数人第一反应都是 REST + HTTP。但接口越写越多、前后端对同一个字段理解对不齐、类型全靠猜——这些坑你大概率都踩过。
这期我们聊 GraphQL:一门出道十多年、却始终没真正普及的技术,为什么在 AI 时代反而值得重新认识。我们从 REST 的痛点出发,讲清楚 GraphQL 的强类型 schema 如何统一前后端协作、如何让缓存更聪明,以及为什么强类型对 AI 写代码是一个巨大的红利。
当然,GraphQL 不是银弹。我们也会聊它真实的坑:n+1 问题、缓存思维的转变、HTTP 状态码、以及什么项目压根不该上 GraphQL。
如果你在做一个中大型项目,或者想让 AI 帮你写出更靠谱的代码,这期也许能给你一些新思路。欢迎在评论区聊聊你对 GraphQL 的看法,记得关注 AsyncTalk 异步聊技术。

#GraphQL #api #全栈开发 #后端开发 #AI #程序员 #asynctalk

前端代码也能「预制」了 Jun 18, 2026

Show notes

Swagger + Hey API 自动生成请求代码,告别手写 interface
在前后端协作中,RESTful 接口缺乏强类型约束,常常带来一系列联调成本:前端遇到read from undefined,排查后发现是后端返回的数据结构缺失;约定好的字段类型被悄然变更(例如 int32 改为 int64 纳秒);字段命名、大小写、enum 取值、是否可选等细节需要反复确认,既影响效率,也容易引入缺陷。

GraphQL、tRPC 能够从根本上解决这类问题,但对既有项目而言改造成本接近重写,新项目也存在不小的学习成本,在实际工程中往往难以落地。

本期介绍一种更具可行性的渐进式方案:由后端提供规范的swagger.json,前端借助 Hey API 根据该契约自动生成请求代码。生成结果不仅覆盖请求发送,还可包含 response body 校验(可选启用 zod)、react-query 的查询代码与 key,并在编译期完成类型检查,从而尽早暴露问题、清晰划分前后端的责任边界。

该方案的另一项优势在于对 AI 与 CI 的友好度:数据结构固定后,AI 无需再推测接口的返回结构与路径细节,生成代码更准确;契约稳定也使 CI 中的类型检查、lint 与测试更加可靠。

它对后端实现与整体架构几乎没有侵入——开发方式仅从调用手写的 HTTP 接口,转为调用 Hey API 生成的接口。需要强调的前提是:后端提供的 swagger 必须准确,这仍依赖团队之间充分而严谨的沟通。

欢迎在评论区分享你的团队是如何管理前后端接口契约的。

#前端开发 #TypeScript #Swagger #HeyAPI #前后端联调 #AI编程 #asynctalk

Our TOPPODCAST Picks

Follow Us

Stay Connected

Related Podcasts

Links

Stay Connected