最近把“AI学习系列”从提示工程往前推了一步今天这篇是系列第04篇专门聊智能体 agent 的核心概念和典型流程。写这篇的原因是身边不少同学已经把大模型聊天、写提示词玩得很溜了但一旦遇到“让AI自己查资料、算结果、写文件、反复调整直到满意”这种任务就不知道怎么设计了。智能体就是用来解决这类问题的它不是“你问一句、它答一句”的问答工具而是能围绕一个目标自己规划、调用工具、根据结果调整行动的完整系统。这篇文章适合刚学完大模型基础、想动手做点实际项目但被“自主、工具、规划、反思”这些词绕晕的学习者。我会把概念和流程用大白话拆开顺便把实际调试中踩过的坑一并说清楚。1. 智能体到底是什么——先给“Agent”一个不玄学的定义1.1 被一堆名词绕晕之前先记住这个四要素市面上“AI智能体”“Agent”“自主代理”这些叫法满天飞其实说的是同一个东西。我的理解很简单智能体是以大语言模型为决策核心能够感知任务环境、自主制定计划、调用外部工具、并根据执行结果自我校正的软件系统。拆开看就是四个部分大脑、手脚、记忆、规划。用带新员工的经理思维来类比普通AI应用像坐在咨询台后面的顾问你问一句它答一句它不会主动去查档案、找外部资料智能体更像一个新入职的员工你给它一个目标“把这周的报表整理好”它会自己拆任务——哪些数据要查、用什么工具、遇到缺数怎么办做完还会自己检查一遍有没有错。这个“拆、做、查、改”的闭环就是智能体区别于普通AI应用的核心。需要提醒的是“Agent”这个词早期在强化学习和传统机器人领域就有指能感知环境、采取动作、获得反馈的实体。大模型时代说的Agent是把“智能决策”这件事转移到了LLM上所以学术界也常叫“LLM Agent”。两者共同点是那个“感知-决策-行动-反馈”回路差别在于大脑从预设策略换成了大模型的文字推理。平时聊天为了不绕口直接叫智能体就行。1.2 三问测试如何判断一个AI应用算不算智能体很多产品宣传里都自称“智能体”但实际的“智能含量”差异巨大。我判断一个应用算不算智能体常用一个三问测试它有没有一个多步的、可以中途调整的目标它能不能自己调用外部工具查数据库、执行代码、发网络请求当执行结果和预期不一致时它会不会自己修正三个问题都回答“是”基本就是合格的智能体。举两个反例和正例对比纯文本翻译API不管翻译质量多高都不是智能体因为既没有多步目标也不会调用工具更不会自我修正。而一个“帮我做竞品分析报告”的应用会去搜索网页、抓取链接内容、整理成表格、写入本地文件重读时发现某个数据源过时又自动重新搜索更新——这是典型的智能体。当然边界产品也很多聊天机器人接了个搜索API勉强算半个智能体带代码解释器的编程助手已经是智能体形态。纠结名词没意义真正要抓住的是“闭环”和“自我校正”这两个本质特征。后面做架构设计时只要紧扣这两个特征就不会跑偏。2. 智能体靠什么“活”起来——四个核心概念拆解2.1 大脑为什么底座要选“工具调用能力强”的模型智能体的底座是一个能力足够的LLM它承担三件事理解、推理规划、表达转换。具体来说理解就是把用户模糊的请求解析成任务、约束和目标推理规划是决定先做什么、需要什么信息、用哪个工具表达转换是生成工具调用的参数以及产出最终回答。选底座模型时我优先级最高的不是“它会写诗”而是三件事指令遵循能力、function calling质量、上下文长度。早先我踩过一个坑某模型写文案很溜但让它“调用名为search的查询工具参数是关键词”它会把工具名编成另一个名字参数结构也乱套整个流程当场崩掉。所以做智能体一定要选专门针对工具调用调优过的模型而不是单纯的“全能选手”。顺便解释一下function calling底层实现有两类一类是模型厂商专门微调出的原生能力一类是靠提示词加结构化输出模拟出来的。对应用开发者来说重点是理解它的行为——模型根据用户请求从我们提供的函数列表里选一个生成结构化的调用参数然后由系统真正执行。2.2 手脚工具不是越多越好描述质量才是关键工具解决了大脑“只会说话不会动手”的问题。给模型提供工具本质上和写API文档很像给模型一份“工具目录”写清每个工具叫什么、干什么、要哪些参数、返回什么。模型根据任务需要从目录里挑生成一个结构化调用请求系统收到请求后真的去执行把结果回传到上下文。哪些东西适合做成工具我习惯分四类类型典型例子应用场景信息获取类搜索引擎、网页抓取、数据库查询、文档读取查资料、检索知识库内容处理类代码解释器、格式转换脚本、正则工具跑代码、清理数据业务操作类发消息、创建工单、操作Excel对接内部系统物理设备类机器人、传感器、智能家居控制硬件控制场景设计工具时最常见的失误是描述含糊。模型比想象中更依赖描述质量比如不要写“search 工具用于搜索”而要写清楚“当用户需要实时信息或最新资讯时使用search进行网页搜索输入参数keyword是搜索关键词返回值包含标题、链接、摘要”。实测下来给每个工具加上“使用场景”和“使用禁忌”两段工具命中率能提升一大截。2.3 记忆上下文窗口装不下时怎么取舍智能体的记忆分两类短期记忆和长期记忆。短期记忆就是对话上下文相当于员工手边的便签LLM的上下文窗口就是便签大小写满了就要做取舍。新手最常见的翻车就是上下文爆炸——跑到第10轮前面所有历史全部塞在请求里又慢又贵模型反而抓不住重点。长期记忆则是存在模型外部的信息用于跨会话保留偏好和知识。常见做法有三种第一向量库存文本块按语义召回相关片段塞进上下文第二关系数据库或文档存结构化记录比如用户档案、任务历史第三摘要压缩法把旧的对话反复压缩成摘要再放进上下文。我的经验是记忆不是越多越好而是“被检索到的才是记忆”。有一版方案我没做检索增强硬塞了20万字符的知识库给模型效果反而很差后来改成向量检索取top-5成本降了一个数量级回答质量反而更稳。对智能体来说记忆本质上就是“上下文管理策略”要学会做减法。2.4 规划任务分解与“刹车”机制规划就是智能体把大目标拆成一连串可执行的小步骤。目前两种常见模式一是“计划-执行”模式Plan-and-Execute先让模型生成一个完整计划列出步骤和依赖关系然后逐步执行执行完再核对计划是否成立。适合任务结构清晰、步骤可预期的场景比如周报生成、数据流水线。二是“推理-行动”模式ReAct不预先写完整计划而是每轮循环都做一次“思考→选择动作→观察结果”下一步根据上一步的结果决定。适合探索型任务比如查资料总结、调试代码。规划环节最容易犯的错是让模型“自由发挥”而没有约束。结果就是模型列了一个惊艳的计划第二步就卡住。正确做法是在系统提示里写明白“优先按最小可行路径执行遇到新信息再调整计划。”同时一定要设置最大步骤数否则“计划”会变成“幻想”模型能在一个目标上无限发散。3. 一次真实的智能体运行——典型流程逐段拆解3.1 第一步从用户指令提取目标与约束典型流程的第一件事是把用户的自然语言转成“目标约束输出格式”。好的目标必须是可验证的。举个对比模糊目标“帮我看看最近的新闻。”——什么是新闻看哪类看完要干嘛全是坑。明确目标“生成一份过去24小时人工智能行业的热点摘要输出10条每条含标题、来源、一句话简介保存到news.md。”实际开发中我会加一个“目标解析层”规定模型从用户指令中抽取goal、constraints、required_output、stop_conditions然后用JSON解析保存。这一步治好了80%的“智能体跑偏”问题——因为后面循环的所有判断都以goal作为基准。如果这一步不做后面就是一盘散沙。3.2 第二步规划与工具选择的基本原则拿到目标后进入规划阶段。简单任务不需要显式规划直接调用一次工具就能完成复杂任务才需要先生成一个计划。如果要生成计划我建议至少包含三块步骤序号、每步目的、预计使用的工具。这样模型在循环里能“照着脚本走”也方便人审查。规划本身不用太详细5步以内最好太长的计划不仅容易执行失败维护成本也高。工具选择有个反直觉的原则用尽量少的工具完成尽量多的事。工具越多模型的选择难度越大推理速度下降还容易出现“该用A却调了B”的低级错误。我的配置经验是一个智能体的常规工具数量控制在3到5个最舒服超过8个就要考虑按场景做分组路由让模型先选组、再选工具。3.3 第三步思维-行动-观察循环智能体的心脏规划或单步动作确定后进入核心循环。ReAct循环的伪代码如下while steps max_steps and not done: thought llm_think(context) # 这次该做什么需要什么信息 action_choice llm_decide_tool(context) # 选哪个工具参数是什么 observation execute_tool(action_choice) # 真正执行工具拿到结果 context.append(observation) # 观察结果写回上下文 if llm_check_done(context): # 判断目标是否达成 break核心点是每一轮“思考”都要产出可以验证的中间结论而不要憋着直接输出最终答案。调试智能体时我最看重日志里的“thought”字段它能告诉我到底是推理错了还是工具返回错了一分钟就能定位问题。这个循环里必须有两个“刹车”最大轮次上限和停机条件。最大轮次默认8比较合适太少复杂任务完成不了太多成本失控。停机条件本质是一个“验收器”由模型判断目标约束是否满足同时可以叠加硬校验比如文件是否存在、返回JSON是否符合格式。3.4 第四步结果整合与强校验循环结束后智能体要把中间过程整理成最终交付物。最后建议多一步“格式化整理”让模型按统一模板输出而不是把日志抛给用户。我踩过一个非常典型的坑让智能体“总结10篇文章并保存”它跑了12轮之后说“任务完成”结果我打开文件一看是空的。复盘发现模型把“输出计划”当成了“执行结果”压根没触发写文件的工具。从那以后我在流程里强制要求执行器层面做硬校验文件是否写入成功、内容长度是否非零。这个校验比模型自己说“完成”要可靠得多。4. 手写一个最小ReAct智能体——代码与参数调优4.1 最小化选型不依赖框架先跑通闭环很多初学者一上来就接复杂的Agent框架结果被框架的抽象搞晕。我建议先不依赖任何框架用最基础的方式手写一个ReAct循环。这里选用Python 3加两个玩具工具一个加法和一个文本保存。核心把循环逻辑摊开理解之后再看框架你会发现框架就是个“循环工具注册记忆管理”的壳子。4.2 完整代码一个可运行的ReAct循环下面是一个极简可运行的实现。为了让你能看到完整效果我用一个模拟函数替代真实大模型接口实际使用中把它换成大模型API调用即可。import json import re from typing import Dict # ---------------- 工具定义 ---------------- def add(a, b): return a b def save_to_note(content): return f已保存{content[:50]} TOOLS { add: {desc: 计算两个数的和参数a和b均为数字, params: [a, b], func: add}, save_to_note: {desc: 把文本内容保存到便签参数content为字符串, params: [content], func: save_to_note}, } TOOL_DESCRIPTIONS \n.join( f- {name}: {info[desc]} 参数: {info[params]} for name, info in TOOLS.items() ) # ---------------- 模拟LLM ---------------- def call_llm(messages): # 真实场景调用大模型API传入messages返回模型输出文本。 # 这里用规则模拟输出统一的JSON结构。 user_text messages[-1][content] if messages else if user_text.startswith(计算): nums list(map(float, re.findall(r[\d.], user_text))) if len(nums) 2: return json.dumps({ thought: 用户要求计算我需要使用add工具, action: add, args: {a: nums[0], b: nums[1]} }, ensure_asciiFalse) return json.dumps({ thought: 参数不足无法执行, action: final, args: {answer: 请提供两个数字} }, ensure_asciiFalse) if user_text.startswith(保存): return json.dumps({ thought: 用户要求保存调用save_to_note工具, action: save_to_note, args: {content: user_text.replace(保存, ).strip()} }, ensure_asciiFalse) return json.dumps({ thought: 没有匹配到工具直接回答, action: final, args: {answer: 请说一个计算或保存任务} }, ensure_asciiFalse) # ---------------- ReAct循环 ---------------- def run_agent(task, max_steps8): context [ {role: system, content: f你是智能体。可用工具如下\n{TOOL_DESCRIPTIONS}}, {role: user, content: task} ] for step in range(1, max_steps 1): raw call_llm(context) try: parsed json.loads(raw) except json.JSONDecodeError: parsed {action: final, args: {answer: 输出解析失败}} thought parsed.get(thought, ) action parsed.get(action, ) print(f[Step {step}] 思考: {thought} | 动作: {action}) if action final: print(最终结果:, parsed[args].get(answer)) return parsed[args].get(answer) if action in TOOLS: tool_func TOOLS[action][func] try: result tool_func(**parsed[args]) except Exception as e: result f工具执行失败: {e} # 把模型输出和工具返回都回写上下文 context.append({role: assistant, content: raw}) context.append({role: tool, content: f工具{action}返回: {result}}) else: print(未知工具提前终止) break print(到达最大步数停止) return None if __name__ __main__: run_agent(计算 3 和 5 的和再把结果保存到便签)这段代码麻雀虽小五脏俱全思考、选工具、执行、观察、回写、终止条件全齐了。你运行后能看到每一轮的thought和action这也是调试真实智能体时最该关心的输出。4.3 运行逻辑与三个关键调参项代码里的几个关键点值得展开。动作格式一定要统一成结构化JSON不要用自由文本后续才能拦截和校验。上下文回写不能省assistant的输出和tool的返回都必须追加到context里否则模型不知道工具执行结果下一轮就是在瞎猜。终止条件要有两层一是模型自己输出final二是最大步数兜底。换成真实模型后通常要调三个参数。第一是max_steps简单任务给4复杂任务给10到15。太大不只是慢而是每多一步都可能进一步跑偏。第二是温度工具调用场景建议调到0到0.2温度越高函数名和参数JSON就越容易出错。第三是工具结果截断如果是真实API返回结果往往很长不截断会稀释模型注意力我习惯限制在500字以内。5. 高频故障排查实录——死循环、幻觉、工具不稳定、成本失控5.1 停不下来的循环目标不清与停机条件太弱现象非常典型日志里反复出现“调用搜索工具→拿到无关结果→再调用搜索工具”像一个失控的打字机。原因基本落在两个地方目标不明确或者停机条件太弱。我在真实项目中处理过一个跑了27轮的循环烧掉大量token最后发现模型把“继续搜索”当成了自己的核心职责。解决办法有三个停机条件加硬校验比如要求输出必须包含制定key否则不算完成同时设置max_steps做硬上限最关键的是在系统提示里加一句“如果没有新增信息直接总结当前已获取内容并结束”。加了这句之后循环次数立刻降了一半以上。5.2 假执行模型幻觉与工具名编造现象更隐蔽模型没有真正调用工具却一本正经地说“我已经查询了数据库结果是……”。这是因为模型在训练数据里见过类似对话容易自己脑补执行过程。还有一种是工具名编造明明只提供两个工具它能“创造”出第三个来。对策上解析层严格要求结构化JSON遇到不存在的工具名直接报错并让模型重新输出工具列表里给每个工具加“别名提示”比如“检索工具别名search_only”降低模型误写的概率。另外一个很有用的办法是执行前校验参数类型比如add的参数如果不是数字就拒绝执行把报错信息反馈给模型让它重新生成。5.3 外部工具不稳定把错误信息当成一种输入网页抓取超时、数据库连接失败、函数内部报错——外部工具不稳定是常态。早期我做了一个粉碎性做法工具一旦报错就让整个智能体终止结果大量任务半途而废。后来改成执行器包一层try-except把错误信息原样返回给模型。实测下来模型在收到“连接超时请重试或更换工具”这样的反馈后大概有一半的概率会选择另一条路径比如换一个搜索源或者改用缓存数据。这也是我想强调的错误信息不是垃圾它是模型最重要的推理输入之一。另外给每个外部工具设置超时时间避免一个卡死的请求拖垮整个循环。5.4 token成本与延迟记账和降级策略智能体跑一次复杂任务调用几十次API很正常成本核算容易失控。我的生产环境里做了“工具调用记账”每轮循环记录次数和token数一旦超过预算自动触发降级策略只回答、不做工具调用。这个策略很土但很有效。还有一个经验是限制工具结果长度前面提过不要小看这一点——一个搜索接口可能返回上万字的正文不截断的话每次携带这些内容调用模型费用和延迟都会成倍增加。优先让工具返回“摘要关键字段”而不是原始全文。6. 给初学者的三条进阶路线参考6.1 先做一个“单工具”的智能体不要一上来就规划复杂路由。先做一个只能调用一个搜索工具或一个计算工具的智能体慢慢跑通“思考→调用→观察→回答”这个闭环然后再加第二个工具观察模型怎么在两个工具之间选择最后再加记忆和规划。我见过很多人第一步就追求架构宏大设计了一堆子智能体和路由规则最后几个月都耗在调试地狱里。小步快跑永远是学Agent最稳的路径。6.2 建一个30条任务的评估集给自己准备30到50条典型任务覆盖正常输入、边界输入和错误输入。每次改完提示词或者换模型先跑一遍评估集统计任务完成率。没有评估集的Agent项目改bug完全靠运气——今天调好一个问题明天可能又出现三个新的。有了固定的评估集至少能知道自己有没有变好。6.3 打印“思考”日志抓住排障命门调试智能体最有效的手段就是打印每一轮的thought。它直接告诉你模型当时怎么想的是信息不足是工具选错还是计划偏离。90%的问题都能从这一行里找到线索。真实开发中我会为每一轮循环保存完整的决策上下文方便出问题时回放。这比盯着最终输出猜原因高效太多。我自己做智能体快两年最大的一个感悟是智能体不是一个“开箱即用的功能”而是一套工程体系。把它想象成带实习生目标要说清楚工具要给到位遇到错误要反馈交付要有验收标准。把这套“带人的管理思路”翻译成代码逻辑很多设计问题会变得一目了然。核心概念其实不多典型流程也固定真正的功夫全在细节校验和工程兜底上。希望这篇系列第04篇能帮你把概念立起来把流程跑通——下一步挑一个十几行的最小循环亲手改一改踩几个坑比看十篇教程都管用。