Практичні зауваження: Чому ніхто не говорить про LangChain, LangGraph чи AutoAgent
Покроковий посібник з практичних нотаток: чому ніхто не говорить про LangChain, LangGraph чи AutoAgent: контракти, перевірки та готові блоки коду для команд, які використовують цю схему.
У цьому посібнику детально описано шлях від сировини до функціональної системи для теми: «Чому ніхто не говорить про LangChain, LangGraph чи AutoAgent». Основна увага приділяється конкретним крокам виконання, чітким перевіркам та коду, який можна просто додати до репозиторію, не намагаючись здогадатися про його призначення. Для отримання загального огляду необхідно визначити вхідні дані, виконавця кроку та критерії завершення перед зміною коду. Виконавці мають мати можливість перезапустити крок з відомої точки контролю, не намагаючись зрозуміти прихований стан системи. Необхідно одночасно задокументувати шлях успішного виконання та шлях відновлення після проблем. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
┌────────────────────────────────────────┐
│ POST-FRAMEWORK PARADIGM │
└──────────────────┬─────────────────────┘
│
┌─────────────┴─────────────┐
▼ ▼
┌──────────────┐ ┌──────────────┐
│ PIPELINE │ │ HARNESS │
│ MODE │ │ MODE │
├──────────────┤ ├──────────────┤
│ • Bounded │ │ • Unbounded │
│ • Code-Run │ │ • Model-Run │
│ • Compute │ │ • Context │
│ Bound │ │ Bound │
└──────────────┘ └──────────────┘
Зміст
Під час роботи над змістом документа спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну послідовність операцій. Робіть перевірки після дорогих кроків. Система повторного запуску не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор намагається виконати наступний етап.
1. Класифікація роботи, якою ніхто не займається
Під час роботи над розділом «1. Класифікація завдань, яку ніхто не виконує», спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте безповідомного часткового виконання завдань. Робіть контрольні пункти після дорогих кроків. Система повернення до виконання не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор намагається виконати наступний етап.
Is the work decomposable into a finite set of
named states with deterministic transitions?
[ YES ] ──► PIPELINE MODE
• Invoice Extraction
• Document Classification
• Approval Routing
• KYC Verification
• Data Enrichment
[ NO ] ──► HARNESS MODE
• Coding Agents
• Research Agents
• Ephemeral Tool/Shell Use
• Legacy Code Migrations
• Open-Ended Investigation
2. Режим потоку: коли завдання можна розбити на частини
Під час роботи у режимі 2. Pipeline Mode: коли завдання можна розбити на частини, спочатку запишіть умови виконання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Відображення витрат на ранньому етапі запобігає несподіваним рахункам, коли процес переходить від демо-середовища до спільних. Робіть контрольні пункти після дорогих кроків. Функція відновлення не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор перезапускає пізнішу ланку. Під час роботи у режимі 2. Pipeline Mode: коли завдання можна розбити на частини, спочатку запишіть умови виконання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте оптимальний шлях виконання та шлях відновлення. Перезапуски, людське керування та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
[Input Data payload]
│
▼
┌──────────────┐
│ State 1 │ ──► [Structured LLM Call]
└──────┬───────┘ │
│ ▼
│ ┌──────────────┐
│ │ Validation │ ──► [Fail] ──► [Error State]
│ └──────┬───────┘
│ │ [Pass]
▼ ▼
┌──────────────┐
│ State 2 │ ──► [Structured LLM Call]
└──────┬───────┘ │
│ ▼
│ ┌──────────────┐
│ │ Validation │ ──► [Fail] ──► [Error State]
│ └──────┬───────┘
│ │ [Pass]
▼ ▼
[Final Success Output]
3. Режим Harness: коли роботу неможливо розкласти на частини
- Режим Harness: коли роботу неможливо розкласти на частини найкраще використовувати, якщо розглядати його як вимірювану поверхню. Зберіть один ідеальний зразок виконання, один випадок невдачі та примітку про скасування дій перед розширенням обсягу завдань. Віддавайте перевагу невеликим, тестованим одиницям перед складними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Використовуйте інструменти з вузькими схемами та чіткими позначеннями побічних ефектів. Адміністраторам потрібно знати, які виклики змінюють стан системи, перш ніж автоматично схвалювати їх.
┌──────────────────────────────────────────────┐
│ HARNESS LAYER │
│ Executes container limits & system safety │
├──────────────────────────────────────────────┤
│ [Safety Hooks] [Budgets] [Time Constraints] │
├──────────────────────────────────────────────┤
│ ┌────────────────────────────────────────┐ │
│ │ MODEL OWNS LOOP │ │
│ │ Plan ──► Execute ──► Observe ──► Plan │ │
│ │ │ │
│ │ Native capabilities: │ │
│ │ • File / Sandboxed Shell access │ │
│ │ • Context-isolated subagent spawning │ │
│ │ • Skill discovery & loading │ │
│ └────────────────────────────────────────┘ │
└──────────────────────┬───────────────────────┘
▼
Result, Partial State, or Escalation
Способи виникнення невдач у режимі Harness
Режими збоїв режиму Harness працюють найкраще, коли їх розглядають як вимірювану поверхню. Зафіксуйте один ідеальний запис, один випадок збою та примітку про скасування перед розширенням обсягу. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання. Використовуйте інструменти з вузькими схемами та чіткими позначеннями побічних ефектів. Адміністраторам потрібно знати, які виклики змінюють стан, перш ніж вони автоматично схвалять їх.
4. Математична реальність обох режимів
- Математична реальність обох режимів найкраще функціонує, коли її розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу з демо-середовища у спільні середовища. Зберігайте стан графа у випрямленому та типованому форматі. Вкладені блоки приховують інформацію про те, який вузол заповнив яке поле, та ускладнюють відновлення після перерв.
- Математична реальність обох режимів найкраще функціонує, коли її розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу. Документуйте як успішний, так і відновлювальний шляхи роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Режим потоку: закон масштабування часу інференції
Для режиму Pipeline: Закон масштабування часу інференції вимагає визначення вхідних даних, власника кроку та критеріїв завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись відгадати прихований стан. Краще використовувати невеликі, тестовані одиниці замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру процесу. Необхідно включати людське схвалення для операцій, які призводять до витрат грошей чи змінюють продуктивні дані. Компіляційне підключення елементів не є гарантією повноти бізнес-функцій.
Режим Harness: Крива деградації контексту
Для режиму Harness: Крива деградації контексту вимагає визначення вхідних даних, власника кроку та критеріїв завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цю стадію як контракт між вхідними даними та перевіреними результатами. Позначте елементи проекту, визначте критерії успіху та не допускайте беззвучного часткового завершення. Аутентифікуйтеся біля шлюзу та повторно авторизуйтесь на рівні обробки даних. Один лише токен-носій не є межею тенантства.
P(Success)
▲
1.0├───────────┐
│ │
│ └───┐
0.5│ │
│ └─────────────► Context Size (Tokens)
0└───────────┬───┬─────────────
50k 100k
5. Форма Harness у 2026 році (план реалізації)
Для розділу 5. «Форма кріплення 2026 року (план реалізації)» необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу з демо-середовища у спільні середовища. Аутентифікуйтеся біля шлюзу та повторно авторизуйтесь на рівні обробки даних. Один лише токен-носій не є межею тенантства. Для розділу 5. «Форма кріплення 2026 року (план реалізації)» необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Документуйте як успішний, так і відновлювальний сценарії роботи. Повторні спроби, людські контролі та обробка некоректних повідомлень є частиною професійного підходу.
канал, а не полірування пізніше.import logging
import os
from typing import Dict, Any, List
from pydantic import BaseModel, Field
# 2026 SDK abstractions (analogous across major provider frameworks)
from modern_agent_sdk import Agent, Skill, SubAgent
from modern_agent_sdk.hooks import PreToolUse, PostToolUse
from modern_agent_sdk.budgets import TokenBudget, StepBudget, WallTimeBudgetlogger = logging.getLogger("EnterpriseHarness")# 1. Skills are dynamically loaded from disk, not declared inline.
# Each skill is an isolated directory containing metadata (SKILL.md),
# runtime scripts, and specialized sandbox requirements.
SKILLS_DIR = "./skills"
all_skills = Skill.load_directory(SKILLS_DIR)# 2. Safety Hooks: Gateway controls running in the host environment.
# These run on the host *before* any action is committed inside the sandbox.
def pre_tool_execution_hook(context: Dict[str, Any], tool_call: BaseModel) -> PreToolUse:
"""
Validates security boundaries and consumption limits before the model executes a tool.
"""
# Hard safety boundary: Prevent destructive shell operations
if tool_call.name == "execute_shell":
command = tool_call.args.get("command", "")
if any(bad_cmd in command for bad_cmd in ["rm -rf", "chmod", "wget"]):
logger.error(f"Execution blocked: Blocked command detected: '{command}'")
return PreToolUse.deny("Destructive shell operations are prohibited in this sandbox.")
# Budget check: Halt network tools if API budget is running low
if tool_call.name == "network_request":
if context["budget"].remaining_tokens < 15_000:
return PreToolUse.deny("Insufficient remaining token budget to execute external network calls.")
logger.info(f"Approved tool call: {tool_call.name}")
return PreToolUse.allow()def post_tool_execution_hook(context: Dict[str, Any], tool_call: BaseModel, result: Any) -> PostToolUse:
"""
Evaluates tool execution outcomes to detect systemic failure loops.
"""
# Detect repeating error patterns to prevent infinite execution loops
if result.is_error and context["consecutive_failures"] >= 3:
logger.warning("System detected a repeating error loop. Forcing escalation.")
return PostToolUse.escalate("Agent is stuck in an execution failure loop.")
return PostToolUse.continue_loop()# 3. Context Isolation via Subagents
# To prevent context poisoning, the parent agent never sees the child's
# scratchpad or intermediate execution steps—only the final verified output.
def spawn_research_subagent(target_query: str) -> str:
"""
Spawns a specialized subagent in a separate context window to perform a task,
keeping the parent's working context completely clean.
"""
logger.info(f"Spawning isolated subagent for query: '{target_query}'")
subagent = SubAgent(
model="claude-sonnet-4-5",
skills=all_skills.filter_by_tag("research"),
budgets=[
TokenBudget(max_input_tokens=40_000, max_output_tokens=8_000),
StepBudget(max_steps=12)
]
)
# Run task and return only the clean, compiled summary
output = subagent.execute(task=target_query)
return output.summary# 4. Assembling the Harness Container
# The harness manages the execution sandbox, enforces constraints, and handles state.
agent_harness = Agent(
model="claude-opus-4-7",
skills=all_skills,
subagent_factories={
"researcher": spawn_research_subagent
},
hooks={
"pre_tool_use": pre_tool_execution_hook,
"post_tool_use": post_tool_execution_hook
},
budgets=[
TokenBudget(max_total_tokens=600_000),
StepBudget(max_steps=100),
WallTimeBudget(max_seconds=1800) # 30-minute hard cap
],
persistence_store="./.agent_state_db", # State is persisted per step to survive restarts
escalation_handler=lambda issue: open_human_review_ticket(issue)
)# 5. Execution
if __name__ == "__main__":
task_input = "Migrate this legacy Django 4.2 codebase to FastAPI with 100% endpoint parity."
try:
# The agent loop is entirely internal to the model.
# There is no manual 'while True' in our orchestration code.
result = agent_harness.run(task=task_input)
logger.info(f"Task completed. Result: {result.status}")
except Exception as e:
logger.critical(f"Harness terminated execution: {e}")
Ключові відмінності від старих фреймворків 2024 року:
Під час роботи над «Ключовими відмінностями від старих фреймворків 2024 року» спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Робіть перевірки після дорогих кроків. Система повторного запуску не повинна знову стягувати плату за той самий виклик LLM, коли оператор намагається знову виконати пізнішу операцію.
6. Архітектурні конфлікти: застосування неправильної структури до неправильної проблеми
Під час роботи над розділом 6 «Архітектурні колізії: застосування неправильної форми до неправильної проблеми» спочатку складіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань. Робіть перевірки після дорогих кроків. Система повернення до виконання не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор намагається знову виконати пізніший етап.
┌─────────────────────────────────────────────────────┐
│ ARCHITECTURAL MATCH │
├──────────────────────────┬──────────────────────────┤
│ PIPELINE WORKLOAD │ HARNESS WORKLOAD │
├──────────────────────────┼──────────────────────────┤
│ • Goal: Exact Extraction │ • Goal: Code Refactoring,│
│ & Routing │ Agent Tasks, Migration │
│ │ │
│ • WRONG: Harness │ • WRONG: Pipeline │
│ (High latency, costly, │ (FSM State explosion, │
│ non-deterministic) │ inflexible schema) │
│ │ │
│ • RIGHT: Pipeline FSM │ • RIGHT: Sandbox Harness │
│ (Predictable transitions)│ (Dynamic loop execution)│
└──────────────────────────┴──────────────────────────┘
Випадок 1: Помилка Harness-on-Pipeline (надмірна інженерія)
Під час роботи над Случаєм 1: Помилка «Harness-on-Pipeline» (надмірна інженерія), спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-середовища до спільних. Фіксуйте назву інструменту, хеш аргументів, затримку та результат кожного виклику. Без цих записів дебагування може займати години. Під час роботи над Случаєм 1: Помилка «Harness-on-Pipeline» (надмірна інженерія), спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте оптимальний та відновлювальний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Случай 2: Помилка «Pipeline-on-Harness» (недостатня інженерна реалізація)
Случай 2: Помилка «Pipeline-on-Harness» (недостатня інженерна реалізація) найкраще аналізувати як вимірювану характеристику. Збережіть один ідеальний запис діяльності, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям коду перед складними скриптами. Коли якась крок виконання зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру процесів. Використовуйте інструменти з вузькими схемами та чіткими позначеннями побічних ефектів. Адміністраторам потрібно знати, які виклики змінюють стан системи, перш ніж автоматично схвалювати їх.
Як вибрати правильну архітектуру
Як вибрати правильну архітектуру — цей процес найкраще розглядати як вимірювану характеристику. Запишіть один ідеальний приклад роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не погоджуйтесь на мовчазне часткове виконання завдань. Зберігайте структуру графа простою та типованою. Вкладені елементи приховують інформацію про те, який вузол заповнив певне поле, що ускладнює продовження роботи після перерв.
7. Рівень навичок: відкритий стандарт 2026 року
- Шар навичок: Отворений стандарт 2026 року найкраще функціонує, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ. Зберігайте стан графа у простому та типованому вигляді. Вкладені блоки приховують інформацію про те, який вузол заповнив яке поле, і порушують послідовність виконання після перерв.
- Шар навичок: Отворений стандарт 2026 року найкраще функціонує, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу. Документуйте як успішний, так і відновлювальний шляхи роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
skills/
├── document_parser/
│ ├── SKILL.md <-- Human/Model readable metadata & capabilities
│ ├── run.py <-- The execution logic running inside the sandbox
│ └── reference_rules.pdf <-- Domain-specific constraints and edge-cases
8. Висновок: Нова інженерна робота
8. Висновок: Для нової інженерної роботи необхідно визначити вхідні дані, відповідальну особу за кожен крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, тестовані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру процесу. Необхідно включати людське схвалення для тих кроків, які призводять до витрат грошей чи змінюють дані виробництва. Компіляційна налаштування не є гарантією повноти бізнес-процесу.
Чек-лист для експлуатації
Чек-лист для експлуатації найефективніше працює, якщо його розглядати як вимірювану структуру. Перед розширенням обсягу необхідно зафіксувати один ідеальний приклад виконання, один випадок невдачі та примітки щодо скасування змін.
Зберігайте конфігурацію поза кодом додатку. Файли середовища, сховища секретів та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь граф.
Зберігайте стан графа у вигляді плоскої структури з типизацією. Вкладені блоки приховують інформацію про те, який вузол заповнив яке поле, і ускладнюють продовження роботи після перерв.
Коли дозволяє бюджет, додавайте тест на базову функціональність, який перевіряє критичний шлях у процесі CI за допомогою фікстур, а не реальних платних API.
Документуйте як шлях успішної роботи, так і шлях відновлення одночасно. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Зберігайте стан графа у вигляді плоскої структури з типизацією. Вкладені блоки приховують інформацію про те, який вузол заповнив яке поле, і ускладнюють продовження роботи після перерв.
Перш ніж запускати стек у продакшн, заморозьте версії, створіть «золотий» запис для критичного шляху та підтвердьте кроки відкату. У спільних середовищах необхідні обмеження на частоту використання, перевірки прав доступу та чіткий власник для зміни секретів. Віддавайте перевагу надійності перед креативними одноразовими демонстраціями.
Примітка до 9f921d978495: не включайте ключі постачальника до репозиторію, встановіть ліміт токенів на сеанс та зберігайте записи поруч із фіксами для оцінки, щоб подальша заміна моделей залишалася порівнянною.