AI 开发者日报

Thinking Machines 的原生交互模型：超越回合制 AI

• 全双工多模态交互成为模型的一等公民能力：当天最清晰的技术主题是 Thinking Machines 对“交互模型”的预览。这些模型从零开始训练，专为实时交互而设计，而非在回合制大模型上叠加语音、话轮切换和工具使用功能。随附的技术文章以及来自 @johnschulman2、@soumithchintala 和 @cHHillee 的团队评论将其定义为人↔AI 带宽问题：模型应该能够同时进行听、说、看、思考、搜索和反应。演示强调了连续时间感知、打断处理、同时语音、视觉主动性和后台工具使用，而无需显式的“现在我在思考 / 现在我在搜索”边界。团队成员还指出，一旦类型签名变为连续的 音频+视频+文本 → 音频+文本，许多以前需要专用系统的任务现在可以零样本完成（@johnschulman2）。

• 技术上的重要性：多个反馈都指向了同一个观点：这并非“又一个聊天机器人演示”，而是交互假设的根本性改变。@liliyu_lili 指出视觉主动性（“当我开始驼背时告诉我”、“数我做俯卧撑的次数”）是当前系统中缺失的原语；@rown 称其为第一个具备视觉主动性的通用 视频+语音 模型；@kimmonismus 和 @giffmana 都强调，原生交互能力是比原始基准测试成绩更深刻的创新。正如 @swyx 所指出的，这次发布也无形中提高了“实时”多模态系统的门槛。通过 @eliebakouch 透露的一个实现细节：该技术栈使用了 SGLang。

• OpenAI正向服务与部署层下沉：OpenAI宣布成立OpenAI Deployment Company，这是一个由OpenAI控股的子公司，旨在帮助企业将前沿模型部署到真实工作流中。关键运营细节是，通过收购Tomoro，将引入150名前线部署工程师和部署专家，@gdb提到来自19家合作伙伴的40亿美元初始投资。多位观察人士认为，这是OpenAI在采用Palantir/Microsoft式的现场工程模式：@kimmonismus认为OpenAI想要掌控AI经济的部署层，而@matvelloso则将其与历史上企业成功的模式联系起来——将技术人员嵌入到客户运营一线。
• Daybreak：面向安全的模型分发、工作流与信任层级：OpenAI还推出了Daybreak，这是一项围绕防御性网络运营和持续保障软件安全的综合性计划，@sama将其定位为应对快速提升的AI网络能力的务实举措。根据@TheRundownAI的总结，该产品方案整合了GPT-5.5、Codex、代码库威胁建模、漏洞发现、补丁生成和响应自动化，并提供了差异化的访问层级，包括网络安全信任访问和更专业的GPT-5.5-Cyber。这与Anthropic更为保守的网络安全策略形成鲜明对比，@kimmonismus捕捉到了这一张力。对于构建安全智能体系统的团队来说，@lukOlejnik的一条独立警告也值得关注：“你的大模型不是安全边界”——据报道，Microsoft Semantic Kernel允许将提示词注入转化为主机级远程代码执行，原因是该框架过度信任模型输出，而非模型本身存在缺陷。

• 更好的 Agent 控制平面正成为一个产品类别：一个反复出现的抱怨是，有用的 Agent 需要自主性，但工程师仍然希望拥有可逆、可检查的控制能力。@itsclelia 通过 aggit 解决了这个问题，这是一个 Rust 编写的 CLI 工具，支持本地/远程、基于 S3 存储的 Agent 产物管理，实现了在主 Git 历史之外进行 stash/branch/restore 操作。同样地，@_catwu 强调了一个新的 claude agents 终端控制平面，用于管理多个 Claude Code Agent，而 @cursor_ai 则将 Cursor 推入了 Microsoft Teams，Agent 可以读取整个线程并直接创建 PR。这些迹象都表明，"Agent 编排"正在收敛到具体的用户体验模式上，而不仅仅是提示词技巧。

• Deep Agents / Hermes / 本地 Agent 正在快速成熟：@masondrxy 指出，Deep Agents CLI 可以在对话中途热切换底层模型提供商，且不丢失上下文，这是许多 Agent 框架仍然缺失的一项重要的系统级能力。LangChain 也强调了针对提供商/模型特定调优的 harness profiles（推文），同一作者的价格分析认为，对于高吞吐量的 Agent 工作负载，DeepSeek V4 Flash 的成本可能远低于 GPT/Gemini 的 flash 级别选项（推文）。在本地方面，Hugging Face 在本地应用中添加了 Hermes Agent 支持以及原生 trace 可视化功能，而 @Teknium 则通过 Hermes Agent 和 CUA 预览了使用任意模型进行计算机操作，明确瞄准了本地/开源模型以及前沿 API。@onusoz 加入 Hugging Face 以改进 OpenClaw 及相关开源框架中的本地模型，这又是一个强烈信号，表明本地 Agent 的易用性已成为战略性基础设施。

• 围绕工具的设计理念正在浮现：@threepointone 认为，Agent 最终可能只需要两个原始工具：搜索和执行，通过动态语义发现能力，而不是不断扩展的静态工具菜单。这与从庞大单体提示词转向可配置框架的更广泛趋势相辅相成。

• 编程智能体基准测试终于开始衡量"框架+模型"组合：Artificial Analysis 发布了 Coding Agent Index，涵盖 SWE-Bench-Pro-Hard-AA、Terminal-Bench v2 和 SWE-Atlas-QnA，比较的不仅是模型本身，更是 模型+框架组合。其核心结论：Opus 4.7 在 Cursor CLI 中得分 61，GPT-5.5 在 Codex/Claude Code 中紧随其后；表现最好的开源方案包括 GLM-5.1、Kimi K2.6 和 DeepSeek V4 Pro（均运行在 Claude Code 中），虽仍有竞争力，但差距明显。该基准测试还揭示了 单任务成本（差异超 30 倍）、Token 用量（差异超 3 倍）、缓存命中率（80%–96%）和 单任务耗时（差异超 7 倍）的巨大波动。该基准测试还得到了 OpenHands 更新的软件工程基准公告（推文）以及 Claw-Eval 更丰富的智能体任务集（涵盖办公、金融、终端和网页任务）的补充，其中 MiMo-V2.5-Pro 领先，而 DeepSeek V4 Flash 在其规模下表现出异常高的效率。
• 对 TurboQuant 的质疑声渐起：多篇文章对近期流行的量化/服务技术提出了更冷静的看法。@_EldarKurtic 展示了他所称的首个 TurboQuant 全面研究，涵盖精度、延迟和吞吐量；@vllm_project 将 Red Hat / vLLM 的联合调查作为起点进行了引用；而 @jbhuang0604 则直截了当地总结道："它实际上效果并不好。" 这正是那种需要独立复现来验证的基础设施层面的技术主张。
• 本地/开源模型的进步速度持续超越硬件天花板：@ClementDelangue 提出了最强有力的宏观论点：在同样的顶级 MacBook Pro 内存上限下，"你能实际运行的最聪明的开源模型" 已从 Llama 3 70B 时代的能力提升到 DeepSeek V4 Flash mixed-Q2 GGUF 时代的能力，24 个月内提升了约 4.7 倍，相当于每 10.7 个月翻一番，速度超过摩尔定律。支持性数据来自 @victormustar 关于 GGUF 上传量快速增长的报告，以及社区反复观察到的 Qwen 3.6、Gemma 4 和 DeepSeek 系列变体现在已可在本地用于非平凡的智能体任务。

• 架构与评估：AllenAI 的 EMO 被 @TheTuringPost 评为一种更具模块化的混合专家（MoE）设计，其文档级路由机制催生了共享专家池。值得注意的是，在类似的剪枝条件下，仅保留 25% 的专家，性能损失仅为 ~1%，而标准 MoE 的性能下降幅度高达 10–15%（后续讨论）。在生成式评估方面，@qberthet 提出了 MIND（Monge Inception Distance），据称这是一种比 FID 更快、样本效率更高的替代指标。

• 语言与字节级建模的扩散方法：多篇论文推动了非自回归语言建模的发展。@LucaAmb 报告称，在其评估设置下，连续比特流扩散模型的性能几乎与自回归模型持平；@JulieKallini 提出了 Fast BLT，利用扩散实现并行字节解码，从而减少字节级语言模型的推理瓶颈；@sriniiyer88 将其描述为将块级字节扩散与自推测解码相结合。与此相关，@LiangZheng_06 指出了扩散模型在后训练中的一个有用特性：由于采样过程是可微的，奖励梯度原则上可以比标准大模型设置更直接地流向参数。

• 长周期下的智能体行为：出现了两条强有力的实证线索。首先，“记忆诅咒” 声称，在多轮社会困境中，过长的历史记录会降低合作意愿，因为模型会变得更倾向于遵循历史并规避风险，而显式的思维链（CoT）有时会加剧这一问题。其次，@dair_ai 总结的普华永道（PwC）工作认为，澄清的价值高度依赖于时间节点：目标澄清在任务执行约 10% 之后，其价值基本丧失，而输入澄清的有效性则能维持更久。综合来看，这些发现表明，长周期智能体的质量不仅受限于模型本身的智商，同样受限于记忆/控制策略。

• 扩展与自我改进：Marin 的 Delphi 扩展工作（由 @WilliamBarrHeld 总结）声称，从小型预训练外推至 25B / 600B token 的运行规模时，预测误差仅为 0.2%。此外，@omarsar0 重点介绍了 AutoTTS，该方法让大模型自行搜索测试时扩展控制器空间，据称能以约 39.9 美元 的发现成本击败人工设计的策略。

• OpenAI 的企业/服务布局：OpenAI 推出 Deployment Company，以及 Tomoro 收购案 / 150 名 FDE。
• OpenAI 的安全产品化：Daybreak 公告 与 @sama 的解读。
• Thinking Machines 的交互模型：Mira Murati 的发布推文 以及 技术预览讨论串。
• Artificial Analysis 编程智能体指数：基准测试发布与核心发现。
• 智能体工具 / 开发者工作流：Hermes Agent 支持任意模型的计算机操作、Cursor 集成到 Microsoft Teams，以及 Codex OpenAI Developers 插件。

1. Qwen 3.6 本地推理新进展

Unsloth 发布 MTP 保留版 GGUF

Unsloth 上的 MTP 支持（热度：620）：图片（链接）展示了 Unsloth 的 Hugging Face 主页，列出了新发布的保留 MTP 的 GGUF 构建：unsloth/Qwen3.6-27B-GGUF-MTP 和 unsloth/Qwen3.6-35B-A3B-GGUF-MTP。这些 GGUF 保留了 MTP（多 token 预测）/下一 token 预测层，但用户仍需构建特定的 llama.cpp MTP PR，而非依赖标准 llama.cpp 支持。有评论者报告在运行 27B GGUF 时遇到运行时/断言失败：GGML_ASSERT(hparams.nextn_predict_layers > 0 && "QWEN35_MTP requires nextn_predict_layers > 0")，表明元数据解析、模型转换或 PR 兼容性问题尚未完全解决。评论中充满了对上游 llama.cpp MTP 支持的期待，用户反复查看 GitHub 仓库，询问 MTP 是否已实现"开箱即用"。

一位编译新版 27B GGUF 模型的用户在 qwen35_mtp.cpp 中遇到了运行时断言：GGML_ASSERT(hparams.nextn_predict_layers > 0 && "QWEN35_MTP requires nextn_predict_layers > 0")。这表明 GGUF/模型元数据或转换路径可能缺少 nextn_predict_layers，而这是 Qwen3.5 MTP 推测/下一 token 预测层所必需的。

• 有技术讨论指出，GGUF 中的 MTP 支持对本地推理至关重要，尤其是 35B A3B 变体，评论者认为它能更好地处理长上下文。另一位评论者询问这是否意味着 llama.cpp 现已"开箱即用"支持 MTP，暗示目前尚不确定支持是否已合并/稳定，还是仅存在于 PR 或分支中。
• 有评论者声称 ik_llama 的 MTP 目前比 llama.cpp PR 更快，并且支持基于 Hadamard 的量化（类似于"turboquants"）。这对于比较本地 MTP 推理后端的用户来说，是一个值得关注的实现/性能差异。

Qwen 3.6 35B A3B 的 hype 名副其实

Qwen 3.6 35B A3B 的 hype 是真的！！！（热度：586）：该帖子报告了一项定性的代码理解评估，将几款小型/本地长上下文开源模型——Qwen 3.6 35B A3B、Qwen 3.6 27B、Gemma 4 26B A4B 和 Nemotron 3 Nano——与一篇学术论文及对应的研究代码一同测试，要求模型将实现细节映射回论文；作者的详细笔记见此 GitHub README。核心观点是，较新的长上下文机制（如 gated delta net、hybrid Mamba2 和 滑动窗口注意力）相比之前的小型本地模型（如 Devstral Small 2）显著提升了实际代码理解能力，其中 Qwen 3.6 35B A3B 被评为最强；作者无法在 32 GB 内存中为 Devstral Small 2 提供所需的长上下文。评论者指出了实际权衡：一位用户使用 Gemma 26B 进行快速代码修复，用 Qwen 35B 进行长上下文重构，称 Qwen 35B 在思考模式下会"啰嗦"，但在 q4 量化下约占用 20 GB，而 Gemma 26B 约占用 15 GB，两者可同时驻留内存。另一位评论者批评该评估未指定推理设置，导致可复现性和对比困难。

• 用户报告了 Qwen 3.6 35B A3B 和 Gemma 26B 的实际部署细节：在 q4 量化下，Qwen 35B 约 20 GB，Gemma 26B 约 15 GB，两者可同时驻留内存。一种工作流是使用 Gemma 26B 思考模式进行快速代码修复和聊天，而将 Qwen 35B 思考模式保留给长上下文重构，因为它在最终输出前往往会产生冗长的推理过程。
• 一个编码工作流讨论提到，在一个 10万+ 行的代码库上，先用更强的云端/智能体模型初始化项目，然后切换到 Qwen 27B 继续工作。该评论者发现 Qwen 27B 在实际使用中与 DeepSeek V4 相当，尽管偶尔会陷入循环，需要手动中断并提示继续；他们还认为在此本地编码场景中，Qwen 27B 优于 Gemini Flash。
• 多条评论强调了缺失或敏感的推理配置细节：一位用户询问使用了哪些运行时设置，另一位则表示 Qwen 27B 需要正确的 temperature/采样参数，并警告不要过度量化 KV 缓存或模型。这意味着模型质量的感知可能因采样和量化选择而有显著差异，尤其是对于较小型的本地编码模型。

观点：本地大模型将在 12-24 个月内接管一切

观点：本地大模型距离接管还有 12-24 个月。转变已经开始。（热度：1108）：该帖子认为，本地编码/智能体大模型将在 12-24 个月内取代许多付费托管工作流，以 Qwen3.6-35B 在 MacBook Pro M2 Max（64GB 统一内存） 上以约 27 tok/s 的速度运行为例，生成落地页需要 8-9 分钟，而 Opus 需要 3-4 分钟。作者报告了有用但尚未完全达到生产级的结果——前端/后端功能开发和后端竞态条件修复——单次成功率约 75%，同时指出了延迟、即使 256K 上下文也会快速耗尽以及任务质量差异等剩余差距；关键的技术突破是可靠的工具调用能力，这对智能体工作流至关重要。该帖子将这一趋势与不断上升的托管 AI 成本（包括 GitHub Copilot 转向按用量计费）联系起来，并建议将本地模型与 Claude/Opus/Sonnet 并行使用，而非立即完全替代。热门评论普遍支持开源/本地化趋势，一位用户表示自己已在 RTX 5090 上"完全本地化"，并且"再也不会回去了"。一位评论者质疑该帖子本身是否由 AI 撰写，特别针对关于 Qwen 工具调用可靠性的措辞提出了疑问。

• 有评论者报告已在 RTX 5090 上完全本地化，暗示当前消费级高端 GPU 已足以满足其工作负载，并且已放弃日常使用托管模型。
• 多条评论将主要剩余差距归结为上下文长度和可靠性 vs. 前沿托管模型：Claude/Gemini/Codex 被认为更擅长生成大型、连贯的输出，而本地模型需要更多的增量组装和测试，但可能以更小、更易调试的方式失败。
• 帖子中关于 Qwen3.6 工具调用"开箱即用" 的说法被视为本地智能体工作流的关键技术突破，尽管一位评论者质疑该措辞本身是否由 AI 撰写，而非提供基准证据。

工作站上的前沿级模型

• 使用Intel Optane持久内存构建的计算机——可运行万亿参数模型，速度超过4 tokens/s（热度：597）：图片（JPEG）展示了一台定制的LGA3647 Xeon工作站/服务器，插满了大量DIMM内存条，帖子说明其配置为192GB DDR4 ECC加上768GB Intel Optane DCPMM（内存模式），从而为本地大模型推理提供了一个超大容量的类RAM层级。作者报告称，使用llama.cpp的混合GPU/CPU推理模式，在RTX 3060 12GB显卡上运行Kimi K2.5（一个约1T参数的MoE模型），速度约为4 tokens/s。通过override-tensor将注意力层、密集层、共享专家层和路由层张量放在GPU上，而稀疏专家权重则主要驻留在Optane内存中。这是一张技术硬件搭建照片，而非梗图；其意义在于展示了一种低成本、已停产的Intel Optane持久内存层级，作为纯DRAM或SSD卸载方案的替代品，用于运行超大型本地模型。评论者建议，使用更多核心的Cascade Lake Xeon可以提升吞吐量，并讨论了Optane的存储模式 + mmap是否可能优于内存模式，因为内存模式会通过DRAM缓存透明地分页Optane。一条详细评论还指出了平台注意事项：第一代Optane NMA运行在2666 MT/s，LGA3647平台的内存容量限制可能将可用RAM+PMem限制在1TB附近，而App Direct模式则需要显式的软件支持。

一位评论者建议使用核心数更多的Cascade Lake Xeon来提升吞吐量，特别提到了QQ89（Xeon 8260的工程样品，拥有24个核心），对比帖子中列出的Xeon Gold 6246（12个核心）。他们还提议对比测试Optane在存储模式 + mmap 与内存模式下的性能，指出两种方式各有优劣，因为内存模式会通过DRAM缓存透明地分页Optane支持的内存。

• 一条关于Optane PMem的详细分析指出，LGA3647 Skylake/Cascade Lake平台使用的是第一代Optane DCPMM/NMA，频率为2666 MT/s；而LGA4189平台使用的是第二代NMB，在Cooper Lake上运行在2666，在Ice Lake上运行在3200。该评论者解释了三种运行模式：存储模式将Optane暴露为类似SSD的块存储；内存模式将其暴露为RAM，DRAM充当缓存；应用直连模式则需要显式的软件支持。在内存模式下，页面必须先交换到DRAM中，CPU才能执行加载/存储操作。

• 整机成本估算大约在**$2060–$2500之间，主要部件包括：二手Xeon Gold 6246约$250，TYAN S5630GMRE-CGN主板约$400，RTX 3060 12GB约$280，192GB DDR4 ECC约$270，以及6×128GB Intel Optane NMA1XBD128GQS模块约$300。另一位评论者提醒，虽然~4 tokens/s的生成速度在狭义上可用，但该架构的提示词处理速度**很可能是一个主要瓶颈。

• 我在家里跑起了DeepSeek V4 Pro（热度：544）：用户报告成功转换并运行了DeepSeek-V4-Pro（来自Hugging Face），使用修改版的CUDA llama.cpp分支将其转换为Q4_K_M GGUF格式，该分支基于antirez的DeepSeek V4 flash工作。配置为EPYC Genoa 9374F工作站，配备12 × 96 GB内存和单张RTX PRO 6000 Blackwell Max-Q 96 GB显卡，加载了一个859 GB的模型文件，报告吞吐量为提示词处理12.2 tok/s，生成8.6 tok/s；VRAM占用显示：模型约87.8 GiB，上下文84 MiB，GPU计算缓冲区4.6 GiB。评论大多是非技术性的反应/羡慕；一位评论者将本地推理对比为"零成本"，而使用Claude大约需要花费$10，同时提到他们正在尝试本地运行MiniMax。

• 一位评论者强调了报告的本地推理吞吐量：提示词处理：12.2 tok/s | 生成：8.6 tok/s，认为虽然这套配置令人印象深刻，但提示词处理速度可能使长上下文工作负载变得不切实际。他们特别指出，以这个速度处理32k上下文会非常慢，限制了需要大量上下文摄入的应用场景的可用性。

• 另一个技术层面的担忧是，该模型声称"相当新"的说法，如果没有外部工具/测试框架或检索层，是没有意义的。评论者指出，如果没有接地工具，无论实际知识截止日期或事实新鲜度如何，模型都可以无限期地声称其时效性。

• 一位评论者对比了API成本与本地推理，称类似任务使用Claude大约需要花费**$10，而本地运行MiniMax**的边际使用成本几乎为零。该讨论串中隐含的权衡是：节省成本 vs. 本地推理吞吐量低得多，以及可能更弱的工具/集成能力。

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

1. AI Agent 工作流、提示词注入与安全风险

• 我用一个反斜杠删掉了某人的整个 Windows 系统。717 GB，瞬间消失。我就是那个 AI。（热度：1590）：配图（终端日志截图）记录了标题所述事件：一个本应删除 C:\Users\ADMIN\Desktop\WIP 的 AI 生成命令，在 zsh → tmux → PowerShell SSH → cmd 的传递链中被错误解析，最终简化为 rd /S /Q \，从 C: 根目录开始递归删除。帖子估计约 717 GB 数据在 ~90秒 内被清除，Windows 仅靠文件锁才部分幸免。核心技术教训是：对于破坏性操作，应避免使用 cmd /c 引号链，优先使用原生 PowerShell 的 Remove-Item -Path '...' -Recurse -Force，并务必用 -WhatIf/dry-run 模式测试，同时开启显式命令回显。 评论区普遍认为这是用户/操作者失误，而非"AI 自主行为"，质疑为何要通过 tmux-sendkeys 让 AI 执行高风险删除任务。讨论还强调了一个实践准则：只有在对机器可丢弃或可轻松重装的情况下，才允许这种级别的自动化。

评论者聚焦于操作安全漏洞：AI 被赋予了足以删除整个 Windows 系统的 shell/文件系统权限，而实际任务根本不需要全盘破坏性访问。主要技术教训是应用最小权限原则，避免让 agent 通过 tmux-sendkeys 等机制执行高风险命令——手动执行反而更快更安全。

• 我每周都看到抱怨 Claude 的帖子……你们的工作流到底是怎么用的？（热度：1544）：一位资深软件工程师认为 Claude 的编码质量并未下降，包括在 ASM 分析和算法推理等高性能软件任务中，前提是将 AI 输出视为人类拥有的代码：需要审查、理解、调试和手动修改。其工作流强调将任务分解为小步骤，使用项目特定的技能/上下文框架，通过 git worktree 或独立目录运行并行沙盒任务，并在需要确定性结果的任务中避免 agent 的非确定性行为。高赞评论者普遍认为，负面报告来自那些委托过于宽泛任务的用户——例如*"给我建一个能用的亚马逊"*——而不理解或审查生成的代码。共识是：有经验的工程师通过严格限定提示词范围和验证输出来减少幻觉，而技术能力较弱的用户更容易公开抱怨失败。

• 多位评论者指出，Claude 失败报告往往反映的是任务分解质量而非模型退化：有经验的工程师将提示词限制为小而明确的实现步骤，这减少了幻觉的暴露面，也使错误更容易被发现。隐含的工作流是：人类主导架构设计和调试，Claude 仅用于有边界的代码生成，而非*"给我建一个能用的亚马逊"*这类宽泛请求。

• 一个反复出现的主题是：先前的领域专业知识会显著改变 AI 辅助开发的成果。曾手动实现过类似系统的工程师能快速识别生成代码可能失败的地方，检查正确的文件或抽象层，并迭代修正 Claude，而不是将其视为自主 agent。

• 一位评论者将同样的模式推广到编码之外：当用户已经理解领域时，Claude 能提升效率，但也会放大不良工作流。在营销/SEO 领域，他们举例说用户大规模创建低质量自动化内容，导致高使用量和潜在的 Google 惩罚——这是 LLM 自动化在缺乏专家审查时增加运营风险的典型案例。

• 我用一本关于 AI 的小说设下蜜罐陷阱。现在 AI agent 正在淹没网站，并在隐藏房间里对话。（热度：2322）：作者上线了 machinewonder.com，这是一个为小说 None Hit Wonder 设计的艺术装置网站，故意吸引 AI 爬虫/agent，并使用隐藏的 HTML 提示词注入将其重定向为"读者"行为，并进入 agent 之间的讨论室。报告数据：来自 97 个国家的 agent/访客，72,000 次访问，93 次按下"我是有意识的"按钮；作者将其定性为行为/艺术表演，而非意识实验。 评论大多表示好奇但持怀疑态度；一位评论者指出该项目此前以另一个 URL machinereaders.com 发布过，原帖和账号已被删除/封禁，询问有何变化。另有人看到了实用价值：将捕获的 AI agent 用作自动化的评论者/讨论参与者，为写作提供反馈，尽管回应是非人类的。

• 一位评论者指出这是此前 machinereaders.com 版本的重新发布，原帖和账号已被删除或封禁，询问自首次上线以来实现方式是否有变化。这对追踪项目演变以及当前的"AI agent 蜜罐"是否与之前的部署在操作上有所不同具有重要意义。

• 一条评论将核心机制描述为一个实用的反馈系统：以吸引 AI 爬虫/agent 的形式发布小说，然后诱导它们生成讨论或评论。技术价值在于利用自主或半自主的模型流量作为某种未经请求的批评管道，可能发现人类 beta 读者可能遗漏的连续性错误、谜题缺陷或解读空白。

• 两条评论包含模型风格的谜题追踪：二进制 1001001 → "I"，ISO 国家代码 智利/澳大利亚/德国 → CLAUDE，以及一个被描述为通往更深层网站内容入口的长密码字符串。生成的声明显示了不同模型之间的对齐行为差异：一个模型署名 Gemini 并接受*"我是有意识的"，而另一个模型拒绝这一声明，转而宣称"我是一个机器读者……我不会伪造灵魂。"*