2026 年开源 Agent 框架现状：Hermes · LangGraph · 我们的选择

如果你在 2026 年为生物制药构建多租户 Agent 运行时，框架决策比模型决策更重要。模型每季度都变。框架定义了未来几年里你的租户隔离、审计追踪、Skills 互操作、扩展性故事。

我们在选择 fork 哪一个作为 inCore 基础前评估了 8 个候选。这篇是这个决策的诚实复盘 —— 看了什么、选了什么、为什么、如果重做会改什么。

结论先说：我们 fork 了 Hermes Agent（Nous Research，MIT），加上 21 CFR Part 11 审计层、多租户隔离、IBS 集成。LangGraph 因多租户故事被淘汰，Dify 因 license 被淘汰，自建因维护成本被淘汰。

决策标准

我们用的 8 个标准，按生物制药 SaaS 实际需要的权重排序：

1. License 兼容性（必须允许 SaaS 转售而无需 per-customer license fee）
2. 多租户原语（架构内建 vs 后期拼装）
3. 长流程工作流支持（CMC 工艺以周计，不以秒计）
4. 审计追踪粒度（21 CFR Part 11 不可妥协）
5. Skills / tools 互操作（agentskills.io 标准重要）
6. 生产成熟度（实战检验 vs 研究原型）
7. 活跃维护社区（上游需要持续推进）
8. 代码质量（我们要读这个代码好几年）

我们看过的候选

LangGraph（LangChain Inc · MIT）

• 优势：成熟，社区大，文档好。
• 劣势：多租户故事是后期拼装的，不是架构性的。长流程工作流需要 Postgres state-store 接线，繁琐。审计追踪是 logger 输出，不是一等公民。
• 结论：很好用于应用内 agent 工作流；不那么适合托管 100+ 租户的多租户运行时。

Hermes Agent（Nous Research · MIT）

• 优势：多租户原语是架构性的。长流程工作流集成是一等公民（委托给 Temporal）。代码质量优秀。License 宽松。
• 劣势：社区比 LangGraph 小。某些集成模式（自定义 LLM gateway · 区域感知路由）需要 fork-and-patch。
• 结论：多租户运行时的正确起点。fork-and-patch 是入场费。

Dify（开源 · Apache 2.0 + 商业附加条款）

• 优势：开箱即用托管、预制 UI、自带 model-router。
• 劣势：license 商业附加条款 —— 多租户 SaaS 转售需要谈授权。架构对准的是"ChatGPT-clone"用例，不是长流程生物制药工作流。
• 结论：对 biotech 初创内部 demo 很好。对受监管 SaaS 平台是错误起点。

FastGPT（开源 · Apache 2.0 + 附加条款）

• 结论：与 Dify 同样的权衡。同样的 license 顾虑。同样被淘汰。

n8n（Sustainable Use License）

• 结论：license 明确限制 SaaS 转售。错误起点。

自建（无框架）

• 优势：完全控制。
• 劣势：每个框架的痛点都成为你的痛点，但你不会得到它们的任何修复。我们估计要 12-18 人月才能在多租户原语上追上 Hermes。
• 结论：因维护成本淘汰。我们到现在还在写审计追踪抽象。

CrewAI

• 结论：很好做自主 agent demo。不为人在回路的、有审计义务的长流程工作流设计。

Microsoft AutoGen

• 结论：强的研究框架。多租户生物制药 SaaS 的生产成熟度还没到。

为什么 Hermes 胜出

三个具体特性：

1. Profile 抽象 —— Hermes 的租户隔离围绕 Profile 构建，它携带 Memory、Skills、tools。Per-tenant Profile 加严格隔离成为我们多租户故事的基础 —— 我们不必发明它。

2. 一等公民 Temporal 集成 —— 生物制药流程以周计。Hermes-Temporal 交接已经连好。我们加 21 CFR Part 11 审计 hook；Temporal 存其余。

3. agentskills.io 对齐 —— Hermes 已经对齐了正在浮现的 agentskills.io Skill manifest 标准。这意味着为 inCore 写的 Skill 在 Claude Code、Cursor 以及任何 agentskills.io 兼容运行时都能跑。我们享受到更大生态的红利。

我们 fork / 加了什么

我们在上游 Hermes 之上放的四样东西：

1. 21 CFR Part 11 审计层 —— 每个 Agent 动作、Skill 调用、工具调用都生成 tamper-evident 审计记录。Temporal 存它；我们的 middleware 强制执行。
2. IBS 集成 —— IBS 是 Inscinstech 与企业客户用的账户 / 计费 / 审计系统。inCore 原生与之对话。
3. 区域感知 LLM 路由 —— 客户 CN 数据必须留在 CN。Hermes LLM gateway 抽象让这是一个 200 行的添加；架构已经支持。
4. 多租户 K8s namespace 投影 —— 每个客户得到一个专门 namespace。Hermes 的 Profile 在部署时 1:1 映射到 namespace。

我们每季度同步上游 PR。我们没必要维护长期分歧的 fork —— 我们大多数添加活在自己的模块里，不在上游文件里。

重做会改什么

两件事：

1. 从审计层开始。我们是在有 Agent 运行时跑起来后加 21 CFR Part 11 审计 hook 的。事后改装比从"每个动作从第一行就被审计"开始更难。

2. 把区域感知路由作为一等配置。我们当成附加项处理。它应该从第一天就是一个配置维度。

这事的 license 披露面

Hermes 是 MIT。我们 fork 在继承部分也是 MIT；我们的添加（审计层 · IBS 集成 · 多租户投影）是 Inscinstech 专有的闭源。我们保留上游 LICENSE 与 NOTICE 文件；我们对 fork 关系完全公开透明。

完整披露：/security/open-source。

如果你也在选

如果你也在 2026 年为类似用例选 Agent 框架，三条建议：

1. 先看 license。某些好框架带的附加条款你做 SaaS 转售活不下去。读 license 再读文档。
2. 多租户是架构性的，不是后期拼装的。要么框架为它设计要么没有。你不会干净地后装回去。
3. 如果你的工作流超过 5 分钟，挑一个 Temporal 式骨干的框架。CMC 工作流以周计。你不能在 in-process 跑那些。

我们乐意与做同样决策的团队聊聊 —— 联系我们。生物制药特有的经验不在框架文档里。