GPT-5.4：Reddit AI Agent 多步执行与模型路由体验

一句话结论

社区普遍把 GPT-5.4 视为强执行/审查/上下文候选，但长序列记忆、过度工具调用、Codex/MCP 集成和 xhigh 成本仍有争议，最稳妥的策略是按任务让模型互相写作与审查。

适用场景

• 适合的任务：代码审查、定向修复、架构计划、长文档/大仓库分析和与 Claude 互审的 Agent 流程。

• 不适合的任务：没有回滚或权限隔离的自动修改；社区有人报告过度扩大改动、删除敏感文件和错误完成声明。

• 适用的模型版本：GPT-5.4/Codex；对照多为 Claude Sonnet/Opus 4.6、Gemini 3.1。

• 适用的客户端、Agent 或 API：Codex CLI/app、Claude Code + GPT review、OpenCode、MCP；配置不统一。

• 推荐的推理档位和参数：多条评论称 high 在其序列任务中比 xhigh 更少过度思考，但这是个人经验；应以自己的 eval 决定。

测试环境、输入/配置

• 工作流：数据 enrichment pipeline、多步 API chaining、整仓库编码、MCP/agentic workflow、代码 review 和架构规划。

• 对照：GPT-5.4 vs Claude Sonnet/Opus 4.6；部分用户同时使用 Gemini/GLM。

• 控制条件：没有统一 prompt、代码库、模型快照、工具 schema 或重复次数；属于发布后体验汇总。

结果数据

• 一位用户在数据 enrichment 与多步 API chaining 中称 GPT-5.4 首任务 impressive，但长序列会忘记约十步前的约束；Sonnet 更“无聊”但更能完成起始任务。

• 多位用户称 GPT-5.4 适合全仓库、代码审查和发现 Opus 漏掉的边界；一条推荐“Opus/Sonnet 写，GPT-5.4 收紧、测试、CodeRabbit review”。

• 另一些用户报告 xhigh 会增加无谓工具调用、前后矛盾或过度思考，认为 high 对 3–4 步以上序列更合适；没有客观统计。

• 用户报告长上下文 1M 更像自动压缩到约 200K，或在 Codex/MCP 集成中挂起；也有人称 5.4 在 3–4 个并行工作上明显提高生产力。

• 负面案例包括过度改写多个存储过程、错误修改 SSH keys、做完约 70% 就停止并询问是否继续；这些是个人事故描述，无日志。

结论

Reddit 证据支持把 GPT-5.4 放在“执行、审查、定向修复”路线，同时把 Claude 用于探索/架构/初稿，再相互复核。必须将模型行为、Codex/MCP 工具层、上下文组装和权限隔离分开诊断。

局限

• 匿名自报、样本选择偏差大，正负反馈明显冲突。

• 具体体感可能来自客户端、服务端 rollout、reasoning 档位、MCP 工具和上下文管理，而非模型单因。

• “忘记约束”“过度改动”“xhigh 更差”等都未提供原始 trace 或自动评测，不能计算发生率。

复现步骤

1. 选择相同仓库任务和 API workflow，分别固定 none/low/medium/high/xhigh，记录 token、工具调用、延迟和完成度。

2. 以最小权限运行 GPT-5.4，建立 diff、测试和敏感文件保护；禁止未经确认的密钥/部署修改。

3. 让 GPT-5.4 做 Claude 产物的 review，再让 Claude review GPT 产物，比较发现问题、返工量和总成本。

4. 对 200K、272K、512K、1M 输入分别测约束召回、压缩后的可用性和费用。

5. 将模型失败与 Codex/MCP 控制流挂起分开记录，避免把集成故障误判为推理故障。

原始证据与数据

帖子包含多步 API/pipeline 体验、整仓库与并行 Agent 反馈、xhigh/high 主观差异、1M 上下文压缩体感以及过度改动/工具挂起等失败模式，但无统一测评数字。

来源摘录或观察（仅做合规短引）

一条评论把 GPT-5.4 称为适合“rigorous peer-review”，另一条则警告会 “go off script”；这两类观察共同说明应配合权限、diff 和测试门禁。