上一篇我们聊了怎么把开发环境跑通、怎么把第一个Agent Demo搭起来。但很多朋友在跑通Demo之后马上就卡住了——不是不会写代码是不知道下一步该怎么写。同一个任务用传统开发的思路去拆写出来一堆if-else调用大模型的流水线跑起来勉强能用但灵活性差换一个场景就废。问题出在哪出在思维方式还停在传统软件开发那一套。这篇就是专门聊“思维跃迁”的。它是整个Agent开发入门系列里我认为最值得反复看的一篇。因为框架、API、语法这些都是有迹可循的唯有思维方式是你带着过去十年编程经验里最根深蒂固的那些习惯需要主动地、刻意地去扭转的。这篇适合两类人一类是有传统开发背景、准备认真做Agent应用的工程师另一类是已经在用Agent框架、但总觉得写出来的东西“不像Agent”的初学者。看完你会明白问题不是你的代码能力而是你脑子里的那套“确定性思维”在打架。1. 传统开发思维为什么困住你确定性代码与概率性推理的底层差异1.1 确定性代码vs概率性推理为什么调试思路要变我们做传统软件开发这么多年所有工程实践——单元测试、异常捕获、状态管理、回归验证——都建立在一个核心假设上**代码的行为是确定的。**给定同样的输入代码必然产生同样的输出。这个假设是整个软件工程大厦的地基。你可以穷举分支、写断言、做覆盖率统计因为每一步都是可预期的。Agent开发完全打破了这条地基。底层的大语言模型本质上是概率系统同样的Prompt两次调用给出的结果可能不同甚至有时候好的离谱有时候蠢的意外。这个差异不是bug是你必须接受和利用的“特性”。这个差异带来的连锁反应几乎影响了开发流程的每一个环节调试方式变了传统代码出问题你可以打断点、看变量、单步执行很快定位到某一行。Agent出问题你没法打断点——模型的“内部状态”是一个黑盒你能看到的只有输入和输出。你只能通过调整Prompt、调整工具返回的信息、调整Agent的决策边界来“间接”控制行为。测试方式变了你没法用断言来验证Agent行为。比如你让Agent写一封邮件你没法断言“邮件内容必须包含某个词”来证明它写得好。因为同一封邮件换个语气、换个结构可能都是好的。错误处理方式变了传统代码的错误是异常你可以catch住然后走备用分支。Agent的错误往往是“它以为自己是对的”——你没法catch一个模型不知道自己做错了的情况。你只能通过设计反馈循环和校验机制来兜底。我印象很深的是团队里一个同学第一次写Agent应用花了两天时间试图让某个Prompt的输出“稳定复现”反复调温度参数、加各种约束词最后还是不行。后来他跟我说感觉自己在跟一个没法讲道理的系统搏斗。我说对你现在的任务不是控制它而是学会和它协作。这就是最底层的思维跃迁从“控制一个确定性系统”变成“引导一个概率性系统”。1.2 从“写死逻辑”到“写清目标”让模型自己选路径传统开发的思路是把任务的每一步都安排好。比如做一个客服系统传统代码会这样写判断用户输入的关键词命中物流规则就调物流接口命中退货规则就走退货流程全都匹配不上就返回默认话术。每个分支你都写死了用户行为一旦超出你的预期系统就处理不了。Agent的开发思路不一样。你要做的不是罗列每一步而是把目标、边界、可用资源说清楚然后让模型自己去选路径。举个对比传统需求描述当用户输入包含“物流”或“快递”等关键词时调用订单查询接口并把返回的物流状态拼接成回复文案当用户输入包含“退货”时转入退货流程。Agent需求描述你是一个电商客服助手。你的目标是为用户解答与订单相关的问题。你可以使用订单查询工具来获取真实的物流与订单状态。当用户的问题超出你的能力范围时礼貌说明并引导用户联系人工客服。注意你只能基于工具返回的真实数据作答不能编造订单信息。看出差别了吗传统写法里你是在告诉程序“每一步怎么做”Agent写法里你是在告诉模型“这个任务是什么、边界在哪、什么不能做、有什么工具可以用”。至于用户问“我的东西怎么还没到”模型自己会判断应该调用订单查询工具、自己决定回复的礼貌措辞、自己决定要不要追问订单号。这个转变本质上是你从一个“事无巨细的管理者”变成了“定方向、划边界、配资源的负责人”。你的注意力从“如何实现”转移到“如何定义”。实操心得判断你是否完成了这个转变有一个很简单的自测方法——把你写的Agent的Prompt删掉然后问自己如果我把这段Prompt发给一个聪明但完全不了解这个业务的同事他能照着完成这个任务吗如果答案是很模糊说明你的目标定义还没到位。好的Prompt本身就是一份“能把活儿交出去”的岗位说明书。2. 站在巨人肩膀上Agent开发框架替你解决的核心问题2.1 框架到底帮你干了哪些活别重复造轮子很多有开发背景的同学面对Agent框架第一反应是抵触这不就是封装了一层API调用吗我自己写也行。这个想法我太熟悉了——我第一眼看到框架时的想法跟你一模一样。但等你真的从零手写过一个带会话管理、工具调用、上下文裁剪的Agent系统之后你才会明白框架的价值。一个成熟的Agent开发框架通常已经帮你解决了这么几类脏活累活框架替你做好的事你手写时要面对的问题模型接入与切换各家模型的API规范不同、鉴权方式不同封装一次要折腾半天多轮会话与上下文管理历史消息怎么存、上下文超长怎么办、什么时候该做摘要压缩工具调用的循环处理模型说要调工具时怎么去执行、怎么把结果回填给模型、出错怎么办结构化输出解析模型返回乱七八糟的文本怎么稳定地提取出字段记忆机制短期记忆、长期记忆、向量检索从零实现的工作量远超想象可观测性与日志Agent跑的过程中token消耗多少、调了哪些工具、哪一步开始跑偏的这些机制不是天才拍脑袋设计出来的是社区的开发者们在无数个生产事故里踩坑踩出来的。你从零实现既没有必要也不划算。这就像你不会自己去写一套HTTP协议再在上面做Web开发一样。站在巨人肩膀上说的是你不需要把巨人走过的路再走一遍你需要做的是站上去看得更远。2.2 思维重心转移从“怎么实现”到“怎么定义”用框架的另一个好处是它会倒逼你完成思维重心的转移。一旦你把模型接入、会话管理、工具循环这些底层机制交给了框架你手上剩下来的事情就变得非常聚焦定义目标这个Agent为谁服务、解决什么问题、做到什么程度算合格。配置工具给Agent提供哪些外部能力每个工具的参数怎么设计哪些工具不能让Agent直接访问。设计反馈Agent的输出谁来把关、用什么标准判断好坏、失败之后怎么办。评估迭代怎么衡量Agent的整体表现改动之后如何保证不退步。你会发现这些事没有一件是“写代码”层面的但每一件都比写代码更决定Agent的最终质量。同样的框架同样的模型有人做出来的Agent像个聪明的助手有人做出来的像个又贵又笨的乱弹琴机器——差别就在于前期的定义和设计。我见过太多人拿到框架之后第一件事就是急着写业务逻辑写完之后发现Agent经常答非所问。回头排查才发现问题根本不在代码在角色定义——连系统Prompt都是随手粘了一段话术没想过要交代边界、要定义什么叫“好的回答”。框架的价值不只是“帮你省事”更重要的是它把那些不该你操心的细节拿走了逼你把精力放在真正重要的事情上。如果你用了一个框架还是天天在业务逻辑里手搓上下文拼接、自己管理历史会话说明你的思维还停在“封装API”的阶段没有真正切到Agent开发模式。3. 从工具人到驾驭者Agent开发必须完成的三个思维跃迁3.1 跃迁一从“写函数”到“定义角色”传统代码的组织单元是函数、类、接口。你调用一个函数它的行为是固定的传什么参数它干什么活一丝不苟。而Agent的组织单元是角色。角色不是一个函数而是一套“行为准则能力边界反馈机制”。什么是角色它包含这几个要素身份与职责你是谁、你在什么场景下工作、你的核心目标是什么。可用工具你有哪些工具可以用、什么情况下应该调用什么工具。行为边界你绝对不能做什么、遇到能力范围外的事情怎么处理。输出规范你以什么格式输出、需要达到什么样的质量标准。写角色定义和写函数完全是两码事。我给你一个例子。假设我做一个订单客服Agent你是一名电商平台的客服助手服务对象是平台的购物用户。 你的核心职责是解答用户关于订单状态、物流进度、退换货政策的查询。 你有两个工具可用查询订单接口、查询物流接口。只有在拿到用户的下单手机号和订单号之后才可以调用信息不全时必须先向用户索要。 你必须基于工具返回的真实数据作答严禁编造订单信息、物流状态或政策条款。 如果用户的问题超出上述范围比如询问商品质量对比、投诉卖家请告知用户你无法处理并引导联系人工客服。 回答语气友好简洁回复长度不超过150字。这段描述你看下来像什么像一份岗位说明书。它没有规定“第一步做什么、第二步做什么”它规定的是“你是什么人、你负责什么、你的边界在哪、你有哪些资源、做到什么标准算好”。剩下的——用户问“我的包裹到哪了”模型自己知道要先要订单号再调查询工具然后把真实状态组织成回复。实操心得写角色定义时我见过最大的坑是把Prompt写成“小作文”。洋洋洒洒几百字背景描述、废话、鼓励的话一大堆真正的约束条件淹没在文字里。模型抓不住重点效果自然差。好的角色定义每条规则都能独立成立、逻辑不重叠、没有废话。写完之后逐条朗读一遍——如果哪句话删掉不影响行为就删掉它。注意事项不要试图用一个超大规模的角色定义解决所有问题。Agent开发里有个反直觉的经验把复杂的任务拆成多个角色每个角色只负责一件事彼此通过工具或消息协作远比一个巨型Prompt管用。就像公司不会让一个人既当前台又当技术总监还要管财务——角色职责越聚焦行为越稳定。3.2 跃迁二从“单次调用”到“自我修正循环”传统开发里一个函数被调用正常情况下只会执行一次返回值就是这个函数的最终结果。Agent开发完全不同——它的核心优势之一是模型可以在一次任务中多次调用自己或工具根据中间结果不断修正直到达到目标。这种“自我修正循环”已经沉淀成几种常见模式推理-行动循环模型先思考“当前情况是什么、我该做什么”然后调用工具或产生动作再根据工具返回的结果继续思考、继续行动。这也是当前多数Agent框架里默认的运行模式。反思-修正循环模型先生成一版结果然后扮演“评审”角色对照原始需求检查这版结果哪里不到位再据此生成修正后的版本。规划-执行模式模型先拿到任务后先拆解成一个步骤清单规划再逐步执行。每个步骤执行完可以根据实际情况修订后续计划。我举个例子说明为什么这个循环很重要。假设你要写一个“会议纪要整理Agent”输入是一段长达几十分钟的会议记录。如果用传统思路你调一次模型“帮我总结一下这段会议”生成的内容很可能遗漏某个决定或某个负责人的行动项。但如果用自我修正循环第一轮让模型先通读全文生成一份初步的结构化摘要。 第二轮让模型对照原始记录逐项检查初步摘要中是否遗漏了决定、负责人、时间节点。 第三轮让模型基于检查结果补全遗漏项输出最终摘要。跑下来你会发现第二轮“对照检查”这个动作能把单次生成的质量提升一个档次。原因很简单——单次生成时模型相当于一边阅读一边写摘要注意力会被长文本稀释而分开“生成-检查-修正”之后每一步的目标更聚焦模型更容易发现第一版遗漏的细节。实操心得自我修正要不要开、开几轮要有节制。简单任务比如给一句话做情感分类开反思循环纯粹是浪费Token和时间。判断标准就一条**这个任务有没有一个“模型自己可以判断好坏”的质量维度**如果有比如“摘要是否包含所有行动项”“代码是否能通过编译”反思循环就有效如果没有比如“这篇文案写得够不够有感染力”模型自己判断也是瞎猜那就别指望反思能带来稳定提升。3.3 跃迁三从“单元测试”到“评估集”传统开发里你给函数写单元测试断言输入输出。Agent开发没法这么做——你没法断言一段自然语言生成的合理性。所以测试Agent的方式需要换成一套全新的思维评估集。评估集是什么说白了就是你准备一批有代表性的输入定义好“什么程度算好的输出”然后跑一遍Agent看它在这些输入上的表现是否达标。具体有三种做法规则评估用脚本检查生成结果是否符合格式要求、是否包含必要字段。比如要求输出必须是JSON就可以用json.loads判断。这是成本最低的评估方式适合结构化较强的场景。模型评估准备一个评判标准rubric用另一个大模型给Agent的输出打分或判定通过与否。这种方式适合主观性较强的评估维度比如“回答是否准确”“语气是否友好”。人工评估人工去看Agent在测试集上的表现。真正让评估集发挥威力的是“坏例驱动迭代”。具体做法是把Agent做错的输入收集起来每一条都沉淀成评估用例然后针对这些坏例去调整Prompt、工具配置、边界设计——每次改完把整个评估集重新跑一遍确保修好了旧问题同时没有把好的能力改坏。这个思路与传统开发的回归测试非常像但它针对的不是“某段代码逻辑”而是Agent的整体行为。实操心得维护评估集比调Prompt重要十倍。我自己的习惯是Agent上线后用户反馈的问题凡是复现出来的全部丢进评估集。几个月下来这个评估集会变成团队最值钱的东西——它是你所有迭代的“安全网”。很多人调Prompt全凭感觉今天觉得这里不对加一句话明天觉得那里不好删一句话改来改去也不知道是变好了还是变坏了。有了评估集你就能用数据回答这个问题。4. 实操对比同一个任务用两种脑回路写差距在哪里4.1 一个具体的任务设定为了让你更直观看到思维差异我给一个具体的任务做一个“会议行动项提取Agent”。输入是一段会议录音转写的文本输出是一份按负责人归类的行动清单包含行动内容、负责人、截止时间。这个任务不大不小但足够用它来展示两种脑回路的差别。4.2 传统脑回路写法把LLM当函数用一个还停留在线性思维的人可能会这样设计第一步调模型对会议文本做分段摘要。 第二步调模型从摘要中提取所有“行动类”句子。 第三步调模型对每个句子做命名实体识别抽取负责人。 第四步用代码按负责人分组。 第五步调模型按分组结果生成最终清单。这个流程看着好像没问题但跑起来就是一场灾难。第一每一环节都调一次模型Token消耗大、延迟叠加一次任务可能要好几十秒成本高得离谱。第二任何一个环节效果不好它会直接传导到最终输出——如果摘要环节漏了一句话后面的提取环节永远找不到那个行动项。第三整个流程是写死的假设会议记录里有人说话特别口语化实体识别环节可能反复出错但Agent自己根本意识不到。这种写法的本质是“把LLM当函数用”——每一个调用都是一个独立的黑盒黑盒之间没有任何反馈和修正。它没有自主性没有自我调整能力只是把传统流水线里的“函数”换成了“模型调用”。我自己早期做Agent就犯过这个错。写出来的东西像一条串了一堆模型调用的水管任何一个环节漏水都全盘崩溃。后来我才意识到这不是Agent这只是“用AI包装的流程”。4.3 Agent脑回路写法定义目标让Agent自己走用Agent的脑回路这个任务应该是这样的你是会议行动项提取助手。输入是一段会议转写文本输出是一份行动清单。 你需要从会议文本中找出所有关于行动安排的描述包括行动内容、负责人、截止时间。 输出为Markdown表格按负责人分组。表头格式负责人 | 行动内容 | 截止时间。 注意事项 - 如果原文没有明确提到截止时间请在截止时间列填写“未指定”。 - 如果某句话说的是已经完成的事项不要列入行动清单。 - 如果有人名被提及但不确定是否为负责人不要猜测统一标记为“负责人待确认”。看到区别了吗这段Prompt没有规定“先做摘要、再提取、再分组”这些步骤。它只定义了目标提取行动项、输出格式Markdown表格、边界不列已完成事项、不猜测负责人。至于怎么找、怎么判断、怎么归类全交给模型自己。模型在执行时会怎么做它会自己通读全文自己判断哪些是行动项自己决定负责人字段缺失时怎么处理甚至可能在输出前自己检查一遍有没有遗漏。它不是按一条写死的流水线走而是像一个真人助理一样根据输入的具体内容动态调整策略。而且Agent写法还有一个巨大优势**模型可以在“找不全”的时候自己补位。**比如传统流水线第一步摘要就漏掉的细节在Agent写法里不会发生——因为Agent是整段理解文本不存在“摘要→提取”的中间环节少一步就少一个信息损失点。我实际跑了对比同样的输入文本Agent写法的输出完整度比流水线写法高出不少尤其在一些模糊表达、口语碎片较多的会议记录上Agent的自适应能力优势非常明显。而后者的最大问题在于它压根不知道自己遗漏了什么——因为没有反馈机制。4.4 使用反馈切换脑回路后效果如何把同一个任务从流水线改成Agent脑回路之后我的感受是写代码的工作量其实更少了但思考和定义的时间更多了。你不再需要花心思去设计“每步怎么调用模型、提示词怎么拼接、结果在代码里怎么流转”你要做的是把任务本身想透——目标是什么、边界是什么、什么算合格、遇到异常情况怎么处理。这个转变一开始会让人很不适应因为你会觉得“我什么都没写它真的能自己搞定吗”但跑几轮之后你会发现模型确实能搞定。它不仅搞定了还会在你划定的边界里想出你原来没设计过但确实有效的处理方式。所以如果你现在写的Agent本质上还是一串“模型调用if-else分支”我建议你停下来重新只用一段角色定义输出规范看能不能完成同样的任务。这个练习能帮助你快速完成从“函数思维”到“Agent思维”的转变。5. 从传统开发转向Agent开发四个高频思维误区与避坑清单5.1 误区一什么都想让模型自己想思维跃迁到另一个极端什么都交给模型反而是新手最容易掉进的坑。模型确实有推理能力但它不是万能的。像数学计算、数据校验、权限控制、固定格式转换这类对确定性要求极高的事情用代码处理是几毫秒的事放进模型里反而容易出错成本还高。正确的做法是“混合架构”能确定性计算的用代码做需要理解和生成的交给模型。一个Agent的内部完全可以有代码逻辑来判断工具返回结果是否合法只不过判断结果会作为上下文喂给模型让模型据此决定下一步行动。这个观念要摆正模型是Agent的“大脑”但Agent的身体里还长着很多“肌肉”和“神经”该用肌肉的地方别指望大脑。5.2 误区二Prompt越长越好第二个高频误区是“话痨式Prompt”。总觉得约束写多一点模型就能更听话。事实上Prompt超过一定长度后新加的词句会让模型的注意力分散甚至覆盖掉更早、更关键的指令。你会发现一个特别长的Prompt模型经常抓不住你最在意的那个核心约束。正确思路是“做减法”。先写核心角色定义和关键边界然后逐条审视这句话真的会影响行为吗还是只是心理安慰没有实际作用的句子删掉。另外与其在Prompt里堆砌“不许做这个、不许做那个”的禁止清单不如花心思把“你只做这一件事”的正向边界说清楚。心理学上这叫“替代性行为设计”——告诉它该做什么比告诉它不该做什么更有效这个规律对大模型同样成立。5.3 误区三忽视可观测性Agent跑飞了你得看得见它是怎么飞的。传统开发你可以打日志Agent开发同理但很多人忽略这一点。Agent的行为链是“思考→调用工具→接收结果→再思考”任何一个环节偏离预期都会导致最终结果崩坏。如果你没有日志你就永远只能看到输入和最终输出中间的过程对你来说就是一个黑洞。实践上至少要做三件事记录Agent每一轮的关键决策和工具调用记录统计每轮任务的Token消耗和耗时在Agent连续多次重试或进入死循环时触发告警。框架一般都有现成的可用性观测能力用起来就好。不要等到线上出事故才发现自己什么都看不到。5.4 误区四把模型输出当最终结果最后一个误区是把模型生成的文本直接当作最终交付物。模型的输出只是一个“草稿”你需要有程序化的校验、格式化、兜底逻辑。比如提取出来的行动清单应该用代码校验一遍负责人字段是否格式正确给用户展示的回复应该经过敏感信息过滤涉及资金、订单状态这种高风险的场景必须有人工确认环节。“模型生成代码把关”——这个组合才是安全的Agent架构。模型负责生成代码负责校验和兜底。这个思维转变很重要传统开发里最后的结果是由代码决定的Agent开发里最后的结果应该是“模型生成再由代码和规则把关之后”才真正成立的。6. 最后给你一张思维跃迁自检卡我的实操笔记6.1 一张自检卡判断你思维是否真正切换我把这个系列反复讲的思维跃迁浓缩成一张自检卡。你每写一个Agent都可以对照着问一遍自检问题如果答案是...我能用一句话说清这个Agent为谁解决什么问题吗说不清说明目标定义还没到位我知道这个Agent绝对不能碰什么吗没想过说明边界设计缺失我给Agent配齐了完成任务需要的工具吗没配说明你还在让它裸奔我能说清“什么情况算它做得好”吗说不清说明你还没有评估标准我记录了它做错的案例并用来驱动下一次调整吗没记说明迭代纯靠感觉它的失败路径工具报错、连续重试有人看得到吗看不到说明可观测性缺失这六条如果都能答得上来你的思维基本上已经完成了跃迁剩下的就是手熟的问题了。6.2 我的一个笨办法写代码前先做“纸面推演”最后分享一个我一直在用、看着有点笨但极其有效的训练方法拿到Agent任务后先不写代码、不写Prompt拿张纸用自然语言把Agent的行为推演一遍。推演格式很随意就是类似用户输入X → Agent会怎么理解 → 它会调用哪个工具 → 工具返回什么 → 它会如何组织回复 → 如果遇到Y这种情况怎么办 → 如果它连续失败怎么办。这个“纸面推演”看着原始但它能逼你在写任何代码之前就把目标、边界、工具、失败路径都想清楚。我踩过的几次较大的坑几乎都是因为跳过了这个步骤直接上手写代码写到一半发现Agent的行为根本不符合预期回头还得重新设计。而每次老老实实先推演一遍后面的开发流畅度都会好很多。把这个习惯保持一段时间你会发现自己面对一个新任务时脑子里第一个冒出来的想法不再是“这个功能怎么实现”而是“这个任务让一个聪明的人来做我需要给他什么交代”——到这一步思维跃迁就真正完成了。下一篇我们再具体讲框架里工具调用的进阶用法以及多Agent协作时的编排思路。
