Ingegneria del contesto per gli agenti AI: audit del ciclo di contesti di Manus

La risposta pratica a Ingegneria del contesto per gli agenti AI: Lezioni da Building Manus è non copiare sei trucchi di prompt. Trasforma ogni lezione in un invariante che puoi controllare durante una corsa. Un prefisso prompt stabile dovrebbe avere una versione e un hash. Uno strumento menzionato nella storia dovrebbe comunque avere uno schema risolvibile. Il materiale compatto deve avere un riferimento riprovibile. L'obiettivo attuale dovrebbe avere un limite di revisione e di freschezza. Le azioni fallite dovrebbero lasciare prove ridotte. Le azioni ripetute devono essere confrontate con i cambiamenti di output. Un rapporto terminale dovrebbe comunque richiedere una ricevuta di risultato. Questo ti dà un contratto di contesti sanitari. Può distinguere tra una corsa efficiente, una corsa recuperabile, una corsa che fa progressi utili, e una corsa che in realtà è sicura da chiamare completa. I segnali di cache e i numeri di token inferiori aiutano, ma nessuno dei due dimostra che l'agente ha conservato le prove necessarie per finire correttamente. Leggi le lezioni di Manus come affermazioni con confini L'originale Posizione di ingegneria di Manus descrive le scelte di progettazione locali raggiunte durante la costruzione del suo framework di agenti. Il suo autore riferisce un rapporto medio di token input output di circa 100:1 per Manus e sostiene che il comportamento prefisso cache importa quindi molto alla latenza e al costo. Il post raccomanda: mantenere stabile il prefisso immediato e deterministico la serializzazione; mascherare le azioni invece di rimuovere le definizioni degli strumenti a metà esercizio; esternalizzare il contesto di grandi dimensioni ai file riprovibili; riscrivere un elenco di attività in modo da riportare l'obiettivo all'attenzione recente; mantenere le azioni e le osservazioni fallite in modo che il modello possa adattarsi; l'introduzione di variazioni controllate per resistere a modelli comportamentali ripetitivi. Queste sono ipotesi ingegneristiche utili, non soglie universali. Le cache dei fornitori differiscono. Alcuni tempi di esecuzione possono modificare in modo sicuro gli schemi di strumenti storici. Un URL può essere conservato ma più tardi diventa inaccessibile. Le tracce della pila grezza possono contenere segreti. Ripetere l'obiettivo ogni otto passi è un valore di prova, non una legge generale. Le prove indipendenti sostengono anche che la capacità di contesto pubblicizzata non sia una garanzia per la salute. Anthropic orientamento per l'ingegneria del contesto definisce il contesto come lo stato di inferenza completo delle istruzioni del sistema, degli strumenti, dei dati esterni e della storia dei messaggi e raccomanda di mantenere il più piccolo set di segnali alti che supporta il comportamento desiderato. Esso descrive anche il recupero just in time, la divulgazione progressiva, la compattazione, le note strutturate e la separazione multi agenti come diverse strategie con costi diversi. I Chroma controllati Context Rot valutazione hanno testato 18 modelli con lunghezza di ingresso variabile e hanno riportato degradazioni non uniformi. I distrattori, la distanza semantica e la struttura del fieno hanno cambiato le prestazioni. L'implicazione operativa è modesta ma importante: all'interno del limite di contesto non è un verdetto. Hai ancora bisogno di prove che il contesto attuale supporti la decisione attuale. Costruire una ricevuta per sei mutazioni di contesto Capture hashes e contatori, non indicazioni crude. A ciascun punto di decisione può essere allegato una ricevuta utile: I campi rispondono a domande separate. Prefix stabilità è un controllo di efficienza. Registrare la versione stabile del modello e un hash di contenuto sul prefisso cachebile. escludere da tale prefisso valori volatili come un timestamp per richiesta, se il tempo di esecuzione lo consente. Un cambiamento di hash non è automaticamente un errore di attività: se l'output utile è ancora in movimento, classificare la corsa come degradata e indagare il churn. Continuità dello schema strumento è un controllo dell'integrità delle decisioni. Tenere un registro di schemi di versione o una traduzione esplicita dalle chiamate storiche degli strumenti al loro contratto di definizione. Se una azione precedente dice browser fetch ma il contesto attuale non definisce più tale azioneo una versione compatibileil modello può essere un ragionamento basato su un record incompleto. Questo dovrebbe bloccare un buon verdetto. Restorbabile contesto esterno è un controllo di recupero. Un percorso di file, chiave oggetto, query o URL è solo un riferimento. Accoppiatelo con una digestione dell'integrità quando possibile, un ultimo controllo di accessibilità, la portata e l'operazione che lo ripristina. Il rilascio di un documento dalla finestra live pur conservando un riferimento verificato è una compressione reversibile. L'abbatterla senza alcun riferimento utilizzabile è perdita di prove. L'obiettivo di freschezza è un controllo di attenzione. Una revisione del piano di attività dovrebbe identificare l'obiettivo attivo, i vincoli accettati, le tappe miliari completate e la prossima decisione. Misura la sua età in passi o in tempo. Non aggiungere infinitamente piani duplicati; aggiornare una ricevuta compatta quando il lavoro cambia significativamente o il suo limite di freschezza scade. Reteramento di errori è un controllo di apprendimento e di audit. Contare le azioni fallite e i record di fallimenti conservati. Immagazzinare la classe di errore, lo strumento, l'identità di tentativo, la decisione di riprova e un digest modificato non in modo arbitrario. Se si sono verificate due fallimenti, ma resta solo un registro sicuro, un ulteriore tentativo non può essere giustificato da prove complete. Repetition versus progress è un controllo di deriva. Un'azione ripetuta non è un ciclo in se stessa: paginazione, sondaggi e retries limitati possono essere legittimi. Combinare una firma di azione con un contatore delta di uscita, freschezza oggettiva, stato di dipendenza e bilancio di riprova. Tre azioni ripetute con manufatti modificati possono funzionare; tre senza delta di stato meritano un verdetto di loop risk. Le lezioni di prefisso stabile e di variazione controllata non sono contraddittorie. Tenere deterministici il prefisso cacheable e i contratti degli strumenti. Applicare la variazione necessaria dopo quel prefisso in esempi, osservazioni di azione o una politica di selezione limitata e misurare se cambia il progresso utile. Applicare una regola di precedenza invece di misurare i segnali Non crollare questi campi in un solo punteggio opaco. Un prefisso economico e stabile con un contesto irrecuperabile non è soprattutto sano. Utilizzare la priorità: 1. unsafe le referenze storiche degli strumenti non sono risolte, le prove compatte non sono riprovabili o un record di guasto è scomparso; 2. loop risk l'obiettivo è obsoleto e le azioni si ripetono senza variazioni di uscita; 3. unverified l'agente segnala il completamento terminale senza ricevimento di risultato valido; 4. healthy ogni invariante di contesto passa e viene verificato il risultato specifico del compito; 5. degraded l'integrità del contesto rimane intatta, ma il prefisso churn o un altro errore di efficienza è presente; 6. Working passano invarianti, le uscite utili cambiano e la corsa non è terminale. Questo ordinamento rende deliberatamente i fallimenti di integrità più forti dei guadagni di efficienza. L'apparecchio di accompagnamento modifica una condizione alla volta: Risultato atteso: Gli otto casi includono un risultato verificato, un utile progresso intermedio, un prefisso che non è stato accertato, una derivazione dello schema degli strumenti, una compressione irreversibile, prove di fallimento cancellate, una ripetizione di obiettivi obsoleti e un completamento segnalato senza ricevimento. Un risultato è intenzionalmente inconveniente: il caso cache churn è degraded , non pericoloso. Il suo prefisso è cambiato, ma gli schemi, i riferimenti, i fallimenti e i progressi utili rimangono intatti. Al contrario, irreversible compaction è unsafe anche se il suo prefisso è stabile. Questa è la differenza tra un problema di costi e un problema di prove. Verificare la ricevuta senza raccogliere la conversazione La ricevuta dovrebbe rivelare l'esistenza di prove senza caricare le prove stesse. Per il prefisso, conservare un identificatore di modello e digest. Per gli strumenti, conservare la versione dello schema, il nome dell'azione e il risultato di compatibilità. Per il contesto esterno, conservare un riferimento di ambito, digest, conto di byte, risultato di accessibilità e tempo di freschezza. Per i fallimenti, conservare una classe ed un identificatore di tentativo modificato. Per il progresso, conservare i hash o i contatori per gli artefatti attesi. Mantenere le richieste, risposte, credenziali, carichi utili di strumenti grezzi e percorsi di host assoluti fuori dalla telemetria condivisa a meno che un contratto di dati esplicito e separato non ne richieda. Usate tre test prima di adottare il contratto. Prima, eseguire un Single mutation replay . Inizia da un'apparecchiatura nota e cambia solo un campo. Il verdetto dovrebbe cambiare per la ragione che si aspetta. Se la rimozione di un riferimento restauribile lascia lo stato sano, la regola è troppo debole. In secondo luogo, eseguire un canario redazione . Mettere un segreto sintetico in un carico utile di fallimento, elaborarlo attraverso il costruttore di ricevute, e affermare che il segreto è assente mentre la classe di errore e la decisione di riprova sopravvive. La conservazione delle "materiali sbagliati" non autorizza la conservazione di contenuti sensibili. In terzo luogo, eseguire un controesempio di risultato . Inserire al classificatore un messaggio di agente terminale mentre non si riceve la ricevuta effettivamente consegnabile. Deve restituire unverified . Poi aggiungere la verifica specifica di un file digest, test di passaggio, lettura dell'API di destinazione o approvazione umana e confermare che solo questa modifica consente healthy . Il controllo dei risultati è necessariamente specifico per il flusso di lavoro. Un compito di ricerca potrebbe richiedere la copertura della fonte citata e un rapporto salvato. Un compito di distribuzione potrebbe richiedere una risposta sanitaria in diretta e parità di versione. Un'attività di posta elettronica potrebbe richiedere la lettura della casella postale di destinazione. Non vi è alcuna prova che un obiettivo arbitrario sia stato raggiunto. Utilizzare il contratto come limite, non come pretesa di prodotto Il post di Manus è prezioso perché espone le vere tensioni di progettazione: l'efficienza della cache rispetto al contesto mutabile, le finestre più piccole rispetto alla perdita irreversibile, il comportamento stabile rispetto alla ripetizione e la pulizia degli errori rispetto alle prove di apprendimento. La mossa operativa è quella di rendere le tensioni ispezionabili. Adottate il contratto quando potete rispondere a queste domande per una vera e propria corsa: È cambiato il prefisso cacheable, e era previsto? È ancora possibile interpretare ogni azione di uno strumento storico? È possibile ripristinare ogni osservazione omessa e verificare l'integrità? L'obiettivo attuale è sufficientemente fresco per la prossima decisione? Ogni azione fallita ha lasciato prove sicure? Le azioni ripetute modificano lo stato del compito? Quale ricevuta separata prova il risultato richiesto? Se non si conosce alcuna risposta sull'integrità, conservare unknown o unsafe ; non produrre verde. Se solo l'efficienza si degrada mentre le prove e i progressi rimangono solidi, mantenere il funzionamento e risolvere separatamente il problema dei costi. Sidewisp è attualmente in anteprima privata. La sua esperienza pubblica è un sito web di accesso precoce e una dimostrazione interattiva; la raccolta di agenti di produzione e il monitoraggio del contesto non vengono generalmente inviati. La direzione del prodotto prevista è quella di trasformare le prove come la freschezza, la continuità del contesto, i progressi utili e i risultati verificati in una visione chiara della salute mantenendo visibili l'incertezza e i confini di approvazione.