手把手教你写一个 LLM Agent：60 行代码理解核心原理-北京尧图网络

手把手教你写一个 LLM Agent60 行代码理解核心原理不依赖任何框架用纯 Python OpenAI 兼容接口从零实现一个能自主调用工具的 ReAct Agent。市面上 Agent 框架一大堆LangChain、LlamaIndex、AutoGen……但很多人用了半年框架被问到「Agent 到底是怎么跑起来的」还是说不清。今天我们抛开框架60 行代码写一个最小的 Agent把核心原理吃透——理解了原理框架只是锦上添花。一、Agent 到底是什么先说清楚 Agent 和普通 Chatbot 的区别Chatbot你问一句它答一句。模型只能靠参数里的知识说话不知道今天天气、查不了数据库、动不了你的系统。Agent在「模型」外面套了一个循环让模型能调用工具、看到执行结果、再决定下一步。感知 → 决策 → 行动直到任务完成。一个 Agent 的三个核心组件┌─────────────────────────────────┐ │ LLM大脑理解任务、做决策 │ │ Tools手脚查天气/查库/执行代码 │ │ Loop循环把结果喂回去直到完成 │ └─────────────────────────────────┘这个「模型工具循环」的模式就是 ReActReasoning Acting模型先推理要不要用工具用完看结果再推理下一步如此往复。二、60 行最小实现用 OpenAI 兼容接口DeepSeek、Kimi、Qwen 都行换个 base_url 就好import json from openai import OpenAI client OpenAI(base_urlhttps://api.deepseek.com/v1, api_key你的key) MODEL deepseek-chat # 1. 声明工具告诉模型「你有什么手脚可用」 tools [{ type: function, function: { name: get_weather, description: 查询指定城市的实时天气, parameters: { type: object, properties: {city: {type: string, description: 城市名}}, required: [city], }, }, }] # 2. 实现工具真实逻辑返回字符串 def get_weather(city: str) - str: # 实际项目里这里是真实 API 调用 return f{city} 今天晴25°C TOOL_MAP {get_weather: get_weather} # 3. Agent 循环推理 → 调用 → 喂回 → 再推理 def run_agent(question: str, max_turns: int 10) - str: messages [ {role: system, content: 你是助手。需要实时信息时必须调用工具拿到结果后再回答。}, {role: user, content: question}, ] for _ in range(max_turns): resp client.chat.completions.create( modelMODEL, messagesmessages, toolstools, ) msg resp.choices[0].message messages.append(msg) if not msg.tool_calls: # 模型不再要求调用工具 return msg.content # → 给出最终答案任务完成 for tc in msg.tool_calls: # 执行每个工具调用 result TOOL_MAP[tc.function.name](**json.loads(tc.function.arguments)) messages.append({ role: tool, tool_call_id: tc.id, content: result, }) return 达到最大轮数任务未完成 if __name__ __main__: print(run_agent(北京和上海今天哪个更热适合穿短袖吗))运行一下模型的完整决策链是这样的第 1 轮模型返回 tool_calls [get_weather(北京)] → 还没答案继续第 2 轮模型返回 tool_calls [get_weather(上海)] → 对比需要两地数据第 3 轮模型返回「上海更热两地都适合穿短袖」 → 无 tool_calls结束这就是 Agent 的全部秘密没有魔法就是「模型的 function calling 一个 while 循环」。三、逐点拆解1. function calling 协议模型本身不会执行代码它只会返回一个 JSON想调哪个工具、参数是什么。执行永远是你的代码干的。所以「工具描述」写得越清楚模型选工具越准——description是写给模型看的提示词不是注释。2. 为什么必须有循环很多任务一步做不完。「对比两地天气」需要两次工具调用「查订单再退款」是两步依赖。循环让模型能把任务拆成多步每一步基于上一步的真实结果决策——这是 Agent 区别于单次问答的根本。3.max_turns是保命符模型可能陷入死循环反复调用同一个工具、或者工具一直报错。没有轮数上限一次失控的任务能把你的 API 余额烧穿。任何 Agent 循环都必须有硬性终止条件最大轮数、超时、预算上限至少要有一样。4. 工具结果必须是字符串role: tool的消息内容是字符串。工具返回 dict/list 时记得json.dumps模型才能读到。四、往上加从玩具到生产60 行是骨架生产级 Agent 在骨架上加四样东西组件解决什么问题常用方案记忆多轮对话记住上下文messages 列表本身就是短期记忆长期记忆存向量库RAG模型不知道你的私有知识文档切块 → embedding → 检索 → 塞进 prompt更多工具能力扩展执行代码、操作数据库、调内部 APIMCP 协议工具即插即用错误处理工具报错、参数解析失败try/except 后把错误信息喂回给模型让它自己调整错误处理值得单独说工具报错不要直接崩掉把报错文本作为工具结果喂回给模型。模型经常能根据报错自己修正参数重试——这比你在代码里写一堆 if-else 重试逻辑优雅得多模型自己就是个不错的错误恢复器。五、什么时候用框架理解了原理之后框架的取舍就清楚了2~3 个工具、线性流程→ 60 行手写没有任何依赖最好调试多 Agent 协作、复杂编排、需要可视化和回调→ LangGraph / AutoGen 这类框架省事工具生态对接→ 直接用 MCPModel Context Protocol写一次工具所有支持 MCP 的 Agent 都能用我的建议先用 60 行跑通一个真实需求再决定要不要框架。反过来先上框架的人最后往往被框架的抽象层搞得怀疑人生。总结Agent LLM 工具循环核心是 ReAct 模式模型只做决策返回要调用的工具和参数执行是你的代码的事循环必须带终止条件max_turns是保命符工具报错喂回给模型让模型自己恢复先手写跑通再考虑框架完整代码复制就能跑把base_url和api_key换成你自己的模型服务即可。下一篇可以讲多 Agent 协作和 MCP 工具生态感兴趣的点个关注。

手把手教你写一个 LLM Agent：60 行代码理解核心原理

相关推荐

LitmusChaos 混沌实验分布式追踪提案解读：用 OpenTelemetry 与 Jaeger 定位混沌注入的性能瓶颈

UE4 C++设计模式实战：用Actor、Component和状态机重构玩法代码

密码学基本理论

更多资讯

Java博客作业

MMAction2 版本演进全解析：从 v0.5.0 到 v1.2.0 的能力版图与迁移脉络

电力系统调峰成本量化与分摊的Matlab实现

FFmpeg纯音频HLS推流时间同步问题解决方案

Codex CLI第三方API接入：config.toml配置排错指南

CRM系统前端源码丢失后如何二次开发？AI分析API + Vue3/Vite重建前端实战

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？