Agent 平台选型实测：3 个月 80 亿 token 后，主力为什么是 WorkBuddy
过去三个月，我在 AI 开发上烧掉了大约 80 亿 token。这个数字不是炫耀，它是四家平台各跑一遍之后的账单合计数——也正因为交了这笔钱，我对"哪个平台能当主力"这件事，有了和半年前完全不同的判断。
这篇不讲跑分，只讲实测。包括我为什么最后把大型项目全部压在一个平台上，以及豆包办公、千问办公、豆包各自在我这里处于什么位置。
先给结论
- 大型、长周期、要跑在生产环境里的项目，我现在只放在 WorkBuddy 上。
- 豆包办公是我会主动打开的第二个产品，它的云电脑与多端同步是真差异化。
- 千问办公用得少，如实说：当前阶段它落后于前两家，这与它新出不久有关。
- 豆包单看内容生产不错，但以我的使用强度算，性价比不成立；不能自定义模型，是我不会选它当主力的核心理由。
判断一个 Agent 能不能当主力，我现在只看三条：成本可控（能不能换模型、能不能分层用）、长任务稳定（会不会写着写着自己崩掉）、多端协同（手机指挥与电脑指挥是不是同一件事）。
一切都从"一个工地"开始
我的重度 AI 开发，是从自己做一个网站开始的。起因是 DeepSeek 发布了 Harness（dsh）这个 Agent 框架，我第一时间上手，给它的评价是一句大实话：它不是毛坯房，它是一个工地。
毛坯房至少还有墙、有顶、水电接好了。工地是另一种景象：地上有钢筋有水泥，但房子得你自己盖。dsh 把"智能体框架"这个底座给到了，能力边界极大，可生产力要靠插件一块一块堆出来。
于是我去找原料，也就是插件。在 GitHub 上翻了很多，踩的坑很集中：装不上的、装错的、装完直接报错的，还有一批插件，我把详情页从头看到尾，仍然不知道它到底干嘛用。
这件事让我意识到这个生态里被忽略的空白：插件这一层缺的从来不是数量，是筛选和验证。 总得有人先跑一遍——哪些能用、哪些会报错、哪些更适合谁。
这就是 DeepSeek Harness Hub 的起点。它的定位很直接：把 dsh 插件先替你测一遍、验一遍，再告诉你它是干什么的。顺便说一句，写这个网站我用的是 WorkBuddy 而不是 dsh 本身——原因很实际：dsh 早期版本太不稳定，写着写着自己就崩了，前几个版本的能力也确实不够。所以我主力干活的 Agent，从那时起就固定了下来。
这里没有贬低 dsh 的意思。我的立场是：dsh 是个好底座，但"底座"和"生产力工具"是两件事。 一个给你最大的自由度，一个替你把事情做完。
WorkBuddy：我的主力，两个理由
第一个理由是可以自定义大模型。这对开发者是刚需，不是加分项。不同模型擅长的方向和它的价格都不一样：便宜模型适合批量干脏活，贵模型适合做架构判断和难决策。你必须有能力把"什么事交给什么样的 AI"分清楚，成本才可控。不能换模型，等于你所有任务都按最贵的价格结账。
所以我认为，自定义大模型是现阶段一个合理 Agent 的必备能力。
第二个理由是长任务的稳定性与可行性。一个网站从写代码，到批量处理数据、批量发版、批量产出内容，是一条很长且不能轻易断的链路。这条链路上，稳定性比单点聪明重要得多。
豆包办公：发布第一天我就开始用
豆包办公是发布当天我就上手的，用下来我认为它相当成功，有三点非常吸引我：
- 自带一台云电脑，等于直接给你分一块服务器资源，不用自己张罗环境。
- 多端的信息同步与会话同步做得非常好。我用手机指挥电脑干活、用电脑指挥电脑干活、用电脑指挥云电脑干活，这三件事对我来说没有任何区别。这种顺滑程度是被严重低估的能力。
- 内容输出层面，它甚至比 DeepSeek 更好，也比 WorkBuddy 更好。
所以它在我的工作流里有明确位置：不是主力生产工具，而是内容侧和"随手指挥"的那一环。
千问办公：用得少，如实说
千问办公我用得比较少。它刚出来的时候我自己也试过，目前看它落后于前两家。
落后在两个地方：一是自定义模型能力，二是离线办公生产东西的速度。不过要给一个客观前提——它新出不久，早期版本不成熟是正常现象。另外我也没拿它干太多深度任务，因为项目已经跑在 WorkBuddy 上了，这个阶段我不太敢突然整体换。
后续我可能会考虑切换一部分工作过去，比如让它承担类似豆包那类内容生产任务。
豆包：内容不错，但性价比不成立
豆包的问题不在能力，在成本结构。
订阅七十多块钱一个月，真正能干的事不算多。像我现在开发网站这种强度的活，交给它，一个月的积分肯定不够。我给一个具体的量感：豆包一个月的积分，大概够每天生产十几到二十篇自媒体内容，几乎就用完了；稍微让它干点重活，积分很快就见底。
再加上它不能自定义模型，我就没法把便宜的任务导到便宜的模型上去。所以在"大型项目"这个场景里，它对我就不成立。
"能不能换模型"是一道分水岭
这是我这几个月最深的一个体会，值得单独讲。
一个网站的日常是什么？批量汉化、批量验证、批量产出内容、批量发版，再加上架构设计、Bug 定位、方案评审。这些活的单位价值差别巨大：
- 批量汉化几万个条目、批量跑验证：量大、单价低，应该交给便宜模型；
- 架构决策、疑难 Bug、长链路重构：量小、单价高，应该交给贵模型。
能不能分层，直接决定你的月度账单是三千还是三万。这就是我把"自定义模型"放在判断标准第一位的原因——它不是功能差异，是成本结构的差异。
三条可执行建议
- 先算你的月度消耗量级，再选平台。 每天十几篇内容的量级，和跑一个持续迭代的网站，是完全不同的两个物种。用错量级去选，结论一定是错的。
- 把"能不能换模型"当第一道筛选。 只要这条不满足，就不要把它放进主力位置，无论它其他功能多好看。
- 不要一次全换。 我的做法是：老项目继续跑在原平台上不动，新任务才拿去试新平台。整体切换的迁移成本，远高于试错成本。
还有一条给做开发的人：先看生态，再看产品。 一个开放框架能给到你的上限，取决于它周边有多少经过验证的插件。这一点上我踩的坑比谁都多，所以我干脆把它变成了一个产品。
我做的那个插件库
上面那些坑——装不上、装错、装完报错、看不懂是干嘛的——我把它做成了一个网站：DeepSeek Harness Hub（dpharness.com）。
它是 dsh 的插件导航站，核心只做一件事：把插件先替你测一遍、验一遍，再告诉你它是干什么的。 截至发稿，站上的实时数字：
- 收录插件 11,602 个
- 已完成中文汉化 11,508 个
- 命令可直接安装（自动检测通过）1,831 个
- 实装验证持续覆盖中 3,473 个
它的判断依据不是人工推荐，而是三层可核验的信号：命令可直接安装（自动检测通过，复制到终端即可执行）、已汉化（中文名与中文说明就位）、实装验证（在真实环境里装过一遍，结果分级记录）。一个插件拿到几个勾，一眼就能看出它能省你多少事。
几个你可能会用到的入口：
- 精选榜单：按真实周下载量排序，不看营销看使用。榜首 dsh-market 周下载 128,104，DSH-better-sidebar 97,317，上下文透视面板 31,332——这些数字比任何推荐语都可信。
- 严选插件：我自己在用的那一批，每个都有明确用途说明。
- 每个插件页都带安装命令：检测通过的会直接给一条可复制的命令，粘到终端就行，不用自己啃源码。
全部免费，不需要注册就能查。如果你也在用 dsh，或者正准备开始用 dsh，建议先把插件挑明白再动手——能省掉的时间比你想象的多。
写在最后
三个月 80 亿 token，最后沉淀下来的其实不是"哪家更强"，而是一套判断标准：先看成本结构能不能分层，再看长任务会不会断，最后看多端顺不顺。
工具会换，标准可以留下来。这也是我做那个插件库的原因——把踩过的坑，变成别人不用再踩的路。