前四篇博客我们像剥洋葱一样把 Agent 的大脑袋LLM、手脚Tools、记忆Memory和灵魂ReAct 规划全给扒得底朝天。理论听了这么多是时候来点**“带泥土气息的工程实战”**了。今天咱们扔掉 LangChain、LlamaIndex 那些沉重的框架包袱。就用最纯粹的 Python 代码手撸一个带多步推理、工具调用和自我运转闭环的 Agent。哪怕你刚学会写 Python 的if-else只要跟着这套逻辑走你也能立刻明白市面上那些估值千万的 AI 创业项目底层到底是怎么跑起来的。一、 我们要造一个什么“打工人”为了化抽象为具象我们要手搓一个**“出行小助手”**。它只有两个极简的超能力工具查天气告诉它城市它返回天气情况。算数给它一个数学公式它给你算结果。任务目标当用户问“我在北京想去上海出差帮我查查上海的天气顺便算算我带 5000 块钱扣掉 1200 机票后还剩多少钱”时这个 Agent 必须能自主思考、按顺序调用工具、并给出最终回答。二、 核心灵魂老板的“SOP标准作业程序”不用框架怎么让 LLM 听话全靠 System Prompt系统提示词。 在这个实战里我们必须强制 LLM 扮演一个“流水线工人”每次只准输出特定格式的 JSON绝对不能说废话。咱们先把这份“SOP”写好PythonSYSTEM_PROMPT 你是一个全能的 AI 助手。你可以使用以下工具来解决用户的问题 【可用工具列表】 1. get_weather: 获取指定城市的天气。参数格式{city: 城市名} 2. calculator: 计算数学表达式。参数格式{expression: 数学公式} 【你的工作流程要求】 你必须且只能以 JSON 格式输出你的决策绝不能输出任何多余的解释文字 JSON 必须严格包含以下 4 个字段 - thought: 你的内心思考过程下一步该干嘛 - action: 你要调用的工具名如果任务已完成请填 FINISH - action_args: 你传给工具的参数字典如果 action 是 FINISH这里留空 - final_answer: 如果任务完成这里填最终回答否则留空 【示例】 {thought: 用户问天气我需要调用 get_weather 工具, action: get_weather, action_args: {city: 北京}, final_answer: } 有了这份极度严苛的 SOP大模型就从一个“聊天机器”变成了一个“决策引擎”。三、 完整代码100 行手捏 Agent找个新建的 Python 文件把下面的代码贴进去。这几乎就是当今所有 Agent 编排引擎最底层的骨架你需要自备一个能调用的 LLM API这里以最通用的 OpenAI 接口格式为例Pythonimport json from openai import OpenAI # 1. 准备大模型客户端 (请替换为你自己的 API_KEY 和 BASE_URL) client OpenAI(api_keysk-your-api-key, base_urlhttps://api.your-llm-provider.com/v1) # # 第一步外包团队定义工具集 # def get_weather(city: str) - str: 模拟查询天气的工具 print(f [️ 动作执行] 正在查询 {city} 的天气...) # 真实工程中这里会调用第三方气象 API mock_data {北京: 晴天20度, 上海: 暴雨15度} return mock_data.get(city, 未知天气) def calculator(expression: str) - str: 模拟计算器工具 print(f [️ 动作执行] 正在计算: {expression}) try: # 真实工程中绝不能直接用 eval极其危险这里仅作演示 return str(eval(expression)) except Exception as e: return f计算错误: {str(e)} # 工具路由表Dispatcher tools_map { get_weather: get_weather, calculator: calculator } # # 第二步核心闭环Agent 运行引擎 # def run_agent(user_query: str): print(f\n‍ 用户提问: {user_query}\n *50) # 初始化短期记忆Context Window messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_query} ] # 强制加上 max_steps 限制防止 Agent 陷入死循环 max_steps 5 for step in range(max_steps): print(f\n--- 第 {step 1} 轮思考 ---) # 1. 大脑决策调用大模型 response client.chat.completions.create( modelgpt-4o-mini, # 或者其他便宜好用的模型 messagesmessages, temperature0.1 # 调低温度让机器人的决策更稳定 ) raw_reply response.choices[0].message.content # 泥土气息的工程操作清理 LLM 返回的 Markdown 标记 clean_json_str raw_reply.replace(json, ).replace(, ).strip() try: decision json.loads(clean_json_str) except json.JSONDecodeError: print(f❌ 致命错误大模型没有返回标准 JSON内容是\n{raw_reply}) break # 2. 打印 Agent 的内心戏 print(f 思考 (Thought): {decision.get(thought)}) # 3. 判断是否大功告成 action decision.get(action) if action FINISH: print(\n 任务完成) print(f 最终回答: {decision.get(final_answer)}) break # 4. 执行动作 (Action) print(f⚙️ 决定调用工具 (Action): {action}, 参数: {decision.get(action_args)}) if action in tools_map: # 拿到对应的函数去执行 func tools_map[action] args decision.get(action_args, {}) # 假设参数只有一个这里做个简单拆包 observation func(list(args.values())[0]) print(f 观察结果 (Observation): {observation}) else: observation f错误找不到名为 {action} 的工具 print(f 观察结果 (Observation): {observation}) # 5. 将结果写入短期记忆进入下一轮死循环 messages.append({role: assistant, content: raw_reply}) # 存入它自己的思考 messages.append({role: user, content: f工具执行结果{observation}}) # 存入客观事实 else: print(\n⚠️ 警告达到了最大思考步数强制停机) # # 启动测试 # if __name__ __main__: run_agent(我准备去上海出差。帮我查一下天气。另外我带了 5000 块钱机票花了 1200我还剩多少预算)四、 见证奇迹程序跑起来是什么样如果你运行这段代码你会看到控制台打印出极其精彩的**“破案过程”**Plaintext‍ 用户提问: 我准备去上海出差。帮我查一下天气。另外我带了 5000 块钱机票花了 1200我还剩多少预算 --- 第 1 轮思考 --- 思考 (Thought): 用户需要查询上海的天气并且需要计算剩余的预算。我应该先查询上海的天气。 ⚙️ 决定调用工具 (Action): get_weather, 参数: {city: 上海} [️ 动作执行] 正在查询 上海 的天气... 观察结果 (Observation): 暴雨15度 --- 第 2 轮思考 --- 思考 (Thought): 已经获取了上海的天气。接下来需要计算剩余预算用 5000 减去 1200。 ⚙️ 决定调用工具 (Action): calculator, 参数: {expression: 5000 - 1200} [️ 动作执行] 正在计算: 5000 - 1200 观察结果 (Observation): 3800 --- 第 3 轮思考 --- 思考 (Thought): 天气和预算都计算完毕。现在我可以给用户一个最终答复了。 ⚙️ 决定调用工具 (Action): FINISH, 参数: {} 任务完成 最终回答: 上海的天气是暴雨15度。您的剩余预算是 3800 元。出行请注意带好雨具哦你看没有任何黑魔法大模型并没有亲自去查天气也没有亲自去算数。它只是在你设定的while/for循环里不断地“思考 → 下发工单 → 等待你把结果塞回来”直到收集齐所有拼图交出最终答卷。五、 带着泥土气息的工程复盘如果你要把这 100 行代码用到生产环境里赚钞票你立刻会面临几个硬核问题这也是真实开发中极其痛的领悟Json 解析的血泪史代码里那句replace(json, )看似随意却是无数工程师用凌晨的头发换来的。即便你千叮咛万嘱咐LLM 依然有极大概率在 JSON 外面包裹 Markdown 标记甚至在 JSON 里塞入未转义的换行符导致loads崩溃。在生产环境你必须引入更强健的解析库比如 Pydantic 或专门的 JSON Repair 工具。死循环的刹车片必须要有max_steps。有时工具一直报错比如网络不通Agent 会不厌其烦地调用同一个工具几百次把你的 API 额度瞬间刷干。安全的边界我们为了演示使用了eval()来做计算器这在工程上是绝对禁止的一旦用户输入import os; os.system(rm -rf /)你的服务器就灰飞烟灭了。真实的工具必须要做极度严格的入参沙箱校验。结语恭喜你到这里你已经亲手拼装了一台 Agent 引擎。回望这五篇博客从抽象的概念拆解、到 ReAct 闭环的理论、再到长短记忆的管理最后到今天这 100 行清晰可运行的代码。你会发现打破 AI 幻觉、让大模型真正落地做事靠的从来不是什么玄之又玄的魔法而是极其清晰的系统架构和扎实的工程手艺。现在底座已经建好。接下来你想给它装上连接数据库的手还是连通微信服务器的腿舞台交给你了