Máis alá do prototipo: 15 leccións difíciles para axentes de IA preparados para a produción de buques

Unha guía para enxeñeiros e construtores de IA Normalmente comeza con algunhas liñas de Python e unha clave de API ChatGPT. Engadir algunhas liñas de contexto, executar e asombrarse de que responde en todo. Entón, quere que faga algo útil. Entón, de forma fiable. Entón, sen ti. É cando se dá conta de que xa non está só chamando un LLM. Está construíndo un axente. Pasei o último ano xuntando scripts e envases, xogando con cadeas LangChain que se sentían máis como unha casa de cartas que sistemas, e constantemente preguntando, " ” Como é que a xente realmente está enviando estas cousas? Perseguín patróns que parecían elegantes en teoría, pero colapsaron no momento en que apareceron os usuarios reais.Construín axentes que funcionaron perfectamente nun notebook e fracasaron espectacularmente na produción. Non o fixo. O que me axudou foi desacelerar, retirar as cousas e prestar atención ao que realmente funcionaba baixo carga, non ao que parecía intelixente en LinkedIn. Se pasaches por retos similares, está escrito para ti. Esta guía é unha destilación desa claridade gañada Considere isto como unha guía pragmática para pasar de envases e cadeas de API a sistemas de IA estables, controlables e escalables. Parte 1 - Obter a fundación correcta Os primeiros prototipos de axentes a miúdo se xuntan rapidamente: algunhas funcións, algunhas prompts, e velaí, funciona. Podes preguntar: "Se funciona, por que complicar as cousas?" Ao principio, todo se sente estable: o axente responde, executa o código e actúa como se esperaba. Pero no momento en que cambia o modelo, reinicia o sistema ou engade unha nova interface, as cousas rompen. : mala xestión da memoria, valores de código duro, ningunha persistencia de sesión ou un punto de entrada ríxido. Normalmente, o problema non é a lóxica ou as recomendacións; é máis profundo Esta sección cobre catro principios clave para axudarche a crear unha base sólida, unha base onde o teu axente poida crecer e escalar de forma fiable. 1 - Externalización do Estado : The Problem Non pode continuar se o axente é interrompido, accidentes, tempos fóra, o que sexa. Reproducibilidade: quere reproducir o que pasou para a proba e o borrador. Desafío de bonos: máis cedo ou máis tarde, quererás executar partes do axente en paralelo, como comparar opcións no medio da conversación ou a lóxica de ramificación (a xestión da memoria é un tema separado que cubriremos en breve). Move todo o estado fóra do axente, a unha base de datos, caché, capa de almacenamento, ou mesmo un simple ficheiro JSON. The Solution : Your Checklist O axente comeza a partir de calquera paso usando só un session_id e estado externo (por exemplo, gardado nun DB ou JSON). Pode interromper e reiniciar o axente en calquera momento (mesmo despois de cambios de código) sen perder o progreso ou romper o comportamento. O estado é totalmente serializable sen perder funcionalidade. O mesmo estado pode ser alimentado a múltiples instancias de axentes que se executan en paralelo durante unha conversación. 2 - Externalizar coñecementos Mesmo nunha sesión, poden esquecer o que lles dixeches, mesturar as etapas da conversación, perder o fío ou comezar a "encher" detalles que non estaban alí. The Problem O modelo céntrase no comezo e o final, perdendo importantes detalles intermedios. Máis tokens custan máis diñeiro. O límite aínda existe: os transformadores traballan con autoatención a complexidade O(n2), polo que o contexto infinito é imposible. Isto é máis difícil cando: As conversacións son longas Os documentos son amplos As instrucións son complexas Separa a "memoria de traballo" do "almacenamento", como nos ordenadores clásicos.O teu axente debe manexar a memoria externa: almacenar, recuperar, resumir e actualizar coñecementos fóra do propio modelo. The Solution : Common approaches Buffer de memoria: almacena as últimas mensaxes k. Rápido para prototipar, pero perde a información máis antiga e non escala. Memoria de resumo: comprime a historia para encaixar máis no contexto. gasta tokens pero corre o risco de distorsión e perda de matiz. RAG (Retrieval-Augmented Generation): obtén coñecemento de bases de datos externas. Escalable, fresco e verificable, pero máis complexo e sensible á latencia. Gráficos de coñecemento: conexións estruturadas entre feitos e entidades.Elegante e explicable, pero complexa e alta barreira á entrada. : Your Checklist Todo o historial de conversación almacénase fóra do prompt e é accesible. As fontes de coñecemento son rexistradas e reutilizables. A historia pode crecer indefinidamente sen bater os límites da xanela de contexto. 3 - Fai o modelo intercambiable : Os LLM evolucionan rapidamente: OpenAI, Google, Anthropic e outros actualizan constantemente os seus modelos. Como enxeñeiros, queremos aproveitar estas melloras rapidamente. Problem : Solution Utilice un parámetro model_id en configuracións ou variables ambientais para especificar que modelo usar. Construír interfaces abstractas ou clases de envoltorio que falen cos modelos a través dunha API unificada. Opcionalmente, aplique as capas de middleware con coidado (os cadros veñen con compromisos). : Checklist Cambiar o modelo non rompe o código nin afecta a outros compoñentes como a memoria, a orquestración ou as ferramentas. Engadir un novo modelo significa simplemente actualizar a configuración e, se é necesario, engadir unha simple capa de adaptador. O cambio de modelos é rápido e sinxelo - ideal para soportar calquera modelo, ou polo menos cambiar facilmente dentro dunha familia de modelos. 4 - Un axente, moitos canais : Mesmo se o seu axente comeza cunha única interface (por exemplo, unha interfaz de usuario), os usuarios en breve quererán máis formas de interactuar: Slack, WhatsApp, SMS, quizais mesmo un CLI para a debugue. Problem Crea un contrato de entrada unificado, unha API ou unha interface universal que todos os canais alimentan. Solution : Checklist O axente funciona a través de CLI, API, UI ou calquera outra interface Todas as entradas fúnnense a través dun único punto final, parser ou esquema Cada interface usa o mesmo formato de entrada Ningunha lóxica de negocio vive dentro de ningún adaptador de canles Engadir novas canles significa simplemente escribir un adaptador - sen cambios no código do axente principal Parte 2 - Move Beyond Chatbot Mode Aínda que só hai unha tarefa, todo é sinxelo, como nas publicacións de influencers de IA. Pero unha vez que engades ferramentas, lóxica de toma de decisións e múltiples etapas, o axente convértese nun caos. Perde a pista, non sabe que facer cos erros, esquece chamar a ferramenta correcta, e volve quedar só con rexistros, onde "ben, todo parece estar escrito alí". Para evitar isto, o axente necesita un modelo de comportamento claro: o que fai, que ferramentas ten, quen toma decisións, como interveñen os humanos e que facer cando algo vai mal. Esta sección cobre cinco principios clave para axudar a mover o seu axente máis aló dun simple chatbot, construíndo un modelo de comportamento coherente que poida usar ferramentas de forma fiable, xestionar erros e executar tarefas complexas. 5 - Deseño para uso de ferramentas : Pode soar obvio, pero moitos axentes aínda dependen de "Plain Prompting + Raw LLM output parsing." É como tentar corrixir un motor de automóbil ao xirar bobinas aleatoriamente. Problem Fragilidade: Un pequeno cambio na orde de palabras ou frases pode romper a súa análise, creando unha constante carreira de armas entre o seu código e a imprevisibilidade do modelo. A linguaxe natural é vaga: “Call John Smith”. : Parsing code gets tangled and hard to debug. Each new agent “skill” means writing more parsing rules. Maintenance complexity Capacidades limitadas: É difícil chamar de forma fiable varias ferramentas ou pasar estruturas de datos complexas a través de texto sinxelo. : Deixe que o modelo devolva JSON (ou outro formato estruturado), e deixe que o seu sistema xestione a execución. para facer, e o seu código coida de ocorre, executando a función correcta a través dunha interface ben definida. Solution que como A maioría dos provedores (OpenAI, Google, Anthropic, etc.) agora soportan ou : function calling structured output Define as súas ferramentas como esquemas JSON cun nome, descrición e parámetros. Cada vez que chama o modelo, proporciona estes esquemas de ferramentas xunto ao prompt. O modelo devolve JSON especificando: (1) a función a chamar, (2) Parámetros segundo o esquema O seu código valida o JSON e invoca a función correcta con eses parámetros. Opcionalmente, a saída da función pode ser devolta ao modelo para a xeración de resposta final. : As descricións de ferramentas forman parte da prompt. Se non están claras, o modelo pode escoller a ferramenta incorrecta. E se o seu modelo non soporta a chamada de función, ou quere evitalo? Important Pídelle ao modelo que produza a saída JSON a través da enxeñaría rápida e valida con bibliotecas como Pydantic. Isto funciona ben pero require unha formatación coidadosa e un manexo de erros. : Checklist As respostas están estruturadas estritamente (por exemplo, JSON) As interfaces de ferramentas son definidas con esquemas (JSON Schema ou Pydantic) A saída é validada antes da execución Os erros de formato non colisionan co sistema (tratamento de erros graciosos) LLM decide que función chamar, o código xestiona a execución 6 - Pór a lóxica de control no código A maioría dos axentes hoxe comportanse como chatbots: o usuario di algo, o axente responde.É un patrón de ping-pong; simple e familiar, pero profundamente limitante. Problem: Con esta configuración, o seu axente non pode: Actúa por conta propia sen unha solicitude de usuario Executar tarefas en paralelo Plano e secuencia de múltiples pasos Retry fracasou pasos intelixentemente Traballo en segundo plano É reactivo en vez de proactivo. Un que mira o traballo por diante, descobre o que facer a continuación, e avanza sen esperar a que o peguen. What you really want is an agent that thinks like a scheduler Isto significa que o seu axente debe ser capaz de: Toma de iniciativa Cadea múltiple pasos xuntos Recuperar do fracaso Cambio entre tarefas Seguide traballando, aínda que ninguén o vexa Move the control flow out of the LLM and into your system. The model can still help (e.g., decide which step comes next), but the actual sequencing, retries, and execution logic should live in code. Solution: This flips your job from Dúas O modelo convértese nunha peza dunha arquitectura máis ampla, non no mestre de bonecas. prompt engineering Deseño do sistema Dividamos tres xeitos en que os equipos se achegan a este cambio. 1. Finite State Machine (FSM) Break the task into discrete states with defined transitions. What it is: Acts within a state or helps pick the next one. LLM role: Linear, predictable flows. Best for: Simple, stable, easy to debug. Pros: Ferramentas: StateFlow, configuracións de YAML, patróns de estado clásicos en código. 2. Directed Acyclic Graph (DAG) Representa as tarefas como un gráfico: os nodos son accións, os bordos son dependencias. LLM papel: Actúa como un nodo ou axuda a xerar o gráfico. Branching flows, parallel steps. Best for: Pros: Flexible, visual, bo para recomputación parcial. Ferramentas: LangGraph, Trellis, LLMCompiler ou DIY cun gráfico lib. 3. Planner + Executor O que é: Un axente (ou modelo) constrúe o plan; outros execútano paso a paso. LLM papel: grandes plans de modelos, pequenos (ou código) executar. Modular systems, long chains of reasoning. Best for: Pros: Separación de preocupacións, escalable, rendible. Ferramentas: Plan-and-Execute de LangChain, ou a súa propia arquitectura de planificador/executor. Why This Matters You gain control over the agent’s behavior You can retry, debug, and test individual steps You can scale parts independently or swap models Facer as cousas visibles e rastrexables en lugar de opacas e máxicas Checklist Agent follows the FSM, DAG, or planner structure LLM suggests actions but doesn’t drive the flow You can visualize task progression Error handling is baked into the flow logic 7 — Keep a Human in the Loop Mesmo con ferramentas, fluxo de control e saídas estruturadas, a plena autonomía aínda é un mito. Non poden ser responsabilizados.E no mundo real, farán a chamada equivocada (antes ou despois). Problem: understand When agents act alone, you risk: Erros irreversibles: borrar rexistros, enviar mensaxes á persoa equivocada, enviar diñeiro a unha carteira morta. Problemas de cumprimento: violación de políticas, leis ou normas sociais básicas. Comportamento estraño: saltar pasos, alucinar accións ou simplemente facer algo que ningún ser humano xamais faría. : users won’t rely on something that seems out of control. Broken trust Ningunha responsabilidade: cando se rompe, non está claro o que pasou mal ou quen posúe a desorde. Solution: Bring Humans Into the Loop (HITL) Treat the human as a co-pilot, not a fallback. Design your system to , , or decisions to a person when needed. Not everything should be fully automatic. Sometimes, “Are you sure?” is the most valuable feature you can build. pause Pregunta Camiño Ways to Include Humans Portas de aprobación: Accións críticas ou irreversibles (por exemplo, envío, eliminación, publicación) requiren confirmación humana explícita. When the model’s confidence is low or the situation is ambiguous, route to a human for review. Escalation paths: Corrección interactiva: Permite aos usuarios revisar e editar as respostas do modelo antes de envialas. Capture human feedback to improve agent behavior and train models over time (Reinforcement Learning from Human Feedback). Feedback loops: Opcións de sobrecarga: Permite que os seres humanos interrompan, sobrecarguen ou reenvíen o fluxo de traballo do axente. Checklist As accións sensibles son confirmadas por un ser humano antes da execución There’s a clear path to escalate complex or risky decisions Users can edit or reject agent outputs before they’re final Logs and decisions are reviewable for audit and debugging O axente explica por que tomou unha decisión (na medida do posible) 8 - Os erros de alimentación volven ao contexto A maioría dos sistemas colapsan ou detense cando ocorre un erro.Para un axente autónomo, iso é un fin morto. Problem: What can go wrong: Fragilidade: calquera fallo, xa sexa un erro de ferramenta externa ou unha saída LLM inesperada, pode romper todo o proceso. Frequent restarts and manual fixes waste time and resources. Inefficiency: Without awareness of its own errors, the agent can’t improve or adapt. No Learning: Errors unaddressed can lead to misleading or fabricated responses. Hallucinations: Treat errors as part of the agent’s context. Include them in prompts or memory so the agent can try self-correction and adapt its behavior. Solution: How it works: Capture error messages or failure reasons clearly. Understand the error: Auto-corrección: O axente reflexiona sobre o erro e intenta corrixilo: (1) detectando e diagnosticando o problema, (2) axustando os parámetros, reformulando as solicitudes ou cambiando as ferramentas, (3) retomando a acción con cambios. O contexto de erro é importante: a información detallada sobre erros (como instrucións ou explicacións) axuda ao axente a corrixirse mellor. Incorporate error-fix examples into model training for improved resilience. Training for self-correction: Escala humana: Se a auto-corrección falla repetidamente, escale a un humano (ver Principio 7). Checklist: Os erros dos pasos anteriores son gardados e introducidos no contexto Retry logic is implemented with adaptive changes Repeated failures trigger a fallback to human review or intervention 9 - O traballo dividido en micro-axentes The larger and messier the task, the longer the context window, and the more likely an LLM is to lose the plot. Complex workflows with dozens of steps push the model past its sweet spot, leading to confusion, wasted tokens, and lower accuracy. Problem: Dividir e conquistar. usar , each responsible for one clearly defined job. A top-level orchestrator strings them together. Solution: small, purpose-built agents Why small, focused agents work Contexto xestionable: as fiestras máis curtas manteñen o modelo afiado. one agent, one task, zero ambiguity. Clear ownership: simpler flows mean fewer places to get lost. Higher reliability: you can unit-test each agent in isolation. Easier testing: when something breaks, you know exactly where to look. Faster debugging: There’s no magic formula for when to split logic; it’s part art, part experience, and the boundary will keep shifting as models improve. A good rule of thumb: if you can’t describe an agent’s job in one or two sentences, it’s probably doing too much. Checklist The overall workflow is a series of micro-agent calls. Each agent can be restarted and tested on its own. Podes explicar a definición de Axente en 1 a 2 frases. Parte 3 - Estabilización do comportamento Most agent bugs don’t show up as red errors; they show up as weird outputs. A missed instruction. A half-followed format. Something that almost works… until it doesn’t. That’s because LLMs don’t read minds. They read tokens. A forma en que enmarcas as solicitudes, o que pasas ao contexto e a forma en que escribes as indicacións, todo iso forma directamente o resultado. E calquera erro nesa configuración convértese nun bug invisible que espera a que se vexa máis tarde. . se non estás atento, cada interacción desvíase lentamente do curso This section is about tightening that feedback loop. Prompts aren’t throwaway strings, they’re code. Context isn’t magic, it’s a state you manage explicitly. And clarity isn’t optional, it’s the difference between repeatable behavior and creative nonsense. 10 - Tratar Prompts como código Too many projects treat prompts like disposable strings: hardcoded in Python files, scattered across the codebase, or vaguely dumped into Notion. As your agent gets more complex, this laziness becomes expensive: Problem: It’s hard to find, update, or even understand what each prompt does There’s no version control — no way to track what changed, when, or why A optimización convértese en adiviñación: sen loop de retroalimentación, sen probas A/B E debugando un problema relacionado con prompt é como tentar corrixir un bug nun comentario code. They define behavior. So manage them like you would real code: Solution: Prompts are from your logic: store them in , , , or use template engines like Jinja2 or BAML Separate them txt .md .yaml .json with your repo (just like functions) Version them Proba-los: (1) respostas de proba de unidade para formato, palabras clave, validez JSON, (2) Execute evals sobre variacións prompt, (3) Use LLM-as-a-judge ou puntuación heurística para medir o rendemento Se un cambio pode afectar o comportamento de saída, merece un segundo conxunto de ollos. Bonus: Checklist: Prompts live outside your code (and are clearly named) They’re versioned and diffable They’re tested or evaluated Eles pasan por revisións cando importa 11 — Engineer the Context Stack We’ve already tackled LLM forgetfulness by offloading memory and splitting agents by task. But there’s still a deeper challenge: Formateamos e entregamos información ao modelo. Problem: how Most setups just throw a pile of role: content messages into the prompt and call it a day. That works… until it doesn’t. These standard formats often: Burn tokens en metadatos redundantes Loita para representar cadeas de ferramentas, estados ou varios tipos de coñecemento Non guiar correctamente o modelo en fluxos complexos E aínda así, aínda esperamos que o modelo "só o descubra". que non é enxeñaría. que son vibracións. Solution: Engineer the context. Tratar todo o paquete de entrada como unha interface coidadosamente deseñada, porque iso é exactamente o que é. : Here’s how : Control what gets in, how it’s ordered, and where it shows up. Everything from system instructions to retrieved docs to memory entries should be intentional. Own the full stack Ir máis aló do formato de chat: Construír formatos máis ricos e densos. bloques de estilo XML, esquemas compactos, pegadas de ferramentas comprimidas, mesmo seccións de Markdown para a claridade. Pensar holisticamente: Contexto = todo o que o modelo ve: prompt, estado de tarefas, decisións previas, rexistros de ferramentas, instrucións, mesmo saídas previas. This becomes especially important if you’re optimizing for: packing more meaning into fewer tokens Information density: high performance at low context size Cost efficiency: Seguridade: controlar e etiquetar o que ve o modelo Resiliencia de erros: sinalización explícita de casos de bordo, problemas coñecidos ou instrucións de retroceso Prompting is only half the battle. is the other half. And if you’re not doing it yet, you will be once your agent grows up. Bottom line: Context engineering 12 - Engadir capas de seguridade Even with solid prompts, memory, and control flow, an agent can still go off the rails. Think of this principle as an insurance policy against the worst-case scenarios: Inxección rápida: os usuarios (ou outros sistemas) escorregan nas instrucións que secuestran o axente. Fugas de datos sensibles: o modelo desvía PII ou segredos corporativos. unwanted hate speech, spam, or disallowed material. Toxic or malicious content: confident but false answers. Hallucinations: Accións fóra do alcance: o axente "está creativo" e fai algo que nunca debería facer. No single fix covers all of that. You need : múltiples salvagardas que capturan problemas en cada etapa do ciclo de solicitude/resposta. defense-in-depth Quick Checklist is in place (jailbreak phrases, intent check). User input validation For factual tasks, answers . must reference RAG context The prompt explicitly tells the model to stick to retrieved facts. O filtro de saída bloquea PII ou contido non permitido. Responses include a citation/link to the source. Agent and tools follow the . least privilege Critical actions route through approval or monitoring. HITL Tratar estas capas como DevOps estándar: rexístralos, probalos e fallar de forma segura. Part 4 - Keep it Working Under Load In production, failures rarely happen all at once, and often you don’t notice them right away, sometimes not at all. Esta sección céntrase en construír a disciplina de enxeñaría para supervisar continuamente o seu axente, asegurando que todo funcione sen problemas. . Desde os rexistros e o seguimento ata as probas automatizadas, estas prácticas fan que o comportamento do seu axente sexa claro e fiable, xa sexa que estea a observar activamente ou se concentre en construír o próximo avance. 13 - Trace o camiño da execución completa : Os axentes inevitablemente comportaranse mal durante o desenvolvemento, actualizacións ou mesmo operacións normais. Debugando estes problemas pode consumir innumerables horas intentando reproducir erros e identificar fallos. Se xa implementou principios clave como manter o estado fóra e comprimir erros no contexto, está por diante. Problem Log toda a viaxe desde a solicitude do usuario a través de cada paso do proceso de decisión e acción do axente. logs de compoñentes individuais non son suficientes; precisa de rastrexo de extremo a extremo que cubra cada detalle. Solution : Why this matters Debugging: Identificar rapidamente onde e por que as cousas foron mal. : Spot bottlenecks and improvement opportunities. Analytics Avaliación da calidade: medir como os cambios afectan o comportamento. Reproducibilidade: Recrear calquera sesión con precisión. Auditoría: Manter un rexistro completo das decisións e accións do axente. Minimum data to capture Entrada: solicitude de usuario e parámetros de pasos anteriores. Estado do axente: variables clave antes de cada paso. Prompt: Prompt completo enviado ao LLM (instrucións do sistema, historia, contexto). : Raw response before processing. LLM output : Tool name and parameters invoked. Tool call : Tool output or error. Tool result Decisión do axente: Seguinte pasos ou respostas escollidas. : Timing, model info, costs, code, and prompt versions. Metadata Utilice as ferramentas de seguimento existentes onde sexa posible: LangSmith, Arize, Weights & Biases, OpenTelemetry, etc. Pero primeiro, asegúrese de que ten cubertas as bases (ver Principio 15). : Checklist Todos os pasos rexistrados con todo o detalle. Os rexistros están vinculados por sesión_id e un paso_id. Interface para revisar cadeas de chamadas completas. Capacidade de reproducir completamente calquera prompt en calquera momento. 14 — Test Every Change : De momento, o seu axente pode sentirse listo para o lanzamento: funciona, quizais mesmo exactamente como quería. Pero como pode estar seguro de que seguirá funcionando despois das actualizacións? Cambios en código, conxuntos de datos, modelos de base ou prompts poden romper silenciosamente a lóxica existente ou degradar o rendemento. Problem Drift de modelo: o rendemento diminúe ao longo do tempo sen cambios de código debido a cambios de modelo ou datos Prompt fragilidade: pequenos axustes prompt poden causar grandes cambios de saída : LLMs often give different answers to the same input, complicating exact-match tests Non-determinism Erros difíciles de reproducir: mesmo con entradas fixas, os erros poden ser difíciles de rastrexar O efecto bolboreta: cambios de cascada imprevisiblemente entre sistemas and other LLM-specific risks Hallucinations Adoptar unha estratexia de probas exhaustiva e multicapa que combine probas de software clásicas con controis de calidade centrados no LLM: Solution Probas de varios niveis: probas de unidades para funcións/prompts, probas de integración e escenarios completos de fin a fin Foco na calidade da saída LLM: relevancia, coherencia, precisión, estilo e seguridade Use conxuntos de datos dourados con saídas esperadas ou intervalos de resultados aceptables para comprobacións de regresión Automatizar as probas e integralas en tubaxes CI/CD Involucrar ás persoas para avaliacións críticas ou complexas (human-in-the-loop) Iterativamente probar e refinar os prompts antes da implantación Proba en diferentes niveis: compoñentes, prompts, cadeas / axentes e fluxos de traballo completos : Checklist A lóxica é modular e probada por separado e en combinación. A calidade da produción é avaliada con base nos datos de referencia As probas cobren casos comúns, casos de borda, fallos e entradas maliciosas Resistencia ás entradas ruidosas ou adversarias Todos os cambios pasan por probas automatizadas e son monitorizados na produción para detectar regresións non detectadas 15 - O seu conxunto enteiro Este principio vincula todo, é unha meta-regra que pasa por todos os outros. Hoxe, hai innumerables ferramentas e marcos para xestionar case calquera tarefa, o que é excelente para a velocidade e a facilidade de prototipos - pero tamén é unha trampa. Isto é especialmente importante no desenvolvemento de axentes, onde ten que xestionar: A imprevisibilidade inherente dos LLM Lóxica complexa en torno ás transicións e á auto-corrección A necesidade de que o seu sistema se adapte e evolucione sen reescribir as tarefas principais Isto pode acelerar o prototipo, pero fai que o desenvolvemento a longo prazo sexa máis difícil de xestionar e personalizar. Frameworks often invert control Many principles you’ve seen can be implemented with off-the-shelf tools. But sometimes, building the core logic explicitly takes similar effort and gives you far better transparency, control, and adaptability. Por outra banda, ir totalmente personalizado e reescribir todo desde cero é sobre-enxeñaría, e igualmente arriscado. A clave é Como enxeñeiro, decides conscientemente cando confiar en marcos e cando tomar o control completo, entendendo plenamente os compromisos implicados. balance Moitas ferramentas actuais foron construídas antes de que os estándares se solidificasen.Pode que se volvan obsoletas mañá - pero as opcións arquitectónicas que fas agora permanecerán moito máis tempo. Remember Conclusión Construír un axente de LLM non é só chamar APIs máis. Trátase de deseñar un sistema que poida xestionar o caos do mundo real: erros, estados, límites de contexto, entradas inesperadas e requisitos en evolución. The 15 principles we covered aren’t theory, they’re battle-tested lessons from the trenches. They’ll help you turn fragile scripts into stable, scalable, and maintainable agents that don’t break the moment real users show up. Cada principio merece unha consideración para ver se se encaixa no teu proxecto. Ao final, é o teu proxecto, os teus obxectivos e a túa creación. Pero lembra: o LLM é poderoso, pero é só unha parte dun sistema complexo. If you take away one thing, let it be this: Porque esa é a única forma de pasar de “wow, respondeu!” a “si, segue a funcionar”. slow down, build solid foundations, and plan for the long hau Sigue iterando, probando e aprendendo.E non esquezas, os humanos no ciclo non son un retroceso, manteñen o teu axente baseado e eficaz. This isn’t the end. It’s just the start of building agents that actually deliver. Struggling to grow your audience as a Tech Professional? The Tech Audience Accelerator is the go-to newsletter for tech creators serious about growing their audience. You’ll get the proven frameworks, templates, and tactics behind my 30M+ impressions (and counting). https://techaudienceaccelerator.substack.com/embed?source=post_page-----e58139d80299---------------------------------------&embedable=true