琥珀生态瓶 2.0 发布：开源通用 Agent 框架重写状态管理

开源通用 Agent 框架琥珀生态瓶（KohakuTerrarium）发布 2.0.0 版本，重写执行状态管理与多模型协作机制，目标是让开发者不再为每个新 Agent 范式从零造轮子。

今天，开源 Agent 框架 KohakuTerrarium（琥珀生态瓶） 发布了 2.0.0 版本。这是一次几乎重写级别的大更新，作者 Kohaku-Lab 把过去半年社区在 openclaw、Hermes Agent、OpenManus 这些项目上踩过的坑，系统性地塞进了一个通用框架里。

如果你最近也在折腾 Agent，应该能体会到一个很反常的现象：每出一个新范式——不管是 ReAct 的某个变体、还是某种新的多智能体协作模式——大家的第一反应往往是「我从头写一个 Agent 出来 demo 一下」。结果就是 GitHub 上躺着几十个架构高度雷同的 Agent 项目，区别只在最外层那一点点想法。琥珀生态瓶想解决的就是这件事：把那些「每次都要重写一遍」的部分沉淀下来，让新想法只需要写新想法的部分。

这次更新到底改了什么

2.0.0 是个有「破坏性变更」标签的大版本，作者自己也承认 API 和 1.x 不再兼容。核心动作有几个：

1. 执行状态管理重写

这是最值得说的一块。Agent 框架的老大难问题之一，就是「跑到一半挂了怎么办」。LangChain、AutoGen 早期版本都被诟病过：一次几十步的工具调用链，中间网络抖一下就全没了，重跑还得从头来。

琥珀生态瓶 2.0 引入了一套显式的 execution state 模型，把 Agent 的运行分解成可序列化、可中断、可恢复的状态片段。换句话说，你可以随时把一个正在跑的 Agent 序列化进数据库，关机吃饭，明天继续。这听起来很基础，但真正做对的框架其实不多——大部分要么把状态藏在 Python 闭包里，要么序列化得很脆。

2. 多模型协作（Multi-Model Collaboration）

2.0 把模型抽象从「一个 Agent 配一个 LLM」改成了「一个 Agent 可以在不同决策节点上调度不同模型」。这背后是一个很现实的判断：在 2026 年这个时间点，单靠一个旗舰模型扛下所有任务既贵又慢。一个合理的 Agent 应该长这样：

规划阶段用 Claude Opus 或 GPT-5 这种推理能力强的
大量工具调用、代码生成用 DeepSeek 或 Qwen 这种性价比高的
视觉理解任务挂到 Gemini
最后总结输出再回到强模型

生态瓶 2.0 把这种「按节点选模型」做成了一等公民，可以在配置文件里直接声明。对于用聚合型 API 平台（比如 OpenAI Hub 这种一个 Key 调所有模型的服务）的开发者来说，这套机制基本是开箱即用——切换模型只是改个 model 字段，不用改 SDK、不用改鉴权。

3. 「Agent 即 Skill」的配置式工作流

生态瓶强调一个概念：一个完整的 Agent，应该能被另一个 Agent 当成「技能」直接调用。这意味着 Agent 之间要有标准的 I/O 协议、要有可发现的能力描述、还要能嵌套组合。

2.0 把这个做成了配置驱动——你写一个 YAML 描述「这个 Agent 是干什么的、需要哪些工具、用什么模型」，框架自己就能拉起一个可被调用的子 Agent。这种设计思路其实和最近 Google 推的 A2A 协议、以及 MCP 在工具层做的事情有点呼应，只是琥珀生态瓶把它收敛到了 Agent 内部。

琥珀生态瓶 2.0 多 Agent 协作架构示意

和市面上的几个框架比，它定位在哪

这里值得花点篇幅对比一下，因为「又一个 Agent 框架」这个赛道已经很拥挤了。

LangChain / LangGraph：偏向「应用开发框架」，抽象层次很多，灵活但学习曲线陡。LangGraph 在状态机这块做得不错，但整体仍然是个「胶水库」。
AutoGen：微软出品，强在多 Agent 对话编排，但底层假设比较固定，想做非对话式 Agent 会觉得别扭。
OpenManus / Minion-agent：偏「产品级 Agent 复刻」，开箱有完整 UI 和工具集，但定制成本不低。
AgentVerse：研究导向，适合做多 Agent 仿真实验。

琥珀生态瓶 2.0 的定位更接近 「Agent 的 Rails」——它给你框架、给你电池（batteries-included），但同时把扩展点暴露得很清楚。作者明确说了它支持「TUI、Web UI、持久化 session、内置工具、子 Agent」，这些都是产品化必备件，但又不强绑死你的实现方式。

直白点说：LangChain 偏向工程师拼装，AutoGen 偏向研究员实验，琥珀生态瓶想同时吃下这两种用户。这个野心不小，能不能成还要看后续社区生态。

一些具体的设计细节

看了下仓库（github.com/Kohaku-Lab/KohakuTerrarium），有几个细节值得提：

Custom Module 系统：用户可以写自己的模块挂进 Agent 的执行循环，类似 Web 框架的中间件。这对做评估、做日志、做 guardrail 都很有用。
Session 持久化：长会话直接落盘，配合执行状态管理可以做到「Agent 永不掉线」。
TUI + Web UI 双前端：TUI 是给开发者调试用的，Web UI 是面向最终用户。这种「开发态和生产态分离」的设计在 Agent 框架里其实不常见。
批处理与并发：2.0 优化了多 Agent 并发执行的调度，避免了上一版被吐槽的「子 Agent 串行卡顿」问题。

多模型这块怎么落地

既然 2.0 主打多模型协作，那实际配模型时怎么搞？看作者的示例，模型配置走的是 OpenAI 兼容协议——也就是说，只要你的模型服务（无论是官方 API 还是聚合平台）能吐 OpenAI 格式，就能直接接。

models:
  planner:
    base_url: https://api.openai-hub.com/v1
    model: claude-opus-4-6
    api_key: ${API_KEY}
  worker:
    base_url: https://api.openai-hub.com/v1
    model: deepseek-chat
    api_key: ${API_KEY}
  vision:
    base_url: https://api.openai-hub.com/v1
    model: gemini-2.5-pro
    api_key: ${API_KEY}

这种配置方式对国内开发者其实挺友好的——一个 Key 走通所有模型，不用为每家单独搞代理和鉴权。像 OpenAI Hub 这类聚合服务，本身就是为了解决这个场景设计的，配合琥珀生态瓶的多模型节点调度，基本可以做到「想用哪个模型就在 YAML 里换一行」。

还有哪些遗憾

实事求是地说，2.0 也不是没问题：

文档还在追赶。Breaking changes 这么多，但迁移指南目前比较简略，1.x 用户升级要做不少手工活。
工具生态偏小。和 LangChain 那套庞大的 integration 没法比，复杂工具大多还得自己写。
MCP 支持没明说。在 MCP 已经事实成为工具协议标准的当下，没有显式的 MCP server/client 支持是个明显短板，估计是后续版本要补的。
性能 benchmark 缺失。多 Agent 协作的吞吐、状态恢复的开销，作者目前没给数字。

写在后面

2026 年了，Agent 这个词已经被用滥到失去意义。但真正能让开发者「少写代码、多想问题」的框架还是稀缺品。琥珀生态瓶 2.0 在执行状态和多模型这两个最实在的痛点上动了刀，方向是对的。

值得一提的是，作者背景在 LINUX DO 社区比较活跃，琥珀系列项目（之前还有 KohakuBlueleaf 的几个图像模型）在开源圈里一直有不错的口碑。Agent 框架这种东西，技术之外更需要的是耐心打磨和社区反馈循环，从 1.x 到 2.0 的迭代节奏看，作者是认真的。

如果你最近正打算搭个自己的 Agent，或者对 openclaw、Hermes 这种范式好奇但又不想从零开始，这个项目值得 clone 下来玩一下。

参考来源

KohakuTerrarium GitHub 仓库 — 琥珀生态瓶官方仓库，含完整源码、配置示例与文档
琥珀生态瓶 2.0.0 大更新发布帖（LINUX DO） — 作者在 LINUX DO 社区的版本说明与设计理念阐述

琥珀生态瓶 2.0 发布：把 Agent 框架做成「乐高」