上个月我需要一个中秋节祝福网页。我对着一款聊天式AI说给我一段带月亮和兔子的HTML页面。它几秒钟内输出了一段完整代码CSS效果很漂亮也能直接复制到编辑器里用。但我接下来做的事情是手动保存文件、打开浏览器预览、逐个替换文案、再想办法部署上去。那一瞬间我意识到一个问题——大模型很聪明但它并没有帮我“干活”真正干活的是我。这个场景正好是普通聊天AI和AI Agent之间那条分界线的缩影。这几年大家都在聊AI Agent。我在手机和代码开发两个场景感受最深。手机上Agent能读屏幕、跨App操作代码里Agent能自己跑测试、修报错、补文档。这篇文章不是讲概念而是把我从“聊天”到“干活”这个转变过程中的理解、搭建方法、踩坑记录和边界判断都写出来。适合已经用过ChatGPT或类似大模型产品、想让AI真正处理工作流的人也适合想从0到1搭一个Agent练手的开发者。1. AI Agent 不是“更聪明的聊天框”从给答案到对结果负责如果只看产品界面聊天框和Agent几乎没区别。你输入文字它输出文字。但背后的目标完全不同聊天机器人的目标是“生成一个合理的回复”AI Agent的目标是“让外部世界的某个状态发生改变”。这个差别决定了后面所有的技术选型和工程取舍。拿做饭来打比方。你问“红烧肉怎么做”聊天机器人给你一份菜谱任务在文本结束那一刻就完成了。但一个会干活的Agent会自己去买菜、洗锅、切肉、开火、加调料最后端一盘成品到你面前并且对“菜好不好吃”负责。前者是“告诉你怎么做”后者是“替你把事情做完”。我自己的评估标准也很简单别听它回答得漂亮不漂亮只看外部状态有没有被正确修改。文件有没有创建、测试有没有通过、日历有没有加事件、短信有没有发出去——这些才是Agent的工作成果。如果模型输出了一段精彩文字但什么都没改变那它本质上还是个聊天框。1.1 聊天机器人只负责“说”Agent必须负责“做完”很多大模型产品都叫“助手”但其中大部分还是停留在“说”的层面。你问一个Excel问题它告诉你用dropna()删空行。这有用但接下来打开Jupyter、写代码、执行、看结果、处理报错全都回到你身上。Agent的差别在于它不仅能告诉你用dropna()还能实际调用一个Python环境把代码跑掉再把运行结果拿给你看跑挂了还能自己看报错、改代码、重跑一次。这个差别不是锦上添花而是质变。一旦模型被允许调用工具它就从“建议者”变成了“执行者”。当然执行者会做错所以Agent系统必须有验证机制。这也是为什么代码场景最适合Agent落地——代码的验证闭环太清晰了跑没跑过测试、有没有报错机器说了算不需要人类主观判断。1.2 Agent 的四件套模型、规划、工具、记忆一个能真正干活的Agent通常由四部分组成。第一模型。它是大脑负责理解任务、推理和决策。第二规划器。复杂任务要拆解成子任务比如“整理这个项目代码”会被拆成“读取目录结构”“分析关键文件”“生成报告”几步。第三工具集。这是Agent的“手”常见的有代码执行器、文件读写、搜索引擎、数据库查询、命令行工具。第四记忆。短期记忆是当前任务的对话上下文长期记忆可以存用户的偏好和历史经验让Agent在后续任务中不需要重复交代背景。这四件套凑齐Agent才能形成“思考—行动—观察—再思考”的闭环。别把Agent想象成一个神秘的新模型它本质上还是那个大模型只是在外面套了一圈“能调用工具、能看工具结果、能记住上下文”的工程系统。1.3 “工具调用”是临界点为什么现在才轮到Agent爆发其实“让模型调用工具”的思路并不新以前也流行过把大模型输出解析成命令但效果很差因为模型经常输出不规范的格式程序根本看不懂。真正的转折点是Function Calling这类机制的出现模型不是输出自然语言命令而是输出结构化的JSON比如{name: run_python, arguments: {code: ...}}。程序看到这个JSON后就调用对应的函数把返回值塞回对话里。这一步让模型第一次有了可靠的“手”。另外两件事也起了关键作用。一个是上下文窗口变大Agent在长链路执行中能记住前面几步做过什么另一个是多模态能力成熟模型能直接读截图这让手机端Agent有了“眼睛”。所以Agent不是凭空冒出来的而是语言模型能力、工具协议、上下文长度、多模态感知几样东西在工程上终于攒齐了。2. 手机上的 Agent屏幕理解、跨App操作和那个折腾人的“快捷指令”手机是Agent普通人最容易感知到的落地场景。原因很简单大家的待办事项都分散在各个App里验证码在短信里航班信息在航旅软件里日程在日历里转账在银行App里。过去想联动这些信息要么靠系统级自动化工具手工配规则要么干脆手动复制粘贴。Agent出现后第一步改变就是你可以用自然语言描述意图它自动生成操作步骤。不过我先把话说在前面手机上的全自动Agent远没有代码Agent成熟。因为手机的App UI不是为机器人设计的屏幕是给人看的不是给程序看的。真正做手机Agent的团队需要先解决“看懂屏幕”和“操作屏幕”两个问题再接住系统权限带来的隐私风险。2.1 手机Agent的“眼睛”和“手”“眼睛”来自两条路径。一条是无障碍服务系统会把当前屏幕的控件树暴露出来Agent能拿到按钮文字、输入框内容、列表项这些结构化信息另一条是截图加多模态模型直接把屏幕截图丢给模型让它识别当前页面在说什么、有哪些可操作元素。两条路各有优劣无障碍信息更准但很多App不友好截图方案更通用但模型可能看错。“手”则是通过系统辅助功能模拟点击、滑动、输入文字。Agent拿到当前页面信息后会输出一个操作序列比如“点击屏幕坐标为(320, 540)的区域”“输入文本123456”“点击完成”。听起来很直接实际工程里坑很多最典型的就是App一更新按钮位置变了坐标型操作立刻失效。所以我做这一类功能时更倾向于让Agent描述“语义动作”点击名称为“确认支付”的按钮而不是写死坐标。把执行层和UI坐标解耦维护成本能低很多。2.2 低成本方案把“快捷指令”变成Agent的执行器很多人以为手机Agent必须手机厂商开放系统能力才能用其实不完全是。普通用户用“快捷指令”加大模型API就能做一个半自动Agent。我拿“从短信里提取日程并创建提醒”举例。操作步骤大概是这样的先建一个快捷指令接收短信文本作为输入然后用“获取URL内容”动作POST到你的API地址把短信文本和一个解析Prompt一起发过去。Prompt我一般写得很具体“你是一个信息提取器。请从短信内容中提取事件摘要、时间、地点并输出JSON格式为{summary: ..., datetime: ..., location: ...}。” API返回JSON后快捷指令再调用“添加新提醒事项”或“创建日历事件”动作一个“短信转日程”的半自动Agent就成型了。这个方案最大的价值在于它把传统快捷指令最难写的“非结构化文本解析规则”交给了模型。以前这种需求得写正则、写分支判断现在只要一段Prompt。但有个红线我必须提醒别把银行卡验证码、身份证号这类敏感信息直接丢给任何第三方API。如果你的场景涉及隐私数据要么选择本地部署的小模型要么自建API并且明确数据不会被留存。2.3 手机Agent不稳定的根源与权限红线手机Agent不稳定根源不只是模型能力而是整个链条都很脆弱。App界面不规则、登录状态失效、动态权限弹窗、系统后台杀进程哪一环断了任务就失败。我自己测过一个自动查询快递的流程前两次跑通了第三次App更新后按钮位置变了整个操作序列报废。后来我调整方案能调公开接口的就不去点屏幕能读剪贴板的就不去截屏把“直接操作UI”当作最后手段。权限红线是另一个必须强调的问题。Agent能读剪贴板不代表它应该自动读取所有敏感信息能调用发送动作不代表它可以不经确认就把消息发出去。我的原则是“读”可以自动“写”必须确认。尤其是涉及对外发送、付款、删除、修改重要资料这几类操作无论如何都要在Agent执行前插入一个人工确认节点。这里的人工确认不是流程繁琐而是给错误一个刹车。真出过事的人都知道宁可多一步确认也不想补救不可逆的后果。3. 代码场景里的 Agent从“能写代码”到“能debug代码”如果说手机Agent还在半自动阶段那代码场景就是Agent最成熟的战场。原因前面提过代码任务的验证闭环天然清晰跑没跑过测试、编译过不过、Lint干不干净都是机器判定的客观结果。模型写代码可以出错但Agent可以通过执行、观察、修改、再执行来纠错这就是“实习程序员”式的工作方式。我自己现在写代码的流程已经变了。以前是“自己写—自己编译—看报错—自己改”现在是“我描述需求—Agent搭框架—Agent跑测试—我看结果提修改意见”。人还是最终负责人但重复劳动明显少了。3.1 代码Agent的完整能力地图一个能真正干活的代码Agent能力至少包括五块。第一代码生成与重构。根据自然语言描述生成实现或者对现有代码做小范围修改这已经是基本功。第二仓库理解。它需要能读取项目目录、函数定义、调用关系而不是只看你当前打开的那一个文件。第三命令执行。能跑测试、执行Lint、运行构建脚本、提交Git让每一步验证真正发生。第四报错诊断。读取编译器或解释器的报错信息定位到文件和行号提出修复方案并应用。第五文档撰写。基于代码库生成README、接口说明、注释这件事特别适合让Agent干。这五项能力组合起来Agent就不再是“写代码片段”的工具而是一个能在仓库里来回折腾的助手。但你要明白它依然像刚入职三天的实习生速度快、热情高、容易在细节上翻车。所以你的角色不是“完全放手”而是“给任务、给环境、给验收标准然后review它的产出”。3.2 最小可用代码AgentFunction Calling 30行版很多人觉得搭Agent一定要上重型框架其实不是。我用原生Function Calling写过一个最小循环几十行代码就能跑通“模型决定调用工具—执行工具—把结果喂回模型—模型继续决策”的闭环。import json import subprocess import tempfile import os from openai import OpenAI # 也可以是任意兼容接口的SDK client OpenAI() TOOLS [ { type: function, function: { name: run_python, description: 执行Python代码并返回stdout/stderr, parameters: { type: object, properties: { code: { type: string, description: 要执行的Python代码 } }, required: [code] } } } ] def execute_code(code): with tempfile.NamedTemporaryFile(w, suffix.py, deleteFalse) as f: f.write(code) path f.name try: r subprocess.run([python, path], capture_outputTrue, textTrue, timeout10) return r.stdout r.stderr finally: os.unlink(path) def agent_loop(user_msg, max_steps5): messages [{role: user, content: user_msg}] for _ in range(max_steps): resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS ) msg resp.choices[0].message messages.append(msg) if not msg.tool_calls: return msg.content # 模型认为任务完成 for tc in msg.tool_calls: args json.loads(tc.function.arguments) result execute_code(args[code]) messages.append({ role: tool, tool_call_id: tc.id, content: result }) return 到达最大步数任务未完成或需要人工确认这个例子把Agent循环的核心逻辑都露出来了模型看到用户任务后决定要不要调用run_python如果调用就返回一个带参数的tool_call程序执行代码并把结果以“tool消息”的形式放回对话模型看到结果后再决定下一步。直到某次响应里不再包含tool_calls循环结束。注意我用了tempfile和subprocess来隔离执行但生产环境里绝对不能直接这样干尤其不能在宿主机上跑未信任的代码。要用容器、无网络沙箱或者云函数来做隔离否则Agent的一次误操作就可能导致整个开发机出问题。3.3 实战记录让Agent从零完成一个“快速排序测试说明文档”小任务我最近让一个Agent独立完成过这样的任务“写一个Python快速排序函数补三个单元测试执行测试并用中文写一段算法说明。”我把这段话发出去然后开着日志看它跑。第一个动作Agent生成了一段快速排序代码并附带了三个简单的断言。但执行之后代码报错TypeError: NoneType object is not iterable。问题很典型它第一版函数里忘记return了排序是在原列表上做最后却没有返回结果。接着Agent读取报错定位到函数末尾补上return arr重新执行测试通过。最后它把快速排序的原理、平均时间复杂度、不稳定排序的特性写了一段说明任务收尾。这个过程中最打动我的不是它一次写对而是它能从报错中自行修复并验证。它真的“干活”了而不是给我一段代码让我自己调。另一个例子我也试过让它写一个Python双均线量化策略的回测脚本。它很快生成了DataFrame、信号列、收益计算和回测结果但后来我检查发现它完全没有考虑交易成本属于很常见的“看起来对但业务假设太简单”的问题。所以我让它在文档里标注假设并补上手续费参数。Agent能做但必须有人把关业务逻辑。4. 从0到1搭建自己的 Agent选型、护栏、排错三板斧如果你想自己动手搭一个Agent我的建议是不要一开始就上重型框架。我自己就吃过这个亏第一次学Agent时直接用了封装度很高的框架结果所有抽象层都看不懂出了问题都不知道该查哪里。后来把代码退回到原生Function Calling一行行看消息循环才真正理解了Agent的工作方式。搭Agent的路径很清楚先让一个工具跑通闭环再加第二个、第三个工具等工具数量多到处理不过来时再考虑用框架做编排。很多人一上来就设计“多个Agent协作、一个主持一个写代码一个审查”结果连单Agent循环都没跑通。先把地基打好比什么架构都重要。4.1 选型别一上来就上框架我整理了一个简单的对照表帮你判断该走哪条路线。方案适合场景维护成本上手难度原生Function Calling工具少、流程短、刚学习低低轻量Agent框架工具3-5个、需要记忆与编排中中多Agent编排框架任务复杂、角色分工明确高高判断标准不是“哪个流行用哪个”而是“你的任务复杂度配不配得上这套系统”。如果你只是要做“从文本里提取信息并创建提醒”原生Function Calling就够了。如果你要让Agent在代码仓库里自主完成任务至少需要文件读取、代码执行、搜索、提交等工具那可以考虑框架。而多Agent编排说实话很多场景是被制造出来的需求单Agent多加几个工具往往就能解决。4.2 护栏设计工具白名单、审批节点、步数上限Agent和聊天框最大的区别是它会主动操作外部世界所以安全设计绝对不能省。我用四个机制来控制风险。第一工具白名单。Agent只能调用你预先注册过的函数不能让它随便执行任意命令。比如代码Agent需要执行Shell命令我会把它限制在特定命令集合里而不是给一个通用Shell工具。第二审批节点。对删除、覆盖文件、发送消息、付款这类高风险操作Agent应该输出一个特殊标记请求人工确认暂停循环等待用户同意后再继续。第三步数上限和Token上限。防的不是模型故意捣乱而是它陷入无意义循环反复调用同一个工具。上限一到强制结束并提示人工接管。第四沙箱隔离。代码类操作放到容器或临时目录里日志单独记录事后能审计。注意不管Agent能力多强都不建议把“对外发送”和“不可逆删除”做成全自动。把审批节点放在Agent循环里哪怕多几次人工点击也比事后追不回来强得多。4.3 排错三板斧看轨迹、验参数、管上下文Agent跑起来之后一定会遇到各种翻车场景。我排错基本靠三板斧。第一斧看轨迹。Agent是带状态的系统只看最终结果根本不知道它为什么走到这一步。所以从第一版起就要记录完整的tool_calls和tool_result日志。遇到问题先回放它在第几步调了什么工具、传了什么参数、工具返回了什么。很多时候问题就藏在某一步的参数错了。第二斧验参数。模型经常输出非法JSON或者输出的参数类型不符合工具定义。我以前吃过亏Agent连续三次调用同一个工具都报参数错误然后陷入重试循环。后来我加了一层宽松的参数解析器先把模型输出转成结构化对象再用工具要求的类型做校验失败了就提示模型“参数不合法请重新生成”效果立刻好转。第三斧管上下文。上下文越长模型越容易在长链路里丢失早期信息甚至会重复执行已经做过的步骤。我的处理方式是不把所有历史都堆进下一次请求而是“保留最近几轮完整消息把早期过程压缩成摘要”。这样既不会丢失关键决策信息又能控制Token消耗。上下文管理不是可选项是Agent长期稳定运行的必需品。5. Agent 接管路上的边界哪些事放心交哪些必须留一手说到“接管”目前更准确的说法其实是“局部接管”。在代码生成、日程提取、信息整理这些有明确结果、有验证手段的领域Agent确实已经在干活。但把它放到所有场景里风险会迅速放大。我在实践里的判断标准就一句话任务的“风险可逆性”决定自动化程度。如果出错之后能轻松恢复比如生成一段文档、跑一次单元测试、整理一份会议纪要那大可放心让Agent全自动。如果出错之后代价很高比如付款、删表、发合同、修改生产环境配置那就必须留人工确认节点。Agent不是不能做这些事而是你必须在它前面加上“人审”这道闸门。5.1 适合Agent的活 vs 不适合Agent的活我按实际经验列个清单。适合交给Agent的重复且规则明确的代码任务写测试、跑Lint、修特定格式的报错。数据整理类工作从非结构化文本里提取结构化信息比如短信提取日程。内容初稿邮件回复、代码注释、周报初稿。有明确验证闭环的流程跑完能自动判断对错。不适合交给Agent的高风险且不可逆的操作付款、删除数据库、真正推送生产环境。强隐私场景把病历、身份证、银行信息传给第三方模型。需要责任背书的决策比如医疗诊断建议、法律意见、合同终审。对幻觉零容忍的文本Agent生成的内容再顺滑也一定要有人核验关键事实。注意我这里的“不适合”不是指Agent技术上做不到而是风险收益比不划算。技术能做到和应该让它做是两回事。5.2 我的建议人机协作的“最少干预原则”我现在的工作流不是“全自动”而是“最少干预”。Agent能自己跑完的步骤就让它跑但在几个关键节点我会刻意加人工确认。Agent只有在任务描述里明确写了“不确定时就停下来问人”才允许执行下一步。我宁可它慢一点也不想它带着幻觉一路狂奔。新搭建的Agent我还会先让它在小范围、低风险的环境里试跑几轮盯住它的日志确认稳定之后才扩大权限。这跟带新人是一样的不能第一天就把生产环境的钥匙交出去先让它处理几个不痛不痒的任务摸清脾气再说。这些年我最大的感受是AI Agent并没有真的“接管”我的手机和代码它更像一个手脚不太协调但学习能力很强的实习生。你需要给它清晰的任务、一个安全的工作台、一套可验证的质量标准然后盯着它把活干完。真正负责任的还是你。