在上一篇“Claude Code 源码研究一个 while(true) 循环让大模型自己干活”之后继续我们的研究——01自然语言引导能保证模型每次都听话吗Claude Code 不靠 if-else 控制模型选哪个工具而是靠 40 份精心撰写的工具说明书做软引导。这立刻引出一个问题软引导靠谱吗模型不听话怎么办答案很直接不能保证。自然语言引导是概率性的不是确定性的。说明书里写了不要用 cat 读文件用 FileRead模型大多数时候会照做但没有任何机制能保证它 100% 遵守。大模型的本质是概率采样概率采样就意味着总有意外的可能。但 Claude Code 的设计者显然不是天真的理想主义者。他们在自然语言引导之外布了三层防线。第一层拦每个工具调用在执行前都必须通过权限检查。危险操作写文件、执行命令会弹窗让用户确认。模型想干什么不重要用户不批准就执行不了。第二层查把 shell 命令解析成抽象语法树识别管道、重定向、子命令嵌套中的危险模式。rm -rf /会被拦住echo hello | rm -rf /也会被拦住。第三层关构建文件系统沙箱在操作系统层面限制 Agent 的活动范围——哪些目录可读、哪些可写、哪些域名可访问全部白名单控制。这是一道物理隔离。劝Prompt提示、拦、查、关四层叠加任何单层都不是 100%。自然语言引导可能失效权限系统可能被用户自己按了全部允许AST 解析可能遇到没见过的命令构造沙箱可能在某些平台上有实现差异。但四层的穿透概率是各层失效概率的乘积趋近于零。这是经典的 Defense in Depth ——纵深防御军事术语也是信息安全的基本原则。不依赖任何单一防线的完美而是通过层层叠加让整体风险降到可接受的水平。就好像你家的安全不是靠一把锁。是门禁 门锁 监控 邻居会报警。每一层都可能失效但小偷要同时突破所有层难度指数级上升。Claude Code 对模型不听话这件事的态度不是努力让它 100% 听话而是假设它一定会不听话然后确保不听话的后果可控。这比盲目信任自然语言引导成熟得多。02如何评估工具执行结果的正确性Agent 调了一个工具工具返回了结果。下一步自然要判断这个结果对不对要不要重试答案出乎意料Claude Code 完全不评估工具执行结果的正确性。代码层面零判断。工具执行完之后结果被原封不动包装成 tool_result塞进消息历史发回给模型。没有检查返回值是否合理的逻辑没有如果结果为空就重试的分支没有任何形式的结果验证。那评估这件事谁来做模型自己做。下一轮循环里模型看到了完整的对话历史——包括自己上一轮请求的工具调用和对应的执行结果。它自己判断结果是否符合预期自己决定下一步做什么如果 grep 搜出来的结果不对模型会换个关键词再搜如果文件编辑之后 npm test 失败了模型会看报错信息、分析原因、修改代码、再跑测试如果一个 API 请求超时了模型会决定是重试还是换个方案……评估不是 Agent Loop 中一个独立的步骤它融入了下一轮循环的决策过程。这其实完全符合人的工作方式。一个工程师在终端里敲了 grep TODO *.py发现结果只有一条他不会启动一个grep 结果正确性评估程序——他直接看一眼觉得不对就换个关键词重来。Claude Code 的设计者抓住了本质——评估和下一步行动是一体的不是两个分离的阶段——对大模型而言理解工具输出并据此决策是它的推理能力的一部分而不是需要额外代码辅助的独立任务。这里面有一个更深的设计哲学不要替模型思考。框架的职责是当好信使——忠实传递请求忠实返回结果——而不是在中间插一脚自作聪明地帮模型理解结果。03用户对结果不满意时如何反馈给 AgentAgent 给出了一个方案用户觉得不对说这不是我要的我要的是 X。这个反馈怎么进入系统有没有专门的反馈处理模块答案是无法反馈。用户的反馈就是一条普通的 user message。走的是和第一次输入完全相同的路径processTextPrompt() → 构建消息 → 进入 Agent Loop。没有反馈模式没有纠错通道没有任何特殊处理。用户说这不对应该用 async/await 而不是 callback这句话被当作一条新的 user message 追加到消息历史的末尾。下一轮 API 调用时模型看到的是完整的对话历史原始需求、自己之前的方案、工具执行的结果、以及用户刚才的这句反馈。模型靠自己的推理能力理解这是一条纠正指令不是一个全新的任务。然后它基于这个理解调整方案继续执行。这意味着纠错能力的上限完全取决于模型的推理能力而不取决于框架的设计。框架不做任何帮助模型理解反馈的事。不会把用户的话标记为这是纠正不会提取其中的关键信息高亮显示给模型不会触发什么反思链路。这个设计一开始让我觉得过于简陋。但想深一步它是对的。原因在于反馈的语义是无限丰富的。 这不对可能是纠正方向加个日志可能是补充需求算了先帮我看另一个文件是话题切换嗯可能只是确认。如果框架试图用代码逻辑去分类和处理这些反馈它要么做得太粗分类错误要么做得太细写不完的规则。那么不如把反馈原样交给模型让模型自己在完整上下文中理解语义。模型是目前最好的自然语言理解引擎没有理由在它前面再套一层更弱的理解层。这跟上一个问题的哲学一脉相承框架不替模型思考。04每次给模型多少上下文用户跳话题怎么办最后一个高频问题Agent Loop 每轮调 API发过去的消息历史有多长如果用户前面在修 bug突然说帮我写个 README——前面那些 bug 相关的上下文还会发过去吗答案简单粗暴全部发过去。每一轮 API 调用Claude Code 把完整的消息历史——从第一条用户消息到最近一次工具执行结果——全部打包发送。不做话题筛选不做相关性过滤不做任何裁剪。这是一个刻意的设计选择。Claude Code 的哲学是宁可让模型在一大堆上下文里自己找到有用的信息也不冒险替模型过滤掉它可能需要的东西。为什么不过滤因为什么是相关的这个判断本身极其困难。用户说帮我写个 README看起来和前面的 bug 修复无关。但如果前面的 bug 修复涉及到项目的核心架构而 README 正好要描述这个架构呢如果框架自作主张把 bug 修复的上下文过滤掉了模型就丢失了关键信息。过滤的风险是不对称的多给了无关信息模型大概率能自己忽略少给了关键信息模型一定会犯错。但这个策略有一个显而易见的问题上下文会撑爆。Claude 的上下文窗口虽然大200K tokens但几轮密集的工具调用之后消息历史可以轻松超过这个限制。一次 FileRead 读一个大文件可能就是几千 tokens十轮循环下来上下文可能已经膨胀到六位数。Claude Code 为此实现了三级压缩机制层层递进第一级Auto-compact主动压缩当上下文接近窗口上限时自动触发。Claude Code 会发起一次额外的模型调用通常用更轻量的 Haiku 模型把之前的对话历史压缩成一份结构化摘要。压缩后的摘要替代原始历史作为后续对话的起点。压缩的 prompt 里有一条特别要求Preserve All user messages——所有用户的原始消息必须保留。因为在所有信息中用户的意图变化是最不能丢的。工具的执行结果可以概括模型的中间推理可以省略但用户说过的每一句话都可能影响后续任务的理解。压缩后消息历史的最前面会加一句This session is being continued from a previous conversation that ran out of context.——告诉模型你看到的不是对话的全部前面有一段被压缩过的历史请据此继续。第二级Reactive compact紧急压缩当 API 直接返回 prompt-too-long 错误时触发。这说明连 auto-compact 都没来得及处理或者压缩后仍然过长需要更激进的压缩策略。第三级Context collapse渐进折叠不是一次性压缩全部历史而是逐步折叠早期的工具执行结果。最近几轮的细节保持完整更早的轮次只保留摘要。有点像人的记忆——昨天的会议你记得细节上个月的会议你只记得结论。三级机制的设计逻辑很清晰先预防auto-compact再应急reactive compact最后兜底context collapse。跟前面讲的安全四层防线一样是同一种工程思维不依赖任何单一机制的完美用多层叠加覆盖各种边界情况。05Agent 框架新范式Claude Code 在框架层面做的事情比大多数人想象的少得多——不评估工具结果不处理用户反馈不筛选上下文甚至不保证自然语言引导的有效性。它做的只是确保信息准确传递、确保安全边界不被突破、确保上下文不会物理溢出。所有智能的部分——理解任务、选择工具、评估结果、解读反馈、忽略无关信息——全部交给模型。这不是偷懒这是一种架构立场在模型能力足够强的前提下框架最大的价值不是替模型做决策而是不妨碍模型做决策。传统软件工程的思维是尽可能用代码控制一切——每个分支、每个判断、每个异常处理都要写在代码里。而 Claude Code 代表的新范式是尽可能少地替 AI 做主——把决策空间完整地交给模型框架只负责基础设施安全、传输、资源管理。这个转变的前提当然是模型足够强。如果模型不靠谱你不得不在框架里加各种护栏、规则引擎、决策树来弥补。但当模型的推理能力越过某个门槛这些精心构建的辅助逻辑反而变成了束缚——它们基于工程师对任务的有限理解而模型可能有更好的判断。这大概是 Claude Code 源码给我们最大的启发好的 AI Agent 框架不是做了了什么而是克制住没做什么。欢迎关注微软智汇AI官方账号一手资讯抢先了解喜欢就点击一下在看吧~