别再浪费这么多 Token 了！PI 编程智能体 vs OPENCODE 同本地大模型实测对比

中文العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский
LLuigi Tech
컴퓨터/소프트웨어게임/e스포츠AI/미래기술

Transcript

00:00:00大家好，这是 Agent 比较 Open Code 的演示，我们将测试这些
00:00:09在这个例子上测试两个框架。这是我在之前的视频中
00:00:20通过“Vibe Coding”编写的游戏。是的，在这个视频中，我想测试如何修复这个游戏，
00:00:29因为存在一些漏洞。例如，如你所见，X 标记赢得了
00:00:38比赛，但单元格没有被高亮显示。我们将尝试使用本地 LLM 进行同样的修复，
00:00:51也就是 Qwen 2.5 32B 3B，在我看来，这是目前
00:01:04你可以在电脑上运行的最好的模型。所以让我们先尝试 Pi，
00:01:16这是 Pi，我将在包含源码的目录中运行它，
00:01:30源码分布在不同的文件中：有 index.html、game.js 和 style.js。我们将尝试
00:01:42在两个框架中使用相同的提示词，并比较结果。我还会
00:01:55使用计时器来看看完成这项任务需要多长时间。这就是提示词。
00:02:11提示词是：让单元格方块更明显，并在它们之间添加间距，
00:02:19因为如你所见，这些方块彼此靠得非常近。然后我们有
00:02:28第二个任务，即改进获胜逻辑：获胜的标记应该
00:02:37变成绿色。这是另一个问题，因为你看不出
00:02:46玩家是在哪里获胜的。是的，它开始遵循我的提示词了，这就是
00:02:59Pi，它开始分析当前目录，在这里你可以看到
00:03:09使用的上下文。不过，也许看看修复游戏所花费的
00:03:20时间会更有趣。是的，它正在工作。然后我们将使用
00:03:30Open Code 执行相同的任务，我会重置仓库以进行同样的测试。现在我将
00:03:41暂停一下视频，等它修复完游戏后再见。
00:04:00好的，完成了。它还在写变更报告，然后我们将测试
00:04:20结果。好的，完成了。使用 Qwen 2.5 耗时 7 分 44 秒。让我们
00:04:38看看结果。这是报告，也就是代码中在技术层面上
00:04:47发生了什么。如你所见，它多次读取了 game.js 的
00:04:58多个部分。这也有一个 diff。你可以看到它对文件进行了大量
00:05:09编辑。总共发送和接收了 9.4K 和 2.8K 个 Token。这是
00:05:23上下文使用情况的结果。让我们测试一下结果：刷新。如你
00:05:35所见，现在的单元格方块间距更大了，彼此更加分离。所以
00:05:44让我们试玩一下游戏。我先从中心单元格开始。好的，好的，我会让
00:06:00电脑赢。好的，太棒了。现在电脑赢了，如你所见，方块
00:06:11分得更开了，而且获胜的标记也高亮显示了。所以它成功了。这是使用
00:06:20Pi 编程 Agent 的结果。现在我们将使用 Open Code 进行相同的测试，
00:06:30使用相同的模型和代码。我会重置代码。好的，现在变更已回退到
00:06:50有漏洞的版本，像这样。现在我们将在 Open Code 中尝试同样的
00:07:00提示词，包括单元格和获胜逻辑。我将通过 Basico 使用相同的模型，
00:07:11Basico 是我自己制作的一个自定义 Agent。我也启动了它，
00:07:27我制作 Basico Agent 是因为它比默认的编程 Agent 要
00:07:36简单得多。Basico Agent 就是这个，
00:07:56它只是一个简单的 Markdown 文件。你是一个 Basico 极简 Agent。是的，我
00:08:07在这里没写太多要求，只是让它使用带有搜索引擎工具的 Web Fetch，
00:08:15但在这次使用中我们用不到它。所以这是一个非常简单的 Agent，只是为了
00:08:24为 Open Code 创造类似的条件。我们已经使用了
00:08:3412K 的上下文。它从 index 和 game.js 开始。是的，在这里我们也会
00:08:47在暂停视频后查看最终结果。它仍在运行，
00:08:58没有太多反馈。我还想说，我也用
00:09:07Gemma 2 27B 进行了同样的测试，但它无法在这种
00:09:20项目上进行工具调用。Gemma 2 虽然能够重新创建 3D 井字棋游戏，但
00:09:30之后却无法通过工具调用来编辑这些文件。所以我只用
00:09:38Qwen 2.5 做了这个测试，因为我认为它是此类本地场景的最佳选择。
00:09:48是的，很有趣，因为它正在填写待办事项。有两个任务：一个是
00:09:58让单元格方块更明显，另一个是修复逻辑。所以它会有
00:10:07一些比 Pi Agent 更多的开销。但是，是的，Pi Agent 能够
00:10:17在没有中间待办事项的情况下完成此类任务。也许在更复杂的
00:10:26情况下，有待办事项会很有用。但归根结底，我认为是 LLM 模型
00:10:35产生了最大的差异，而不是框架。但我们
00:10:44拭目以待。
00:10:56好的。
00:11:27好的，快完成了。两个待办事项都已完成，但它还需要读取
00:11:40然后写入文件。
00:11:52好的，正在编写报告。我希望之后它能结束。已经用了 12
00:12:05分钟，时间更长，但好的，它结束了。暂停。如你所见，
00:12:15Open Code 使用了约 23K 的上下文。可能它们报告
00:12:26Token 使用量的方式不同，但似乎 Pi 修复问题只用了一半的 Token。
00:12:36这是技术报告，它多次打开了
00:12:46game.js 进行修复。让我们测试游戏，看看这些修复
00:12:57是否真的有效。刷新。看起来和 Pi 版本很像。中心单元格，好的。
00:13:19试着赢下这局。好的，我赢了。如你所见，我们得到了
00:13:32和 Pi 一样的结果，但花费了更多的 Token 和更多的时间来
00:13:43完成方案。在这个用例中，通常拥有更多功能
00:13:55（如护栏和更多提示词微调）的 Open Code，得到了与
00:14:06Pi 相同的方案，但 Pi 花费的时间和 Token 更少。总之，在我看来，正如我
00:14:18之前所说，所使用的 LLM 是最相关且最重要的部分。
00:14:28框架虽然有用且重要，但更重要的是它放入上下文中的数据质量。
00:14:36在这种情况下，使用 Pi 编程 Agent，
00:14:47开销更小，且即使在 LLM 没有很长提示词的情况下也得到了很好的结果。
00:14:58在评论区告诉我你更喜欢哪种开源
00:15:06框架编程 Agent。下个视频见，再见。

Key Takeaway

在本地运行 Qwen 2.5 32B 模型时，Pi 编程智能体比 Open Code 修复代码的速度快 35% 以上，且仅消耗约 50% 的 Token 资源。

Highlights

  • Qwen 2.5 32B 在本地编程任务中表现优异，能够通过工具调用准确修改多个源代码文件。

  • Pi 编程智能体修复井字棋游戏漏洞仅需 7 分 44 秒，而 Open Code 耗时超过 12 分钟。

  • Pi 智能体在处理相同任务时消耗约 1.22 万个 Token（9.4K 输入 / 2.8K 输出），比 Open Code 节省了近一半的上下文资源。

  • Gemma 2 27B 虽然能生成游戏代码，但在本地环境下无法通过工具调用对现有文件进行编辑修复。

  • Open Code 在任务执行过程中会生成详细的待办事项清单（To-Do List），这增加了系统的运行开销。

Timeline

本地模型编程测试环境配置

  • 测试目标是修复一个由 Vibe Coding 编写且存在逻辑漏洞的井字棋游戏。
  • 本地运行环境选择 Qwen 2.5 32B 3B 模型，该模型被视为目前个人电脑上性能最强的选择。

游戏源码分布在 index.html、game.js 和 style.js 三个文件中。当前版本存在两个主要问题：单元格方块间距过窄导致视觉模糊，以及获胜逻辑中缺失高亮显示功能，玩家无法直观判断胜负位置。

Pi 编程智能体修复实测

  • Pi 智能体通过分析目录结构自动获取 index.html、game.js 和 style.js 的上下文信息。
  • 修复过程总计耗时 7 分 44 秒，总 Token 消耗约为 1.22 万个。

Pi 在接收提示词后直接对源码进行多处编辑。最终结果成功扩大了单元格间距，并实现了获胜标记变为绿色的高亮逻辑。技术报告显示其多次读取 game.js 片段并生成 diff 文件完成修改。

Open Code 与 Basico 智能体对比测试

  • Open Code 使用相同的 Qwen 2.5 模型配合 Basico 极简智能体执行任务。
  • 完成相同修复任务耗时超过 12 分钟，上下文消耗量达到 2.3 万个 Token。

Open Code 的操作逻辑更为复杂，它会先创建包含多个步骤的待办事项清单，随后再执行文件读写。这种结构化的流程虽然在复杂项目中可能有用，但在简单的修复任务中产生了显著的时间和资源开销。

本地 LLM 性能与框架效率总结

  • LLM 模型本身的性能是决定编程任务成败的核心因素，而非框架本身。
  • Pi 编程智能体在没有冗长提示词的情况下，依然能提供更高效的上下文管理。

测试对比证实了 Pi 在 Token 利用率上的优势。此外，实验发现 Gemma 2 27B 等模型在本地调用文件编辑工具时存在局限性，而 Qwen 2.5 能够稳定处理此类交互任务。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video