Практичні нотатки: Від шаблону до конвеєра: реалізація Агентного кортексу з
Покрокове керівництво з практичних нотаток: від шаблону до пайплайну: реалізація Agentic Cortex із використанням контрактів, перевірок та готових блоків коду для команд, які впроваджують цей шаблон.
Джерела: From Pattern to Pipeline: Implementing the Agentic Cortex with LangGraph and OPA
Наведені нижче примітки описують практичний підхід до реалізації проекту «Від шаблону до конвеєра: впровадження Agentic Cortex за допомогою LangGraph та OPA». Основна увага приділяється контрактам, перевіркам та місцям для вставки коду, а не мотиваційним аспектам. Під час роботи на етапі огляду спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допоможе зберегти чесність подальших змін у коді. Документуйте як успішний, так і відновлювальний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Огляд архітектури:
Етап огляду архітектури працює найкраще, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед складними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Зберігайте стан графа у простій та типованій формі. Вкладені структури приховують інформацію про те, який вузол заповнив яке поле, що ускладнює продовження роботи після перерв.
Послідовність дій: шість вузлів, один StateGraph
Етап Six Nodes Pipeline працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Зберігайте стан графа у простому та типованому вигляді. Вкладені структури приховують інформацію про те, який вузол заповнив яке поле, що ускладнює продовження роботи після перерв.
class CortexState(TypedDict, total=False):
domain_outputs: Dict[str, DomainOutput]
normalized_recommendations: List[NormalizedRecommendation]
cross_domain_conflicts: List[CrossDomainConflict]
policy_decisions: List[PolicyDecision]
resolved_conflicts: List[CrossDomainConflict]
sentinel_check: Optional[SentinelCheckResult]
final_recommendations: List[NormalizedRecommendation]
workflow = SateGraph(CortexState)
workflow.add_node("collect_domains", domain_collector_agent)
workflow.add_node("evaluate_mesh", mesh_evaluator_agent)
workflow.add_node("apply_policies", policy_engine_agent)
workflow.add_node("resolve_conflicts", conflict_resolver_agent)
workflow.add_node("sentinel_check", sentinel_loop_agent)
workflow.add_node("generate_report", report_generator_agent)workflow.set_entry_point("collect_domains")
workflow.add_conditional_edges("collect_domains",
should_continue_after_collection,
{"evaluate_mesh": "evaluate_mesh", "end": END})
Node 1: Збирач доменів
Етап Node 1 The Domain працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовища до спільних середовищ. Зберігайте стан графа у випрямленому та типованому форматі. Вкладені блоки приховують інформацію про те, який вузол записав яке поле, та ускладнюють продовження роботи після перерв. Етап Node 1 The Domain працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Документуйте як успішний, так і відновлювальний шляхи роботи разом. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
AGENT_A_URL = "http://localhost:8001"
AGENT_B_URL = "http://localhost:8002"
Node 2: Оцінювач сітки – місце виникнення конфліктів
На етапі Node 2 The Mesh необхідно визначити вхідні дані, відповідального за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, тестирувані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру обробки даних. Необхідно забезпечити людське схвалення для операцій, які призводять до витрат грошей чи змінюють продуктивні дані. Підключення елементів під час компіляції не є гарантією повноти бізнес-процесу.
{
"conflict_type": "budget_reliability_tradeoff",
"severity": "HIGH",
"resource_id": "resource-x",
"recommendation_a": {"domain": "domain_a",
"title": "Decommission idle resource-x"},
"recommendation_b": {"domain": "domain_b",
"title": "Enable redundancy for resource-x"}
}
Оцінка мережі = (Рівень впевненості × 100) + Бонус за серйозність — Штрафи за конфлікти
На етапі розрахунку оцінки мережі за формулою «Рівень впевненості × 100» необхідно заздалегідь визначити вхідні дані, відповідального за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити цей крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Призначте назви елементам, визначте критерії успіху та не допускайте мовчазного часткового завершення. Необхідно забезпечити людське схвалення для операцій, які призводять до витрат грошей чи змін даних у продакшені. Компіляційна налаштування не є гарантією повноти бізнес-процесу.
Вузол 3: Двигун політик OPA, детерміністичне управління
Для етапу OPA у Node 3 необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Відображення витрат заздалегідь запобігає несподіваним рахункам під час переходу з демо-середовища у спільні. Встановлюйте людське схвалення для кроків, які спричиняють витрати чи змінюють дані у продакшені. Підключення під час компіляції не є гарантією повноти функціоналу продукту. Для етапу OPA у Node 3 необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Документуйте як шлях успішного виконання, так і шлях відновлення одночасно. Повторні спроби, людське схвалення та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Архітектура OPA Sidecar
Під час роботи над етапом архітектури OPA Sidecar спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед складними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Робіть перевірки після дорогих кроків. Функція відновлення не повинна знову оплачувати один і той самий виклик LLM, коли оператор намагається виконати наступний етап.
package cortex.recommendation
decision := result if {
_is_destructive_action(input.recommendation.title)
_is_critical_resource(input.recommendation.resource_id,
input.context)
result := {
"decision": "deny",
"reason": "Policy prevents decommissioning
of critical resource",
"rule_name": "protect_critical_resources"
}
}
package cortex.conflict
# Budget vs Reliability on critical resources gets policy override
resolution := result if {
input.conflict.conflict_type == "budget_reliability_tradeoff"
_is_critical_resource(input.conflict.resource_id, input.context)
result := {
"strategy": "policy_override",
"winner": _higher_ranked_domain(...),
"rule_name": "budget_reliability_critical_resource"
}
}# Resource Contention resolved by domain priority for unequal ranks
resolution := result if {
input.conflict.conflict_type == "resource_contention"
domain_rank[...] != domain_rank[...]
result := {
"strategy": "domain_priority",
"winner": _higher_ranked_domain(...),
"rule_name": "resource_contention_priority"
}
}# Opposing Recommendations on critical resources are escalated
resolution := result if {
input.conflict.conflict_type == "opposing_recommendations"
_is_critical_resource(...)
result := {
"strategy": "escalate",
"winner": "none",
"rule_name": "opposing_critical_escalate"
}
}
package cortex.priority
domain_rank := {
"domain_a": 1,
"domain_b": 2,
"domain_c": 3,
"domain_d": 4,
"domain_e": 5
}
services:
opa:
image: openpolicyagent/opa:latest
command: run --server --addr=0.0.0.0:8181 /policies
volumes:
- ./src/policies:/policies
Крок 4: Розв’язувач конфліктів, чотири етапи вирішення
Під час роботи над етапом Крок 4 «Розв’язування конфліктів» спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Призначте назви елементам, визначте критерії успіху та не допускайте безповідомного часткового виконання. Робіть контрольні позначки після дорогих кроків. Система відновлення не повинна знову оплачувати один і той самий виклик LLM, коли оператор намагається знову виконати пізніший крок.
Ієрархія чотирьох етапів розв’язування конфліктів
Під час роботи над етапом чотирьох стадій вирішення конфліктів спочатку запишіть умови використання: необхідні дані вхіду, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність подальших змін у коді. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Відображення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-версії до спільних середовищ. Робіть контрольні пункти після дорогих кроків. Функція відновлення не повинна знову стягувати плату за один і той самий виклик ШІ, коли оператор перезапускає пізніший етап. Під час роботи над етапом чотирьох стадій вирішення конфліктів спочатку запишіть умови використання: необхідні дані вхіду, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність подальших змін у коді. Одночасно задокументуйте оптимальний та резервний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
{
"winner": "a" | "b" | "both",
"reasoning": "...",
"confidence": 0.0-1.0
}
Node 5: The Sentinel Loop, виявлення відхилень між циклами
Етап Node 5 The Sentinel працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний зразок даних, один випадок збою та примітку про скасування дій перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед складними скриптами. Коли якась дія зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Зберігайте стан графа у простій та типованій формі. Вкладені структури даних приховують інформацію про те, який вузол записав яке поле, і ускладнюють продовження роботи після перерв.
change_percent = (current - previous) / abs(previous) * 100
if abs(change_percent) > DRIFT_THRESHOLD_PERCENT:
drift_status = "WORSENED" if change_percent < 0
else "DRIFTED"
Node 6: Генератор звітів
Етап Node 6 „Створення звіту“ працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Призначте назви документам, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Зберігайте стан графа у простому та типованому вигляді. Вкладені блоки даних приховують інформацію про те, який вузол заповнив певне поле, що ускладнює продовження роботи після перерв.
Повна сценарій демонстрації
Етап „The Full Demo Scenario“ працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовища до спільних середовищ. Зберігайте стан графа у простому та типованому вигляді. Вкладені блоки приховують інформацію про те, який вузол записав яке поле, і ускладнюють продовження роботи після перерв. Етап „The Full Demo Scenario“ працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу. Документуйте як успішний, так і відновлювальний шляхи роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Запуск
Для етапу «Running It» необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, перевірювані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру процесу. Необхідно встановити людське схвалення для операцій, які призводять до витрат грошей чи змінюють дані у продакшені. Підключення елементів під час компіляції не є гарантією повноти бізнес-функціоналу.
git clone https://github.com/kyndryl-cto/agentic-cortex.git
cp .env.example .env
# Fill in Azure OpenAI credentials
docker-compose up
curl -X POST http://localhost:8000/assess \
-H "Content-Type: application/json" \
-d '{"subscription_ids": ["sub-001"],
"tenant_id": "tenant-001"}'
{
"node": "evaluate_mesh", "status": "processing",
"agent": "mesh_evaluator", "timestamp": "..."
}
{
"node": "apply_policies", "status": "processing",
"agent": "policy_engine", "timestamp": "..."
}
Масштабування до продакшну: додавання доменів без змін у конвеєрі обробки
На етапі додавання для масштабування до продакшну необхідно визначити вхідні дані, відповідальну особу за кожен крок та критерії завершення ще до змін у коді. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись визначити прихований стан. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Призначте назви для кожного елемента, визначте критерії успіху та не допускайте мовчазного часткового завершення. Встановіть людське схвалення для тих кроків, які пов’язані з витратами грошей чи змінами у продакшн-даних. Компіляційна налаштування не є гарантією повності виконання завдань у бізнес-сенсі.
Створення власних політик Rego для управління, специфічного для організації
На етапі створення власних політик Rego необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу з демо-середовища у спільні. Встановлюйте людське схвалення для кроків, які спричиняють витрати чи змінюють дані у продакшені. Підключення під час компіляції не є гарантією повноти функціоналу продукту. На етапі створення власних політик Rego необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Документуйте як оптимальний, так і резервний сценарії роботи. Повторні спроби, людське схвалення та обробка некоректних повідомлень є частиною продукту, а не елементами, які додаються пізніше.
ш.decision := result if {
"database" in lower(input.recommendation.resource_type)
_is_destructive_action(input.recommendation.title)
not _has_recovery_plan(input.recommendation.resource_id,
input.context)
result := {
"decision": "deny",
"reason": "Cannot decommission database without
verified recovery plan",
"rule_name": "protect_databases"
}
}
decision := result if {
input.recommendation.estimated_savings > 10000
result := {
"decision": "escalate",
"reason": sprintf("Projected savings $%.0f exceeds
threshold and requires approval",
[input.recommendation.estimated_savings]),
"rule_name": "high_impact_approval"
}
}
Впровадження циклу Sentinel з використанням моніторингу хмари
Під час роботи над етапом впровадження циклу Sentinel спочатку запишіть умови функціонування: необхідні вхідні дані, сигнал про успіх та наслідки часткової несправності. Такий перелік допоможе зберегти чесність подальших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду замість об’ємних скриптів. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну структуру обробки даних. Робіть перевірки після дорогих кроків. Система повторного запуску не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор намагається перезапустити пізніший етап.
Інтеграція циклу Sentinel з моніторингом хмари
Під час роботи над етапами Sentinel Loop та Cloud спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Призначте назви елементам, визначте критерії успіху та не допускайте безповідомного часткового виконання. Робіть контрольні пункти після дорогих кроків. Система відновлення не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор намагається знову виконати пізніший етап.
Спостережуваність: відстеження повного шляху вирішення
Під час роботи над етапом Observability Tracing the Full спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із результатами функціонування. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-середовища до спільних. Робіть контрольні пункти після дорогих кроків. Функція відновлення не повинна знову стягувати плату за той самий виклик LLM, коли оператор перезапускає пізніший етап. Під час роботи над етапом Observability Tracing the Full спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Перезапуски, людські перевірки та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
{
"decision_id": "pd-001",
"recommendation_id": "rec-001",
"policy_name": "protect_critical_resources",
"result": "deny",
"reason": "Policy prevents decommissioning
of critical resource",
"evaluated_at": "2026-03-12T14:23:01Z"
}
{
"conflict_id": "cf-001",
"resolution_strategy": "POLICY_OVERRIDE",
"resolved_by": "policy",
"resolution_outcome": "Resolved by policy:
'protect_critical_resources'
denied 'Decommission idle resource-x'"
}
Короткий огляд архітектури
Етап Короткого огляду архітектури найефективніше функціонує, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад роботи, один випадок збою та примітку щодо скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед складними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Зберігайте стан графа у простому та типованому вигляді. Вкладені структури приховують інформацію про те, який вузол заповнив яке поле, і ускладнюють продовження роботи після перерв.
Чек-лист операцій
Для етапу Чек-листу операцій необхідно визначити вхідні дані, відповідальну особу за кожен крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан.
Зберігайте конфігурацію поза кодом додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код.
Встановіть людське схвалення для операцій, які спричиняють витрати грошей або змінюють дані в продакшені. Підключення на етапі компіляції не є гарантією повноти бізнес-функціоналу.
Напишіть короткий посібник: як оновлювати ключі, як спорожнювати чергу, як скасовувати останнє завантаження даних.
Документуйте як успішний, так і відновлювальний сценарії роботи. Повторні спроби, людське контролювання та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Встановіть людське схвалення для операцій, які спричиняють витрати грошей або змінюють дані в продакшені. Підключення на етапі компіляції не є гарантією повноти бізнес-функціоналу.
Перш ніж запускати стек у продакшн, заморозьте версії, створіть «золотий» запис для критичного шляху та підтвердьте кроки відкату. У спільних середовищах необхідні обмеження на частоту запитів, перевірки прав власності та чіткий власник для зміни секретів. Віддавайте перевагу надійності перед креативними одноразовими демонстраціями.
Примітка до пакету 90ddb9951707: не включайте ключі постачальника до репозиторію, встановіть ліміт токенів на сеанс та зберігайте записи поруч із фікстурами для оцінки, щоб подальша заміна моделей залишалася порівнянною.