考察点
这道题出自字节跳动 Agent 开发实习一面（2026 年牛客面经），表面是产品对比，实际考察两点：你是否真的深度用过这些工具（回答里有只有用过才知道的细节，而不是官网文案），以及你对自己做的东西定位清不清楚——通用工具已经这么强，你做的 agent 存在的理由是什么。第三问是陷阱题，答"我的比它们强"会显得狂妄，答"不如它们"等于否定自己的项目，正确姿势是讲通用与专用的取舍。追问可能往"你觉得它们的 harness 哪里设计得好、哪里可以改进"上走。
参考答案
Claude Code 的特点
Claude Code 是终端优先、agentic 程度最高的那一类。它的设计哲学是把模型放进一个薄壳里：给一组精心调过的工具（文件读写、bash、grep、glob），配上权限模式和长循环，然后相信模型自己完成任务。几个我觉得设计得好的地方：一是生态化的扩展体系——CLAUDE.md 项目记忆、skills、subagent、hooks、MCP，几乎每层都留了口子让团队沉淀自己的工程实践，它不是工具而是平台；二是长任务能力，auto-compact 和任务清单机制支撑它跑半小时以上的复杂重构；三是权限分级做得细，从逐条确认到全自动有多档，敢在生产仓库里用。短板也明显：token 消耗大，成本敏感场景肉疼；长任务偶尔会"过度自信"，一路错下去不回头的案例不少见。
Codex 的特点
Codex 的取向不同，它的核心是云端异步任务。你在 GitHub 上丢给它一个 issue，它在云端沙箱里开环境、装依赖、跑测试、提 PR，你可以同时委托好几个任务挂着跑。这个模式和 Claude Code 的"本地陪你干活"是两种人机关系：Codex 更像一个异步外包同事，Claude Code 更像坐在旁边的结对伙伴。云端沙箱的好处是隔离干净、并行度高，坏处是环境配置不对就抓瞎，而且调试反馈链路长。后来 Codex 也有了 CLI，形态上在向 Claude Code 靠拢，两边其实在互相学习。
我做的 coding agent 和它们的区别
我从不认为自己在做一个"更好的 Claude Code"，定位差异在三个层面。
第一是领域深度。通用工具对所有仓库一视同仁，我的 agent 只服务特定的项目和内部技术栈，因此可以把通用工具做不到的事情做深：内置对内部 CI 系统、代码托管平台、监控告警的直接集成，工具返回的是结构化数据而不是让模型去网页上扒；内置了项目特有的知识，比如哪些模块有历史包袱不能乱动、联调环境怎么申请。
第二是harness 可控。用别人的产品，压缩策略、权限模型、循环控制都是黑盒，出问题只能绕。自己的 agent 每一层都可调：我能针对我们的任务分布调压缩阈值、给高风险操作定制审批流、在 trace 里埋我们关心的指标。这种可控性在调试和迭代 agent 本身时是刚需。
第三是评测与数据闭环。通用工具不会为我的场景跑回归。自己的 agent 可以从第一天就建评测集：典型任务的成功率、平均 token 成本、人工接管率，每次改 harness 都跑一遍。Agent 工程的竞争力很大程度就在这层闭环上，而这层只有自己做才建得起来。
一句话概括我的观点：通用 coding agent 解决的是"任何代码任务做到 80 分"，专用 agent 的价值在于特定场景从 80 到 95 的那段，而那段靠的正是深度集成、可控 harness 和评测闭环。
可能的追问
通用工具进化这么快，专用 agent 会不会被吃掉？ 薄壳会、厚 harness 不会。模型能力提升吃掉的是"通用流程编排"，吃不掉的是内部系统集成、私有知识和场景化评测，这些恰恰是专用 agent 的价值主体。
你觉得 Claude Code 最值得抄的设计是什么？ 渐进披露的上下文管理：CLAUDE.md 分层加载、skills 按需触发、工具结果截断，整套机制都围绕"上下文是最贵资源"设计，这套思想在任何 agent 里都成立。
Codex 的云端模式你怎么评价？ 适合任务定义清晰、环境可容器化的场景（修 bug、写测试、依赖升级）；需要频繁人机往返的探索性任务不适合，反馈延迟会杀死体验。两种模式会长期共存。