跳到主要内容

开源 AI Agent 框架

高级

当你亲手搭过几个 agent 之后，同样的管道逻辑会反复出现：一个循环调用模型、运行模型要求的工具、把结果喂回去，并在任务完成时停止。Agent 框架把这套管道封装起来——外加状态、记忆和多 agent 协调——让你少写胶水代码。本页是一份持久、中立于厂商的地图，梳理主要的开源选项、它们实际提供什么，以及如何选择。它们几乎全都是模型无关的：既能配合 Claude、GPT、Gemini，也能配合本地开放权重模型。

What you'll learn
  • 了解 agent 框架相比手写循环给了你什么——以及没给什么
  • 认识三种原型：有状态图、基于角色的团队，以及极简循环
  • 使用一套可复用的流程来选择其一——用复杂度换取控制力
  • 记住这些大多是模型无关的——框架很少把你锁定在某一个厂商上

agent 框架实际给了你什么​

抛开品牌包装，一个框架无非是在向你提供四样东西中的某个子集：

  • 编排（Orchestration）——控制循环。顺序步骤、分支、重试、循环到完成，以及（越来越常见的）能在崩溃后存活并从中断处恢复的持久执行。
  • 工具（Tools）——一套标准方式来声明模型可调用的函数、校验其参数、运行它并返回结果。就是你在 工具使用 中已经熟悉的那套「描述→调用→执行→返回」循环。
  • 记忆与状态（Memory & state）——一个跨轮次保存对话历史、草稿事实和检索到的文档的地方，让 agent 在各步骤之间不会失忆。
  • 多 agent（Multi-agent）——让多个专门化 agent 相互交接工作的模式：一个主管把任务委派给工人，或者对等 agent 协作完成一项任务。（在概念上和 Claude Code 的 子 agent 是同一个思路。）

当你原本得亲手编写并维护这全部四样东西时，框架才值得用。而当你的任务是「调用模型、跑一两个工具、返回一个答案」时，它不值得——在那里，框架只是你要花时间与之搏斗的额外开销。

三种原型​

框架之间的差别比它们的营销话术所暗示的要小。真正只有三种形态，大多数项目都是其中之一的变体：

  • **有状态图 / 工作流（Stateful graph / workflow）。**你把 agent 建模为一张由节点和边（或步骤和转移）构成的显式图。控制力最大、状态可检查，适合长时运行和人在回路的流程。前期要学的东西更多。→ LangGraph、LlamaIndex Workflows。
  • **基于角色的团队（Role-based crew）。**你按角色（「研究员」「写手」「审稿人」）描述 agent，让它们协作或跑一段流程。表达一个多 agent 团队很快；你用一些细粒度控制换取了高层抽象。→ CrewAI，以及 AutoGen 那种对话式多 agent 风格。
  • 极简循环 / 少抽象（Minimal loop / few abstractions）。在模型原生工具调用之上薄薄一层，包含几个 agent 之间的交接，别的不多。从头到尾都好读、好丢弃。→ OpenAI Agents SDK（实验性项目 Swarm 的生产级继任者），以及你自己写的朴素循环。
Pro tip
  • 从能用的最简单方案开始——朴素的工具调用循环往往胜过一个笨重的框架。

快速巡览（下注前请核实定位）​

以下是值得了解的开源项目。之所以点名，是因为每个项目真实的仓库都经过核实；一切易变的信息都藏在上面的 VerifyNote 背后。

  • LangGraph——一个面向有状态、长时运行 agent 的低层编排框架，把 agent 建模为图；持久执行和人在回路是一等公民。既可独立使用，也可与更广的 LangChain 生态一起用。模型无关。
  • LlamaIndex——起初是一个数据/RAG 框架（连接器、索引、检索），如今也提供了一个事件驱动的 Workflows 层给 agent 用。当你的 agent 本质上是在你的文档之上做检索时，它很强。
  • Microsoft AutoGen——一个面向对话式多 agent 系统的框架。截至 2026 年年中，它处于维护模式；微软把新项目导向一个统一的继任者（Microsoft Agent Framework，合并了 AutoGen + Semantic Kernel）。开工前请查看当前状态。
  • CrewAI——一个基于角色的框架：按角色和目标定义 agent，把它们组织成 Crews（自主协作）或 Flows（事件驱动的控制）。是搭出一个多 agent 团队的快捷路径。
  • OpenAI Agents SDK——一个刻意保持轻量、少抽象的框架，面向带交接的多 agent 工作流。尽管名字如此，它其实是厂商无关的（其文档指出支持 100+ 种 LLM），并且是实验性项目 Swarm 的生产级继任者。
  • 朴素的 agent 循环——完全没有框架：你自己围绕模型原生工具调用写的 while 循环。对简单 agent 而言这是正确的默认选择，也正是上面每个框架归根结底所包装的东西。

如何选一个框架​

Guided walkthrough1 of 6
  1. 用一句话说明 agent 做什么，外加那些不可谈判的条件：延迟、成本上限、数据隐私、运行是否必须在崩溃后存活，以及是否必须有人来批准某些步骤。

每个框架都在包装的那个东西​

在伸手去拿任何库之前，先看看它们全都构建于其上的那个循环会很有帮助。这就是全部思路——模型决策，你执行，重复直到完成：

# Provider-neutral agent loop — the core every framework wraps.
# `model_call` and `run_tool` are yours; swap in Claude, GPT, Gemini, or a local model.

def agent_loop(task, tools, max_steps=10):
    messages = [{"role": "user", "content": task}]

    for _ in range(max_steps):
        # 1. Ask the model what to do next (it sees the tool schemas).
        response = model_call(messages, tools=tools)

        # 2. No tool requested → the model is done. Return its answer.
        if not response.tool_calls:
            return response.text

        # 3. Run each requested tool and feed results back in.
        messages.append(response.as_message())
        for call in response.tool_calls:
            result = run_tool(call.name, call.arguments)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result,
            })

    return "Stopped: hit max_steps without finishing."

如果你能读懂这段，你就理解了本页每个框架在底层做的事。图为其加上显式状态和分支；团队为其加上角色和委派；极简 SDK 为其加上整洁的交接——但那个心跳始终是这个循环。

极简 agent 系统提示词（与上面的循环搭配）

You are a task-completing agent with access to tools.

Loop:
1. Think briefly about the next single step toward the goal.
2. If a tool would help, call exactly ONE tool with valid arguments.
3. When you have enough to answer, stop calling tools and give the final answer.

Rules:
- Prefer the fewest tool calls that get the job done.
- If a tool fails, read the error and adjust — do not repeat the same call.
- Never invent tool results; use only what tools actually returned.
- If the goal is impossible with the available tools, say so and stop.

Goal: {one-sentence task}

关于炒作的一点说明​

这里没有哪个框架是「最好的」——这个问题本身就是错的。图框架赢在控制力和持久性；团队框架赢在快速表达一支团队；极简框架赢在可读性和低锁定；而朴素循环获胜的频率，比框架的 README 所承认的要高。正确的选择，是那个能让你自己最难的一步变清晰的最小工具。就像挑模型一样，让你自己的任务——而不是 star 数——来决定。你在 评估 上会用的那套纪律，在这里同样适用：做原型、在真实用例上测量、留一条撤离通道。

自我检查

0/3
  1. 你的 agent 做一次模型调用、运行单个搜索工具，然后返回一个答案。正确的起点是什么？
  2. 你需要一个长时运行、必须在崩溃后存活并恢复、并让人来批准某些步骤的 agent。哪种原型最合适？
  3. 一位同事说「OpenAI Agents SDK 意味着我们被锁死在 GPT 上」。这对吗？
Agent 框架——核心思想
按 Enter 或空格键翻转卡片。使用左右方向键在卡片之间切换。已显示术语。
1 / 6
Key takeaways
  • agent 框架把编排、工具、记忆和多 agent 协调打包起来——只有当你原本得自己构建这全部四样时才采用它。
  • 三种原型覆盖了整个领域：有状态图（控制/持久性）、基于角色的团队（快速团队）、极简循环（可读性、低锁定）。
  • 这些几乎全都是模型无关的——它们跑在 Claude、GPT、Gemini 和本地模型上；请按项目逐个核实，而不是假设。
  • 没有哪个框架是普遍「最好」的；选那个能让「你」最难的一步变清晰的最小工具，并留一条撤离通道。
  • 朴素的工具调用循环是诚实的默认选择——而它正是每个框架所包装的东西。
  • 维护状态会变（例如 AutoGen → 一个继任者）；在下注前，先到项目自己的仓库确认它仍在积极维护。

来源与延伸阅读​

下一步​