yetone @yetone

昨天因为我前天早上发挥低素质能力精确优雅地运用 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 本身变得轻盈的同时不阻碍它做迭代和功能扩展。 [引用 @yetone]: 很多人想让我分享一下工作流，我一直没想好怎么分享，因为其实我没有任何的魔法，甚至还特别简陋，总觉得分享出来毫无意义。其实我就是用 Claude Code，然后用官方的 Opus 5.5 模型执行 loop 就可以了。 我会并行执行图里的 3 个 loop，然后每晚抽一点时间铲铲屎（主要是 UI/UX 的问题），然后就没活儿了。