昨天晚上睡觉之前，我给 Codex 安排了一大批任务。
这其实是我很习惯的一种工作方式。反正要睡觉了，接下来六七个小时不会操作电脑，那就把能做的事情都交给 AI，让它在后台慢慢干。等我第二天早上起来，看看完成了什么，再决定下一步。之前用 Claude Code 的时候，我经常这么干。
结果这次有点离谱，睡了一觉起来，Codex 还在运行。七个多小时过去了，任务没结束。更让我难受的是，我去看它的执行过程，发现有些工作其实已经完成了，但是它没有汇报，也没有交付。我只能继续等，可能再等一个小时，也可能三个小时，甚至更久，我不知道。
最近从 Claude Code 切回 Codex 之后，这类事情发生得越来越多。我也开始重新思考一个问题：一个 AI Agent，究竟应该怎样工作，才算真正好用？
十几道数学图，Codex 选择一张一张画
我最近一直在开发自己的备课工作台，前段时间整理了两千多道数学题。题目需要扫描、识别、核对，涉及图形的还要重新绘制。
之前这些事情主要交给 Claude Code，它处理批量任务有个习惯，会主动安排多个子代理。比如我给它十几道需要绘图的题，它会把任务拆开，几个 Agent 同时画图，最后再由主代理整理结果，速度很快。我印象中，有时候二十分钟就能完成四五张。
最近换到 Codex 之后，发现完全不是那么回事。同样给它十几道题，它居然自己一张一张画。画完第一张，再画第二张，第二张完事，再去处理第三张。一张图二三十分钟，十几张图就得好几个小时。
我最开始以为是模型本身太慢。后来仔细看了一下执行过程，才发现它根本没有主动使用多个子代理。我提醒它之后，它倒是开始并行了。这说明它并非完全没有这项能力。
可问题又来了。
子代理完成工作，主代理又卡在结果汇总
Codex 开始使用子代理之后，一部分任务确实完成得快了一些。但我随后发现，子代理显示已经完成，主代理却还在继续工作。它需要整合结果、检查文件、处理剩余任务。然后又是一段漫长的等待。
所以现在看来，子代理只能解决一部分问题。任务拆分、并行执行、结果回收、阶段交付，这其实是一整套工作。光有几个子代理同时干活，并不能保证整体效率。尤其是我晚上给它大量任务的时候。我的预期是它能够先把事情拆成几个阶段，完成一部分就交付一部分。哪怕后面的工作出现问题，前面的成果也可以先拿来使用。可是 Codex 很喜欢把全部工作放在同一轮任务中，最后一次性汇报，于是就出现了开头那种情况。
七个小时过去了，内部可能已经完成了很多事情，但我作为用户，仍然拿不到一个明确的阶段成果，我觉得这比单纯的运行速度慢更麻烦，因为我无法预测自己的工作进度。
自己写的文件 Codex 还要开浏览器用鼠标点
最近还有一件事情，把我看得有点傻眼。
我让 Codex 做一个交互式 HTML 设计稿，这个东西没什么复杂的。我需要讨论一个软件的界面设计，希望 AI 把自己的设计思路写成 HTML，在浏览器里展示出来。我看看布局、颜色、交互，再告诉它哪些地方需要修改。
之前跟 Claude Code 做设计的时候，我们也是这么干的。它把 HTML 写完，告诉我文件在哪里，哪些东西可以点击，然后我自己打开看，有问题就继续聊。因为它本来就是一个设计讨论稿。
结果 Codex 写完 HTML 之后，开始打开 Computer Use，在自己生成的页面里进行鼠标操作。点这里，点那里。看一下，再点一下。我当时真的有点惊讶。这个 HTML 文件不是它自己写的吗？源码就在它手里。如果需要改变按钮状态，完全可以通过代码实现。如果需要检查某个交互，也可以使用程序化工具。
但它偏偏选择像人一样操作页面。截图、分析、点击、等待，然后再截图。这些操作本身都需要时间和计算资源。对于我这种只想尽快看到设计稿的人来说，整个过程就显得非常多余。
设计稿没必要当作正式产品验收
后来我跟 ChatGPT 讨论这件事，它提出一个观点。
HTML 写完之后，确实应该检查实际渲染效果。因为代码正确，不代表页面显示一定正确。这个道理当然成立，如果软件准备正式上线，我也希望 AI 能够认真测试。但这里有一个非常重要的前提：这次交付的究竟是什么？
我要求的是设计稿，设计稿就是拿来讨论、拿来修改的。它本来就没有确定最终应该长什么样，甚至某些按钮只是为了让我感受一下交互方式，根本没有真正的业务逻辑。这种情况下，AI 完成基本设计，保证文件能够正常打开，就可以交给我了。至于好不好看，布局合不合理，交互舒服不舒服，本来就需要我来判断。它没有必要把一个等待我反馈的初稿，按照正式产品的标准反复检查。
而且在我的工作方式里，这部分验收本来就是我负责的。我不需要 AI 把所有事情全部做到它自己满意，我需要它在合适的时候把东西交给我。些工作需要 AI 自己验证，有些工作本来就应该交给人判断。
如果连这一点都分不清，Agent 就很容易做大量看似认真、实际上没有多少价值的事情。
我的工作台为 AI 准备了另一套操作方式
这件事让我想到之前开发备课工作台时，与 Claude Code 确定的一套设计。
我的工作台有两种使用方式。前台是给我看的，我可以查看教材地图、讲义、题目和图形，进行判断和验收；后台则是给 Agent 使用的，它可以直接访问数据库、调用绘图组件、修改文件、执行代码，也可以进行各种自动化检查。
为什么要这样设计？因为我不会编程，也不需要去看那些代码。而 AI 本身就能够操作代码和数据库，它没有必要跟我一样，一个按钮一个按钮地点击。我们各自使用自己最擅长的方式，然后通过工作台完成协作。
这套设计当时就是 Claude Code 帮我建立起来的。它很清楚，我只需要看最终的成品，至于中间采用什么技术路线，应该由它自己判断。可切回 Codex 之后，我发现它有时候明明能够直接操作后台，却更愿意使用面向人类的前台界面。这让我开始怀疑，两个产品在 Agent 工作方式上的默认倾向，可能存在相当明显的差异。
如果一个软件没有提供可以直接操作的接口，AI 能够像人一样使用它，Computer Use 确实解决了很多以前无法解决的问题。但如果一个软件本来就提供了 API，甚至整个系统就是专门为 Agent 设计的，那么直接调用这些接口通常会更高效。Computer Use 在这种情况下可能只会增加额外步骤。
Agent 需要学会判断什么时候应该用它，什么时候应该放弃它。
OpenAI 也承认子代理不足和过度测试的问题
后来我查了 OpenAI 官方的 GPT-6 Astra 使用指南，里面有两个地方很有意思。
一个是子代理委派，官方提到，模型可能没有充分使用子代理，需要明确告诉它在适合并行的情况下主动分工。另一个是测试与验证，官方也提到，模型有时候会对一些很小的修改进行过度测试，需要根据任务情况控制验证范围。看到这里，我突然觉得，自己最近遇到的这些问题，好像确实有一定的共性。
这也说明，这些问题已经进入了 OpenAI 的官方技术讨论范围，它们并非只有我一个人在意。
还有一个很讽刺的地方，我之前从 GPT-6 Astra 换到 GPT-6.1 Sol，是因为 Astra 的额度消耗太快。这个问题 Sol 确实改善了，效果相当明显。以前一个复杂任务可能消耗掉大量额度，现在 Sol 跑很长时间，剩余额度也没有明显变化，我很满意这一点。
但另一个问题变得更加明显，任务太慢了。一两个小时很常见，遇到复杂工作，三四个小时，甚至七个小时还没结束。所以对我来说，Sol 解决了一个问题，又留下了一个很严重的问题。而我之前使用 Claude Code 时，基本上不需要过多操心这些事情。我正常说话，把任务交给它。它主动拆分，主动并行，完成阶段工作后告诉我结果。
当然不同任务的耗时也不能直接拿来作严格的模型性能比较，但在目前这些软件开发、数学绘图和设计稿任务里，两者带给我的使用体验确实存在很明显的差距。
我觉得，评价 Agent 的效率，只看 Token 消耗远远不够。还要看它花了多少时间、进行了多少次无意义的操作、让用户返工多少次，以及什么时候能够真正交付结果。
我希望 AI 成为一个会安排工作的同事
我一直把 Claude Code 形容成一个很好用的同事。
它未必每件事都能做到最好，但在我过去半个多月的开发经历里，它能够比较准确地理解我的工作方式。我不需要告诉它每项任务应该怎样拆分，也不需要不断强调要使用子代理，它会根据任务情况安排执行。
而现在用 Codex，我发现自己反而需要学习怎样管理 Agent。我得告诉它什么时候该并行，什么时候该交付，什么时候不要继续验收，什么时候应该使用代码而不是鼠标。
这些事情可以通过全局指令去改善。但我认为，一款面向普通用户的 Agent 产品，不应该长期依靠用户自己编写大量工作规则，才能拥有比较正常的效率。尤其是对我这样不懂编程的人。我愿意讨论软件应该有什么功能，愿意判断界面好不好看，也愿意验收数学图形是否符合教学要求。但我不希望自己还要花大量精力研究，怎样让一个 Agent 正确安排其他 Agent 干活，这些应该是工具本身擅长的事情。
所以我现在仍然期待 OpenAI 的下一次更新，但我不一定需要一个能够解决更多前沿数学问题的模型。如果下一代 Sol 只是更懂得拆分任务，能够及时交付阶段成果，减少重复测试，合理选择后台工具，并且保持现在的额度经济性，我就已经会觉得它好用了很多。
毕竟我买这些 AI 订阅，最终目的是把自己的事情做好。
一个任务跑了七个小时，模型可能做了很多工作，但我仍然不知道哪些东西已经可以拿来使用。这才是我现在最希望 Codex 改变的地方。