开发一个AI Agent 难不难提示词工程、上下文记忆、任务编排开发一个自己的AI Agent到底需要哪些技术知识在网上搜索相关的信息什么提示词工程上下文记忆任务编排听着都是既抽象又难理解的概念看得脑袋都疼。后来想起来AutoGLM 应该也是AI Agent智谱把它开源了代码也不多。不如先从它的代码看起先直观了解一下AI Agent到底是怎么一回事。Agent 到底在干什么简单读了一下源码发现它也没想象的那么复杂可以说简单到让你都觉得离谱。输入指令“帮我打开小红书搜一下美食攻略。”人会如何操作先看一眼屏幕 → 脑子想小红书图标在哪 → 手指点一下 → 再看一眼确认打开了 → 然后点搜索框 → 打字…… 。 AI Agent做事流程一模一样。看截图 → 想大模型推理 → 动执行动作 → 再看新截图 → 再想 → 再动……就是一个循环。从头跑到尾。AutoGLM的核心代码在agent.py里一个while循环没有调度器没有任务队列没有状态机。总结功能就三块提示词怎么写、上下文怎么记、遇到意外怎么处理。一、提示词工程提示词工程这个概念听起来高大上到底做了什么脑子里没有概念。翻看了一下AutoGLM的提示词设计抽象的概念马上有了直观的感受。提示词工程是一套用来引导大模型输出精准、符合预期结果的方法论、技巧范式与优化手段。抽象的概念不好理解我们来看一下AutoGLM的提示词是怎么设计的。1.身份定义“你是一个智能体分析专家可以根据操作历史和当前状态图执行一系列操作来完成任务。”2.输出格式约束{推理} {action}3.动作说明书→ Launch / Tap / Type / Type_Name / Swipe / Long Press / Double Tap/ Back / Home / Wait / Take_over / Interact / Note / Call_API→ 每种操作都配有用途说明 参数格式 特殊注意事项4.硬性规则涵盖了各种边缘情况网络错误重试、滚动查找逻辑、购物车状态管理、敏感操作确认、死循环避免、操作生效验证等先拿点击操作举例坐标怎么算AutoGLM的处理方式挺妙的。把屏幕统一映射成0到999的坐标系统不管什么分辨率。“坐标系统从左上角(0,0)开始到右下角(999,999)结束”就这么一句话。模型只需要说Tap [100, 200]代码自动换算成实际像素。一个Prompt规则解决了一个工程问题。点歪了怎么办AutoGLM的做法依然是写规则。“如果点击没生效可能因为App反应较慢请先稍微等待一下如果还是不生效请调整一下点击位置重试如果仍然不生效请跳过这一步继续任务。”三级处理等 → 换位置 → 跳过。全写在Prompt里。Prompt工程到底做了些什么输出格式——你得告诉模型你要它输出什么格式比如do(actionxxx)这种伪代码。操作规则——遇到什么情况怎么处理上面例子全是这个。边界条件——什么时候放弃、什么不能做。输入内容——每一步要给模型看截图、当前应用信息、历史对话。这些东西在传统代码里需要使用分支判断状态切换异常处理。在Agent里将这些逻辑通过自然语言描述的方式放到Prompt里了这些逻辑都由ai来完成。二、上下文记忆模型如何记住用户之前说了什么拿点奶茶举个例用户“帮我点一杯海盐咖啡。”第1步模型收到的信息是系统提示词上面那些规则 用户说的话 当前手机截图。模型想了想决定先打开美团。输出Launch(美团)。第2步模型收到的信息变成系统提示词 上一轮的思考和动作 “帮我点一杯海盐咖啡”还在 新的截图美团已经打开了。模型看到新截图哦打开了接下来要搜索。输出Tap(搜索框)。第3步又收到系统提示词 前两轮完整对话 “帮我点一杯海盐咖啡”还在 新截图搜索框已经点开了。模型好输入海盐咖啡。输出Type(“海盐咖啡”)。看出门道了么模型为什么能一直记住海盐咖啡因为每一轮都把这句话重新发给了它。就是这么简单粗暴。每次循环前面所有对话全部塞给模型。这就是AutoGLM的上下文记忆——没有技术含量纯堆上下文窗口。做了唯一的优化一直累加上下文不是越来越长吗那消耗的token不是越来越多吗图片使用token比较多对图片做Base64处理之后生成的文本会非常的大非常的消耗token。AutoGLM做了唯一一个优化每一轮推理完立刻把这一轮的图片从历史上下文里删掉。只保留文字删掉图片。文字虽然也在累积但好歹比图片小得多。一个直观的比喻就像你一边跟人打电话一边做笔记每次说新的话之前都要把前面所有的笔记重新念一遍给对方听。没有向量数据库没有embedding没有RAG。就是简单的历史对话拼接。但够用了。一开始我也感觉奇怪以为自己理解错了。但代码就这么写的没有RAG技术就是每轮把之前说过的话再发一遍。三、任务分解与编排前面说的都是单步操作但几十步的操作怎么处理如何决定先干什么后干什么按传统思路写状态机、画流程图、堆if-else。AutoGLM如何处理的呢复杂的任务分解与编排也交给模型处理。还是点咖啡但这次出了意外正常流程打开美团 → 搜索海盐咖啡 → 找到商品 → 加购 → 下单。真实环境下有可能出现各种意外。意外1App没打开第1步模型说Launch(美团)。执行完了新截图来了——桌面图标闪了一下但App没起来。模型看到截图咦怎么还在桌面规则3说了页面没加载出来就先等等等三次还不行就重新进。于是模型决定等两秒 → 重新Launch。意外2搜索出来是拿铁模型搜了海盐咖啡结果列表第一个是海盐拿铁。模型看到截图嗯不是我要的。规则5说了找不到目标就滑动查找。于是它往下滑了一下找到了真正的海盐咖啡。意外3点加入购物车没反应模型找到商品了点加入购物车没反应。新截图来了还在商品详情页。规则14点击没生效 → 调一下位置重试。这次换了个坐标点成功了。最神奇的是这些纠错逻辑里没有一行代码去判断当前是不是出错了。代码只干了三件极简单的事模型崩了就结束任务总比乱操作强模型输出解析不了就将内容直接展示给用户操作执行报错了不终止循环给模型一次机会重来。真正的纠错逻辑全在Prompt规则里。规则2是进错页面就按返回规则3是加载不出来等三次规则5是找不到就滑一滑规则14是点不中就换位置。你把Prompt里的每条规则想象成传统代码里的一个if判断。只不过这些if-else是自然语言写的由模型自己判断当前情况匹配哪条。是不是一下就理解了核心就这些东西一个while循环。一个塞满规则的Prompt。一个不断追加的聊天记录。看完代码我最大的感受不是系统好复杂而是感觉设计很巧妙。厉害的不是代码是思路。提示词的巧妙设计把传统工程里那些需要if-else、状态判断、异常处理的活全用自然语言安排给大模型去做了。当然复杂产品肯定不止这些。场景复杂了任务队列、并行执行、记忆压缩、RAG检索这些东西都会往上堆。但核心骨架就是这三块万变不离其中。所以如果你也想搞一个自己的Agent找个AutoGLM这样的小项目把循环、Prompt、上下文这三样搞明白比啥都强。了解了这些简单的技术再去研究复杂的技术就容易多了。
