AI 编码智能体的残酷真相

我在ML社区反复听到这样一个故事：一个团队启动了一群编码代理，以10倍速度发布功能，然后庆祝。两个月后，团队中没有人再理解这个代码库。测试通过但生产环境崩溃。代理被叫来收拾残局，但代码库现在如此庞大、如此纠结、远远超出了任何人的上下文窗口，甚至代理都无法理清头绪。

这不是假设。独立软件开发者 Mario Zechner 刚刚发布了他自己的编码代理框架 PI，他观察到了这种模式的出现，并决定公开说出来。他的演讲 《在 Slop 世界中构建 PI》 是我见过的对 AI 编码代理当前状态最诚实、技术上最接地气的观点之一。我几乎同意他说的每一句话。以下是我从他演讲中得出的看法。

0、为什么一位资深开发者离开了 Claude Code

Mario 并不是出于恶意才构建 PI 的。他从 2025 年 4 月开始使用 Claude Code，非常喜欢，并称赞 Anthropic 团队确实才华横溢。但随着时间的推移，有些东西发生了变化。工具的功能增长速度快于它的改进速度。

他的具体抱怨值得点名：

• 他无法控制的上下文。 Claude Code 代表你管理上下文窗口，它会在你不知情的情况下做一些事情。系统提示词在每次发布时都会更改，包括工具定义。工具被移除或修改而没有通知。
• 在最糟糕的时刻注入的系统提醒。 该工具会在任务中途将提醒插入上下文，有时带有"这可能与你正在做的事情相关或无关"这样的措辞，正如 Mario 指出的，这恰恰是那种会混淆试图保持连贯性的语言模型的模糊措辞。
• 零可观测性。 你看不到你的代理在做什么或为什么这么做。对于任何关心理解自己系统的人来说，这是一个严重的问题。
• 浅层的可扩展性。 钩子确实存在，但它们是进程级别的，每个触发器都会生成一个新的 shell 命令。不是深度集成。不可编程。

这些不是对 Anthropic 意图的抱怨。这是对以牺牲透明度和稳定性为代价来优化功能速度所产生后果的抱怨。Mario 的比喻非常完美：如果你的锤子每天在工地上都坏掉，你会生气的。开发工具没有什么不同。

他研究了替代方案，向 AMP 和 Factory Droid 致敬，称它们为编码框架中的"保时捷和兰博基尼"，还深入研究了 OpenCode 的内部结构，在那里他发现了类似的问题：有效地使模型"脑白质切除"的上下文剪枝、编辑中途注入的 LSP 错误（在每一行之后检查错误，而不是在你完成工作之后），以及一个默认向浏览器中打开的任何网站暴露自己的服务器。

所以他构建了 PI。他构建的东西教会了我们一些重要的东西。

1、极简胜过极繁

PI 只配备了四个工具。它的系统提示词可以放在一张幻灯片上。这就是全部。

在你将其视为玩具项目的极简主义之前，考虑一下 Terminal Bench——一个编码代理基准测试，它给模型恰好一种能力：向 tmux 会话发送按键并读取输出。没有文件工具。没有子代理。没有搜索。只有一个终端。截至 2025 年 12 月，Terminal Bench 在排行榜上的得分高于大多数全功能框架，包括原生模型框架。最简单的可能环境胜过了功能最丰富的环境。

这应该让我们停下来思考。

我们一直在一种假设下运作：更多的上下文管理、更多的工具、更多的代理脚手架等于更好的性能。Mario 的论点，有基准数据支持，是我们正处于他所称的编码代理的"瞎折腾"阶段。我们实际上还不知道正确的框架长什么样。在这种不确定性中，极简方法胜出，因为它引入了更少的混淆变量，给模型更干净的信号，并且更容易推理。

这直接映射到 ML 从业者已经知道的东西：具有强归纳偏置的简单模型在低数据环境下始终优于过参数化的模型。这个原则在代理设计中同样成立。一个经过大量 RLHF 训练的编码任务模型已经知道编码代理是什么，你不需要 10,000 个 token 来提醒它。它知道，因为它被训练成为其中一个。

PI 的可扩展性理念强化了这一点：与其发布每一个功能，不如发布一个极简的核心，让代理自己扩展。用户描述他们需要什么；PI 构建扩展。代理适应你的工作流，而不是反过来。

2、没有纪律的代理速度是打了类固醇的技术债

这是 Mario 演讲中我认为每个 ML 团队负责人和从业者都需要听到的部分。

代理会复合错误。Mario 将这些称为"boooos"——默默积累的错误，没有通常会提醒人类开发者的摩擦感。人类会感到痛苦。他们会困惑、沮丧，他们会减速、重构。代理不会感到痛苦。它们会愉快地不断向一个破损的代码库生成代码，永无止境。

这里的数学是残酷的。一个人类开发者，每天能进入代码库的错误数量有一个天然的瓶颈。加上十个并行运行的代理，那个瓶颈就消失了。错误率在扩展。审查负担也在扩展，但你人类的审查能力不会。

而代理所学内容有一个结构性问题：它们是在互联网上训练的，而互联网上绝大多数是我们旧的、平庸的代码。不是珍珠，是垃圾。规格说明中的每一个空白都会被代理使用从那些垃圾中学到的模式来填充。你会得到没有人要求的抽象层、重复的逻辑、为不存在的场景生成的向后兼容垫片。两个人和十个代理在两周内生成的企业级复杂性。恭喜。

"但我们有详细的规格说明。"Mario 对此的回应值得直接引用：足够详细的规格说明就是一个程序。 如果你的规格说明有空白，模型会填补它们。你无法控制它用什么来填补。

"但我们有审查代理。"这也不够。审查代理能捕获一些问题。它们会遗漏架构层面的问题，那些局部看似合理但会造成全局性损害的决策，因为那些需要理解整个系统，而这恰恰是当没有人在阅读代码时会丢失的东西。

Mario 的负责任代理使用框架是实用的，我支持它：

• 严格限制范围。 只给代理它需要的上下文，并确保它能找到与任务相关的一切。如果你无法界定范围，就不要委托。
• 模块化你的代码库。 更小、边界清晰的模块使代理任务变得可处理和可审查。
• 将代理用于正确的任务。 Bug 的复现案例、无聊的样板代码、非关键的自动化、研究，这些是好的。核心业务逻辑、安全敏感代码、架构决策，这些不是。
• 自己阅读关键代码行。 每一行。如果你不知道哪些是关键的，那就是你的答案：阅读更多代码。

最后一点让人不舒服，我认为这就是重点。阅读自己代码的纪律不是对生产力的税，它正是让你成为开发者而不是代理决策的审查者的东西。

3、开源问题：机器人正在损害公共资源

简短提一下，因为它值得被提及：AI生成的 GitHub issue 和 PR 正在让开源维护者筋疲力尽。Mario 展示了他自己的追踪器，其中一半是自主运行的代理实例产生的垃圾，在不阅读贡献指南的情况下提交 PR，用低质量报告淹没 issue 队列。

他的应对方式——自动关闭代理 PR，要求贡献者用自己的声音在不超过一屏的文字内撰写 issue，构建一个只让真正阅读了说明的账户通过的过滤器——很巧妙。但他不得不花时间为自己的开源项目构建滥用过滤器，这是社区造成的问题。

如果你正在使用代理为开源做贡献，请为它们配置适当的约束。或者更好的做法是，阅读仓库并自己撰写 issue。

4、慢下来。少构建。多理解。

Mario 以一句在 2025 年听起来几乎是反潮流的话结束他的演讲：慢下来。思考你在构建什么以及为什么。学会说不。更少的功能，但要做那些真正重要的，然后使用你的代理来打磨这些功能，直到它们出色。

我认为他是对的。最大化代理输出的竞赛就是最大化技术债、用户困惑和维护者倦怠的竞赛。将构建最持久、最值得信赖的 AI 驱动系统的从业者，是那些将代理视为精密仪器而非自主联合开发者的人。

Mario 的结束语是我一直回想的：

"摩擦是在你头脑中建立对系统理解的机制，它也是你学习新事物的地方。"

我们一直把摩擦视为敌人。它不是。它是理解从代码传递到开发者的机制。完全消除它，你最终会得到一个你无法调试、无法扩展、无法信任的代码库。

使用你的代理。好好使用它们。但要把手放在代码中。

原文链接：Slop, Speed, and Discipline: Hard Truths About AI Coding Agents

汇智网翻译整理，转载请标明出处