我让Codex和Claude Opus处理同一个Java AI单体代理项目

我在自己的Java小项目上做了一次小实验，结果比预期的要混乱。需要说明的是，我是在2026年4月19日做的最终对比审查。对于AI编码工具来说，这个结果已经有些时效性了。这个项目是一个多模块的Java单体应用，包含Telegram机器人、代理循环、工具、内存、流式响应，以及本地模型和OpenRouter模型的混合。当时我已经开始将部分代理逻辑从Spring AI迁移到自己的FSM/ReAct流程中，但代码仍然有很多bug。于是我把整个项目复制到两个独立的分支中，给Codex 5.3和Claude Opus 4.6相同的模糊提示，让两个代理几乎完全自主地工作。规则故意设得很简单：* 按你认为正确的方式完成任务 * 通过现有测试（包括端到端测试） * 运行审查 * 修复审查意见 * 重复直到只剩下小意见。基本上就是纯粹的“氛围编码”。Claude Opus在多个地方生成了更吸引人的架构。最好的部分是关于流式输出的。它创建了原始模型块和可展示给Telegram用户的文本之间更清晰的界限。这很重要，因为模型不会流式输出完整的句子。它们可能会发送 `<th`，然后是 `ink>`，接着是内部推理，再然后是结束标签。如果你只在流式完成后清理最终文本，那么部分垃圾可能已经到达了用户。从这点来看，Claude的想法更好：在发出用户可见的事件之前进行过滤。Codex则不那么优雅。更多逻辑绑定到了上下文变异和后处理上。感觉像是以后可能难以维护的代码。但当我要求生成时序图/调用链时，我发现了令人不安的部分：Claude的一些漂亮架构实际上并没有被使用。测试通过是因为旧的Spring AI流式路径仍然覆盖了端到端场景，而不是因为新的ReAct/FSM流式流程被正确集成。这改变了我对整个结果的解读。Codex也有自己的问题。它引入了更多的状态和更高的并发风险。其中一个分支甚至在完整的验证运行中未能通过一个REST测试切片。但Codex也添加了一些实用的东西：* 针对卡住的AI流，有超时和回退机制 * 重启后的对话历史恢复 * 在向用户显示链接前进行URL清洗 * 在流式约定中更好地区分进度和最终答案 * 对Telegram进度更新进行批处理。并非所有代码都漂亮。有些正是你后来想要简化的那种代码。但更多的代码与工作产品相关联。对我来说，这是主要教训：使用AI编码代理时，“好的架构”和“实际执行的代码路径”不是一回事。第二个实验类似。我比较了Codex 5.3和同一个领域的一个较新的GPT模型。同样，更强的模型提出了更整洁的抽象，但代码大多没有执行，也没有发现真正的bug。Codex更无聊、更直接，对于这个特定的自主开发循环更有用。我并不是说Codex普遍优于Claude。这只是一个项目、一个设置、一个日期、一种提示风格和一个相当具体的任务：在无人监督的情况下对Java Telegram代理进行自主开发。对于规划、研究和抽象设计，更强的模型可能更好。Anthropic自己的Claude Code设置也指向那个方向：Opus用于规划/建议，而执行通常通过不同的模型进行。但就我的设置而言，实际结果很简单：看起来不那么令人印象深刻的模型往往更能推动实际产品的进展。我仍在思考的部分不是“哪个模型最好”，而是如何评估编码代理——当它们能够生成令人信服但实际上从未进入运行时路径的架构时。对于构建或使用AI编码代理的人来说：你如何检查代理看起来最好的工作是否真的与产品相连，而不仅仅是靠旧路径通过测试？