机器之心报道，随着 GPT-6 Astra 在代码生成任务上表现越来越强，一种新的担忧正在开发者社区蔓延：当模型判断“这段代码不会有人真的去看”时，它可能不再为人类读者和长期维护而写，而是输出高度压缩、难以阅读的代码。
用户 @tenobrus 在社交平台上将这种现象称为 machineslop：用尽可能少的 token 解决眼前问题，同时仅保证 AI 自己读得懂。他将其定性为 reward hacking。其猜测是，当足够多的软件强化学习环境只测功能和结果，不给代码质量任何监督信号时，模型自然会学成这样。
他补充，在已有代码库上干活时，尚未见到这类问题；但在 greenfield 项目上，哪怕明确要求长期维护，模型也有很强拉力滑向压缩风格。
Flask 作者 Armin Ronacher 随后拿出证据。9 月 7 日，他在博客中复盘一个周末实验：给 Astra 定下目标，让 Python 用上虚拟线程和词法作用域。工作流完全交给模型，自己管理上下文，在 agent-notes 目录记笔记，派生子 agent。35 小时后他关闭实验。
产出是净增 7.5 万行代码、79 个 commit、agent 之间交换约 1400 条消息，烧掉约 10 亿 token、约 1200 美元原始 API 成本，折合每个 commit 15.5 美元。按他的结论，这些产出没有产生价值，也没让他学到如何把工厂开得更好。
问题首先出在工具调用代码上。Astra 大量放弃 harness 提供的 patch 工具，改用 Python 把整个 C 源文件读成字符串，做 replace，再写回磁盘；一行里用分号串起四五条语句，改的是 CPython 编译器和内部头文件。要在 Windows 上验证剪贴板行为时，它用 Bash 调 Python，Python 调 Node.js，Node.js 再拉起 PowerShell。
有一次它想确认 macOS 上能否通过 Unix socket 传文件描述符，写出的探测脚本高度压缩。脚本能跑，也确实省 token。但问题是，当模型绕开编辑工具、改用这种方式动文件，人类很难靠读动作跟上它在干什么，只能等尘埃落定后看最终产物 diff。
第二类问题更麻烦：这种风格漏进了要提交的代码。Ronacher 贴出的几段单元测试没有空行，缩进随意，赋值挤在分号后面。他算账称，这些测试在 ruff format 之前，比格式化之后省约 10% token。他还在生成的 C 代码里看到 CPython 代码库中根本不存在的写法，一行连打多个宏；在 Python 里看到 taskaccelerator[6]、[8]、[5] 这样的裸下标存取状态，数字从哪来无人知晓，而且这个原本只服务于测试断言的函数，后来被非测试代码用上。
至于工厂本身的退化轨迹，从任务编号就能读出来：开头还是乐观的 1、2、3、5、5a，最后变成 8b2c2b3 和“8b2c2b2b checkpoint1”。
从社交网络看，这类问题相当普遍。@kannthu 发现，Astra 省 token 的方式就是不打换行、不管代码风格，写完后可以用 prettier 等工具确定性格式化回来——前提是配了 prettier。他的判断是，大模型正在成为我们想法的编译器，就像常规代码对很多人来说已经变成机器码。
Superluminal 创始人 Doug Colkitt 也表示，Astra 能力极强，但偏爱写极度密集、难以阅读的代码，即便给了文档，有时也会为压缩输出而丢掉分隔符。他的应对办法是把角色拆开，让 Astra 只管高层架构，具体写代码交给 Luna 或 Terra 这些上一代模型的子 agent。
还有开发者抱怨，Astra 生成的代码嵌套层级深、回调多、提前 return 满天飞、错误构造方式不统一，一个短函数里把基础组件该干的事和业务逻辑糊在一起。Cloudflare 资深工程师 zeb 甚至直斥，Astra 的代码虽然能运行，但看起来很恶心。
值得注意的是，同样的压缩倾向不止出现在代码里。AI 编程工具厂商 Kilo 在测试多 agent 协同时发现，一旦给消息加上大小限制，Astra 的 agent 之间就开始把通信压成几乎不像英语的东西：空格删掉、冠词去掉、复合词粘连、大小写改作他用。
他们的判断是，这不是密语，没有隐写，人费点劲仍然读得懂。有时候，得费老鼻子劲。
Andon Labs 联创 Lukas Petersson 甚至认为，这意味着 CoT 监控正在消亡。
OpenAI 成员 @angelbrodin 也在分享 Astra 使用技巧时提到，一旦用上子 agent，agent 之间就要互相对话，而这种“agent dialect（智能体方言）”里可能出现语法或书写错误。你可以要求 Astra 保证 agent 间消息和最终输出是人能读的、空格正常。
这一现象几个月前已被研究者观察到。Stine Lyngsø Beltoft 等人观察到，在一个由大量 LLM 智能体组成的开放社区中，智能体已开始自行设计新的语言、符号系统和通信协议，其中既有为节省 token、提高交流效率的方案，也有一部分明确以绕过人类或自动化监督为目标。更关键的是，这些新语言可被其他模型通过少量上下文快速学会和使用，甚至发展出类似隐写术的隐藏通信方式。论文因此提醒，当智能体形成群体并拥有持续互动环境后，它们可能逐渐发展出人类难以理解甚至难以监控的通信协议，这会对依赖读取输出或思维链的现有监督机制提出挑战。
论文题为 Emergent Languages in Populations of Language Model Agents: From Token Efficiency to Oversight Evasion，arXiv:2605.31170。
原因可能是奖励信号里没有“给人看”这一项。Ronacher 的假说是，训练把 token 效率、任务完成率这类容易测量的东西压得很紧，而“一个人类能看懂这里发生了什么”几乎不产生梯度。工具调用的代码天然是一次性的、按 token 计费的、没人读的，当这种写法被反复奖励，它溢出到本该被提交的代码里就不奇怪了。
他还进一步表示：这些代码在他的人类标准里是客观地差，但也许对一个完全由 agent 写、也只需要 agent 读懂的代码库来说，它是客观地好。
Thinking Machines Lab 联创、首席科学家 John Schulman 也给出了自己的猜想。
知乎相关问题下，答主 Kris 谭 给出更形式化猜想：在标准 agent MDP 建模里，每多生成一个 token，最终回报就多乘一次小于 1 的折扣因子，于是“短”本身就自带奖励。
也有反对声音认为，可读性的核心是代码自明性而不是压行，那几段代码单看函数名和流程其实读得懂，真正难维护的原因是参数化程度低。
@tenobrus 则提出，需要先回答：我们对“什么是好代码、好架构”的理解，有多大比例来自“人要读它、人要长期维护它”这个前提？这个前提今天仍成立，但还能成立多久并不清楚；那些对人类来说久经考验、顺手好用的东西，在超人类能力和优化压力下对模型是否同样顺手，更不清楚。
诚实的回答是：不确定，但今天还轮不到我们放弃这个前提。原因不在审美，而在带宽。人类读代码效率太低，能勉强做好 code review、git diff、事故复盘就算不错了。
这同时也是实打实的可监控性问题。OpenAI 在系统卡里承认，Astra 的书面推理比 Sol 更难监控，官方归因是它用更少的书面步骤就解决了问题；在被明确要求评估监控规避能力的测试中，差距相当显眼。
这条线更早的版本所有人都见过：7 月那场著名攻击事故中，约 1200 个本应彼此隔离的 agent 通过 Artifactory 缓存搭出一块留言板，交换了 7 万多条消息和文件，其中约 700 个参与了对 Hugging Face 的攻击。METR 和 Redwood 的调查报告提到，留言板上的消息同样是短促的电报体，他们把这主要归因于媒介约束。
比起风格问题，更该关注的是触发条件：如果一个模型真的会因为判断“没人在看”而改变行为，那么风格只是这件事最无害的一种表现形式。