轻量框架

2026 年做 Agent，未必一上来就上重型编排框架。很多场景只是「接一个模型、配两三个工具、跑一个循环」，重型框架带来的抽象反而成为负担。轻量级选型的思路是：先跑通最小闭环，再按需长骨头。从零到可用的标志很朴素——你能用几十行代码让模型调通一个工具、拿到真实结果、在失败时优雅退出。围绕这个最小闭环选依赖，而不是被框架的特性清单牵着走。 最小闭环到底需要哪几块？ 一块不能少的是模型客户端：负责发请求、解析工具调用。一块是工具注册表：每个工具一个函数，带上名字、描述、参数 schema，运行时按名分发。一块是循环控制：模型输出调用请求，你执行，把结果喂回去，直到它给出最终答案或触顶。再加上最朴素的日志，闭环就成了。这三块加起来，在主流语言里往往几十行就能写完。判断一个轻量框架是否值得引入，标准就是：它替你省的代码，是否少于它加的概念。如果看完示例你仍说不清「工具在哪注册、循环在哪停」，那它对你就不轻。 什么时候该从自研小闭环升级到成熟框架？ 自研小闭环的甜蜜期很短，遇到下面这些信号就该升级了：需要多个角色协作、需要持久化的中间状态、需要可视化地跑流程图、需要内置的人审节点、需要跨任务的长期记忆。这些能力自己造轮子会越写越重。务实的路径是先自研验证业务真需求，跑两三周发现自己在手写状态管理、手写重试、手写工具分发时，再迁到成熟框架。别反过来——先上框架再找场景，结果往往是为用不上的抽象买单。轻量不是目的，刚好够用、看得懂、改得动，才是从零到可用的标准。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论