一直以来我都有一个问题，为什么我们需要 agent framework，大模型不够用吗？
最近深度使用了几个工具，以及参与几个 agent 项目后，我得到了结论。
LLM 的问题
之所以要有 agent，最大的问题是，llm 本身的局限性。
首先，我认为最大的问题是 context 长度。虽然现在很多模型 context 都变长了很多（GPT-4 Turbo 128K，Claude-3.5 Sonnet 200K，Gemini-1.5 Pro 最高 2M），但是对于真正复杂的任务来说，还是不够长。比如你要处理一个大型代码库，或者分析很多文档，这点 context 还是不够用。而且这些长 context 处理起来费用很高，也很慢。
此外，则是其他能力的问题。
- 对于视觉能力，现在的 VLM 虽然已经很强了，但是在一些特定场景下，传统的 CV 模型还是会更好一些。而且部分模型（如 deepseek-v3）本身就没有视觉能力。
- LLM 本身不能直接访问数据库、文件系统、网络服务等外部资源。
- 一些专门的工具，比如代码执行、数学计算、数据分析等，需要通过 MCP 等协议才能给 LLM 用。
agent 可以做什么
除了上述原因之外，应该还有其他原因，但是我目前没有在实践中遇到。欢迎大家补充。但以上原因足够表明我们需要 agent。下文是几个常见的 agent。
分领域的文本处理
将不同文本块（context）使用不同的 agent 进行处理。
- context 节省：通过 agent，我们可以将部分 context 进行压缩，或者干脆不给 context。这样一来，context 的长度就被节省下来了。
- 性能优势：进而，agent 中的 llm 可以聚焦在某一件具体的事情上，从而获得较好的性能。例如，如果我们将大段的文本给与 LLM，他可能无法找到关键信息。但是如果我们减少给于 LLM 的文本数量，找到关键信息就变得相对容易了。
- LLM 是使用相对通用的文本训练的。因此，如果我们要 agent 掌握领域知识，就需要在 context 中添加这些领域知识。
视觉能力集成
通过 agent，我们可以集成一些传统的视觉模型，来做一些之前视觉上不好做的事情。例如，我们可以通过 mcp 与 agent 配合，增加视觉能力。
常见的是智谱的视觉 MCP。通过使用这个 MCP + Agent，可以增强视觉能力。
我想这也是部分完全整合其他 mcp 服务的 mcp server 存在的意义。
agent 框架
- pydantic ai: 我认为是比较好用的。其优势在于将 pydantic basemodel 引入了 agent 框架，比较容易调试。我测试了其与 qwen3 的集成。
- langchain: 没有在生产环境中使用过。开发环境中简单调试过。其 api 变化比较大。一个小的问题是 prompt 的处理，我使用了 jinja 来解决