不是套壳：为什么 Codex、Claude Code 这类 Agent 工具能把 LLM 能力放大一倍

很多人第一次看到 Codex、Claude Code、Kimi Code、WorkBuddy 这类工具，会下意识说一句：这不就是给大模型套了个壳吗？

这个判断只说对了一小半。

如果所谓“壳”只是换个 UI、包一层聊天窗口，那确实没什么价值。但 Codex、Claude Code 这一类工具真正重要的地方，不是 UI，而是它们把大模型放进了一个完整的 Agent Runtime / Agent Harness 里。

换句话说，差异不只是“问同一个模型”，而是“让模型处在什么工作系统里”。

从我的使用角度看，重要工作只用聊天窗口，其实是一种暴殄天物。你拿到的是可以读上下文、调用工具、执行命令、验证结果、持续迭代的大模型能力，却只把它当成一个会说话的搜索框。不是模型能力太弱，而是使用方式把它压扁了。

一、只用聊天窗口，很快会碰到天花板

聊天窗口适合问概念、写文案、解释代码片段。但真实工程任务通常不是一次问答，而是一条任务链：

• 读项目结构
• 找相关文件
• 理解历史约定
• 修改多处代码
• 运行测试
• 看报错
• 修复失败
• 生成 diff
• 解释改动
• 保留这次经验，下次继续

如果只用聊天窗口，这些环节大部分都要靠人手工搬运。你要复制代码、贴日志、解释目录、提醒它上一次说过什么。模型每次回答都像从局部信息里猜答案。

这会带来几个明显问题：

问题	表现
上下文不完整	模型没看到真实文件，只能根据你粘贴的片段推断
幻觉更高	它可能编造不存在的类、配置、API 或调用链
质量不可控	同一个问题多问几次，答案可能方向完全不同
验证缺失	它说“应该能跑”，但没有真正执行测试
记忆断裂	上一轮踩过的坑，下一轮可能重新踩
人工成本高	你变成模型的文件系统、终端、测试机和记事本

所以聊天窗口的问题不只是“不够自动化”。更严重的是：它让模型长期处在低证据、低验证、低连续性的环境里。

在这种环境下，模型再强，也容易变成一个口才很好的猜测器。

所以我现在的判断更明确：普通问题可以问聊天窗口，但重要工作应该优先进入 Codex 或类似 Agent 工具的工作流。越重要的任务，越不应该停留在“问一句、答一句”。

二、直接调用 API 也不是完整答案

有人会说：那我直接调用 API，不就更自由了吗？

API 当然重要，但 API 是原材料，不是工作台。你直接调用 API，拿到的是模型能力本身；但真实任务需要的是一整套工程系统。

你至少要自己解决这些问题：

• Context Engineering: 哪些文件、规则、日志、历史决策应该进入上下文？
• Prompt Engineering: 系统提示、任务提示、权限提示、输出格式怎么分层？
• Loop Engineering: 模型什么时候搜索、什么时候编辑、什么时候测试、什么时候重试？
• Harness Engineering: 如何接入文件系统、Shell、Git、浏览器、MCP、数据库？
• Session Management: 会话怎么恢复？长上下文怎么压缩？历史结论怎么复用？
• Permission & Sandbox: 哪些命令能自动执行？哪些动作必须人工批准？
• Trace & Verification: 每一步工具调用、测试结果、失败原因怎么记录？
• Cache: 重复上下文、容器环境、依赖安装怎么复用，避免成本爆炸？

这就是为什么好的 Agent 工具不是“套壳”，而是把 API 变成可工作的系统。

这里还有一层经常被忽略：自家模型 + 自家工具链，通常是当前最自然的能力释放路径。模型厂商最清楚模型的工具调用习惯、上下文组织方式、压缩策略、权限边界、缓存机制和失败恢复路径。当 Codex 这类工具把这些能力整合成一个统一 harness 时，它不是在外面随便包一层 UI，而是在把模型能力接入真实工作现场。

三、Agent 壳真正优化的是 LLM 使用生命周期

一个成熟的 Agent Harness，大致会把任务组织成这样的生命周期：

这条链路里，模型只是核心推理引擎。真正让结果变稳定的是外围系统：

• 它能读真实代码，而不是只看你复制的片段。
• 它能运行命令，而不是只说“你可以试试”。
• 它能看到失败，再根据失败继续迭代。
• 它能保留项目规则、偏好和历史坑点。
• 它能用 sandbox 和 approval 限制风险。
• 它能通过 trace、日志、测试结果让人复核。

这就是 Agent 壳的价值：把一次性回答，变成可验证、可迭代、可恢复的工作流。

四、为什么说能力可能被放大一倍？

这里要谨慎。不能简单说“套上 Codex，模型智商翻倍”。更准确的说法是：

在真实任务完成率、返工次数、人工搬运成本、验证质量上，好的 Agent Harness 可能带来 100% 量级的相对提升。

比如同样 20 个真实工程任务：

使用方式	可能结果
聊天窗口	完成 6 个，很多答案需要人工验证和重写
直接 API	完成 8 个，但大量工作要自己写 orchestration
Agent Harness	完成 12-15 个，并能留下 diff、测试、日志和复盘

如果聊天窗口完成率是 30%，Agent Harness 完成率到 60%，这就是 100% 的相对提升。

这个提升不是玄学，而是来自四个确定因素：

1. 信息更完整：模型看到真实上下文。
2. 行动更闭环：模型能读、改、跑、查、修。
3. 质量更可控：结果经过测试、日志、diff 验证。
4. 经验可积累：项目规则和失败经验不会每次清零。

公开资料也能看到这个方向。OpenAI 在 Codex 升级说明中提到，Codex 支持 CLI、IDE、Cloud、GitHub 等多工作面协同，并包含 todo、MCP、审批、压缩、测试验证、环境缓存等能力；其云端环境缓存让新任务和 follow-up 的中位完成时间降低 90%。Claude Code 文档也明确把它定义为能读代码库、编辑文件、运行命令、集成开发工具的 agentic coding tool，而不是普通聊天框。

五、真正的竞争不只是模型，而是运行系统

未来开发者比较 AI 工具，不能只问：

这个模型多聪明？

还要问：

• 它能不能理解我的项目？
• 它能不能安全地操作文件和命令？
• 它能不能验证自己的输出？
• 它能不能保留团队规则和历史经验？
• 它能不能在失败后继续迭代？
• 它能不能让我审计它做了什么？

大模型是发动机，Agent Harness 是车架、仪表盘、刹车、导航、维修记录和驾驶规则。

只用聊天窗口，相当于把发动机放在桌上，让人手推着跑。直接 API，相当于你拿到了发动机图纸，但整辆车要自己造。而 Codex、Claude Code 这类工具的意义，是把模型装进一个真正能工作的系统里。

所以，它们不是简单套壳。

它们是在补齐 LLM 从“会回答”到“能完成任务”的最后一公里。

参考来源

• OpenAI: Introducing upgrades to Codex
• Claude Code Overview
• Claude Code Memory
• SWE-bench Leaderboards