Inside a Self-Built Coding Agent: Prompt Assembly, Context Compression, and Multi-Agent Orchestration

I saw this post.

I've been at Ctrip for 4 years, monthly salary around 30,000 RMB, R&D role, and there's basically been no raise. But I'm quite satisfied after all these years, since it's stable and the benefits are good.

In this fast-paced AI era, I truly admire anyone who can say the word "satisfied."

Look around you, isn't everyone caught up in the rat race? A new model drops in the morning and you have to test it; a new workflow emerges at noon and you have to try it. The whole industry's pace is like rushing to catch the last train, everyone pushing forward relentlessly, without stopping.

But this guy says: satisfied, stable, good benefits.

That resonates deeply with me.

These past two years, AI has accelerated the pace so much that people have forgotten one thing — life should still exist. Getting off work on time, no weekend overtime, no replying to messages in the middle of the night — aren't these what we should be pursuing more?

If you ask me, stability is the best posture for learning. Anyway, I can only work and learn new things when my external environment is smooth sailing.

If you also crave stability, and at the same time want to learn some new AI knowledge at a stable pace and rhythm, then the following Agent interview questions are worth a careful read.

(The full text is quite intense, I guarantee you'll learn a lot. Buckle up, let's goooooo~)

Content

PS: PaiCLI is a terminal Agent similar to Claude Code, already open-sourced. If you want hands-on project experience with an Agent, you can refer to it.

GitHub: https://github.com/itwanger/PaiCLI-Python

01. What's special about Claude Code and Codex respectively?

Lao Wang flipped open the interview question and asked directly: "Have you used both Claude Code and Codex? What's special about each?"

"I've used both. These two products have completely different directions."

"Claude Code is a terminal Agent made by Anthropic. Its biggest feature is real-time interaction, perfectly fitting the AI era — you can complete coding work without an IDE. You give it tasks in the terminal, then it reads code, modifies files, runs commands. The whole process is fully visible, and you can interrupt or correct it at any time. As of now, Claude Code is the strongest terminal Agent, bar none."

"Codex is a desktop Agent made by OpenAI, using asynchronous multi-threading, with stronger visualization than Claude Code."

"Personally, I'm a heavy user of both. Claude Code paired with the Opus model is stronger in the text domain and overall architectural capability. For Codex, I prefer pairing it with GPT-5.6 Sol for code development and image generation, and I also hand it tasks that consume a lot of Tokens."

02. What parts make up the prompt input to the model?

"For the Agent you built, how is the prompt input to the model assembled? Which parts must be injected, and which are not?"

"Prompt assembly uses layered concatenation, 9 layers in total, stitched together in a fixed order."

"The first 4 layers are static, unchanged throughout the session."

• The first layer is identity definition, including tool schemas, security policies, and behavioral rules. This layer must be injected; without it, the model doesn't even know who it is, let alone what tools it can use.
• The second layer is the persona layer, controlling tone and style.
• The third layer is the mode layer, loading different instruction sets based on the current execution path — one set each for ReAct, Plan, and Team modes.
• The fourth layer is the approval layer, defining which tool calls require user confirmation.

"The last 5 layers are dynamic, potentially changing every round. Runtime context (date, timezone), project memory, Skills index, context management strategy, and closing instructions."

"What must be injected are the identity layer and the mode layer — the model must know who it is and what execution mode it's currently working in. The persona layer, Skills index, and project memory are not mandatory; the model can still work without them, but the experience will be much worse. For example, without the Skills index, the model wouldn't know what ready-made skills are available to load and would have to figure things out from scratch when encountering problems."

Why should static content be placed at the very front?

"Because of Prompt Caching."

"Prompt Caching hits based on the longest common prefix. The first 4 layers are static content, placed at the very front of the prompt. The prefix for each request round is the same, maximizing the cache hit rate. If dynamic content is inserted at the front, the prefix changes every round, the cache will basically never hit, and the token cost will be several times higher."

03. How is your coding agent different from Claude Code and Codex?

"Claude Code is the benchmark for terminal Agents."

But while using these tools, a question arose — how exactly do these tools work under the hood?

How does it understand my instructions, how does it decide which file to read, how does it judge which tool to call, how does it manage the context of multi-turn conversations?

I found that if I only knew how to use these tools without understanding their underlying design, when the tool performed poorly (e.g., the Agent chose the wrong tool, context lost key information, generated code didn't match the project style), I could only try rephrasing and asking again, without being able to judge from a principle level where the problem lay.

So I decided to implement an Agent CLI from scratch, writing all the core modules — the ReAct reasoning loop, Tool Calling, Memory management, and the MCP protocol — myself.

After finishing, I had source-code-level understanding of every layer of the Agent system. When I went back to using Claude Code, I could clearly feel my ability to command the tool had improved — I knew what kind of instructions would make the Agent understand my intent more accurately, I knew in what scenarios I should manually compress the context, I knew how to design tool description information to improve call accuracy.

04. How is context compression done?

Lao Wang leaned forward and continued asking: "You mentioned context compression, how is it done specifically?"

"Three-layer compression, each layer handles content at different granularities."

"The first layer is tool result truncation. If the content returned by a single tool call exceeds a threshold — for example, a grep command returning several thousand lines — it's directly truncated, keeping the head, tail, and key information, with the middle replaced by a summary. This layer takes effect immediately, processed as soon as the tool returns."

"The second layer is conversation history summarization. When the total token count of the entire conversation approaches the upper limit of the context window, the most recent few rounds of complete conversation are kept, and the earlier history is summarized once using an LLM. The summary retains four types of key information: the user's core request, the operations the Agent has completed, the consensus reached, and unresolved to-dos."

"The third layer is emergency degradation. If the token count still exceeds the limit after summarization compression, non-core context is discarded by priority — Skills index, non-critical memory, low-priority parts of project memory — to free up space for the core conversation."

05. Why adopt a three-layer compression strategy? Is the content compressed at each layer the same?

"The design logic is granularity from fine to coarse, and trigger conditions from loose to strict."

"The first layer handles redundancy at the single-message level, with the loosest trigger condition — every tool return is checked, and truncated if it exceeds the limit. The cost is almost zero, no need to call an LLM."

"The second layer handles expansion at the conversation history level, triggered when the token count exceeds roughly 80% of the context window. For a 200k window, it triggers around 167k. This layer requires one LLM call for summarization, incurring cost, so it doesn't happen too frequently."

"The third layer is the last line of defense, only activated when the first two layers are insufficient. What's discarded is recoverable auxiliary information — the Skills index can be reloaded, project memory can be re-retrieved — core conversation content is not touched unless absolutely necessary."

"The content compressed by the three layers is completely different. The first layer compresses tool output, the second layer compresses conversation history, the third layer discards auxiliary context. If you used just one layer to compress everything indiscriminately, you'd either compress too early and waste context space, or compress too late and directly hit an over-limit error."

06. How to detect and handle unsatisfactory results from over-compression?

"Rely on two signals."

"The first is behavioral anomalies. The model starts repeating things it has already done — for example, reading a file it clearly read ten minutes ago, reading it again. Or the model directly says 'I'm not quite sure what was discussed before,' which means compression has lost key information."

"The second is a drop in task success rate. For the same type of task, if it could be completed before but starts failing after a few rounds of compression, it's highly likely that key content was lost from the context."

"There are three handling methods."

First, dynamically adjust the number of retained rounds. The default is to keep the most recent 3 rounds uncompressed; if an anomaly is detected, temporarily expand to 5 rounds.

Second, key information marking. Requirements explicitly given by the user and confirmed technical plans are marked as non-compressible and skipped during summarization.

Third, back up the original history before compression. If the result is poor, you can roll back to the pre-compression state and re-compress with a more conservative strategy.

07. How is the incremental modification system done? What information needs to be re-injected?

"It uses a Plan review mechanism."

"After the Agent generates an execution plan, the user can review it. If a new feature needs to be added, the user selects 'Supplement Requirements' and passes in the new requirement description. The system takes the original plan and the new requirements together and hands them to the planner to regenerate a plan."

"Three pieces of information are re-injected: the original task description, a summary of completed steps, and the supplementary description of the new requirements. Completed steps are not re-executed; the planner arranges subsequent steps based on the current progress."

Why not just append to the original plan, but re-plan instead?

"Because new requirements might change the dependencies of existing tasks."

"For example, the original plan is 'first create the database table, then write the CRUD interface.' The user supplements: 'add a caching layer.' This isn't simply appending a cache task at the end — the implementation logic of the CRUD interface needs to change: read operations must check the cache before the database, write operations must synchronously update the cache. If you just append, the previously written interface code will be wrong."

"Re-planning allows the planner to see the full picture, rearrange dependencies and execution order, avoiding subsequent steps being built on incorrect premises."

08. What is the flow of a tool call?

Lao Wang flipped a page of his notes and continued asking: "Tell me about tool calling, what's the complete flow?"

"Three stages."

"First stage, the LLM generates a tool_call. After the model sees the tool's schema definition, it decides which tool to call and what parameters to pass based on the current task, outputting a structured tool_call request."

"Second stage, policy approval. Write operations (modifying files, running commands) go through a security check — whether the path is within the allowed range, whether the command is on the blacklist. Operations requiring user confirmation will pause and wait for approval."

"Third stage, execution. A single tool is executed directly; multiple tools can run in parallel, with a thread pool cap of 4 concurrent executions. The execution result is appended to the conversation history as a tool message. After the LLM gets the result, it decides the next step. The whole process is a loop: Generate → Approve → Execute → Result back to model → Continue generating, until the model deems the task complete."

Can Skills replace Tools?

No, the two things are completely different.

Dimension	Tool	Skill
Essence	Executable capability — read files, run commands, search code	Decision knowledge — how to use tools, what strategy, what specifications
Call Method	LLM calls via tool_call protocol	LLM calls load_skill, content injected into the next message round
Return Content	Structured result (file content, command output)	Markdown instructions (prompt-level knowledge)
Lifecycle	Single call, used and gone	Loaded and resides in context, continuously influencing subsequent decisions

"Tool is the hand, Skill is the experience in the brain. You can't use experience to replace a hand for turning a screw, nor can you use a hand to replace experience for judging which screw to turn. The two are complementary, not substitutive."

09. Tell me about your Skills, what are they?

"The core design philosophy is progressive disclosure, loaded in three layers."

"The first layer is the index. Only the Skill's name and a one-sentence description are put into the system prompt, controlled within 4KB, with a maximum of 20 Skills. This layer resides permanently in the context, at very low cost."

"The second layer is the body. After the LLM sees the index, it judges which Skill the current task needs, calls a load_skill tool to pull in the complete instructions, with a single Skill body capped at 5KB. Loaded Skills are placed in an LRU buffer, holding a maximum of 3 simultaneously; excess ones are evicted based on least-recently-used."

"The third layer is reference documentation. Some Skills come with a reference document directory, only loaded when explicitly required by the Skill instructions."

Why not load everything at once?

Because the longer the system prompt, the lower the Prompt Caching hit rate. The vast majority of conversations only use one or two Skills; loading everything means making the user pay token costs for content they won't use.

"Skills have three source priorities: built-in, user-level, and project-level, overridden from low to high. Project-level Skills can override the behavior of built-in Skills with the same name, without modifying the source code."

10. How many times did the model get called for tool usage? How many times for Skills?

"This depends on task complexity, let's talk about a typical scenario."

"For a task like 'add a pagination interface to my project,' the model needs to call tools about 10 to 15 times — reading the project structure, reading existing interface code, reading the database model, writing the new interface, writing tests, running tests, fixing bugs — each step is a tool call. For Skills, it might just load one Skill related to coding standards, once."

"Tool call frequency is much higher than Skill loading, roughly a 10:1 to 20:1 ratio. This is also why Skills use progressive loading — their usage frequency isn't as high as tools, so there's no need to keep them all resident in context."

Scenario Questions

11. Facing a complex task, how does your coding agent make a plan?

Lao Wang capped his pen and changed direction: "Here's a scenario question. If a complex task comes in, how does your Agent make a plan?"

"First, judge whether the task actually needs a plan. Simple tasks — like 'change this variable name' — go directly to ReAct mode, done in one step, no planning needed."

"Complex tasks go to Plan-and-Execute mode. After receiving the user's task, the planner generates a JSON plan with dependency relationships. Each sub-task has an id, description, type, and dependency list."

"After the plan is generated, topological sorting is performed first to confirm there are no circular dependencies. Then tasks are executed in batches based on dependency relationships — tasks without dependencies can run in parallel, those with dependencies wait for their predecessors to complete before starting."

"The user can review the plan before execution, adjust it if they think it's wrong, or supplement requirements for the planner to produce a new proposal."

How is multi-Agent orchestration specifically done?

"In Team mode, there are three roles."

"The Planner is responsible for breaking down the task into an execution plan with dependency relationships, only using its brain, not its hands, and does not call any tools. The Worker is the doer, with an independent conversation history and a complete toolset. Tasks without dependencies in the same batch can be distributed to different Workers for parallel execution, with a default maximum of 2 Workers working simultaneously. The Reviewer is responsible for quality control; after a Worker finishes, the Reviewer checks the output, rejects it if it's not up to standard, with a maximum of 2 rejections."

What are the differences between each sub-Agent?

"The differences lie in two dimensions: system prompt and conversation history."

"Each role has a dedicated system prompt, loaded through different modes — the Planner's prompt tells it 'you are only responsible for breaking down tasks, do not call tools,' the Worker's prompt tells it 'you are responsible for executing specific steps, use tools freely,' the Reviewer's prompt tells it 'you are responsible for checking quality, give a pass or reject judgment.'"

"Conversation histories are completely isolated. Each role only sees its own interaction records. Worker-1 doesn't know what Worker-2 is doing, and the Reviewer can't see how the Planner was thinking. Each role only focuses on information within its own scope of responsibility, keeping the context clean and less prone to mutual interference."

Why design it this way? Can all sub-Agents share tools?

"The tools themselves are shared. The three roles use the same tool registry — 11 core tools plus MCP dynamic tools — technically all roles can access them."

"But the Planner and Reviewer do not call tools. This is constrained by the prompt, not because it's technically impossible. The design intentionally prevents them from touching tools, for the reason of role isolation — if the Reviewer had tool execution permissions, it might find a problem with the Worker's code and decide to fix it itself. After fixing it, it would then review the code it just modified, acting as both player and referee."

"Tool execution authority is concentrated in the Worker's hands; the Planner and Reviewer only make judgments. When problems arise, they're easy to locate — if the code is wrong, look to the Worker; if the plan is poorly decomposed, look to the Planner; if something was missed in review, look to the Reviewer. The boundaries of responsibility are crystal clear."

Ending

In the past, we crammed for interviews with rote-memorized questions, memorizing concurrency, middleware, and design patterns. Now, interviewers ask how prompts are assembled, how context is compressed, what's the difference between Tool and Skill, and how multi-Agent orchestration works.

【The tech stack is changing, interview questions are changing, but one thing hasn't changed — people with a stable mindset learn everything faster.】

AI is redrawing the map of an engineer's capabilities, and this process has only just begun. Don't be anxious, improving a little bit every day is enough.

Follow Second Brother's Agent rote-memorization guide, and get to it.

Keep it up, brothers and sisters.

See you next time.