Harness বনাম context engineering: harness engineering, prompt ও context engineering-এর পার্থক্য

সংক্ষেপে: একই কাজের তিনটি স্তর

Prompt engineering উত্তর দেয় «কীভাবে চাইব», context engineering উত্তর দেয় «মডেলের এখন কী জানা দরকার», আর harness engineering উত্তর দেয় «এজেন্ট কোন পরিবেশে কাজ করে এবং কীভাবে জানে যে সে ভুল করেছে»। এগুলো প্রতিযোগী পদ্ধতি নয়, বরং একটির ভেতরে আরেকটি বসা স্তর: ভালো prompt ভালো context-এর অংশ, আর সুচিন্তিত context harness-এর একটি উপাদান।

বিভ্রান্তি আসে কারণ তিনটিই মডেলের আচরণ বদলায়। কিন্তু তাদের লিভার আলাদা। এজেন্ট test চালাতে না পারলে prompt-এর যেকোনো শব্দবন্ধ তা ঠিক করবে না। সে গতকালের সিদ্ধান্ত ভুলে গেলে সমস্যা অনুরোধের শব্দে নয়, অবস্থা কোথায় রাখা হয়েছে সেখানে। Harness বনাম context engineering-এর পার্থক্য বুঝলে সপ্তাহের পর সপ্তাহ বাঁচে: যেখানে পরিবেশ ভাঙা, সেখানে আর নির্দেশনা বারবার লিখতে হয় না।

Prompt engineering: একটি অনুরোধের শব্দচয়ন

Prompt engineering হলো অনুরোধের লেখা নিয়ে কাজ: ভূমিকা, কাজ, উত্তরের ফরম্যাট, উদাহরণ (few-shot), সীমা ও ধাপের ক্রম। এর কাজের একক একটি মডেল-কল। ফল বিচার হয় উত্তর দেখে: ঠিক কি না, ফরম্যাট ঠিক কি না, মডেল পথ হারিয়েছে কি না।

প্রচলিত কৌশল:

• আউটপুটের ফরম্যাট স্পষ্টভাবে বর্ণনা করা (JSON স্কিমা, সারণি, তালিকা);
• ২–৩টি «ইনপুট → সঠিক আউটপুট» উদাহরণ দেওয়া;
• উত্তরের আগে ধাপে ধাপে যুক্তি চাওয়া;
• নির্দেশনা ও ডেটাকে স্পষ্ট বিভাজক দিয়ে আলাদা করা;
• কী করা যাবে না তা তালিকাভুক্ত করা।

Prompt engineering «এক ইনপুট — এক উত্তর» ধরনের কাজে ভালো চলে: শ্রেণিবিভাগ, ডেটা বের করা, অনুবাদ, টেমপ্লেট অনুযায়ী লেখা। এর সীমা দেখা যায় যখন মডেল কাজ করতে শুরু করে: টুল কল করা, ফাইল বদলানো, কয়েক ডজন ধাপ একটির পর একটি চালানো। সেখানে গুণমান আর একটি বাক্যের ওপর নির্ভর করে না, নির্ভর করে মডেলকে ঘিরে থাকা সবকিছুর ওপর।

Context engineering: মডেলের জানালায় কী ঢুকবে

Context engineering হলো প্রতিটি ধাপে প্রসঙ্গ-জানালার বিষয়বস্তুর ব্যবস্থাপনা। জানালা সীমিত, আর দীর্ঘ সেশনে এজেন্ট জমায় কমান্ডের আউটপুট, ফাইলের বিষয়বস্তু ও কথোপকথনের ইতিহাস। লক্ষ্য: প্রতিটি মুহূর্তে জানালায় যা দরকার তা থাকবে, এবং অতিরিক্ত কিছু থাকবে না।

এর মধ্যে আছে:

• নির্বাচন: কাজের জন্য কোন ফাইল, নথি ও কোডের অংশ লোড হবে (অনুসন্ধান, RAG, প্রয়োজনমতো পড়া);
• সংকোচন: দীর্ঘ ইতিহাসের সারসংক্ষেপ, কমান্ড-আউটপুট ছাঁটা, সেশন ঘনীভূত করা;
• কাঠামো: নির্দেশনার ফাইল সূচির মতো, আর বিস্তারিত আলাদা নথিতে, যা প্রয়োজনে এজেন্ট খোলে;
• আইসোলেশন: উপকাজকে নিজস্ব পরিষ্কার প্রসঙ্গসহ subagent-এ সরানো, যাতে মূল ধারা দূষিত না হয়।

Context engineering-এর মেট্রিক: এজেন্ট কি ঠিক সময়ে প্রয়োজনীয় নিয়ম বা তথ্য খুঁজে পেয়েছে, এবং সে আবর্জনায় ডুবে যায়নি কি না। এর চেনা লক্ষণ: নিয়ম CLAUDE.md-এ লেখা, কিন্তু এজেন্ট তা লঙ্ঘন করে, কারণ ফাইলটি পাঁচ পাতার আর নিয়মটি টোন ও টিম-লিডের পছন্দের স্টাইলের ভিড়ে হারিয়ে গেছে।

Harness engineering: মডেলকে ঘিরে থাকা সবকিছু

Harness («লাগাম») হলো সেই পরিবেশ যেখানে এজেন্ট কাজ করে। তার ভেতরে মডেল একটি উপাদান, যা চক্রে একবার ঢোকে। বাকি সবকিছু — নির্দেশনা, টুল, পরিবেশ, অবস্থা ও প্রতিক্রিয়া — নকশা করে ইঞ্জিনিয়ার। Harness engineering নিশ্চিত করে যে এজেন্ট শুধু কোড লিখতে পারে না, সে সেটি চালাতে, যাচাই করতে, নিজের ভুল জানতে এবং পরের সেশনে ঠিক সেখান থেকে কাজ শুরু করতে পারে।

Harness-কে সহজে পাঁচ উপাদানে ভাগ করা যায়:

এই কাঠামোয় context engineering বাস্তবে প্রথম দুটি উপাদানের ভেতরে থাকে: সে ঠিক করে নির্দেশনা ও টুলের আউটপুট কীভাবে জানালায় ঢোকে। Harness যোগ করে এমন জিনিস, যা প্রসঙ্গে ঢোকানো যায় না: কার্যকর যাচাই-কমান্ড, পুনরুৎপাদনযোগ্য পরিবেশ, পুনরায় চালু হওয়ার পরও টিকে থাকা অবস্থার ফাইল।

তুলনার সারণি

প্রম্পট ও প্রসঙ্গ কেন যথেষ্ট নয়

একটি চেনা গল্প: দল দেখল এজেন্ট প্রায়ই ভুল করছে এবং এক সপ্তাহ ধরে পাঁচ পাতার AGENTS.md লিখল। এজেন্ট তবুও commit-এর আগে linter চালায় না। কারণ লেখায় নয়: এজেন্টের প্রয়োজনীয় অনুমতিসহ shell প্রবেশাধিকার নেই, আর image-এ linter ইনস্টলই করা নেই। এটি টুল ও পরিবেশের সমস্যা, কিন্তু সারানো হয়েছে নির্দেশনা দিয়ে।

দ্বিতীয় গল্প: এজেন্ট একই bug তৃতীয়বার একইভাবে ঠিক করছে, কারণ পুনরায় চালু হওয়ার পর সে মনে রাখে না কী চেষ্টা হয়েছে। এখানে সেশনের ভেতরের context engineering সাহায্য করে না: জানালা পরিষ্কার হয়ে যায়। দরকার অবস্থার উপাদান — একটি ফাইল যেখানে এজেন্ট চেষ্টা ও সিদ্ধান্ত লেখে, এবং শুরুতে তা পড়ার নিয়ম।

তৃতীয় গল্পটি সবচেয়ে ব্যয়বহুল: এজেন্ট লিখল «সম্পন্ন», unit test সবুজ, কিন্তু ফিচার কাজ করে না। «সাবধানে যাচাই করো» ধরনের কোনো prompt বা প্রসঙ্গে অতিরিক্ত নথি এজেন্টকে স্বাধীন যাচাই দিতে পারে না। সেটি আসে শুধু মেশিনের প্রতিক্রিয়া থেকে: end-to-end test, যাচাই-স্ক্রিপ্ট, অথবা সম্পাদকের যুক্তিতে প্রবেশাধিকারহীন আলাদা মূল্যায়নকারী।

সাধারণ সিদ্ধান্ত: prompt ও context প্রভাবিত করে মডেল কী ভাবে। Harness প্রভাবিত করে মডেল কী করতে পারে এবং কাজের পর সে কী জানতে পারে।

মডেল বদলালে কেন সমস্যা মেটে না

অস্থির এজেন্টের প্রতিক্রিয়া সাধারণত হয় আরও শক্তিশালী মডেল নেওয়া। এতে সাধারণত সমস্যা মেটে না: একই মডেল ভালোভাবে গড়া repository-তে আত্মবিশ্বাসী সিনিয়রের মতো কাজ করে, কিন্তু যাচাই-কমান্ড ও stack-এর বিবরণ ছাড়া repository-তে দিশাহারা হয়। শক্তিশালী মডেল আপনার দলের কনভেনশন আন্দাজ করতে পারবে না, এমন database-এ প্রবেশাধিকার পাবে না যা নেই, আর ভাঙা migration-এর কথা জানবে না যদি কেউ তা চালায়নি।

নতুন মডেল আসার সঙ্গে harness পুরনো হয়ে যায় না। নির্দেশনা, পুনরুৎপাদনযোগ্য পরিবেশ ও যাচাই যেকোনো মডেলের দরকার। বদলায় শুধু কতটা হাতে-ধরে নির্দেশনা বাদ দেওয়া যায়: শক্তিশালী মডেলের জন্য invariant যথেষ্ট («ডেটা সীমানায় যাচাই হয়»), ধাপে ধাপে নির্দেশ নয়।

কোন স্তর ঠিক করতে হবে, কীভাবে বুঝবেন

লক্ষণ দেখে রোগ নির্ণয় পরীক্ষা-নিরীক্ষার চেয়ে দ্রুত:

Harness শুরু করবেন কোথা থেকে

শূন্য থেকে গড়লে ব্যবহারিক ক্রম: প্রতিক্রিয়া → নির্দেশনা → অবস্থা → পরিবেশ → টুল। প্রতিক্রিয়া আগে, কারণ এটি ছাড়া অন্য পরিবর্তনের প্রভাব মাপা যায় না। যতক্ষণ এমন কোনো কমান্ড নেই যা সৎভাবে বলে «কাজ করছে কি না», ততক্ষণ নির্দেশনার প্রতিটি উন্নতি শুধু চোখের আন্দাজে বিচার হয়।

ন্যূনতম শুরু দেখতে এমন:

# AGENTS.md (অংশ)
## কীভাবে যাচাই করবেন
- make check   # lint, type, unit test
- make e2e     # end-to-end পরিস্থিতি
ফিচার তখনই প্রস্তুত, যখন উভয় কমান্ড কোড 0 নিয়ে শেষ হয়।

## নিয়ম
- MUST: সব SQL query parameterized
- MUST: commit-এর আগে make check চালাও
- পেমেন্টের বিস্তারিত: docs/payments.md (কাজ পেমেন্ট ছুলে পড়ো)

শেষ লাইনটি লক্ষ করুন: এটাই harness-এর ভেতরের context engineering। প্রবেশ-ফাইলটি মানচিত্র, পাঠ্যবই নয়; বিস্তারিত «কখন» শর্তে লোড হয়।

প্রতিটি অংশের অবদান কীভাবে মাপবেন

Harness-এর একটি মেট্রিক আছে, যা প্রম্পটের নেই: যে কাজগুলোকে এজেন্ট «সম্পন্ন» বলেছে কিন্তু স্বাধীন যাচাই নিশ্চিত করেনি, তাদের অনুপাত। এটিকে বলা হয় verification gap। ১০টি কাজ পরপর নিন, প্রতিটির পর লিখুন এজেন্ট «সম্পন্ন» বলেছিল কি না এবং যাচাই পাস করেছিল কি না — পরিবর্তনের পর তুলনার জন্য একটি সংখ্যা পাবেন।

কোন উপাদানের প্রভাব আছে তা জানতে ablation ব্যবহৃত হয়: মডেল ও কাজের সেট একই রেখে harness-এর একটি অংশ বন্ধ করে মান কতটা কমে তা দেখা হয়। দুটি বিষয় মনে রাখুন। ablation দিয়ে শুরু করবেন না, শুরু করুন ব্যর্থতার লগ দিয়ে: কোন স্তরে ভাঙল তা চিহ্নিত করলে বাধা দ্রুত ধরা পড়ে। আর শূন্য পতন প্রমাণ করে না যে উপাদানটি অপ্রয়োজনীয়: হয়তো এই কাজের সেট কখনো তা ব্যবহার করেনি।

সাধারণ ভুল

• Harness মানে একটি prompt ফাইল ভাবা। নির্দেশনা পাঁচটির একটি উপাদান মাত্র। রেসিপির তাক দেখে রান্নাঘর হয় না।
• টুলের অভাব লেখা দিয়ে সারানো। «সবসময় test চালাও» অকেজো, যদি এজেন্টের পরিবেশে test চালানোই না যায়।
• নির্দেশনা ফোলানো। প্রবেশ-ফাইল যত লম্বা, গুরুত্বপূর্ণ নিয়ম না-পড়া হওয়ার সম্ভাবনা তত বেশি। গুরুত্বপূর্ণ নিয়মকে চালানো যায় এমন যাচাইয়ে বদলান।
• এজেন্টের নিজের প্রতিবেদনে বিশ্বাস করা। নিজের কাজ মূল্যায়নকারী মডেল বাড়িয়ে ধরতে ঝোঁকে। যাচাই করবে স্ক্রিপ্ট বা পরিষ্কার প্রসঙ্গসহ আলাদা এজেন্ট।
• একবার harness গড়ে ছেড়ে দেওয়া। কোডের মতো harness-ও পুরনো হয়: নিয়ম বাস্তব থেকে সরে যায়, কমান্ড বদলায়। নিয়মিত পর্যালোচনা দরকার।

সারসংক্ষেপ

Prompt engineering সূত্রবদ্ধ করে, context engineering মডেলের জানালায় তথ্য বাছে, আর harness engineering পুরো এজেন্ট-পরিবেশ গড়ে: টুল, পরিবেশ, অবস্থা ও যাচাই সহ। এজেন্ট যখন দীর্ঘ সময় ধরে কাজ করে এবং নিজেই কোড বদলায়, তখন harnessই নির্ধারক: সে «এজেন্ট বলল সম্পন্ন» কে «ব্যবস্থা যাচাই করেছে এটি কাজ করে» বানায়। তাই harness বনাম context engineering বিতর্কে বিকল্প একটি নয়: context harness-এর অংশ, আর কোন উপাদান ঠিক করতে হবে তা লক্ষণ দেখায়। বিষয়টি হাতে-কলমে harness engineering কোর্সে একটি পূর্ণ পেমেন্ট ব্যাকএন্ড প্রকল্পে শেখানো হয়।