ai agent从零构建大模型智能体怎么做

内容创作

从零搭一个大模型智能体:拆清模型、提示、工具、记忆、循环五块骨架,给出可交付的最小闭环与上线前检查清单。

你可能已经会调 API,但一到「让它自己干活」就卡住:不知道该接哪几个模块、工具怎么描述、循环什么时候停、跑起来的钱怎么算。这篇不堆概念,按一个能交付的最小闭环来排:先定任务边界,再依次补模型、提示、工具、记忆和循环,最后给一份上线前自查清单和不适用的场景。

你可能已经会调 API,但一到「让它自己干活」就卡住:不知道该接哪几个模块、工具怎么描述、循环什么时候停、跑起来到底花多少。别急着上框架,先按一个能交付的最小闭环来排:定任务边界,再依次补模型、提示、工具、记忆和循环,最后过一遍上线前自查。这篇只讲顺序和判断标准,具体数字一律去站内页面看当时的。

下面每一节都对应一个可以动手的交付物。做完一节就该有东西落盘,不然说明这层没想清楚。全文默认你用的是通用大模型接口,本地部署、私有化这些差异单独说明。

先定任务边界:什么活才值得做成智能体

判断标准就三条:多步、需调用外部数据、每步结果影响下一步。三条里至少中两条才值得上智能体。单轮问答硬套智能体,只会更贵更慢,还多出一堆调试成本。比如「查一条订单状态再按规则回话」是两步,算;「把一段话改通顺」是一次生成,老实用提示词加模板。

  • 输入从哪来:是用户手输、定时触发,还是别的系统推过来,得写死
  • 输出交给谁:直接回人、写回数据库、还是发通知,决定失败时谁能兜底
  • 失败怎么接手:重试、转人工、还是直接报错,提前定,别等上线了现想
  • 把上面三条写成一张任务卡,后面每一层都围着它加,加不进去的功能就是多余的

五块骨架:大模型、提示、工具、记忆、循环

模型
负责判断与生成,是唯一的决策核心
提示
负责约束输出格式和动作范围,相当于上岗说明
工具
负责碰外部世界,查数据、写记录、发消息都靠它
记忆
负责跨步保存状态,防止下一步忘了上一步做过什么
循环
负责把上面四者串起来,决定什么时候继续、什么时候停

动手前先画一张数据流图:谁产生中间结果、存在哪、下一步谁读。图画不清楚,代码一定乱。第一版工具控制在三五个,够跑通闭环就行,工具越多模型越容易选错。任务本身不需要外部数据时,可以省掉工具层,只留提示加循环。

模型与提示层:让它按格式交付

选型看三件事:能不能稳定输出结构化结果、单次延迟能不能接受、单位调用成本能不能兜住。具体单价和档位去 和 核对,别凭印象选。

检查项合格表现不合格就改
结构化输出连续多次返回都能解析成同一格式把格式要求拆成字段清单,并给一个示例
延迟单步在你能接受的等待范围内拆小任务、减少不必要的历史上下文
成本单次任务的调用量能估出来砍掉重复调用,合并可以合并的步
稳定性偶尔失败但能重试成功重试有限次数,并且换参数或换路径
  • 系统提示只写角色、边界、输出格式和停止条件,别把业务数据写死进去
  • 要求模型每步输出「思考要点+下一步动作」,动作必须限定在已注册工具清单里
  • 温度别开高,判断类任务偏高会让格式漂移;参数含义不清楚先查
  • 提示改动要留版本,不然出问题时没法回滚对比

工具层:描述写不好,模型就不会用

模型不会读你的代码,只会读你写的工具描述。每个工具写清四件事:名字干什么、什么情况下该用、参数含义与取值范围、成功和失败分别返回什么。这四件缺一件,调用就会出错或干脆不调。

  1. 先定工具清单把任务卡里所有需要碰外部系统的动作列出来,合并同类项,第一版不超过五个;参考 挑现成的,别自己从零造
  2. 写描述和参数每个工具一段说明,参数标类型和取值边界,给一个调用示例;示例用通用场景就行,别编真实业务数据
  3. 定返回格式只回模型判断需要的字段,压短;整段原始数据塞回去会撑爆上下文还带偏判断
  4. 分开回失败超时、无权限、查不到三种分开回,模型才知道该重试还是换路
  5. 用真实小样本验证挑两三条真实任务跑,看模型有没有选对工具、参数填得对不对;错得多就回头改描述,不要改代码

记忆层:短期工作状态与长期知识分开存

短期记忆存这一步的中间结果和已做过的动作,防止循环里重复做同一件事。长期知识走检索,把文档切片后存进向量库,可选方案见 ,命中的片段再拼进提示。两者别混在一个池子里,混了就没法控制上下文长度。

  • 已做过的动作记成结构化列表,每步开头先查一遍,避免原地打转
  • 超过一定轮数就做摘要压缩,只留结论和待办,别把全程对话原样带下去
  • 检索命中的片段带上来源标识,方便出错时回溯是哪一段带偏的
  • 任务几步就结束、每步都依赖上一次结果的,可以只留短期记忆,不做检索

循环与停止条件:不设上限就是烧钱

三类停止条件缺一不可:任务目标达成、达到最大步数、连续失败或结果重复。只写第一条,模型卡住时会一直循环到你手动掐掉,调用量就是这么失控的。

停止条件怎么判定触发后做什么
目标达成输出满足任务卡里约定的完成标准返回结果,记录耗时和调用次数
达到最大步数步数计数到上限中断,把当前中间结果交人工
连续失败同一动作失败次数到阈值换参数或换路径,仍失败就退出
结果重复连续两步动作和输入几乎一样中断,提示可能陷入打转

每步记录动作、输入摘要、输出摘要和耗时,出问题时按时间线回看,比盯日志猜快得多。失败重试要有限次数,并且换参数或换路径,原样重试通常还是同样结果。单次任务的成本要算得出来:调用次数乘单次用量,口径对齐 。

上线前的可交付清单

下面这几份东西都有,才算能交付。缺哪份就说明哪层还没想清楚,不要靠「先跑起来再说」糊过去。

  1. 凑齐五份文档任务卡、数据流图、工具清单、停止条件、失败后的人工接手方式,逐条对照现有文档补缺
  2. 跑真实小样本挑两三条真实任务跑通,确认输出格式稳定、成本在预算内、异常能兜住;跑不通就回到对应层改
  3. 单列计费口径模型调用、检索、外部接口、重试带来的额外消耗分别记一栏,具体单价去 看当时的数字
  4. 确认授权边界调用的外部系统允不允许自动化写入,回传的用户内容怎么存怎么删,合规口径见 ;这块没确认就别上生产

这些情况先别上智能体

  • 任务步骤每天变、没有稳定流程的,先把流程固定下来再谈自动化
  • 对结果要求零容错且没人复核的,智能体给的是可用草稿不是最终结论
  • 数据不能出内网的,先确认模型部署方式,该走本地就走本地
  • 预算按次卡得很死却又要多步调用的,先做单步工具,跑顺了再加循环
  • 外部系统接口本身不稳定或经常改的,先把接口这层捂热,智能体只会放大抖动
智能体不是更聪明的提示词,它是一套带停止条件的自动流程,停止条件写不清楚,越聪明越容易闯祸。
下一步先把任务卡画出来,再去挑模型和工具;顺带对一下同类中转的调用口径和计费方式,避免跑到一半发现成本兜不住。

常见问题

从零做一个能用的大模型智能体大概要多久?

看任务复杂度。单工具、单流程的最小闭环,一个人几天能跑通;带检索和多轮判断的通常要按周算。关键不在写代码,而在把任务边界和工具返回格式定清楚,这部分占的时间往往比写代码长。

一定要用框架吗,直接调 API 行不行?

行。任务简单时直接调 API 加自己写的循环更好排查,框架带来的抽象反而遮住问题。等工具多起来、需要统一管状态和重试,再考虑换框架,选型可以先看 /stacks/frameworks。

智能体老是绕圈或者重复调同一个工具怎么办?

先查三处:停止条件有没有设最大步数,工具返回的失败信息够不够区分,提示里有没有把已做过的动作带进下一步。三处都补上还绕圈,通常是任务边界太模糊,拆小一点再跑。

怎么估算跑一次任务的成本?

按步数乘单次用量来估:每步一次模型调用,加上检索和外部接口的调用次数,再加上失败重试的余量。单价和用量口径到 /tools/model-cost-calculator 和 /tools/token-price-calculator 按当时数字对一遍,别用记忆里的老价格。

智能体自动写进外部系统,出了错谁负责?

责任在使用方。稳妥做法是写入类动作设人工确认或二次校验,读类动作放开。涉及用户数据和对外内容的,提前确认授权范围,口径可参考 /safety。

本文依据各平台公开文档与官方公告整理,只做中文归纳;具体做法、参数与限制以官方文档为准。