我最早做 Agent 开发的时候，第一反应是找功能最全的框架。LangChain 什么都有：Chain、Agent、Tool、Memory、Callback……我当时觉得，功能多就代表着强大，选它准没错。结果用了两个星期，我崩溃了。一个简单的「调用工具再回答」的流程，我要理解好几个抽象类之间的关系。出了 bug，错误栈里全是框架自己的代码。我明明只是想调用一个搜索 API，却感觉自己在研究一套操作系统。
后来我换成了 Agno（原 Phidata），一个自称「轻量级」的 Agent 框架。一开始我不以为然——不就是功能少吗？但用完之后我才意识到：它砍掉的不只是功能，而是我理解这个框架所需的脑细胞。它的 GitHub 首页上写着：
Agno is a lightweight library for building Multimodal Agents. It is open-source and designed for simplicity, speed, and control.
这句话翻译过来就是：少点魔法，多点掌控。这个设计哲学，正是我后来想明白的答案。
Agno 的核心：一个 Agent 类，一个循环
Agno 的设计极简到什么程度？你创建一个 Agent，给它配上模型、工具，然后运行。代码长这样：
from agno.agent import Agent
from agno.tools.duckduckgo import DuckDuckGoTools
agent = Agent(
name='Web Search Agent',
model='openai:gpt-4o',
tools=[DuckDuckGoTools()],
show_tool_calls=True,
)
agent.print_response('What is the latest news?', stream=True)就这些。没有 Chain，没有复杂的记忆模块，没有一堆 Callback。Agent 就是一个对象，run 就是一个方法。你可能会问：那工具调用、多轮对话、记忆呢？Agno 把这些都内置在 Agent 的循环里，你不需要自己拼装。
这个循环的本质是什么？其实就是：模型看到输入，决定要不要调用工具；如果要，框架执行工具，把结果塞回对话；模型再决定下一步，直到它觉得可以回答了。这个循环是 Agent 的通用底层模式，Agno 只是把这个模式直接做成了默认行为。在 官方文档 中，这个循环被描述为「Agentic Loop」，你可以用很短的代码验证它的每一步。
为什么堆功能会成为问题？
你可能会说：功能多不好吗？多总比少强啊。但在软件工程里，有一个很朴素的道理：每多一个抽象，就多一层误解和出错的可能。
拿 LangChain 来说，它的早期版本有 100 多个抽象类。你想搞明白一个 Agent 是怎么工作的，得读好几层代码。而且它为了兼容各种模型，每个模型接口还要写适配层。一旦模型行为有差异，这些适配层就会产生微妙的问题。
我知道有个朋友，用 LangChain 跑一个简单的 RAG 应用，结果发现某个版本的 callback 机制改动导致所有追踪失效，他花了一晚上排查，最后发现是框架版本升级的坑。这几乎是重型框架的宿命——功能越多，维护成本越高。
| 对比维度 | Agno | 典型重型框架（如 LangChain） |
|---|---|---|
| 核心抽象数量 | 少数几个（Agent/Model/Tool/Memory） | 上百个（Chain/Agent/Runnable/Message…） |
| 理解成本 | 低，几十分钟能看懂源码 | 高，需要阅读大量文档 |
| 调试体验 | 栈清晰，框架代码少 | 经常要钻进框架内部 |
| 功能覆盖 | 聚焦核心 Agent 能力 | 全栈，集成丰富 |
| 可控性 | 高，可以轻易修改行为 | 低，容易受框架约定约束 |
这张表不是想说 Agno 秒杀一切，而是想说：当你最需要的是可控性时，极简主义往往比功能堆砌更有价值。
极简主义是怎么做到的？
有人可能觉得，轻量级框架是不是靠牺牲功能换来的？不是。Agno 支持多模态、工具调用、知识库（RAG）、结构化输出、流式响应，甚至还能跑在本地模型上。它只是把这些功能的实现方式压缩到最少。
它的核心实现其实不复杂。Agent 类的内部有一个循环，大致是：
- 把用户输入和对话历史一起传给模型。
- 模型返回响应，如果里面有工具调用指令，就解析出来。
- 框架执行对应的工具函数，得到结果。
- 把工具结果作为新消息继续传给模型。
- 重复 2-4，直到模型不再请求工具，给出最终回答。
这个循环用 Python 写也就几十行。Agno 的聪明之处在于，它把这个循环封装成一个类，然后允许你通过参数调整模型、工具、记忆等，而不是用一堆继承和组合来搭建。
我自己写过一个 Agent 来调用股票 API。在 LangChain 里，我要定义 Tool 类、绑定模型、设置 AgentExecutor……在 Agno 里，我只需要写一个 Python 函数，然后用 @tool 装饰器注册它，再传给 Agent。没了。这种「少就是多」的感觉，真的很爽。
什么时候极简主义会翻车？
我不是在说所有项目都该用 Agno。极简主义也有它的代价。比如：
- 如果你需要跟几十种外部系统开箱即用的集成，Agno 的生态可能不如重型框架。
- 如果你需要复杂的、预定义的多 Agent 协作流程（比如计划-执行-反思），Agno 给了你基础组件，但不会帮你编排好。
- 如果你的团队已经熟悉 LangChain，切换成本可能大于收益。
但即便如此，我依然认为，极简主义的方向是对的。因为复杂流程本来就该由你自己掌控，而不是靠框架的「魔法」替你决定。Agno 至少把这些决策权还给了你。
关于极简主义的三个常见误解
Agno 是不是只是个玩具？
不是。它支持多模态、工具调用、RAG、流式输出，还能跟 OpenAI、Anthropic、本地 Ollama 等模型对接。很多生产项目已经用它跑了。
极简主义会不会导致我什么都要自己写？
Agno 把 Agent 的基础循环封装好了，你只需要写工具函数和模型配置。对于 80% 的 Agent 场景，这些就够了。剩下的 20% 需要你写一点自定义逻辑，但那是你该掌控的。
LangChain 那么多功能，难道都没用？
当然有用。如果你需要的是开箱即用的全套集成，比如几十种文档加载器、向量数据库、回调系统，LangChain 的生态确实强。但代价是你得忍受它的复杂度。关键看你的项目是「要快」还是「要可控」。
最后说点我的判断
Agno 的轻量级设计不是「功能阉割」，而是「克制的设计」。它适合那些想真正理解 Agent 工作原理的开发者，也适合对生产环境可调试性有要求的团队。它的边界在于：它不是一个一站式全栈平台，而是一个让你可以自由扩展的「毛坯房」。
如果你厌倦了在框架的抽象海洋里游泳，不妨试试这种极简的体验。你可能会像我一样，突然明白为什么有人选择少一点，而不是多一点。
原创文章，作者：guanweilu，如若转载，请注明出处：https://guanweilu.cn/article/310.html