大家好，我想分享一下过去几个月来我试图理解编程代理实际工作原理的经历。这个过程虽然有些令人沮丧，但也真的很有收获，让我从仅仅使用这些工
具转变为真正理解它们的构建原理。
起点：从困惑到好奇
我最初每天使用 Cursor，就像其他人一样。后来听说了 Claude Code，就想试试看。但用的越多，我越意识到——这些工具对我来说基本上就是魔法。我完全不知道底层发生了什么。
这时我变得很好奇。我不想再只做一名用户，我真的想理解编程代理背后的工作原理。
学习路径：在两个极端之间挣扎
于是我开始寻找学习资源，但发现了一个奇怪的空白——所有内容要么超级简单，要么就异常复杂。
简单的一面：
- 我找到了像"构建一个代理"(ampcode.com)这样的教程，它们对于入门确实很不错
- 但基本上只是演示，你知道吧？它们展示了基础，但你仍然错过了整体画面
- 完成这些教程后，我的想法是"好吧，但我如何用这个实际构建一些真实的东西？"
复杂的一面：
- 我深入研究了像逆向工程的 Claude Code、Gemini CLI、Crush、Neovate Code 这样的开源项目
- 这些都是真家伙——人们实际使用的生产工具
- 但天哪，代码库太庞大了（我们说的是数万行代码），架构简直让人不知所措
- 对于想要学习的人来说，几乎不可能分辨什么是真正重要的，什么只是实现细节
我真的感觉卡住了。我想理解这些东西实际如何工作，但一切都要么太简单以至于无用，要么太复杂以至于无法学习。
转折点：答案是亲手构建
卡住一段时间后，我有了一个想法——如果我自己构建一个呢？
我不是要创造下一个大事件或者与现有工具竞争。我只是想要：
- 构建一些完整但不过于复杂的东西
- 真正理解每个部分的作用以及它们如何连接
- 掌握核心模式，而不需要额外的生产级复杂性
从构建中学到的东西
老实说，自己实现这个时，我终于开窍了。
LLM 和工具集成
- 弄清楚如何让 LLM 可靠地调用工具
- 如何处理工具结果和错误
- 何时并行运行，何时串行执行
为什么 MCP 真的很重要
- 以前我认为 MCP 只是增加了复杂性，但后来明白了为什么我们需要标准化的工具通信方式
- 如何让不同服务协同工作而不抓狂
- 为什么即使在小项目中，可扩展性也很重要
人机协作相关
- 何时真的需要用户输入，何时可以自动执行
- 如何构建不烦人的确认流程
- 自动化和保持人类控制之间的平衡
整合所有部分
- 配置管理、权限、会话——所有无聊但必要的东西
- 错误处理（太多错误处理了...）
- 让 CLI 和交互式 UI 真正协同工作
让我豁然开朗的领悟
我意识到的最重要的事情：
- 复杂性是分层的——只有看到不同层次以及每个层次为何存在，你才能真正理解这些东西
- 亲手构建比阅读好得多——几周的编码让我学到的东西比几个月的教程还多
- 最佳状态是平衡——你需要足够完整才能真实，但又要足够简单才能理解
如果你也在学习这些
对于其他走这条路的人，以下是对我有效的方法：
- 不要只是使用工具——试着理解实际发生了什么
- 中间地带很难找——大多数东西要么是"hello world"，要么是生产级复杂性
- 构建你自己的版本，即使很简单——你会学到超多东西
- 更多关注"为什么"而不是"如何做"——架构决策比具体代码更重要
整个经历不仅教会了我编程代理如何工作，它实际上改变了我对构建复杂系统的思考方式。
总之，如果有人对中等复杂度的实现感兴趣，我把我的项目放到了 GitHub 上：github.com/minmaxflow/…
这基本上是我试图填补简单演示和复杂生产系统之间空白的一次尝试。它大约有 14K 行代码——足够有用和完整，但又不会多到让你理解时头爆炸。更多的是教育性质的东西。
