热点聚合 · 2026-09-20

AX 把跑 AI 任务需要的沙盒、代码仓库、网络权限和模型配置，抽象成了四种声明式配置，写个 YAML 文件就能自动搭好环境。底层用了一个叫 Agent Substrate 的运行时，把每个任务当成轻量级“演员”来调度：AI 在等模型回复或外部工具时，任务会被挂起，回来时不到一秒就能恢复，这样一台机器能同时挂几十个任务，只在 AI 真正干活时才占资源。官方说一个集群能跑到数十亿并发任务，这个数字挺夸张，但正文没给出具体测试条件，先打个折看。 代码用 Apache 2.0 协议开源在 GitHub 上，对研究场景比较友好，比如批量跑沙盒收集训练数据或做大规模评估。不过目前只看到命令行操作，没提有没有图形界面或托管服务，生产环境落地还得自己折腾部署和监控。另外，Workspace 支持用自然语言描述环境需求，AX 会自动装好工具链，这点对不熟悉配置的人挺友好，但生成结果的可靠性没给数据，实际用起来可能还得人工检查。

Will Larson 在 Imprint 搞的这个“软件工厂”实验，核心是把项目目标交给 AI 代理，让它自己跑一个循环：先检查有没有对应的 Notion 设计文档和 Datadog/Snowflake 监控看板，没有就催人建；接着扫一遍 Linear 任务状态，发现缺活就自己往里加，然后挑没被阻塞的任务开始写 PR、催 review 或者提澄清问题。任务完成后如果项目描述太久没更新，就重新跑一遍全流程。 这个做法的好处是逼着人把以前攥在手里的目标状态交出来，让代理能自己判断方向对不对，而不是只会闷头执行。Larson 还提到，发布后的项目也可以用这个模式定期巡检，比如他之前上线的 passkeys 功能，如果没人盯着，代理能自动发现异常。 不过正文没披露任何性能指标或成本数据，比如代理自己加的任务质量怎么样、误判率多高、跑一圈要花多少钱。另外，这套东西目前还跑在他本地，计划迁移到公司内部的“Agent Fleet”编排系统上，但迁移后稳定性如何也没说。整体思路值得跟，但实际效果还得等更多数据。

Mustafa Suleyman 这次表态，说白了就是反对把“中国竞争”当成放松 AI 监管的挡箭牌。他的核心判断是安全与速度可以并行，不是二选一。这个立场本身不新鲜，但由微软这种同时押注商业化和合规的巨头说出来，信号意味更强——它在告诉政策制定者和市场，自己不会为了抢跑而牺牲安全人设。 不过这篇报道只是一篇公开表态稿，正文没披露任何具体的监管框架、时间表，也没提到微软内部为“安全与速度并行”付出了多少成本、做了哪些取舍。没有这些信息，就很难判断这到底是务实路线，还是单纯在舆论场上占个安全高地。 另外，文章完全没提中国 AI 的实际进展或监管现状，只是把“中国”当作一个辩论里的对立面来用。如果你想知道中美 AI 监管的真实差距在哪，这篇提供不了什么增量。

Dan McKinley 这个演讲的核心判断很直白：别跟提示词死磕了，那是个死胡同。他做面向消费者的 agent 时发现，哪怕用了结构化输出，模型还是会在一小部分请求里彻底翻车，比如把标题字段塞满废话直到爆掉。他试出来的一个离谱解法是把字段名从“title”改成“heading”，暂时管用，但随时可能失效。这说明模型根本不理解你的指令，只是在统计上蒙答案。 他的主张是用 pass^k 测试和评估管线来约束模型行为，而不是靠改提示词去“驯服”它。但演讲本身是幻灯片，没给出具体的评估框架或指标，也没披露他用的模型、请求量和失败率的具体数字。所以这个思路方向对，但落地细节全是空白。 还缺什么：他说的评估管线到底怎么搭、成本多高、延迟多大，正文都没提。另外，改字段名这种“玄学”解法能撑多久，也没有任何量化结论。

安全研究员逆向还原了 OpenAI 的广告追踪机制，技术细节很扎实。你在用 ChatGPT 时，它会种下一个叫 `__obi` 的 cookie，有效期一年，并且配置为 `SameSite=none`，专门为跨站追踪设计。之后你再去逛 Chewy、HelloFresh、Coursera 这类投了 ChatGPT 广告的网站，这个 cookie 就会被送回 OpenAI，顺带还会把页面上抓到的邮箱、电话、姓名（哈希后）和城市、邮编（明文）一起传回去。研究员在 1029 个域名上观察到了 936 个不同的广告像素，抓包数据很全。 最值得警惕的一点是：即使你只同意分析类 cookie、拒绝营销类，这个追踪照样生效。OpenAI 把 `__obi` 标为分析类 cookie，但它的实际行为就是跨站广告追踪。研究员向 OpenAI 求证分类和同意机制的问题，对方承认收到但没回答。这点先别太激动，目前还没看到 OpenAI 的正式回应，但技术复现和抓包证据摆在那里，分析同意这个缺口是整件事最尖锐的地方。 还缺什么：OpenAI 对 cookie 分类的解释、用户能否单独关闭这个追踪、以及这些数据在广告定向里具体怎么用，正文都没披露。

Sagiv Ofek 这篇吐槽精准地描述了当前 AI 写作的通病：不是写得差，而是把所有活人味儿都打磨掉了。他列举了一堆被 AI 用烂的词——“解锁”、“赋能”、“切入点”、“重塑”，以及那个标志性的破折号。这些词本身没问题，但被模型批量生产后，读起来就像同一个 27 岁、人生顺遂的精英在写 LinkedIn 模板。 文章最有价值的判断是：AI 迷恋完美的结构和流畅的过渡，但真人写作本来就有毛边、跑题和重复。他给出的建议很实在：继续用 AI 改稿，但改完必须把自己塞回去，删掉破折号，扔掉“解锁”，允许句子怪一点。正文没提供任何量化数据，纯粹是个人观察和感受，但这恰好印证了他的观点——有观点的写作本来就不该像论文。

这篇是罗博深在陶哲轩博客上的客座文章，起因是 OpenAI 解出了纳维-斯托克斯千禧年难题，数学界各种宣言和公开信满天飞。罗博深没跟着喊口号，而是从“人类应该帮助人类繁荣”这个公理出发，推了一套逻辑：如果 AI 继续变强，它创造出来需要人干的活，会比能干活的人还多，多到 AI 的进步反而会被拖慢。这个结论反直觉，而且他声明适用于所有行业，不只是数学。 文章提到了几个经济学家的反对意见，比如 Cowen 和 Gans，说数学家应该适应 AI 世界、让出控制权。罗博深承认这些反对声音让他重新思考，但他认为自己的论证更站得住脚。他还点名了《莱顿宣言》有 4000 多人签名、Math and AI 有 7000 多人签名，说明数学界的焦虑是真实的。 不过这篇文章本质上是一篇立场声明，不是研究论文。全文没有给出任何量化模型、数据支撑或时间线，论证全靠逻辑推导。罗博深自己也说了，这个公理不是人人都同意，有人骂他“物种主义”、太以人类为中心。所以读的时候要清楚：这是一个哲学框架，不是预测。如果真想判断 AI 对就业的冲击，还需要看具体行业的数据和实证研究，这篇文章没提供这些。

微软内部团队用一套叫 Nachete 的 AI 智能体系统，把 Copilot 运行时从 C# 整体迁移到了 Rust。智能体跑了 7 轮迭代，自己写代码、编译、修错误，最终产出 12.5 万行 Rust 代码，首次编译就通过了。人类只参与了代码审查和安全审计，总花费约 12 万美元。团队估算纯人工重写得花 110 万美元和 9 个月，但文章没披露这个基线的计算方式——是外包报价、内部工时折算，还是拿历史项目类比，全都不清楚。 12 万美元听起来很省，但得看这 12.5 万行代码的质量和可维护性。智能体生成的代码能一次编译通过，不代表逻辑正确、没有安全漏洞，也不代表后续迭代成本低。人类审查到底花了多少时间、发现了多少问题，正文也没给数字。另外，Nachete 是微软内部系统，外部团队没法复现，这个成本数字的参考价值要打折扣。 还缺几个关键信息：迁移后的性能对比、生产环境跑了多久、有没有线上事故。如果只是把代码搬过去但性能没提升，或者后续维护反而更贵，那 12 万美元就不是省钱，是把成本往后挪了。

这三家巨头跟云厂商、算力租赁商签的不是直接采购合同，而是业绩担保——承诺未来用到一定量，用不够就赔差价。这么操作的好处是财报上不体现巨额资本开支，账面看着轻，但实际风险敞口还在。FT估算总规模约3000亿美元，不过正文没披露每家具体担保金额和到期日，这个数字是FT自己的估算，不是审计出来的精确数。 对从业者来说，这意味着AI基建的真实成本比财报上看到的要大得多。一旦AI需求不及预期，这些担保就会变成实打实的亏损。目前还缺两个关键信息：一是各家担保的具体触发条件和赔付上限，二是这些算力最终有多少能转化成实际收入。没有这两块，很难判断这3000亿到底是合理的战略押注，还是为了撑股价做的财务魔术。

这篇文章讲了一个很实在的工程经验：让 AI 长时间写代码，最大的坑不是它不会写，而是上下文会丢细节，而且 agent 自己报告“做完了”经常不可信。作者给的解法是把一个长会话拆成指挥和干活两个角色。指挥会话负责分配任务、核实结果、记录教训，但不碰代码；干活会话是短命的，只负责具体实现。状态存在一个外部的任务板里，不靠对话上下文，因为上下文会被压缩。 核心纪律就一条：别信 agent 的自我报告。它说测试通过了，你得重新跑一遍命令，看退出码是不是 0。这个检查环节才是瓶颈，生成代码反而不是。作者管这套叫 Chief of Staff 模式，但自己也说这不是新东西，本质就是 orchestrator-worker 或者集成经理那套分工。 文章没给量化数据，比如用这套方法后任务成功率提升了多少、能跑多长的任务不崩，都是定性描述。工具链依赖 cmux 来开执行环境，但没展开讲怎么配。如果是真的，这套纪律对跑 overnight 任务会省很多返工，但落地成本在于你得先搭好那个外部任务板和消息通道。

Z.ai 这篇复盘的价值不在跑分，在于把 agent 工程化中“卡在哪”的问题拆清楚了。核心判断很朴素：优化之前先测量，这个原则对 AI 比对人更致命，因为 agent 完全依赖环境递给它的信息。文章用三个真实故障把分层反馈的链条跑通了——精度丢失靠数值差异比对定位到 TF32 模式，GIL 争用靠时间线追踪发现传输与计算从未重叠，算子冗余计算靠微基准测试揪出重复执行四次的门控计算。每个案例都走了“定目标、看现象、提假设、修复、验证”的完整闭环，不是纸上谈兵。 但有几个信息缺口得说清楚。第一，端到端吞吐达到约 3 倍基线，厂商自述这是多项技术组合的结果，且没有做消融实验来剥离诊断反馈的单独贡献，所以不能直接把 3 倍全算在 feedback engineering 头上。第二，GIL 争用那个案例，DeepEP 社区早在 2025 年 5 月就有相关 PR，智能体的贡献是在特定集群上完成本地定位和迁移，不是首次发现。第三，KDA 精度修复那条路径默认关闭，管的是算得对不是跑得快，不能计入性能账。 这篇文章真正稀缺的地方，是把“工程师该干什么、agent 该干什么”这条分工线画明白了。工程师定目标和系统边界，搭反馈环境，审高风险改动；agent 在分层验证体系里自己跑假设和代码变更。这和 Elastic 的 atune、DeepMind 的 AlphaEvolve 思路一致，都是把性能分析工具提供的“梯度信息”看得比最终判决更重。还缺什么？缺这套方法在不同模型、不同芯片集群上的可迁移性验证，也缺更长期的稳定性数据——两周跑通到生产就绪，但跑一个月后会不会出现新的长尾故障，正文没提。