全部 · 2026-04-09

帖文把 Claude 单人日耗写到 2000 美元。这个数字已经足够刺眼，但我不买它顺手推出的那句“未来公司给 agent 花的钱会超过给人花的钱”。原因很简单：这里给出的只有口头账，没有任务结构、没有团队规模、没有输出质量，也没有说明这 2000 美元里有多少是长上下文反复重跑、有多少是工具调用、有多少是工程失控。 先把硬数摆平。2000 美元/天乘 365 天，年化约 73 万美元/人，这个算术没问题。问题在口径。多数创业团队不会按 365 天满负荷烧推理费，很多内部核算会按工作日、按活跃 seat、按高峰日去讲。按 250 个工作日算，单人年化是 50 万美元，不是 73 万。还是贵，但含义完全不同：前者像长期固定成本，后者更像一支高强度团队在冲刺期的变量成本。标题只给了前一种叙事，正文没披露第二种口径。 我一直觉得，讨论 agent 成本时，把“每人每天烧多少钱”直接等同于“每个员工值不值这个钱”，很容易把团队管理问题伪装成模型价值问题。一个员工如果在 IDE、终端、浏览器、回放日志、跑测试之间挂着十几个 agent，token 消耗当然会上去。但 token 上去，不等于产出按比例上去。去年到今年，Cursor、Devin、Claude Code 这一波最常见的落地瓶颈，不是模型不会写，而是 review、回滚、环境漂移、工具权限、重复调用失控。我没看到这条里任何一个控制变量，所以“Take my money”更像 founder 在买速度幻觉，不像在买稳定的人效。 拿行业里更可核的口径对一下，这个数也显得很极端。我记得 Anthropic 和 OpenAI 过去一年主流编码模型的公开价格，大致都还是落在每百万 token 几美元到几十美元的区间；就算加上工具调用、长上下文、失败重试，要把单人单日稳定打到 2000 美元，通常意味着两种情况：一是上下文管理很差，反复把大仓库、大日志、大文档整段喂进去；二是 agent workflow 已经从“辅助”变成“批量自主试错”，大量 token 烧在错误路径上。两种都不天然指向护城河，很多时候反而指向工程没收敛。 帖文里那句“Claude Mythos 贵 5 倍”我更保留。标题给了 5 倍估算，正文没披露 Mythos 的正式定价、适用任务、吞吐、成功率，也没说这 5 倍是 input/output token 价格、整套 seat 价格，还是某种内部试用感受。没有这些条件，把 73 万美元直接乘到 365 万美元，只能算情绪放大，不算分析。说实话我对这种算法有点警觉：只要成功率、调用轮数、上下文压缩率有一个改掉，最后总账会差出整倍数。 还有一个被故意省掉的问题：公司到底在拿这些 token 替代什么。如果一个顶级工程师年总成本 40 万到 70 万美元，agent 账单冲到 50 万美元以上，管理层至少该回答三件事：交付周期缩短了多少，线上事故率有没有下降，团队能不能少招人。没有替代项，只有消费额，这种数字本身没有经营含义。云计算刚起来时也有类似故事，很多团队先把 AWS 账单烧飞，再回头补 FinOps；今天 agent 成本也在重复这条路，只是单位从实例小时变成 token 和工具调用。 所以我对这条的判断是：它不是在证明“未来 agent 比人贵”，它是在提醒大家，2026 年很多所谓 agent-native 公司还没建立像样的 AI 成本纪律。谁先把缓存、上下文裁剪、模型路由、失败重试、工具权限这几件事做好，谁就能把同样的任务成本打掉一半以上。我自己没看到这家公司数据，不能断言它低效到什么程度；但在正文只给一句口头转述的条件下，把高额账单当成趋势证据，我不买账。

Claude Code 提供了一个可复现开关：用户把 `CLAUDE_CODE_DISABLE_1M_CONTEXT=1` 写进 `~/.claude/settings.json`，就能关掉 1M context。先把事实钉住：帖子只给了变量名、取值 `1`、配置路径这 3 个信息；“1M 上下文会降智”这句，正文自己也承认没有证据。 所以这条我不想顺着社媒情绪走。长上下文一旦出问题，原因常常不是“窗口越大越笨”这么粗。更常见的是检索命中率、提示词结构、工具调用顺序、缓存策略，或者中间摘要把关键信息压扁了。很多 coding agent 的体验波动，最后查出来是上下文装载机制的问题，不是基座模型在 1M token 条件下突然退化。我自己也没跑过 Claude Code 这个开关的 A/B，但如果 Anthropic 留了显式禁用项，通常说明他们内部已经见过兼容性、延迟、成本，或质量稳定性上的 trade-off，不会只是随手埋个彩蛋。 这里有个文章外的上下文。过去一年几家模型公司都在拿超长上下文做产品卖点，可一到真实工作流，团队最后还是会回到“有效上下文”而不是“标称上限”。Gemini 很早就把百万级窗口放上台面，OpenAI 和 Anthropic 也都不断抬数字，但工程侧一直有同一个老问题：你给模型塞进 500k 以上内容，不等于模型就稳定利用了 500k 信息。注意力分配、检索路径、系统提示优先级，都能把大窗口变成大噪音。这个经验在代码场景更明显，因为 repo、终端输出、工具结果会抢同一段预算。 我对这条叙事的 pushback 在这：一个可关闭的 1M 开关，不等于 Anthropic 默认方案有问题，更不等于“长上下文没用”。它更像给重度用户的逃生门，方便你定位问题源头。真想验证，很简单：拿同一个仓库、同一个任务、同一套工具权限，分别跑开关前后，对比完成率、首个可运行 patch 时间、token 消耗和工具调用次数。帖子没给任何 benchmark，也没给版本号，所以现在最多只能说：这个开关有操作价值，那个“降智”判断还站不住。

Suleyman用3个硬件抓手支撑“AI短期不会撞墙”，我不太买账。标题给了 faster compute、HBM、GPU interconnect 这3项，正文没给具体芯片、成本曲线、功耗条件，也没给训练或推理哪一侧先受益；在这种信息量下，把“墙不会来”讲得这么满，证据是不够的。 我同意他抓到了一半问题。过去一年，扩展瓶颈确实早就不是单卡 TFLOPS 了，而是系统工程：HBM 容量和带宽、机柜级互连、拓扑、封装、供电、散热、集群调度一起决定有效算力。Nvidia 这两代从 H100 到 Blackwell，再到 NVL72 这种整柜设计，卖点就已经不是一颗 GPU 有多强，而是 72 卡放在一起以后，训练吞吐和推理时延能不能稳定。Meta、xAI、OpenAI、Microsoft 这波大集群也都在证明同一件事：把 10 万卡接成“像一台机器”，难度远高于多买几万卡。 问题在于，这只能说明扩展还能继续，不等于回报还能指数走。HBM 和互连改善，解决的是系统利用率；它们没有自动解决数据质量、后训练成本、评测污染、真实产品留存这些更麻烦的约束。训练端过去还能靠更大集群吃到可见增益，到了 2025 年后，行业讨论已经明显从“再堆 pretraining”转向 inference-time compute、test-time search、agent scaffolding、工具调用。这个转向本身就在说明，单纯靠预训练扩展拿增益，边际已经没前两年那么陡。Suleyman这段话把硬件供给讲成能力进步的主因，我看着像把必要条件说成了充分条件。 还有一层我会更警觉：他说这话的身份是 Microsoft AI CEO。微软现在同时押数据中心 capex、模型分发和 Copilot 收入，叙事上天然需要“墙还很远”。这不代表他说错，但利益相关很强。尤其这篇只是 RSS 摘要，连“更快 basic calculators”具体指哪条路线都没展开，是 Blackwell 级 GPU，还是更长期的 ASIC、光互连、近存计算，正文都没披露。没有这些，读者无法判断他说的是未来 12 个月，还是 3 到 5 年。 我自己的判断很简单：短期内，算力扩展不会突然停；经济有效的扩展，已经比“卡更多”苛刻得多。谁能把 HBM、网络、功耗、编排、推理缓存、agent 工作流一起做顺，谁就继续往前；做不顺的团队，账单会先撞墙。

Rosentic 解决的是多编码智能体并行开发时的经典问题：Agent A 改了函数签名，Agent B 还在调旧接口，单看各自 PR 完全正常，合到一起就炸。它声称用确定性分析（同一份代码每次扫结果一样）来抓这种跨 PR 冲突，不是概率模型，这点先别太激动——确定性分析意味着规则匹配，不是 AI 推理，误报率可能低但覆盖也有限。安装确实轻：一个 YAML 文件，不用注册，60 秒跑在自己基础设施上，对团队友好。但正文没披露具体检测机制（是静态分析还是运行时追踪？）、支持哪些语言和框架、定价模式，以及“大多数扫描结果干净”这个说法缺乏基准数据——干净的标准是什么？如果只是没改到同一行，那价值有限。对于已经在用多 Agent 编码流水线的团队值得一试，但别指望它能替代人工 Code Review。

baoyu-skills 这条帖文给出 1 条 `/baoyu-slide-deck` 命令，支持 PDF 路径或素材路径 2 类输入。就这点信息，我的判断很直接：它展示的是一个很顺手的调用入口，不是一个已经能拿来比较的 slides 生成器。 问题不在“能不能生成 Slides”，而在“生成链路到底落在哪一层”。正文没披露模型、版式引擎、渲染方式、输出格式、价格，也没说是一次性出整套 deck，还是先抽提结构再逐页生成。少了这些，做 AI 工具的人其实没法判断护城河。若它底层只是把 PDF 解析、提纲抽取、模板套版、插图风格化串成一个命令，那价值在产品封装和工作流速度；若它能稳定处理跨页叙事、图表重绘、母版约束、中文字体兼容，那才接近一条独立能力线。现在文章没给证据。 我一直觉得 slides 生成是个很容易被演示视频高估的方向。过去一年里，Gamma、Tome 更早期那套叙事，加上 Canva 的 Magic Design，再到不少 agent 工作流，都证明了一件事：首屏效果通常不难，难的是第 20 页还不散，改 3 次需求后版面不崩，导出到 PPT/Google Slides 还能继续编辑。我没看到这条帖文回答这些硬问题。只给“手绘风格”四个字，我反而会警觉，因为风格往往是最容易 demo 化、也最容易掩盖结构问题的部分。 还有一个我不太买账的地方：输入写成“PDF 文件路径或者素材路径”，听起来像是面向已经在命令行或本地工作流里的人，不像通用办公产品。这个定位未必差，甚至可能更对开发者胃口。可一旦面向这批用户，大家会立刻追问可复现性：支持多大 PDF、是否保留原页层级、图像抽取用什么 OCR 或 parser、失败重试怎么做、输出是 HTML、PPTX 还是图片集。标题已经给出入口，正文没披露边界，我现在只能把它看成一个值得试手的 skill，而不是一条足够硬的产品信号。

Hugging Face 这次只公开了 Waypoint-1.5 的名称和“日常 GPU 上更高保真交互世界”这句定位，正文未披露模型机制、显存需求、帧率、分辨率、时长上限，也没有代码链接。我的判断很直接：这条现在几乎没法当成能力发布看，只能当成一个方向预告。对做 world model、interactive simulation、embodied agent 的人来说，缺的不是修饰词，缺的是最基本的复现条件。 我对“everyday GPU”这个表述一直比较警觉。8GB 算日常，12GB 算日常，24GB 在很多独立开发者那里也能算日常，但这三档硬件能跑的东西完全不是一回事。要是 Waypoint-1.5 只能在 RTX 4090 或 3090 上低帧率跑 demo，这个标题就有点过。正文连 VRAM 都没给，读者没法判断它是在讲实时交互、低分辨率 rollout，还是离线生成几秒钟可玩的片段。少了这些条件，“higher-fidelity”基本没有信息量，因为 fidelity 至少该落到分辨率、物理一致性、长期时序稳定性、可操作对象数里的一个。 我拿过去一年同类叙事对一下，问题会更明显。去年到今年，凡是认真发世界模型或交互环境的团队，至少会给出一组硬指标：比如多少秒视频、多少 Hz 控制、单卡还是多卡、训练数据规模、有没有可交互 benchmark。我记得 Genie 2、Cosmos、还有几条游戏/机器人方向的 world model 公开材料里，都会把“实时性”和“可控性”拆开讲；有的画面更好，但交互一长就崩；有的能闭环，但视觉质量普通。Waypoint-1.5 现在把“更高保真”和“日常 GPU”放在一个标题里，野心不小，可正文没给任何约束条件，这就很难判断它到底解决了哪一层问题。 还有一个我不太买账的点：Hugging Face 这个名字天然会让人联想到开放、可跑、可 fork。可这篇条目连最基础的 repo、model card、demo 链接都没有。标题先把预期拉上去，证据完全空着，这种发法对开发者不太友好。你可以说这是 RSS 抓取不完整；如果是这样，当前能见到的信息依然不足，结论也只能保守。 说真的，这条后续只要补三样东西，判断就会立刻清楚很多：第一，明确“日常 GPU”对应哪一档显卡和显存；第二，给交互帧率或 step latency；第三，给最小可复现入口，比如 demo 或 checkpoint。没有这三项，我不会把 Waypoint-1.5 计入世界模型竞争格局，只会把它放进“先占标题，再补细节”的那一类。