Vercel Zero 语言观察:Agent 时代,编译器也得会给机器读
Vercel Labs 做 Zero,表面上是又一门系统编程语言。真值得看的不是“它要不要挑战 Rust、Go、Zig”,而是另一个问题:如果代码的主要生产者、调试者、修复者越来越多地变成 Agent,编程语言和编译器该不该换一套默认设计。 Zero 的答案很直接:让能力显式,让诊断结构化,让内存和依赖可预算,让修复动
共 30 篇文章
Vercel Labs 做 Zero,表面上是又一门系统编程语言。真值得看的不是“它要不要挑战 Rust、Go、Zig”,而是另一个问题:如果代码的主要生产者、调试者、修复者越来越多地变成 Agent,编程语言和编译器该不该换一套默认设计。 Zero 的答案很直接:让能力显式,让诊断结构化,让内存和依赖可预算,让修复动
终端文件管理器这类工具,很容易被写成“ls 和 cd 的升级版”。这说法没错,但有点浅。 Yazi 更关键的地方,不只是它能在终端里预览图片、PDF、压缩包和代码,而是它把“文件浏览”这件事重新放回了键盘工作流里。对开发者、运维、远程服务器用户来说,文件管理不是打开一个 Finder 或资源管理器那么简单:你经常在
把 Claude Code 装在自己电脑上,适合“坐在桌前写代码”。但真正想让 Agent 干活,问题很快就变成另一种:人不在电脑前怎么办?浏览器登录态怎么保留?任务跑到一半遇到 2FA 或验证码怎么办?手机上能不能只发一句话,让它继续处理? bux 解决的正是这个缝隙。它不是另一个浏览器自动化框架,也不是给 Clau
Karpathy 把 Software 3.0 说清楚之后,很多人第一反应还是落在“以后是不是不用写代码了”。这个问题问得太早,也太浅。更值得看的是:软件的接口正在换人。 Software 1.0 的接口给程序员用,核心是编程语言、函数、类型、测试和部署。Software 2.0 的接口给训练系统用,核心是数据集、损
很多本地模型方案都绕不开下载模型、选量化、配显存、调推理服务。Mac 用户还有另一条路:把系统自带的 Apple Intelligence 变成命令行工具和本地 OpenAI 兼容接口。apfel 做的就是这件事。 它把 Apple FoundationModels 暴露成 UNIX CLI、交互式聊天和本地 Open
Office 自动化一直是 Agent 的尴尬区。企业文件大量存在 Word、Excel、PowerPoint 里,但传统自动化要么依赖桌面 Office,要么用几套库分别处理 docx、xlsx、pptx,结构不统一,预览也麻烦。Agent 想稳定修改这些文件,不能只靠“生成一段 Python 试试”。 Office
Agent 真正进入日常工作以后,瓶颈往往不在模型本身,而在运行时。聊天框能回答问题,但很难长期维护一个项目:它要记住上下文、调用工具、拆任务、写代码、跑测试、处理失败、接消息平台,还要能在长会话里恢复状态。 OpenHarness 把这个问题直接摆到了台面上。它不是另一个“套壳聊天助手”,而是一套轻量 Agent h
Ubuntu 上的防火墙不难,难的是很多人一开始就把它想歪了:不是背几条 `ufw allow`,也不是把所有端口一关就叫安全。真正能长期维护的防火墙配置,应该回答三个问题:这台机器对外提供什么服务、谁能访问、出了问题怎么安全回滚。 Ubuntu 默认推荐的入口是 UFW,也就是 Uncomplicated Firew
Agent Zero 这类项目,最容易被写成“又一个自主 Agent 框架”。这话不能算错,但没抓到重点。 它更关键的地方,不是会聊天,也不是会调用几个工具,而是把 Agent 放进一台完整的 Linux 工作台里:有文件系统,有终端,有浏览器,有记忆,有项目隔离,有插件和技能,还能把任务继续拆给子 Agent。
大模型成本控制最常见的错误,是只盯单价。单价当然重要,但真正烧钱的,是简单任务也走最贵模型,失败重试又继续走最贵模型,最后账单一看,像开了水龙头。 UncommonRoute 的思路是加一层自动路由。它作为 OpenAI 兼容代理,帮你判断请求复杂度,把简单任务交给便宜模型,把复杂任务交给更强模型。项目强调最高可以节省
AI 写小说最常见的失败,不是写不出字,而是写着写着就散了。人物性格漂,节奏乱,前后设定打架,越到后面越像自动续杯的套路汤。 InkOS 值得看的地方,是它没有把自己包装成一个“输入一句话生成百万字”的玩具,而是把小说创作拆成写、审、改、人工审核几个环节。它是一个自动化小说写作 Agent,也发布成 OpenClaw
很多多 Agent 项目看起来都挺热闹:一个规划,一个执行,一个检查,再来一个总结。演示的时候顺滑,真塞进业务流程,麻烦就来了。中途失败怎么办?状态丢了怎么办?两个 Agent 写冲突了怎么办?谁来判断它该停手? Hive 的切口不是再做一个花哨 Agent,而是做 harness。也就是给多 Agent 任务补上状态
语音 AI 的 demo 通常都很好听。真正落地时,问题才冒出来:长文本断句不自然,显存吃紧,首包延迟高,声音克隆授权不清楚,多说几分钟后情绪和音色开始飘。 MOSS-TTS 是开源语音生成模型家族,覆盖长文本语音、多说话人对话、声音设计、环境声和实时流式等方向。它适合想把 TTS 放到本地或自托管环境里的团队。 但语
很多人做 AI 应用时,第一反应是把业务数据直接塞成 JSON。简单、通用、模型也能读,看起来没毛病。 但一到真实场景,账就不太对了。订单列表、埋点日志、知识库片段、搜索结果、用户画像、商品属性,全都用 JSON 喂给模型,会浪费大量字段名、括号和重复结构。上下文窗口再大,也不能这么霍霍。 TOON 的价值就在这里。它
让 Coding Agent 写普通 Web 代码已经不新鲜了。难的是让它进入一个复杂数据平台:Spark、Unity Catalog、Jobs、MLflow、Model Serving、权限、表结构、流水线规范全都在场。 `Databricks AI Dev Kit` 解决的是这个问题:给 Claude Code、C
很多人用 Claude Code,习惯是把需求直接扔进去,然后盯着它改。能跑,效率也有,但问题很快出现:产品判断没人做,设计味道没人看,安全审计靠运气,最后发布时再补文档和测试。AI 写代码变快了,工程流程反而容易被省掉。 gstack 值得看的地方,不在“Garry Tan 的同款配置”这个噱头,而在它把 Claud
Agent 应用最怕“演示很好,上线就飘”。本地试十次都对,真实用户换个问法就错;工具调用在测试里正常,生产里突然走偏;你知道它失败了,却不知道失败发生在哪一步。 Future AGI 想做的是一条完整质量闭环:评测、追踪、模拟、数据集、网关、防护都放在一个平台里。它不是单点 eval 工具,而是更像 Agent 应用
把 Agent 接进 CI/CD,听起来很诱人:自动整理 issue、修小 bug、更新文档、跑评审、生成 PR。问题是,Agent 一旦进了仓库自动化链路,权限、输出和审计就不能再靠一句“相信模型”。 GitHub Agentic Workflows 的方向很值得看:用自然语言 Markdown 写 agentic
AI 编程最大的问题之一,是同一句“修这个 bug”,今天和明天可能跑出两种完全不同的过程。一次它先读测试,一次它直接改代码;一次会写计划,一次把计划省了;一次跑验证,一次嘴上说完成。 Archon 的思路很直接:不要把工程流程交给模型临场发挥,而是把计划、实现、测试、review、审批和 PR 创建写成工作流。模型负
GitHub 是典型的代码托管和开发者协作平台:不注册,很多功能看不完整;一注册,又可能开始收到确认邮件、提醒、营销信息和各种后续通知。只想先试一下时,tempmail.ee 可以当作临时邮箱缓冲层。 要先把边界说清楚。临时邮箱不是绕过平台规则的工具,也不该用于刷号、规避封禁、垃圾信息或冒充身份。它只适合低风险试用:先