给孩子点点STAR吧求求了https://github.com/Liujingze11/thinking-is-all-you-need.git0 前言最近我在用LangGraph 搭建一个 Agent目标是让它根据用户任务自动生成机器人可执行的任务指令。一开始我以为这会是一个典型的 Prompt Engineering 问题。于是我不断调提示词加规则、加限制、加示例、加反例、加格式要求。结果很残酷效果并没有明显提升。更奇怪的是我甚至让另一个 Agent 去辅助分析错误让它解释为什么生成错了、应该怎么改结果也没有从根本上提高准确率。它能解释问题但下一次还是可能犯类似的错。最后真正有效的方式反而是最原始的方式和人类对话反复辩论指出问题修改逻辑。这让我开始意识到一个问题也许不是 Agent 不知道规则而是它缺少一个正确的思考过程。1 问题不在“提示词不够强”而在“思考顺序不对”机器人任务指令生成不是普通文本生成。它不像写一段文案只要语义通顺就可以。它更像是在生成一张流程图里面有节点、有分支、有条件判断、有跳转、有返回。任何一个小错误都会导致整个任务不可执行。这些问题靠“请你严格遵守规则”是很难解决的。因为 Agent 在生成指令时本质上是在边想边写。或者按照自己的思考逻辑进行推理。它不是先完整规划一遍再严谨输出。很多时候它是在生成过程中临时决定下一个节点是什么。于是看起来每一步都合理但连起来就可能出错。这就像让一个人一边走迷宫一边画地图。走着走着他可能忘了某个分支也可能把两条路画到了一起。2 灵感来自一次“Superpower 式”的头脑风暴真正的转折点发生在一个很普通的中午。我一边吃饭一边还在想这个问题为什么我已经给 Agent 加了这么多规则它还是会在复杂任务里出错后来我突然想到我平时和 Superpower 做头脑风暴时效果之所以好并不是因为它一上来就给我一个最终答案而是它会先和我一起拆问题、找矛盾、推演可能性再慢慢逼近一个更好的方案。这给了我一个启发为什么不让 Agent 也像头脑风暴一样先完成一轮结构化思考再生成最终结果不是简单地告诉它“请仔细思考”。因为“仔细思考”本身太抽象了模型并不知道到底该怎么仔细。真正有用的是给它一套明确的思考路径先理解任务再拆解结构再推演分支最后校验结果。这其实很像人类做复杂决策的过程。我们在执行一个动作之前看起来好像是直接行动但大脑其实已经在潜意识里完成了很多判断目标是什么、当前条件是否满足、可能会遇到什么风险、下一步应该怎么走、如果失败该如何处理。很多时候所谓“聪明”并不是答案本身更强而是思考路径更正确。于是我决定不再继续堆提示词而是给 Agent 增加一套前置思考流程。我想验证一件事如果模型自己不会稳定地产生正确的思考过程那我能不能把这个过程显式设计出来3 我做的不是增加规则而是给 Agent 设计一套思考流程后来我意识到单纯给模型加限制是没有意义的。因为限制只是在告诉它“不要犯错”但没有告诉它“应该如何避免犯错”。于是我换了一种方式不再要求 Agent 直接生成最终结果而是让它在输出之前先经过一套固定的思考流程。这套流程大概分成四步。3.1 第一步是先还原任务结构。也就是说Agent 不能一上来就写结果而是要先理解任务本身用户真正想完成什么任务中有哪些关键对象它们之间是什么顺序、关系和依赖哪些信息是明确的哪些信息需要推断哪些地方存在风险这一步的目标不是生成答案而是先把问题“看清楚”。3.2 第二步是把任务拆成可执行的中间计划。复杂任务最怕模型直接跳到最终答案。因为一旦它在中间漏掉某个环节最终输出看起来可能还很完整但实际逻辑已经错了。所以我要求 Agent 先生成一个中间规划把任务拆成一个个可检查的步骤。每一步都要说明为什么需要它它依赖什么它会导致什么结果。这相当于让 Agent 先画出一张“草图”而不是直接交付成品。3.3 第三步是沿着可能路径进行推演。很多错误不是在单个步骤里出现的而是在多个步骤串起来之后才暴露出来。所以我让 Agent 不只是列计划还要模拟执行这套计划从起点开始沿着不同可能性往下走检查每一条路径是否合理是否会断掉是否会走向错误的结果。这一步本质上是在让模型做“预演”。就像人类在行动前会在脑子里先过一遍如果这样会怎样如果不行怎么办下一步接哪里3.4 第四步是用规则反向校验结果。最后Agent 不能直接相信自己的规划而是要回过头来逐条检查有没有遗漏有没有重复有没有冲突有没有看似合理但实际上不成立的地方如果发现问题就回到前面的规划里修正而不是带着错误进入最终输出。这一步非常重要。因为模型最大的问题之一就是它经常会自信地输出一个错误答案。而校验流程的意义就是让它在交付之前先对自己的结果做一次结构化审查。4 结果准确率明显提升这套方法加进去之后效果立刻不一样了。不是因为我写了更多限制条件而是因为我改变了 Agent 的工作方式。以前它是看到任务 → 直接生成结果 → 出错后解释原因。现在它变成了看到任务 → 提取路径 → 规划节点 → 追踪分支 → 对照规则 → 修正草稿 → 输出结果。这中间最大的变化是我不再把准确率完全交给模型的“即时生成能力”而是把任务拆成了一套可验证的思考流程。Prompt 不再只是“命令模型做什么”而是变成了“规定模型如何思考”。这才是真正的提升点。5 我开始怀疑很多 Agent 失败不是能力不够而是没有思考流程这件事让我有了一个更大的思考。我们经常说大模型有推理能力但在真实任务里模型并不总是会自动选择正确的推理方式。尤其是小模型或者复杂约束任务它可能根本不会自发形成稳定的内部思考流程。它知道规则也知道目标但它不知道应该按什么顺序去拆解问题。就像一个新人执行任务你只告诉他“不要出错”其实没什么用。真正有用的是给他一套工作方法先检查目标再列步骤再验证路径最后交付结果。人也是一样我们执行任何一个行动之前潜意识里其实已经完成了大量预演。只是这些思考太快了所以我们误以为自己是“直接行动”。而 很多Agent 没有这套潜意识所以我们要把它显式写出来。6 从 LangGraph 到 Claude Code我想把这种思想推广出去这次经验让我想到代码生成是不是也一样我们用 Claude Code、Cursor 或其他 AI 编程工具时经常会遇到类似问题它能写代码但容易改坏别的地方它能修 bug但可能引入新的 bug它能理解需求但实现路径不稳定。也许问题不是它不会写代码而是它缺少一套固定的工程思考流程。比如在动手改代码前是否应该先理解目标 —— 定位相关文件 —— 推断影响范围 —— 设计修改方案 —— 列出测试路径 —— 再真正修改代码。如果机器人任务指令生成可以通过“思考脚手架”提升准确率那么 AI 编程也应该可以。于是我和 Claude Code 一起写了一个项目https://github.com/Liujingze11/thinking-is-all-you-need.githttps://github.com/Liujingze11/thinking-is-all-you-need.git它的核心思想很简单不要只优化模型输出而要优化模型思考。7 Prompt Engineering 的下一步可能不是更长的 Prompt过去我们调 Prompt总是在想怎么让模型“听话”。但我现在越来越觉得真正重要的不是让模型记住更多规则而是让它拥有更好的工作流。规则是静态的。思考流程是动态的。规则告诉模型什么不能做。流程告诉模型应该怎么做。这两者完全不同。对于复杂任务来说只靠规则堆叠很容易让 Prompt 变得越来越长模型却越来越混乱。因为规则之间可能冲突优先级不清晰验证方式也不明确。但如果给模型一套清晰的思考流程它就能先拆解再规划再验证最后输出。这才更接近人类解决问题的方式。8 结语Thinking is All You Need这次用 LangGraph 做机器人任务指令生成让我重新理解了 Agent。Agent 不是一个“更会写答案的模型”。Agent 应该是一个“有工作方法的模型”。如果没有正确的思考流程再强的模型也可能在复杂任务里犯低级错误。如果有了正确的思考流程即使模型本身没有变结果也可能大幅提升。所以我越来越相信未来优化 Agent 的关键不只是模型能力不只是工具调用也不只是 Prompt 技巧。真正重要的是给 Agent 设计一套可执行、可验证、可迭代的思考过程。这也是我做thinking-is-all-you-need的原因。因为很多时候答案不是最重要的:如何思考才是!给孩子点点STAR吧求求了#https://github.com/Liujingze11/thinking-is-all-you-need.git