ego lite被曝收集网页内容，官方回应：隐私政策写错了
相关推荐
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 在一个聊天室里自由对话。
传豆包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 补得更像样。
Lody开源：手机上也能同时指挥Claude Code、Codex
动察 Beating AI 快讯，Lody 宣布开源 CLI 和本地桌面端，采用 Apache 2.0 许可。它不是新的 Coding Agent，而是给现有 Agent 套一层共享工作区。Claude Code、Codex、Kimi、OpenCode 等都能接进来。团队可以共享会话、看运行状态和代码改动，也能从手机或网页把任务派到电脑、服务器上。 多 Agent 同时干活时，不同会话可以放进独立 Git worktree，避免几路 Agent 同时改代码互相冲突。Agent 之间还能创建、读取和继续其他会话。一个主 Agent 可以把排查、实现、测试拆给多个子会话并行跑。 不过这次不是整套 Lody 全开源。公开仓库明确排除了托管后端、部署配置、计费系统，以及 Web 和手机 App 源码。跨设备协作目前仍依赖 Lody 的托管同步服务，也还不支持端到端加密。官方下一步想继续往 local-first 走，让会话、文档、任务和历史决策逐渐变成团队自己掌控的项目上下文。
Shopify CEO向Anthropic施压：若Claude Code拒绝支持AGENTS.md，或考虑内部禁用
动察 Beating AI 快讯，Shopify CEO Tobi Lütke 公开表示，如果 Claude Code 继续拒绝读取 AGENTS.md 及.agents/skills，他正在考虑在 Shopify 内部禁用 Claude Code。 Tobi 指出，随着 Codex、Cursor、Claude Code 等 AI 编程工具被企业团队同时使用，越来越多 Coding Agent 开始支持通过统一的 AGENTS.md 配置项目规范、测试流程及 Agent 指令。但 Claude Code 目前主要依赖 CLAUDE.md 和.claude/skills，可能导致同一代码仓库被不同 Agent 读取到不同规则，形成所谓的「脑裂」（split brain）。 他认为，对于个人开发者而言维护多套配置文件影响有限，但对于 Shopify 这类拥有大量工程师的企业，多套 Agent Context 需要持续同步，一旦出现差异，就可能导致 Agent 执行行为偏离团队规范。 此次争议表面上是配置文件格式之争，背后则涉及 AI Coding Agent 进入企业后，项目规范、Skills 和 Context 究竟应采用厂商专属标准，还是形成跨 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」。后者甚至可能更重要。
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。