一个多供应商库为何要把自己改写成框架

该团队做了一件反直觉的事——一个用了几年的多供应商库，突然把自己推倒重来，变成了完整的框架。版本号跳到 3.0.0 的时候，他们引入了一套基于事件驱动的架构，核心概念叫"控制反转"。

这不是技术术语的堆砌。控制反转在这里的意思是：开发者不再被塞进固定的顺序流水线里。人类、智能体、观察者和工具，可以在同一个共享环境里协作。参与者能发射、观察、响应带类型的上下文项，而且是实时的。

多智能体编排因此变得更灵活、可组合、可并发。但问题是，为什么非要走到这一步？一个库不够用吗？

从字符串到类型化上下文

3.0 版本引入了一个关键改变：结构化、多供应商兼容的上下文模型，遵循 OpenResponses 规范。

传统做法是把提示词当纯字符串处理。新版本的做法是建模为带类型的上下文项，包括系统消息、开发者消息、用户消息、工具结果、推理结果等。

这种结构让开发者能给语言模型更清晰、更精确的指令。比如，把系统、开发者、用户消息分开，比全塞进一条用户消息里要规整得多。

更重要的是，这种结构让模型交互变得可检查、可存储、可回放、可跨供应商适配。上下文不再是黑箱里的临时字符串，而是显式的、可移植的数据结构。

现在通过 ModelContext 把上下文建模为有序的上下文项聚合。这为短期工作记忆和长期持久化提供了结构化基础。框架包含仓库接口，允许通过不同存储后端保存和检索上下文。

内存实现是框架自带的，开发者也可以自己实现文件系统、数据库或其他持久层的仓库。记忆因此保持显式、可移植、供应商无关。

异步生成器：非阻塞的核心机制

3.0 在框架的关键部分引入了异步上下文项生成器，包括输入处理、推理和函数调用执行。

传统做法是依赖阻塞式的 await 链。新版本的做法是让运行器通过异步可迭代对象随时间产生上下文项。这使得项可以被实时生成和投递，同时让开发者控制何时以及如何消费这些流。

框架为函数调用执行和 OpenAI 推理提供了默认实现。开发者也可以创建自己的实现，这对测试、模拟运行器、定制工具执行或添加额外模型供应商支持特别有用。

这里的核心取舍是：延迟确定性与实时响应性的交换。阻塞式代码写起来简单，但智能体之间的协作会被串行化拖慢。异步生成器增加了认知负担，但解锁了真正的并发。

参与者与环境：协作的抽象层

3.0 的主要目标是让 AI 智能体以非阻塞方式协作。

团队认为，真正的智能体系统不应该被限制在顺序链里。很多真实用例中，智能体需要并发地观察、反应、贡献。

为此，新版本引入了 Participant（参与者）抽象和 AgenticEnvironment（智能体环境）。参与者加入同一环境，对到达的带类型上下文项做出反应。人类和智能体作为参与者，订阅其他参与者生成的上下文项。当一个参与者产生新项时，其他人可以实时响应。

这个设计把"智能体协作"从代码层面的调用关系，提升到了环境层面的事件订阅。智能体不再是主动调用工具的程序，而是对环境变化做出反应的参与者。

为什么是现在？

从库到框架的跃迁，通常意味着项目野心的膨胀。但路线图暗示了更深层的判断：多智能体系统正在从演示走向生产，而生产环境需要的不只是能跑的代码，而是能协作的架构。

控制反转、事件驱动、异步生成器——这些不是新发明，但组合在一起，指向一个特定的技术赌注：未来的智能体系统不是管道，而是生态系统。

3.0.0 的发布，是这个赌注的第一次完整表达。