
Agent 不是一种神秘的新模型。它就是给大模型配上目标、工具、工作记录和一个可以反复执行的循环让它不只“说”还能连续“做”直到任务完成。一句话讲明白普通 AI 像一个坐在咨询台的人你问一句它答一句。Agent 像一个能使用电脑的数字员工你交代结果它自己判断下一步查资料、调用工具、检查结果没完成就继续。flowchart LR subgraph Chat[普通 AI咨询台] U1[ 用户提问] -- L1[ 大模型] L1 -- A1[ 回答] A1 -- E1[结束] end subgraph AgentBox[Agent会办事的数字员工] U2[ 用户交代目标] -- L2[ 大模型判断] L2 -- T2[️ 使用工具] T2 -- O2[ 查看结果] O2 -- D2{任务完成} D2 --|否| L2 D2 --|是| A2[✅ 交付结果] end style Chat fill:#eef6ff,stroke:#4a90e2 style AgentBox fill:#f2fff4,stroke:#45a049 style D2 fill:#fff3cd,stroke:#d39e00例如你说帮我查明天北京的天气再给我一份穿衣建议。普通聊天模型可能凭已有知识直接回答。Agent 则会明白最终目标包含“查天气”和“给建议”调用天气工具查询实时数据读取工具返回的温度和天气根据结果生成穿衣建议判断两个要求都已完成然后结束。这就是 Agent 最核心的工作方式目标 → 判断下一步 → 调用工具 → 观察结果 → 再判断 ↑ ↓ └── 未完成就继续 ──┘Agent 不是什么初学者最容易把下面几样东西混在一起概念通俗理解是完整 Agent 吗大模型LLM会理解和推理的“大脑”❌ 只有大脑还不能操作外部世界Prompt给大脑的岗位说明和工作要求❌ 只是说明书Function Calling / MCPAgent 能使用的“手和工具箱”❌ 只有工具没有自主工作循环Workflow人提前写死的流水线不一定通常不能自己改变下一步Agent大脑根据目标选择动作并根据结果继续工作✅最关键的区别不是“用了大模型”就叫 Agent也不是“写了一段很长的 Prompt”就叫 Agent。只有当模型能够在循环里根据当前情况自主选择下一步行动才真正有了 Agent 的味道。Agent 的六个零件可以把 Agent 想成一个刚入职的员工零件员工类比在程序中的样子目标老板交代要达到什么结果用户任务、成功标准大模型员工的大脑OpenAI、Claude 或本地模型指令岗位说明书System Prompt / Agent Prompt工具浏览器、计算器、数据库等函数、API、MCP 工具状态/记忆工作笔记和已完成清单对话历史、工具结果、任务状态循环与边界做完检查危险操作要请示while 循环、结束条件、步数限制、人工审批可以写成一个简单公式Agent 大模型 指令 工具 状态 执行循环 安全边界大模型负责做判断但真正把这些零件连接起来的是普通程序代码。flowchart TB G[ 目标br/要完成什么] -- C[ 大模型br/判断下一步] I[ 指令br/应该怎样工作] -- C M[️ 状态与记忆br/已经做了什么] -- C C -- T[ 工具箱br/搜索 / API / 数据库 / 文件] T -- O[ 观察结果] O -- M O -- D{✅ 完成了吗} D --|没有| C D --|完成| R[ 最终交付] B[️ 安全边界br/权限 / 步数 / 审批] -.限制.- C B -.限制.- T style C fill:#e3f2fd,stroke:#1976d2 style T fill:#fff3e0,stroke:#ef6c00 style M fill:#f3e5f5,stroke:#7b1fa2 style B fill:#ffebee,stroke:#c62828 style R fill:#e8f5e9,stroke:#2e7d32Agent 是怎么“想”的Agent 每一轮只需要解决三个问题现在已经知道什么——读取用户目标和前几步的结果。下一步最应该做什么——调用某个工具或者直接完成任务。做完了吗——完成就输出没完成就把新结果放回上下文再来一轮。这就是 ReAct 的通俗版本思考Reason→ 行动Act→ 观察Observe→ 再思考Note“思考”不是要求模型把隐藏推理过程全部展示出来。程序真正需要的是模型给出可执行的下一步例如“调用 get_weather参数是北京”。一次真实执行会发生什么用户目标查北京天气并建议穿衣 第 1 轮 模型决定调用 get_weather(city北京) 程序执行get_weather(...) 工具结果晴28°C 第 2 轮 模型看到工具结果后决定信息已经足够生成最终回答 程序发现没有新的工具调用结束循环模型并没有亲自执行 Python 函数。它只是提出“我要调用哪个工具和参数”真正执行函数的是你的程序。sequenceDiagram autonumber actor U as 用户 participant P as Agent 程序 participant L as 大模型 participant T as 天气工具 U-P: 查北京天气并建议穿衣 P-L: 目标 指令 工具说明 L--P: 调用 get_weather(city北京) Note over L,P: 模型只提出调用请求 P-T: 真正执行 Python 函数 T--P: 晴28°C P-L: 回填工具结果 L--P: 天气结论 穿衣建议 P--U: 返回最终结果从零设计 Agent 的思路不要一上来就学习复杂框架。先按下面七步设计flowchart LR S1[1️⃣ 明确结果] -- S2[2️⃣ 模拟人工流程] S2 -- S3[3️⃣ 设计最小工具集] S3 -- S4[4️⃣ 编写工作指令] S4 -- S5[5️⃣ 实现执行循环] S5 -- S6[6️⃣ 设置停止与容错] S6 -- S7[7️⃣ 增加安全审批] style S1 fill:#e3f2fd,stroke:#1976d2 style S3 fill:#fff3e0,stroke:#ef6c00 style S5 fill:#f3e5f5,stroke:#7b1fa2 style S7 fill:#ffebee,stroke:#c62828第 1 步先写清楚结果而不是先选模型错误目标做一个万能 Agent。合格目标接收城市名称查询天气并基于查询结果给出穿衣建议。目标越具体越容易判断 Agent 什么时候应该停止。第 2 步画出人类完成任务的流程先假装没有 AI问自己一个员工会怎么做读取城市 → 查询天气 → 检查查询是否成功 → 生成建议 → 返回结果这一步能帮你找到需要哪些工具和可能出现的错误。第 3 步只提供真正需要的工具天气 Agent 先有一个get_weather就够了不要一开始给它几十个工具。每个工具要写清楚名字和用途参数及类型返回结果的格式失败时返回什么是否会产生外部副作用。工具描述越含糊模型越容易选错工具或传错参数。详见 Function Calling。第 4 步写最小可用指令Prompt 主要告诉 Agent你是天气助手。 必须先使用天气工具获得数据再提供建议。 信息不足时说明缺少什么不要编造天气。 完成用户要求后直接给出简洁结果。Prompt 决定“怎么工作”代码决定“能做什么”。详细写法见 Agentic Prompt 设计。第 5 步写执行循环上下文 [用户目标] for 步骤 in range(最多步骤): 决定 大模型(指令, 工具说明, 上下文) if 决定要求调用工具: 结果 执行工具(工具名, 参数) 上下文.append(结果) # 让模型看见行动结果 else: return 决定的最终答案 # 没有工具调用任务结束 return 超过最大步骤停止并报告这段循环就是最小 Agent 的骨架。Agent 框架虽然功能更多底层仍然在帮助你管理这件事。第 6 步明确停止条件和失败处理至少回答这些问题最多允许执行几步工具报错后重试几次什么结果代表任务已经完成连续没有进展时怎么办调用不存在的工具时怎么办没有停止条件的 Agent可能不断调用 API浪费时间和 Token。第 7 步给危险动作加审批“查天气”可以自动执行“发送邮件、付款、删除数据、部署生产环境”则应先让用户确认。详见 Agent 四大约束。最小 Python Agent不使用 Agent 框架下面示例只使用 OpenAI Python SDK不使用 LangGraph 等 Agent 框架。天气数据是本地模拟的所以示例重点是看懂模型决定 → 程序执行 → 结果回填 → 模型继续的循环。运行准备pip install openai设置环境变量OPENAI_API_KEY把代码保存成weather_agent.py后运行。示例采用 Responses API模型名称可以按账户权限和成本要求替换。import json from openai import OpenAI client OpenAI() MODEL gpt-5.6-terra MAX_STEPS 5 # 1. 真正干活的普通 Python 函数 def get_weather(city: str) - dict: 演示用假数据真实项目可在这里调用天气 API。 demo_data { 北京: {weather: 晴, temperature: 28}, 上海: {weather: 小雨, temperature: 24}, } return demo_data.get(city, {error: f暂时没有 {city} 的天气数据}) # 2. 告诉模型有哪些工具、每个工具需要什么参数 TOOLS [ { type: function, name: get_weather, description: 查询指定城市的天气和摄氏温度, parameters: { type: object, properties: { city: {type: string, description: 城市名称如北京} }, required: [city], additionalProperties: False, }, strict: True, } ] # 3. 工具注册表把模型说的工具名映射到真正的函数 TOOL_FUNCTIONS { get_weather: get_weather, } INSTRUCTIONS 你是天气穿衣助手。 回答天气问题前必须调用 get_weather不得编造天气。 拿到天气后给出简洁、实用的穿衣建议。 def run_agent(task: str) - str: # 第一次把用户目标交给模型 response client.responses.create( modelMODEL, instructionsINSTRUCTIONS, inputtask, toolsTOOLS, ) for step in range(1, MAX_STEPS 1): calls [item for item in response.output if item.type function_call] # 模型没有再要求调用工具说明它给出了最终答案 if not calls: return response.output_text tool_outputs [] for call in calls: try: function TOOL_FUNCTIONS.get(call.name) if function is None: result {error: f工具不存在{call.name}} else: arguments json.loads(call.arguments) result function(**arguments) except Exception as error: # 不让一次工具错误直接弄崩整个 Agent result {error: str(error)} print(f第 {step} 步{call.name} - {result}) # 用 call_id 把执行结果交还给对应的工具调用 tool_outputs.append({ type: function_call_output, call_id: call.call_id, output: json.dumps(result, ensure_asciiFalse), }) # 模型看到工具结果后再决定下一步或生成最终答案 response client.responses.create( modelMODEL, instructionsINSTRUCTIONS, previous_response_idresponse.id, inputtool_outputs, toolsTOOLS, ) return f执行超过 {MAX_STEPS} 步已停止请检查任务或工具返回。 print(run_agent(北京现在天气怎么样我应该穿什么))官方当前建议使用 Responses API 构建推理、工具调用和多轮工作流可参考 OpenAI Model guidance。逐段看懂这份代码代码它在 Agent 中的角色get_weather()Agent 的工具/手TOOLS给模型看的工具说明书TOOL_FUNCTIONS程序实际允许调用的函数白名单INSTRUCTIONSAgent 的岗位说明和行为规则response.output模型本轮做出的决定function_call_output工具执行后的观察结果previous_response_id让下一轮接着当前任务继续for ... MAX_STEPSAgent 的执行循环和保险丝谁负责什么大模型负责理解目标、选择工具、填写参数、判断何时回答 程序负责执行函数、管理历史、处理错误、限制权限、决定最多跑几轮 工具负责连接真实世界并返回数据因此“写 Agent”并不是训练一个新模型而是写一套围绕模型的控制程序。flowchart LR subgraph ModelLayer[模型层负责决定] LLM[ LLM] INS[ INSTRUCTIONS] -- LLM DESC[ TOOLS 工具描述] -- LLM end subgraph ControlLayer[程序控制层负责管理] LOOP[ run_agent 循环] LIMIT[⏱️ MAX_STEPS] -- LOOP ERROR[ 异常处理] -- LOOP end subgraph ToolLayer[工具层负责执行] REG[️ TOOL_FUNCTIONS] WEATHER[️ get_weather] REG -- WEATHER end LOOP --|目标与上下文| LLM LLM --|function_call| LOOP LOOP --|按白名单调用| REG WEATHER --|function_call_output| LOOP LLM --|没有工具调用| FINAL[✅ 最终答案] style LLM fill:#e3f2fd,stroke:#1976d2 style LOOP fill:#f3e5f5,stroke:#7b1fa2 style REG fill:#fff3e0,stroke:#ef6c00 style FINAL fill:#e8f5e9,stroke:#2e7d32从最小 Agent 演进到真正项目建议按顺序增加能力不要一步到位单次工具调用模型选一个工具程序执行一次。加入循环工具结果回填模型可以继续选择下一步。加入状态保存任务进度、已完成步骤和必要上下文。加入可靠性参数校验、超时、重试、日志和测试。加入安全边界工具白名单、目录限制、人工审批和成本上限。任务确实复杂时再选架构ReAct、Plan-and-Execute 或 Multi-Agent。重复代码明显时再用框架框架是为了减少工程工作不会替你想清目标、工具和边界。flowchart BT L1[① 单次 Function Callingbr/模型选择一个工具] L2[② 最小 Agentbr/加入观察与循环] L3[③ 可靠 Agentbr/状态、重试、日志、测试] L4[④ 安全 Agentbr/权限、沙箱、审批、预算] L5[⑤ 复杂 Agent 系统br/规划、记忆、框架、多 Agent] L1 -- L2 -- L3 -- L4 -- L5 style L1 fill:#f5f5f5,stroke:#757575 style L2 fill:#e3f2fd,stroke:#1976d2 style L3 fill:#fff3e0,stroke:#ef6c00 style L4 fill:#ffebee,stroke:#c62828 style L5 fill:#f3e5f5,stroke:#7b1fa2判断一个需求是否真的需要 Agent适合 Agent下一步取决于上一步的结果需要组合多个工具过程存在不确定性不能提前写死允许 Agent 在边界内自主尝试和纠错。不适合 Agent固定的三步数据处理每次流程完全一样一次 API 调用就能完成金融付款等高风险动作不能容忍模型自主决策需要百分之百确定、可复现的业务规则。flowchart TD Q1{一次固定调用br/就能完成吗} Q1 --|是| API[使用普通函数 / API] Q1 --|否| Q2{流程能否提前br/完全写死} Q2 --|是| WF[使用固定 Workflow] Q2 --|否| Q3{下一步是否取决于br/前一步的结果} Q3 --|否| CODE[继续使用普通程序] Q3 --|是| Q4{允许模型在边界内br/自主选择行动吗} Q4 --|否| HUMAN[固定流程 人工决策] Q4 --|是| AG[适合使用 Agent] style API fill:#f5f5f5,stroke:#757575 style WF fill:#fff3e0,stroke:#ef6c00 style HUMAN fill:#ffebee,stroke:#c62828 style AG fill:#e8f5e9,stroke:#2e7d32Tip能用普通if/else和固定 Workflow 稳定完成的任务优先用普通程序。Agent 的价值不是让简单事情变复杂而是处理“下一步无法事先完全写死”的任务。初学者常见误区误区 1Prompt 越长Agent 越聪明Prompt 只需说清目标、工具规则、边界和完成标准。重复堆砌“认真思考”通常不能替代好工具与清晰流程。误区 2工具越多能力越强工具越多选择错误、权限过大和调用成本越容易增加。先提供完成任务所需的最小工具集。误区 3只要能调用工具就会一直做到完成程序必须把工具结果放回上下文并允许模型进入下一轮否则仍然只是一次 Function Calling。误区 4Multi-Agent 一定比单 Agent 好多个 Agent 会增加协调、Token、延迟和调试成本。一个 Agent 加几个清晰工具通常就足够。误区 5让模型自己保证安全Prompt 中说“不要删除文件”不够。真正的安全还要靠程序权限、工具白名单、沙箱和人工审批。学完后应该记住1. Agent 不是新模型而是一套以大模型为决策核心的程序系统。 2. Prompt 是岗位说明工具是手状态是工作笔记循环让它持续做事。 3. 最小 Agent 的核心就是模型决定 → 程序执行 → 结果回填 → 再决定。 4. 写 Agent 先想目标、工具和结束条件最后才考虑框架。 5. 能力越大越需要步数限制、权限控制和人工审批。