我最后没 fork AgentScope，决定自己搭
Agora · 第 2 篇 / 共 7 篇
上一篇把赛道摸了一遍，二十几个项目，要么是通用框架，要么是专做某一个游戏的，中间缺一个平台层。这篇讲在这种情况下，技术选型具体是怎么做的。
当时的问题大概是这样。AgentScope 是阿里出的一个多 agent 框架，GitHub 上两万三千星，agent 抽象、消息隔离、记忆系统全是现成的。要搭一个多 agent 平台，fork 它改一改看起来是最快的。那到底 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 个项目里拆出一个平台。