Agent 循环本身 — 搭 loop + 编多个 agent
这条分支在货架里的位置: 总纲把这 195 个库的共性讲成一句话——「把一个只会吐文本的 LLM,包成能在循环里感知-动作、能被放心运营的程序」。围绕这条共性分出几条分支,本章是分支 A「循环本身」:别的分支把「动作」换成改代码 / 控浏览器 / 查文档,而这一支往回退一步,问**「那个循环怎么搭出来」——统一接各家模型、定义工具、跑「想→调工具→看结果→再想」、挂记忆;再往上把多个这样的循环编成一支团队**,或者给它一个目标全自动跑。它是所有别的分支下面的地基:任何一个 coding agent / browser agent,拆开壳子最里面都是这一层。
30 秒导读: 这一档库都在补 LLM 缺的第一样东西——循环。一个裸模型只能「给一段文本→回一段文本」,它不会自己调工具、不会记住上一轮、更不会跑很多轮直到把活干完。这一支的库分三层:① 单体循环层——把「接模型 + 定义工具 + 跑 reason-act-observe + 挂记忆」这四件事做成一个可复用的引擎(framework/SDK);② 多 agent 编排层——把多个单体循环按角色 / 协议 / SOP 编成一个团队,让它们分工、传消息、汇总;③ 自治层——给一个高层目标,让系统自己把它拆成子任务、自己调度、自己判断做完没有。本章把这三层横过来切,讲清每层对准哪个环节、代表库怎么做。
怎么读本章: 正文是给人读的白话综述,不出现路径行号。每个论断后面挂一个脚注
[^x],精确的仓库/路径:行+ 符号名都在脚注里;对比矩阵则单开一列「代码锚点」放引用。人读正文,agent 读脚注 / 锚点列。
1. 这条分支要解决什么(第一性原理)
承上:整个货架的共性是「给只会说话的 LLM 装手脚,让它能在循环里对世界采取动作」。别的分支默认「循环已经有了」,只关心那个动作是什么(改代码 / 点浏览器 / 查文档)。本分支专门盯着「循环本身」——它是所有别的分支下面那层看不见的地基。
一个裸 LLM 的能力边界是残酷的:给它一段文本,它回一段文本,仅此而已。它做不到四件事,而这四件恰好是「agent」这个词的全部含义:
| 裸模型缺什么 | 白话 | 为什么非补不可 |
|---|---|---|
| 统一的模型接口 | 换个模型就得改一遍调用代码 | OpenAI / Anthropic / 本地模型的消息格式、工具格式全不一样 |
| 工具的定义与调用 | 模型说「我要查天气」,谁去查、结果怎么塞回去? | 模型只会说要调工具,不会真的调,更不会接住返回值 |
| 循环控制 | 一轮不够,得「想→调→看→再想」很多轮 | 复杂任务要多步;何时停、错了怎么办,得有代码兜 |
| 记忆 | 下一轮怎么知道上一轮干了啥? | 模型无状态,历史 / 中间结果得程序自己攒着喂回去 |
补齐这四件,就得到一个单体 agent 循环。这是第一层。但一个循环常常不够——一个复杂任务(比如「做一个软件」)需要多个角色分工(产品、架构、工程、测试),于是有了第二层:把多个单体循环编成一支团队。再进一步,如果连「怎么分工、分几步」都不想手写, 而是丢一个目标让系统自己拆解、自己调度,那就是第三层:自治。
一句话直觉: 这一支是由内向外的三个同心圆——最里面是「一个 LLM + 一圈脚手架 = 一个会干活的循环」,中间是「多个循环 + 一套协作协议 = 一支团队」,最外面是「一个目标 + 自拆自调 = 自治系统」。越往外,交给 LLM 自主决定的东西越多,兜底的确定性脚手架就越吃紧。
据此,本章把这一支分成三层来讲:§2 单体循环层(framework / SDK)、§3 多 agent 编排层、§4 自治层。§5 是对比矩阵,§6–§8 是权衡、趋势与代表作。
2. 第一层:单体 agent 循环(framework / SDK)
这一层的库都在干同一件事——把「接模型 + 工具 + 循环 + 记忆」做成一个可复用引擎,让你写几行就得到一个会干活的 agent。它们的分化不在「干不干这四件」,而在用什么抽象去组织这个循环。三个流派。
怎么读这张图: 从左到右是「循环的形状被写死的程度」——左边把循环固定成经典 ReAct、你只填工具;右边把循环拆成可任意拼的积木,连「什么时候调模型」都由你摆。
循环形状写死 ───────────────────────────────► 循环形状自由拼装
你只管填工具 你摆每一块积木
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ ① ReAct 引擎 │──►│ ② 声明式约束 │──►│ ③ 图 / 状态机 │
│ 想→调→看 │ │ 规则/校验 │ │ 节点+连线自由拼 │
│ 内建循环 │ │ 门控每一步 │ │ 循环=图里的环 │
└──────────────┘ └──────────────┘ └──────────────────┘
strands/camel beeai/upsonic pocketflow/burr/koog
2.1 ReAct 引擎:把「想→调→看」焊死成内建循环
最主流的做法:框架内建一个 reason → act → observe 的循环,你只需要提供工具和一个目标,循环体由框架跑。这是「agent framework」这个词最朴素的形态。
- strands-agents:核心就是一个
event_loop_cycle事件循环——调模型、若有 tool_use 就执行、把结果塞回历史、再进下一轮,直到模型不再要工具。1 它把「循环 + 重试 + max-tokens 恢复」都收进这一个引擎。 - camel:
ChatAgent是一个 6000+ 行的单体,step()里跑「模型→工具→再模型」并用max_iteration封顶;它还专门做了模型归一化——BaseMessage.to_openai_message把 40+ 家后端的消息格式统一成一套。2 这正好覆盖了 §1 表里的「统一接口 + 工具 + 循环」三件。 - atomic-agents:走「schema 驱动」的极简 ReAct——每个 agent 的输入 / 输出都是一个带 docstring 的 Pydantic schema,
run()是同步 / 异步 / 流式三个入口,历史由ChatHistory管。3 - goose / genkit / voltagent / marvin / composio:同属这 一类——给你一个内建循环 + 工具注册 + provider 适配。goose 的
Agent在 Rust 里跑一个loop,靠 MCP 作为唯一的工具扩展机制;4 composio 则专攻这一层里最脏的一环——给循环喂 1000+ 现成工具,tools.get/tools.execute管拉取和执行,provider 适配器区分 agentic / 非 agentic 两种接法。5
2.2 声明式约束:给循环的每一步套规则
新一代的关注点从「能不能循环」转到「循环别跑飞」。做法是:不让模型在每一步自由发挥,而是用声明式的规则 / 校验门控——这一步允许调哪些工具、必须先满足什么条件、输出得过哪些验证。
- beeai-framework:
RequirementAgent把「规则」做成一等公民——每个Requirement在每次迭代产出一组Rule(禁用 / 强制 / 只在第 N 步),RequirementsReasoner按优先级聚合、遇冲突「forbidden wins」,还内建死循环检测。6 代价是每轮都要重算规则、重渲染系统提示。 - upsonic:主打「可靠」——给循环挂上任务校验和缓存,让 agent 的产出先过一遍验证再算数。[^upsonic-validate]
- koog:JVM(Kotlin)阵营的代表,主打容错——把 agent 循环建成可组合的策略图,内建重试 / 回退,面向生产。7
2.3 图 / 状态机:把循环拆成可自由拼的积木
最灵活的一类:不预设循环形状,而给你「节点 + 连线」或「状态 + 转移」两种原语,循环只是图里的一个环,你想怎么拼就怎么拼。适合分支、并行、人在环上这些非线性流程。
- pocketflow:极致的极简主义——整个框架 99 行。核心是
BaseNode的prep → exec → post三段生命周期 + 内建重试(exec_fallback),Flow靠post的返回值当「action 字符串」决定下一个节点,循环就是图里指回自己的一条边。8 「用最小内核表达一切」的教科书。 - burr:把 agent 显式建成状态机——
State是不可变容器,Action拆成 Function(读)+ Reducer(写),Graph定义转移;application.py的_step()是执行引擎,配reads/writes三级校验和持久化 / fork-resume。9 - fast-agent:MCP-native 的图式框架,把 agent、workflow、评估都建在 MCP 之上,强调可组合和可评测。10
对照: ReAct 引擎(§2.1)上手最快但循环形状被写死;图 / 状态机(§2.3)最灵活但要自己画流程;声明式约束(§2.2)夹在中间——循环还是内建的,但每一步都能被规则收住。三者其实是同一个循环的三种「暴露面」。
3. 第二层:多 agent 编排(把多个循环编成团队)
一个循环不够时,把多个单体循环(§2 的产物)编成一支能分工协作的团队。这一层的分化,全在**「谁决定下一步该谁上、信息怎么在成员间流动」**。三个流派。
怎么读这张图: 从左到右是「协作结构被写死的程度」——左边按预先排好的角色 / SOP 顺序走,右边由一个协调者在运行时动态决定谁接手。
结构预先排好 ──────────────────────────────► 运行时动态决定
按角色/SOP 顺序 协调者临场调度
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ ① 角色+SOP │──►│ ② 图/DAG 编排 │──►│ ③ 协调者-工人 │
│ 流水线 │ │ 节点连线 │ │ 动态派活 │
│ PM→架构→工程 │ │ 拓扑执行 │ │ coordinator │
└──────────────┘ └──────────────┘ └──────────────────┘
metagpt/chatdev agentverse/chatdev camel/agency-swarm
3.1 角色 + SOP:把人类团队的流程搬进来
最有辨识度的一支:给每个 agent 一个角色(产品经理 / 架构师 / 工程师 / 测试),再用一套**标准作业流程(SOP)**把他们串成流水线——上一个角色的产物是下一个角色的输入。
- metagpt:标杆实现。每个
Role是一个带_think/_act/_observe的循环,RoleReactMode决定它是 ReAct、按序、还是先规划后执行;成员之间不直接对话,而是靠Environment.publish_message发布 / 订阅消息(每个角色_observe自己关心的);顶层Team用hire招人、invest设预算、run跑 N 轮。11 「一句话生成一个软件」就是这套 SOP 流水线跑出来的。 - chatdev:把公司搬成一张工作流图——
GraphExecutor按拓扑层执行 CEO→程序员→评审→测试;它有个巧妙的loop_counter,在计数没到上限时返回空边来压制下游,于是不用图里真的成环就实现了「反复迭代到达标」的有界循环;边上带carry_data控制上下文是否随边传递。12
3.2 图 / DAG 编排:把协作画成一张可执行的图
不预设「角色流水线」,而给你一张可配置的图 / DAG,节点是 agent、边是信息流,由引擎按拓扑执行。比 §3.1 更通用——协作模式(是流水线还是辩论)由图的形状决定,而非写死。
- agentverse:一个
Registry+ YAML 就能把组件拼成环境;它内建四种decision_maker(纵向 / 横向 / 中心化 / 头脑风暴),同一个「协作解题」目标能换四种拓扑;BasicEnvironment.step()跑一个五段 Rule 引擎(排序→描述→LLM→选择→更新)。13 - open-multi-agent:主打「目标优先」——你描述一个目标,一个协调者把它分解成运行时的任务 DAG,再派给各 agent 执行。14 这条也是通往 §4 自治层的桥。
- microsoft-agent-framework:微软把 AutoGen 的经验收编进来,主打 Python + .NET 双栈的多 agent workflow 编排。15
3.3 协调者-工人:一个 manager 在运行时派活
最动态的一支:设一个协调者(coordinator / manager),由它在运行时看着任务状态,决定拆成哪些子任务、每个派给哪个工人 agent、失败了怎么重派。结构不预先固定,而是临场生成。
- camel:除了单体
ChatAgent(§2.1),它还有Workforce——一个协调者-工人管线:协调者做任务分解、找 assignee、LLM 驱动的失败恢复,工人并发跑。16 注意它有个隔离边界:share_memory只覆盖SingleAgentWorker,嵌套 workforce 不共享记忆。 - agency-swarm:把「谁能给谁派活」显式声明成通信流,
send_message工具是同步串行的委派——一个 manager 一轮内没法同时问两个专家(被去重锁挡住),要多轮。17 - swarms / praisonai / openmanus / agentscope:都提供多种协作拓扑。agentscope 特别之处是把单体循环也做成状态机——
_check_next_action在运行时判定下一步是 reasoning / acting / exit,天然支持暂停 / 恢复,再往上 叠多 agent 消息传递。18
对照: 角色 + SOP(§3.1)最像人类公司、可解释但死板;协调者-工人(§3.3)最灵活、能临场应变但更难预测;图 / DAG(§3.2)夹在中间——结构可配但仍是静态的。三者的共同暗线是**「消息怎么在成员间流动」**:metagpt 用环境发布 / 订阅,agency-swarm 用 send_message 工具,agentverse 用 Rule 引擎的 selector——通信机制才是多 agent 系统真正的骨架。
4. 第三层:自治(给目标,让它自拆自跑)
最外圈:不再手写「分几步、谁做什么」,而是丢一个高层目标,让系统自己把它拆成子任务、自己调度执行、自己判断做完没有。这一层与 §3 的界线是——§3 的结构由开发者摆(角色 / 图 / 协调者规则),§4 的结构由系统运行时自己生成。分化在「自主到什么程度」。
怎么读这张图: 从左到右是自主性递增——左边只自动拆任务、执行仍受控;右边连自己的工具 / 技能都能自己写、自己进化。
只自拆任务 ────────────────────────────────► 连能力都自我进化
执行受控 自写工具/自学技能
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ ① 任务循环 │──►│ ② 生成式平台 │──►│ ③ 自进化 │
│ 拆→做→回填 │ │ block/工具 │ │ 自写函数/自学技能 │
│ 目标驱动 │ │ 持续运行 │ │ 修复+复用 │
└──────────────┘ └──────────────┘ └──────────────────┘
agenticseek autogpt/suna/hermes babyagi/evoagentx/openspace
4.1 目标驱动的任务循环:自拆、自调、自回填
经典自治形态:给目标 → LLM 生成一个任务计划 → 逐个执行 → 结果回填、动态重排。
- agenticseek:一个
router先用双分类器(BART + LLM)投票选 agent、估复杂度;planner_agent让 LLM 吐一个 JSON 计划(带依赖),再逐任务派给对应 agent,失败可动态重规划。19 注意它为兼容本地小模型,工具调用走的是 Markdown 代码块(python /web_search)而非函数调用 JSON——牺牲标准换本地可用。
4.2 生成式平台:持续运行的自治 agent 产品
把自治做成一个能长期运行、能落地成产品的平台——通常带可视化搭建、工具生态、长时任务管理。
- autogpt:如今是一个可视化 block 平台——每个
Block是一个带输入 / 输出 schema 的能力单元(async def run),ExecutionManager用「就绪驱动」的调度把 block 按图执行、输出回填下游。20 它把「自治 agent」重构成了「可编排的 block 图」。 - suna:开源的通用型 agent runtime(Manus 风格)——带工具、浏览器、可直接部署成 app,给一个目标就能跑一套完整任务。21
- hermes-agent:自我改进的个人自治 agent——持久记忆 + 40 多种工具 + 消息渠道集成,主打长期陪跑。22
4.3 自进化:连自己的能力都能自己造
最激进的一档:不只自拆任务,还能自己写工具 / 自己学技能 / 自己修复自己,能力随运行不断增长。
- babyagi(现版本):已从 2023 年那个经典任务循环转成一个自建 agent 框架——
break_down_task把目标拆开、create_function让 LLM 写出新函数并存进函数库供后续复用。23 注意它用裸exec()跑生成代码、无沙箱,作者明说非生产。 - evoagentx:让 agentic 工作流自我进化——用 MCTS / 梯度式优化去 改 prompt 和 workflow 结构,让整条流水线越跑越好。24
- openspace:一个自进化技能层,套在现有 agent 之上,让它们自主学习、修复、共享可复用技能。25
对照: 任务循环(§4.1)自主性最低、最可控;自进化(§4.3)自主性最高但也最危险——
exec()无沙箱、自写代码是这一档的通病。生成式平台(§4.2)是当下最有产品落地的一支。这条分支的共同暗线是**「自主性和可控性此消彼长」**:越让系统自己决定,兜底的确定性脚手架(沙箱、预算、校验)就越是安全的唯一防线——这也直接呼应总纲「把 LLM 包成可信程序」的底线。
5. 对比矩阵(逐格接地)
维度:所在层(§2 单体 / §3 多 agent / §4 自治)、核心抽象、循环 / 协作机制、模型 & 工具接法、语言。描述列写白话,精确
path:line+符号 全在最右「代码锚点」列。—表示该维度对此库不突出。
| 库 (id) | 层 | 核心抽象 | 循环 / 协作机制 | 语言 | 代码锚点 |
|---|---|---|---|---|---|
| strands-agents | 单体 | 事件循环引擎 | event_loop_cycle:调模型→跑工具→回填→再来 | Python/TS | strands-py/.../event_loop/event_loop.py:182;agent/agent.py:138 |
| camel | 单体(+多) | ChatAgent 单体 + Workforce | step()+max_iteration;协调者-工人管线 | Python | camel/agents/chat_agent.py:505;societies/workforce/workforce.py:176;messages/base.py:431 |
| atomic-agents | 单体 | schema 驱动的原子 agent | run() 同步/异步/流式,历史管理 | Python | atomic_agents/agents/atomic_agent.py;base/base_io_schema.py |
| goose | 单体 | Rust Agent + MCP 扩展 | 内建 loop {};MCP 为唯一工具机制 | Rust | crates/goose/src/agents/agent.rs:237/:301/:1522 |
| composio | 单体(工具层) | 工具 / 认证适配层 | tools.get/tools.execute + provider 适配 | TypeScript | ts/packages/core/src/models/Tools.ts;provider/BaseProvider.ts |
| genkit | 单体 | Google AI app 框架 | 内建 flow / 工具 / provider(JS/Go/Py) | TypeScript | samples/(README) |
| voltagent | 单体 | TS 框架 + 可观测控制台 | 内建循环 + 工程 / 监控 console | TypeScript | packages/(README) |
| marvin | 单体 | 结构化输出 / ambient | agentic workflow + 结构化输出 | Python | src/(README) |
| beeai-framework | 单体(约束) | RequirementAgent + 规则 | 每轮规则门控 + 死循环检测 | Python/TS | python/.../agents/requirement/_runner.py;.../requirements/ |
| upsonic | 单体(约束) | 任务校验 + 缓存 | 产出先过校验再算数 | Python | src/(README:task validation) |
| koog | 单体(约束) | JVM 容错 agent | 策略图 + 重试 / 回退 | Kotlin | agents/(README:fault-tolerant) |
| pocketflow | 单体(图) | 99 行 Node/Flow | prep→exec→post,post 返回值选下一节点 | Python | pocketflow/__init__.py:3/:9/:39/:50 |
| burr | 单体(状态机) | State+Action+Graph | _step() 状态转移 + reads/writes 校验 | Python | burr/core/application.py;core/persistence.py |
| fast-agent | 单体(图) | MCP-native 组合 | agent/workflow/eval 建在 MCP 上 | Python | src/(README:MCP-native) |
| metagpt | 多 agent | 角色 + SOP 流水线 | Role._think/_act;环境发布/订阅;Team | Python | metagpt/roles/role.py:125/:340/:454;environment/base_env.py:175;team.py:32/:83 |
| chatdev | 多 agent | 软件公司工作流图 | GraphExecutor 拓扑执行 + loop_counter 有界循环 | Python | workflow/graph.py:53/:126/:261;entity/configs/node/node.py:38/:63 |
| agentverse | 多 agent | Registry + 环境 Rule 引擎 | 四种 decision_maker;五段 step() | JavaScript | agentverse/registry.py;environments/simulation_env/basic.py |
| open-multi-agent | 多 agent | 目标→任务 DAG | 协调者分解目标成运行时 DAG | TypeScript | packages/(README:goal-first DAG) |
| microsoft-agent-framework | 多 agent | Python+.NET workflow | 多 agent workflow 编排(AutoGen 后继) | Python | python/(README) |
| agency-swarm | 多 agent | 角色 agency + 通信流 | send_message 同步串行委派 + 去重锁 | Python | src/agency_swarm/agency/core.py;tools/send_message.py |
| agentscope | 多 agent | 状态机 agent + 消息传递 | _check_next_action reasoning/acting/exit | Python | src/agentscope/agent/_agent.py:2297/:728/:1574 |
| swarms | 多 agent | 多种 swarm 拓扑 | 企业向 swarm 编排 | Python | examples/(README) |
| praisonai | 多 agent | 自反思 + 记忆 + RAG | 多 agent + self-reflection(Py/JS) | Python | src/(README) |
| openmanus | 多 agent | 通用 agent 多 agent flow | Manus 替代,MCP + 多 agent flow | Python | app/(README) |
| agenticseek | 自治 | router + planner | 双分类器选 agent;JSON 计划 + 重规划 | Python | sources/router.py:370/:441;agents/planner_agent.py:75 |
| autogpt | 自治 | 可视化 block 平台 | Block.run + 就绪驱动 ExecutionManager | Python | backend/blocks/_base.py:550/:654;executor/manager.py:389 |
| suna | 自治 | 通用 agent runtime | 目标驱动 + 工具 / 浏览器 / 可部署 | TypeScript | apps/(README:generalist runtime) |
| hermes-agent | 自治 | 个人自我改进 agent | 持久记忆 + 40+ 工具长期陪跑 | Python | apps/(README:self-improving) |
| babyagi | 自治(自进化) | 自建函数库 | break_down_task+create_function 自写函数 | Python | functionz/packs/drafts/code_writing_functions.py:77/:345 |
| evoagentx | 自治(自进化) | 工作流自进化 | MCTS / 梯度式优化 prompt+workflow | Python | examples/(README:self-evolve) |
| openspace | 自治(自进化) | 自进化技能层 | 套在现有 agent 上自学 / 修复 / 共享技能 | Python | README.md(self-evolving skills) |
矩阵里反复出现的「家族」:FoundationAgents 系(metagpt / openmanus 同源思路)、OpenBMB 系(chatdev / agentverse)。长尾库不必逐一拆解——它们在「循环 / 协作 / 自治」上往往落进上面某个已接地的格子。README-only 顶的格子(genkit/voltagent/marvin/…)标了
(README),是待写子库 doc 时优先补的锚点。
6. 模式与权衡(可带走的领域智慧)
读完矩阵,几条横跨全分支的规律浮出来:
-
四件苦工是不变量,变的是「谁来做」。 §1 那四件(统一接口 / 工具 / 循环 / 记忆)每个库都得做,区别只在藏在哪:strands 把循环藏进
event_loop_cycle,camel 把模型归一化藏进BaseMessage,composio 干脆把「工具」这一件单独抽成一个层卖。认出这四件,再复杂的框架都能一眼拆开。 -
「循环形状写死 vs 自由拼装」是第一层的核心取舍。 ReAct 引擎(strands/camel)最快上手但形状固定;图 / 状态机(pocketflow/burr)最灵活但要自己画。没有免费的午餐——灵活性和上手成本永远反向。
-
多 agent 的骨架是「通信」,不是「角色」。 角色好起名,难的是消息怎么流:metagpt 用环境发布 / 订阅、agency-swarm 用 send_message 工具、agentverse 用 Rule selector。谁的通信机制清晰,谁的团队才不乱。 agency-swarm 的「同步串行、一轮只能问一个专家」就是通信机制直接决定了能力上限的例子。
-
自主性和可控性此消彼长,沙箱是最后防线。 越往自治层走,交给 LLM 决定的越多,能出的岔子越大——babyagi / agenticseek 的裸
exec()无沙箱正是这条线绷断的地方。自治系统的工程价值,一大半在那圈兜底的确定性脚手架(沙箱 / 预算 / 校验)。 -
状态机是贯穿三层的隐形主线。 burr 把单体 agent 显式建成状态机,agentscope 用
_check_next_action把「下一步 reasoning 还是 acting」做成状态转移,metagpt 的RoleReactMode也是。把 agent 当状态机看,pause/resume、错误恢复、多 agent 调度就都统一了。 -
层与层是同心圆,不是三个孤岛。 一个多 agent 系统(§3)的每个成员,内部就是一个单体循环(§2);一个自治系统(§4)拆出的子任务,常常就派给一支多 agent 团队。由内向外读,越外圈越依赖内圈已经把循环做稳。
7. 演化趋势(这条分支往哪走)
把时间轴拉出来,三条趋势很清楚:
-
手写循环 → 声明式约束 / 图。 早期框架(strands / camel 式 ReAct 引擎)把循环焊死在引擎里;新一代要么用声明式规则收住每一步(beeai 的
Requirement、upsonic 的校验),要么把循环拆成可组合的图 / 状态机(pocketflow / burr / koog)。控制权从「框架内建」交回给「开发者显式表达」。 -
静态编排 → 动态协调 → 自治。 多 agent 从写死的角色流水线(metagpt SOP)→ 可配的图(agentverse)→ 运行时协调者派活(camel Workforce)→ 系统自己拆目标(open-multi-agent、agenticseek)。结构的决定权在从开发者手里一步步移交给运行时。
-
能力固定 → 能力自造。 最前沿的一档(babyagi 自写函数、evoagentx 自进化工作流、openspace 自学技能)让 agent 的工具 / 技能 / 流程本身随运 行增长。容错和能力都在从「确定性代码」长出「模型自己生成」的环节。
三条趋势其实同源:模型越可靠,系统就越敢把「怎么循环、怎么协作、有什么能力」的决定权还给模型——但好的工程仍坚持「沙箱 + 校验 + 预算」这条兜底底线。这也呼应总纲的共性:把 LLM 包成可信程序,关键不在模型多聪明,而在它自主时脚手架兜不兜得住。
8. 代表作 + 深入读哪些
按流派点名代表作,想深入就从这里下钻:
| 想学的东西 | 代表作 | 入口 |
|---|---|---|
| 最小可用的 agent 循环(必修) | strands-agents · camel | event_loop/event_loop.py · agents/chat_agent.py |
| 「一切皆图」的极简内核 | pocketflow | pocketflow/__init__.py(99 行读完) |
| agent 即状态机 + 持久化 | burr | burr/core/application.py |
| 声明式规则门控每一步 | beeai-framework | agents/requirement/_runner.py |
| 模型归一化(接各家后端) | camel | messages/base.py:431 |
| 工具生态 / 认证层 | composio | ts/packages/core/src/models/Tools.ts |
| 角色 + SOP 多 agent 流水线 | metagpt | roles/role.py · team.py |
| 软件公司工作流图 | chatdev | workflow/graph.py |
| 可配 的多拓扑协作 | agentverse | environments/.../decision_maker/ |
| 协调者-工人动态派活 | camel Workforce · agency-swarm | societies/workforce/workforce.py · tools/send_message.py |
| 目标→任务 DAG 自拆 | open-multi-agent · agenticseek | packages/ · agents/planner_agent.py |
| 可视化 block 自治平台 | autogpt | backend/blocks/_base.py |
| 自写函数 / 自进化 | babyagi · evoagentx | packs/drafts/code_writing_functions.py · evoagentx/ |
给入门者的学习路径: 先读 pocketflow(99 行,把「循环 = 图里的环」这个内核一次看穿)→ 再读 strands / camel 的 ReAct 引擎,理解 §1 那四件苦工怎么被收进一个 event_loop_cycle / ChatAgent(camel 还顺带看模型归一化)→ 想要非线性流程就读 burr 的状态机 → 往上一层读 metagpt,看「角色 + SOP + 环境消息」怎么把多个循环编成团队 → 最后读 autogpt / babyagi,理解「给目标自拆自跑」的自治层及其沙箱风险。读完回总纲 index.md,你会发现别的分支(coding / browser / …)只是给这套「循环」换了个具体的动作对象。