Agent Loop 入门到深入：从 ReAct 到 LangGraph、Agents SDK 与 MCP

这两年 “Agent” 这个词被用得很满：聊天机器人叫 agent，工具调用叫 agent，自动写代码叫 agent，多角色协作也叫 agent。真正值得抓住的不是名词，而是背后的循环结构：模型不再只是一次性回答，而是在“观察、思考、行动、再观察”的闭环里逐步推进任务。

这篇文章先用最小模型讲清楚 agent loop 是什么，再结合近期全网和 GitHub 上比较热的项目，梳理它为什么火、工程上怎么落地、哪些地方容易翻车。

本文依据包括 ReAct 论文、Anthropic 的 agent 工程文章、OpenAI Agents SDK、LangGraph、Hugging Face smolagents、Google ADK、Pydantic AI、Microsoft AutoGen/Agent Framework、MCP 官方文档，以及 2026-07-28 通过 GitHub API 抓取的仓库快照。文末列出来源。

一句话入门：Agent Loop 是什么

最朴素的 LLM 调用是：

用户问题 -> 模型 -> 答案

Agent loop 多了一个关键动作：模型可以选择工具，工具执行后把结果再喂回模型，直到模型判断任务完成。

用户目标
  -> 规划/推理
  -> 选择动作
  -> 调用工具
  -> 读取观察结果
  -> 更新状态
  -> 继续循环或输出最终答案

用伪代码写就是：

state = init(user_task)

for step in range(max_steps):
    decision = llm(
        instructions=system_prompt,
        state=state,
        tools=tool_schemas,
    )

    if decision.type == "final_answer":
        return decision.content

    if decision.type == "tool_call":
        if requires_human_approval(decision):
            pause_for_approval(decision)

        observation = run_tool(decision.tool, decision.args)
        state.append(decision, observation)

raise BudgetExceeded("agent loop stopped by max_steps")

这段循环里有几个核心对象：

• state：当前任务状态，包含历史消息、工具结果、文件变更、浏览器页面、临时计划等。
• LLM decision：模型在每一步给出的选择，可以是最终回答，也可以是工具调用、子任务委派、要求更多信息。
• tool：外部能力，比如搜索、数据库、文件系统、浏览器、代码执行、企业 API。
• observation：工具执行结果。它会进入下一轮上下文，影响模型继续行动。
• stop condition：终止条件，包括完成、超步数、超预算、失败、等待人工确认。

所以 agent loop 的本质不是“模型更聪明了”，而是：模型被放进一个带工具、状态、预算和刹车的控制回路里。

ReAct：为什么“思考”和“行动”要交替

Agent loop 最常被追溯到 ReAct 思路。ReAct 论文提出让语言模型交替生成 reasoning traces 和 task-specific actions，也就是边推理边行动。论文里的关键点是：推理帮助模型跟踪计划、处理异常；行动让模型能访问外部知识库或环境，从而补充信息。

这解决了纯 Chain-of-Thought 的一个老问题：模型可以推理得很像那么回事，但如果事实前提错了，会一路错下去。Agent loop 则允许模型在中途查证、试探、纠错。

一个简化例子：

问题：某个开源库最新版本是否支持 MCP？

Thought：需要查官方 README 或 release。
Action：search_repository("repo MCP support")
Observation：README 提到 ToolCollection.from_mcp。
Thought：还需要确认版本和文档位置。
Action：open_docs(...)
Observation：文档有 MCP 章节。
Final：支持，并给出来源链接。

这就是 agent loop 的最小魅力：不是一次猜完，而是一边走一边看路。

为什么最近又火了

我这次检索时看到一个明显现象：agent loop 的热度不只来自研究论文，而是来自三类工程入口同时成熟。

第一类是 编码 agent。截至 2026-07-28 的 GitHub API 快照里，opencode、Claude Code、browser-use、Gemini CLI、OpenAI Codex 等仓库都有很高关注度，且多数在近期仍有提交。它们把 agent loop 放进终端、浏览器和代码仓库里，用户能直接看到“模型计划、改文件、跑命令、读错误、再改”的长循环。

第二类是 agent 框架。OpenAI Agents SDK、LangGraph、CrewAI、AutoGen、Google ADK、Pydantic AI、smolagents 等都在强调工具、状态、handoff、人类审批、tracing、durable execution 等能力。它们不只是封装一次 LLM 调用，而是在帮开发者管理循环本身。

第三类是 工具协议标准化。MCP 官方文档把 MCP 描述为连接 AI 应用和外部系统的开放标准，覆盖数据源、工具和工作流。它让 agent loop 的工具侧从“每个项目自己接一堆 API”逐步走向可复用的工具生态。

一个有意思的小结论是：2026 年的 agent 热，不是因为大家突然发现了循环，而是循环里的每个部件都开始产品化了。

GitHub 热度快照：注意力在哪里

下面是我在 2026-07-28 通过 GitHub API 抓取的一组快照。星标不是质量排名，只能说明社区注意力；是否适合生产，还要看维护状态、抽象复杂度、团队需求和你自己的可控性。

项目	关注点	Stars	最近提交	许可证
opencode	开源编码 agent	190320	2026-07-28	MIT
Claude Code	终端编码 agent	139355	2026-07-25	未标明
browser-use	浏览器自动化 agent	107057	2026-07-27	MIT
Gemini CLI	终端 AI agent	106216	2026-07-28	Apache-2.0
OpenAI Codex	终端编码 agent	101967	2026-07-28	Apache-2.0
AutoGen	多 agent 框架	60049	2026-04-15	CC-BY-4.0
CrewAI	多角色 agent 编排	56252	2026-07-28	MIT
LlamaIndex	文档 agent / RAG 生态	51153	2026-07-26	MIT
Agno	agent platform	41462	2026-07-28	Apache-2.0
LangGraph	有状态、长运行 agent	38296	2026-07-27	MIT
smolagents	code agent / tool agent	28565	2026-07-21	Apache-2.0
OpenAI Agents SDK	多 agent workflow	28230	2026-07-28	MIT
Google ADK	agent/workflow toolkit	20920	2026-07-28	Apache-2.0
Pydantic AI	类型安全 agent 框架	18850	2026-07-28	MIT

这里有两个信号值得看：

• 编码和浏览器 agent 非常热：因为它们让 loop 直接接触真实环境，能跑命令、看错误、改文件、浏览页面。
• 框架都在往生产能力靠：不是只提供 agent.run()，而是提供状态、持久化、审批、调试、追踪、部署、MCP 接入。

也要注意：AutoGen README 里已经标注 maintenance mode，并指向 Microsoft Agent Framework 作为更活跃支持的方向。星标是一段历史，不等于当前最佳选择。

Anthropic 的区分：Workflow 和 Agent 不是一回事

Anthropic 在 “Building Effective AI Agents” 里给了一个很实用的区分：

• Workflow：LLM 和工具沿着预先写好的代码路径运行。
• Agent：LLM 动态决定自己的流程和工具使用方式。

这一区分很重要。很多系统被叫做 agent，其实只是 workflow：比如固定的“先检索，再总结，再分类”。这没有问题，反而更稳定。真正的 agent 是模型在每一步都可以改变路线，例如发现信息不足后追加检索，发现代码测试失败后修改实现，发现权限风险后请求人工审批。

我的理解是：workflow 像地铁线路，agent 像出租车。地铁稳定、便宜、可预测；出租车灵活，但需要导航、费用上限和安全规则。别一上来就让模型开车横穿城市，小项目先坐地铁通常更划算。

Agent Loop 的工程骨架

一个稍微靠谱的 agent loop，通常至少包含这些层。

1. 指令层：告诉模型角色和边界

系统提示词不是越长越好。它应该回答几个问题：

• 目标是什么？
• 可以使用哪些工具？
• 什么情况下必须停止？
• 什么操作需要人工审批？
• 输出格式是什么？
• 遇到不确定信息时如何处理？

好的 agent prompt 更像操作规程，而不是文学创作。

2. 工具层：把世界变成可调用函数

工具设计决定 agent 的上限，也决定事故半径。一个工具至少要有：

• 清楚的名称和描述。
• 结构化参数。
• 可解释的返回结果。
• 错误码或失败信息。
• 权限边界。
• 幂等性或回滚策略。

OpenAI Agents SDK README 把工具列为核心概念之一，包括 functions、MCP、hosted tools。Pydantic AI 也强调工具、依赖注入、结构化输出。MCP 则试图把工具连接做成开放标准。

工具文档越糊，模型越容易瞎用。模型不是读心术，它只是很会假装自己读懂了。

3. 状态层：循环不是聊天记录那么简单

很多 agent 系统的问题不是模型不会想，而是 state 管不好。状态至少分几类：

• 短期上下文：当前任务、最近观察、当前计划。
• 工作记忆：中间文件、草稿、检索结果、命令输出。
• 长期记忆：用户偏好、项目约定、历史决策。
• 外部事实：数据库、文档、网页、API 返回。

LangGraph README 强调 long-running、stateful workflow，并提到短期工作记忆和长期持久记忆。Pydantic AI 则强调 durable agents，可以跨 API 失败、应用错误或重启保留进度。这说明工程界已经意识到：agent loop 的难点不是 while，是 while 里的状态可恢复。

4. 控制层：预算、步数和终止条件

没有控制层的 agent loop 很容易变成“模型在迷宫里散步”。常见控制手段包括：

• 最大循环步数。
• token 和费用预算。
• 工具调用次数上限。
• 每类工具的权限范围。
• 失败重试次数。
• final answer 判定。
• evaluator 或 verifier 检查。

AutoGen 示例里出现 max_tool_iterations，Google ADK README 提到 loops、retry、state management、human-in-the-loop。它们都指向同一个现实：循环必须有边界。

5. 观测层：没有 tracing，就没有调试

传统函数调用失败了，栈追踪还能告诉你哪里炸了。Agent loop 失败时，可能是提示词错、工具 schema 不清、检索结果污染、模型选错工具、状态丢失、预算太低、终止条件太松。

因此 tracing 是生产 agent 的必需品。OpenAI Agents SDK 把 tracing 列为核心能力；LangGraph 也强调可视化执行路径、状态转移和运行指标。你需要看到每一轮：

• 模型看到了什么上下文。
• 它选择了什么工具。
• 参数是什么。
• 工具返回了什么。
• 下一轮状态如何变化。
• 最终答案依据哪些观察。

Agent 的 bug 经常不像 bug，更像一段“很有道理但完全走偏的故事”。tracing 是把故事拆回证据链的工具。

几种常见模式

Prompt Chaining

把任务拆成固定步骤，例如“提取信息 -> 校验格式 -> 生成摘要”。适合路径稳定的任务。优点是可靠，缺点是不够灵活。

Routing

先判断任务类型，再分发给不同模型、提示词或工具。客服、文档问答、代码任务分类都常用。

Orchestrator-Workers

一个主模型拆任务，多个 worker 分头完成，再由主模型汇总。Anthropic 把它用于难以预先预测子任务的复杂问题，比如代码修改、多源检索。

Evaluator-Optimizer

一个模型生成，另一个模型评价并反馈，循环改进。适合有明确评价标准的任务，比如写作润色、代码审查、SQL 纠错。

ReAct Tool Loop

模型每一步决定是否调用工具，观察结果后继续。适合检索、网页操作、调试、代码执行等环境交互任务。

Multi-Agent Handoff

把某些任务交给专门 agent。OpenAI Agents SDK 把 handoffs 和 agents-as-tools 列为核心概念。这个模式有用，但要小心：多 agent 不是魔法，多一个 agent 就多一个状态边界和失败点。

Code Agent：为什么 smolagents 选择“用代码行动”

Hugging Face smolagents 的一个鲜明观点是 CodeAgent：让模型把 action 写成 Python 代码片段，而不是只输出工具调用 JSON。README 里说 code action 相比传统工具调用可以减少步骤，并在困难 benchmark 上表现更好。

这背后的直觉很简单：如果一次行动里需要组合多个工具、循环处理数据、做局部计算，代码比一串 JSON tool call 更自然。

例如传统 tool calling 可能是：

{"tool": "search", "query": "LangGraph memory docs"}

CodeAgent 可能直接写：

results = web_search("LangGraph memory durable execution")
docs = [open_url(r.url) for r in results[:3]]
final_answer(summarize(docs))

代码行动的代价也很明显：安全边界更重要。你需要沙箱、文件权限、网络权限、超时、审计日志。越强的行动能力，越不能裸奔。

MCP：工具生态的“接口层”

MCP 官方文档把它解释为连接 AI 应用与外部系统的开放标准，能连接数据源、工具和工作流。它的意义不在于“又多一个协议”，而在于让 agent loop 的工具层可复用。

没有 MCP 时，每个 agent 项目都要自己写一套：

连接 Notion
连接 GitHub
连接浏览器
连接数据库
连接内部系统

有了 MCP，理想情况是：

Agent client -> MCP server -> 外部系统

这让工具接入从“项目内硬编码”变成“协议化能力”。当然，协议不是安全本身。MCP server 能暴露什么资源、哪些操作需要授权、日志如何记录、敏感数据如何隔离，仍然要由应用层认真设计。

初学者怎么做一个最小 Agent Loop

不要从十个 agent、五个框架、三套记忆系统开始。可以从一个非常小的 loop 做起：

tools = [search_docs, read_url, final_answer]
state = [{"role": "user", "content": task}]

for step in range(8):
    decision = call_model(state, tools)

    if decision.name == "final_answer":
        break

    result = run_tool(decision.name, decision.arguments)
    state.append({"role": "tool", "content": result})

然后逐步加能力：

1. 加最大步数和费用预算。
2. 给工具返回结构化错误。
3. 记录每轮 tracing。
4. 对高风险工具加人工审批。
5. 把长任务状态持久化。
6. 增加 evaluator 检查最终答案。
7. 只有当任务确实复杂时，再引入多 agent。

入门时最有价值的练习不是“跑通框架 demo”，而是观察模型什么时候会选错工具、什么时候会过早结束、什么时候会陷入循环。

我对 Agent Loop 的判断

Agent loop 会继续火，但真正沉淀下来的不是“自主智能体”这个营销词，而是几组工程能力：

• Tool use：模型能可靠调用外部系统。
• Stateful execution：任务状态可保存、恢复、审计。
• Human-in-the-loop：高风险行动前能暂停。
• Tracing and eval：每一步可回放、可评估。
• Protocol layer：MCP 这类工具协议降低集成成本。
• Workflow-agent hybrid：稳定步骤用 workflow，不确定部分交给 agent。

最危险的误解是把 agent loop 当作“把模型放出来自己干活”。更准确的说法是：给模型方向盘，同时给系统装刹车、仪表盘、护栏和行车记录仪。

如果你要在业务里落地，我建议从这三个问题开始：

1. 这个任务是否真的需要动态决策？如果流程固定，用 workflow。
2. 哪些工具调用会产生外部副作用？这些地方必须有审批或回滚。
3. 出错后能不能复盘每一步？如果不能，先补 tracing，再谈智能。

Agent loop 的上限来自模型，可靠性来自工程。真正好用的 agent 系统，不是看起来最像科幻的那个，而是出错时你能解释、能停住、能修好的那个。

参考来源

• ReAct: Synergizing Reasoning and Acting in Language Models：https://arxiv.org/abs/2210.03629
• Anthropic, Building Effective AI Agents：https://www.anthropic.com/engineering/building-effective-agents
• OpenAI Agents SDK README：https://github.com/openai/openai-agents-python
• LangGraph README：https://github.com/langchain-ai/langgraph
• Hugging Face smolagents README：https://github.com/huggingface/smolagents
• Microsoft AutoGen README：https://github.com/microsoft/autogen
• Microsoft Agent Framework：https://github.com/microsoft/agent-framework
• CrewAI README：https://github.com/crewAIInc/crewAI
• Google Agent Development Kit：https://github.com/google/adk-python
• Pydantic AI README：https://github.com/pydantic/pydantic-ai
• Model Context Protocol 官方介绍：https://modelcontextprotocol.io/docs/getting-started/intro
• GitHub API 快照：本文表格数据抓取时间为 2026-07-28 14:30-14:37（Asia/Shanghai），保存于本地检索记录。