驾驭工程 — 读Claude Code源码学习Agent架构哲学(1)

今年春节过后，突然一个新的名词火了，“Hareness Engineering”，如果时间线没错的话，我是先从Anthropic这家公司提出了一个新的概念Skill（技能）再到OpenClaw小龙虾风靡全球，当时还是一个懵逼的状态，各种公众号，视频平台都开始说Harness工程，因为就在去年我还在学习提示词工程（Prompt Engineering），上下文工程（Context Engineering），怎么突然又来了一个Harness，没办法只能硬着头皮学了。

当时开始看各种科普视频和文章，我印象很深的小白Debug讲的不错，简单点说就是如何让AI大模型更稳定的输出，从而可以对生产系统进行AI化改造，但是说实话也是踩着石头过河，一点点根据自己的理解学习和应用。

前两年AI应用的热潮是从Dify这种可编排的AI基础应用底座开始，搭建各种工作流，从而让业务系统更快速的在某个点进行AI化，如果说最火的AI应用那肯定就是知识库类型的应用了。不过我也做了很多非知识库的业务应用，当时就有很多疑惑，从提示词工程开始，看了很多文档，以及Google的提示词白皮书，才了解到为什么叫工程。

前年有Dify的时候我就在想如何利用大模型快速赋能软件研发，因为那时候大模型输出代码的能力已经是飞快了，当时我快速通过Dify搭建了一个代码生成的工作流，当时把项目架构，项目规约，技术栈等全放到了这个工作流里面，还别说当时效果非常显著，对于大型项目的0-1代码，AI模型非常快速的生成好了，只不过当时还需要人工复制粘贴到项目代码库里，后来我才意识到原来我上面给的这些背景知识其实就是上下文工程的一部分。

其实Harness这个概念很早就接触了，只是并没有总结出来叫驾驭工程，当时印象很深，做了一个Agent平台项目，这个项目是想从软件开发生命周期（SDLC）平台层面，赋能软件交付的每一个环节，不像我上面讲到的Dify工作流那么简单，它最大的一个耗时的节点要解决的是1-n的项目问题，项目从去年12月中旬开始，当时还没有Skill，Harness这些概念，但当时已经有了多智能体（Multi Agent）这个概念，当时翻阅了各大AI框架，了解到SuperVisor模式，MCP注入，SystemPrompt，Instruction....等等非常多的概念，但是遇到最大的问题并不是学习这些概念，而是怎样让AI模型输出效果稳定且高效，说实话当时就有很多问题在脑子里埋下种子，比如Agent为什么会不稳定的调用某些工具，或者调用一半然后Agent说他完成了，结果它忽悠我。

使用Few-Shot 举例子约束
使用模型温度参数约束
使用上下文长度约束
设置重试机制
设置工具调用拦截器捕获工具调用结果，捕获错误
使用上下文长度压缩约束，保证模型上下文不越界
使用精简的提示词要求模型不要太多废话，节省token
....

不得不说Agent做好门槛确实不低，最简单的一点并不是所有人都知道提示词工程，甚至有时候Agent输出的很稳定，但只要不小心调整了某个环节，例如更换了模型，Agent就会导致整个多智能体链条变得不稳定起来。

请原谅我上面说了那么多废话，还没说到具体的Agent架构哲学，因为上面那些真实的经验都是在过去通过互联网，技术官方文档，社区群了解的概念，自己一点点应用摸索，还算不上哲学，只是一点点自己的碎碎念，直到最近我看了Claude的源码，才真正意识到原来Agent架构是如此精密的设计，如果你过去也有很多困惑在Agent应用方面，那么接下来就要进入到正文了😁

Claude Code的架构可以分为三层，每一层有明确的职责边界。Agent Loop 运行在应用层，工具执行编排跨越应用层和运行时层，缓存优化则涉及所有三层的协作。

看完第一章我就学习到了非常多的概念，Claude Code架构简直就是把Agent系统设计哲学应用到了极致，我印象很深的几点

并行预取，将 I/O 密集型操作提前到模块加载的"死时间"中并行执行，让Agent运行时环境启动足够快，要做到这些必须对系统和框架的运行原理了解的足够清楚
Feature Flag，最开始我以为就是简单的Feature开关，后来我发现他简直把框架原理运用到了极致，ClaudeCode的技术栈是：TypeScript + React Ink + Bun，它过JS构建时死代码消除的原理来保证Agent运行时环境特性功能在打包的时候物理消除。
"On Distribution" 哲学设计理念，AI Agent 行为是不确定的，它会根据用户的输入来具体做相关的事，这个过程模型可能会调用工具，调用读的工具系统磁盘的文件，调用可执行的工具去写文件，或者去调用外部系统的工具，所以在AI Agent设计理念上意味着工具的 description 字段不能只描述"这个工具做什么"，还必须引导"模型应该在什么情况下使用这个工具"。

不管是从上下文的四层裁切（snip → microcompact → collapse → autocompact）还是错误恢复策略，总是从最轻量（信息损失最小）的手段开始，逐步升级到更重量级的手段。不仅是性能优化，更是信息保留策略——每一级都在"用最少的代价换最大的空间"。
用户在使用Agent系统的时候，错误不立即暴露给消费者。它们被暂时扣留，只有在所有恢复手段耗尽后才被释放。这个模式解决了一个现实问题：SDK 消费者（Desktop、Cowork）会在看到错误时终止会话——如果恢复成功，过早暴露错误就是一次不必要的中断。
开源社区有很多Harnes Skills文件输出内容该多长才合适，例如PRD文档，他们做了一个非常有意思信息收集，越长的文档反而拒绝率越高，瓶颈虽然在开发这个步骤好像消失了，但是却忽略了review的时间，这个设计太有意思了

如果你有一组工具要执行，为了提高执行效率你会怎么做？如果默认，我想你会默认一个一个串行执行，而Claude在顺序保证和并行效率之间，选择一个简单的中间方案，既节省了时间，又降低了和模型交互的频率变相也节省了token，顾名思义贪心流水线合并分区策略
工具执行权限体系设计，纵深防御安全设计体系
200K上下文竞技场
提示词工程作为控制平面

Token的节省，Claude也是煞费苦心，例如有些Agent他认为不需要注入Claude.MD（Agents.md）从而节省token，虽然现在都是放飞的时代的时代，但是我相信在不久的将来，AI Agent应用的Token优化也是一个大的课题，毕竟都是真金白银

以上只是开胃菜，今天的碎碎念先到这，后面我会在持续更新，因为看完ClaudeCode源码，真的非常叹服这些工程师为了驾驭工程做出的绝妙的设计，如果你也有很多关于Agent想不清楚的问题，可以好好读一遍它的源码分析，我详细都会给你更好的指引，我认为胜过市面上的任何营销号所谓的书籍。