Harness engineering কী: কীভাবে AI এজেন্টকে কার্যকর কাজের টুলে পরিণত করবেন

সহজ ভাষায় harness engineering

Harness engineering হলো একটি শৃঙ্খলা, যেখানে শেখানো হয় ভাষা মডেলের চারপাশে কীভাবে এমন পরিবেশ গড়তে হয় যেখানে সে বাস্তব কাজ নির্ভরযোগ্যভাবে করতে পারে। Harness শব্দের অর্থ «লাগাম» বা «সাজসরঞ্জাম»: মডেলটি শক্তিশালী, কিন্তু নিজে থেকে সে জানে না কোথায় যেতে হবে, কী ব্যবহার করতে হবে, বা কখন থামতে হবে। Harness সেই শক্তিকে পথ দেখায়।

সবচেয়ে সংক্ষিপ্ত সূত্রটি এরকম:

Agent = Model + Harness

Model হলো ওজন এবং যুক্তি করা ও লেখা বা কোড তৈরির সক্ষমতা। Harness বাকি সবকিছু: system নির্দেশনা ও CLAUDE.md বা AGENTS.md-এর মতো ফাইল, টুলের সেট (shell, ফাইল সম্পাদনা, MCP সার্ভার), এজেন্ট যেখানে কমান্ড চালায় সেই sandbox, সেশনের মধ্যে অবস্থার ফাইল, এবং test, linter ও hook যা এজেন্টকে ভুল সম্পর্কে জানায়। Harness সরিয়ে নিলে যা থাকে তা হলো একটি চ্যাট, যা শুধু লেখায় উত্তর দিতে পারে।

কেন এজেন্ট কখনো «সিনিয়র», কখনো «জুনিয়র»

পরিচিত একটি দৃশ্য: এক রিপোজিটরিতে এজেন্ট অভিজ্ঞ ডেভেলপারের মতো কাজ করে, অন্যটিতে গোলমাল পাকিয়ে ফেলে, গতকালের সিদ্ধান্ত ভুলে যায় এবং যে ফিচার কাজ করে না তাকে «সম্পন্ন» বলে জানায়। প্রথম প্রতিক্রিয়া সাধারণত হয় নতুন মডেলে বদলানো। এতে সাধারণত কাজ হয় না, কারণ দুই ক্ষেত্রেই মডেল একই। পার্থক্যটা পরিবেশে।

এখান থেকেই harness engineering-এর মূল চিন্তাভঙ্গি শুরু হয়: এজেন্ট ভাঙা নয় — ভাঙা হলো তার চারপাশের কাঠামো। এজেন্ট test চালাতে পারে না যদি সেখানে প্রবেশাধিকার না থাকে। যা কোথাও লেখা নেই, তা সে মনে রাখবে না। কোনো যাচাই তাকে না জানালে ফিচারটি ভাঙা, তা সে বুঝবে না। এটা মডেলের «চরিত্র» নয়, নকশার ত্রুটি, এবং এই ত্রুটি নিয়মতান্ত্রিকভাবে সারানো যায়।

দুর্বল harness-এর লক্ষণ

• প্রতিটি নতুন সেশন পরিবেশ ঠিক করে শুরু হয়: ভুল dependency, database চালু হয় না, variable নেই।
• এজেন্ট আগে বাতিল হওয়া সমাধানই আবার বেছে নেয়, কারণ আগের সেশন তার মনে নেই।
• নিয়ম নির্দেশনায় স্পষ্ট লেখা আছে, তবু এজেন্ট তা মানে না।
• «Test সবুজ», কিন্তু ফিচার ভাঙা, কারণ test ভুল জিনিস যাচাই করছিল।
• এজেন্ট একসঙ্গে তিনটি কাজ ধরে, কিন্তু একটিও শেষ করে না।

Harness-এর উপাদান: পাঁচটি সাবসিস্টেম

একটি সাধারণ ভুল হলো harness মানে শুধু একটি prompt ফাইল ভাবা। আসলে এর মধ্যে পাঁচটি প্রক্রিয়া আছে, এবং প্রতিটি নিজের মতো করে ভাঙে।

নির্দেশনা

নির্দেশনা উত্তর দেয়: «এজেন্ট কি প্রয়োজনীয় নিয়মটি খুঁজে পাবে?» ভালো প্রবেশ-ফাইল একটি মানচিত্রের মতো: ছোট একটি সূচি, যেখানে যাচাই-কমান্ড ও কঠোর সীমা থাকে, আর বিস্তারিত থাকে আলাদা নথিতে, যা এজেন্ট দরকার হলে খোলে। ভালো নির্দেশনা invariant ঠিক করে («সব SQL query parameterized»), প্রতিটি লাইনে বাস্তবায়ন বলে দেয় না।

টুল

এজেন্ট শুধু সেটাই যাচাই করতে পারে যেখানে তার প্রবেশাধিকার আছে। সে যদি linter চালাতে না পারে, তবে «commit-এর আগে linter চালাও» নিয়ম কাজ করবে না। টুল যুক্ত হয় এজেন্টের নিজস্ব সামর্থ্যের মাধ্যমে (ফাইল পড়া ও সম্পাদনা, কমান্ড চালানো) এবং MCP-এর মাধ্যমে, যা এজেন্টকে database, browser ও টাস্ক ট্র্যাকারে প্রবেশাধিকার দেয়।

পরিবেশ

পরিবেশ হলো সেই জায়গা যেখানে এজেন্ট কমান্ড চালায়। এটি এক কমান্ডে চালু হওয়া উচিত, সেশনে সেশনে একই থাকা উচিত, এবং ভুলের ক্ষতি সীমিত রাখা উচিত: উৎপাদনে প্রবেশাধিকারহীন sandbox, আলাদা branch বা কাজের কপি, এবং এক মিনিটে সবকিছু আগের অবস্থায় ফেরানোর সুযোগ।

অবস্থা

মডেলের সেশনের মধ্যে কোনো স্মৃতি নেই: যা repository-তে লেখা নেই, তা প্রসঙ্গ-জানালার সঙ্গে হারিয়ে যায়। তাই লক্ষ্য, সম্পন্ন কাজ, নেওয়া সিদ্ধান্ত, বন্ধ পথ এবং পরের ধাপ ফাইলে থাকা জরুরি। পরীক্ষাটি সহজ: নতুন সেশন খুলুন, এজেন্টকে বলুন «চালিয়ে যাও» — দেখুন সে সরাসরি কাজ শুরু করে, নাকি জিজ্ঞেস করে কী করতে হবে।

প্রতিক্রিয়া

Feedback loop হলো সবচেয়ে গুরুত্বপূর্ণ উপাদান। এটি না থাকলে এজেন্ট নিজেই নিজের একমাত্র বিচারক হয়ে যায় এবং সৎভাবেই কাজটি সম্পন্ন ধরে নেয়। Test, type check, প্রতিটি পরিবর্তনের পর চলা linter hook, browser-এ E2E পরিস্থিতি — এসব এজেন্টকে লাল সংকেত ফিরিয়ে দেয়, যখন ভুল ঠিক করা এখনো সস্তা।

Harness একটি চক্র, তালিকা নয়

পাঁচটি উপাদান একটি বন্ধ চক্রের মতো কাজ করে। মডেল নির্দেশনা পায়, টুলের মাধ্যমে পরিবেশে কাজ করে, repository-তে পরিবর্তন আনে, আর যাচাই ফলাফল পরীক্ষা করে। লাল ফলাফল সংশোধনের জন্য মডেলে ফিরে যায়, সবুজ ফলাফল অবস্থায় নথিভুক্ত হয়। অবস্থা আবার পরের সেশনের নির্দেশনা হালনাগাদ করে।

নির্দেশনা → মডেল → টুল → পরিবেশ → পরিবর্তন
                ↑                              ↓
                └──── লাল ── যাচাই ────────────┘
                                     ↓ সবুজ
                                 অবস্থা → (পরের সেশন)

যেকোনো একটি তীর সরালে চক্রটি ঠিক সেই জায়গায় ভেঙে যায়। যাচাই না থাকলে এজেন্ট ভুল টের পায় না। অবস্থা না থাকলে পরের সেশন কাজের বদলে পুরনো কথা খুঁড়তে শুরু করে। তাই একটি উপাদানে বিনিয়োগ অন্য উপাদানের ফাঁক পূরণ করে না: পাঁচ পাতার AGENTS.md অনুপস্থিত test-এর জায়গা নিতে পারে না।

Harness engineering কীভাবে prompt ও context engineering থেকে আলাদা

এই ধারণাগুলো একে অপরের ভেতরে থাকে, একে অপরের প্রতিযোগী নয়।

Prompt engineering নির্দেশনা উপাদানের একটি অংশ। Context engineering নির্দেশনা ও অবস্থা দুটোই ছোঁয়: প্রতিটি মুহূর্তে এজেন্ট কী দেখছে। Harness engineering এমন জিনিসও যোগ করে যা প্রসঙ্গ-জানালায় মোটেই ধরে না: প্রবেশাধিকার, sandbox, test, hook এবং কাজের প্রক্রিয়া। ভালো লেখা prompt-ও কাজে আসে না, যদি এজেন্ট বাস্তবে test চালাতেই না পারে।

Harness কেন দরকার: দীর্ঘ কাজের গাণিতিক হিসাব

সহজভাবে মনে হয়, যে মডেল ৯৫% ধাপ ঠিকভাবে করে সে প্রায় নিখুঁত। কিন্তু এজেন্টের কাজে অনেক ধাপ থাকে, এবং ভুল জমে। ধাপগুলো যদি একে অপর থেকে স্বাধীন হয়, তবে সবগুলো ভুল ছাড়া পার হওয়ার সম্ভাবনা প্রতিটি ধাপের সম্ভাবনার গুণফল:

0.95 ^ 10 ≈ 0.60
0.95 ^ 20 ≈ 0.36
0.95 ^ 50 ≈ 0.08

দশম ধাপে একটিও ভুল ছাড়া পৌঁছায় প্রায় ৬০% চেষ্টা, পঞ্চাশতম ধাপে দশটির মধ্যে একটিরও কম। মডেলের নির্ভুলতা ৯৭%-এ তোলা ব্যয়বহুল এবং আপনার হাতের বাইরে। কিন্তু যে ধাপে ভুল হয়েছে ঠিক সেখানে তা ধরা এবং এজেন্টকে ফিরিয়ে দেওয়া harness-এর কাজ। Feedback loop «এক ভুল পরের ভুল টানে» শৃঙ্খলকে ছোট, সংশোধনযোগ্য ধাপের শৃঙ্খলে পরিণত করে।

উদাহরণ: একই এজেন্ট, দুটি রিপোজিটরি

কাজ: FastAPI-ভিত্তিক payment backend-এ প্রোমো কোড দিয়ে ছাড় যোগ করা।

Harness ছাড়া

এজেন্ট কয়েকটি ফাইল পড়ে, ছাড় হিসাবের একটি ফাংশন ও একটি unit test লেখে, যা শুধু সেই ফাংশনকে আলাদাভাবে যাচাই করে। Test সবুজ, এজেন্ট লেখে «সম্পন্ন»। সে জানত না যে মোট মূল্যের হিসাব অন্য মডিউলে হয়, এবং পুরো checkout পরিস্থিতি চালাতে পারেনি। একদিন পরে জানা যায়, কার্টে ছাড় প্রয়োগই হচ্ছে না।

Harness-সহ

প্রকল্পের মূলে আছে কয়েক ডজন লাইনের AGENTS.md: পরিবেশ কীভাবে চালু করতে হবে, কোন যাচাই-কমান্ড বাধ্যতামূলক, এবং payment-এর স্থাপত্য কোথায় লেখা। পরিবেশ চালু হয় docker compose up -d দিয়ে। Repository-তে একটি পরিকল্পনার ফাইল আছে, যার সমাপ্তির মানদণ্ড: «প্রোমো কোডসহ checkout E2E পরিস্থিতি পাস করে»। প্রতিটি পরিবর্তনের পর hook linter ও type check চালায়, এবং সমাপ্তির আগে এজেন্টকে E2E test চালাতে হয়।

# AGENTS.md (অংশ)
## যাচাই — «সম্পন্ন» বলার আগে বাধ্যতামূলক
make lint        # ruff + mypy
make test        # pytest, unit ও integration
make e2e         # checkout পরিস্থিতি

## MUST
- টাকার হিসাব হবে পয়সায় (int), কখনো float নয়
- সব SQL query parameterized
- উৎপাদনে প্রয়োগ হওয়া migration বদলানো যাবে না

মডেল একই। কিন্তু এখন এজেন্ট প্রকল্পের মানচিত্রের মাধ্যমে মোট মূল্যের মডিউল খুঁজে পায়, E2E test প্রথম চেষ্টাতেই ব্যর্থ হয়, এজেন্ট দেখে ছাড়টি কার্ট পর্যন্ত পৌঁছায়নি, তা ঠিক করে, এবং সবুজ ফল পাওয়ার পরেই প্রতিবেদন দেয়। ফলের এই পার্থক্যটি পুরোপুরি harness-এর কৃতিত্ব।

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

1. লিখুন এজেন্ট কীভাবে নিজের কাজ যাচাই করে: এক থেকে তিনটি কমান্ড যেগুলো তার অবশ্যই চালানো উচিত। Feedback সবচেয়ে বেশি ফল দেয়, তাই এখান থেকে শুরু করুন।
2. পরিবেশ পুনরাবৃত্তিযোগ্য করুন: এক কমান্ডে চালু হবে, এবং দ্রুত আগের অবস্থায় ফেরার উপায় থাকবে।
3. একটি অবস্থার ফাইল বানান: লক্ষ্য, সম্পন্ন কাজ, সিদ্ধান্ত ও বন্ধ পথ, এবং পরের ধাপ।
4. নির্দেশনা ছোট করে মানচিত্রে পরিণত করুন: যাচাই-কমান্ড, কঠোর সীমা, এবং বিস্তারিত নথির লিংক।
5. এজেন্টের ব্যর্থতার লগ রাখুন: প্রতিটি ব্যর্থতায় লিখুন কোন উপাদান তা হতে দিয়েছে। এই লগই বলে দেবে এরপর কী ঠিক করতে হবে।

একটি কাজের অভ্যাস হলো পাঁচটি উপাদানের প্রতিটিকে ১ থেকে ৫ স্কেলে মূল্যায়ন করা, সবচেয়ে দুর্বলটির পেছনে আধ ঘণ্টা দেওয়া, এবং একই পাঁচটি সাধারণ কাজ আগে ও পরে চালানো। এভাবে harness-এর উন্নতি পরিমাপযোগ্য হয়, «অনুভূতি» নয়।

সারসংক্ষেপ

Harness engineering মডেল নিয়ে নয়, মডেলের চারপাশের সবকিছু নিয়ে কাজ: নির্দেশনা, টুল, পরিবেশ, অবস্থা এবং feedback loop। এজেন্টের নির্ভরযোগ্যতা এই চক্রের সবচেয়ে দুর্বল অংশ দিয়ে নির্ধারিত হয়, তাই মডেল বদলালে অস্থিরতা খুব কমই সারে, কিন্তু একটি test বা পরিকল্পনার ফাইল যোগ করলে প্রায়ই সারে। পাঁচটি উপাদান এবং পুরো harness কীভাবে গড়তে হয়, তা হাতে-কলমে harness engineering কোর্সে শেখানো হয়।