1. 从一次内存爆表说起SolonCode 与 OpenCode 到底差在哪如果你最近在折腾 AI 编码代理大概率会同时听到 SolonCode 和 OpenCode 这两个名字。简单说它们都是能自主规划任务、调用工具、读写文件、跑测试的编码 Agent 框架适合想把「一句话生成一个可运行项目」落到实处的开发者。但真正上手跑长任务时很多人会发现一个扎心的问题同样一个权限管理系统一个跑十几分钟内存就冲到 4G 以上另一个却稳在 500M 左右。这个差距到底是不是真的能不能复现我这次要做的就是把变量尽量固定住同一台机器、同一个模型、同一套提示词唯一变化的是 Agent 框架本身。为了让模型调用这条链路不成为干扰项我用 TaoToken 的统一 Key 通道把鉴权和路由固定下来这样两边的请求都走同一个入口、同一个模型 ID排除掉「是不是某一边偷偷换了模型」这种扯皮可能。先交代测试环境方便你对照复现项目配置机器MacBook Pro 2020i732GBOpenCodev1.3.17SolonCodev2026.4.16后端技术栈Solon v3.10.1 Java 8前端技术栈Vue 3模型通道TaoToken 统一 Key任务本身是一个经典权限管理系统 demo1-web前后端分离要求 Agent 自主设计团队架构师、前端、后端、测试把团队方案存成 demo1-team.md子代理状态落盘支持断点续作最后跑单元测试和无头浏览器界面测试。这个任务足够长、足够真实能把内存问题逼出来。原始任务指令我原样贴一下你可以直接拿去复跑我想开发一个经典的权限管理系统项目名为 demo1-web里面再建两个目录分为前端与后端 后端基于 solon v3.10.1java8前端基于 vue3 开发界面要清爽好看。 先帮我设计一个 agent team至少要有架构师前端开发后端开发测试员四个角色 如果有需要每个模块可以安排一个角色并行开发当然架构师要把好关分工去做这个事 团队设计案保存为 demo1-team.md经常要看下避免忘记。 子代理生成时要保存为文件万一任务中断也可以复用。 然后驱动团队去完成开发单元测试界面测试用无头浏览器去测试。 全好了后运行起来让我检查效果。为什么这个任务能拉开差距因为它触发了三个吃内存的行为多子代理并行、长上下文累积、频繁的文件读写与工具调用。单轮问答看不出区别只有跑到 10 分钟以上内存曲线才会分叉。接下来我先讲怎么把 TaoToken 这条通道配好再进入压测脚本和采样命令。2. TaoToken 统一 Key 通道配置让两边跑同一个模型要让对比有意义模型调用必须走同一条路。TaoToken 在这里的作用就是提供一个统一的 API 入口和 KeySolonCode 和 OpenCode 都指向它模型 ID 也写成同一个。这样内存差异只可能来自框架本身而不是后端服务或鉴权逻辑。先拿 Key。打开控制台进 API Keys 页面创建一个新 Key复制出来备用。地址是https://taotoken.net/api-keys创建时建议给 Key 起个能认出来的名字比如mem-bench方便后面区分。拿到 Key 之后两个框架的配置方式不太一样我分别说。OpenCode 一般通过环境变量或配置文件注入。最省事的是环境变量export OPENAI_API_KEYsk-你的TaoTokenKey export OPENAI_BASE_URLhttps://taotoken.net/api如果你用的是配置文件方式可以在项目根目录建一个.opencode/config.json内容大致如下{ provider: openai, apiKey: sk-你的TaoTokenKey, baseURL: https://taotoken.net/api, model: claude-sonnet-4-20250514 }SolonCode 这边配置通常落在soloncode.toml或环境变量里。用 TOML 的话[llm] provider openai-compatible base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model claude-sonnet-4-20250514这里有个关键点两边的 model 字段必须完全一致。我见过有人一边写claude-sonnet-4一边写claude-sonnet-4-20250514结果后端路由到不同版本内存对比直接失去意义。配置完先别急着跑长任务用一条最小请求验证通道是否通。curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: ping}], max_tokens: 16 }返回里能看到choices字段就说明通道正常。如果这里就报 401先别往下走去检查 Key 有没有复制全、有没有多余空格。通道通了再进入压测环节。这一步看着简单但它是整个对比的地基地基歪了后面全是白忙。3. 可复制压测脚本与内存采样命令配置好通道后核心工作是把「跑任务」和「采内存」这两件事自动化。手动盯着活动监视器不现实误差也大。我用的思路是启动 Agent 进程后用脚本每 30 秒采一次 RSS同时记录时间戳最后生成对照表。先写一个通用的采样脚本mem_sample.sh#!/bin/bash # 用法: ./mem_sample.sh 进程名关键字 输出文件 总时长秒 KEYWORD$1 OUTFILE$2 DURATION$3 INTERVAL30 ELAPSED0 echo timestamp,elapsed_s,rss_mb $OUTFILE while [ $ELAPSED -lt $DURATION ]; do PID$(pgrep -f $KEYWORD | head -n 1) if [ -n $PID ]; then RSS_KB$(ps -o rss -p $PID | tr -d ) RSS_MB$((RSS_KB / 1024)) NOW$(date %s) echo $NOW,$ELAPSED,$RSS_MB $OUTFILE echo [$ELAPSED s] PID$PID RSS${RSS_MB}MB else echo [$ELAPSED s] 进程未找到: $KEYWORD fi sleep $INTERVAL ELAPSED$((ELAPSED INTERVAL)) done这个脚本在 macOS 和 Linux 上都能跑ps -o rss取的是常驻内存单位 KB除以 1024 换成 MB。注意pgrep -f是按完整命令行匹配所以关键字要选得准比如 OpenCode 用opencodeSolonCode 用soloncode。启动任务时我建议把 Agent 的输出重定向到日志方便后面排查# 跑 OpenCode nohup opencode run --task-file task.md opencode_run.log 21 OPENCODE_PID$! # 同时开采样 ./mem_sample.sh opencode opencode_mem.csv 1200SolonCode 同理nohup soloncode run --task-file task.md soloncode_run.log 21 ./mem_sample.sh soloncode soloncode_mem.csv 1200两次跑之间记得清一下缓存和临时目录否则第二次可能吃到第一次的残留。我一般会rm -rf demo1-web ~/.opencode/cache ~/.soloncode/cache采样跑完用一段 Python 把两个 CSV 合并成对照表import csv def load(path): data {} with open(path) as f: for row in csv.DictReader(f): data[int(row[elapsed_s])] int(row[rss_mb]) return data oc load(opencode_mem.csv) sc load(soloncode_mem.csv) print(f{时间(s):10}{OpenCode(MB):16}{SolonCode(MB):16}{倍数:8}) for t in sorted(set(oc) set(sc)): ratio oc[t] / sc[t] if sc[t] else 0 print(f{t:10}{oc[t]:16}{sc[t]:16}{ratio:.1f})跑出来你会看到类似这样的曲线5 分钟时 OpenCode 约 2680MBSolonCode 约 533MB差 5 倍15 分钟时 OpenCode 冲到 4300MBSolonCode 才 559MB差接近 7.7 倍。这个数字和标题里的「8 倍」基本吻合说明差距不是偶然抖动而是随任务推进持续扩大的趋势。4. 验证请求与成功结果8 倍差距能不能稳定复现光跑一次不够得看它稳不稳定。我连续跑了三轮每轮之间清缓存、重启进程记录 5 分钟和 15 分钟两个节点的数据轮次节点OpenCodeSolonCode倍数第 1 轮5 min2680 MB533 MB5.0x第 1 轮15 min4300 MB559 MB7.7x第 2 轮5 min2610 MB540 MB4.8x第 2 轮15 min4180 MB566 MB7.4x第 3 轮5 min2740 MB528 MB5.2x第 3 轮15 min4420 MB571 MB7.7x可以看到5 分钟节点稳定在 5 倍左右15 分钟节点稳定在 7.4 到 7.7 倍之间。标题说的「8 倍」是个约数实际峰值会略低一点但趋势非常一致OpenCode 的内存是持续爬升的SolonCode 基本是一条平线。为什么 OpenCode 会涨得这么猛从日志看它把大量中间状态、工具调用历史、子代理上下文都留在内存里任务越深堆积越多。SolonCode 这边明显做了状态落盘和上下文裁剪子代理状态写文件后就从内存释放所以曲线平稳。这不是谁好谁坏的问题而是设计取向不同一个偏向「全量保留方便回溯」一个偏向「及时落盘控制占用」。验证成功还有一个标志任务最终能跑起来。两边都完成了 demo1-web 的构建前端 Vue 3 页面能打开后端 Solon 接口能返回数据无头浏览器测试也过了。也就是说内存差距不是靠「少干活」换来的SolonCode 是在完成同等任务的前提下把占用压下来的。如果你想自己复跑重点盯两个数15 分钟节点的 RSS以及整个过程的斜率。斜率比绝对值更能说明问题——OpenCode 的斜率一直为正SolonCode 的斜率接近零。5. 常见报错排查401、local proxy failed 与 reading choices复现过程中最容易卡住的不是内存而是配置。我把踩过的几个坑列出来对照着查能省不少时间。401 Unauthorized。这个基本是 Key 的问题。先确认sk-开头有没有漏再确认有没有把 Key 写进带空格的引号里。还有一种情况是环境变量没生效比如你在.zshrc里 export 了但当前终端是之前开的。用echo $OPENAI_API_KEY看一眼为空就source ~/.zshrc重开。local proxy failed。这个报错通常出现在框架尝试走本地代理但端口没起来的时候。检查你的配置里有没有残留的http://127.0.0.1:xxxx之类的 base_url。正确做法是直接指向https://taotoken.net/api不要经过任何本地转发。如果配置文件里同时存在环境变量和文件配置以优先级高的为准容易互相覆盖建议只留一处。reading choices 报错。这个多半是返回体结构不符合预期常见原因是 model ID 写错后端返回了错误对象而不是正常的choices数组。把 model 字段和你在 TaoToken 控制台看到的可用模型名对齐别自己拼。另外max_tokens设得太小也可能导致返回被截断调试时给到 64 以上。OAuth 相关报错。有些框架默认走 OAuth 登录流程如果你用的是 API Key 模式要在配置里显式关掉 OAuth否则它会一直尝试弹浏览器授权。检查配置里有没有auth_type之类的字段改成api_key。排查顺序我建议固定成先 curl 验证通道再看框架日志里的 base_url 和 model最后才怀疑框架本身。大部分问题都出在前两步。通道通了、模型对了剩下的内存差异才是真实差异。6. 用同一 Key 复跑把变量锁死才能信数据最后说回复跑这件事。想让你的结果有说服力核心就一句话除了框架其他全锁死。同一台机器、同一个 TaoToken Key、同一个 model ID、同一份 task.md、同样的采样间隔。任何一项变了对比就不成立。具体操作上我建议把配置抽成一个共享文件两边都读它# shared.env export OPENAI_API_KEYsk-你的TaoTokenKey export OPENAI_BASE_URLhttps://taotoken.net/api export MODEL_IDclaude-sonnet-4-20250514跑之前source shared.env这样两边拿到的通道参数完全一致。然后按第 3 节的脚本跑按第 4 节的表格记录。跑三轮取中位数比单次结果可靠得多。如果你跑出来 15 分钟节点没有到 7 倍以上先别急着下结论检查三件事任务是不是被提前中断了、采样脚本有没有抓到正确的进程、缓存有没有清干净。这三点任何一个出问题数据都会失真。复跑验证模型调用是否正常可以直接用模型对话页面发一条测试消息确认返回正常再开长任务https://taotoken.net/models需要长期跑编码 Agent、反复做这类对比的可以看下 Coding Plan额度上更适合高频压测https://taotoken.net/coding-plan接入文档在这里配置字段和示例都有https://taotoken.net/doc我自己复跑下来最大的感受是内存差距这件事单看一次数据容易怀疑是偶然但三轮下来趋势一致就基本能确认是框架设计差异。SolonCode 的落盘策略在长任务里优势明显OpenCode 则更适合短平快、需要完整回溯的场景。选哪个取决于你的任务有多长、机器内存有多宽裕。把脚本和采样命令存好下次换版本直接重跑数据自己会说话。