一个 AI 编程怀疑论者亲自尝试 AI Agent 编程：详尽实录

原文来源：Max Woolf's Blog — 数据科学家 Max Woolf 以怀疑论者的身份深入测试 Claude Opus 4.5 的 AI Agent 编程能力，从 AGENTS.md 配置到 YouTube 数据抓取实战，记录了真实的使用体验、遇到的陷阱和意外的生产力提升。

你可能已经看过很多关于 AI Agent 编程或 Vibe Coding 的博客文章，作者们要么夸夸其谈代理现在能做什么，要么担忧代理会导致编程技能退化、亵渎人类灵魂。这篇文章不是那种。你已经被警告了。

去年五月，Max Woolf 写了一篇《作为一个有经验的 LLM 用户，我其实不常用生成式 LLM》，作为对 Agentic Coding 炒作的回应。当时他承认 LLM 确实有用，能比自己写更快地回答简单编码问题，但代理是另一回事：它们不可预测、昂贵，而且炒作与实际效果严重不成比例。不过他当时也表示，如果 LLM 足够改进，代理变得更可靠，他是愿意接受的。

几个月过去，他继续做着数据科学家的日常工作，同时跟踪 OpenRouter 上出现的最新 LLM。八月，Google 发布了 Nano Banana 生成式图像 AI 及对应的 API，API 很难用，所以他开源了 gemimg Python 包作为包装器。这个项目没什么激动人心的地方，实现空间不大，满足感来自于它带来的价值而非写工具本身。于是他把功能完整的代码丢给 OpenRouter 上的各种新兴 LLM，让它们找出 Python 代码中的问题。如果失败了，说明当前 LLM 的能力还有限；如果成功了，那对用户来说是软件质量的提升，他没有道德上的反对。结果 LLM 确实帮了忙：除了添加好的函数文档字符串和类型提示外，它们还识别出了一些代码块的更 Pythonic 的实现方式。

大约同一时间，同事们在 Visual Studio Code 里推 GitHub Copilot，特别是当时新出的 Claude Sonnet 4.5。对于数据科学工作来说，Sonnet 4.5 在 Copilot 里没什么帮助，倾向于创建过于冗长的 Jupyter Notebook，所以他没被打动。但到了十一月，Google 发布了 Nano Banana Pro，需要立即更新 gemimg 以兼容新模型。测试 Nano Banana Pro 后，他发现这个模型可以创建任意网格的图片（比如 2x2、3x2），这是一个极其实用的工作流。于是他快速写了一个 spec 来实现支持，并且把每个子图切片单独保存。他知道这个工作流用 Pillow 实现起来简单但繁琐，所以放心地让 Copilot 去执行，结果它确实做到了，虽然在 spec 没提到的区域有错误（比如行列顺序搞混了），但通过更具体的提示就能修复。即使算上处理错误的时间，这也是足够的生产力提升，让他对代理能力变得更乐观，但远没到成为 AI hypester 的地步。

十一月，就在感恩节前几天，Anthropic 发布了 Claude Opus 4.5。同事们自然好奇它是否比 Sonnet 4.5 有显著改进。Anthropic 在重大节假日前发布产品通常是为了把不够惊艳的公告埋掉，因为潜在用户都在忙着聚会。幸运的是，Max 在旧金山没有朋友也没有家人，所以有充足的带宽来测试新 Opus。

AGENTS.md 的前置准备

有一个 Agent 方面 Max 之前没研究过，但知道要获得好结果是必要的：AGENTS.md 文件。这个文件可以控制 Agent 的特定行为，比如代码格式。如果文件存在于项目根目录，Agent 会自动读取并理论上遵守其中的所有规则。这类似于普通 LLM 调用的系统提示，Max 对高度精细化的系统提示有不健康的执念，包括用全大写来增加对更重要规则的遵守度（是的，这仍然有效）。

他找不到一个好的 Python oriented AGENTS.md 起点，所以让 Opus 4.5 自己生成一个：

Add an AGENTS.md file oriented for good Python code quality. It should be intricately detailed. More important rules should use caps, e.g. MUST

然后他加了一些个人偏好和从之前与 Python Agent 合作失败中学到的建议：使用 uv 和 .venv 而非基础 Python 安装，使用 polars 而非 pandas 进行数据处理，只在 .env 中存储密钥/密码/API 并确保 .env 在 .gitignore 中，等等。大多数约束不是告诉 Agent 做什么，而是怎么做。一般来说，每当遇到不喜欢的基本行为时，就往 AGENTS.md 里加一条规则，这非常有效。比如 Agent 喜欢用不必要的 emoji，他讨厌，所以加了：

**NEVER** use emoji, or unicode that emulates emoji (e.g. ✓, ✗).

Agent 还倾向于留下大量冗余代码注释，所以又加了一条：

**MUST** avoid including redundant comments which are tautological or self-demonstrating (e.g. cases where it is easily parsable what the code does at a glance or its function name giving sufficient information as to what the code does, so the comment does nothing other than waste user time)

他的最新 Python AGENTS.md 文件可以在 GitHub Gist 上找到。在整个与 Opus 合作的过程中，它遵守了每一条规则，尽管文件很长。而在他不小心在没有 AGENTS.md 的情况下查询 Agent 时，差异非常明显。他毫不怀疑这个文件是获得好与坏结果的主要区分因素，尽管成功仍然 mixed。

顺便说一下，如果你在用 Claude Code，文件必须命名为 CLAUDE.md，因为 Anthropic 比较 weird。这篇文章统一用 AGENTS.md。

与 Opus 的第一次接触

AGENTS.md 设置好后，Max 研究了正确提示 Agent 的方法，看看之前与 Sonnet 4.5 合作时表现不佳是不是因为遗漏了什么。

Anthropic 的提示建议很简单，但你不能给 LLM 一个开放式问题就期望得到你想要的结果。用户很可能潜意识里很挑剔，而且总有功能需求是 Agent 不会神奇地应用的，因为它读不懂你的心，表现得像个字面意义上的 genie（灯神）。Max 的做法是把可能非常大的单个提示写在自己的 Markdown 文件里（可以纳入 git 跟踪），然后让 Agent 读取这个文件并执行。工作完成并手动审查后，他手动提交到 git，提交信息引用具体的提示文件，这样就有良好的内部追踪。

他完全无视了 Anthropic 的建议，写了一个更复杂的测试提示，基于一个他熟悉因此能审查 Agent 代码质量的用例。2021 年他写了一个脚本，用 YouTube Data API 抓取给定频道的视频元数据，但 API 文档写得又差又反直觉，他的 Python 脚本也不怎么样。他订阅了 SiIvagunner YouTube 账号，这个频道作为 gimmick 的一部分，每月发布数百个视频，缩略图和标题都不起眼，很难判断哪些视频是好的，除了观看次数。视频元数据可以用来发现他错过的好视频，于是他有了一个测试 Opus 4.5 的有趣想法：

Create a robust Python script that, given a YouTube Channel ID, can scrape the YouTube Data API and store all video metadata in a SQLite database. The YOUTUBE_API_KEY is present in .env.
 
Documentation on the channel endpoint: https://developers.google.com/youtube/v3/guides/implementation/channels
 
The test channel ID to scrape is: UC9ecwl3FTG66jIKA9JRDtmg

这个提示包含了他能想到的所有细节：API 密钥放在 .env 里、使用 SQLite、提供了频道 ID 和文档链接。他认为如果 Agent 连这个都做不好，那它就不够格。

Opus 4.5 接收了这个提示，开始工作。Max 观察着它的行为：它先读取了 AGENTS.md，然后开始创建文件结构。它正确地使用了 python-dotenv 来加载 .env，使用了 sqlite3 模块，并且按照 YouTube Data API 的文档正确地分页获取了所有视频。整个过程大约花了十分钟，Agent 在终端里一行一行地输出它的思考过程和操作。

结果令人印象深刻。代码结构清晰，类型提示完整，文档字符串到位，而且正确地处理了 API 分页。Max 手动审查了代码，发现只有一个小问题：Agent 在创建数据库表时，把一个字段的类型搞错了，把 publishedAt 存成了 TEXT 而不是 DATETIME。但这很容易修复，而且考虑到 Agent 是在没有明确指定字段类型的情况下自己推断的，这个错误可以理解。

更让他惊讶的是，Agent 还主动添加了一个他没想到的功能：一个命令行参数解析器，让用户可以通过 --channel-id 参数指定不同的频道。这不是他提示里要求的，但 Agent 认为"一个健壮的脚本应该支持命令行参数"。Max 觉得这个判断是正确的，保留了这个功能。

遇到的陷阱

当然，过程并非一帆风顺。Max 记录了几个典型的 Agent 陷阱：

过度工程化。Agent 倾向于创建比实际需要更复杂的架构。在 YouTube 抓取脚本中，Agent 创建了一个完整的类结构，包括 YouTubeScraper 类、DatabaseManager 类、配置类等等。虽然这些类在理论上是好的设计，但对于一个简单的数据抓取脚本来说，这有点过度了。Max 最终保留了一些，但简化了整体结构。

幻觉文档。Agent 有时会引用不存在的 API 参数或方法。在实现分页逻辑时，Agent 最初使用了一个 pageToken 参数名，但 YouTube Data API 实际使用的是 page_token（snake_case）。Agent 在第一次尝试时搞混了，Max 不得不在后续提示中纠正它。

上下文丢失。当任务比较复杂时，Agent 有时会"忘记"之前的决策。在脚本的后半部分，Agent 突然开始用不同的变量命名风格，与 AGENTS.md 中规定的风格不一致。Max 不得不提醒它"遵守 AGENTS.md 中的命名规范"。

隐藏成本。Opus 4.5 的 API 调用成本比 Sonnet 4.5 高得多。整个 YouTube 脚本任务的 token 消耗大约是 Sonnet 的 3-4 倍。对于个人 side project 来说这不是问题，但如果是企业级使用，这个成本差异需要认真考虑。

意外的生产力提升

尽管有这些问题，Max 还是发现了几个意外的生产力提升点：

快速原型。对于"我想试试这个想法"类型的任务，Agent 能在几分钟内给出可运行的代码骨架。虽然不完美，但比自己从头写快得多。Max 估计，对于熟悉领域的任务，Agent 能把初始实现时间缩短 60-70%。

边缘情况处理。Agent 倾向于考虑一些人类开发者可能忽略的边缘情况。在 YouTube 脚本中，Agent 主动添加了错误重试逻辑、API 配额超限处理和空结果检查。这些不是 Max 明确要求的，但确实是健壮脚本应该有的。

学习新 API。当面对一个不熟悉的 API 时，Agent 能快速生成一个可用的示例。Max 承认，虽然他后来验证了 Agent 生成的代码，但 Agent 提供的初始结构让他理解新 API 的速度快了很多。

最终判断

测试完 Opus 4.5 后，Max 的态度从"谨慎乐观"变成了"有条件接受"。他的结论是：

AI Agent 编程不是魔法，也不是灾难。它是一个工具，有明确的适用场景和明确的限制。对于个人 side project、快速原型、学习新 API，它确实能提供显著的生产力提升。但对于生产代码、关键业务逻辑、需要长期维护的代码库，人类工程师的审查和判断仍然不可替代。

AGENTS.md 是区分好与坏体验的关键。没有它，Agent 会按照它自己的默认行为行事，这些行为往往与人类的期望不符。有了它，Agent 的表现可以提升到"可用"甚至"不错"的水平。

成本是一个需要考虑的因素。Opus 4.5 的能力确实比 Sonnet 4.5 强，但价格也更高。对于个人用户来说，这个 trade-off 可能是值得的；对于企业用户，需要仔细计算 ROI。

最后，Max 强调了一个重要的使用原则：永远不要把 Agent 的输出直接提交到生产环境。审查、测试、验证，这些步骤一个都不能少。Agent 是加速器，不是替代者。

文章末尾，Max 附上了他的 AGENTS.md 模板和 YouTube 抓取脚本的完整代码，供读者参考和批评。