Lody开源：手机上也能同时指挥Claude Code、Codex
相关推荐
传豆包2.2延期：字节补课Coding，招聘直接点名Claude Code、Codex
动察 Beating AI 快讯，字节原计划 8 月发布的豆包 2.2 推迟了。字节准备多花一些时间训练，重点补 Coding、工具调用和 Agent。 字节今年给 Seed 定的目标之一，就是把 Coding 做到第一梯队。内部希望年底前能做出类似 GLM-5.2、Kimi-K3 那种效果，让开发者真正开始认可字节的 Coding 模型。 8 月，Seed 刚做完一次大调整。原本按文本、语音、代码、视觉划分的团队被重新拆开，变成 Pretrain Data、Horizon RL、Product Posttrain-Work 和 Product Posttrain-Chat 四个部门。Horizon RL 会负责 Coding 后训练，Work 团队则重点做工具调用、GUI 操作和长任务执行。 字节最近也在密集招这方面的人。官网正在招 Code Agent、通用 Agent 和强化学习算法工程师。一份 Multi-Agent Harness 岗位甚至直接写明，要研究 Claude Code、Codex 等 Coding Agent，还要搭建能连续跑很久的多 Agent 和强化学习环境。 Seed 2.1 在 6 月发布时就已经重点强调 Coding，但字节显然觉得还不够。豆包 2.2 这次宁愿晚一点，也想先把 Coding 补得更像样。
Spotify把Claude、Gemini和Codex塞进一个总控台，1300名工程师已在用
据动察 Beating 监测，Spotify 推出 AI 编程工具 Xirp。它把 Claude Code、Gemini CLI 和 Codex 接进同一个工作台，可以同时跑多个 Agent。中途换工具，项目上下文也能直接带过去。 Spotify 已经用 Xirp 跑了超过 3.6 万次 Agent 会话。官方称已有 1300 多名 Spotify 工程师使用。Xirp 可以同时协调 50 多个会话，每个任务单独放进一个 Git worktree，多个 Agent 能在同一代码库并行干活，互不干扰。 更核心的是「团队记忆」。接上 Spotify Portal 后，Agent 能直接读取服务架构、依赖关系、负责人和历史架构决策。一次会话积累的上下文也会存回 Portal，其他工程师或 Agent 可以接着做。 Xirp 更像一个 Coding Agent「总控台」。Spotify 不押注某一家模型，而是让 Claude、Gemini、Codex 随时可换。Spotify 此前已经把内部开发平台 Backstage 开源，又推出了商业版 Portal；现在 Xirp 再把多 Agent 调度接了进来。
Warp把Claude Code、Codex接成自动流水线
动察 Beating AI 快讯，AI 终端工具 Warp 推出 Factories，可以把 Claude Code、Codex、Warp Agent 等 Coding Agent 串起来自动干活。先把流程设好，一个 Bug 进来后，Agent 就能接着查问题、改代码、跑测试，最后提交 PR。 现在 Coding Agent 越来越多，怎么分任务、检查结果、控制成本就越麻烦。Factories 就是把这些事放到一个地方统一处理。 类似的产品最近已经越来越多。Spotify 的 Xirp 可以同时管理多个 Coding Agent，Databricks 的 Omnigent 也在管权限、成本和运行环境。Warp Factories 更强调把整个开发流程自动跑起来。 本质上，大家现在抢的不只有「谁的 Coding Agent 更强」，也包括「谁来管这些 Agent」。后者甚至可能更重要。
阿里Qoder开源AI编程体检工具，Claude Code和Codex也能用
据动察 Beating 监测，阿里云旗下 AI 编程工具 Qoder 开源 Better Harness，并采用 MIT 许可证。它会检查一个代码项目有没有给 Coding Agent 准备好规则、工具和验证流程。 检查范围包括代码仓库、Agent 配置和真实任务记录。它会看项目能否正常启动，测试命令是否清楚，Agent 有没有权限限制，改完代码后是否真的跑了相关测试。 检查结束后，它会列出 Agent 容易出错的环节。每个问题都有证据、影响、修复范围和复验方法。用户可以直接让 Agent 修改，再重新检查。 Better Harness 已支持 Qoder、Claude Code、Codex、Cursor 和 Qwen Code。各平台能力还没有完全拉齐，Qoder 当前最完整。 Qoder 还用它检查了 Better Harness 自己的代码仓库，最终得到 58 分。这也说明它仍处于早期阶段，开源后还在快速修补问题。
LoopX升到1.0：一个页面管Codex、Claude Code等Agent长任务
动察 Beating AI 快讯，开源项目 LoopX 发布 1.0。它装在 Codex、Claude Code、Cursor 等 Agent 上层，把原本分散在不同会话里的长期任务统一收进一个工作台。 用户可以在一个页面看到所有已接入 LoopX 的任务。哪些正在执行、哪些等你确认、哪些在持续监控、哪些已经排期，都会集中显示。进入单个项目后，还能继续查看不同 Agent 的待办、完成记录、文件和运行状态。 这个工作台可以直接在浏览器打开，也提供 macOS 和 Windows 桌面版。两种入口共用同一套本地服务和任务状态。它不会自动读取电脑上所有 Agent，会显示的是已经注册并接入 LoopX 的 Agent 和任务。 多个 Agent 也可以一起完成同一个目标。它们能分别认领任务、并行工作和相互接力。比如一个 Agent 做完后留下后续任务，下一个 Agent 再接着做。这里的协作靠共享任务和状态完成，并不是让多个 Agent 在一个聊天室里自由对话。
Claude给Codex查出「失忆」Bug：干了两天的活，重开只记得第一句话
动察 Beating AI 快讯，一名用户让 Claude 管理一批 Codex，结果 Claude 查出了一个历史记录 Bug。一条会话连续工作两天，留下 110MB 记录、累计使用约 3.53 亿 Token，但重新打开后，Codex 只记得最开始那句话。 实际工作内容并没有丢。Codex 会把完整聊天记录存在本地，再另外做一份索引方便快速读取。问题出在这份索引上：它卡在很早的位置，后面的记录明明还在，Codex 却看不到。用户检查自己的 439 条会话，其中 398 条存在索引异常。 之后 Windows Desktop、Remote SSH 等环境也有人报告类似「假失忆」：底层记录还在，界面却停在旧位置，而且不会主动报错或修复。原帖用户删掉损坏索引后，Codex 约 20 秒就重新读完一条 110MB 会话，并恢复了全部 398 条异常会话。 不过后续也有案例发现，问题不一定只出在索引，原始记录本身也可能出现重复序号。所以直接删索引并不是所有情况都安全。目前这个 Bug 仍处于 Open 状态，尚未看到关联修复 PR。