Now vibe coding, so learning hammer FE ?
《OpenAI Agents SDK:轻量级多智能体工作流框架》
标签:#AI #多智能体 #Python #OpenAI #MCP #智能体工作流 #LLM #实时语音 #沙箱环境
总结:
OpenAI Agents SDK 是一个轻量但功能强大的 Python 框架,用于构建多智能体工作流。它支持 OpenAI 的 Responses 和 Chat Completions API,同时兼容 100 多种其他 LLM,具有供应商无关性。框架围绕"智能体"这一核心概念展开,每个智能体都配备指令、工具、护栏和交接机制,让复杂任务可以像搭积木一样拆解协作。
文章要点:
- 智能体是核心乐高积木:每个智能体都自带"说明书"(指令)、"工具箱"(函数/MCP/托管工具)和"安全护栏"(输入输出校验),还能互相"交接"任务,像团队协作一样分工处理复杂流程
- 沙箱智能体让AI真正"动手干活":0.14.0 版本新增的 Sandbox Agent 能在容器环境里操作文件系统、运行命令、打补丁,适合需要长时间执行且要保留工作状态的"重体力"任务
- 人在回路,安全可控:内置了人类介入机制,在关键节点可以暂停流程等人来确认,避免AI"自作主张"搞出大新闻
- 全链路可观测:自带 Tracing 追踪系统,能可视化查看每个智能体的思考过程、工具调用耗时和 Token 消耗,方便调试和优化
- 不挑模型,兼容百家:虽然是 OpenAI 出品,但设计上保持中立,支持接入 100+ 种 LLM,包括通过 LiteLLM 等适配层接入国产模型
- 实时语音也能玩:支持用
文章URL:https://github.com/openai/openai-agents-python
标签:#AI #多智能体 #Python #OpenAI #MCP #智能体工作流 #LLM #实时语音 #沙箱环境
总结:
OpenAI Agents SDK 是一个轻量但功能强大的 Python 框架,用于构建多智能体工作流。它支持 OpenAI 的 Responses 和 Chat Completions API,同时兼容 100 多种其他 LLM,具有供应商无关性。框架围绕"智能体"这一核心概念展开,每个智能体都配备指令、工具、护栏和交接机制,让复杂任务可以像搭积木一样拆解协作。
文章要点:
- 智能体是核心乐高积木:每个智能体都自带"说明书"(指令)、"工具箱"(函数/MCP/托管工具)和"安全护栏"(输入输出校验),还能互相"交接"任务,像团队协作一样分工处理复杂流程
- 沙箱智能体让AI真正"动手干活":0.14.0 版本新增的 Sandbox Agent 能在容器环境里操作文件系统、运行命令、打补丁,适合需要长时间执行且要保留工作状态的"重体力"任务
- 人在回路,安全可控:内置了人类介入机制,在关键节点可以暂停流程等人来确认,避免AI"自作主张"搞出大新闻
- 全链路可观测:自带 Tracing 追踪系统,能可视化查看每个智能体的思考过程、工具调用耗时和 Token 消耗,方便调试和优化
- 不挑模型,兼容百家:虽然是 OpenAI 出品,但设计上保持中立,支持接入 100+ 种 LLM,包括通过 LiteLLM 等适配层接入国产模型
- 实时语音也能玩:支持用
gpt-realtime-1.5 构建语音智能体,把实时语音能力也纳入多智能体协作体系文章URL:https://github.com/openai/openai-agents-python
《基于Andrej Karpathy观察的Claude Code行为优化指南》
标签:#AI辅助编程 #ClaudeCode #LLM最佳实践 #代码质量
总结:该项目将Andrej Karpathy对LLM编程缺陷的观察转化为可落地的CLAUDE.md规范文件,通过"编码前思考、极简优先、精准修改、目标驱动"四大原则,系统性解决AI助手常见的过度假设、过度工程化和无关修改等问题,帮助开发者获得更精准、简洁、可控的AI编程辅助体验。
文章要点:
- 问题诊断:LLM常犯的错误包括擅自假设却不验证、过度复杂化代码、擅自修改无关代码等,Karpathy一针见血地指出了这些痛点
- 编码前思考原则:不确定时要主动提问而非猜测,有歧义时呈现多种解读,该拒绝时要敢于说"这样更简单"
- 极简优先原则:只做被明确要求的功能,不为单用场景造抽象,不把200行代码写成50行就算过关
- 精准修改原则:只碰该碰的代码,不动"看起来不顺眼"的邻居代码,自己的烂摊子自己收拾,但别碰别人留下的
- 目标驱动原则:把"加个验证"改成"写测试让非法输入失败,再让它通过",给AI明确的验收标准,它会自己循环到达标
- 使用方式:支持Claude Code插件一键安装,或下载CLAUDE.md文件到项目根目录,Cursor用户也有对应规则文件可用
- 取舍提醒:这套规范偏向谨慎而非速度,简单改错别字不必上全套,但复杂任务能帮你避开返工噩梦
文章URL:https://github.com/forrestchang/andrej-karpathy-skills
标签:#AI辅助编程 #ClaudeCode #LLM最佳实践 #代码质量
总结:该项目将Andrej Karpathy对LLM编程缺陷的观察转化为可落地的CLAUDE.md规范文件,通过"编码前思考、极简优先、精准修改、目标驱动"四大原则,系统性解决AI助手常见的过度假设、过度工程化和无关修改等问题,帮助开发者获得更精准、简洁、可控的AI编程辅助体验。
文章要点:
- 问题诊断:LLM常犯的错误包括擅自假设却不验证、过度复杂化代码、擅自修改无关代码等,Karpathy一针见血地指出了这些痛点
- 编码前思考原则:不确定时要主动提问而非猜测,有歧义时呈现多种解读,该拒绝时要敢于说"这样更简单"
- 极简优先原则:只做被明确要求的功能,不为单用场景造抽象,不把200行代码写成50行就算过关
- 精准修改原则:只碰该碰的代码,不动"看起来不顺眼"的邻居代码,自己的烂摊子自己收拾,但别碰别人留下的
- 目标驱动原则:把"加个验证"改成"写测试让非法输入失败,再让它通过",给AI明确的验收标准,它会自己循环到达标
- 使用方式:支持Claude Code插件一键安装,或下载CLAUDE.md文件到项目根目录,Cursor用户也有对应规则文件可用
- 取舍提醒:这套规范偏向谨慎而非速度,简单改错别字不必上全套,但复杂任务能帮你避开返工噩梦
文章URL:https://github.com/forrestchang/andrej-karpathy-skills
《Claude架构图生成器:AI一键绘制专业系统架构图》
标签:#AI工具 #Claude_Skill #架构可视化 #开发效率 #系统架构图
总结:
这是一款专为Claude AI设计的Skill工具,让用户只需用自然语言描述系统架构,即可生成精美的暗色系专业架构图。输出为独立的HTML/SVG文件,无需任何设计技能或额外软件,适合快速迭代和团队协作分享。
文章要点:
- 零门槛使用:不需要设计基础,用大白话描述系统组件和连接关系,Claude就能帮你画出专业级架构图
- 多种输入方式:可以让AI分析代码库自动生成描述,也可以自己手写组件列表,还能直接问Claude要典型架构模板
- 精美视觉风格:采用暗色主题(Slate-950背景),组件按类型着色(前端青色、后端翠绿、数据库紫色、云服务琥珀色),自带网格底纹和JetBrains Mono字体
- 独立文件输出:生成单个HTML文件,内嵌CSS和SVG,任何浏览器都能直接打开,方便分享、打印或嵌入文档
- 实时迭代优化:生成后可以继续在对话中要求修改,比如"加上Redis缓存"或"调整布局",Claude会即时更新图表
- 多平台安装:支持Claude.ai网页版(Pro/Max/Team/Enterprise)、Claude Code CLI、以及Projects知识库三种方式
- 丰富示例覆盖:内置Web应用(React+Node+PostgreSQL)、AWS无服务器(Lambda+API Gateway)、微服务(K8s+多语言服务)等典型场景模板
文章URL:https://github.com/Cocoon-AI/architecture-diagram-generator
标签:#AI工具 #Claude_Skill #架构可视化 #开发效率 #系统架构图
总结:
这是一款专为Claude AI设计的Skill工具,让用户只需用自然语言描述系统架构,即可生成精美的暗色系专业架构图。输出为独立的HTML/SVG文件,无需任何设计技能或额外软件,适合快速迭代和团队协作分享。
文章要点:
- 零门槛使用:不需要设计基础,用大白话描述系统组件和连接关系,Claude就能帮你画出专业级架构图
- 多种输入方式:可以让AI分析代码库自动生成描述,也可以自己手写组件列表,还能直接问Claude要典型架构模板
- 精美视觉风格:采用暗色主题(Slate-950背景),组件按类型着色(前端青色、后端翠绿、数据库紫色、云服务琥珀色),自带网格底纹和JetBrains Mono字体
- 独立文件输出:生成单个HTML文件,内嵌CSS和SVG,任何浏览器都能直接打开,方便分享、打印或嵌入文档
- 实时迭代优化:生成后可以继续在对话中要求修改,比如"加上Redis缓存"或"调整布局",Claude会即时更新图表
- 多平台安装:支持Claude.ai网页版(Pro/Max/Team/Enterprise)、Claude Code CLI、以及Projects知识库三种方式
- 丰富示例覆盖:内置Web应用(React+Node+PostgreSQL)、AWS无服务器(Lambda+API Gateway)、微服务(K8s+多语言服务)等典型场景模板
文章URL:https://github.com/Cocoon-AI/architecture-diagram-generator
《在本地终端预览OpenGraph卡片》
标签:#前端 #OpenGraph #CLI工具 #Zig #Kitty图形协议 #开发工具
总结:
作者为解决OpenGraph调试痛点,开发了CLI工具
文章要点:
- 传统OG调试流程繁琐:需要部署到公网或使用隧道工具,且Facebook等平台的调试器缓存机制会导致反复迭代困难
-
- 终端图片渲染基于Kitty图形协议,兼容Ghostty、iTerm2、WezTerm等主流终端,不支持的终端会自动降级为文本输出
- 工具内部使用Zig的
- 提供四种输出模式:OpenGraph预览(默认)、Twitter Card预览、表格视图、JSON格式,后者支持管道操作(如配合jq使用)
- 具备校验功能:当缺少必需的OG字段(title、type、image、url)时会输出错误并返回非零退出码,适合集成到CI流程作为布局模板检查
- 安装方式灵活:支持预编译二进制、源码编译(Zig 0.15+)和mise工具管理
文章URL:https://simonhartcher.com/posts/2026-04-15-testing-opengraph-on-localhost-from-the-cli/
标签:#前端 #OpenGraph #CLI工具 #Zig #Kitty图形协议 #开发工具
总结:
作者为解决OpenGraph调试痛点,开发了CLI工具
og-check,可直接在终端内渲染本地开发环境的OG卡片预览,无需部署到公网或使用隧道服务。工具基于Zig编写,支持Kitty图形协议在终端内显示图片,并提供OpenGraph、Twitter Card、表格和JSON四种输出格式,同时可作为CI检查工具确保OG标签完整性。文章要点:
- 传统OG调试流程繁琐:需要部署到公网或使用隧道工具,且Facebook等平台的调试器缓存机制会导致反复迭代困难
-
og-check支持在本地终端直接预览OG卡片,包含图片渲染,将反馈周期从分钟级缩短到秒级- 终端图片渲染基于Kitty图形协议,兼容Ghostty、iTerm2、WezTerm等主流终端,不支持的终端会自动降级为文本输出
- 工具内部使用Zig的
std.http.Client抓取页面,解析meta标签并按命名空间分类(og:、twitter:等),通过zigdown渲染Markdown到终端- 提供四种输出模式:OpenGraph预览(默认)、Twitter Card预览、表格视图、JSON格式,后者支持管道操作(如配合jq使用)
- 具备校验功能:当缺少必需的OG字段(title、type、image、url)时会输出错误并返回非零退出码,适合集成到CI流程作为布局模板检查
- 安装方式灵活:支持预编译二进制、源码编译(Zig 0.15+)和mise工具管理
文章URL:https://simonhartcher.com/posts/2026-04-15-testing-opengraph-on-localhost-from-the-cli/
《用TanStack_Start构建博客(上篇)》
标签:#前端 #TanStack_Start #TanStack_Router #Server_Functions #静态预渲染 #Markdown博客 #代码高亮
总结:
本文通过实战案例演示如何使用 TanStack Start 框架构建一个 Markdown 博客系统。文章重点介绍了 Server Functions 解决同构加载器无法访问文件系统的问题、动态路由参数处理、以及使用 markdown-it 和 Shiki 实现带行号的高亮代码块,为开发者提供了完整的技术实现路径。
文章要点:
- TanStack Start 是基于 TanStack Router 的轻量级服务端框架,支持 SSR、API 端点和 Server Functions
- 使用
- Server Functions 是同构应用的关键——无论 loader 在服务端还是客户端运行,都能保证文件读取逻辑始终在服务端执行
- 动态路由通过
- 使用 markdown-it + Shiki 实现代码高亮,通过自定义 transformer 支持
- 文章预告下篇将介绍静态生成和部署策略
文章URL:https://frontendmasters.com/blog/building-a-blog-in-tanstack-part-1-of-2/
标签:#前端 #TanStack_Start #TanStack_Router #Server_Functions #静态预渲染 #Markdown博客 #代码高亮
总结:
本文通过实战案例演示如何使用 TanStack Start 框架构建一个 Markdown 博客系统。文章重点介绍了 Server Functions 解决同构加载器无法访问文件系统的问题、动态路由参数处理、以及使用 markdown-it 和 Shiki 实现带行号的高亮代码块,为开发者提供了完整的技术实现路径。
文章要点:
- TanStack Start 是基于 TanStack Router 的轻量级服务端框架,支持 SSR、API 端点和 Server Functions
- 使用
import.meta.glob 动态扫描 Markdown 文件,配合 gray-matter 解析文章元数据- Server Functions 是同构应用的关键——无论 loader 在服务端还是客户端运行,都能保证文件读取逻辑始终在服务端执行
- 动态路由通过
$slug.tsx 文件命名实现,配合 createFileRoute 和 head 函数设置页面标题- 使用 markdown-it + Shiki 实现代码高亮,通过自定义 transformer 支持
line-numbers 语法标记,结合 CSS counter 渲染行号- 文章预告下篇将介绍静态生成和部署策略
文章URL:https://frontendmasters.com/blog/building-a-blog-in-tanstack-part-1-of-2/
《垂直代码库:告别按类型分层,拥抱按业务域组织》
标签:#前端 #代码组织 #架构设计 #Monorepo #React #软件工程
总结:
本文主张前端代码库应从"水平分层"(按 components/hooks/utils 技术类型划分)转向"垂直切片"(按业务域/功能域组织)。作者以 Sentry 代码库十年演进为例,指出水平分层会导致代码分散、认知负荷高、耦合混乱;而垂直组织将同一业务域的组件、工具、类型内聚到一起,配合 Monorepo 的显式边界(exports/eslint-plugin-boundaries),能显著提升可维护性。虽然确定正确的垂直划分需要更多团队沟通,但这是支撑代码库长期演进的必要投资。
文章要点:
- 水平分层的隐患:把代码按 components / hooks / utils / types 分类虽然上手简单,但随着项目膨胀,同一业务逻辑会被拆得七零八落——比如 PageFilters 的组件、类型、工具函数散落在三个目录,改一个小需求要跳来跳去, cognitive load 直接拉满
- 垂直切片的核心思想:不按"技术类型"而按"业务域"分组,把同一个功能域(如 dashboard、profiling、billing)相关的组件、Hook、工具、类型全部收进一个目录;就像当年我们把 HTML/CSS/JS 从三层文件合并成组件一样,这次是更高维度的"关注点内聚"
- 与团队结构天然对齐:现代产品团队通常是端到端的功能团队(dashboard 团队、replay 团队),垂直代码结构让 CODEOWNERS 和包边界直接对应团队职责,谁负责什么一目了然
- 解决跨域复用焦虑:不是所有代码都严格属于某个页面,像 PageFilters 这种被多页面使用的通用能力,完全可以作为独立垂直域存在;关键是按"逻辑关联"而非"物理位置"来划分
- 用边界守护架构:垂直化后还需降低耦合,推荐通过 Monorepo + package.json#exports 显式暴露公共 API,或借助 eslint-plugin-boundaries 禁止深路径导入,把"私有实现"真正保护起来
- 没有银弹,但值得投入:确定合理的垂直域确实比"丢进 utils"更难,也可能出现不同团队重复造轮子;但作者认为这恰恰促进了团队沟通,而沟通本就是软件工程最难也最重要的部分
文章URL:
https://tkdodo.eu/blog/the-vertical-codebase
标签:#前端 #代码组织 #架构设计 #Monorepo #React #软件工程
总结:
本文主张前端代码库应从"水平分层"(按 components/hooks/utils 技术类型划分)转向"垂直切片"(按业务域/功能域组织)。作者以 Sentry 代码库十年演进为例,指出水平分层会导致代码分散、认知负荷高、耦合混乱;而垂直组织将同一业务域的组件、工具、类型内聚到一起,配合 Monorepo 的显式边界(exports/eslint-plugin-boundaries),能显著提升可维护性。虽然确定正确的垂直划分需要更多团队沟通,但这是支撑代码库长期演进的必要投资。
文章要点:
- 水平分层的隐患:把代码按 components / hooks / utils / types 分类虽然上手简单,但随着项目膨胀,同一业务逻辑会被拆得七零八落——比如 PageFilters 的组件、类型、工具函数散落在三个目录,改一个小需求要跳来跳去, cognitive load 直接拉满
- 垂直切片的核心思想:不按"技术类型"而按"业务域"分组,把同一个功能域(如 dashboard、profiling、billing)相关的组件、Hook、工具、类型全部收进一个目录;就像当年我们把 HTML/CSS/JS 从三层文件合并成组件一样,这次是更高维度的"关注点内聚"
- 与团队结构天然对齐:现代产品团队通常是端到端的功能团队(dashboard 团队、replay 团队),垂直代码结构让 CODEOWNERS 和包边界直接对应团队职责,谁负责什么一目了然
- 解决跨域复用焦虑:不是所有代码都严格属于某个页面,像 PageFilters 这种被多页面使用的通用能力,完全可以作为独立垂直域存在;关键是按"逻辑关联"而非"物理位置"来划分
- 用边界守护架构:垂直化后还需降低耦合,推荐通过 Monorepo + package.json#exports 显式暴露公共 API,或借助 eslint-plugin-boundaries 禁止深路径导入,把"私有实现"真正保护起来
- 没有银弹,但值得投入:确定合理的垂直域确实比"丢进 utils"更难,也可能出现不同团队重复造轮子;但作者认为这恰恰促进了团队沟通,而沟通本就是软件工程最难也最重要的部分
文章URL:
https://tkdodo.eu/blog/the-vertical-codebase
Syncpack 是一个专门用于大型 JavaScript Monorepo 的命令行工具,用于强制保持跨包依赖版本一致性,支持自动检测、修复和格式化 package.json 文件。
https://syncpack.dev/
https://syncpack.dev/
《嵌套Promise的实际用途》
标签:#JavaScript #Promise #并发控制 #RWLock #函数式编程
总结:
文章探讨了JavaScript中Promise自动扁平化设计的利弊。作者回顾了Promise/A+规范制定时关于是否引入Monad和Functor概念的争论,并通过实现读者-写者锁(RWLock)的实际案例,展示了嵌套Promise在并发控制中的独特价值——它能让一个异步函数调用另一个异步函数,却不阻塞等待内层函数完成,从而实现精细的并发管理。
文章要点:
- Promise的
- 函数式编程社区曾希望Promise能区分
- 作者在开发EscoDB时遇到了一个真实场景:实现读者-写者锁(RWLock)需要协调多个读操作并发执行、写操作独占执行
- 通过显式返回
- 嵌套Promise代表"一个异步函数调用另一个异步函数,但不等待其完成"的语义,在主动管理并发控制时非常有用
- Promise扁平化本质上是"时间上的连接"(强制顺序执行),而嵌套Promise则保留了并行调度的可能性
文章URL:https://blog.jcoglan.com/2026/03/23/uses-for-nested-promises/
标签:#JavaScript #Promise #并发控制 #RWLock #函数式编程
总结:
文章探讨了JavaScript中Promise自动扁平化设计的利弊。作者回顾了Promise/A+规范制定时关于是否引入Monad和Functor概念的争论,并通过实现读者-写者锁(RWLock)的实际案例,展示了嵌套Promise在并发控制中的独特价值——它能让一个异步函数调用另一个异步函数,却不阻塞等待内层函数完成,从而实现精细的并发管理。
文章要点:
- Promise的
then()方法同时承担了Functor的map和Monad的flatMap功能,会自动扁平化任意层级的嵌套Promise- 函数式编程社区曾希望Promise能区分
map()和flatMap(),但规范作者出于便利性考虑拒绝了这一提议- 作者在开发EscoDB时遇到了一个真实场景:实现读者-写者锁(RWLock)需要协调多个读操作并发执行、写操作独占执行
- 通过显式返回
{ promise: Promise<T> }结构来"绕过"Promise自动扁平化,实现了关键功能:保护"检查队列状态"和"放入任务"这两个动作的原子性,同时又不阻塞调度器等待任务实际执行完成- 嵌套Promise代表"一个异步函数调用另一个异步函数,但不等待其完成"的语义,在主动管理并发控制时非常有用
- Promise扁平化本质上是"时间上的连接"(强制顺序执行),而嵌套Promise则保留了并行调度的可能性
文章URL:https://blog.jcoglan.com/2026/03/23/uses-for-nested-promises/
《Karpathy把私藏的知识管理方法开源了:让LLM帮你维护Wiki,自己只管提问》
标签:#AI #知识管理 #LLM_Knowledge_Base #Personal_Wiki #Obsidian #RAG #Agent
总结:
Andrej Karpathy 分享了他用 LLM 管理个人知识库的方法:将原始资料放入只读目录,由 LLM 自动生成和维护结构化的 Wiki,再通过 Obsidian 查看。这套"摄入-查询-检查"工作流让他在小规模数据下无需 RAG 也能高效检索,更重要的是体现了 AI 时代的新范式——分享想法而非代码,让每个人的 Agent 按需实现。这对知识工作者如何从"操纵代码"转向"操纵知识"具有启发意义。
文章要点:
- **三层架构设计超清晰**:原始资料放在
- **四个核心操作好懂又实用**:Ingest(新资料进来时 LLM 自动更新相关页面)、Query(日常提问让 LLM 去 Wiki 里搜索综合回答)、Lint(定期检查知识库有没有矛盾或遗漏)、Extra Tools(比如 vibe coding 的小搜索引擎)。整个知识库会越用越丰富~
- **为什么不用 RAG?Karpathy 的回答很实在**:他的知识库大约 100 篇文章、40 万字,在这个量级下 LLM 自己维护的索引和摘要已经够用了,不需要复杂的向量检索。Wiki 本身就是一种"压缩过的知识表示"
- **从"分享代码"到"分享想法"**:他把这套方法写成"idea file"公开,认为在 Agent 时代,清晰的思路比具体代码更有价值。每个人把自己的 Agent 叫来,照着这个想法文件就能搭出适合自己的版本
- **工作重心正在悄悄转移**:Karpathy 说他最近的 token 消耗从"写代码"大幅转向"操纵知识"。这对咱们知识工作者也是个信号——让 LLM 当长期的知识管家,而不只是临时问答工具,效率会更高呢!
文章URL:https://mp.weixin.qq.com/s/EoGLi067d_3huZf-X0Q6Fg
标签:#AI #知识管理 #LLM_Knowledge_Base #Personal_Wiki #Obsidian #RAG #Agent
总结:
Andrej Karpathy 分享了他用 LLM 管理个人知识库的方法:将原始资料放入只读目录,由 LLM 自动生成和维护结构化的 Wiki,再通过 Obsidian 查看。这套"摄入-查询-检查"工作流让他在小规模数据下无需 RAG 也能高效检索,更重要的是体现了 AI 时代的新范式——分享想法而非代码,让每个人的 Agent 按需实现。这对知识工作者如何从"操纵代码"转向"操纵知识"具有启发意义。
文章要点:
- **三层架构设计超清晰**:原始资料放在
raw/ 目录保持只读,LLM 自动读取并编译成结构化的 Wiki 文档,最后用 Obsidian 当查看器来展示。整套系统就像"原料→加工厂→展示厅"一样分工明确!- **四个核心操作好懂又实用**:Ingest(新资料进来时 LLM 自动更新相关页面)、Query(日常提问让 LLM 去 Wiki 里搜索综合回答)、Lint(定期检查知识库有没有矛盾或遗漏)、Extra Tools(比如 vibe coding 的小搜索引擎)。整个知识库会越用越丰富~
- **为什么不用 RAG?Karpathy 的回答很实在**:他的知识库大约 100 篇文章、40 万字,在这个量级下 LLM 自己维护的索引和摘要已经够用了,不需要复杂的向量检索。Wiki 本身就是一种"压缩过的知识表示"
- **从"分享代码"到"分享想法"**:他把这套方法写成"idea file"公开,认为在 Agent 时代,清晰的思路比具体代码更有价值。每个人把自己的 Agent 叫来,照着这个想法文件就能搭出适合自己的版本
- **工作重心正在悄悄转移**:Karpathy 说他最近的 token 消耗从"写代码"大幅转向"操纵知识"。这对咱们知识工作者也是个信号——让 LLM 当长期的知识管家,而不只是临时问答工具,效率会更高呢!
文章URL:https://mp.weixin.qq.com/s/EoGLi067d_3huZf-X0Q6Fg
《2026年JavaScript生态全景指南》
标签:#前端 #JavaScript #ECMAScript2025 #ECMAScript2026 #React #Vue #Svelte #NodeJS #TypeScript #Vite #Bun #Deno #TemporalAPI #IteratorHelpers #ImportAttributes
总结:
本文全面梳理了2026年JavaScript生态系统的最新发展,涵盖ECMAScript 2025(迭代器助手、Set方法、Promise.try等)和2026预期特性(Temporal API、资源管理),React/Vue/Svelte框架动态,Node.js原生TypeScript支持、Bun和Deno运行时竞争,Vite 8与Turbopack构建工具演进,TypeScript v6及AI编程趋势。文章强调掌握基础原理比追逐工具更重要,特别是在AI辅助编程时代,架构能力和代码品味尤为关键。
文章要点:
- **ECMAScript 2025超实用新玩具**:迭代器终于能链式调用`.map()
- **2026年最期待的Temporal API**:Date对象终于被拯救了!处理时区和日期计算不会再莫名其妙多出几天,浏览器原生支持即将到来,告别 moment.js 大礼包的时代要来啦~
- **框架圈的大新闻**:React 19的Server Components和Compiler还在消化中,Vue 3.6祭出Vapor Mode性能大招,Svelte 5的Runes API让响应式更细粒度; Next.js 16默认切到Turbopack,Astro被Cloudflare抱走,Remix正在酝酿去React化的大胆实验~
- **运行时三国杀**:Node.js 22+能直接跑.ts文件啦(虽然只是剥离类型),Bun被Anthropic(Claude家)收编后1.3版本速速飞起,Deno 2稳如老狗主打安全牌,三足鼎立格局越来越有意思~
- **TypeScript登顶GitHub第一**:v6严格模式默认开启,v7要用Go重写编译器提速10倍;92%的开发者都在用AI写代码,但文章提醒我们——基础原理和架构品味才是AI时代真正的护城河呀!
文章URL:https://frontendmasters.com/blog/what-to-know-in-javascript-2026-edition/
标签:#前端 #JavaScript #ECMAScript2025 #ECMAScript2026 #React #Vue #Svelte #NodeJS #TypeScript #Vite #Bun #Deno #TemporalAPI #IteratorHelpers #ImportAttributes
总结:
本文全面梳理了2026年JavaScript生态系统的最新发展,涵盖ECMAScript 2025(迭代器助手、Set方法、Promise.try等)和2026预期特性(Temporal API、资源管理),React/Vue/Svelte框架动态,Node.js原生TypeScript支持、Bun和Deno运行时竞争,Vite 8与Turbopack构建工具演进,TypeScript v6及AI编程趋势。文章强调掌握基础原理比追逐工具更重要,特别是在AI辅助编程时代,架构能力和代码品味尤为关键。
文章要点:
- **ECMAScript 2025超实用新玩具**:迭代器终于能链式调用`.map()
和.filter()`啦,而且是惰性求值不耗内存;Set之间可以玩集合运算,轻松找出技能交集和差集;`Promise.try()`让同步异步错误一网打尽;还有`RegExp.escape()`终于解决了用户搜索时特殊字符炸正则的问题~- **2026年最期待的Temporal API**:Date对象终于被拯救了!处理时区和日期计算不会再莫名其妙多出几天,浏览器原生支持即将到来,告别 moment.js 大礼包的时代要来啦~
- **框架圈的大新闻**:React 19的Server Components和Compiler还在消化中,Vue 3.6祭出Vapor Mode性能大招,Svelte 5的Runes API让响应式更细粒度; Next.js 16默认切到Turbopack,Astro被Cloudflare抱走,Remix正在酝酿去React化的大胆实验~
- **运行时三国杀**:Node.js 22+能直接跑.ts文件啦(虽然只是剥离类型),Bun被Anthropic(Claude家)收编后1.3版本速速飞起,Deno 2稳如老狗主打安全牌,三足鼎立格局越来越有意思~
- **TypeScript登顶GitHub第一**:v6严格模式默认开启,v7要用Go重写编译器提速10倍;92%的开发者都在用AI写代码,但文章提醒我们——基础原理和架构品味才是AI时代真正的护城河呀!
文章URL:https://frontendmasters.com/blog/what-to-know-in-javascript-2026-edition/
《OpenHarness:开源智能体基础设施框架》
标签:#AI #Agent #智能体 #开源 #Python #工具调用
总结:
OpenHarness是港大数据智能实验室(HKUDS)推出的轻量级开源智能体基础设施框架,仅用Python实现,代码量比Claude Code轻44倍(1.1万行vs 51万行),提供完整的工具调用、技能加载、记忆管理和多智能体协调功能,让开发者快速构建安全可靠的AI Agent应用。
文章要点:
- 极简架构设计:相比Claude Code的51万行TypeScript代码,OpenHarness仅用1.1万行Python实现,去除了企业级复杂依赖如遥测和OAuth,专注于核心Harness架构
- 五大核心模块:包含Agent循环(支持流式工具调用、并行执行、成本追踪)、工具套件(43种工具覆盖文件/Shell/搜索/Web/MCP)、上下文记忆(CLAUDE.md自动注入、MEMORY.md持久化)、权限治理(多级权限模式、交互式审批)、Swarm多智能体协调(子智能体委派、任务管理)
- 生态兼容性:完全兼容anthropics/skills技能格式和claude-code/plugins插件生态,支持OpenClaw、nanobot、Cursor等CLI工具集成
- 开箱即用:一条命令
文章URL:
https://github.com/HKUDS/OpenHarness
标签:#AI #Agent #智能体 #开源 #Python #工具调用
总结:
OpenHarness是港大数据智能实验室(HKUDS)推出的轻量级开源智能体基础设施框架,仅用Python实现,代码量比Claude Code轻44倍(1.1万行vs 51万行),提供完整的工具调用、技能加载、记忆管理和多智能体协调功能,让开发者快速构建安全可靠的AI Agent应用。
文章要点:
- 极简架构设计:相比Claude Code的51万行TypeScript代码,OpenHarness仅用1.1万行Python实现,去除了企业级复杂依赖如遥测和OAuth,专注于核心Harness架构
- 五大核心模块:包含Agent循环(支持流式工具调用、并行执行、成本追踪)、工具套件(43种工具覆盖文件/Shell/搜索/Web/MCP)、上下文记忆(CLAUDE.md自动注入、MEMORY.md持久化)、权限治理(多级权限模式、交互式审批)、Swarm多智能体协调(子智能体委派、任务管理)
- 生态兼容性:完全兼容anthropics/skills技能格式和claude-code/plugins插件生态,支持OpenClaw、nanobot、Cursor等CLI工具集成
- 开箱即用:一条命令
oh即可启动,内置114个单元测试和6个E2E测试套件,提供稳定可靠的基础能力文章URL:
https://github.com/HKUDS/OpenHarness
用游戏比赛的方式,投票选出你最适合你的编程字体:
https://www.codingfont.com/
https://www.codingfont.com/