Anthropic 的 Claude Code 泄露揭示了 AI Agent 工程化的关键在于 Harness，即模型之外的工程体系，它决定了 Agent 的稳定性和可控性。
原文标题：一场泄露看懂 Claude Code：Harness 是让 Agent 干活靠谱的关键
原文作者：图灵编辑部
冷月清谈：
怜星夜思：
2、文中提到 Claude Code 使用 Markdown 文件而非向量数据库来构建记忆系统，这种选择的原因是出于工程化的考虑，更易于查看、修改和调试。你认为在 Agent 的记忆系统设计中，易用性和性能之间应该如何权衡？在你自己的实践或设想中，会如何选择或结合不同的技术来实现记忆功能？
3、文章强调了 Harness 在 Agent 开发中的重要性，指出应该关注出错处理、防止无限重试、上下文分层和任务并行等方面。在你看来，在构建一个稳定、可靠的 Agent 系统时，除了文中提到的这些点，还有哪些容易被忽略但至关重要的工程实践？
原文内容
上周，Anthropic 的 Claude Code 源码被“意外”放了出来。整整 51 万行代码。
大家一开始都在玩梗——什么 CLI 宠物、扭蛋系统、capybara 彩蛋……挺有意思，但说实话，这些都不重要。
真正有价值的，是它让我们第一次看清了一件事，一个能在真实世界里工作的 AI Agent，到底长什么样。
看完源码之后，我最大的一个感受是：“我们之前对 Agent 的理解，太浅了。”
01
以前做 Agent，只做对一半
这两年大家做 Agent，路径都差不多，写 prompt、接几个工具（文件、搜索、shell）、搞个循环（ReAct）、能跑起来就觉得差不多了。
但 Claude Code 告诉你，这只是最简单的那一层。
真正复杂的，是这些问题：
-
模型乱调工具怎么办？
-
输出一半被截断怎么办？
-
上下文爆了怎么办？
-
连续失败几十次怎么办？
-
多个工具同时跑会不会打架？
-
用户还没输入完，能不能先干点活？
这些东西，在 demo 里都不存在，但在真实产品里，全都会发生。而且每一个都很难。
02
一个关键概念：Harness
源码里其实隐含了一个核心思路，可以用一句话总结：“Agent = 模型 + Harness。” 模型你已经很熟了。
那么 Harness 是什么？
简单说 Harness 是模型之外的一切工程。
包括，上下文怎么管、工具怎么调、错误怎么恢复、权限怎么控制、多任务怎么并行、成本怎么压。
以前大家拼 prompt，现在开始拼这个了。
03
难点不在调用工具
很多人以为 Agent 的核心是让模型学会调用工具。但从 Claude Code 来看，这部分反而是最简单的。真正难的是工具调用之后怎么办？
举几个特别真实的问题：
1. 上下文不是“总结一下”就完了
很多教程会说：“上下文太长？总结一下。”
但实际情况是：
-
有的内容是垃圾（可以直接删）
-
有的内容要保结构（不能只留结论）
-
有的内容必须长期保留（比如用户偏好）
Claude Code 的做法不是一次总结，而是一整套分层策略。
简单理解就是，不同信息，不同处理方式。
这点如果你做过复杂对话系统，其实会有共鸣。
2. 成本问题，比你想象的严重
源码里有个特别“工程味”的点，Prompt Cache 是一等公民。
不是优化，是约束。什么意思？
就是你 prompt 怎么写、子任务怎么拆、输出怎么格式化，都要围绕能不能命中缓存来设计。
否则就是成本直接翻倍，延迟也跟着炸。这在 demo 里完全感知不到，但在真实产品里是生死线。
3. 安全问题，不是加几个 if
最容易被低估的一块。Claude Code 的权限控制，大概是五层：静态规则、用户自定义 Hook、工具自身声明（只读 / 写）、LLM 判断（是的，用模型管模型）、熔断机制。
而且默认策略是一律按最危险情况处理（Fail-closed）
比如，工具默认不是并发安全、默认不是只读、不确定就拦，这种风格很像做基础设施，而不是做 demo。
4. 错误处理：用户不应该看到过程
这个设计我觉得特别值得学。一般我们做系统：出错 → 返回错误，但 Claude Code 的策略是先自己兜底，兜不住再说。
比如：
-
输出被截断 → 自动扩 token 重试
-
还不行 → 自动续写
-
模型挂了 → 自动降级
只有所有手段都失败，才把错误暴露给用户。一句话总结：“错误是系统内部的问题，不应该第一时间甩给用户。”
5. 一个很现实的问题：Agent 会发疯
源码里有真实数据，有会话连续失败 3000+ 次、每天浪费几十万次调用。所以他们做了一件很“朴素但有效”的事——到处加熔断器。
比如，压缩最多 3 次、权限拒绝最多 3 次、输出续写最多 3 次。没有什么 fancy 的算法，就是一句话——不让它无限试下去。
04
把 Agent 用轻一点
一个我很认同的设计就是把 LLM 用轻一点。以前我们会觉得，LLM 很贵，要慎用。但 Claude Code 反而是到处用小模型。
比如，权限判断、记忆筛选、工具总结，甚至主模型在思考的时候，这些都在后台并行跑。
效果是几乎不增加延迟但整体体验好很多。这个思路其实挺重要的：“不要只想着少调用，而是怎么用得更聪明。”
05
反直觉选择：不用向量数据库
他们的记忆系统，用的是 Markdown 文件，而不是向量库。
原因很现实，能直接看、能手动改、能 git 管、出问题好 debug。你可以说它“土”，但它非常工程化。
06
说点更大的判断
看完这套系统，我有一个更确定的感觉：
1. 模型正在变得不那么重要
不是说不重要，而是差距在缩小。大家都能用差不多的模型。
2. 差距开始转移
真正的差距变成，谁更稳定、谁更便宜、谁更可控、谁更不容易出错，也就是 Harness 的能力！
3. 一个更现实的结论
如果你现在在做 Agent，别只卷 prompt 和模型了。可以多花点时间想想这些问题，出错了怎么办？怎么防止无限重试？上下文怎么分层？哪些可以并行？哪些必须限制？
这些东西不炫技，但决定你这个东西能不能真的上线用。
07
写在最后
这次 Claude Code 的泄露（不管是不是“意外”），其实给行业补了一课，Demo 和产品之间，差的不是一点点优化，而是一整套工程体系。
以前大家在卷能不能做，接下来更重要的是能不能稳定地做、长期地做、低成本地做。
这才是下一阶段真正的门槛。
如果你对这些工程细节感兴趣，我把源码里更底层的一些实现（包括具体代码和设计拆解）整理在博客里了，有兴趣可以继续往下深挖：
👉 https://01.me/2026/04/blog-claude-code/
另外，如果你最近也在考虑入门或者系统性学习 AI Agent，这块我也做了一套偏工程实践的课程，主要讲的不是怎么玩，而是怎么做成一个能上线的东西。
感兴趣的话也可以了解一下。