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