工具选型与迁移：一年换过多个框架之后的标准
一年里我在本机先后长期使用过多种智能体框架，也自己改造过一个。外界看是"换得很勤"，但每次迁移背后都是同一个问题：当前框架的能力边界，是否已经挡住我手上的任务类型。
一、评估维度
我用下来稳定有用的判断维度是这几条：
| 维度 | 具体看什么 |
|---|---|
| 上下文容量 | 能否在不频繁截断的情况下处理长文件与长会话 |
| 长任务能力 | 是否支持目标模式、自动续跑、无人值守执行 |
| 多智能体 | 能否派发子任务并各自独立完成 |
| 可扩展性 | 是否支持插件、技能、MCP 这类外部能力接入 |
| 可控性 | 能否接本地模型、私有部署、自建服务 |
| 成本 | 额度模型是否适合长时间运行 |
二、什么时候该换
触发迁移的从来不是"出了新工具"，而是任务类型变了，而工具的能力边界没跟上：需要跑几小时的自主任实验、需要在超大代码库上工作、需要把子任务并行发出去——这些需求在原框架里没有对应机制时，迁移才发生。
三、什么时候不换
反过来，有几种情况即使新工具更好，我也会先不换：
- 增量收益小于迁移成本：迁移的不只是配置，还有已经积累的规则、记忆与习惯；
- 旧项目仍在进行：让旧项目在原框架里跑完，新任务再用新框架，而不是把所有历史一次性搬过去；
- 只是"更流行"：社区热度不等于能力边界变化。
四、什么时候自己改
当需要的能力上游不可能提供（因为它是项目特定、或者上游有其它取舍），自研才有意义。我的做法是增量改造而不是重写：以开源实现为底座，只移植真正需要的特性，其余保持上游结构。这样上游升级时冲突面小，出问题也容易定位责任边界。
五、真正的资产不在框架里
这是这一年最重要的一条结论：记忆、规则、方法论不应该存放在任何框架内部。
它们以文件形式存在于项目目录中；框架只是"执行层"，随时可以替换。这样看，"换了几个框架"这件事本身并不重要——重要的是每次迁移时，真正的资产没有被留在身后。
六、体会
把工具当执行层、把方法与记忆当资产，选型问题就从"哪个工具最好"变成了两个更清楚的问题：当前任务需要什么能力，以及迁移时什么会留下。前者决定要不要动，后者决定动得起动不起。