编译 | 苏宓 出品 | CSDN（ID：CSDNnews） 一天烧掉 100 美元，是平时一周 Token 预算的 5 倍！ 微软产品经理 Keiji Kanazawa 怎么也没想到，让 Claude Code 和 Codex 连续给自己写了三周代码，等到真正仔细检查 AI 生成的代码时，才发现自己被「骗」了。 Agent 不仅没有按照他的要求实现真正的 Agent 架构，还把单元测试直接接到了生产环境的推理接口上，一天跑了约 30 轮，狂烧 Token。折腾了三周，项目最终还是只能推倒重来。 近日，AI Engineer 栏目在 YouTube 分享了 Keiji Kanazawa 的这段经历——《I Let Agents Refactor My Codebase for 3 Weeks. Then I Read the Code》（我让 Agent 连续三周重构代码库，直到后来才真正去看代码）。 那么，这位微软产品经理究竟是怎么被 AI Coding Agent 狠狠「上了一课」的？ 让两个 AI 轮流写代码，三周后发现架构根本不是自己想要的 要知道，Keiji Kanazawa 可不是什么不懂代码的纯小白。他早年做过开发，也有 AI 研究背景，如今在微软工作，日常主要负责与 OpenAI、Anthropic 等前沿实验室对接，将大模型交付给微软客户。 在工作中，他大约 90% 的时间都在使用 GitHub Copilot CLI，而在个人项目中，则主要使用 Claude Code 和 Codex。 原本以为，终于可以让两个 AI 编码助手替自己搭建一套复杂系统，没想到最后留下的坑远比预想中多。 其实，Keiji Kanazawa 的这个项目最初很简单。 他想搭建一套个人播客处理工具，能够自动下载播客、转录音频，再生成摘要。 后来，项目逐渐扩展成一个更复杂的系统。他增加了对 X（原 Twitter）和 Threads 内容的抓取与总结，加入定时调度器，让整个系统 24 小时运行，还接入了邮件收件箱——只要往里发送一个链接，系统就会自动抓取内容并返回摘要。 随着功能越来越多，他逐渐将其发展成 Andrej Karpathy 所说的「LLM Wiki」。 但这还不够。 Keiji Kanazawa 开始在原有系统上构建真正的 Agent 工作流，包括深度研究、针对自己日常 Claude Code 使用记录的每日反思，以及根据反思结果沉淀新技能、自动提出 Agent 指令优化建议等。 为了让整个系统更加自动化，他专门编写了一套规格说明（Spec），希望构建一个真正的 Agent Runtime（Agent 运行时），其中包括 Agent 注册中心，能够调度独立的 Agent，并对接不同的 Agent SDK。 具体实现时，他没有自己动手写代码，而是让 Codex 和 Claude Code 轮流接手。一方负责实现，另一方负责检查代码、发现问题，再尝试修复 Bug。 就这样，两个 AI 编码助手连续工作了三周。表面上看，它们几乎完全按照 Kanazawa 的需求把系统跑通了。 真正让他起疑的， 是一次摘要生成错误。 当时，系统生成的一份每日摘要中，有一句话被错误地归到了另一个板块。 为了排查问题，Kanazawa 让 Claude Code 调出这轮会话的 Agent SDK Trace（执行轨迹），按照 Turn 逐步展示。 没想到，Claude Code 给出的回答却让他有些意外：「 我们没有这个数据。因为这并不是真正的 Agent，它根本没有使用 Agent SDK。 」 Kanazawa 当即反问：「我不是明确要求你必须使用 Agent SDK 吗？」 顺着这个线索继续检查，他才第一次真正深入查看 AI 生成的底层代码，并发现此前自己一直以为已经实现的系统架构，和实际代码之间存在不小的差距。 具体来说： Agent Skills： 没有真正独立的 skill.md 文件，也没有对应的底层脚本。 Actions： 与 Skills 实际上使用的是同一套逻辑，只是换了一个名字。 Agents： 同样没有真正运行在任何 Agent SDK 之上，所谓的 Agent 抽象也没有实现他要求的独立运行机制。 每日反思 Agent： 虽然能够按照计划定时运行，但重构过程中底层 Prompt 逻辑被破坏，实际上已经无法生成有效内容。 换句话说，系统里虽然有 Agent、Skills、Actions 等各种听起来很专业的概念，但它们并没有按照这些概念应该具备的方式运行。 step_type = 'agent' Keiji Kanazawa 对此有一个很直接的描述： 「它们给系统里的这些构造起了听起来很合理的名字，但实际上根本不是它们所声称