去年我接手一个内部项目任务听起来很简单让模型根据用户描述自动生成报告并发送到指定邮箱。我一开始的做法是写一个很长的 Prompt让它直接输出邮件正文我再调发送接口。结果并不意外——邮件内容偶尔缺附件偶尔格式错乱更多时候是模型回复一句“我已经帮你写好了”然后什么都不发生。问题不在模型不够聪明而在我只把它当成一个聊天窗口没有给它套上能干活的外壳。后来我把功能拆分成模块重构任务成功率大幅提升这才真正想明白大家反复讨论的 AI Agent核心价值不是“更会聊天”而是把大模型从“话痨”变成“执行者”。这篇内容会把 AI Agent 的核心模块拆开讲大模型底座、规划模块、记忆模块、工具调用以及它们如何串成一条“理解任务—拆解步骤—执行动作—观察结果—修正计划”的闭环。适合两类人看一类是刚接触 Agent、想搞清楚它和聊天机器人到底差在哪的初学者另一类是已经在用框架搭 Agent、但总在真实任务里翻车想补上落地方案和排查思路的开发者。我会把原理、实例和踩坑经验混在一起写尽量少讲空洞概念多给能直接抄的思路。1. 聊天窗口变成执行系统Agent 到底多做了哪三件事先扎一个问题同样面对“帮我把本周项目进度整理成周报并发给团队”这句话普通对话型 AI 和 Agent 的表现有什么不同普通 AI 会给你一份完整的周报文本然后你自己复制、保存、打开邮箱、粘贴、发送。Agent 则会尝试自己完成整套动作包括读取项目文档、汇总进度、生成周报、找到收件人、调用邮件接口发送最后告诉你“已发送”。这中间差的不是智能程度而是三件事能用工具、能记住状态、能自己决策下一步。1.1 会聊天只需要“预测下一个字”能干活需要“闭环反馈”大模型本质是一个语言模型你给它一串 token它预测下一串 token。聊天场景下你的问题进来模型回答完对话就结束即使多轮对话也不过是把历史记录堆在上下文里继续预测。整个过程是单向的模型不负责检查“回答完之后会发生什么”。干活不是这样。干活需要的是一个闭环模型输出意图 — 系统执行动作 — 系统把执行结果反馈回模型 — 模型判断结果是否符合预期 — 不符合就调整 — 直到任务完成。我打一个比方聊天机器人像一位只动嘴的顾问你说什么他给建议说完散场Agent 像一位接了工程项目的包工头他不仅要出方案还要盯进度、叫工人、检查材料、处理突发状况最后交付结果。这也是为什么很多人第一次搭 Agent 时会觉得“它怎么这么笨”——因为你在用聊天产品的使用习惯去衡量一个执行系统。聊天产品答错一句可以接受Agent 执行错一步可能整个流程就断了。所以 Agent 的第一设计原则不是“聪明”而是“可控”。1.2 从 ReAct 范式看 Agent 的最小骨架目前在应用层最主流的 Agent 工作范式是 ReActReasoning Acting推理与行动交替进行。这个名字是从一篇论文里来的但思想很简单模型先思考当前情况Reason然后决定调用什么动作Act系统执行动作后返回观察结果Observation模型再基于新观察继续思考循环往复。这个循环构成了 Agent 的最小骨架。你可以把一次完整的 Agent 运行想象成下棋每走一步棋调用工具之前都要判断局面观察结果然后决定下一步走法规划。没有这个循环模型只能说“我建议你怎么走”有了这个循环模型才能替你把棋子拿起来放下。在这个骨架之上后续所有模块——规划、记忆、工具、自省——本质上都是在加强这个循环的某个环节规划加强“决定下一步”记忆加强“记得之前的局面”工具加强“能让棋子真的动起来”。所以我倾向于把标题里“从会聊天到能干活”翻译成一句更直白的话从单次回答到闭环执行。理解了闭环后面的每个模块都顺理成章。2. 四大核心模块拆解让 Agent 真正能干活的地基既然 Agent 是一个闭环执行系统那它必须至少具备四个模块大模型底座充当决策内核、规划模块决定先做什么后做什么、记忆模块记住任务状态和长期知识、工具模块连接外部系统并执行动作。缺任何一个闭环都会断。2.1 大模型底座关键是“决策内核”而不只是“会聊天”很多教程把大模型底座描述成 Agent 的“大脑”这个说法没错但容易让人误解成“模型越聪明Agent 越强”。在实际工程里选底座模型更多看三件事指令遵循能力、是否支持结构化输出或函数调用、上下文长度是否足够容纳任务状态。指令遵循能力决定模型能不能老老实实按你规定的格式输出。很多场景下你不关心模型的话术好不好听只关心它输出的 JSON 合不合法。如果模型经常多输出一句解释、少输出一个字段下游工具调用立刻报错。结构化输出能力更直接——现在主流大模型服务都提供 Tool Calling工具调用或 Function Calling函数调用接口模型不是在文本里“说”我想调用某个工具而是返回一个结构化的调用请求包括工具名和参数。这项能力几乎是 Agent 的标配选型时建议优先考虑。另外有个容易被忽略的点模型输出的一致性和速度比“聪明”更影响 Agent 体验。同一套 Prompt模型这次返回 A 格式、下次返回 B 格式整个执行链路就很难稳定。我自己做选型时会在一个固定任务集上反复跑同一批 Prompt看模型的输出格式漂移率和误调用率而不是单看几个回答质量。2.2 规划模块把一个大任务拆成一串可执行的小步骤“把公司所有客户的合同到期时间整理出来提前提醒销售续约”——这种任务对模型来说太大了一次性让它干完结果通常不可控。规划模块的作用就是把这个模糊目标拆成一串有依赖顺序的小步骤先列出客户名单 → 读取每份合同的关键条款 → 提取到期日 → 与当前日期比较 → 生成提醒列表 → 推送给对应销售。规划通常有两种实现路线。第一种是单次规划任务开始前让模型一次性生成完整步骤列表后续按列表顺序执行。适合步骤明确、依赖清晰的场景优点是省 token、好排查缺点是任务中途一旦出意外后面的规划全作废。第二种是动态规划模型每执行一步都基于最新结果决定下一步。适合环境变化多的场景更灵活但循环次数多、成本高、也更容易失控。目前工程上比较稳妥的做法是两者结合先生成一个粗略计划执行中允许模型根据观察结果调整后续步骤同时给循环次数设硬上限防止它无限重试。规划结果的表达方式也值得注意。常见做法是让模型输出一个 JSON 数组每一项包含步骤 ID、动作类型、依赖的前置步骤、预期结果。这样做的好处是方便在系统里校验——比如步骤 C 依赖步骤 B 的结果B 还没执行完C 就不能放行。很多失败案例表面上是模型不够聪明实际是缺了这种流程控制导致计划与执行脱节。2.3 记忆模块短期工作台与长期档案柜的区别记忆是我认为被低估最多的模块。没有记忆的 Agent 就像一个人边干活边失忆他每执行一步都要重新阅读所有材料效率极低而且很容易遗忘早期信息。记忆至少分两层。短期记忆对应模型的上下文窗口保存当前任务相关的所有状态用户需求、已执行的步骤、工具返回的结果、遇到过的错误。这些信息要尽量精炼否则把几百条工具日志全塞进去很快就超出上下文长度还会冲淡关键信息。我在实践中会对工具返回做截断和摘要比如检索工具返回了 50 条记录我可能只保留前 10 条完整内容其余压缩成一行摘要文件内容太长时先交给摘要模型提炼再放回上下文。长期记忆则解决跨任务的知识沉淀问题用户偏好、历史决策、特定业务的规范。最常见的载体是向量数据库把历史经验切块向量化每次新任务开始时先做相似度检索把相关记忆放进上下文。换个方式理解短期记忆是办公桌上的便签长期记忆是书架上的资料每次开工前先查一下资料再把需要的部分摊到桌面上而不是把整个书架搬上桌。这个类比基本就是 Agent 记忆管理的设计哲学。QLoRA 之类的微调方案也能沉淀知识但成本和维护复杂度高对大多数场景不做首选。2.4 工具模块文本到操作的桥梁安全边界在这层工具模块是 Agent 区别于聊天机器人的直接原因。没有工具调用能力模型再聪明也只能输出文字有了工具它才能查数据库、发邮件、调接口、操作浏览器。工程上工具模块要做好三件事。第一给模型一张清晰的“工具说明书”。每个工具必须让模型知道三件事这个工具是干什么的、参数是什么、返回值是什么。主流做法是用 JSON Schema 描述工具参数模型按 Schema 生成调用请求系统负责校验参数类型不合法就拒绝并告知模型修改。第二收敛工具数量。我给 Agent 接工具的经验是单个任务链里的工具尽量控制在 5 到 8 个。工具太多模型选择错误的概率会显著上升——就像你给实习生一份 50 个按钮的操作台说明书他能按对的概率很低。第三决定哪些工具允许 Agent 自主执行哪些必须人工确认。我的原则是只读操作查询、检索、计算可以放权有副作用且不可回滚的操作发送邮件、删除文件、转账、下单默认要人工审批。这个边界如果不在架构里限制光靠 Prompt 约束迟早会出事。3. 从“听懂你的话”到“替你办成事”一次完整任务是怎么跑通的模块拆开看不难难的是组合起来。这一章我拿一个实际跑通过的功能举例把 Agent 处理一个真实任务的完整流程走一遍顺便解释每一步为什么要这么设计。任务背景来自我做过的一个内部演示项目用户上传一批简历文件Agent 根据职位要求筛选出候选人生成对比表格并把结果以邮件附件发送给 HR。听起来不复杂但它覆盖了 Agent 的完整循环。3.1 起步阶段把模糊需求改造成结构化任务用户输入“筛选出适合推荐给 HR 的候选人”这类含糊话术Agent 不能直接开干。它先要完成两件事澄清关键缺失信息以及将目标拆解为结构化描述。在这个例子里Agent 会反问用户目标职位是什么硬性要求有哪些需要排几名候选人进而构造一个任务对象包含输入文件列表、筛选条件、输出格式。我常用的方法是在初始 Prompt 里让模型先输出一段“任务理解”再输出“任务参数”两者都必须用 JSON 表示。任务理解是给系统做日志和审计用的任务参数则直接传给规划模块。这一步的作用是提前避免“做了半天方向错了”。很多 Agent 实现只注重最后一个步骤的回答质量忽略了起步阶段的对齐导致后面的动作全部建立在错误理解上。3.2 执行阶段规划—调用—观察—修正的循环规划模块拿到任务参数后会生成大致执行序列读取简历目录 → 解析每份简历文本 → 按硬性条件做初筛 → 对候选简历做匹配打分 → 生成对比表格 → 调用发送邮件工具。然后进入执行循环。每一步工具调用完成后系统会把结果返回给模型模型判断结果是预期中的吗如果不是是重试还是改用其他工具比如简历解析工具解析某份 PDF 失败模型可能会先重试一次失败后改调用 OCR 解析工具再不行就标记该文件为“解析失败”跳过并记录原因。这个“遇到问题再决策”的动态过程是 Agent 比固定脚本更灵活的核心也是容易失控的地方——所以每一轮循环都要带计数超过上限必须停下来让人工介入。3.3 收尾阶段结果校验比执行更重要任何任务执行到“工具返回成功”都不等于“任务真正成功”。邮件接口返回 200不代表邮件格式正确、附件齐全、收件人没弄错。所以我在收尾阶段会强制加一道校验步骤让 Agent 把执行结果与最初的任务要求逐项比对输出一份完成报告写明每个步骤完成状态和证据。还是用上面那个例子生成表格后校验模块会检查每个候选人的关键字段是否非空发送邮件前会检查附件路径是否存在、文件名是否匹配。对校验不过的结果Agent 要自己提出修正方案而不是强行给用户交差。这一步是 Agent 和聊天机器人最大的差异也是最需要工程投入的地方。4. 一上真实任务就翻车Agent 工程化里的几个深坑原理说了这么多接下来聊聊我在实际推进 Agent 落地时反复踩过的坑。这些坑不会出现在入门教程里但几乎每个真实项目都会遇到。4.1 评估标准不统一是第一个横在面前的问题聊天机器人好不好用大家凭感觉就能说个大概。Agent 行不行得看它在真实任务上的成功率但“成功”怎么定义邮件发出去算成功还是收件人正确打开附件算成功多步任务里前三步对了、第四步错了这算部分成功还是失败我目前采用的方法是多层分开评估每一子步骤单独打分步骤完成率整条任务按最终交付物判断任务成功率再用一个人工抽检比例兜底。不要试图设计一个万能指标把不同模块用同一把尺子量容易失真。关键是建立一套固定的评估任务集比如 20 个典型任务、50 个边界情况每次改动模块后都跑一遍对比前后差异。没有这套任务集你会陷入“这次改好了下次又坏了”的循环。4.2 模型不会主动承认失败它是“编结果”惯犯这是我在所有 Agent 项目里遇到最头疼的问题。当某个工具反复报错、计划无法推进时很多模型不会停下来告诉用户“我做不到”而是基于上下文猜测一个看似合理的结果继续执行。后果比报错严重得多——报错至少明确编结果是拿错误信息当真。我的对策有三层。第一在系统架构层面给每轮循环设中断条件超过 N 次失败、连续相同错误、步骤偏离预期超过阈值都强制进入人工评审流程。第二在 Prompt 层明确要求“当无法确认结果时必须输出 UNKNOWN不能编造”并且实际跑测确认模型真的遵守。第三在输出层增加事实性核查凡是工具返回值和最终交付物中数字、日期、金额等关键字段做一致性校验。这三层缺一不可。4.3 token 成本失控多轮循环是费用放大器Agent 和单次大模型调用的 token 消耗完全不是一个量级。一次多步骤任务可能要调用模型十几次每一次都要把上下文塞进去成本成倍放大。最夸张的一次我做一个简单的“收集资料并生成摘要”任务token 消耗是我预估的八倍原因是模型反复重读长文档还因为工具返回超长导致上下文爆掉。控制成本的经验一是精炼上下文每轮只保留必需信息工具返回一律先摘要再入上下文二是减少无效循环模型在处理多步骤任务时很多来回是因为规划不够清晰单次规划的质量上来了整体次数会明显下降三是做好预算熔断在代码里设置 token 上限超过上限直接停止并告知用户而不是任它无限烧钱。4.4 多个 Agent 协作时的死锁与权限纠缠做单 Agent 难做多 Agent 协作更难。我在一个项目中尝试过让“资料检索 Agent”和“写稿 Agent”协同完成长文整理结果两个 Agent 互相等待对方输出谁都不先干活最后靠超时强制重启才结束。多 Agent 方案严重依赖角色边界和交接协议。每个 Agent 的输入输出必须有明确的 Schema交接处要校验字段完整性和类型。理想情况下多 Agent 不应互相直接对话而应通过一个共享的“任务黑板”传递信息一个 Agent 把结果写到黑板上另一个 Agent 从黑板取自己需要的字段。这样职责清晰也方便后续追踪到底是谁产出错了。5. 自己搭一个最小可用 Agent可直接参考的骨架与经验有很多人会问入门 Agent 开发是直接用框架还是自己从零搭我的建议是初期自己从零搭一个最小版本跑通之后再引入框架。原因很简单框架封装了很多细节出了问题你很难判断是模型的问题、Prompt 的问题还是框架内部的问题。自己搭一个最小闭环每个模块都在掌控之中调试的时候思路才清楚。这里给一个能被直接参考的 Python 伪代码骨架涵盖了前几张讲到的循环结构。5.1 最小闭环的代码骨架单 Agent 版的“执行者”核心代码可以简化成下面这个循环它会串联大模型、工具和记忆。伪代码省略了具体的大模型 SDK 细节但逻辑结构是完整的。# 伪代码完整的最小 Agent 执行循环 def run_agent(user_request, tools, memory, max_steps10): # 1. 将记忆中的相关片段检索出来与用户请求组装成初始消息 context memory.retrieve(user_request) user_request # 2. 初始规划让模型输出任务拆解和第一步动作 plan_step call_llm(规划, context, task_schema) for step in range(max_steps): # 3. 让模型基于当前上下文决定下一步动作调用工具/给出最终答复 decision call_llm(决策, context, tool_schemas) if decision.action finish: # 4. 出现结束标志时做最终校验不通过则继续修正 if validate(decision.answer, user_request): return decision.answer else: context.append(系统最终交付物未通过校验请修正后重新输出。) continue # 5. 执行工具调用捕获错误信息 try: result dispatch_tool(decision.tool_name, decision.arguments) result summarize_tool_result(result) # 压缩工具返回防止上下文膨胀 except Exception as e: result f工具执行失败: {e} # 6. 将观察结果写回上下文同时写入短期记忆 context.append(f系统调用 {decision.tool_name}结果{result}) return 任务超时未完成已停止并保留中间状态。 if __name__ __main__: tools { read_file: read_file, search_db: search_db, send_email: send_email, } result run_agent(读取项目文档并生成周报邮件, tools, memory) print(result)这段骨架里的关键点有三个。一是每个循环都强制要求模型给出结构化决策而不是自由聊天二是工具返回必须压缩这是控制成本的核心三是有明确的 max_steps 上限防止死循环。你完全可以在这个骨架上逐步扩展加上长期记忆检索、增加人工审核队列、替换成多 Agent 协作调度器。5.2 工具设计经验宁可少而精不要多而全前面提到工具数量要收敛具体执行时我有一条硬标准每个工具都必须有可验证的输入输出 Schema并且工具功能之间尽量不重叠。比如你同时提供“搜索候选人”和“查询候选人信息”两个工具模型就会搞混它们的使用场景。我通常会在工具名里直接写清楚场景并加一句“本工具用于XX场景返回XX结构”让它变成给模型看的说明书。还有一个细节工具返回的内容一定带“结果可信度”或“字段完整性”标记。比如检索工具返回时标明“匹配到 5 条其中 2 条字段缺失”。让模型拿到信息时知道哪些能用、哪些不能用这会显著减少它拿着残缺数据硬编答案的概率。5.3 上线前必跑的测试集用 20 个任务替代拍脑袋调参我给 Agent 项目做验收时会准备三批测试数据正常场景10 个、边界场景5 个、异常场景5 个。正常场景验证主流程跑得通边界场景验证极端输入不会崩比如空文件、超大文件、重复数据异常场景验证工具报错时 Agent 能不能优雅降级比如数据库连不上、接口超时。每次调整 Prompt 或核心模块都把这三批数据重新跑一遍。这个做法能避免一个经常出现的尴尬情况你修好了 A 问题结果 B 问题又冒出来了。Agent 是高度耦合的系统模块间影响很难凭感觉预估只能靠回归测试兜底。最后再分享一个关于 Prompt 的体会很多人以为写了 Agent 就不用管 Prompt 了实际上 Prompt 恰恰是 Agent 项目里最需要反复打磨的部分。区别在于给聊天机器人的 Prompt 追求“说得漂亮”给 Agent 的 Prompt 追求“说得清楚”。我在实践中总结出一套适合 Agent 的 Prompt 写法不要问模型“你打算怎么做”而是明确告诉它“你现在有哪些工具、每个工具的参数约束、什么情况下必须停止、输出格式是什么”同时把每个工具的使用边界写进工具描述里而不是统一塞在系统 Prompt 中。这样做的好处是模型做决策时随时能看到对应工具的规则不会被大段无关指令干扰。另外不管 Prompt 写得多么完善都要保留“人工兜底”的思想。Agent 再成熟也只是把重复劳动自动化而不是把责任外包。关键操作永远设置确认环节重要任务永远保留日志这不仅是工程要求也是做事的基本判断。把这几条做好你搭的 Agent 才算真正从“会聊天”走向了“能干活”。