界面好看，有空试试，不过学习一个新工具成本还高，现阶段专业的还是脱离不了 ide 或者 codex cc 成熟的 agent 生态，以及 vb 上绕不过去的 codex app 大山。如果给成熟的 agent 做“外围插件”，什么记忆系统之类的，难免会受限，像支持 hook 、plugin 的 agent 也没多少，更别说更深层的定制改动了，不够自由，但自己做 agent ，同质化和换工具成本高。如果只是免费注册用 api ，推广的吸引力还是不够，毕竟凹凸曼大善人，时不时来个 bug gpt5.5 就 free 了，还有一堆中转站。
我实践时也发现 op 所言，它完全缺乏全局观，agent 本身只是个“操作系统”，在复杂老项目中，完成需求任务，更多的瓶颈不是上下文大小、agent 能力，而是上层应用，只有 agent ，AI 不知道业务架构，AI 无法从一个页面上，定位到你成百上千的仓库改哪个文件，AI 无法完成测试闭环，这背后还有需求分析、业务数字化、代码地图、质量审计的事情，以及模仿阿尔法狗进化的老路子，让 AI 自己学习经验，试错才是最宝贵的，这也是我边做需求边做 ai 工作流头疼的点。
多 agent 弄个对抗网络的设计，之前好像也见过，但实际开发并不会像 demo 那样一段话生成***，自由度没这么高，也不是单仓库项目，往往是涉及多个仓库，多个包。
多 agent 对抗、规范沉淀，加上需求复杂性导致不可避免的上下文压缩，感觉有让 AI 偏离原有的产品 prd 设计方向的风险。
另外对比图也过于夸张了，opus4.7 不至于，一句话生成***不仅听腻了，感觉也并不是好的案例，先弄一个网盘系统，再用标准的产品 prd ，对比看或许更明显。