yetone

大家放心，magpie 正在着重优化性能问题，接下来会给大家一个满意的体验

按着 Agent 的头修的（

已在 v0.1.1277 发布 🎉 开关在：设置 › 回复 › 精简 Claude 系统提示词（默认关）。已安装的 magpie 会自动更新，或到 usemagpie.ai 下载。

magpie 的 Claude 订阅为什么更费 token？这次改了什么、省了多少： 以前：magpie 用真的 Claude Code 跑你的请求。每个请求都带着 Claude Code 自己的系统提示词，你 agent 的指令只能塞进第一条用户消息里。等于每次请求都多付一份 Claude Code 的提示词，约 1K token。 现在：设置里新增「精简 Claude 系统提示词」开关（默认关）。打开后，Claude Code 启动时用 --system-prompt-file 把你 agent 自己的指令作为系统提示词，替换掉 Claude Code 那一份，第一条消息只剩对话本身。 真实订阅实测（Sonnet 5.5）： · 每个请求固定省约 0.9–1.2K token · 轻量聊天客户端，3 轮：输入 10,048 → 6,580 token（−35%） · claude -p 这种自带大提示词的客户端，4 个请求：85.4K → 81.9K（−4%） 客户端自己的提示词越小，省得越多。注意：发请求的仍是真的 Claude Code，但不再带它自己的提示词，看起来没那么像 Claude Code 本身，账号风险请自己权衡。下个版本发布。

Magpie 现在全面插件化了 🧩 以前社区插件只能接入新的订阅；现在 Magpie 自己的几乎每一层都向社区开放，一个 npm 包就能扩展： • 订阅 / Provider：登录、刷新、模型、请求、用量全由插件负责 • 网关中间件：改写经过 Magpie 的请求和响应 • 路由策略：自己决定请求怎么在多个账号、多个模型之间分配 • onUsage：每一条用量记录插件都能收到 • 工具：插件写的工具通过 Magpie 的 MCP 服务器，给每一个接入的 Agent 用 • Agent：让 Magpie 支持一个新的 Agent • 页面：插件在 Magpie 窗口里有自己的页面，跑在沙盒里 入口：Magpie › 插件 › 发现，每类插件各有分区；点「编写插件」直接打开文档。 文档：usemagpie.ai/docs/plugins 社区仓库：github.com/magpie-community/plugins 三个示例已经发到 npm：tools-calc（精确计算、单位换算、日期计算工具）、page-usage（用量一览页面）、middleware-reserve（留余量的路由策略）。 magpie plugin add @magpie-community/tools-calc 一行装好。来写插件吧 👇

好久没打开 Yansu 了，今天突然打开了一下，这个自动生成 Memory 的功能还是让我暖心

帮转

所以说每一家订阅商有每一家订阅商自己的花活儿，如果不插件化的话，Magpie 要处理的 edge case 实在是太多了。

帮转

我是上闲鱼，不管 kyc 还是啥都上闲鱼解决

话说 Muse Web 和 Muse Code 是一个东西吗？ 社区已经支持了 Muse Web：github.com/JohnWangggg/magpie-muse-web

Anthropic 这种公司嘛，Claude 这种产品是有受众的（

哈哈😭

昨天因为我前天早上发挥低素质能力精确优雅地运用 6 个「操你妈」和 2 个「你妈死了」辱骂了几个对我阴阳怪气恶意抹黑者，导致被他们举报后因违反推特规定我的推特账号被封禁 12 个小时。所以有些事情没来得及过来补充。现在解封后特地来补充一下。 当时关于为啥相对激进地采用这种工作流，主要是因为我在一开始设计 Magpie 的时候，就是想把 Magpie 做为一个运行在用户本地的 Agent 基础设施，让它作为一个 bridge 去连接散落在用户本地电脑上的各式各样的 Agent 和越来越多难以维护的大模型订阅供应商，解决两者没打通导致每个人每个月手里浪费大量订阅的 Token 甚至因为供应商绑定导致无法切换 Agent 等等一系列问题。 但挑战也随之而来，因为我用过的 Agent 就那么几个，听说和订阅过的供应商也就那么几家，可是这个世界上的 Agent 和供应商都太多了，而且相互之间各种差异，每个人都有自己独特的偏好，更何况每个 Agent 都有自己千奇百怪独有的配置和设计，供应商自己也有千奇百怪的订阅花活儿，所以一旦把产品交付出去，那么我注定无法应对所有人的各式各样的 Agent 和供应商的支持需求，所以 Magpie 在早期它注定就应该是 UGC 的，也就是用户提需求我来帮其实现。所以我才自然而然地打造了这一套 Agent loop 工作流。 但是 Agent driven 的 UGC 也是有风险的，比如很多人在吐槽的 Magpie 看起来一直在堆砌功能在产品观上没有克制，以及因为要快速交付获得反馈导致发版过快让人觉得不靠谱，其实事情一直都在起变化，最近这一切都在极大地缓解，首先现在 Magpie 已经把 Provider 和 Agent 分别都插件化了，这个解耦导致以后相关它们的新的支持和修复都不需要动 Magpie 产品本身。其次，Magpie 下一步就是在保留最核心功能框架的基础上把所有的功能包括 UI 都插件化，让 Magpie 本身变得轻盈的同时不阻碍它做迭代和功能扩展。

对了，还漏了一个关键点，就是你要把真实的运行环境提供给 Agent。比如你要有一台 macOS 电脑以及一台Windows 电脑，然后在 Windows 上再创建个Linux虚拟机。这样的话，三端的复现环境就已经提供完毕了。让Agent 每次都要在这三端上去真实地复现 bug 并去修复就可以了。

很多人想让我分享一下工作流，我一直没想好怎么分享，因为其实我没有任何的魔法，甚至还特别简陋，总觉得分享出来毫无意义。其实我就是用 Claude Code，然后用官方的 Opus 5.5 模型执行 loop 就可以了。 我会并行执行图里的 3 个 loop，然后每晚抽一点时间铲铲屎（主要是 UI/UX 的问题），然后就没活儿了。

牛啊！这个太实用了！

事情正在起变化

在 X 查看视频

帮转！