编辑 | 云昭
出品 | 51CTO技术栈(微信号:blog51cto)
世界上最好用的编程工具,Claude Code,又被人深度研究了!
它背后,竟然只保留了一个主控制循环,系统逻辑竟然简单到爆。
管AI代理如此复杂,但这款最令人愉悦的AI编程工具,却保持了极其简单的方式。
“我高度怀疑:大多数应用可能真不需要多 Agent 系统。”
近日,CC 的一家重度用户,MinusX 团队经过煞费苦心的研究,终于发现了背后的秘密。
事情是这样婶儿的。
MinusX 是一家去年成立的、位于美国旧金山的初创公司,核心愿景就是打造一款“AI数据科学家”, 让 AI 能像人一样,在用户熟悉的数据工具里(如 Jupyter、Metabase、Grafana、Tableau等),通过点击和输入帮助用户自主完成数据分析。(没错,又是一款 Agent!)
近日,他们的联合创始人兼 CEO Vivek Aithal 对于自家团队使用 CC 打造 Agent 的经历颇有感触,并突然发现:值得学习的对象,远在天边,近在眼前。
Claude Code 本身就是一款超级无敌好用的 AI Agent!
于是他们为了搞清楚 CC 为什么如此好用,几月前专门搭建了一个日志工具,拦截每一次网络请求,并分析了数月的使用数据。
图片
结果,他们团队发现了很多反常识的真相。
- 50% 的 Claude Code 调用使用了更便宜的 Haiku 模型:不仅用于简单任务,还包括读取大型文件、解析 git 历史,甚至是生成你看到的那些一词式处理标签。
- “Edit” 是使用最频繁的工具(占 35%),其次是 “Read”(22%)和 “TodoWrite”(18%)。
图片
- 没有任何多 Agent 的交接。尽管外界炒得很热,Claude Code 实际上只用一条主线程,最多带一个分支。
- 工具描述竟然超过 9400 个 token ——他们在工具提示上的投入比大多数人整个系统提示还要多。
- LLM 搜索 >>> RAG 搜索。
最令人吃惊的是,在外界充斥各种 AI Agent 复杂性的同时,这款世界上最好用的编程 AI 却选择了一条极致简洁的路径:
一个循环、一份消息历史、清晰的工具设计、大量示例。
Vivek 为此大为触动,很细致地将这次 CC 的逆天研究也分享了出来,当然全面解析 CC 的开发设计哲学并不是最终目的,目的还是告诉大家如何打造一款叫好且叫座的 Agent 产品!
网友看罢,直呼过瘾。
图片
话不多说,全文逻辑非常清晰,请各位大佬系好安全带,咱们这就发车!
一、CC 击败了 Cursor,为什么它如此让人省心、开心
Claude Code 是迄今为止我用过最让人愉快的 AI agent/工作流。
它不仅能做定向修改,而且在“甩手写点小工具”的场景下,也不那么烦人。更重要的是,用 Claude Code 的过程本身就让我开心。它的自主性刚刚好——既能做出有趣的事,又不会像其他工具那样带来强烈的“失控”感。
客观地说,即使它们底层模型相同,Claude Code 也要比 Cursor 或 Github Copilot agents 更省心。
PS:当然,大部分硬活儿还是得靠 Claude 4 新模型(尤其是 interleaved thinking)撑着。
那问题来了,Claude Code 到底为什么这么好用?如果你边读边点头,我会尝试给你一些答案。
注意,这里不会像市面上那样再去搞一篇 CC 架构的剖析文章,而是基于我过去几个月使用和试验 CC 的经验(加上我们拦截并分析的日志),写的一份“如何打造让人叫好的 LLM agent”指南。
多说一嘴,如果各位想直接看干货,可以跳到 TL;DR 部分。
二、Claude Code 的妙处
CC 之所以好用,是因为它“就是能跑起来”。
CC 的设计从根本上理解了 LLM 擅长什么、糟糕在哪。它的 prompts 和工具能帮模型弥补短板,同时放大强项。而且,其控制循环极其简单,容易跟踪和调试。
我们在 MinusX 一发布就开始用了 CC。为了探底,Sreejith 写了个 logger,能拦截并记录每一个网络请求。
以下分析就是我过去几个月的大量使用总结。
本文的核心问题是——“Claude Code 为什么好用?你又如何在自己的对话式 LLM agent 里实现 CC 式体验?”我们已经在 MinusX 吸收了大部分经验,希望你也能做到!
三、重点来了:如何打造一个像 Claude Code 的 Agent
如果只记住一句话,那就是——保持简单,傻瓜(Keep Things Simple, Dummy)。
LLM 本来就够难调试和评估了,你加的每一层复杂度(多 Agent、交接链、复杂 RAG 检索算法)都会让调试难度翻十倍。就算能跑起来,你之后也会害怕去改它。
所以,把所有逻辑放在一个文件里,避免无谓的脚手架,每隔一阵子就全部推倒重来几次 :)
先来给大家看一个省流版,后面详细为大家奉上各个 CC 的细节。
1)Control Loop
- 保持一个主循环(最多一条分支)+ 一份消息历史。
- 大量使用小模型。所有场景。所有时间。
2)Prompts
- 用 claude.md 模式协作并记录用户偏好
- 使用特殊的 XML 标签、Markdown、大量示例
3)Tools
- LLM 搜索 >>> RAG 搜索
- 工具设计的高低抽象取舍(High vs Low level)
- 让 Agent 自己管理 todo list
4)Steerability(可控性)
- 语气和风格
- 很遗憾,“PLEASE THIS IS IMPORTANT” ,仍然是 SOTA
- 写出算法,附带启发式和示例
Claude Code 在每个环节都选择架构上的简洁:一个主循环、简单的搜索、简单的 todo 列表……要抵抗“过度工程化”的冲动,给模型搭个好舞台,让它自由发挥。是不是又回到了“端到端自动驾驶”的老梗?是的,苦涩教训依然成立。
1.Control Loop 设计
1)保持单一主循环
记住,可调试性 >>> 花哨的多 Agent 拼图。
尽管多 Agent 系统很火,但 CC 只有一个主线程。它会定期用不同提示词总结 git 历史、压缩消息历史、生成一些有趣的交互元素。但除此之外,它就是一份简单的消息列表。处理层级任务时,CC 会“克隆”自己作为子 agent,但子 agent 无法再继续派生,最多一层。执行结果作为“tool response”并回到主循环。
简单任务靠迭代工具调用即可,复杂任务才会触发“最多一条分支”的子 agent + todo list 机制。这样既能拆解问题,又不会偏离最终目标。
我高度怀疑大多数应用真的需要多 Agent 系统。每加一层抽象,系统更难 debug,更重要的是,你也偏离了“靠模型本身不断进化”的大趋势。
2)小模型无处不在
CC 超过 50% 的重要调用都是给 claude-3-5-haiku 的。它用来读大文件、解析网页、处理 git 历史、总结长对话,甚至给每个击键生成一字标签。小模型比大模型(Sonnet 4、GPT-4.1)便宜 70-80%,该用就用,别心疼。
2.Prompts
Claude Code 的提示词非常复杂,充满启发式、示例和“重要提醒”。系统 prompt ~2800 tokens,工具 prompt 高达 9400 tokens。
用户请求里总是包含 claude.md 文件(1000-2000 tokens)。系统提示里还有语气风格、主动性、任务管理、工具使用策略、当前目录、平台/OS 信息、最近提交等。
一定要去读完整提示!这里,小编索性帮大家扒下来了 CC 的系统提示词和工具提示词。大家可以拷贝研究下。
复制1)claude.md:共享上下文与偏好
几乎所有 Coding Agent 都有 context 文件(Cursor Rules / claude.md / agent.md)。有无 claude.md,Claude Code 的表现判若两人。它能传递代码库之外的上下文,固化用户偏好。例如,强制跳过某些目录、指定使用特定库。CC 每次请求都会附带完整 claude.md。
我们在 MinusX 也搞了 minusx.md,正在成为默认的团队/用户偏好配置。
2)特殊 XML 标签、Markdown、示例
CC 广泛使用 XML 标签和 Markdown 来组织 prompt。常见标签有:
- <system-reminder>:提醒 LLM 某些状态,但不要显式告诉用户
示例:
复制- <good-example> / <bad-example>:对比式示例,明确“走哪条路才对”
示例:
复制Markdown 用于分割系统提示的部分:Tone、Style、Code style、Task Management、Tools 等。
3.Tools
正如前文所说,CC 的工具 prompt 多达 9400 tokens。
1)LLM 搜索 >> RAG 搜索
CC 和大多数 agent 不同,它不依赖 RAG,而是像人一样搜索代码库,利用复杂的 ripgrep、jq、find 命令。因为 LLM 本身理解代码,能用高级正则定位任意片段,有时直接用小模型读完整文件。
RAG 理论上好,但引入了大量隐藏失败模式:相似度函数、reranker、chunk 策略、大 JSON 如何处理……而 LLM Search 就像你自己翻文件一样,看看几行再决定要不要读更多。更重要的是,这是可 RL 学习的方向,未来大厂会重点发力。
2)工具设计:高 vs 低抽象
工具到底给“泛用能力”还是“低层级操作”?答案是——都要有。
CC 有低层(Bash、Read、Write)、中层(Edit、Grep、Glob)、高层(Task、WebFetch、ExitPlanMode)。例如,虽然能直接用 bash grep,但因为 grep/glob 用得太多,单独做成工具更稳。WebFetch 这种高层工具则高度确定性,避免 LLM 瞎折腾低级操作。
工具描述里有大量示例,系统 prompt 也写明“什么时候用哪个工具”。
3)让 Agent 自己管理 todo list
长时间跑 Agent 的一个常见问题就是: context rot(上下文腐化):一开始热情满满,后面渐渐跑偏变垃圾。
常见方案:
- 专门的 todo 生成/执行模型
- 多 Agent 接力(PM -> 实现 -> QA)
但我们知道多 Agent 接力很糟糕。CC 的做法是——todo list 由模型自己维护。模型被强烈提示要频繁参考 todo list,同时也能随时调整,丢掉或插入新的事项。这正好利用了 LLM 的 interleaved thinking 能力,既保持目标感,又具备灵活性。
图片
4.可控性
1)语气与风格
Claude Code(CC)会明确地尝试控制代理的“审美行为”。在系统提示词(system prompt)里有专门的语气、风格和主动性部分——充满了规则和示例。这就是为什么 Claude Code 在评论和回应中会显得“有品味”而且“积极”的原因。我的建议是,直接把这部分大段内容原封不动地抄到你的应用里。
语气与风格的几个示例:
- 重要: 除非用户要求,否则不要加任何不必要的开头或结尾(比如解释你写的代码,或总结你采取的行动)。不要主动补充代码解释或总结,除非用户明确提出需求。
- 如果你不能或不打算帮助用户完成某件事,请不要解释原因,也不要讲可能导致什么结果。因为这会显得说教且令人烦躁。
- 只有在用户明确要求时才使用表情符号。否则避免在任何交流中使用 emoji。
图片
2)“THIS IS IMPORTANT” 依然是当前的最佳实践
很遗憾,Claude Code 在“让模型不要做某件事”方面也没有更好的办法。用 IMPORTANT(重要)、VERY IMPORTANT(非常重要)、NEVER(绝不要)、ALWAYS(始终要) 仍然是最有效的手段。未来模型应该会更容易被引导,避免这种“粗暴”的做法。但在现阶段,CC 大量使用了这种方式,你也应该如此。
一些示例:
- IMPORTANT:不要添加任何注释,除非用户要求。
- VERY IMPORTANT:你必须避免使用 find 和 grep 这样的搜索命令。替代方案是使用 Grep、Glob 或 Task 来搜索。你必须避免使用 cat、head、tail、ls 等命令来读取文件,而要用 Read 和 LS 工具。如果你仍然觉得必须要运行 grep,停下!始终要先用 ripgrep(rg)。
- IMPORTANT:绝对不要为用户生成或猜测 URL,除非你非常确定这些 URL 是为了解决编程问题。你可以使用用户在消息中提供的 URL,或者使用本地文件中的 URL。
图片
3)写出算法(带启发式规则和示例)
识别 LLM 需要执行的最关键任务,并为它写出算法,这一点极其重要。
你可以尝试“角色扮演”,把自己当作 LLM,带着示例一步步走流程,明确写出所有决策点。
如果能做成流程图会更好。这样能帮助结构化决策过程,并让 LLM 更容易遵循。
要绝对避免的一点是:把提示写成一大堆 “该做 / 不该做” 的杂乱集合。
- 这类规则很难管理和相互排斥;
- 一旦提示长度达到几千 token,就必然会出现冲突;
- LLM 会因此变得非常脆弱,新的用例也很难加入。
Claude Code 的系统提示里,在 任务管理(Task Management)、执行任务(Doing Tasks) 和 工具使用策略(Tool Usage Policy) 部分,都明确列出了要遵循的算法。这些部分还包含了大量启发式规则和各种情境下的示例。
四、为什么要关注大厂的提示词?
在 LLM 的“可控性”设计里,很多工作其实是在逆向工程它们后训练 / RLHF 的数据分布。
- 你应该用 JSON 还是 XML?
- 工具描述要放在系统提示里,还是放在工具列表里?
- 要不要包含应用的当前状态?
观察大厂在它们自家应用里的做法,可以给你很好的参考。Claude Code 的设计非常有“主见”,拿来借鉴,会帮你更快地确定方向。
五、CC风格的Agent:简单且强大
再强调一次:保持简单。复杂的脚手架框架只会让问题更多。
Claude Code 让我真正相信,“Agent”其实可以既简单又非常强大。我们已经把其中很多经验吸收到 MinusX 里了,还在持续加入更多。
所以,把自己的 LLM 代理“Claude 化”,也许是一条不错的构建和优化路线!
如果你想要适用于 Metabase 的、可训练的 Claude Code 风格的数据代理,可以看看 MinusX,或者直接约个 demo。
祝你玩得开心(Claude 风格的编程快乐)!
好了文章到这里就结束了,这里小编想补充两点。
一来,其实 Claude Code 偶尔也会启动并行的 agents,只是在有明确提示要求时,会做得更好。
二来,“claude.md 模式”是真的火,现在几乎所有的 AI 工具都会在每次请求时附带整个指令文件。据一位 Reddit 网友表示,这也不是 Claude Code 的新东西,几乎可以肯定 GitHub Copilot 的指令文件早就一直是这么做的。
CC 为什么如此好用?除了简单的循环控制逻辑、提示词用法以外,还有哪些?评论区交给各位大佬们了。
参考链接:
https://minusx.ai/blog/decoding-claude-code/
https://www.reddit.com/r/ClaudeAI/comments/1myw74x/analyzed_months_of_claude_code_usage_logs_tell/