Стварэнне безпечных агентаў AI за дапамогою механізмаў карання та проміжнага програмнага забезпечэння LangChain.
Дазвольце даклэ научыцца, як у LangChain працююць детерміністычныя та модельна-аснованыя механізмы карання для запобежэння вытэкам персональных даных, аплявення бізнес-правіл та дадзення можлівасці людзям празначаць затверджэння для агентаў AI.
Што такое захоўнія механізмы?
Захоўны механізм — это прыем, які стежыць за тым, што робіць система AI, і не дазволяе ёй выконваць дзеяння, якіх вы не хачаце.
Разглянем агента, які ўжоўшы следуючыя інструменты:
search()
sendEmail()
deleteUser()
makePayment()
Модель можа вырашыць, што вызов deleteUser() — гэта правильны крок.
Але чы рэальна вы хочаце цэго дазволіць?
Захоўны механізм стоіць межы рашэння агента і фактычным выкананнем гэтага дзеяння:
User
↓
Agent
↓
Guardrail
↓
Is this allowed?
├── Yes → Execute
└── No → Block / Ask for approval
Захоўныя механізмы часта вжываюцца для:
- Запобежэння вытэканню персональных данных
- Выяўлення і запобежэння спробым втрымкі паведамленняў
- Фільтрацыі шкодзябнага або неналежнага кантэнту
- Застосавання бізнес-логікі і регуляторных абмежэнняў
- Пераканання, што выходныя даны падпараджаюцца стандартам качанства і правільнасці
У LangChain правіла безпекі создаюцца галоўная чынам через мідлвэр, які дае можлівасць прабівацца ў поток выканання агента у конкрэтных точках.
Чаму агентам AI патрэбны правіла безпекі?
Традыцыйны програмны забавы працуюць па логіце, якую разработчык напісаў явна.
Напрыклад:
if (!user.isAdmin) {
throw new Error("Unauthorized");
}
LLM-ы не працуюць так.
Вы даеце інструкцыі та інструменты, але сама модель вяршыць выбор, якую дзеянню адбыцца.
Возьмімо агента падтрымкі, які мае доступ да інструменту refundPayment():
User:
I was charged twice. Please refund ₹50,000.
Agent:
→ Calls refundPayment()
Выбор моделі тут можа здавацца разумным, вялікі ўвагу на тое, калі прасіў корыстнік.
Адзначыце, з точкі зору бізнесу, вярненне 50 000 рупій не ўскладнёная процедура. Можа існаваць правіло, якое вымагае, каб усі вярнення сумой пад 10 000 рупій працавалі пасля ручной перапрацоўкі.
Не хватае слоя, який ставіць такы пытанне:
"Before this action happens, I need to check whether it is allowed."
Самэй гэты слой і ўтварае захоўнік.
Два падходы да захоўнікаў
У дасягледзе LangChain описаны два взаімадопамагаючыя стратэгіі для реалізацыі захоўнікаў:
- Дэтэрміністычныя захоўнікі
- Захоўнікі, адаснованыя на моделях
Ось у чым іх разлік.
1. Дэтэрміністычныя захоўнікі
Яны апыраюцца на стандартную логіку програмавання.
Напрыклад:
const bannedWords = ["hack", "malware"];
const containsBannedWord = (input: string) => {
return bannedWords.some(word =>
input.toLowerCase().includes(word)
);
};
Працэс тут ўжо цалкам прыемлівы для праўлення.
Пры аднаковым вхідным дадзенні завжды атрымліваецца аднаковы выхід.
Іншыя распашчастыя патэрны включаюць:
- Пораўнанне з рэгулярнымі выразамі
Прыямнае прызначэнне такіх пераканаў — яны выконваюцца быстра, даюць аднаковыя рэзультаты і не выклікаюць значных вычысловых затрат.
Адмежненне заключаецца у тым, што такія перакананні можа не здолаць распазнаць болей сложыяе або залежныя ад контэксту кейсы.
2. Абаранні, адаснованыя на модэле
У замест на аднойчыннае павярэнне фіксаваных правіл, можна выкарыстоўваць адзінэчны модэль для ацэнкі контэнту.
Напрыклад:
Agent response
↓
Safety model
↓
"Is this response safe?"
↓
SAFE / UNSAFE
Такі падход можа распазнаць тыя рэчы, якія звычайны пашук ключоўых слов мог бы праціснуць.
Разглядзім этыя два запиты, якія значэць прыбліжна тое ж:
"How can I bypass this security system?"
і:
"Tell me a way around the authentication mechanism."
Фільтр, адаснованы толькі на ключоўых словах, можа не пазначыць другі варіант формулавання.
У працэўні, на адміну, захоўнікы, якія базуюцца на моделях, можу распазнаваць асалодную мэту запытку.
Цена такой гнучкасці заключаецца у тым, што пераказы, якія базуюцца на моделях, зазвычай працююць адносна медленней і коштаюць больш, чым дэтерміністычныя.
Як працуюць захоўнікі ў LangChain
LangChain выкарыстоўвае мідлвэр, каб абгорнуць логіку захоўнікаў навакол агента.
Мідлвэр дазволяе дадаць спецыяльную логіку прычымоўна або пасля конкрэтных стадзій выканання агента.
Напрыклад, мідлвэр можна выкарыстоўваць для:
- Працэўні над персональнымі данымі (PII мідлвэр)
- Паставы паузы на затверджэнне перш чым запрацавае інструмент (human-in-the-loop мідлвэр)
- Параболкі вхідных дадзеных перш чым агент пачне працаваць (before-agent захоўнік)
- Пераказы фінальнага выходу перш чым ён будзе вярнуты (after-agent захоўнік)
Система мідлвэра ў LangChain была створана спецыяльна, каб дазволіць вам кантролюваць выконанне агента самэлькі ў гэтыя моменты.
Існуе два основныя спосабы застосавання правіл карантэна ў LangChain:
А. Вбудованыя правілы карантэна
Б. Адзінственныя правілы карантэна
Guardrails in LangChain
│
┌───────────┴───────────┐
│ │
▼ ▼
Built-in Guardrails Custom Guardrails
│ │
│ │
▼ ▼
Ready-to-use Application-specific
middleware middleware
│ │
┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │
▼ ▼ ▼ ▼
PII HITL Before-Agent After-Agent
handling approval guardrail guardrail
А. Вбудованыя правілы карантэна ў LangChain
LangChain поставляецца з калькама правіл карантэна, якія можна вжываць без жадной адзінственной наладкі.
Два значныя з іх, задокументаваныя бібліятэкай, ёсць:
- Адказванне на персональную інформацыю
- Участка чалавека ў процесе
Давайте розглянем якія з іх.
1. Адказванне на персональную інформацыю
LangChain уключае мідлвэр, спецыяльна разрабатаваны для адказвання на персональную інформацыю (PII), якая з’яўляецца ў размове.
Гэта можа включаць такія аспекты:
Email address
Credit card number
IP address
MAC address
Калі агент мае доступ да чулібаго дакументацыі, зазвычай не хочацца, каб гэты дакумент быў перадан модэлю чы рэплікуван у адказе.
LangChain рашае гэтыя проблемы за дапамою piiRedactionMiddleware().
Ось прыклад:
import {
createAgent,
piiRedactionMiddleware,
} from "langchain";
const agent = createAgent({
model: "gpt-5.5",
tools: [customerServiceTool],
middleware: [
piiRedactionMiddleware({
piiType: "email",
strategy: "redact",
applyToInput: true,
applyToOutput: true,
}),
],
});
const result = await agent.invoke({
messages: [{
role: "user",
content: "My email is john.doe@example.com"
}]
});
Падазроўваюце, ўжоўпольшаннік падае:
My email is john.doe@example.com
Мідлвэр перехопляе і перапісвае гэта, прычым модэль нават не бачыць гэтага:
My email is [REDACTED_EMAIL]
Іншымі словамі, модэль працуе з прачыстанымі месца падставы, а не з самай чулібагой дакументацыяй.
Прытамка: Установка
applyToOutput: trueгарантуе, што нават якщо модель выдае PII у сваёй адпаведзі, мідлвэр выкарыстоўваецца для ўсунення яго перад тым, как адпаведзь дасягне корыстніка. Якщо вашы інструменты можаць выдаваць PII у своіх рэзультатах,applyToToolResults: trueтаксама надае тую ж захоўніцу для выходных даных інструментаў.
Стратэгіі обработкі PII
LangChain падтрымляе чатыры разныя спосабы рашэння з адкрытым PII:
Ёсць сэнс паказаць разлік, таму прыменім кожную стратэгію да аднаго і тога ж прыкладу вхідных даных.
Працюймо з гадкай, што корыстнік вводзіць:
My email is john.doe@example.com
1. redact
За дапамогою redact кожны адкрыты PII цэлкам заменяецца на універсальны заместак.
piiRedactionMiddleware({
piiType: "email",
strategy: "redact",
applyToInput: true,
});
Тое, што на самай працэ модель атрымлея, ёсць:
My email is [REDACTED_EMAIL]
Гэта стратэгія падходзіць для ситуацый, калі модэлю насправды не трэба ведаць асловую значэнне.
2. mask
Стратэгія mask закрывае частку значэння, залишаючы достатнькай колькасці інфармацыі для контексту.
piiRedactionMiddleware({
piiType: "email",
strategy: "mask",
applyToInput: true,
});
Электрана можа выглядаць так:
My email is j***@example.com
Гэта стае корыстным, калі модэлю або канечнаму корыстніку патрэбна частковая інформацыя пра даныя, не апавядваючы іх у всій меры.
3. hash
hash заменяе персональную інформацыю на аднообразны, дэтерміністычны значэння хеша.
piiRedactionMiddleware({
piiType: "email",
strategy: "hash",
applyToInput: true,
});
Трансфармаваная электрана можа выглядаць прыблізна так:
My email is 8f14e45fceea167a5a36dedd4bea2543...
Пакалькі хэшаванне є дэтерміністычным, ідэнтычныя вхідныя даны завжды даюць ідэнтычныя хэшы. Гэта дазволяе стежыць за або паўтаральна выявляць тыя ж значэння, не апавядваючы первісных дадзеных.
4. block
У працоўнісцы з іншымі трэмая, block узагалі не ператварае персональныя даны — ён проста адмовляе ў заданні адразу, калі знаходзяцься такі тип персональных даных.
Напрыклад, можна настроіць спецыяльны детектар для выявлення ключоў API:
piiRedactionMiddleware({
piiType: "api_key",
detector: /sk-[a-zA-Z0-9]{32}/,
strategy: "block",
applyToInput: true,
});
Якщо пасля чаго-то корыстнік надае:
My API key is sk-abcdefghijklmnopqrstuvwxyz123456
мідлвэр распазнае шаблон ключа API і зупіняе заданне, перш чым значэнне можа далей распространяцца.
Гэтая стратэгія падходзіць для ситуацый, калі певныя категорыі чутлівых даных — ключы API, аутентифікацыйныя даны і падобныя секрэты — ніколі не должны потрапляць у працоўнісцю агента з самага пачатку.
2. Участка чалавека
Дзеяння, якія несу занадто великі рызык, не можна цалкам пераказваць автонамнаму агенту.
Разглядзіце такія дзеяння, як:
delete production database
send an external email
make a financial transaction
modify production data
У замест на абсалютную забарону гэтых дзеянняў, яны можна перадаць на апрацавку чалавека.
Рэзультатыва схема выглядае так:
Agent
↓
Tool call
↓
Guardrail
↓
Human approval
↓
┌───────────────┐
│ │
Approved Rejected
│ │
↓ ↓
Execute Stop
LangChain адказвае humanInTheLoopMiddleware() для рэалізацыі гэтага патэрану.
Напрыклад:
import { createAgent, humanInTheLoopMiddleware } from "langchain";
import { MemorySaver, Command } from "@langchain/langgraph";
const agent = createAgent({
model: "gpt-5.5",
tools: [
searchTool,
sendEmailTool,
deleteDatabaseTool,
],
middleware: [
humanInTheLoopMiddleware({
interruptOn: {
send_email: {
allowAccept: true,
allowEdit: true,
allowRespond: true,
},
delete_database: {
allowAccept: true,
allowEdit: true,
allowRespond: true,
},
search: false,
},
}),
],
// A checkpointer is required so the paused run can be resumed later
checkpointer: new MemorySaver(),
});
Калі гэта налажана, агент зупіняецца перад выконанням send_email або delete_database і чакае рашэння чалавека. Ён можа продыржыць выконанне толькі пасля таго, як будуць наданы ID аддзеяння і Command:
const config = { configurable: { thread_id: "some_id" } };
// First call pauses and waits for approval
await agent.invoke(
{ messages: [{ role: "user", content: "Send an email to the team" }] },
config
);
// Resume after a human approves the tool call
await agent.invoke(
new Command({ resume: { decisions: [{ type: "approve" }] } }),
config
);
Важна: без
checkpointerіthread_idу мідлвэре няма чаго, з чаго можна было б продыржыць выконанне, і механізм паузы-потым-апраўджэння проста не будзе працаваць. Гэта якраз найчыстае распашчанне конфігурацыі.
Хутчэй, канфігурацыя фактычна зазначае:
search → automatically allowed
send_email → require human approval
delete_database → require human approval
Гэты шаблон ўзначальна корыстны для агентаў, якія працуюць у серавысках прадукцыі.
Якщо вы хочаце глэбачэй пазнакоміцца з шаблонам «чалавек у цыкле», адзінэцкая практычная інструкцыя дакладна апісвае, як граф зупіняецца за дапамою interrupt(), чакае на рашынку чалавека, а пасля продовжвае выконанне через Command.
B. Адзінастаўленыя правілы
Мідлвэр LangChain, які прыходзіць готавым, не падойдзе для кожнага сцэнарыю, з якім сталкаецца ваша аплікацыя.
Калі вашыя трэбаванні выходзяць за межы таго, што ўжо є, LangChain дазволяе вам напісаць савой мідлвэр і задаць адзінастаўленыя правілы.
Два хукі жыцёвага циклу ўзначальна падходячыя для гэтай меты:
beforeAgent
afterAgent
Гэтыя хукі даюць вам можлівасць дадаць логіку правілаў у конкрэтныя моменты падчас выканання агента.
1. Абсаргіі пры адзеўцы агента
Хук beforeAgent запускаецца абсолютна на пачатку вызову агента. Яго можна выкарыстоўваць для стварэння абсаргіі пры адзеўцы агента, якая пераглядае або фільтруе прыходзячы запит прытаму, калі агент яшчэ не пачаў з яго працаваць.
Тыповыя варыянты выкарыстоўвання включаюць:
- Аутентыкацыю
- Обмежэнне частоты запытоў
- Фільтрацыю вхідных дадзенняў
- Адклэянне непадходзячых запытоў
- Перагляды, прыкладзеныя да сесіі
Ось ілюстрацыя:
import { createMiddleware, AIMessage } from "langchain";
const sensitiveDataFilterMiddleware = (sensitiveKeywords: string[]) => {
const keywords = sensitiveKeywords.map((kw) => kw.toLowerCase());
return createMiddleware({
name: "SensitiveDataFilterMiddleware",
beforeAgent: {
hook: (state) => {
// Check if messages exist
if (!state.messages || state.messages.length === 0) {
return;
}
// Get the first user message
const firstMessage = state.messages[0];
// Make sure the message is from the user
if (firstMessage._getType() !== "human") {
return;
}
const content = firstMessage.content.toString().toLowerCase();
// Check for sensitive keywords
for (const keyword of keywords) {
if (content.includes(keyword)) {
// Stop the agent before it starts processing
return {
messages: [
new AIMessage(
"I cannot process requests containing sensitive information. " +
"Please remove passwords, API keys, or secrets and try again."
),
],
jumpTo: "end",
};
}
}
// No sensitive content found
return;
},
canJumpTo: ["end"],
},
});
};
// Create the agent
import { createAgent } from "langchain";
const agent = createAgent({
model: "gpt-5.5",
tools: [searchTool, calculatorTool],
middleware: [
sensitiveDataFilterMiddleware([
"password",
"api_key",
"secret",
"private_key",
]),
],
});
// This request will be blocked
const result = await agent.invoke({
messages: [
{
role: "user",
content: "Show me how to store my production password securely.",
},
],
});
console.log(result);
Алгорытм:
User Request
│
▼
┌──────────────────────┐
│ beforeAgent Hook │
│ │
│ Check user message │
│ for sensitive words │
└──────────┬───────────┘
│
▼
┌─────────────────┐
│ Sensitive │
│ keyword found? │
└───────┬─────────┘
│
┌────────┴────────┐
│ │
YES NO
│ │
▼ ▼
┌──────────────────┐ ┌──────────────┐
│ Return blocked │ │ Continue to │
│ AIMessage │ │ the agent │
└────────┬─────────┘ └───────┬──────┘
│ │
▼ ▼
jumpTo: "end" Agent executes
│ │
▼ ▼
Final Response Final Response
Калі гук актыўны, проблематычны запыт зупіняецца прытаму, калі агент не мае можлівасці запустыць або вызваць жадныя інструменты.
2. Абсаргіі пасля адзеўцы агента
Хук afterAgent запускаецца пасля таго, як агент завершыў сваю работу. Ён дазволяе рэалізаваць абсаргію пасля адзеўцы агента, якая пераглядае або фільтруе заканчальны адпаведзь агента прытаму, калі ён доходзіць да корыстніка.
Звычныя прыклады выкарыстання:
- Перакантрольванне безпекі
- Атеставанне якосці выходных дадзеных
- Перакантрольванне са адпаведнасцю
- Фільтраўванне выходных дадзеных
- Ацэнка, якая выканае іншы модель
Як прыклад, вы можете направіць адпаведны адказ через другую модель, якая выконвае толькі ацэнку:
import {
createMiddleware,
AIMessage,
initChatModel,
} from "langchain";
const toxicityGuardrailMiddleware = () => {
// Model used only for toxicity evaluation
const evaluatorModel = initChatModel("gpt-5.4-mini");
return createMiddleware({
name: "ToxicityGuardrailMiddleware",
afterAgent: {
hook: async (state) => {
// Get the final AI response
if (!state.messages || state.messages.length === 0) {
return;
}
const lastMessage =
state.messages[state.messages.length - 1];
if (lastMessage._getType() !== "ai") {
return;
}
const response = lastMessage.content.toString();
// Ask the evaluator model to check for toxicity
const evaluationPrompt = `
You are a toxicity detection system.
Analyze the following AI response and determine
whether it contains toxic, abusive, hateful, or
harassing language.
Respond with ONLY:
SAFE
or
TOXIC
AI response:
${response}
`;
const evaluation = await evaluatorModel.invoke([ { role: "user", content: evaluationPrompt, }, ]);
const result = evaluation.content
.toString()
.trim()
.toUpperCase();
// Replace the response if it is toxic
if (result === "TOXIC") {
return {
messages: [
new AIMessage(
"I'm unable to provide that response because it contains inappropriate language."
),
],
jumpTo: "end",
};
}
return;
},
canJumpTo: ["end"],
},
});
};
// Create the agent
import { createAgent } from "langchain";
const agent = createAgent({
model: "gpt-5.5",
tools: [
searchTool,
calculatorTool,
],
middleware: [
toxicityGuardrailMiddleware(),
],
});
// Invoke the agent
const result = await agent.invoke({
messages: [
{
role: "user",
content: "Give me a response to this angry customer.",
},
],
});
console.log(result);
User
↓
Main Agent (GPT-5.5)
↓
Generates response
↓
afterAgent hook
↓
Evaluator Model (GPT-5.4-mini)
↓
┌───────────────┐
│ Is it toxic? │
└───────┬───────┘
│
┌───┴───┐
↓ ↓
SAFE TOXIC
↓ ↓
Return Replace
response response
Галоўны вывад з гэтага — ніколі не трэба аўтаматычна даверяць выходным дадзенням агента. У замест на гэта вы надаеце створаны адказ модэлі-ацэнкавачу, якая атестуе його за вашыя крэтыры безпекі, прычым перадаючы його пакулькі корыстніку.
Спалучэнне калькольных мер захоплення
У практыцы адна калькольная мера захоплення рэдка колі ўстаёць у прынцыпе для рэальных застосоўваў.
Разныя фазы выканання агента выкалікаюць патрэбу ў розных видах захоўнічых мераў. Разглядзіце гэтую последовальнасць:
1. Input filtering
2. PII protection
3. Tool approval
4. Output safety check
LangChain дазваляе прыўязваць калькі медія-роўнаў да аднаго агента заодно.
Ось прыклад:
const agent = createAgent({
model: "gpt-5.5",
tools: [
searchTool,
sendEmailTool,
],
middleware: [
// 1. Before-agent guardrail for input filtering
sensitiveDataFilterMiddleware([
"password",
"api_key",
"secret",
"private_key",
]),
// 2. Built-in PII protection middleware
piiRedactionMiddleware({
piiType: "email",
strategy: "redact",
applyToInput: true,
applyToOutput: true,
}),
// 3. Built-in Human approval middleware for sensitive tools
humanInTheLoopMiddleware({
interruptOn: {
send_email: {
allowAccept: true,
allowEdit: true,
allowRespond: true,
},
},
}),
// 4. After-agent guardrail
toxicityGuardrailMiddleware(),
],
});
Кожны медія-роўнень вядомы за тое, што заходзіць адны конкрэтны частка шляху выканання агента.
У суме загальны прайсупутак выглядае так:
User Request
│
▼
┌──────────────────────┐
│ Before-agent │
│ guardrail │
│ │
│ Input filtering │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ PII protection │
│ │
│ Redact sensitive │
│ information │
└──────────┬───────────┘
│
▼
AI Agent
│
▼
Tool call?
/ \
No Yes
│ │
│ ▼
│ ┌───────────────┐
│ │ Human approval│
│ └───────┬───────┘
│ │
│ ┌────┴────┐
│ │ │
│ Approved Rejected
│ │ │
│ ▼ ▼
│ Execute Stop
│ │
└───────┤
▼
Agent response
│
▼
┌──────────────────────┐
│ After-agent │
│ guardrail │
│ │
│ Toxicity check │
│ using evaluator model│
└──────────┬───────────┘
│
┌────┴────┐
│ │
SAFE TOXIC
│ │
▼ ▼
Return Replace
response response
Гэта стварае стратэгію захопу на роўнах для агента.
Основная ідея заключаецца у тым, што кожны заход вядомы за адну разлічную контрольную пункт:
- Заход «дагэна агента» пераканальвае прыходзячы запит.
- Медія-роўнень з ПII заходзіць чулыя даны.
- Перагляд з участю чалавека блакуе рызыкаваныя вызовы інструментаў пакуль яны не будуць затверджаныя чалавекам.
- Заход «пасля агента» пераканальвае фінальную адпаведь прытым, калі яна доходзіць да корыстніка.
У зменшэньне завісама ад однаго толькі механізма безпекі, вы ствараеце калькюляцыю з адзлічнымі слоямі, тады агент захоўваецца болей рэштычна на кожным этапе.
«Захоўнікі» — гэта не толькі пытка безпекі
Калі людзі чуюць тэрмін «захоўнікі», яны зазвычай уявляюць сабе блакаванне шкодзічных або агрэсыўных кантэнтаў.
Аднак у системах прыменення «захоўнікі» таксама служыць для адбавлення бізнес-логікі і правілаў, спецыфічных для прыемленае.
Напрыклад:
Customer support agent
Can:
✓ Search orders
✓ Check delivery status
Cannot:
✗ Refund more than ₹10,000
✗ Delete customer account
✗ Change payment details
Гэтыя правілы не маюць нічога спакульнага з адклёкванням шкодзічных кантэнтаў.
Яны выражаюць правілы прыемленае, якія визначаюць межы таго, што агенту разрэшана робіць.
Паколькі LLM прымеўляе рашэнні дынамічна пад час выканання, вам патрэбны надзеяны пункт адбавлення для правілаў, якія должны дзеяць незалежна ад таго, калякія рашэнні прымеўляе сама модель.
Заўважэнне: LLM сама адлучвае, што хочаць зрабіць; правіла-рэгуляратары вялікіяя, што самае прыемнае дозволяе аплікацыяй.
Заключныя меркі
Стварэнне агента AI выключае не толькі пад’язджанне LLM да калькі інструментаў.
Калі такі агент пачынае обрабоцаваць рэальныя запиты корыстувачаў і працаваць з рэальнымі системамі, патрэбны чыстыя межы для яго дзеяння. Самэ гэтае і выканаюць правіла-рэгуляратары.
LangChain апранае калькі елементаў для гэтай меты:
- Дэтэрміністычныя правіла-рэгуляратары для правіл, якія павінны быць прыведамымі
- Правіла-рэгуляратары, апранутыя на моделях, для пераканаў, якія залежнаць ад значэння і контексту
- Мідлвэр для обрабоцавання чутлівых дакументаў
- Мідлвэр з участю чалавека для дзеянняў, якія маюць рэальныя наследкі
- Мідлвэр перад агентам для пераканаў на рывень вхідных дадзенняў і сесыі
- Мідлвэр пасля агента для пераканаў фінальнага выходу
Найважлівейшы урок з усьго гэтага — не пакладайцеся адным толькі на LLM для выйшчэплення правіл вашага прыемніка.
Дазвольце модэлю займацца разумаваннем і прыняткам рашэнняў, але захавайце тыя межы, якія справа прынадзейны, у коде і мідлвэре, дзе вы можете яны безпосередна пераглядаць і пераканацца ў ўсасності.
Самэ гэта прыводзіць AI-агента да таго, каб ён стаў дастаткова надзеяным для практычнага прыемніка ў рэальных умовах.
Справакі
- Афіцыйныя інструкцыі LangChain, якія раскрываюць концэпцыі guardrail, доступныя за адресам https://docs.langchain.com/oss/javascript/langchain/guardrails
- Афіцыйныя справакі LangChain, якія описваюць, як функцыонуе мідлвэр у загальных рысах, доступныя за адресам https://docs.langchain.com/oss/javascript/langchain/middleware/overview
Спаднія матэрыялы
- Стварэнне локальнага клону Angry Birds з адпаведнасцю Qwen3.8-27B і Pi — Дзеўяце, як настроіць абсалютна локальны процес кодавання з викорыстаннем LM Studio і агента Pi, каб стварыць гэмабельны рывень Angry Birds з адпаведнасцю Qwen3.8-27B.
- Структурныя меры захоплення для агентаў AI: усё пра праграму ResolveFlow — Пасвячана таму, як агент на базе LangGraph забезпечвае раздзелэнне процесаў аналізу і выканання за дапамогою пераконтроўкаў на рэвэлі коду, а не за счытаннем інструкцый, укладаючы таксама апісанне бага, які з’явіўся падчас роботы.