★ FEATURED ARTICLE 最近在各技术社区里聊 Agent 的内容越来越多了但坦白讲大部分讨论都停留在概念层面越聊越玄。作为一直在一线做对话系统和自动化工具的开发者我被问得最多的一个问题是我手上的 ChatBot 已经能回答用户问题了它离 Agent 到底还差多远这个问题特别实际也特别容易被回避掉。这篇内容我不打算讲宏大叙事就从工程实践角度用一个具体任务把两者拆开看ChatBot 和 Agent 在处理同一件事时到底有什么本质差别那个被反复提到的“循环”到底是什么、为什么要循环、循环里跑的是什么。最后我还会给出一个可以把普通 ChatBot 改造成最小可用 Agent 的实操方案以及我踩过的一些坑。无论你是在做内部效率工具还是在尝试给产品加上自动化能力这篇文章应该都能给你一些能直接落地的参考。1. 核心差异拆解回答一个问题和完成一个任务是两码事1.1 一个例子看懂差距“改期会议”任务的两种表现先看一个非常日常的场景。用户说“帮我把周五下午的产品评审会议改到周一早上十点顺便通知所有参会人再订一间能容纳十人的会议室。”如果面对的是一个 ChatBot典型的处理方式是什么它会基于对话模型的理解能力给你生成一段听起来很合理的回复大意是“好的你可以打开日历应用找到周五下午的会议把它移到周一上午十点修改参会人然后使用会议室预订功能……”有些做得好的对话系统可能会继续追问“你想通知哪些人”或者“你要预订哪个楼层的会议室”但仅此而已。它给你的是指导方案、是参考信息、是文档级别的答案。你照着它说的去做动作还得你自己完成。而 Agent 面对同样一句话行为模式是完全不同的。它会开始“干活”先调起日历接口查询周五那个会议是否存在确认参会人名单判断周一上午十点是不是有空档如果时间冲突要么自动往后顺延要么停下来问你然后调用邮件接口给所有参会人发改期通知再调用会议室预订接口查看并锁定一个十人间最后回来向你汇报“会议已改期到周一 10:008 位参会人已通知3 号会议室已预订成功这是新的会议邀请链接。”看到差别没有同样是那一段用户请求ChatBot 输出的是“内容”Agent 交付的是“结果”。我在做内部工具时最直观的一点感受是当任务复杂度越高、涉及的步骤越多ChatBot 式的回答就越显得无能为力。因为它没有手脚也没有眼睛它只是生在真空中帮你组织语言。即便它背后的模型再聪明只要没有连接外部系统它就永远停留在“纸上谈兵”的水平。1.2 ChatBot 在做“参考”Agent 在做“执行”更难分辨的一点是现在不少 ChatBot 已经能联网搜索、能调插件了那它们和 Agent 的边界到底怎么划我的理解是这样的如果调用工具只是单轮交互的一部分比如用户问“今天北京天气怎么样”ChatBot 搜索一下再回答那它本质上还是一个 ChatBot。工具在这个链路里是辅助它“组织答案”的素材来源回答完这句话交互就结束了。整个过程是线性的输入 → 检索/调用 → 生成回复 → 结束。Agent 不一样的地方在于它把工具调用作为“动作”内化到了任务推进的链条里。工具返回的结果不是为了修饰回复而是它决定下一步动作的依据。而且这个“下一步”是真真切切发生在真实世界里的操作不是又一段文字建议。它是在执行不是在参考。这个区别在代码层面也能看出来。ChatBot 的典型实现是一个大函数generate_response(user_input, context) - text。它天然没有“执行后产生副作用”的概念。而 Agent 的核心实现是一个带状态的主循环里面有分支、有权衡、有执行、有对执行结果的观察最后收敛到一个结果。这个差异决定了你不论给 ChatBot 套多漂亮的产品外壳都不可能让它自动帮你处理一封邮件或者跑一段数据清洗流程。1.3 Agent 的三个硬性门槛状态、工具、反馈从工程设计角度看我习惯把一个系统从 ChatBot 升级到 Agent 看作跨过三道门槛。这三个条件缺一不可。第一道门槛是状态管理。ChatBot 只需要“记住我们刚才聊了什么”这是一种上下文级别的记忆。但 Agent 需要的是“记住整个任务目前推进到哪一步、哪些子任务已完成、哪些结果被观察到了”这是任务级别的状态。没有状态循环无法进行。你可以想象一下如果 Agent 调用完会议室接口之后不记得自己已经查过哪个时间段、已经订过哪个房间它下一步就没法做任何决策。第二道门槛是工具接口。Agent 必须能够改变外部世界的状态。它至少要能读取外部系统信息最好还能写入、修改、触发。邮件接口、日历接口、数据库操作、文件系统、爬虫脚本这些都属于工具。而且工具不能只是被硬编码调用它需要以模型能理解的方式暴露出来让模型自己决定什么时候用。第三道门槛是反馈回路。每次工具调用之后Agent 要能拿到结构化的结果并把结果重新放回到模型中参与下一步推理。如果外部系统返回了错误Agent 要能理解错误并调整策略。这个“行动 → 观察 → 思考 → 再行动”的回路就是我后面要讲的“循环”。如果没有反馈回路Agent 就只是一个安装了插件列表的问答系统。这里可以做一个更直观的对比维度ChatBotAgent交互模式一问一答答完即止任务下发 过程反馈 结果交付对上下文的理解记住对话历史用于生成更自然的回复维护任务状态记录每一步执行结果与外部系统的关系可读取信息但不承担动作后果主动调用工具并承担执行结果错误处理能力生成的回答错了就错了无纠错机制根据观察结果循环调整直到收敛交付物一段文本建议一个被完成的操作或系统结果2. 从“漏斗”到“闭环”为什么 Agent 需要一个循环2.1 一步生成的模型天然缺乏“纠错能力”聊到这里核心问题就浮现出来了Agent 为什么要做成一个循环它就不能像 ChatBot 一样用户给一句指令它直接生成一串已经做好的操作吗答案在于当前这一步生成式模型的能力模型是“一次前向推理”。模型看到输入直接生成输出这个过程没有中途停下来检查自己干得怎么样的机制。你可以让它生成一段代码但它在生成之前并不知道这段代码跑起来会不会报错也不知道依赖项版本对不对。你可以让它生成一段 SQL但它并不知道这个表里到底有没有这个字段。如果任务只是“根据需求生成一段文本”没问题一次生成就够了。但任务一旦涉及外部世界的操作不确定性就急剧上升。外部接口可能返回意想不到的数据格式时间可能冲突权限可能不足网络可能抖动。在所有这些不确定性的阴影里如果你不让系统具备“看一眼结果再决定下一步”的能力那它本质上仍然是盲目的。很多从 ChatBot 转 Agent 的开发者最容易犯的错误就是试图让模型“一步到位”地完成所有操作一次性规划好所有步骤一次性传递好所有参数然后一次性执行。这也是为什么很多人做出来的 Agent 效果不稳定——因为真实世界根本不按你规划好的剧本走。一次生成注定只能应对确定性的世界而真实任务充满意外。2.2 Agent 循环的四要素感知、决策、行动、观察Loop 的本质就是模仿一个理性人完成复杂任务的过程。拆开来看一个最基本的 Agent 循环包含四个环节。感知对应的是获取当前状态和用户目标。这是输入环节。任务开始时要明确目标是什么、边界是什么、可用资源是什么。在每一步循环里感知还意味着把工具执行结果拉回到工作记忆里。决策对应的是模型在“当前状态”下回答“下一步该做什么”的问题。这里的动作可能是调用一个工具、生成一段中间分析、向用户提一个澄清问题或者宣布任务完成。行动即真正执行决策。如果是调用工具那么这一步会对外部系统产生真实影响如果是向用户提问那么这一步就是把人纳入循环。行动环节也是 Agent 区别于纯思考系统的地方。观察对应的是把行动后的结果反馈给系统。这里的关键是结果要结构化要让模型容易“读懂”。比如返回一个 JSON 格式的状态、错误码、字段列表。如果你直接丢一段混沌的报错堆栈给模型它会很难做出有效的下一步决策。这四个环节不断轮转就形成了闭环。你再回头对比一下 ChatBot 的漏斗式结构“输入 → 输出 → 结束”。你会发现漏斗是直通式的没有回来找补的可能性而闭环每一步都带着上一个行动的反馈重新进入决策层。用通俗的话讲ChatBot 是“你说一句它说一句”Agent 是“你交代一件事它自己绕圈子把事办成”。2.3 循环不是无限跑终止条件比循环本身更重要循环听起来简单但设计不好就会变成灾难。最常见的翻车现场就是 Agent 在一个错误里无限重试或者反复在两个工具之间来回横跳烧掉大量 Token最后什么问题也没解决。我见过一个朋友做的小 demo模型在调用 A 工具报错后又调 B 工具B 工具依赖 A 工具的结果于是又调 A 工具如此循环往复几分钟内调用了上百次接口。所以设计循环时最需要想清楚的其实是终止条件。终止条件至少要有三层一是成功终止即任务目标的完成条件是什么这个条件必须是可判定的比如“会议室预订成功返回了订单号”“邮件队列已清空”二是失败终止即在什么情况下你承认任务无法继续比如“预定接口连续报错三次”“用户提供了互相冲突的信息”三是强制终止即最大步数上限。这个上限是从工程安全角度设置的保险栓哪怕任务还没完成到了上限就必须停下来汇报当前进度把控制权交还给用户。我用下来最舒服的做法是把强制终止做得“软”一点到了最大步数后不只是简单报错而是让模型把当前的执行日志、已完成动作、未完成原因整理成一份结构化报告交给用户。这样即便任务没完成用户也能理解卡在了哪一步下一步该怎么介入。比起光秃秃抛一个 Timeout 异常体验好很多。3. 动手改造把一个 ChatBot 变成最小可用 Agent3.1 改造前先盘点你的场景值得加循环吗在动手写代码之前我强烈建议你先做一个判断你手头这个任务到底适不适合改造成 Agent。并不是所有对话场景都需要变成 Agent很多时候加个循环反而是画蛇添足。我判断一个场景适不适合通常看四个条件。第一任务是否包含多个步骤——如果用户问“今天的天气怎么样”一步搜索就完事了别折腾。第二任务是否需要跨系统操作——比如查数据在 A 系统、写结果在 B 系统这种跨系统编排正是 Agent 的主场。第三任务的中间结果是否需要人工参与判断——如果需要Agent 可以处理但要把“人工确认”设计进循环里。第四任务失败的成本有多大——如果一次性操作不可逆且风险高比如自动删除文件、批量发送邮件那更要仔细设计权限边界而不是无脑全自动。如果四个条件大部分不满足我建议你安心把产品做好 ChatBot 就足够了。Agent 不是趋势的遮羞布不适合的场景硬上只会暴露出一堆工程质量问题。3.2 关键模块一目标与状态模型如果你确定场景合适第一步不是写循环而是先定义清楚状态模型。我给一个最小的结构做参考。状态里至少要包含用户的目标描述、任务当前执行的阶段、已经执行过的步骤列表、每一步的观察结果、当前待确认的临时信息。我用 JSON 来组织它{ goal: 把周五下午的产品评审会议改到周一 10:00并通知所有参会人预订一个 10 人间, status: in_progress, steps: [ { action: query_calendar_event, args: {event_keyword: 产品评审, date: 周五}, result: {event_id: evt_12345, participants: [ax.com, bx.com]} } ], current_focus: 需要确认新时间是否与现有日程冲突, task_memory: [] }状态模型的意义在于它让循环里的每一步都能回溯也让模型在决策时能清楚地看到“我执行过什么、结果是什么、现在停顿在哪里”。如果你把状态模型设计得足够好很多后续问题——比如模型重复执行同一操作、上下文丢失、无法生成可解释的进度报告——都能在源头缓解。一个关键经验是状态里的 user 目标要写清楚steps 列表应该持续追加而不是重写。原因很简单模型需要看到完整的执行轨迹才能做出一致性决策。如果你只保留最后一步模型几乎是必然忘记前面做过什么。3.3 关键模块二工具层的设计与封装下一步是给 Agent 接上工具。当前主流大模型都支持类似“工具调用”的机制可以让模型在生成回复时输出一个结构化的“调用意图”而不是自然语言。你作为开发者负责实现真正执行这些工具的函数并把它们的描述喂给模型。关于工具层我自己在设计时有一个比较实用的套路。每个工具我提供一个名字动词前缀 对象比如query_calendar_event、send_email_notice一段详细的语义描述一个 JSON Schema 格式的参数定义以及一个执行入口。描述极其重要因为模型是靠你的描述来理解工具“什么时候该用、怎么用”的。描述越精确模型选错工具的概率越低。比如一个查会议室的工具描述里我会写清楚“根据人数、时间段查询可用会议室返回会议室编号和容量”。还有一个点值得注意对写操作和读操作的工具应当做明确区分。读操作工具相对安全可以放开让 Agent 自由调用写操作工具发送邮件、修改日程、删除数据我建议在代码层面单独标注执行前经过一层确认逻辑。这不是技术限制而是产品责任感的问题。任何一个自动系统在没有充分确认的前提下自动发出邮件或者删除数据都可能在真实场景里造成不可挽回的损失。3.4 关键模块三主循环的伪代码与实现要点当状态模型和工具层都就位之后我们就可以进入核心部分主循环。我用一个简化过的伪代码展示它的骨架这里面不涉及具体技术栈或者某个厂商的 API你可以很容易地把它映射到你自己常用的语言和框架上。# 最小可用 Agent 主循环伪代码 def run_agent(user_request: str): state initialize_state(user_request) while not should_stop(state): decision llm_decide_next_action( system_prompt你是任务执行助手根据状态决定下一步, statestate, available_toolstool_descriptions ) if decision.type call_tool: result execute_tool(decision.tool_name, decision.args) state.steps.append({ action: decision.tool_name, args: decision.args, result: result }) state.current_focus f等待处理 {decision.tool_name} 的返回结果 elif decision.type ask_user: user_answer input([需要确认] decision.question) state.task_memory.append({ question: decision.question, user_answer: user_answer }) elif decision.type finish: break return summarize_execution(state)这份代码只有二三十行但里面隐藏了几个我反复调整过的关键细节。第一个细节是decision必须包含 type 字段。明确分出调用工具、询问用户、完成任务这三种类别。这比直接用自然语言让模型“想怎么说就怎么说”要稳定得多。第二个细节是每次工具执行结果不要给模型“打包成一句转述”直接把结构化结果塞进 steps 里。让模型看到原始数据它才能做出正确判断。第三个细节是should_stop函数内部要同时检查成功条件、失败条件和最大步数。我用的时候会把最大步数设成一个可配置参数调试阶段设小一点比如 5-8 步跑出稳定效果后再放大。3.5 关键模块四记忆与上下文的取舍最后一个模块我单独拿出来说因为很多人在这上面栽过跟头。主循环每跑一步上下文里就会多一段工具结果。几步之后上下文就膨胀得很厉害。我见过有人跑一个稍微复杂的任务上下文从最初的两千字膨胀到上万字。这既拖慢响应速度又烧钱还可能导致模型在长上下文里“迷失重点”。这里我比较推荐的做法是分级组织记忆。完整的执行日志留在外部存储里比如 write-back 到数据库或者 JSON 文件。真正塞给模型去决策的上下文是压缩过的目标摘要 最近一两轮重要操作和结果 当前待处理焦点。这相当于给模型一份“工作简报”而不是把所有会议记录都甩到它面前。具体操作上可以在每个循环轮次开始时对旧日志做一个小结。你可以让模型把 1 到 3 步里的操作行为、返回结果、关键数据用三五行概括出来放到task_memory里下一轮决策时直接复用这段小结。这样既保留了长期信息又避免上下文增长失控。另外如果某个工具返回了超长数据不要让模型把数据全文读进脑子而是先做一层截断或者聚合。例如查询参会人名单时如果名单很长让工具端先汇总成“共 12 人其中内部 8 人、外部 4 人”细节再按需查询。把这个“预处理逻辑”写在工具实现里会让 Agent 的决策轻松很多。4. 我在实操中踩过的坑和排查方法4.1 死循环、空转、任务不收敛这个坑我敢说是所有做 Agent 的人都遇到过的第一名。表现形态五花八门模型反复调用同一个工具每次参数有一丁点儿区别模型在两个工具之间来回横跳甚至模型明明已经把任务完成了一大半却舍不得进入 finish 分支还要继续“检查”和“确认”。我排查这类问题的经验首先是看决策日志。把每一步模型输出的 decision 完整保存下来跑完任务后用脚本拉出来看。如果发现模型在某个工具名附近反复横跳大概率是工具描述里语义不清晰或者没有明确告诉模型“这个操作完成后的成功标志是什么”。如果模型迟迟不进入 finish很可能是成功判定条件没有被明确写进系统提示里。我现在的做法是在每个工具调用之后由程序自动判断“是否已经满足任务完成条件”一旦满足直接把 finish 动作注入到下一轮决策里不再把选择权交给模型。还有一个硬办法是给每个工具加幂等性。同一个操作重复执行不能造成副作用。会议预订这种还好像发送邮件这种操作如果不加幂等控制Agent 空转几轮用户的收件箱就被塞爆了。4.2 工具返回结果“污染”了核心上下文第二个高频问题是工具返回的结果占据了太多上下文空间导致模型丧失了对用户主目标的关注。我曾经测试过一个任务让 Agent 从一个大文件里读取多段数据去完成汇总。结果它每读一小段就把整段内容塞进上下文几轮之后模型开始画蛇添足地解释文件内容完全忘了用户想要的是什么汇总。这个问题在 3.5 节已经聊过解法这里再补充一个实践中比较有用的技巧在塞给模型的上下文里把用户原始目标放在最前面并且每轮循环都要重复一遍。做这个处理的理由其实很朴素——模型处理长上下文时注意力会分散把最核心的目标放在信息流的开端能显著降低它跑偏的概率。有段时间我的 Agent 行为反常我发现竟然是系统提示和状态结构排布的问题把用户目标调整到首个文本块后问题立刻缓解了很多。4.3 模型权力越大越要加护栏第三类问题是安全边界相关的。在给 Agent 接上真实写操作工具后权限控制如果做得太粗风险就会戏剧性地放大。我见过一个演示程序模型在调用删除接口时参数传错差点把不该删的数据抹掉。我的习惯是给所有写操作工具加上一个统一的“确认层”。在执行前要求 Agent 必须输出一个拟操作预览比如“即将发送邮件主题 xxx收件人 xxx正文摘要 xxx”然后由用户点击确认再真正执行。确实这会牺牲一部分“全自动”的体验但换来的是可控性。尤其在做企业级内部工具时这个确认层几乎是必须的。没有哪个管理者愿意用一个动不动就自己乱发邮件的系统。在确认层的实现上我通常用状态机去管理一旦工具被标记为 “needs_confirmation”Agent 就算已经决定调用也要先走一个生成确认预览的中间步骤。在这个过程中模型不拥有直接执行该工具的权限。这比在工具内部做二次确认更加灵活因为你可以让多种高风险工具共用一套确认机制。5. 场景选择和成本评估Agent 不是万能钥匙5.1 适合上 Agent 的场景长什么样在聊了这么多技术改造之后我想把镜头拉远一点聊聊场景选择。不是所有功能都值得改造成 Agent我见过最失败的案例是把“和用户闲聊”这种场景硬做成 Agent结果用户问一句“周末去哪玩”系统非要调用天气、地图、点评好几个接口用了几十秒最后给个还不如直接问搜索的答案。我认为适合上 Agent 的场景通常具备这样几个共同特征。首先是步骤固定但需要协调的系统多比如一个审批流程要查人事系统、查日程系统、发通知。其次是需要根据中间结果频繁调整方案的比如跨平台数据迁移会有字段映射冲突、格式不兼容等意外。第三是用户期望拿到的是“结果”而不是“建议”的场景比如“把这份报表每天早上九点发给相关团队”而不是“我该怎么发报表”。反过来纯知识问答、开放式的头脑风暴、快速闲聊这些场景ChatBot 反而更适合速度更快成本更低用户体验也更轻。5.2 算一笔账循环带来的成本与收益做 Agent 的决策者如果只看功能不看成本很容易在第一个月就被账单惊醒。我必须提醒你一个现实同样的用户请求ChatBot 可能只需要一次模型调用而 Agent 一个完整循环下来平均会调用 8 到 20 次模型接口。这还是优化过的情况如果 Agent 中途走错路、反复重试调用次数很可能冲到 40 次以上。Token 消耗量不是线性增长是近似乘法式增长。我习惯用一个简单的公式估算成本单次任务总 Token 数 ≈ 状态与工具描述的固定开销 每次决策的 Token 数 × 循环步数 每次工具返回的结果 Token 数 × 工具调用次数。固定开销基本恒定真正的大头在后两项。如果你的场景是低频高价值的自动化操作比如每周跑一次的数据同步报表这个成本完全可接受。但如果你要做一个用户高频使用、单次价值并不高的消费级功能这个成本会非常可观你要想清楚谁来承担。收益端也要会算。Agent 的价值不是“回答得更好”而是省去用户手动执行的时间。如果用户平均手动完成那个任务要 10 分钟而 Agent 通过 30 秒的循环就完成了那么这个产品价值足够明显。如果用户手动做只要 20 秒Agent 却要 20 秒再加上偶尔出错返工那这个价值就很弱。5.3 我给新手的实操建议最后分享一点我自己的经验。如果你正准备做一个 Agent我最真诚的建议是别急着上复杂的 Multi-Agent 框架、规划器、记忆向量库这些东西。先选一个你每天都会做、步骤固定、但需要跨两三个系统的小任务把它改造成一个单循环的最小 Agent。跑通了你会对“循环”这两个字有完全不同的体感尤其是那种模型第一次通过自动调用工具解决了一个真实问题的瞬间你会觉得前面的所有繁琐设计都值了。跑通第一个之后再慢慢往里面加复杂度。让工具变得更丰富、让终止条件更智能、让决策上下文更精确。到这一步你已经不是在跟风谈论 Agent而是真正在使用 Agent 思维解决工程问题了。后面的多 Agent 协作、人机协同、异步任务调度本质上都是在帮你更好地管理这一个又一个循环而已。
阅读完成 · 觉得有帮助？
