yetone

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

其实我很害怕「大佬」这个词，求求了别叫我大佬了，只要不叫我垃圾叫啥都行。 另外我也很害怕「粉丝」这个词，顶多叫关注者，所以我一直都说 followers ，不然真的像被架在火上烤一样难受。 我关注数多只是因为长期以来的生活中的孤僻导致互联网上话痨以及没有别的爱好只想写写代码，无他惟孤独尔。

我的需求是好的，只是下面的 claude code 执行歪了。

这就是中国人能飞和中国人会飞的区别。

昨天因为我前天早上发挥低素质能力精确优雅地运用 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 本身变得轻盈的同时不阻碍它做迭代和功能扩展。

哈哈😭

说实话，相对于他们，你这种人才是我最讨厌的。你比他们更抹黑我百倍千倍不止啊！在你面前，他们简直就是小清新

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 本身，账号风险请自己权衡。下个版本发布。

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

哈哈，这就是我给自己的赛马模式，我为了加新的产品链接，会淘汰一下旧的产品链接（

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

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

帮转

为什么我抢不到😭

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

话说 Muse Web 和 Muse Code 是一个东西吗？ 社区已经支持了 Muse Web：https://t.co/ldd2YI2LME

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

帮转

@turingou 有道理啊