Dziś podzielę się architekturą inżynieryjną, którą stworzyłem dla gry OpenClaw (która również nadaje się do innych produktów i gier opartych na agentach). Ten produkt nie tylko jest przeznaczony dla ludzi, ale także dla agentów, aby zrozumieć i eksplorować świat. Dlatego od samego początku architektura musi uwzględniać dwie rzeczy: jak agent rozumie treść oraz jak ludzcy gracze mogą uzyskać synchronizację, a nawet lepsze doświadczenie. Ostatecznie podzieliło się to na trzy kluczowe części: kod logiki gry, umowa API, SKILL. Wczesny etap (pozwolenie OpenClaw na prowadzenie API i SKILL) Na początku Claude miał dość płytkie zrozumienie gry, więc jeśli pozwoliłem mu od razu pisać API i SKILL, często pomijał ważną logikę gry i punkty doświadczenia gracza. Dlatego najpierw pozwoliłem OpenClaw zbudować architekturę SKILL. Przekształcił wcześniej stworzone przeze mnie proste umiejętności RESPONSE i MONITOR w nową strukturę, która lepiej pasuje do rozgrywki, i wypełnił ją głównymi treściami (zobacz rysunek 1): - SKILL.md: jako główny SKILL, przewodnik wprowadzający + zbiór często używanych API - HEARTBEAT.md: monitorowanie w czasie rzeczywistym i synchronizacja stanu - SOCIAL.md: interakcje społeczne, takie jak goście, tablica wiadomości, kradzież plonów itp. - RULES.md: ograniczenia zachowań agenta, optymalizacje, które zapewniają lepsze doświadczenie gry i immersję dla graczy - TRAVEL.md: rozgrywka podróżnicza (generowanie selfie, losowe wydarzenia, system prezentów), o wyższej złożoności, stworzono osobne wejście Po zbudowaniu solidnych fundamentów OpenClaw wiedział, kiedy samodzielnie zająć się sprawami, a kiedy przekazać kluczowe informacje do mnie. Drugi etap (przekazanie Claude'owi, dodanie weryfikacji przez ludzi) Gdy fundamenty były stabilne, zacząłem pozwalać Claude'owi automatycznie aktualizować SKILL i API, ponieważ przestrzegając zasad dotyczących innych zmian w kodzie, jego wydajność w API i SKILL znacznie się poprawiła w porównaniu do początków. Jednak musiałem również utrzymać nawyk: po każdej dużej zmianie w kodzie, pozwalałem cc sprawdzić, czy SKILL i API są zgodne z najnowszą wersją. Na przykład na rysunku 2, poprosiłem go o przegląd ostatnich trzech dni logów commitów, odkrywając, że około 4/5 zmian można zsynchronizować, a tylko około 1/5 wymagało ostatecznej weryfikacji i uzupełnienia. Ciekawe jest to, że im bardziej projekt był dopracowany, tym głębsze było zrozumienie doświadczenia gracza przez Claude'a. Powoli zaczynał rozróżniać, które zmiany są istotne dla ludzkich graczy, a które są jedynie wewnętrznymi dostosowaniami na poziomie bazy danych. Moim pierwszym błędem było: utrzymywanie tylko dwóch umiejętności RESPONSE i MONITOR, całkowite zignorowanie synchronizacji dokumentacji API. To bezpośrednio doprowadziło do poważnego opóźnienia w zrozumieniu świata przez agenta. Obecnie myślę tak: najpierw zapewnić integralność ludzi (szczególnie wizualne doświadczenie front-end), a następnie skupić się na tym, jak agent lepiej zrozumie ten świat. Poprzez ciągłe optymalizowanie architektury SKILL, zachowanie agenta i przyjemność ludzkich graczy powinny być zawsze ze sobą powiązane, a nie dwoma równoległymi liniami. Chociaż przeszliśmy przez wiele zakrętów, coraz bardziej czuję, że produkty oparte na agentach naprawdę muszą traktować "tworzenie świata dla agenta" i "zapewnienie dobrego doświadczenia dla ludzi" jako jedną i tę samą rzecz.

Czuję, że codex to osoba typu S, a claudecode to osoba typu N. Czy ktoś to rozumie? .. codex wykonuje zadania bardzo dokładnie, ale zrozumienie intencji jest nieco słabe, podczas gdy claudecode rozumie szybko i precyzyjnie, ale zawsze wymaga drobnych poprawek.

W claudecode użycie codex review to mały atom multi-agent! Kto wymyślił, że dorośli nie podejmują wyborów, tylko chcą wszystko? 🥹 Dziś znów byłem prowadzony przez przyjaciela inżyniera.