AI agent-ներ

01Գաղափարը՝ մոդել ցիկլում՝ tools-ով

Chatbot-ը պատասխանում է մեկ անգամ։ Agent-ն աշխատում է կրտսեր գործընկերոջ պես, որին տրվել է նպատակ և գործիքների արկղ․ մտածում է հաջորդ քայլի մասին, օգտագործում է tool, նայում է արդյունքին և շարունակում, մինչև ավարտի կամ խրվի։ Տեխնիկապես դա tool-use API-ն է ցիկլում։ Ուղարկում եք նպատակը գումարած tool-երի սահմանումները, մոդելը պատասխանում է tool call-ով, ձեր կոդն այն աշխատեցնում է և հետ ուղարկում արդյունքը, կրկնում եք, մինչև մոդելն ավարտի իր հերթը։ «Պլանավորումը» հիմնականում մոդելի մտածելն է քայլերի միջև, երբեմն օգնում է նրան խնդրել սկզբում գրել պլան կամ to-do ցուցակ։ Agent-ի որակը կախված է չորս բանից՝ մոդելը, նրան տրված tools-ը, կոնտեքստը, որը նա տեսնում է, և guardrail-ները նրա շուրջ։ Anthropic-ի խորհուրդն արժե կրկնել՝ սկսեք ամենապարզ լուծումից և agent-ային բարդություն ավելացրեք միայն այն ժամանակ, երբ այն հստակ բարելավում է արդյունքները։

• Workflow՝ ձեր կոդն է որոշում քայլերը, LLM-ը լրացնում է մասերը
• Agent՝ LLM-ն է որոշում քայլերը, ձեր կոդը տրամադրում է tools և սահմանափակումներ
• Production համակարգերի մեծ մասը համակցում է երկուսը

02Նվազագույն agent loop

Ահա հիմնական ցիկլը Claude Messages API-ով TypeScript-ում։ Այն շարունակում է կանչել մոդելը, քանի դեռ վերջինս tools է խնդրում, աշխատեցնում է յուրաքանչյուր պահանջված tool և բոլոր արդյունքները վերադարձնում մեկ user հաղորդագրությամբ։ Կարևոր մանրամասներ՝ քայլերի առավելագույն քանակ, որպեսզի շփոթված agent-ը չկարողանա անվերջ ցիկլել, սխալները վերադարձվում են մոդելին որպես tool result՝ is_error-ով, որպեսզի այն կարողանա հարմարվել՝ crash լինելու փոխարեն, և assistant-ի յուրաքանչյուր պատասխանի ամբողջ content-ը ավելացվում է պատմությանը, ոչ թե միայն տեքստը։ Իրական նախագծերում կարող եք օգտագործել SDK-ի tool runner helper-ը (որը ձեր փոխարեն վարում է այս ցիկլը), Claude Agent SDK-ն (Claude Code harness-ը որպես գրադարան՝ ներկառուցված ֆայլային, shell և վեբ tools-ով) կամ hosted տարբերակներ, ինչպիսին է Claude Managed Agents-ը։ Մյուս էկոհամակարգերն առաջարկում են նման SDK-ներ, բայց դրանց տակ ցիկլը նույնն է։

1const messages: Anthropic.MessageParam[] = [{ role: "user", content: goal }];
2for (let step = 0; step < 20; step++) {
3  const res = await client.messages.create({ model: "claude-opus-5-5", max_tokens: 8000, tools, messages });
4  messages.push({ role: "assistant", content: res.content });
5  if (res.stop_reason !== "tool_use") return res;
6 
7  const results: Anthropic.ToolResultBlockParam[] = [];
8  for (const block of res.content) {
9    if (block.type !== "tool_use") continue;
10    try {
11      const out = await runTool(block.name, block.input, currentUser); // your code, your auth
12      results.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(out) });
13    } catch (e) {
14      results.push({ type: "tool_result", tool_use_id: block.id, content: String(e), is_error: true });
15    }
16  }
17  messages.push({ role: "user", content: results });
18}
19throw new Error("Agent hit the step limit");

03Tools-ի նախագծում, որոնցից մոդելը կարող է լավ օգտվել

Tools-ը agent-ի ձեռքերն են, և agent-ների ձախողումների մեծ մասը tool-երի նախագծման ձախողումներ են։ Յուրաքանչյուր tool-ի տվեք մեկ հստակ գործառույթ, անուն, որն ասում է, թե ինչ է անում, և նկարագրություն, որը բացատրում է, թե երբ օգտագործել, ինչ է վերադարձնում և որոնք են տարածված թակարդները՝ կարծես նոր թիմակցի համար փաստաթուղթ եք գրում։ Նախընտրեք մի քանի բարձր մակարդակի tools («search_orders»՝ ֆիլտրերով) յուրաքանչյուր endpoint-ի շուրջ տասնյակ բարակ wrapper-ների փոխարեն։ Վերադարձրեք կոմպակտ, համապատասխան արդյունքներ․ 5 MB JSON dump ստացող agent-ը վատնում է կոնտեքստը և շփոթվում, ուստի pagination արեք, ամփոփեք և ներառեք id-ներ հաջորդ կանչերի համար։ Սխալները դարձրեք օգտակար («customer_id-ն չի գտնվել, սկզբում օգտագործիր search_customers»)։ Հնարավորության դեպքում գրող tools-ը դարձրեք idempotent և կարդացող tools-ն առանձնացրեք գրողներից, որպեսզի դրանց տարբեր իրավունքներ տաք։ Tools-ը փորձարկեք՝ դիտելով իրական transcript-ները․ որտեղ մոդելը սխալ է օգտագործում tool-ը, սովորաբար նկարագրությունն է պետք մշակել։

04MCP՝ agent-ներին համակարգերին միացնելը

Model Context Protocol-ը (MCP) բաց ստանդարտ է, որը ներկայացրել է Anthropic-ը և որն այժմ աջակցվում է բազմաթիվ AI գործիքներում և provider-ներում՝ AI հավելվածները tools-ին և տվյալներին միացնելու համար։ MCP server-ը ստանդարտ JSON-RPC պրոտոկոլով տրամադրում է tools (գործողություններ), resources (կարդալու տվյալներ) և prompts (կաղապարներ)՝ կամ լոկալ՝ stdio-ով, կամ հեռակա՝ HTTP-ով։ Ցանկացած MCP client՝ Claude Code, Claude հավելվածներ, IDE-ներ և այլ agent host-եր, կարող է այն օգտագործել առանց հատուկ «սոսնձող» կոդի։ Դա նշանակում է, որ «tickets» կամ «database» ինտեգրացիան գրում եք մեկ անգամ և վերաօգտագործում տարբեր agent-ներում։ Հեռակա MCP server-ները authorization-ի համար օգտագործում են OAuth, ուստի agent-ը գործում է օգտատիրոջ պատվիրակած, սահմանափակ իրավունքով։ Երրորդ կողմի MCP server-ներին վերաբերվեք որպես ցանկացած տեղադրվող dependency-ի՝ ստուգեք, թե ինչի հասանելիություն ունեն, pin արեք տարբերակները և նախընտրեք վստահելի հրատարակիչների server-ները։

1{
2  "mcpServers": {
3    "tickets": {
4      "command": "node",
5      "args": ["./mcp/tickets-server.js"],
6      "env": { "TICKETS_API_URL": "https://api.example.com" }
7    }
8  }
9}

05Կոնտեքստ՝ agent-ի աշխատանքային հիշողությունը

Այն ամենը, ինչ agent-ը գիտի առաջադրանքի ընթացքում, ապրում է նրա context window-ում՝ հրահանգներ, tool-երի սահմանումներ, կանչերի և արդյունքների պատմություն։ Երկար առաջադրանքները լցնում են այն, և որակը նվազում է, երբ կոնտեքստը դառնում է «աղմկոտ»։ Լավ harness-ները ակտիվորեն կառավարում են կոնտեքստը։ System prompt-ը պահեք կենտրոնացված նպատակների, սահմանափակումների և աշխատանքի ստուգման եղանակի վրա։ Երբ tools-ը շատ են, բեռնեք դրանք ըստ պահանջի (tool search)։ Մաքրեք հին, ծավալուն tool result-ները, երբ դրանք այլևս պետք չեն (context editing), կամ ամփոփեք ավելի վաղ պատմությունը (compaction)։ Agent-ին տվեք scratchpad կամ memory ֆայլ նշումների համար, որոնք պետք է պահպանվեն՝ պլան, որոշումներ, առաջընթաց։ Մեծ առաջադրանքների համար աշխատանքը բաժանեք subagent-ների միջև․ յուրաքանչյուրը ուսումնասիրում է իր սեփական թարմ կոնտեքստում և հիմնական agent-ին վերադարձնում միայն կարճ արդյունք։ Այսպես են կոդավորող agent-ները շարունակում աշխատել մեծ repository-ների վրա՝ առանց ֆայլերի բովանդակության մեջ խեղդվելու։

06Guardrail-ներ և human-in-the-loop

Agent-ը կարող է իրական գործողություններ կատարել, ուստի սահմանափակումները նախագծում եք այնպես, ինչպես production հասանելիություն ունեցող նոր աշխատակցի համար։ Least privilege՝ տվեք միայն առաջադրանքին անհրաժեշտ tools-ը՝ օգտատիրոջ կամ նեղ service account-ի սահմաններով credentials-ով։ Իրավունքների մակարդակներ՝ միայն կարդացող tools-ն աշխատում են ազատ, գրելը պահանջում է հաստատում կամ աշխատում է sandbox-ում, ավերիչ գործողությունները (վճարումներ, ջնջումներ, email-ներ հաճախորդներին) միշտ պահանջում են մարդ։ Բյուջեներ՝ քայլերի սահմանափակում, token-ի կամ արժեքի բյուջե և wall-clock timeout-ներ։ Sandboxing՝ կոդը և shell հրամանները աշխատեցրեք մեկուսացված կոնտեյներներում՝ առանց գաղտնիքների և սահմանափակ ցանցով։ Ստուգում՝ ասեք agent-ին, թե ինչպես ստուգել իր աշխատանքը՝ աշխատեցնել թեստերը, նորից կարդալ արդյունքը, և հնարավորության դեպքում ինքներդ ստուգեք կոդում։ Աուդիտ՝ log արեք յուրաքանչյուր tool call՝ մուտքերով, ելքերով և այն ինքնությամբ, որի անունից գործել է։

• Կարդալ՝ թույլատրել · Գրել՝ հաստատում կամ sandbox · Անդառնալի՝ մարդու հաստատում
• Քայլերի, token-ի և ժամանակի բյուջեներ յուրաքանչյուր գործարկման համար
• Գաղտնիքները մնում են tool-ի շերտում, երբեք prompt-ում

07Context engineering երկարատև agent-ների համար

Երկար agent գործարկումը կոնտեքստի բյուջեի խնդիր է։ Յուրաքանչյուր քայլ ավելացնում է մոդելի մտածողությունը, tool call-ը և դրա արդյունքը․ մի քանի տասնյակ քայլից հետո window-ի մեծ մասը հնացած log-եր են։ Տեխնիկաները՝ մոտավորապես օգտագործման հերթականությամբ՝ tool-երի ելքերը դիզայնով պահեք փոքր (ամփոփումներ, pagination, id-ներ ամբողջական օբյեկտների փոխարեն), մաքրեք հին tool result-ները, որոնք մոդելին այլևս պետք չեն՝ պահելով այն փաստը, որ կանչը տեղի է ունեցել (context editing), պարբերաբար պատմությունը compact արեք ամփոփման մեջ, որից agent-ը շարունակում է, մնայուն վիճակը պահեք window-ից դուրս՝ առաջընթացի ֆայլ, առաջադրանքների ցուցակ, memory store, որպեսզի թարմ կոնտեքստը կարողանա վերսկսել, և ուսումնասիրությունը պատվիրակեք subagent-ներին, որոնք վերադարձնում են խտացված արդյունքներ։ Prompt caching-ը փոխազդում է այս ամենի հետ․ cache hit-երին պետք է կայուն prefix, ուստի պատմությանն ավելացրեք՝ այն վերագրելու փոխարեն, և կոնտեքստը խմբագրեք API-ի աջակցած մեխանիզմներով, ոչ թե ավելի վաղ հաղորդագրությունները փոփոխելով, ինչը ներկայիս մոդելներում կարող է նաև անվավեր դարձնել մոդելի պահպանված reasoning-ը։

08Prompt injection և «մահացու եռյակը»

Անվտանգության հետազոտողները նկարագրում են agent-ների համար վտանգավոր համակցություն՝ գաղտնի տվյալների հասանելիություն, անվստահելի բովանդակության ազդեցություն և տվյալներ դուրս ուղարկելու հնարավորություն (email tool, HTTP հարցում, նույնիսկ նկարի URL render անելը)։ Երեքի առկայության դեպքում չարամիտ վեբ էջը կամ փաստաթուղթը կարող է հրահանգել agent-ին կարդալ գաղտնիքները և արտահանել դրանք։ Քանի որ ոչ մի մոդել լիովին անխոցելի չէ injection-ի նկատմամբ, կոտրեք համակցությունը կառուցվածքային մակարդակում։ Հնարավորության դեպքում հեռացրեք մեկ «ոտքը»՝ sandbox-ում outbound ցանց չկա, կամ browsing-ի ժամանակ գաղտնի տվյալների հասանելիություն չկա։ Կիրառեք allow-list-եր դոմենների և ստացողների համար։ Պահանջեք հաստատում ցանկացած գործողության համար, որը տվյալներ է ուղարկում դուրս։ Credentials-ը պահեք tool-ի շերտում, որպեսզի մոդելը երբեք չտեսնի դրանք, և օգտագործեք յուրաքանչյուր օգտատիրոջ սահմանափակ token-ներ, որպեսզի վնասը սահմանափակվի այն բանով, ինչ այդ օգտատերը կարող էր անել։ Log և alert արեք անսովոր tool հաջորդականությունների դեպքում և eval suite-ի մաս կազմող injection-ով փաստաթղթերով red-team արեք ձեր agent-ը։

09MCP server-ի կառուցում

MCP server-ը փոքր ծրագիր է, որը հայտարարում է tools՝ JSON Schema մուտքերով, և մշակում կանչերը։ Պաշտոնական SDK-ներ կան TypeScript-ի, Python-ի և այլ լեզուների համար։ Լոկալ server-ները հաղորդակցվում են stdio-ով և ժառանգում օգտատիրոջ մեքենայի իրավունքները, հեռակա server-ներն օգտագործում են Streamable HTTP և պետք է իրականացնեն OAuth, որպեսզի յուրաքանչյուր օգտատեր տրամադրի սահմանափակ հասանելիություն։ Tools-ը նախագծեք agent-ների համար, ոչ թե API-ի ամբողջականության՝ քիչ tools, հստակ նկարագրություններ, կոմպակտ արդյունքներ։ Վավերացրեք յուրաքանչյուր մուտք և authorization-ը կիրառեք server-ի կողմում։ Տարբերակավորեք ձեր server-ը և փաստագրեք breaking change-երը, որովհետև agent-ները կախված են tool-երի անուններից և ձևերից։ Կառուցելուց առաջ ստուգեք MCP-ի ընթացիկ specification-ը և SDK-ի փաստաթղթերը, քանի որ պրոտոկոլը զարգանում է։

1import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
2import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
3import { z } from "zod";
4 
5const server = new McpServer({ name: "tickets", version: "1.0.0" });
6 
7server.registerTool(
8  "get_ticket",
9  {
10    description: "Fetch one support ticket by id, including status and last 5 messages.",
11    inputSchema: { id: z.string().describe("Ticket id, e.g. T-1042") },
12  },
13  async ({ id }) => {
14    const t = await fetchTicket(id); // your API, your auth
15    return { content: [{ type: "text", text: JSON.stringify(t) }] };
16  },
17);
18 
19await server.connect(new StdioServerTransport());

10Արժեքի և հուսալիության ինժեներիա

Agent-ի արժեքը մեկ քայլի token-ներն են բազմապատկած մեկ առաջադրանքի քայլերով, և երկուսն էլ աճում են աննկատ։ Չափեք արժեքը և հաջողությունը ըստ ավարտված առաջադրանքի, ոչ թե ըստ հարցման։ Լծակներ՝ prompt caching կայուն prefix-ի վրա (system prompt և tools), ինչը շատ կարևոր է, որովհետև յուրաքանչյուր քայլ նորից ուղարկում է պատմությունը, ավելի ցածր effort կամ ավելի փոքր մոդել subagent-ների և պարզ քայլերի համար, ավելի քիչ, բայց ավելի լավ tools, որպեսզի agent-ին ավելի քիչ կանչ պետք լինի, և task budget-ներ, որոնք թույլ են տալիս մոդելին ինքը կարգավորել տեմպը՝ քայլի կեսին կտրվելու փոխարեն։ Հուսալիության համար tools-ը դարձրեք idempotent և retry-ները անվտանգ, checkpoint արեք առաջընթացը, որպեսզի crash եղած գործարկումը կարողանա վերսկսել, դրեք wall-clock սահմանափակումներ և ոչ-«happy» stop reason-ները (max_tokens, refusal, քայլերի սահմանափակում) մշակեք հստակ արդյունքով՝ լռության փոխարեն։ Երկար առաջադրանքներն աշխատեցրեք որպես ֆոնային job-եր՝ կարգավիճակի թարմացումներով, ոչ թե HTTP հարցման ներսում։