人物雷达｜Mitchell Hashimoto和他的朴素工程哲学

我观察 Mitchell Hashimoto 有一段时间了。

在讨论 AI agent 的人里，他是一个奇怪的存在。他不做预测，不讲愿景，不谈谁会被替代，也不说哪个模型即将封神。他甚至承认——自己今天使用 agent 的很多技巧，可能三年以后就不再需要。他只是在博客和访谈里，一点点地讲他是怎么用的、哪里用得好、哪里被卡住、卡住之后他怎么想。

但如果你把他过去一年的表达拼起来看，会发现它们形成了一个非常克制、非常朴素、也非常难被时间淘汰的结构。

这个结构可以用他自己的一句话概括：当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

这句话听起来几乎不像一个“观点”。它不锋利，不性感，没有流量。但它恰恰是我愿意花一篇文章写他的原因。

他先是个做环境的人，然后才是个用 agent 的人

要理解 Mitchell 现在的 AI 观，得先绕开 AI，回到他过去十几年做的事情。

他在自己网站上把履历写得非常冷静——主要在做 Ghostty；曾在 HashiCorp 做过四年 CEO、五年 CTO、两年个人贡献者，2023 年离开。这份简历背后，是 Vagrant、Packer、Consul、Terraform、Vault、Nomad、Waypoint——几乎构成了过去十年云基础设施的默认词汇。

有意思的是，把这些工具并排放着看，会发现一条相当连贯的线索：它们都在解决同一件事——怎么让一个开发者环境，从“存在于某个老员工脑子里”，变成“可以被代码描述、被机器复制、被工具执行”。

Vagrant 让本地开发环境可以被复制。Terraform 让云基础设施可以被声明。Nix 让整台桌面可以被代码重建。Ghostty 是终端，看起来和前几样不一样，但仍然是开发者环境的一部分。

他在 Open Source Ready 聊 Nix 的时候有一句话让我印象挺深——他说自己其实想要的只是一种“可靠、一致、可用代码重建”的桌面。这听上去很简单，但放进他过去所有工具里都成立。

这个人一辈子都在做一件事：把人对环境的隐性依赖，转成环境本身的显性约束。

所以当他进入 agent 时代时，他看 agent 的角度和大多数人不一样。他不觉得 agent 是一个需要仰望的智能体，也不觉得它是一个需要贬低的补全工具。他看到的是一个会在环境里读文件、执行命令、调用工具、观察结果、循环行动的东西——换句话说，一个新的、可以被工程化地约束和塑形的对象。

这是他和大多数 AI 讨论者的分水岭。

他一开始其实不太满意

我不喜欢过度拔高一个人的“先见之明”。Mitchell 对 AI 的态度不是一开始就那么清晰的，他自己也坦白过这件事。

在《My AI Adoption Journey》里，他说自己第一次认真用 Claude Code 的感觉是——不太行。生成的东西要大改，改完还不如自己写。他一度怀疑自己是不是不适合这套工作方式。

然后他做了一件我觉得很能代表他性格的事情。

他没有得出“agent 不行”的结论，也没有得出“我不行”的结论。他选了一条更笨、更慢的路——把自己已经手写完成的 commit 拿出来，关掉答案，逼自己用 agent 在看不见答案的前提下，复现同等功能和质量的结果。

这件事其实很反效率。他在正常交付之外，又凭空给自己加了一层工作量。但也正是在这段笨功夫里，他开始真正理解 agent 适合什么、不适合什么。

他自己总结出了三条结论，简单到几乎像一本软件工程教科书：任务要拆小；模糊需求要先规划再执行；最重要的——给 agent 一个能自己验证工作的办法。

读到第三条的时候，很多人会觉得这不就是测试吗？是的。这正是他的风格。他不造新词，他把那些我们本来就熟悉的工程原则原样搬了过来。只是以前我们说“不要让人记住规则，让系统执行规则”；现在他说，“不要指望 agent 下次会变聪明，要把这次错误变成环境的一个约束”。

为什么是“环境”，而不是“prompt”

Mitchell 讨论 AI 时，很少聊 prompt。

这件事本身就值得注意。今天大多数关于 AI 编程的内容，核心都是 prompt——怎么写出更好的 prompt，怎么骗模型一步步思考，怎么给它塞上下文让它听话。但 Mitchell 几乎从不谈这些。

他谈的是 harness——套在 agent 外面的那一整层环境：规则、文档、工具、脚本、测试、权限、工作目录、反馈信号、观察机制。

LangChain 早就有过一句简洁的定义——Agent = Model + Harness。模型提供智能，harness 让智能变得可用。Mitchell 不是提出了这个概念，他只是把它变成了日常工作的重心。

他把 harness 分成两类。一类他叫“更好的隐式提示”，最典型的载体是项目里的 AGENTS.md 文件。Ghostty 仓库的 src/inspector/AGENTS.md 是个小而具体的例子：它告诉 agent，inspector 类似浏览器开发者工具；去哪里找 dcimgui.h；widget 例子在哪里；macOS 构建时要加什么参数；这个包没有单元测试。没有一句宏大的 AI 理论，全是具体到命令、文件、API 的本地说明。

另一类是真正的程序化工具——截图脚本、过滤测试脚本、可重复的构建命令、轻量的模拟环境。前者改变 agent 的认知上下文，后者改变 agent 的行动能力和反馈质量。

两者加起来是这样一件事——agent 找不到 API，就写下 API 的位置；用错构建命令，就把正确命令写进去；不知道如何验证 UI，就给它截图工具；一再违反架构边界，就写结构性测试或 lint 规则。

这和 prompt engineering 很像，但不是一回事。prompt engineering 是“这一次我怎么说”，harness engineering 是“这个系统怎么设计”。前者的收益随对话消散，后者的收益会长期累积。

Mitchell 相信的是后者。原因不复杂——他一辈子都在相信后者。

责任不能外包：一句分量很重的话

他在 2025 年 10 月发过一篇文章，《Vibing a Non-Trivial Ghostty Feature》。那篇文章公开了他用 AI 辅助完成 Ghostty 一个具体功能的全过程——macOS 上不打断用户的自动更新提示。

很多人关注里面的数字：16 次 agentic coding session，token 成本 15.98 美元，约 8 小时墙钟时间。他自己也承认效率提升是真实的，尤其是 SwiftUI 细节迭代那部分，AI 帮了大忙。但我读那篇文章时，印象最深的不是这些数字，而是他在遇到 bug 时的一段话。

他遇到了所谓的 slop zone——agent 生成的代码看起来合理，能跑，甚至测试都能过，但里面藏着一个关键 bug。他换了几次更精确的 prompt，都没有修好。

这时候，工程师的本能会告诉你——再换一个 prompt；再换一个模型；或者等 Claude 下个版本。

他没有选任何一条。他停下来，自己去学 Sparkle 框架，自己去看 Obj-C 的 protocol，自己去理解为什么会出错。然后他在博客里写下了一句让我反复想了很多次的话：

如果 agent 找到了解法，我会学习；如果我不理解，我就回退。我不交付自己不理解的代码。

这句话的分量，在 AI 编程的讨论里不太常见。

今天太多人在讨论 AI 带来的速度——更便宜、更快、更多产出。这些都是真的。但 Mitchell 更在意的东西是另一样：你理解了吗？你能维护吗？它会不会回归？下一个看到这段代码的人（不管是人类还是 agent）会不会更容易，还是更困难？

AI 可以写代码，但代码的责任不会因此外包。你可以让 agent 试、写、改、跑测试、找资料、整理结构；但最终合进代码库的是你。用户坏了，不会说“这是 Claude 写的”；维护者，也不能把不可理解的复杂性推给模型。

Mitchell 的这句话，我私下认为是整个 AI 编程讨论里最接近“工程伦理”的一句。它没有宏大语言，但它把一个特别容易被模糊掉的边界，清晰地钉下来了。

他把 agent 当 junior engineer，不当 superhero

Mitchell 还有一个类比用得很多——和 agent 合作像指导一个 junior engineer。

如果你是个带过人的工程师，你会立刻懂他在说什么。

把一个开放式问题丢给 junior，比如“去优化一下我们的订单系统”，基本等于灾难。把一个边界清楚、护栏齐全、验证明确的小问题丢给 junior，比如“这个接口加一个重试逻辑，条件是 A 和 B，不要改 C，写一个对应测试”，他往往能做得不错。

AI 目前处在一个很类似的位置。

这也是为什么 Mitchell 从不把架构外包。他负责代码结构、数据流、状态放在哪里；他把问题切成合适的形状，再让 agent 在那个形状里行动。他在 Zed 的访谈里说过——如果你只对 agent 说“这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式，把症状敲掉，留下一个你将来一定要还的债。

他对 agent 的能力边界，也判断得很具体。

重构、重命名、整理结构、清理死代码、填空式的样板代码——agent 几乎总能做得很好。他把这类任务称作“outsource the slam dunks”，专门挑高把握的扔给它。

开放式架构、高性能数据结构、小众语言——agent 目前仍然很差。Ghostty 底层是 Zig，但 Zig 的训练数据太稀，agent 常常幻觉出根本不存在的语法。他的 workaround 很务实——让 agent 用它更熟悉的 C、Rust、Swift 或 Python 写方案，再由自己手工翻成 Zig。

这不是什么宏大的理论。这就是一个老工程师在分配任务。只是他现在多了一个**“永远不抱怨、永远不累、但需要护栏”**的新成员。

他不相信“X + AI”

Mitchell 有一个经常被误解的立场——他对 AI 产品的批评。

很多人以为他是 AI 怀疑派。其实不是。他反对的不是 AI，而是一种特定的做法——把 AI 当产品的遮羞布。

在 Open Source Ready 的访谈里，他批评过一类典型的 AI 产品：一个邮件客户端本身已经不好用，只是外面加了 AI 功能；一个笔记应用本身已经割裂，只是加了个 AI 总结。他的判断简单粗暴——AI 集成可以很好，但用户最终仍然要使用完整产品；如果基础体验不成立，AI 救不了它。

这句话背后其实是一以贯之的工程哲学：基础要扎实，环境要可靠，工具要真正解决人的问题。 一个糟糕的产品加上 AI，不会变成好产品；一个混乱的代码库加上 agent，不会变成可维护系统。AI 会放大已有系统的性质——清晰的环境被放大为效率，混乱的环境被放大为 slop。

他对开源的判断也在发生变化。在 The Pragmatic Engineer 那篇访谈总结里，他提到开源可能会从 default trust 走向 default deny——因为 AI 让“看起来合理但实际低质量”的贡献变得太容易。这不是说开源不再欢迎贡献，而是说维护者必须建立新的过滤机制。

他的 Ghostty 里那个被反复删除的 issue，就是这种态度的具体体现。有人贴了另一个终端的 GPL 代码片段，他立刻删了。对方说你让 ChatGPT 生成类似的就行，他反问——这样做安全吗？是不是把代码通过模型洗了一遍？他没有给答案，他只是说希望法律先例先明确。

一个愿意在具体问题上说“我不知道”的人，才有资格在大问题上被信任。

一条不变的线索

WIRED 在 2019 年做过一期关于他的报道。文章里他自己说——“我这辈子做的事情有一条连续的线索——自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

你会发现，这句话放到 2026 年几乎可以一字不改地成立。只是“重复劳动”的内容变了。过去是搭环境、建虚拟机、管理 secret、写配置；现在是查资料、整理 issue、跑测试、写样板、做 refactor、生成模拟场景、修构建错误。

变化的是工具，不变的是原则。

所以 Mitchell 的 agent 哲学，从来不是“让人退场”。他从不说编程会消失，也不说工程师会被替代。他说的是另一件更温和、也更诚实的事情——人要换一个位置。 过去大量时间花在亲手写代码，现在要有一部分时间转向设计“agent 能成功工作的环境”；过去经验沉淀在资深工程师脑子里，现在要沉淀进 AGENTS.md、脚本、测试、文档和约束；过去 review 是看人写的代码，现在 review 还要看 agent 是否被正确约束。

这个位置迁移，听起来不像一个很性感的故事。它没有“一切都将改变”的戏剧感。但它可能更接近真实发生的事情。

一个很难被淘汰的想法

我想最后回到那句话——当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

这句话的好处是，它不依赖任何一个具体模型、任何一个具体工具、任何一个具体版本。模型会变，工具会变，今天的 harness 明天可能就过时。但这句话所表达的姿态——把错误当成系统暴露出来的缺口，而不是模型的偶然失误——几乎可以迁移到任何技术的任何时代。

也许几年以后，agent 比我们所有人想象的都聪明。到那时候，很多具体技巧会被扔进“临时技能”的抽屉里，包括 Mitchell 今天讨论的很多。但我不觉得 harness engineering 的姿态会过时。

因为它本质上说的其实是一件很老的事——不要迷信智能，设计环境；不要反复提醒，建立机制；不要把错误看成偶然，把错误看成可工程化的信号。

软件工程里，所有真正有复利的东西，几乎都是这个形状。

Mitchell Hashimoto 的价值不在于他发明了什么新术语，而在于他在一个很喧嚣的时刻，把 AI agent 这个看起来魔法般的东西，拉回了工程师最熟悉的地面——环境、约束、反馈、自动化、责任。

这种姿态不一定最能吸引眼球。但时间通常比较偏爱这种人。