深度解析 Claude Code 在 Prompt / Context / Harness 的设计与实践
深度解析 Claude Code 在 Prompt / Context / Harness 的设计与实践
来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, OpenClaw, 记忆系统, 办公效率, 网络安全, 编程, 芯片, 大模型
原文链接： https://mp.weixin.qq.com/s/YgGW92VBP8s846yzIxjVWQ
摘要
阿里妹导读 文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。 背景 前几天写了一篇对OpenClaw的深度解析文章《深度解析 OpenClaw 在 Prompt / Context / Harness 三个维度中的设计哲学与实践》，深入探讨了一下OpenClaw在Prompt Engineering（提示词工程）、Context Engineering（上下文工程）以及新兴的Harness Engineering（驾驭工程/脚手架工程）等维度上所做的很多可值得学习和落地工作。Claude Code是一个非常好用的AI Coding Agent，我在使用的时候经常会感觉...
核心内容
阿里妹导读
文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
背景
前几天写了一篇对OpenClaw的深度解析文章《深度解析 OpenClaw 在 Prompt / Context / Harness 三个维度中的设计哲学与实践》，深入探讨了一下OpenClaw在Prompt Engineering（提示词工程）、Context Engineering（上下文工程）以及新兴的Harness Engineering（驾驭工程/脚手架工程）等维度上所做的很多可值得学习和落地工作。Claude Code是一个非常好用的AI Coding Agent，我在使用的时候经常会感觉到令人“Amazing”的时候，因为其对长程任务、复杂度较高的任务完成的是比较出色的，这里面除了Claude Opus4.6基座模型本身的强大之外，Claude Code这个CLI程序里的工程设计也绝对是“顶级”的，因为你会发现在Claude Code之外的其他地方使用Claude API的时候，相比Claude Code也会感觉有所逊色，这就说明在模型之外，Claude Code的很多设计也是极其“增色”的。那么，这就引起了我对Claude Code具体实现的好奇心了，还是老样子，我的视角从来不在具体的前后端工程实现上，而是关注“如何设计一个好用的Agent系统”，因此，我会和之前分析 OpenClaw 一样，从Prompt Engineering、Context Engineering和Harness Engineering这三个维度展开，来分析 Claude Code 的设计思路，提炼出其中可以给我们设计Agent系统过程中，能够复用的方法论。声明一下：本文所分析的所有信息均来自于网络他人整理的公开信息，仅供学习研究之用，无任何其他用途。Prompt Engineering → Context Engineering → Harness Engineering被称作是现代AI系统的三大关键阶段，分别聚焦于“如何说”、“让AI看什么”以及“构建怎样的运行环境”，三者层层递进，共同致力于提升大模型在复杂任务中的可靠性与可控性。比如说，我想做一个95分的Agent系统，直接通过Prompt Engineering拿到90+分是非常不现实的，顶多可以实现70+分，通过Context Engineering可以将其提高到80~85分，最后再通过Harness Engineering的约束，才可以再将其提升到90~95分。关于这些方面的内容，大家可以阅读我之前的文章《深度解析 OpenClaw 在 Prompt / Context / Harness 三个维度中的设计哲学与实践》，里面有比较详细的介绍。那么，接下来让我们看看Claude Code里面在Prompt/Context/Harness三个维度上的关键设计，以及与OpenClaw对比有哪些相同的地方，又有哪些不同的地方。
Prompt Engineering：静态与动态信息的组装
首先，我们先看Claude Code最基础的Prompt Engineering（提示词工程）部分。关于“如何写好Prompt”这类话题，相关的最佳实践已经不胜枚举。但如果我们把视角拉回到Claude Code这样成熟的Agent系统实践中，会发现“Prompt Engineering”的内涵其实早就已经发生了质的变化：它不再仅仅是针对单次任务撰写一段固定的System Prompt，而是一套复杂的、动态的Prompt组装机制。很多人容易陷入一个误区，认为写个漂亮的“提示词”就是做好了提示词工程，但实际上，真正的“工程”体现在实际生产环境中，提示词是如何根据身份人设、系统行为、安全守则、任务要求、工具规范、Skill要求、约束条件等等动态信息进行实时拼接和组装的，以适应更加复杂多变的任务场景。这也正是为什么行业内越来越多人开始将关注点从单纯的“提示词如何写好”转向更宏观的“提示词如何组装”的原因所在。Claude Code的System Prompt和OpenClaw一样，是一个多层级、动态组装的过程。它由多个文件协同工作，最终拼装成一个字符串数组然后发送给Claude大模型的API接口。整个组装流程就像搭积木一样：先放好固定的底座（静态内容），再根据当前环境和用户配置，往上叠加各种积木块（动态内容），最后把整个积木塔完整，就是最终的System Prompt。当然，这也不是说就可以不关注Claude Code的System Prompt本身写的内容了，虽然说我要做一个95分的Agent系统，可以通过Prompt + Context + Harness的方式实现，但是Prompt一定是这三者的基石，如果没有一个70+分的底子，即使你再怎么设计和调优Context、Harness，Agent的基线已经拉低了，因此，一个好的Prompt是绝对的效果保障和底气。通过对Claude Code的深入学习和分析，我一直在感叹，Anthropic真的把很多细节做的非常的细致，“细节决定成败”这句话体现的淋漓尽致，这种极致的产品体验背后其实就是“极致的工程优化”和“细节打磨”，这种精神值得所有AI产品或项目的开发者们学习。
System Prompt的动态组装过程
首先，我们来看一下，System Prompt是如何一步一步组装起来的。
第1步：QueryEngine发起请求
当用户输入消息后，在QueryEngine.ts 里的 ask()函数就开始启动，这是Query引擎的主入口：
-
-
-
-
QueryEngine.ask() → fetchSystemPromptParts() // 获取默认 prompt + 用户上下文 + 系统上下文 → buildEffectiveSystemPrompt() // 根据优先级选择最终 prompt → query() // 发送到 API
第2步：获取三大组件
在queryContext.ts中有个函数叫fetchSystemPromptParts()，它会并行去获取三样东西：1.defaultSystemPrompt — 调用constants/prompts.ts中的getSystemPrompt() 构建的默认 prompt（如果没有自定义 prompt）2.systemContext — 调用context.ts中的getSystemContext() 获取 Git 状态信息3.userContext — 调用context.ts中的getUserContext()获取CLAUDE.md内容 + 当前日期
第3步：组装默认System Prompt
这是最核心的函数，在constants/prompts.ts中的getSystemPrompt()。它把 prompt 分成静态部分和动态部分两大块：
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
...(内容截断，完整内容请查看原文)
本页由自动化脚本生成，待人工审核补充