智能体框架怎么选：先分清三类东西，再看四个维度

搜「智能体框架」的时候，你会发现候选名单里混着三类完全不同的东西：LangChain 这类编排库、Dify 这类可视化平台，还有 Downcity 这类 Agent 运行时。它们都能出现在演示里跑通一个 Agent，但解决的问题不在一个层面上。

所以选型的第一步不是对比功能表，而是先认清你要的是哪一类。

三类东西的区别

这张表里最关键的一列是「由你实现」。编排库和平台并不是不好，而是它们不承诺承担状态、权限和成本这三件事。你可以自己写，只是要知道这是你自己在写。

四个判断维度

不要从「哪个框架更火」开始问，从这四个问题开始。

一、这个 Agent 跑多久

如果它在一次请求里跑完就结束，进程内存在就够了。

如果它需要跑几周、跨重启、跨部署，那你必须有一个能持久化、能恢复、能分叉的 Session 存储。这是「编排库能不能用」的第一道分水岭，也是最常被低估的一条。

二、谁来碰它碰的东西

只给自己用的时候，工具权限放开无所谓。

一旦有真实用户，你就必须能回答：这个 Agent 可以读写哪些路径、可以调用哪些外部接口、哪些动作需要人工审批。注意这里有两件事——策略（该不该允许）和强制（物理上能不能发生）——只做前者的系统，出问题时挡不住。

三、多个产品是否共用一套后端

多数团队要交付的不是一个 Agent，而是控制台、扩展、API 和内部工具同时要跑同一套模型与账号。

如果每个入口各接一遍，你会得到四份模型配置、四份用量记录和四份账单。能不能复用同一套后端，决定了后续维护成本是线性还是指数。

四、成本能不能归因

token 开销是真实成本。如果用量无法归因到某个用户、产品或会话，你就没法定价、限流，也没法回答「上个月账单为什么翻了三倍」。

归因必须在调用发生时采集（也就是在模型边界上），事后从日志反推只能得到近似值。

选型清单

把下面几项直接拿去问候选方案，答案比任何功能列表都有用：

• 进程重启之后，正在跑的任务能不能接着跑？
• 会话能否恢复、分叉、重放？
• 工具是显式装配的，还是自动发现的？
• 权限是策略，还是同时有沙箱强制？
• 是否有需要人工审批的动作，审批链路在哪一层？
• 用量能否按用户 / 产品 / 会话拆开？
• 多个产品能否复用同一套模型与账号体系？
• 换模型要改配置，还是改代码？
• 出问题时，能否还原「它做了什么、为什么」？

如果候选方案在「重启后能不能接着跑」这一项就答不上来，那它多半是编排库，你需要再补一层运行时。

三个常见误区

误区一：把编排库当成运行时。 编排库擅长表达逻辑，不负责进程、持久化和权限。demo 跑通不等于能运营。

误区二：以为上了可视化平台就不用管架构。 平台替你挡掉了一部分问题，代价是你的状态与权限被锁在平台里；当你要把 Agent 做成自己的产品时，这层依赖会变成迁移成本。

误区三：先挑模型，最后才想运行时。 模型是可以换的（前提是提供方逻辑没有渗进你的控制流）。运行时决定了这个 Agent 能不能长期活着，换起来要贵得多，应该先定。

Downcity 处在哪里

Downcity 是第三类：一套开源 Agent Harness 加上让它可交付的配套 Kit。它不替代你已有的编排方式，而是把上面那四件事收进运行时：

两个设计选择值得单独说明：能力显式装配（由调用方决定挂哪些工具，权限才可审计），以及产品边界与运行时分离（产品负责体验，运行时负责模型、权限、用量这些被反复重建的基础设施）。

常见问题

智能体框架有哪些类型？ 大致三类：编排库（偏代码、要自己补基础设施）、低代码平台（偏可视化、状态与权限在平台内）、Agent 运行时（承担进程、状态、权限与成本）。选之前先确定你要哪一类。

智能体框架和 Agent Harness 是一回事吗？ 不是。框架帮你描述 Agent 的行为，Harness 是运行它并治理它的那层。多数团队最终两者都需要。

可以不用框架，直接自己写吗？ 可以，而且很多团队就是这么起步的。诚实地说：你会把会话持久化、沙箱、权限校验、用量核算和多入口访问重新实现一遍。如果没有特殊诉求，从现成的运行时起步更快。

选型时最该先确认哪一条？ 「重启之后能不能接着跑」。这一条能最快区分编排库和运行时，也是后期最难补的。

中文生态里常见的那些工具怎么归类？ 判断方法同上，看它承不承担进程、状态、权限和成本。不承担的那部分，最终都要由你补上。

下一步

想先动手看效果，可以安装并启动第一个 Agent，几分钟内就能拿到一个真实的 Session、Workspace 和权限边界。

想先看清架构，建议读 Agent Harness 是什么 和 内部构造，后者逐个拆解了运行时持有的十个子系统；白皮书则解释了这些边界为什么该这么画。