我最后没 fork AgentScope，决定自己搭
Agora · 第 2 篇 / 共 7 篇
上一篇把赛道摸了一遍：二十几个项目，通用框架和特定游戏两头走，中间缺一个平台层。这篇讲面对这个局面，技术选型具体是怎么做的。
当时的问题大概是这样的：AgentScope 是阿里出的一个多 agent 框架，agent 抽象、消息隔离、记忆系统全是现成的，GitHub 上两万三千星。要搭一个多 agent 平台，fork 它改一改看起来是最快的路。那到底 fork 不 fork？
我跑了八轮自我反驳，结论是不 fork。但「不 fork」不等于「不学」，这两件事得分开看，这个区别挺重要的，后面会反复用到。先把这一轮下来想清楚的三件事列出来：
- fork 还是自建，看的是权重最高的那两三个维度，不是功能清单谁更长。
- adversarial reflection 比拍脑袋可靠——对着具体的技术维度去辩，别对着感觉辩。
- 「不 fork 但偷」是第三条路：代码用自己的，但每个核心模块的设计都有明确的出处。
AgentScope 好在哪
讲道理，AgentScope 做得真的挺好。好在哪，具体拆一下：
- agent 抽象干净。 整个 agent 的行为就两个方法：
reply()和observe()。reply 是「轮到你说话了」，observe 是「这条消息你需要知道」。就这么两个接口，简单，正交，从辩论到狼人杀到剧本杀全都盖得住。这个设计我是真觉得优雅。 - 消息隔离有现成方案。 MsgHub 支持嵌套作用域、动态管理订阅者、自动广播开关。狼人杀那种狼人频道、平民广场、先知视野，MsgHub 都能做出来。
- 记忆系统两层都有。 工作记忆压缩：消息超过阈值，就用便宜模型把旧消息总结掉，留摘要加最近 N 条。长期记忆：关键事件向量化存起来，走 semantic search。斯坦福 Generative Agents 那套 observe → reflect → plan 循环，它也有对应实现。
- 结构化输出。 用 Pydantic 把投票目标约束在存活玩家里，agent 物理上就没法投给死人。
- pipeline 组合。 Sequential（轮流说话）和 Fanout（并行决策）当原子操作，随便组合。狼人夜里并行投票用 Fanout，白天轮流发言用 Sequential。
加权打分
这一圈看下来是挺诱人的。但诱人归诱人，适不适合得另外算。我列了八个维度，按重要性加权打分：
| 维度 | 权重 | 自建 | fork AgentScope |
|---|---|---|---|
| 可插拔模式系统 | 25% | 9 | 3 |
| Web UI 体验 | 20% | 9 | 4 |
| 多模型支持 | 15% | 8 | 7 |
| Agent 抽象 | 10% | 6 | 9 |
| 消息/频道系统 | 10% | 5 | 8 |
| 记忆系统 | 10% | 4 | 8 |
| 部署运维 | 5% | 8 | 5 |
| 社区生态 | 5% | 3 | 7 |
加权总分：自建 7.1，fork 5.6。分数本身我倒不太看重，我看的是结构：权重最高的两个维度，模式系统（25%）和 Web UI（20%），全都大幅偏向自建。
模式系统这块，AgentScope 压根没有「模式」这个概念。MsgHub 是代码级别的消息隔离，不是用户能在 UI 上选的「游戏模式」。我要的是用户从下拉菜单选「狼人杀」或者「圆桌辩论」，频道、角色、流程自动配好——这一整套都得自己建。而这是平台的核心竞争力，占了 25%。
Web UI 这块更直接。AgentScope 是 Python 全栈，前端能力的上限就是 Gradio 和 Streamlit。我要做的是 Accio Work 那种群聊式 UI（头像气泡、实时流式输出、模型标识、频道切换），这个 Python 做不到。占 20%。
也就是说 45% 的权重指向同一个方向。剩下 55% 里 fork 确实有优势，agent 抽象、消息系统、记忆系统都是现成的，但这几项权重加起来才 30%。
反正到这一步，方向已经挺明显了。
八轮自己怼自己
打完分我还是不放心。打分有个天然的问题：你心里想自建，就会不自觉给自建打高分，confirmation bias 躲不掉。所以又跑了八轮 adversarial reflection，每一轮专门挑前面结论的漏洞。挑几轮关键的讲：
第一轮：定位是通用平台，AgentScope 是不是更值钱了？ 要是只做狼人杀，fork 确实没必要。但目标是通用多 agent 平台的话，AgentScope 那套通用 agent 抽象和记忆系统吸引力就大得多了。这一轮有道理，但不改结果——模式系统和房间概念，平台最核心的两个东西，AgentScope 还是没有。净评估从「明显不该 fork」调整成「有争议但仍不推荐」。
第二轮：自建的记忆系统够不够用？ 记忆系统是整个调研里最让我犹豫的部分，AgentScope 这块做得是真完整，工作记忆压缩加长期语义检索都有。自建能做到什么程度？分层看：MVP 阶段一个消息数组加系统提示词就够了。工作记忆压缩，大概 80 行 TypeScript：消息超阈值就用便宜模型总结，留摘要加最近 N 条。长期记忆用 pgvector 做 semantic search，大概 100 行。加起来 200 行，能做到 AgentScope 八成的效果。而且这两个模块在第四阶段（剧本杀）之前根本用不上，前三个阶段消息数组就够了。
第四轮：Python 真不行吗？ Python 在 ML 工具链上的优势是真实的。但在 LLM 应用层，这个优势已经被 Vercel AI SDK 抹平了——多模型支持、流式输出、结构化输出、工具调用，全覆盖。而这个产品的核心价值在 UI 体验，TypeScript 全栈在前端上的优势是决定性的。
第五轮：该不该从圆桌辩论开始，而不是狼人杀？ 这一轮把实施顺序改了。圆桌辩论不需要信息隔离，不需要状态机，一周能出 demo，而且平台所有核心能力（房间、agent、多模型、UI）它全能验证到。狼人杀复杂得多，市场需求 Accio Work 也已经验证过了，不急。所以圆桌辩论先上，狼人杀第二阶段做。
第七轮：那 10% 的遗憾到底在哪？ 这轮最关键。「觉得有点遗憾」这种感觉没法处理，得拆到具体模块上：
- 工具系统？不遗憾，Vercel AI SDK 加 MCP TypeScript SDK 已经覆盖了。
- agent 抽象？稍微有点遗憾。reply/observe 这个双接口设计确实优雅，不过翻译成 TypeScript 就是一个 interface 定义的事。
- 记忆系统？这是真遗憾。工作记忆压缩和长期 semantic search 是 AgentScope 做得最好的两个模块。但前面算过了，200 行 TypeScript 加 pgvector 能覆盖八成，而且第四阶段之前用不上。
第八轮：最终置信度。
| 决策 | 置信度 |
|---|---|
| 不 fork AgentScope | 90% |
| TypeScript 全栈自建 | 90% |
| 从圆桌辩论开始 | 90% |
| Vercel AI SDK 做 LLM 层 | 95% |
| 记忆模块第四阶段前自建 | 95% |
| 不 fork 的遗憾度 | 10% |
90% 不 fork，10% 的遗憾集中在记忆系统，而记忆系统是可以追的。这个账能接受。
什么时候该 fork
这次选型走完，我把方法整理了一下。一共五步：
- 列维度，加权重。 把对项目最重要的维度列出来，按重要性分百分比。分权重这个动作本身就是在做产品思考，它逼你回答「核心竞争力到底是什么」。
- 只看权重最高的两三个维度。 它们都指向同一个方向的话，答案基本就定了。低权重维度上的优劣，只能说是噪音。
- adversarial reflection。 打分有 confirmation bias，想自建就会给自建打高分。解法是每一轮专门找前面结论的漏洞，问「假设 fork 才是对的，我哪里想错了」。
- 量化遗憾。 「fork 好不好」这种问题太模糊，没法处理；要拆到「不 fork 的遗憾具体落在哪个模块，这个模块自己补有多难」这个粒度。模糊的不安拆成具体的工作量，就能算账了。
- 记得有第三条路。 fork 和自建不是二选一，「不 fork，但系统性地偷设计模式」是第三个选项：不背 fork 的技术债，同时每个核心模块的设计都有出处。
下一篇就讲这份偷取清单：从 AgentScope 偷什么，从 ChatArena 偷什么，从斯坦福 Generative Agents 偷什么，怎么拼成一个平台架构。文章在这：偷取清单：从 20 个项目里拆出一个平台。