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

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 多了一个关键动作模型可以选择工具工具执行后把结果再喂回模型直到模型判断任务完成。用户目标 - 规划/推理 - 选择动作 - 调用工具 - 读取观察结果 - 更新状态 - 继续循环或输出最终答案用伪代码写就是stateinit(user_task)forstepinrange(max_steps):decisionllm(instructionssystem_prompt,statestate,toolstool_schemas,)ifdecision.typefinal_answer:returndecision.contentifdecision.typetool_call:ifrequires_human_approval(decision):pause_for_approval(decision)observationrun_tool(decision.tool,decision.args)state.append(decision,observation)raiseBudgetExceeded(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。 Actionsearch_repository(repo MCP support) ObservationREADME 提到 ToolCollection.from_mcp。 Thought还需要确认版本和文档位置。 Actionopen_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开源编码 agent1903202026-07-28MITClaude Code终端编码 agent1393552026-07-25未标明browser-use浏览器自动化 agent1070572026-07-27MITGemini CLI终端 AI agent1062162026-07-28Apache-2.0OpenAI Codex终端编码 agent1019672026-07-28Apache-2.0AutoGen多 agent 框架600492026-04-15CC-BY-4.0CrewAI多角色 agent 编排562522026-07-28MITLlamaIndex文档 agent / RAG 生态511532026-07-26MITAgnoagent platform414622026-07-28Apache-2.0LangGraph有状态、长运行 agent382962026-07-27MITsmolagentscode agent / tool agent285652026-07-21Apache-2.0OpenAI Agents SDK多 agent workflow282302026-07-28MITGoogle ADKagent/workflow toolkit209202026-07-28Apache-2.0Pydantic AI类型安全 agent 框架188502026-07-28MIT这里有两个信号值得看编码和浏览器 agent 非常热因为它们让 loop 直接接触真实环境能跑命令、看错误、改文件、浏览页面。框架都在往生产能力靠不是只提供agent.run()而是提供状态、持久化、审批、调试、追踪、部署、MCP 接入。也要注意AutoGen README 里已经标注 maintenance mode并指向 Microsoft Agent Framework 作为更活跃支持的方向。星标是一段历史不等于当前最佳选择。Anthropic 的区分Workflow 和 Agent 不是一回事Anthropic 在 “Building Effective AI Agents” 里给了一个很实用的区分WorkflowLLM 和工具沿着预先写好的代码路径运行。AgentLLM 动态决定自己的流程和工具使用方式。这一区分很重要。很多系统被叫做 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_iterationsGoogle 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 可能直接写resultsweb_search(LangGraph memory durable execution)docs[open_url(r.url)forrinresults[: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}]forstepinrange(8):decisioncall_model(state,tools)ifdecision.namefinal_answer:breakresultrun_tool(decision.name,decision.arguments)state.append({role:tool,content:result})然后逐步加能力加最大步数和费用预算。给工具返回结构化错误。记录每轮 tracing。对高风险工具加人工审批。把长任务状态持久化。增加 evaluator 检查最终答案。只有当任务确实复杂时再引入多 agent。入门时最有价值的练习不是“跑通框架 demo”而是观察模型什么时候会选错工具、什么时候会过早结束、什么时候会陷入循环。我对 Agent Loop 的判断Agent loop 会继续火但真正沉淀下来的不是“自主智能体”这个营销词而是几组工程能力Tool use模型能可靠调用外部系统。Stateful execution任务状态可保存、恢复、审计。Human-in-the-loop高风险行动前能暂停。Tracing and eval每一步可回放、可评估。Protocol layerMCP 这类工具协议降低集成成本。Workflow-agent hybrid稳定步骤用 workflow不确定部分交给 agent。最危险的误解是把 agent loop 当作“把模型放出来自己干活”。更准确的说法是给模型方向盘同时给系统装刹车、仪表盘、护栏和行车记录仪。如果你要在业务里落地我建议从这三个问题开始这个任务是否真的需要动态决策如果流程固定用 workflow。哪些工具调用会产生外部副作用这些地方必须有审批或回滚。出错后能不能复盘每一步如果不能先补 tracing再谈智能。Agent loop 的上限来自模型可靠性来自工程。真正好用的 agent 系统不是看起来最像科幻的那个而是出错时你能解释、能停住、能修好的那个。参考来源ReAct: Synergizing Reasoning and Acting in Language Modelshttps://arxiv.org/abs/2210.03629Anthropic, Building Effective AI Agentshttps://www.anthropic.com/engineering/building-effective-agentsOpenAI Agents SDK READMEhttps://github.com/openai/openai-agents-pythonLangGraph READMEhttps://github.com/langchain-ai/langgraphHugging Face smolagents READMEhttps://github.com/huggingface/smolagentsMicrosoft AutoGen READMEhttps://github.com/microsoft/autogenMicrosoft Agent Frameworkhttps://github.com/microsoft/agent-frameworkCrewAI READMEhttps://github.com/crewAIInc/crewAIGoogle Agent Development Kithttps://github.com/google/adk-pythonPydantic AI READMEhttps://github.com/pydantic/pydantic-aiModel Context Protocol 官方介绍https://modelcontextprotocol.io/docs/getting-started/introGitHub API 快照本文表格数据抓取时间为 2026-07-28 14:30-14:37Asia/Shanghai保存于本地检索记录。