国外大神逆向了 Claude Code,发现它好用的秘密 (English)

Generated: 2026-06-21 01:35:31

---

I spent months studying AI agents, only to realize that I'd been heading in the wrong direction from the very start. A month ago, I noticed something striking: using the same model, Claude Code performed like a seasoned assistant, while my own agent floundered like a beginner. I tried countless open-source projects that claimed to replicate it, but the results always fell short. For a while I convinced myself they must be using a proprietary model with some secret sauce.

Then I read a reverse-engineering analysis and realized my entire approach was backwards. I spent three days validating those findings with a TypeScript project—20,000 lines of code, five typical tasks, each run three times and averaged. The results were eye-opening.

Here are the pitfalls I fell into, and what I learned.

---

First Counter‑Intuition: More than half the tasks are handed off to a small model.

I used to believe in "brute force"—throw Sonnet or even Opus at everything, because only the top‑tier model would be reliable. But the reverse engineering showed that over half of Claude Code's calls used the small model Haiku.

I didn't believe it, so I checked my own bills and found I was paying much more. I ran a blind test: had Sonnet and Haiku each read a 3,000‑line file and summarize its function list. My colleagues couldn't tell which response was from which model. Haiku took only 60% of Sonnet's time and cost only 20% as much.

Reading large files, parsing web pages, processing Git history, summarizing long contexts—these high‑frequency tasks are plenty for Haiku. Even the "processing..." hints in the UI are generated by Haiku.

So don't idolize the most expensive model. Categorize your tasks first. Let a small model handle the high‑frequency simple work—the money you save can go a long way.

---

Second Counter‑Intuition: It doesn't rely on the model's memory at all.

Many agents lose their memory in long conversations. They either truncate context or simply compress it. When debugging a bug that spans a dozen files, by the second half they've forgotten what they changed earlier.

Claude Code treats the file system as external storage. Observations are written directly to files; the context only keeps references. During a debugging process that required multiple file edits, a normal agent started spinning its wheels in the second half, but Claude Code used a TodoWrite tool to record each step, so progress was clear at a glance.

Also, when handling a continuous dialogue, it processes from the most recent assistant response backward instead of scanning from the beginning. Under high‑frequency calls, this gave a noticeable performance boost.

The method is simple but effective: don't force the model to memorize everything—make good use of external storage.

---

Third Counter‑Intuition: Prompt engineering isn't about writing an essay; it's about building scaffolding.

My old prompt was something like: "You are a programming assistant. Write code as requested." Claude Code's system prompt is 2,800 tokens, the tool descriptions are 9,400 tokens, and every request also attaches a claude.md file—totaling over 10,000 tokens, not a single wasted word.

The most useful part is claude.md. Placed in the project root, the whole team can maintain it together. It records tacit knowledge that doesn't live in the code: directories that must not be modified, required UI libraries, test commands, code style, and so on.

After I added a claude.md to my own project, the agent stopped touching node_modules, stopped arbitrarily replacing native APIs with Lodash, and its commit messages now follow my team's conventions. And because the file is included in every request, it doesn't forget after a single conversation.

This implementation of long‑term memory is straightforward: write the requirements into the prompt, and repeat them every time.

---

Fourth Counter‑Intuition: Don't give the model a raw shell—give it filtered projections.

Claude Code doesn't give the model a raw shell. Instead, it designs various tools: ReadFile only reads a limited number of lines, Grep only returns matching lines, LS only shows a single level of listing. Each tool is a filtered slice of the file system.

After each tool returns, the system injects a hint that updates the to‑do list and the next step. This helps the model stay focused during long conversations.

I compared this with giving an agent a full shell, and it's easy for the agent to waste energy on irrelevant files. With these limited tools, the behavior becomes much more focused.

So when you design an agent, don't expose the entire file system directly—only provide the information slices needed for the current task.

---

Fifth Counter‑Intuition: Multi‑agent must forbid recursion.

Claude Code has a sub‑agent (General‑Purpose Subagent), but by design it cannot launch another agent—there's no "Agent" tool in the tool list. The sub‑agent's system prompt is different from the main agent's; it only outputs a concise summary, because its output is a report to the main agent, not to the user.

I tried to start a sub‑agent from within a sub‑agent and was directly refused. Some open‑source frameworks don't have this restriction, and the result is often infinite recursion, either timing out or burning through your budget.

For now, LLMs aren't good at delegating to other agents. Opening up recursion is a disaster. Multi‑agent architectures must include recursion limits.

---

Sixth Counter‑Intuition: Security checks must be thorough.

Claude Code's Bash security checks include 23 rules covering command blacklisting, Unicode zero‑width character injection, null‑byte injection, and even a malformed token bypass discovered through HackerOne.

I intentionally slipped a backtick injection that looked harmless into my code, and it was blocked. The agent frameworks I usually use don't have this level of protection.

If you're letting your agent execute shell commands, you can't skimp on security configuration.

---

From my test results, the difference was clear:

Task completion rate went from 65% to 95% (after the prompt explicitly said "must continue until the problem is solved"). Average cost per task dropped from $0.32 to $0.11 (thanks to the small model handling the load). Memory confusion in long conversations went from frequent to rare. The misoperation rate fell from 30% to near zero. Security protection went from nothing to solid, and runaway recursion never happened again.

---

Here's what I learned:

• Don't worship the strongest model. Categorize your tasks and let a small model handle the high‑frequency grunt work.
• Use a mechanism like claude.md to hardcode long‑term preferences, instead of expecting the model to guess them each time.
• Design tools as filtered projections that only provide the information needed for the current task.
• Don't skimp on security, especially when shell execution is involved.
• Multi‑agent architectures must restrict recursion.

What's truly worth learning from Claude Code isn't what it does—it's what it chooses not to do. It doesn't do complex orchestration (a single‑threaded while loop is enough). It doesn't do vector search (regex is sufficient). It doesn't cram in too much context (external files do the job instead). This design restraint is what makes it work so well.

If you're building an agent, think carefully about these design principles. They matter more than copying code. When your agent no longer relies on an all‑powerful terminal, no longer unconditionally trusts the biggest model, and no longer permits unlimited recursion, its behavior will improve dramatically.

True intelligence is knowing what not to do.