santismm-knowledge
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SANTISMM_CONTENT_DIR | No | Directory containing the content corpus. Defaults to 'content/'. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_author_profileA | Get the author's professional profile as structured facts: name and the other forms it takes, current role with its start date, previous organisations, the frameworks he is the author of with their canonical URLs, how to cite this work, the licence, and the date these facts were last verified. Use this to attribute or cite anything this server returns. A |
| get_overviewA | Get the complete MCP map — start here. Returns the five-domain core plus the separate Article, Labs, Homeric Atlas, claim-registry, AI-benchmark and Physical AI surfaces, with their tools, identifiers, citation rules, languages, licence and bulk-ingest URLs. Federated surfaces that publish a dataset version report it and their live counts. |
| search_allA | Search the core corpus, first-party essays, executable Labs, epistemic claims, the Homeric Atlas, the AI benchmarks (professions and benchmark catalogue) and Physical AI (robot platforms, documented deployments, deployment guide) in one call. Use this first when a natural-language question might require a calculation, a long-form essay, a claim audit or a model choice rather than only a core knowledge unit. Results name the next tool to call; calculator-shaped questions are routed toward Labs, 'which AI model for…' questions toward the benchmarks, and robotics questions toward Physical AI. |
| list_knowledgeA | List all knowledge units (concepts on agentic & enterprise AI) with slug, category, title, summary and Evidence-First provenance. Use this to browse the domain; use |
| get_knowledgeA | Get one knowledge unit by slug. Returns the full entry, or a single-locale body if locale is given. Use this once |
| list_patternsA | List all Enterprise AI patterns (reusable agentic design patterns) with slug, category, name, summary and provenance. Use this to browse the catalogue; use |
| get_patternA | Get one Enterprise AI pattern by slug (includes problem, solution, KPIs, failure modes, lessons). Use this once |
| list_architecturesA | List all reference architectures (end-to-end enterprise agentic blueprints) with id, slug, category, name, summary and provenance. Use this to browse the blueprints; use |
| get_architectureA | Get one reference architecture by slug (includes the request flow, reference scenario, KPIs, cost & scaling, and the patterns/knowledge it composes). Use this once |
| list_governanceA | List all AI governance units (regulations, standards, frameworks, playbooks — EU AI Act, ISO 42001, NIST AI RMF, agentic checklist) with id, slug, category, name and summary. Use this to browse the regulations and standards; use |
| get_governanceA | Get one AI governance unit by slug (includes scope, key requirements, implementable controls, a checklist and common pitfalls). Use this once |
| list_handbookA | List the Harness Engineering Handbook chapters (HRN-001…): the canonical long-form corpus on harness engineering — definition, history, taxonomy, principles, memory, observability, evaluation, governance, planning, orchestration, security, case studies, glossary and bibliography. Use this to see the chapter map; use |
| get_handbookA | Get one Harness Engineering Handbook chapter, by id (e.g. 'HRN-001') or slug. Returns the full Markdown body plus its provenance and related ids. Use this once |
| searchA | Ranked keyword search across the whole corpus (knowledge, patterns, architectures, governance and the handbook). Matches every language and ignores accents, so query in the user's own words. Each hit carries a relevance score and the fields it matched; follow up with the matching get_* tool for full detail. Use this before any |
| list_articlesA | List every long-form essay published on articles.santismm.com, with language, dates, topics and citable canonical URLs. Use this to browse the essay catalogue; use |
| get_articleA | Get one complete essay by slug, including its clean Markdown-like body, metadata, licence context and canonical URL. Use this after |
| search_articlesA | Ranked, accent-insensitive full-text search over every first-party essay, including titles, summaries, topics and bodies. Use this when you need long-form analysis about a topic; follow with |
| list_professionsA | List the professions that have a ranking of frontier AI models built from independent benchmark results (lawyer, accountant, developer, salesperson, translator, engineer…), each marked as a direct or an indirect evaluation, with the model that ranks first today. Use this to find the profession id; then call |
| recommend_model_for_professionA | Get the ranking of frontier AI models for one profession: the best result, the runner-up, the best value and the best open-weights model, the full table with data coverage and price, which tasks each benchmark measures and which tasks no benchmark measures yet. Use this when someone asks which AI model to use for their job, after |
| compare_modelsA | Put two or more frontier models side by side on the benchmark results recorded for them (score, unit, source table and evidence grade per benchmark), optionally with their rows in one profession's ranking. Use this when the user is choosing between specific models; use |
| list_benchmarksA | List every benchmark in the AI Agent Benchmarks catalogue (agentic benchmarks with SOTA, saturation and headroom) and in the radar's complementary list (vision, long context, factuality, instruction following, language). Use this to find a benchmark slug; then call |
| get_benchmarkA | Get one benchmark by slug or name: what it measures, state of the art, saturation, headroom, human baseline, source and notes, the radar axis it informs, the model scores recorded on it, and which profession rankings use it. Use this after |
| list_labsA | List every SANTISMM Lab with its inputs, outputs, assumptions, formulas and citation URL. Use this to discover interactive and machine-readable tools; filter by kind when the user specifically asks for a calculator, converter, experiment or educational game. |
| get_labA | Get one Lab by slug, including formulas, assumptions, related SANTISMM content and its executable endpoint when one exists. Use this after list_labs or search_all; use the named calculate_* tool rather than reimplementing a published formula. |
| calculate_agent_economicsA | Calculate monthly operating cost, cost per verified outcome, manual baseline, savings, ROI and break-even success rate from explicit assumptions. Use this for an agent business case or scenario comparison; keep every monetary input in the same currency and cite the returned canonical_url. |
| calculate_evaluation_sample_sizeA | Calculate two different samples: how many independent evaluations are needed to detect at least one failure, and how many are needed to estimate its rate at a chosen margin. Use this when a user asks how many tests are enough; do not interpret zero observed failures as proof of zero risk. |
| calculate_human_supervision_capacityA | Calculate review and escalation workload, required FTE, available headroom or backlog, monthly labour cost and sustainable case volume. Use this before production rollout to test whether the stated human-oversight model is operationally credible; the result uses averages and is not a queueing simulation. |
| search_physical_aiA | Search the Physical AI dataset — real robot platforms (humanoids, quadrupeds, mobile manipulators, UGVs, drones), documented deployments with sources, the enterprise deployment guide, the autonomy taxonomy and the evidence methodology. Filter by type and taxonomy ids. Each result carries its evidence level, the sources behind it and what is NOT published (limitations); cite canonical_url. Use this for any question about robots, robotic platforms or real robotics deployments; use search_all when the question may also concern the rest of the corpus. |
| get_physical_ai_itemA | Read one record by type and slug: a platform sheet (specs with test conditions, provenance and sources, autonomy by task, evidence stage, access, lifecycle), a documented case study (sourced facts, published KPIs, lessons), a guide, a cited source, or the taxonomy and methodology (no slug). A spec or KPI the maker has not published is null with status 'unpublished' — report it as unknown, never estimate it. Use this after search_physical_ai, with the type and slug it returned. |
| compare_physical_ai_platformsA | Compare 2–5 platforms side by side on published fields only — payload, runtime, weight, speed, IP rating, temperature range, price, autonomy, coordination, control, perception, environments, sectors, evidence stage, access and lifecycle. Every cell says whether the value is published, unpublished or an editorial estimate, who stated it (manufacturer, press) and under what test conditions. There is no ranking or winner: present it as a table of facts and say which values are unknown. Use this when the user is choosing between named platforms. |
| calculate_physical_ai_roiA | Run the Physical AI calculator's own 36-month model: manual vs robotic TCO, annual savings, upfront investment, payback month, ROI, coverage, supervision and incidents, plus payback sensitivity to hourly cost, capex, coverage, integration, maintenance and uptime. Every input is optional; use_case applies a published preset first. The response lists the assumptions with their evidence level and the fields_to_validate that are still editorial defaults — tell the user to replace them. Orientative, undiscounted, single currency; not a quote. Use this for the cost, savings or payback of a robot fleet; for an AI-agent business case use calculate_agent_economics. |
| assess_physical_ai_fitA | Run the deployment guide's readiness assessment: score per area and overall, the band and its guidance, the weakest area, blockers (items answered 'no') and the questions still unanswered, plus the platforms and documented deployments that match the environment, sector and family, ordered by strength of evidence. Call with no answers first to receive every question. It never recommends a purchase; it shows what is ready, what is missing and what evidence exists. Use this when an organisation asks whether it is ready to deploy robots. |
| get_relatedA | Traverse the knowledge graph: given a unit, return its neighbours — the units it links to (outgoing) and the units that reference it (incoming), each with the relationship type. Use this after a |
| list_homeric_placesA | List every place in the Homeric Atlas with its identification class, its confidence score and how many competing identifications it carries. Use this to browse the atlas; use |
| get_homeric_placeA | Get one place by slug: every identification proposed for it, each with its own coordinates, class, 0-12 rubric and sources, plus the attested passages. Use this when you need to weigh the evidence for a location, or to cite it; a place the poem does not locate carries no coordinates at all. |
| list_homeric_episodesA | List every episode of the Iliad and the Odyssey held in the atlas, in reading order, with its passage, the places it involves and how firmly it can be located. Use this to find the episode you want; use |
| get_homeric_episodeA | Get one episode by slug: the passage, the narrative, the competing theories about where it happened (each with its proponent and sources), the confidence rubric and the FAQs. Use this when the question is where an episode took place and who argued for it. |
| list_homeric_routesA | List the reconstructed itineraries (the nostos of Odysseus and the others), each with its rival reconstructions scored separately. Use this to see which voyages the atlas reconstructs before fetching one. |
| get_homeric_routeA | Get one route by slug: each reconstruction variant with its ordered stops, the hypothesis chosen at each stop, its confidence rubric and its sources. Use this to compare rival reconstructions of a voyage: they are returned side by side rather than merged. |
| list_claimsA | List the load-bearing claims of the corpus, each tagged as observed_fact, industry_synthesis, santismm_thesis or strategic_hypothesis, with its confidence and the units it underpins. Use this before quoting the handbook to know whether a statement is evidence, a reading of the industry, or a position taken. Filter by |
| get_claimA | Get one claim by id (HE-CLAIM-001) or slug: the statement, what it rests on, its structured sources, and — always present — what it does NOT establish and the observation that would retire it. Use this to cite the corpus honestly, or to check whether a result you have just measured confirms or falsifies a claim it makes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| locate_in_corpus | Find which surface holds a concept before fetching it. Searches every surface first, so a slug that lives in one domain is not requested from another. |
| locate_handbook_chapter | Hands over the real chapter identifiers and their titles, so a chapter is requested by an id that exists rather than one inferred by analogy. |
| cite_with_provenance | Produce a citation that carries the canonical URL, the Evidence-First block and — when the statement is load-bearing — the epistemic level and retraction condition of the claim behind it. |
| evaluate_physical_ai_opportunity | Walk from an operational problem to an evidence-backed assessment: matching platforms and documented deployments, the readiness assessment, and the host's own ROI/TCO model — with every assumption and unknown stated. It assembles public, deterministic results; it is not a priced business case. |
| compare_physical_ai_options | Shortlist platforms for a need and compare them as a table of published facts — with provenance, test conditions and the values nobody has published — instead of a generated opinion. |
| design_physical_ai_pilot | Draft a pilot plan — scope, operational design domain, KPIs, success criteria and exit conditions — grounded in the deployment guide and in the lessons of documented deployments, with each borrowed point cited. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| corpus-overview | Read the corpus map, licences, languages, extensions and bulk-ingest URLs. |
| author-profile | Read the author's professional facts: name and its other forms, current role with its start date, previous organisations, the frameworks he authored, how to cite, licence, and when these facts were last verified. |
| knowledge/agent-memory@en | Agent memory is how an AI agent retains and recalls information beyond a single context window — across steps, sessions and tasks. It typically separates short-term working memory (the current context) from long-term memory (durable stores the agent reads from and writes to). Mem |
| knowledge/agentic-ai@en | Agentic AI refers to systems that pursue goals over multiple steps — planning, calling tools, acting on an environment and reacting to feedback — instead of producing a single response. It turns a language model from a text generator into an actor that can complete tasks. The shi |
| knowledge/agentic-evaluation@en | Agentic AI evaluation is the practice of measuring how well an agent completes multi-step, tool-using tasks in an environment — not just the quality of a single answer. As models saturate static knowledge benchmarks, evaluation is shifting from measuring capability (what a model |
| knowledge/agentic-threat-model@en | An agentic threat model is the map of how an autonomous agent can be attacked: not through its weights, but through everything it reads, remembers, calls and is allowed to do. It names the surfaces — direct and indirect prompt injection, tool poisoning, excessive agency, memory p |
| knowledge/ai-agent@en | An AI agent is a system that combines a model with tools, memory and a control loop to take actions toward a goal, rather than just answering a single prompt. It perceives a situation, decides what to do, acts through tools, observes the result and repeats until done. Autonomy ra |
| knowledge/ai-cyberdefense@en | AI cyberdefense is the practice of protecting AI systems — models, agents, the tools they call and the data they reach — from attacks that exploit how those systems reason and act. For agents it is not a layer added afterwards: the controls that stop an attack are the same harnes |
| knowledge/ai-governance@en | AI governance is the set of policies, processes, roles and controls that ensure AI is built and used responsibly, legally and safely. It spans risk management, accountability, transparency, security and compliance across the AI lifecycle. In practice it operationalizes recognized |
| knowledge/ai-observability@en | AI observability is the practice of instrumenting AI systems — especially agents — so you can see what they did and why. It captures traces of each step: prompts, tool calls, retrieved context, model outputs, tokens, latency and cost. Because agents are non-deterministic and mult |
| knowledge/context-engineering@en | Context engineering is the discipline of deciding what information enters a model's limited context window at each step — and what stays out. As agents run over many steps, naively stuffing everything into context degrades quality and cost. Context engineering curates the right i |
| knowledge/embeddings@en | An embedding is a numeric vector that represents the meaning of text (or images, audio, code) so that semantically similar items sit close together in vector space. Vector search finds the nearest embeddings to a query, enabling search by meaning rather than keywords. Embeddings |
| knowledge/enterprise-rag@en | Enterprise RAG (retrieval-augmented generation) is the pattern of grounding a model's answers in an organization's own documents, retrieved at query time, instead of relying on the model's parametric memory. It lets a company use private, current and governed knowledge — policies |
| knowledge/fine-tuning@en | Fine-tuning continues training a pretrained model on a smaller, targeted dataset to specialize its behavior, style or domain knowledge. It is far cheaper than pretraining and changes the model's weights — unlike prompting or retrieval, which leave the model unchanged. Use it to l |
| knowledge/foundation-models@en | A foundation model is a large model pretrained on broad data at scale that can be adapted to a wide range of downstream tasks. Large language models (LLMs) and large multimodal models are the canonical examples. The term, coined at Stanford in 2021, captures a shift: instead of t |
| knowledge/guardrails@en | Guardrails are runtime controls that constrain what goes into and comes out of an AI system, keeping its behavior safe, on-policy and compliant. They check and filter inputs and outputs, validate tool actions, block disallowed content and enforce limits — sitting around the model |
| knowledge/harness-engineering@en | Harness engineering is the emerging discipline of designing and optimizing the scaffolding around an AI model — the prompts, tools, memory, environment, control loop and guardrails — so the model performs reliably on real tasks. Its core premise: as base models converge in raw ca |
| knowledge/human-in-the-loop@en | Human-in-the-loop (HITL) is a design pattern where a person reviews, approves or corrects an AI system's output before it takes effect — especially for high-impact actions. Instead of full autonomy, the agent proposes and a human disposes. It is a primary control for managing ris |
| knowledge/mcp-security@en | MCP security is what stops a Model Context Protocol server from becoming the easiest way into a system. The protocol standardises how agents discover and call tools; it does not decide who may call them, what they may reach, or what happens when a tool description turns hostile. |
| knowledge/model-context-protocol@en | The Model Context Protocol (MCP) is an open standard for connecting AI models and agents to external tools, data sources and systems through a single, uniform interface. Introduced by Anthropic in late 2024, it standardizes how an application exposes context and capabilities to a |
| knowledge/multi-agent-architecture@en | A multi-agent architecture divides a task among several specialized agents that collaborate, delegate or compete to reach a goal, instead of relying on one general agent. Common shapes include an orchestrator that delegates to workers, pipelines where each agent owns a stage, and |
| knowledge/prompt-engineering@en | Prompt engineering is the practice of designing the inputs given to a language model so it produces the desired output reliably. A good prompt specifies the role, the task, the constraints, the output format and, when useful, examples. It is the most accessible lever for steering |
| knowledge/prompt-injection@en | Prompt injection is an attack in which malicious instructions hidden in the input to a language model hijack its behavior — making it ignore its rules, leak data or misuse tools. It tops the OWASP Top 10 for LLM applications. The root cause is that models cannot reliably separate |
| knowledge/reasoning-models@en | Reasoning models are language models trained to spend extra computation 'thinking' before they answer — generating internal reasoning steps to solve harder problems in math, code and logic. They trade latency and cost for accuracy on complex, multi-step tasks. The key idea is tes |
| knowledge/recursive-self-improvement@en | Recursive self-improvement is the idea of a system that improves its own ability to improve — each round of self-modification making the next one more effective, so that gains compound. Narrow pieces of that loop are real and measured today: a model that refines its own answer, g |
| knowledge/tool-use@en | Tool use, also called function calling, lets a language model invoke external functions, APIs or code to fetch information or take actions in the real world. The model decides which tool to call and with what arguments; the application runs the tool and returns the result, which |
| knowledge/agent-memory@es | La memoria de un agente es cómo un agente de IA retiene y recuerda información más allá de una sola ventana de contexto: entre pasos, sesiones y tareas. Suele separar la memoria de trabajo a corto plazo (el contexto actual) de la memoria a largo plazo (almacenes duraderos que el |
| knowledge/agentic-ai@es | La IA agéntica designa sistemas que persiguen objetivos en varios pasos —planifican, llaman a herramientas, actúan sobre un entorno y reaccionan al feedback— en lugar de producir una única respuesta. Convierte a un modelo de lenguaje de generador de texto en un actor capaz de com |
| knowledge/agentic-evaluation@es | La evaluación de IA agéntica es la práctica de medir cómo de bien un agente completa tareas de varios pasos con uso de herramientas en un entorno, no solo la calidad de una única respuesta. A medida que los modelos saturan los benchmarks estáticos de conocimiento, la evaluación s |
| knowledge/agentic-threat-model@es | Un modelo de amenazas agéntico es el mapa de cómo se puede atacar a un agente autónomo: no a través de sus pesos, sino de todo lo que lee, recuerda, invoca y tiene permitido hacer. Nombra las superficies —inyección de prompts directa e indirecta, envenenamiento de herramientas, e |
| knowledge/ai-agent@es | Un agente de IA es un sistema que combina un modelo con herramientas, memoria y un bucle de control para tomar acciones hacia un objetivo, en lugar de solo responder a un prompt. Percibe una situación, decide qué hacer, actúa mediante herramientas, observa el resultado y repite h |
| knowledge/ai-cyberdefense@es | La ciberdefensa de la IA es la práctica de proteger sistemas de IA —modelos, agentes, las herramientas que invocan y los datos que alcanzan— frente a ataques que explotan cómo esos sistemas razonan y actúan. En agentes no es una capa que se añade después: los controles que detien |
| knowledge/ai-governance@es | La gobernanza de la IA es el conjunto de políticas, procesos, roles y controles que garantizan que la IA se construya y use de forma responsable, legal y segura. Abarca gestión de riesgos, rendición de cuentas, transparencia, seguridad y cumplimiento a lo largo del ciclo de vida |
| knowledge/ai-observability@es | La observabilidad de IA es la práctica de instrumentar sistemas de IA —sobre todo agentes— para poder ver qué hicieron y por qué. Captura trazas de cada paso: prompts, llamadas a herramientas, contexto recuperado, salidas del modelo, tokens, latencia y coste. Como los agentes son |
| knowledge/context-engineering@es | La ingeniería de contexto es la disciplina de decidir qué información entra en la ventana de contexto limitada de un modelo en cada paso, y qué se queda fuera. Como los agentes se ejecutan en muchos pasos, meter todo ingenuamente en el contexto degrada calidad y coste. La ingenie |
| knowledge/embeddings@es | Un embedding es un vector numérico que representa el significado de un texto (o imágenes, audio, código) de modo que los elementos semánticamente similares quedan cerca en el espacio vectorial. La búsqueda vectorial encuentra los embeddings más cercanos a una consulta, permitiend |
| knowledge/enterprise-rag@es | El RAG empresarial (generación aumentada por recuperación) es el patrón de fundamentar las respuestas de un modelo en los propios documentos de la organización, recuperados en el momento de la consulta, en lugar de depender de la memoria paramétrica del modelo. Permite usar conoc |
| knowledge/fine-tuning@es | El fine-tuning continúa el entrenamiento de un modelo preentrenado con un conjunto de datos más pequeño y dirigido para especializar su comportamiento, estilo o conocimiento de dominio. Es mucho más barato que el preentrenamiento y cambia los pesos del modelo, a diferencia del pr |
| knowledge/foundation-models@es | Un modelo fundacional es un modelo grande preentrenado a escala con datos amplios que puede adaptarse a una gran variedad de tareas posteriores. Los modelos de lenguaje (LLM) y los multimodales son los ejemplos canónicos. El término, acuñado en Stanford en 2021, captura un cambio |
| knowledge/guardrails@es | Los guardarraíles son controles en tiempo de ejecución que acotan lo que entra y sale de un sistema de IA, manteniendo su comportamiento seguro, conforme a la política y al cumplimiento. Comprueban y filtran entradas y salidas, validan acciones de herramientas, bloquean contenido |
| knowledge/harness-engineering@es | La ingeniería de harness es la disciplina emergente de diseñar y optimizar el andamiaje alrededor de un modelo de IA —prompts, herramientas, memoria, entorno, bucle de control y guardarraíles— para que el modelo rinda de forma fiable en tareas reales. Su premisa central: a medida |
| knowledge/human-in-the-loop@es | Human-in-the-loop (HITL) es un patrón de diseño en el que una persona revisa, aprueba o corrige la salida de un sistema de IA antes de que surta efecto, sobre todo en acciones de alto impacto. En lugar de autonomía total, el agente propone y un humano dispone. Es un control prima |
| knowledge/mcp-security@es | La seguridad en MCP es lo que impide que un servidor de Model Context Protocol se convierta en la vía más fácil de entrar a un sistema. El protocolo estandariza cómo los agentes descubren e invocan herramientas; no decide quién puede invocarlas, a qué pueden llegar ni qué pasa cu |
| knowledge/model-context-protocol@es | El Model Context Protocol (MCP) es un estándar abierto para conectar modelos y agentes de IA con herramientas, fuentes de datos y sistemas externos a través de una interfaz única y uniforme. Presentado por Anthropic a finales de 2024, estandariza cómo una aplicación expone contex |
| knowledge/multi-agent-architecture@es | Una arquitectura multiagente divide una tarea entre varios agentes especializados que colaboran, delegan o compiten para alcanzar un objetivo, en lugar de depender de un único agente general. Formas habituales: un orquestador que delega en trabajadores, pipelines donde cada agent |
| knowledge/prompt-engineering@es | La ingeniería de prompts es la práctica de diseñar las entradas que se dan a un modelo de lenguaje para que produzca la salida deseada de forma fiable. Un buen prompt especifica el rol, la tarea, las restricciones, el formato de salida y, cuando conviene, ejemplos. Es la palanca |
| knowledge/prompt-injection@es | La inyección de prompts es un ataque en el que instrucciones maliciosas ocultas en la entrada a un modelo de lenguaje secuestran su comportamiento, haciéndole ignorar sus reglas, filtrar datos o usar mal las herramientas. Encabeza el OWASP Top 10 para aplicaciones LLM. La causa r |
| knowledge/reasoning-models@es | Los modelos de razonamiento son modelos de lenguaje entrenados para gastar cómputo extra 'pensando' antes de responder, generando pasos de razonamiento internos para resolver problemas más difíciles de matemáticas, código y lógica. Cambian latencia y coste por precisión en tareas |
| knowledge/recursive-self-improvement@es | La auto-mejora recursiva es la idea de un sistema que mejora su propia capacidad de mejorar: cada ronda de automodificación hace más eficaz la siguiente, de modo que las ganancias se acumulan. Partes estrechas de ese bucle son reales y están medidas hoy — un modelo que refina su |
| knowledge/tool-use@es | El uso de herramientas, también llamado function calling, permite a un modelo de lenguaje invocar funciones, APIs o código externos para obtener información o tomar acciones en el mundo real. El modelo decide qué herramienta llamar y con qué argumentos; la aplicación ejecuta la h |
| knowledge/agent-memory@pt | A memória de um agente é como um agente de IA retém e recupera informação além de uma única janela de contexto: entre passos, sessões e tarefas. Costuma separar a memória de trabalho de curto prazo (o contexto atual) da memória de longo prazo (armazenamentos duráveis que o agente |
| knowledge/agentic-ai@pt | A IA agêntica designa sistemas que perseguem objetivos em vários passos — planejam, chamam ferramentas, agem sobre um ambiente e reagem ao feedback — em vez de produzir uma única resposta. Transforma um modelo de linguagem de gerador de texto em um ator capaz de concluir tarefas. |
| knowledge/agentic-evaluation@pt | A avaliação de IA agêntica é a prática de medir quão bem um agente conclui tarefas de vários passos com uso de ferramentas num ambiente, não só a qualidade de uma única resposta. À medida que os modelos saturam os benchmarks estáticos de conhecimento, a avaliação se desloca de me |
| knowledge/agentic-threat-model@pt | Um modelo de ameaças agêntico é o mapa de como um agente autônomo pode ser atacado: não pelos seus pesos, mas por tudo o que ele lê, memoriza, invoca e tem permissão para fazer. Ele nomeia as superfícies — injeção de prompts direta e indireta, envenenamento de ferramentas, excess |
| knowledge/ai-agent@pt | Um agente de IA é um sistema que combina um modelo com ferramentas, memória e um laço de controle para tomar ações rumo a um objetivo, em vez de só responder a um prompt. Ele percebe uma situação, decide o que fazer, age por meio de ferramentas, observa o resultado e repete até c |
| knowledge/ai-cyberdefense@pt | A ciberdefesa de IA é a prática de proteger sistemas de IA — modelos, agentes, as ferramentas que eles chamam e os dados que alcançam — contra ataques que exploram como esses sistemas raciocinam e agem. Em agentes não é uma camada adicionada depois: os controles que detêm um ataq |
| knowledge/ai-governance@pt | A governança de IA é o conjunto de políticas, processos, papéis e controles que garantem que a IA seja construída e usada de forma responsável, legal e segura. Abrange gestão de riscos, prestação de contas, transparência, segurança e conformidade ao longo do ciclo de vida da IA. |
| knowledge/ai-observability@pt | A observabilidade de IA é a prática de instrumentar sistemas de IA — sobretudo agentes — para poder ver o que fizeram e por quê. Captura rastros de cada passo: prompts, chamadas de ferramentas, contexto recuperado, saídas do modelo, tokens, latência e custo. Como os agentes são n |
| knowledge/context-engineering@pt | A engenharia de contexto é a disciplina de decidir qual informação entra na janela de contexto limitada de um modelo a cada passo, e o que fica de fora. Como os agentes rodam em muitos passos, enfiar tudo ingenuamente no contexto degrada qualidade e custo. A engenharia de context |
| knowledge/embeddings@pt | Um embedding é um vetor numérico que representa o significado de um texto (ou imagens, áudio, código) de modo que itens semanticamente similares ficam próximos no espaço vetorial. A busca vetorial encontra os embeddings mais próximos de uma consulta, permitindo buscar por signifi |
| knowledge/enterprise-rag@pt | O RAG empresarial (geração aumentada por recuperação) é o padrão de fundamentar as respostas de um modelo nos próprios documentos da organização, recuperados no momento da consulta, em vez de depender da memória paramétrica do modelo. Permite usar conhecimento privado, atual e go |
| knowledge/fine-tuning@pt | O fine-tuning continua o treinamento de um modelo pré-treinado com um conjunto de dados menor e direcionado para especializar seu comportamento, estilo ou conhecimento de domínio. É muito mais barato que o pré-treinamento e muda os pesos do modelo, ao contrário do prompting ou da |
| knowledge/foundation-models@pt | Um modelo de fundação é um modelo grande pré-treinado em escala com dados amplos que pode ser adaptado a uma ampla variedade de tarefas posteriores. Os modelos de linguagem (LLMs) e os multimodais são os exemplos canônicos. O termo, cunhado em Stanford em 2021, captura uma mudanç |
| knowledge/guardrails@pt | Os guard-rails são controles em tempo de execução que limitam o que entra e sai de um sistema de IA, mantendo seu comportamento seguro, em conformidade com a política e a regulação. Verificam e filtram entradas e saídas, validam ações de ferramentas, bloqueiam conteúdo não permit |
| knowledge/harness-engineering@pt | A engenharia de harness é a disciplina emergente de projetar e otimizar o andaime ao redor de um modelo de IA — prompts, ferramentas, memória, ambiente, laço de controle e guard-rails — para que o modelo tenha desempenho confiável em tarefas reais. Sua premissa central: à medida |
| knowledge/human-in-the-loop@pt | Human-in-the-loop (HITL) é um padrão de design em que uma pessoa revisa, aprova ou corrige a saída de um sistema de IA antes de surtir efeito, sobretudo em ações de alto impacto. Em vez de autonomia total, o agente propõe e um humano dispõe. É um controle primário para gerir o ri |
| knowledge/mcp-security@pt | Segurança em MCP é o que impede que um servidor de Model Context Protocol se torne o caminho mais fácil para dentro de um sistema. O protocolo padroniza como agentes descobrem e invocam ferramentas; ele não decide quem pode invocá-las, o que elas alcançam, nem o que acontece quan |
| knowledge/model-context-protocol@pt | O Model Context Protocol (MCP) é um padrão aberto para conectar modelos e agentes de IA a ferramentas, fontes de dados e sistemas externos por meio de uma interface única e uniforme. Apresentado pela Anthropic no fim de 2024, padroniza como uma aplicação expõe contexto e capacida |
| knowledge/multi-agent-architecture@pt | Uma arquitetura multiagente divide uma tarefa entre vários agentes especializados que colaboram, delegam ou competem para alcançar um objetivo, em vez de depender de um único agente geral. Formas comuns: um orquestrador que delega a trabalhadores, pipelines em que cada agente pos |
| knowledge/prompt-engineering@pt | A engenharia de prompts é a prática de projetar as entradas dadas a um modelo de linguagem para que ele produza a saída desejada de forma confiável. Um bom prompt especifica o papel, a tarefa, as restrições, o formato de saída e, quando útil, exemplos. É a alavanca mais acessível |
| knowledge/prompt-injection@pt | A injeção de prompts é um ataque em que instruções maliciosas escondidas na entrada de um modelo de linguagem sequestram seu comportamento, fazendo-o ignorar suas regras, vazar dados ou usar mal as ferramentas. Lidera o OWASP Top 10 para aplicações LLM. A causa raiz é que os mode |
| knowledge/reasoning-models@pt | Os modelos de raciocínio são modelos de linguagem treinados para gastar computação extra 'pensando' antes de responder, gerando passos de raciocínio internos para resolver problemas mais difíceis de matemática, código e lógica. Trocam latência e custo por precisão em tarefas comp |
| knowledge/recursive-self-improvement@pt | Auto-aperfeiçoamento recursivo é a ideia de um sistema que melhora a sua própria capacidade de melhorar: cada rodada de automodificação torna a seguinte mais eficaz, de modo que os ganhos se acumulam. Partes estreitas desse laço são reais e estão medidas hoje — um modelo que refi |
| knowledge/tool-use@pt | O uso de ferramentas, também chamado function calling, permite a um modelo de linguagem invocar funções, APIs ou código externos para obter informação ou tomar ações no mundo real. O modelo decide qual ferramenta chamar e com quais argumentos; a aplicação executa a ferramenta e d |
| knowledge/agent-memory@fr | La mémoire d'agent désigne la manière dont un agent d'IA conserve et rappelle des informations au-delà d'une seule fenêtre de contexte — à travers les étapes, les sessions et les tâches. Elle sépare généralement la mémoire de travail à court terme (le contexte actuel) de la mémoi |
| knowledge/agentic-ai@fr | L'IA agentique désigne des systèmes qui poursuivent des objectifs à travers plusieurs étapes — planification, appel d'outils, action sur un environnement et réaction aux retours — plutôt que de produire une réponse unique. Elle transforme un modèle de langage, de simple générateu |
| knowledge/agentic-evaluation@fr | L'évaluation de l'IA agentique consiste à mesurer la capacité d'un agent à accomplir des tâches multi-étapes utilisant des outils dans un environnement — et non pas seulement la qualité d'une réponse unique. Alors que les modèles saturent les benchmarks de connaissances statiques |
| knowledge/agentic-threat-model@fr | Un modèle de menace agentique cartographie la manière dont un agent autonome peut être attaqué : non pas à travers ses poids, mais à travers tout ce qu'il lit, mémorise, appelle et est autorisé à faire. Il identifie les surfaces d'attaque — injection de prompt directe et indirect |
| knowledge/ai-agent@fr | Un agent d'IA est un système qui combine un modèle avec des outils, de la mémoire et une boucle de contrôle pour entreprendre des actions vers un objectif, plutôt que de simplement répondre à un prompt unique. Il perçoit une situation, décide de l'action à mener, agit via des out |
| knowledge/ai-cyberdefense@fr | La cyberdéfense de l'IA est la pratique consistant à protéger les systèmes d'IA — modèles, agents, outils qu'ils appellent et données auxquelles ils accèdent — contre les attaques qui exploitent la façon dont ces systèmes raisonnent et agissent. Pour les agents, il ne s'agit pas |
| knowledge/ai-governance@fr | La gouvernance de l'IA est l'ensemble des politiques, processus, rôles et contrôles qui garantissent que l'IA est conçue et utilisée de manière responsable, légale et sûre. Elle englobe la gestion des risques, la responsabilité, la transparence, la sécurité et la conformité tout |
| knowledge/ai-observability@fr | L'observabilité de l'IA consiste à instrumenter les systèmes d'IA — en particulier les agents — afin de comprendre ce qu'ils ont fait et pourquoi. Elle capture les traces de chaque étape : prompts, appels d'outils, contexte récupéré, sorties du modèle, jetons, latence et coût. Le |
| knowledge/context-engineering@fr | L'ingénierie de contexte est la discipline qui consiste à décider quelles informations entrent dans la fenêtre de contexte limitée d'un modèle à chaque étape — et lesquelles en sont exclues. À mesure que les agents enchaînent les étapes, intégrer naïvement toutes les données dans |
| knowledge/embeddings@fr | Un embedding est un vecteur numérique qui représente la signification d'un texte (ou d'images, d'audio, de code) de sorte que les éléments sémantiquement similaires soient proches dans l'espace vectoriel. La recherche vectorielle trouve les embeddings les plus proches d'une requê |
| knowledge/enterprise-rag@fr | Le RAG d'entreprise (génération augmentée de récupération) est le modèle consistant à ancrer les réponses d'un modèle dans les propres documents d'une organisation, récupérés au moment de la requête, plutôt que de s'appuyer sur la mémoire paramétrique du modèle. Il permet à une e |
| knowledge/fine-tuning@fr | Le fine-tuning poursuit l'entraînement d'un modèle préentraîné sur un ensemble de données plus restreint et ciblé afin de spécialiser son comportement, son style ou ses connaissances sectorielles. Il est bien moins coûteux que le préentraînement et modifie les poids du modèle — c |
| knowledge/foundation-models@fr | Un modèle de fondation est un grand modèle préentraîné à grande échelle sur des données larges, qui peut être adapté à un large éventail de tâches en aval. Les grands modèles de langage (LLM) et les grands modèles multimodaux en sont les exemples canoniques. Le terme, inventé à S |
| knowledge/guardrails@fr | Les garde-fous sont des contrôles au moment de l'exécution (runtime) qui limitent ce qui entre et sort d'un système d'IA, garantissant un comportement sûr, conforme aux politiques et réglementations. Ils vérifient et filtrent les entrées et les sorties, valident les actions des o |
| knowledge/harness-engineering@fr | Le Harness Engineering est la discipline émergente de conception et d'optimisation de l'échafaudage (scaffolding) autour d'un modèle d'IA — les prompts, les outils, la mémoire, l'environnement, la boucle de contrôle et les garde-fous — afin que le modèle fonctionne de manière fia |
| knowledge/human-in-the-loop@fr | Le Human-in-the-loop (HITL) est un design pattern dans lequel une personne examine, approuve ou corrige les résultats d'un système d'IA avant qu'ils ne prennent effet — en particulier pour les actions à fort impact. Au lieu d'une autonomie totale, l'agent propose et l'humain disp |
| knowledge/mcp-security@fr | La sécurité MCP est ce qui empêche un serveur Model Context Protocol de devenir la porte d'entrée la plus facile dans un système. Le protocole standardise la manière dont les agents découvrent et appellent les outils ; il ne décide pas de qui peut les appeler, de ce qu'ils peuven |
| knowledge/model-context-protocol@fr | Le Model Context Protocol (MCP) est un standard ouvert permettant de connecter des modèles et agents d'IA à des outils, sources de données et systèmes externes via une interface unique et uniforme. Introduit par Anthropic fin 2024, il normalise la manière dont une application exp |
| knowledge/multi-agent-architecture@fr | Une architecture multi-agent divise une tâche entre plusieurs agents spécialisés qui collaborent, délèguent ou rivalisent pour atteindre un objectif, plutôt que de s'appuyer sur un seul agent généraliste. Les configurations courantes incluent un orchestrateur qui délègue à des ex |
| knowledge/prompt-engineering@fr | Le Prompt Engineering est la pratique consistant à concevoir les entrées fournies à un modèle de langage afin qu'il produise le résultat souhaité de manière fiable. Un bon prompt spécifie le rôle, la tâche, les contraintes, le format de sortie et, si nécessaire, des exemples. C'e |
| knowledge/prompt-injection@fr | L'injection de prompt est une attaque dans laquelle des instructions malveillantes masquées dans l'entrée d'un modèle de langage détournent son comportement — l'amenant à ignorer ses règles, à divulguer des données ou à faire un mauvais usage des outils. Elle figure en tête du To |
| knowledge/reasoning-models@fr | Les modèles de raisonnement sont des modèles de langage entraînés à consacrer de la puissance de calcul supplémentaire à « réfléchir » avant de répondre — en générant des étapes de raisonnement internes pour résoudre des problèmes plus difficiles en mathématiques, en code et en l |
| knowledge/recursive-self-improvement@fr | L'auto-amélioration récursive est l'idée d'un système qui améliore sa propre capacité à s'améliorer : chaque tour d'automodification rend le suivant plus efficace, si bien que les gains se cumulent. Des parties étroites de cette boucle sont réelles et mesurées aujourd'hui — un mo |
| knowledge/tool-use@fr | L'utilisation d'outils, également appelée appel de fonction (function calling), permet à un modèle de langage d'invoquer des fonctions externes, des API ou du code pour récupérer des informations ou entreprendre des actions dans le monde réel. Le modèle décide quel outil appeler |
| knowledge/agent-memory@de | Das Agenten-Gedächtnis (Agent Memory) ermöglicht es einem KI-Agenten, Informationen über ein einzelnes Kontextfenster hinaus zu behalten und abzurufen – über Schritte, Sitzungen und Aufgaben hinweg. Es trennt typischerweise das Kurzzeit-Arbeitsgedächtnis (den aktuellen Kontext) v |
| knowledge/agentic-ai@de | Agentic AI bezieht sich auf Systeme, die Ziele über mehrere Schritte hinweg verfolgen – durch Planung, den Aufruf von Tools, Interaktion mit einer Umgebung und Reaktion auf Feedback –, anstatt nur eine einzige Antwort zu generieren. Sie verwandelt ein Sprachmodell von einem reine |
| knowledge/agentic-evaluation@de | Agentic AI Evaluation ist die Praxis zu messen, wie gut ein Agent mehrstufige, Tool-nutzende Aufgaben in einer Umgebung bewältigt – nicht nur die Qualität einer einzelnen Antwort. Da Modelle statische Wissens-Benchmarks sättigen, verschiebt sich die Evaluation von der Messung der |
| knowledge/agentic-threat-model@de | Ein Agentic Threat Model ist die Abbildung dessen, wie ein autonomer Agent angegriffen werden kann: nicht über seine Gewichte, sondern über alles, was er liest, sich merkt, aufruft und tun darf. Es benennt die Angriffsflächen – direkte und indirekte Prompt Injection, Tool Poisoni |
| knowledge/ai-agent@de | Ein KI-Agent ist ein System, das ein Modell mit Tools, Speicher und einer Kontrollschleife kombiniert, um Aktionen zur Erreichung eines Ziels auszuführen, anstatt nur auf einen einzelnen Prompt zu antworten. Er nimmt eine Situation wahr, entscheidet, was zu tun ist, agiert über T |
| knowledge/ai-cyberdefense@de | KI-Cyberdefense ist die Praxis des Schutzes von KI-Systemen – Modellen, Agenten, den von ihnen aufgerufenen Tools und den Daten, auf die sie zugreifen – vor Angriffen, die die Funktionsweise und das Handeln dieser Systeme ausnutzen. Bei Agenten handelt es sich nicht um eine nacht |
| knowledge/ai-governance@de | AI Governance ist die Gesamtheit der Richtlinien, Prozesse, Rollen und Kontrollen, die sicherstellen, dass KI verantwortungsvoll, rechtmäßig und sicher entwickelt und eingesetzt wird. Sie umfasst Risikomanagement, Rechenschaftspflicht, Transparenz, Sicherheit und Compliance über |
| knowledge/ai-observability@de | AI Observability ist die Praxis der Instrumentierung von KI-Systemen – insbesondere von Agenten –, um nachvollziehbar zu machen, was sie getan haben und warum. Sie erfasst Traces (Spuren) jedes Schritts: Prompts, Tool-Aufrufe, abgerufenen Kontext, Modell-Outputs, Tokens, Latenz u |
| knowledge/context-engineering@de | Context Engineering ist die Disziplin der Entscheidung, welche Informationen in jedem Schritt in das begrenzte Kontextfenster eines Modells gelangen – und welche draußen bleiben. Da Agenten über viele Schritte hinweg laufen, verschlechtert das naive Einfügen aller Daten in den Ko |
| knowledge/embeddings@de | Ein Embedding ist ein numerischer Vektor, der die Bedeutung von Text (oder Bildern, Audio, Code) so darstellt, dass semantisch ähnliche Elemente im Vektorraum nahe beieinander liegen. Die Vektorsuche findet die einer Suchanfrage am nächsten liegenden Embeddings und ermöglicht so |
| knowledge/enterprise-rag@de | Enterprise RAG (Retrieval-Augmented Generation) ist das Entwurfsmuster, bei dem die Antworten eines Modells auf den eigenen Dokumenten einer Organisation fundiert werden, die zum Zeitpunkt der Abfrage abgerufen werden, anstatt sich auf das parametrische Gedächtnis des Modells zu |
| knowledge/fine-tuning@de | Fine-tuning setzt das Training eines vortrainierten Modells auf einem kleineren, zielgerichteten Datensatz fort, um dessen Verhalten, Stil oder Domänenwissen zu spezialisieren. Es ist weitaus günstiger als das Vortraining und ändert die Gewichte des Modells – im Gegensatz zu Prom |
| knowledge/foundation-models@de | Ein Foundation Model ist ein großes Modell, das in großem Maßstab auf breit gefächerten Daten vortrainiert wurde und an eine Vielzahl von nachgelagerten Aufgaben angepasst werden kann. Große Sprachmodelle (LLMs) und große multimodale Modelle sind die klassischen Beispiele. Der Be |
| knowledge/guardrails@de | Guardrails sind Laufzeitkontrollen, die die Ein- und Ausgaben eines KI-Systems einschränken, um dessen Verhalten sicher, richtlinienkonform (on-policy) und compliant zu halten. Sie prüfen und filtern Inputs und Outputs, validieren Tool-Aktionen, blockieren unzulässige Inhalte und |
| knowledge/harness-engineering@de | Harness Engineering ist die entstehende Disziplin des Entwurfs und der Optimierung des Gerüsts (Scaffolding) um ein KI-Modell herum – die Prompts, Tools, Speicher, Umgebung, Kontrollschleife und Guardrails –, damit das Modell bei realen Aufgaben zuverlässig funktioniert. Die Kern |
| knowledge/human-in-the-loop@de | Human-in-the-Loop (HITL) ist ein Entwurfsmuster, bei dem eine Person die Ausgabe eines KI-Systems überprüft, genehmigt oder korrigiert, bevor sie wirksam wird – insbesondere bei folgenschweren Aktionen. Anstelle von vollständiger Autonomie schlägt der Agent vor und der Mensch ent |
| knowledge/mcp-security@de | MCP-Sicherheit verhindert, dass ein Model Context Protocol-Server zum einfachsten Einfallstor in ein System wird. Das Protokoll standardisiert, wie Agenten Tools erkennen und aufrufen; es entscheidet nicht, wer sie aufrufen darf, was sie erreichen können oder was passiert, wenn e |
| knowledge/model-context-protocol@de | Das Model Context Protocol (MCP) ist ein offener Standard zur Verbindung von KI-Modellen und -Agenten mit externen Tools, Datenquellen und Systemen über eine einzige, einheitliche Schnittstelle. Es wurde Ende 2024 von Anthropic eingeführt und standardisiert, wie eine Anwendung Ko |
| knowledge/multi-agent-architecture@de | Eine Multi-Agenten-Architektur teilt eine Aufgabe auf mehrere spezialisierte Agenten auf, die zusammenarbeiten, delegieren oder konkurrieren, um ein Ziel zu erreichen, anstatt sich auf einen einzigen universellen Agenten zu verlassen. Zu den gängigen Mustern gehören ein Orchestra |
| knowledge/prompt-engineering@de | Prompt Engineering ist die Praxis des Entwerfens von Eingaben für ein Sprachmodell, damit dieses zuverlässig die gewünschte Ausgabe erzeugt. Ein guter Prompt spezifiziert die Rolle, die Aufgabe, die Einschränkungen, das Ausgabeformat und, falls nützlich, Beispiele. Es ist der am |
| knowledge/prompt-injection@de | Prompt Injection ist ein Angriff, bei dem bösartige Anweisungen, die in der Eingabe eines Sprachmodells verborgen sind, dessen Verhalten kapern – was dazu führt, dass es seine Regeln ignoriert, Daten preisgibt oder Tools missbraucht. Es steht an der Spitze der OWASP Top 10 für LL |
| knowledge/reasoning-models@de | Reasoning-Modelle sind Sprachmodelle, die darauf trainiert sind, vor der Antwort zusätzliche Rechenleistung für das „Nachdenken“ aufzuwenden. Sie generieren interne Argumentationsschritte, um schwierigere Probleme in Mathematik, Code und Logik zu lösen. Sie tauschen Latenz und Ko |
| knowledge/recursive-self-improvement@de | Rekursive Selbstverbesserung ist die Idee eines Systems, das seine eigene Fähigkeit zur Verbesserung verbessert: Jede Runde der Selbstmodifikation macht die nächste wirksamer, sodass sich Gewinne aufaddieren. Schmale Teile dieser Schleife sind real und heute gemessen — ein Modell |
| knowledge/tool-use@de | Tool Use, auch Function Calling genannt, ermöglicht es einem Sprachmodell, externe Funktionen, APIs oder Code aufzurufen, um Informationen abzurufen oder Aktionen in der realen Welt auszuführen. Das Modell entscheidet, welches Tool mit welchen Argumenten aufgerufen wird; die Anwe |
| knowledge/agent-memory@ja | エージェントメモリとは、AIエージェントが単一のコンテキストウィンドウを超えて、ステップ、セッション、タスク間で情報を保持および想起する方法である。通常、短期のワーキングメモリ(現在のコンテキスト)と、長期メモリ(エージェントが読み書きする永続的なストレージ)を分離する。メモリによって、エージェントは長いタスクを通じて状態を維持し、時間の経過とともにユーザーを記憶し、重複する作業を避けることができる。これはハーネスエンジニアリング (Harness Engineering) のコアレイヤーである。 |
| knowledge/agentic-ai@ja | Agentic AIとは、単一の回答を生成するのではなく、計画、ツールの呼び出し、環境への働きかけ、フィードバックへの対応など、複数のステップにわたって目標を追求するシステムを指す。これにより、言語モデルはテキスト生成器から、タスクを完了できる実行者へと変化する。これが表すシフトは、人間がすべてのステップを主導する「DIY(Do-It-Yourself)ソフトウェア」から、システムが作業を実行して報告する「DIFM(Do-It-For-Me)ソフトウェア」への移行である。 |
| knowledge/agentic-evaluation@ja | アジェンティックAI評価とは、単一の回答の品質だけでなく、エージェントが環境内でツールを使用するマルチステップのタスクをどれだけ適切に完了できるかを測定する手法です。モデルが静的な知識ベンチマークで飽和状態に達するにつれ、評価は「能力(モデルが何を知っているか)」の測定から「エージェンシー(システムが実際に何を達成できるか)」の測定へと移行しています。優れた評価(evals)は、ハーネスエンジニアリングを可能にするフィードバックループとなります。 |
| knowledge/agentic-threat-model@ja | アジェンティック脅威モデルとは、自律型エージェントがどのように攻撃され得るかを示すマップです。これはモデルの重み(ウェイト)を介した攻撃ではなく、エージェントが読み取り、記憶し、呼び出し、実行を許可されているすべての要素を対象とします。直接的および間接的なプロンプトインジェクション、ツールの汚染(ツールポイズニング)、過剰なエージェンシー、メモリの汚染、サプライチェーン、情報の流出経路、混乱した代理人(Confused Deputy)問題などの攻撃対象領域(サーフェス)を特定し、システムプロンプトに期待するのではなく、ハーネス内でそれぞれに対する制御(コ |
| knowledge/ai-agent@ja | AIエージェントとは、単一のプロンプトに回答するだけでなく、モデルにツール、メモリ、コントロールループを組み合わせて、目標に向けたアクションを実行するシステムです。状況を認識し、何をすべきかを決定し、ツールを介して行動し、結果を観察し、完了するまでこれを繰り返します。自律性の範囲は、単一のツール呼び出しから、複雑なタスクの長期的な実行まで多岐にわたります。 |
| knowledge/ai-cyberdefense@ja | AIサイバーディフェンスとは、AIシステム(モデル、エージェント、それらが呼び出すツール、アクセスするデータ)を、それらのシステムの推論や行動の仕組みを悪用する攻撃から保護する取り組みです。エージェントにとって、これは後から追加するレイヤーではありません。攻撃を阻止するコントロールは、エージェントを機能させるためのハーネスコンポーネント(ツールの権限、コンテキスト境界、承認ゲート、オブザーバビリティ)そのものです。エージェントを防御することは、そのハーネスをエンジニアリングすることに他なりません。 |
| knowledge/ai-governance@ja | AIガバナンスとは、AIが責任を持って、合法的に、かつ安全に構築および使用されることを保証するための一連のポリシー、プロセス、役割、およびコントロールのことです。これは、AIのライフサイクル全体にわたるリスク管理、説明責任、透明性、セキュリティ、およびコンプライアンスを網羅します。実際には、EU AI法、NIST AIリスク管理フレームワーク(NIST AI RMF)、ISO/IEC 42001などの認知されたフレームワークを、組織が実装、実証、および監査できる具体的なコントロールへと運用化します。 |
| knowledge/ai-observability@ja | AIオブザーバビリティとは、AIシステム(特にエージェント)をインストルメンテーションし、何を実行したか、そしてその理由を可視化する手法です。プロンプト、ツール呼び出し、取得されたコンテキスト、モデルの出力、トークン、レイテンシ、コストなど、各ステップのトレースをキャプチャします。エージェントは非決定的かつマルチステップであるため、オブザーバビリティこそが障害の診断を可能にし、体系的な改善を実現します。これは評価にデータを供給し、ハーネスエンジニアリング (Harness Engineering) のループを閉じるレイヤーです。 |
| knowledge/context-engineering@ja | コンテキストエンジニアリングとは、モデルの限られたコンテキストウィンドウに各ステップでどの情報を入れ、どの情報を除外するかを決定する技術分野です。エージェントが多くのステップを実行する際、単純にすべてをコンテキストに詰め込むと、品質が低下しコストが増大します。コンテキストエンジニアリングは、適切な指示、取得された知識、ツールの結果、およびメモリを厳選し、モデルが必要な時に必要なものを正確に得られるようにします。これはハーネスエンジニアリングの中核となる部分です。 |
| knowledge/embeddings@ja | 埋め込み(Embedding)とは、テキスト(または画像、音声、コード)の意味を表現する数値ベクトルであり、意味的に類似したアイテムがベクトル空間上で近くに配置されるようにします。ベクトル検索は、クエリに最も近い埋め込みを見つけることで、キーワードではなく意味による検索を可能にします。埋め込みは、検索拡張生成(RAG)、セマンティック検索、クラスタリング、レコメンデーションの基盤となっています。 |
| knowledge/enterprise-rag@ja | エンタープライズRAG(検索拡張生成)は、モデルのパラメータメモリに依存するのではなく、クエリ実行時に検索された組織独自のドキュメントに基づいてモデルの回答を根拠付けるパターンです。これにより、企業はモデルを再トレーニングすることなく、ポリシー、マニュアル、チケット、契約書などのプライベートで最新の、かつガバナンスの効いた知識を利用できると同時に、企業が必要とするアクセス制御、引用、監査可能性を維持できます。 |
| knowledge/fine-tuning@ja | ファインチューニングとは、事前学習済みモデルをより小さく的を絞ったデータセットで追加学習させ、その振る舞い、スタイル、またはドメイン知識を特化させる手法です。事前学習よりもはるかに低コストであり、プロンプティングや検索(これらはモデルを変更しません)とは異なり、モデルの重みを変更します。一貫したフォーマット、トーン、またはスキルを固定したい場合に適しています。最新の事実やプライベートな事実が必要な場合は、代わりに検索を使用してください。 |
| knowledge/foundation-models@ja | 基盤モデル(Foundation Model)とは、広範なデータを用いて大規模に事前学習され、幅広いダウンストリームタスクに適応できる大規模なモデルのことです。大規模言語モデル(LLM)や大規模マルチモーダルモデルがその代表例です。2021年にスタンフォード大学で提唱されたこの用語は、タスクごとに専用のモデルを学習させるのではなく、共有された汎用的なベースを基盤として構築し、プロンプティング、検索、またはファインチューニングを通じて特化させるというパラダイムシフトを捉えています。 |
| knowledge/guardrails@ja | ガードレールとは、AIシステムへの入力と出力を制限し、その動作を安全、ポリシー準拠、かつコンプライアンスに則った状態に保つためのランタイム制御です。モデルの周囲に安全レイヤーとして配置され、入出力のチェックとフィルタリング、ツールアクションの検証、不許可コンテンツのブロック、制限の適用などを行います。ガードレールは、AIガバナンスにおける主要な運用管理手段であり、悪用やプロンプトインジェクションに対する重要な防御策です。 |
| knowledge/harness-engineering@ja | ハーネスエンジニアリングとは、AIモデルの周囲にある足場(プロンプト、ツール、メモリ、環境、制御ループ、ガードレールなど)を設計および最適化し、モデルが実際のタスクで確実に機能するようにするための新しい分野です。その核心となる前提は、ベースモデルの生の能力が収束していくにつれ、競争優位性はモデル自体からその周囲に構築されるハーネスへと移行するということです。同じモデルであっても、タスクの成否はほぼ完全にそのハーネスに依存します。 |
| knowledge/human-in-the-loop@ja | Human-in-the-Loop(HITL)は、特に影響の大きいアクションにおいて、AIシステムの出力が有効になる前に人間がレビュー、承認、または修正を行う設計パターンです。完全な自律性の代わりに、エージェントが提案し、人間が決定します。これはエージェント型システムにおけるリスク管理の主要なコントロールであり、EU AI法やNIST AI RMFなどのAIガバナンスフレームワークで繰り返し求められる要件です。 |
| knowledge/mcp-security@ja | MCPセキュリティとは、Model Context Protocolサーバーがシステムへの最も容易な侵入経路になるのを防ぐためのものです。このプロトコルは、エージェントがツールを検出して呼び出す方法を標準化しますが、誰がツールを呼び出せるか、ツールがどこにアクセスできるか、あるいはツールの説明が有害なものに変化した場合に何が起こるかまでは決定しません。これらの決定は、認証、オリジンおよびトランスポートの検証、厳密にスコープ定義されたツール、レート制限、監査トレールなど、サーバー側で行われます。 |
| knowledge/model-context-protocol@ja | Model Context Protocol (MCP) は、AIモデルやエージェントを、単一の統一されたインターフェースを介して外部のツール、データソース、システムに接続するためのオープン標準です。2024年後半にAnthropicによって導入され、アプリケーションがコンテキストや機能をモデルに公開する方法を標準化します。ユニバーサルアダプターのように機能し、準拠している任意のクライアントが、準拠している任意のサーバーと通信できるようにします。 |
| knowledge/multi-agent-architecture@ja | マルチエージェントアーキテクチャとは、1つの汎用エージェントに依存するのではなく、目標を達成するために、連携、委譲、または競合する複数の特化型エージェントにタスクを分割する仕組みです。一般的な形態には、ワーカーに委譲するオーケストレーター、各エージェントがステージを担当するパイプライン、ディベートやクリティック(批評)のパターンなどがあります。複雑なタスクにおけるモジュール性と信頼性を向上させることができますが、調整のオーバーヘッドが加わるため、単一のエージェントでは明らかに不十分な場合にのみ採用すべきです。 |
| knowledge/prompt-engineering@ja | プロンプトエンジニアリングとは、言語モデルが望ましい出力を確実に生成するように、モデルに与える入力を設計する手法です。優れたプロンプトは、役割、タスク、制約、出力形式、および必要に応じて例を指定します。これはモデルの挙動を制御するための最も手軽な手段であり、モデルを取り囲む広範なハーネスの1つのレイヤーですが、これ単体でシステムの大規模な信頼性を担保できるわけではありません。 |
| knowledge/prompt-injection@ja | プロンプトインジェクションとは、言語モデルへの入力に隠された悪意のある指示によってモデルの挙動が乗っ取られ、ルールを無視させられたり、データを漏洩させられたり、ツールを悪用させられたりする攻撃です。これはLLMアプリケーションにおけるOWASP Top 10の第1位に挙げられています。根本的な原因は、モデルが信頼できる指示と信頼できないコンテンツを確実に分離できないことにあります。そのため、エージェントが読み取るあらゆるテキスト(Webページ、ドキュメント、ツールの実行結果など)が攻撃を媒介する可能性があります。 |
| knowledge/reasoning-models@ja | 推論モデルとは、回答する前に「思考」するために追加の計算処理を行うようトレーニングされた言語モデルです。数学、コーディング、論理におけるより困難な問題を解決するために、内部的な推論ステップを生成します。複雑で複数ステップに及ぶタスクにおいて、レイテンシーとコストを引き換えに精度を向上させます。重要なアイデアは「テスト時計算(test-time compute)」です。モデルのサイズを大きくするだけでなく、推論時により長く推論を行わせることで、結果を大幅に改善できます。 |
| knowledge/recursive-self-improvement@ja | 再帰的自己改善とは、自らを改善する能力そのものを改善する系という考えである。自己改変の各周回が次の周回をより有効にし、利得が積み上がる。この輪の狭い部分は現実に存在し、今日すでに測られている——自分の答えを推敲するモデル、自分の訓練データを生成するモデル、より良いプロンプトと道具立てを探索するモデル。だが、この語が本来名指す「積み上がる再帰」は実証されていない。測られた輪は頭打ちになり、動くためには外部からの正しさの信号を必要とし、自分の出力で訓練した系は改善ではなく劣化する。 |
| knowledge/tool-use@ja | ファンクションコーリング(function calling)とも呼ばれるツール利用(tool use)は、言語モデルが外部の関数、API、またはコードを呼び出して、情報を取得したり現実世界でアクションを実行したりできるようにする機能です。モデルはどのツールをどのような引数で呼び出すかを決定し、アプリケーションがそのツールを実行して結果を返します。モデルはその結果を使用して処理を継続します。ツール利用は、テキスト生成AIを、実際にアクションを実行できるエージェントへと変える架け橋となります。 |
| knowledge/agent-memory@zh | 智能体记忆是 AI 智能体在单个上下文窗口之外保留和检索信息的方式——跨越步骤、会话和任务。它通常将短期工作记忆(当前上下文)与长期记忆(智能体读写的持久化存储)区分开来。记忆使智能体能够在长期任务中携带状态、长期记住用户并避免重复工作。它是 Harness Engineering(智能体支撑系统工程)的核心层。 |
| knowledge/agentic-ai@zh | Agentic AI 是指通过多个步骤追求目标的系统——进行规划、调用工具、对环境做出行动并对反馈做出反应——而不是仅生成单一的响应。它将语言模型从文本生成器转变为能够完成任务的执行者。它代表了从“自主操作”(do-it-yourself)软件(人类主导每一步)向“代劳”(do-it-for-me)软件(系统执行工作并汇报结果)的转变。 |
| knowledge/agentic-evaluation@zh | 智能体AI评估是指在特定环境中衡量智能体完成多步骤、使用工具的任务的能力,而不仅仅是评估单个回答的质量。随着模型在静态知识基准测试上趋于饱和,评估正在从衡量能力(模型知道什么)转向衡量能动性(系统实际能完成什么)。优秀的评估是实现支撑系统工程的反馈闭环。 |
| knowledge/agentic-threat-model@zh | 智能体威胁模型是自主智能体可能遭受攻击的路径图:攻击并非通过其权重进行,而是通过它所读取、记忆、调用以及被允许执行的一切操作。它指明了各种攻击面——直接和间接提示词注入、工具投毒、过度授权、记忆投毒、供应链、数据外泄通道、混淆代理——从而让每一个攻击面都能在支撑系统中得到具体控制,而不是寄希望于系统提示词。 |
| knowledge/ai-agent@zh | AI 智能体是一种将模型与工具、内存和控制循环相结合的系统,旨在朝着目标采取行动,而不仅仅是回答单个提示词。它感知情境、决定做什么、通过工具采取行动、观察结果并重复这一过程直至完成。其自主程度从单一的工具调用到复杂任务的长周期执行不等。 |
| knowledge/ai-cyberdefense@zh | AI 网络防御是保护 AI 系统(模型、智能体、它们调用的工具以及它们访问的数据)免受利用这些系统推理和行为方式的攻击的实践。对于智能体而言,它不是事后添加的层:阻止攻击的控制措施与使智能体正常工作的支撑系统组件完全相同——工具权限、上下文边界、审批关口、可观测性。防御智能体就是构建其支撑系统。 |
| knowledge/ai-governance@zh | AI 治理是一套确保负责任、合法且安全地构建和使用 AI 的政策、流程、角色和控制措施。它涵盖了整个 AI 生命周期中的风险管理、问责制、透明度、安全性和合规性。在实践中,它将公认的框架(欧盟《AI 法案》、NIST AI 风险管理框架和 ISO/IEC 42001)转化为组织可以实施、证明和审计的具体控制措施。 |
| knowledge/ai-observability@zh | AI 可观测性是指对 AI 系统(尤其是智能体)进行插桩的实践,以便您能够了解它们做了什么以及原因。它捕获每一步的追踪:提示词、工具调用、检索到的上下文、模型输出、Token、延迟和成本。由于智能体具有非确定性和多步骤特征,可观测性使故障诊断和系统性改进成为可能。它是为评估提供数据并闭环 Harness Engineering(智能体支撑系统工程)的层。 |
| knowledge/context-engineering@zh | 上下文工程是一门决定在每一步中哪些信息进入模型有限的上下文窗口,以及哪些信息被排除在外的学科。随着智能体运行多个步骤,盲目地将所有内容塞入上下文中会降低质量并增加成本。上下文工程通过策划正确的指令、检索到的知识、工具结果和记忆,使模型在需要时恰好拥有其所需的内容。它是 Harness Engineering 的核心部分。 |
| knowledge/embeddings@zh | Embedding(嵌入)是一个数值向量,用于表示文本(或图像、音频、代码)的含义,从而使语义相似的项在向量空间中彼此接近。向量搜索用于查找与查询最接近的 Embedding,从而实现按含义而非关键词进行搜索。Embedding 是检索增强生成(RAG)、语义搜索、聚类和推荐的核心支柱。 |
| knowledge/enterprise-rag@zh | 企业级 RAG(检索增强生成)是一种在查询时检索组织自身的文档,并以此作为模型回答依据的模式,而不是依赖模型的参数化记忆。它允许企业在不重新训练模型的情况下,使用私有、最新且受治理的知识(如政策、手册、工单、合同),同时保持企业所需的访问控制、引用和可审计性。 |
| knowledge/fine-tuning@zh | 微调是在较小且有针对性的数据集上继续训练预训练模型,以使其行为、风格或领域知识专业化。它比预训练便宜得多,并且会改变模型的权重——这与提示(prompting)或检索不同,后者不会改变模型。使用微调可以锁定一致的格式、语气或技能;当您需要新鲜或私有的事实时,请改用检索。 |
| knowledge/foundation-models@zh | 基础模型是在大规模广泛数据上进行预训练的大型模型,可以适应广泛的下游任务。大语言模型(LLM)和大型多模态模型是典型的例子。该术语由斯坦福大学于 2021 年提出,体现了一种转变:组织不再针对每个任务训练定制模型,而是构建在共享的通用基座之上——然后通过提示、检索或微调使其专业化。 |
| knowledge/guardrails@zh | 护栏是运行时控制机制,用于约束 AI 系统的输入和输出,确保其行为安全、符合策略且合规。它们检查并过滤输入和输出、验证工具操作、拦截不合规内容并强制执行限制——作为安全层环绕在模型周围。护栏是 AI 治理中的主要运营控制手段,也是防范滥用和提示词注入的关键防线。 |
| knowledge/harness-engineering@zh | Harness Engineering 是一门新兴学科,旨在设计和优化 AI 模型周围的脚手架——提示词、工具、记忆、环境、控制循环和护栏——以便模型在实际任务中可靠地运行。其核心前提是:随着基础模型在原始能力上趋于一致,竞争优势正从模型本身转向围绕其构建的支撑系统(harness)。同一个模型在执行某项任务时是成功还是失败,几乎完全取决于其支撑系统。 |
| knowledge/human-in-the-loop@zh | 人机回环(Human-in-the-loop, HITL)是一种设计模式,其中由人员在 AI 系统的输出生效之前对其进行审查、批准或纠正——特别是针对高影响力的操作。智能体负责提议,人类负责决策,而不是完全自主。它是管理智能体系统风险的主要控制手段,也是欧盟《AI 法案》和 NIST AI RMF 等 AI 治理框架中的常见要求。 |
| knowledge/mcp-security@zh | MCP 安全是防止 Model Context Protocol(模型上下文协议)服务器成为进入系统最便捷通道的关键。该协议规范了智能体如何发现和调用工具;但它并不决定谁可以调用它们、它们可以访问什么,或者当工具描述变得具有敌意时会发生什么。这些决策存在于服务器中:身份验证、来源和传输验证、严格限制范围的工具、速率限制以及审计追踪。 |
| knowledge/model-context-protocol@zh | 模型上下文协议(MCP)是一个开放标准,用于通过单一、统一的接口将 AI 模型和智能体连接到外部工具、数据源和系统。它由 Anthropic 于 2024 年底推出,规范了应用程序向模型暴露上下文和能力的方式——其作用类似于通用适配器,使任何合规的客户端都能与任何合规的服务器进行通信。 |
| knowledge/multi-agent-architecture@zh | 多智能体架构将任务分配给多个协同、委派或竞争以达成目标的专业化智能体,而不是依赖单个通用智能体。常见形态包括向工作智能体委派任务的编排器、每个智能体负责一个阶段的流水线,以及辩论或批判模式。它可以提高复杂任务的模块化程度和可靠性,但会增加协调开销,只有在单个智能体明显无法胜任时才应采用。 |
| knowledge/prompt-engineering@zh | 提示词工程是设计提供给语言模型的输入以使其可靠地产生所需输出的实践。一个好的提示词会指定角色、任务、约束、输出格式以及(在有用时)示例。它是引导模型行为最易用的手段——也是围绕模型的更广泛支撑系统(harness)中的一层——但仅凭其自身并不能使系统在大规模下保持可靠。 |
| knowledge/prompt-injection@zh | 提示词注入是一种攻击方式,隐藏在语言模型输入中的恶意指令会劫持其行为——使其忽略自身规则、泄露数据或滥用工具。它位列 OWASP LLM 应用十大安全风险之首。其根本原因在于模型无法可靠地将可信指令与不可信内容区分开来,因此智能体读取的任何文本(网页、文档、工具结果)都可能携带攻击载荷。 |
| knowledge/reasoning-models@zh | 推理模型是经过训练的语言模型,在回答前会消耗额外的计算资源进行“思考”——生成内部推理步骤以解决数学、代码和逻辑方面的更难问题。它们在复杂的多步任务中以延迟和成本换取准确性。其核心思想是测试时计算(test-time compute):让模型在推理时进行更长时间 of 推理,而不仅仅是把模型做大,这可以显著改善结果。 |
| knowledge/recursive-self-improvement@zh | 递归自我改进指的是这样一个系统:它改进的是自己改进的能力——每一轮自我修改都让下一轮更有效,于是收益会累积。这个回路的狭窄片段是真实的,今天也已经被测量:一个模型润色自己的答案、生成自己的训练数据,或者搜索更好的提示词与工具组合。但这个词真正指称的那种累积式递归并没有被证实。已测量的回路会趋于平台,它们要运转就得依赖外部的正确性信号,而用自己的输出训练出来的系统是退化而非进步。 |
| knowledge/tool-use@zh | 工具使用(也称为函数调用)允许语言模型调用外部函数、API 或代码,以获取信息或在现实世界中执行操作。模型决定调用哪个工具以及使用什么参数;应用程序运行该工具并返回结果,模型利用该结果继续执行。工具使用是将文本生成器转变为能够实际执行任务的智能体的桥梁。 |
| patterns/attributed-memory@en | Store what an agent remembers as records that carry their origin, an owner who can remove them, and a lifetime — never as an anonymous blob of text. Memory is what turns a one-shot attack into one that re-triggers on future, unrelated tasks; attribution is what makes that reversi |
| patterns/context-compression@en | Context compression reduces the tokens fed to a model on each call while preserving the information it actually needs to act. Use it on long-running agents and long conversations to cut cost and latency and to stay inside the context window. The three levers are summarizing histo |
| patterns/correlated-run-trace@en | One identifier threads a whole agent run — inputs, model and version, every tool call with its arguments and outcome, the final action — into a record you can replay months later. The hard part is not capture. It is being complete enough to reconstruct the run and restrained enou |
| patterns/egress-allowlist@en | Restrict where an agent's traffic is allowed to go. Data theft and injection payload delivery both end in an outbound request, so a default-deny list of permitted destinations is the control that still works after every other one has failed. |
| patterns/evaluator-optimizer@en | One LLM generates a response while a second LLM evaluates it against criteria and returns feedback; the generator revises and the loop repeats until the evaluation passes. It raises quality on tasks with clear evaluation criteria, at the cost of extra calls. |
| patterns/goal-decomposition@en | Goal decomposition has an agent break a high-level goal into an ordered set of smaller, tractable sub-tasks — a plan — before acting, then execute and monitor that plan, re-planning when steps fail. The explicit plan becomes an inspectable artifact you can review, gate, and debug |
| patterns/human-approval-gate@en | A human approval gate pauses an automated workflow at a defined checkpoint so a person can review, edit or reject a proposed action before it executes — especially for high-impact, irreversible or regulated operations. It is the operational form of human-in-the-loop oversight. |
| patterns/human-escalation@en | Hand the whole task to a human when the agent detects it is out of its depth — low confidence, repeated failure, ambiguity, or sensitive situations — and pass full context so the person can take over without re-investigating. Unlike an approval gate, which pauses one action for s |
| patterns/least-privilege-tooling@en | Give an agent the narrowest set of tools, and each tool the narrowest scope, that the task actually needs. The pattern accepts that prompt injection will sometimes succeed and bounds what a hijacked agent can do — you cannot patch the model, but you can decide what it is able to |
| patterns/long-term-memory@en | Give an agent persistent memory across sessions so it remembers facts, user preferences, and prior outcomes beyond a single context window. A write path decides what to store, summarizes it, and deduplicates it; a read path retrieves only the relevant memories into context when n |
| patterns/orchestrator-workers@en | An orchestrator LLM dynamically breaks a task into subtasks, delegates each to a worker LLM, and synthesizes the results. Unlike fixed parallelization, the orchestrator decides the subtasks at runtime — making it suited to complex tasks whose decomposition is not known in advance |
| patterns/output-boundary-encoding@en | Treat everything the model emits as hostile input to whatever consumes it. Encode and validate at each destination — renderer, shell, query, downstream agent — using that destination's own rules. One global sanitiser cannot do this: escaping that is correct for HTML is meaningles |
| patterns/parallelization@en | Parallelization runs multiple LLM calls at the same time and aggregates the results. Two flavors: sectioning (split a task into independent subtasks run in parallel) and voting (run the same task several times to improve reliability or coverage). It cuts latency and can raise qua |
| patterns/prompt-chaining@en | Prompt chaining decomposes a task into a fixed sequence of LLM calls, where each step works on the output of the previous one. It trades a little latency for much higher accuracy and control, and is the simplest workflow pattern: use it whenever a task cleanly splits into ordered |
| patterns/recovery-strategy@en | Give the agent an explicit plan for when things break. Detect failures by validating outputs and catching tool errors; then retry with adjustment, fall back to an alternative path, roll back partial actions, or escalate. Bound retries to avoid runaway loops and cost, make actions |
| patterns/reflection@en | Reflection has a model critique its own output and then revise it, using the critique as feedback. It is a lightweight, single-model way to catch mistakes and improve quality on reasoning, coding and writing tasks — at the cost of extra calls. |
| patterns/routing@en | Routing classifies an input and directs it to the most appropriate specialized handler, prompt or model. It improves quality by letting each path be optimized for its case, and controls cost by sending easy requests to cheap models and hard ones to capable models. |
| patterns/sandboxed-execution@en | Run everything an agent generates or invokes inside a disposable, isolated environment with no ambient credentials, a bounded filesystem, controlled egress and hard resource caps. The sandbox is not there because the agent is malicious; it is there because the agent's input can b |
| patterns/semantic-caching@en | Semantic caching stores past model responses and reuses them when a new request is semantically similar to a previous one — matching by meaning via embeddings, not exact text. It cuts cost and latency for repetitive or near-duplicate queries common in production. |
| patterns/supervisor-agent@en | A supervisor agent is a persistent coordinator that manages a team of specialized sub-agents. It reads the conversation state, decides which specialist should act next, routes messages to it, and integrates returned results toward the goal. Unlike a one-shot decomposer, the super |
| patterns/task-prioritization@en | Order an agent's candidate tasks by value, urgency, dependencies, and cost instead of processing them first-in-first-out. A scoring function and a priority queue decide what runs next, so limited compute, budget, and time go to the work that matters most. Re-score as state change |
| patterns/attributed-memory@es | Guarda lo que un agente recuerda como registros que llevan su origen, un responsable que puede borrarlos y una caducidad — nunca como un bloque de texto anónimo. La memoria es lo que convierte un ataque de una vez en uno que vuelve a dispararse en tareas futuras que no tienen nad |
| patterns/context-compression@es | La compresión de contexto reduce los tokens que se envían al modelo en cada llamada conservando la información que realmente necesita para actuar. Úsala en agentes de larga duración y conversaciones extensas para recortar coste y latencia y mantenerte dentro de la ventana de cont |
| patterns/correlated-run-trace@es | Un identificador hilvana la ejecución entera de un agente —entradas, modelo y versión, cada llamada a herramienta con sus argumentos y su resultado, la acción final— en un registro que puedes reproducir meses después. Lo difícil no es capturar. Es ser lo bastante completo para re |
| patterns/egress-allowlist@es | Restringe adónde puede ir el tráfico de un agente. El robo de datos y la entrega de un payload de inyección terminan ambos en una petición saliente, así que una lista de destinos permitidos con denegación por defecto es el control que sigue funcionando cuando todos los demás ya h |
| patterns/evaluator-optimizer@es | Un LLM genera una respuesta mientras un segundo LLM la evalúa contra criterios y devuelve feedback; el generador revisa y el bucle se repite hasta que la evaluación pasa. Eleva la calidad en tareas con criterios de evaluación claros, a costa de llamadas extra. |
| patterns/goal-decomposition@es | La descomposición de objetivos hace que un agente divida una meta de alto nivel en un conjunto ordenado de subtareas más pequeñas y abordables — un plan — antes de actuar, para luego ejecutar y supervisar ese plan, replanificando cuando algún paso falla. El plan explícito se vuel |
| patterns/human-approval-gate@es | Una puerta de aprobación humana pausa un flujo automatizado en un punto de control definido para que una persona revise, edite o rechace una acción propuesta antes de ejecutarse, sobre todo en operaciones de alto impacto, irreversibles o reguladas. Es la forma operativa de la sup |
| patterns/human-escalation@es | Entrega toda la tarea a una persona cuando el agente detecta que supera su competencia — baja confianza, fallos repetidos, ambigüedad o situaciones delicadas — y traspasa el contexto completo para que el humano retome sin volver a investigar. A diferencia de una puerta de aprobac |
| patterns/least-privilege-tooling@es | Dale al agente el conjunto de herramientas más estrecho, y a cada herramienta el alcance más estrecho, que la tarea realmente necesita. El patrón asume que la inyección de prompts a veces tendrá éxito y acota lo que un agente secuestrado puede hacer: no puedes parchear el modelo, |
| patterns/long-term-memory@es | Dota a un agente de memoria persistente entre sesiones para que recuerde hechos, preferencias del usuario y resultados previos más allá de una única ventana de contexto. Una vía de escritura decide qué almacenar, lo resume y lo deduplica; una vía de lectura recupera solo las memo |
| patterns/orchestrator-workers@es | Un LLM orquestador descompone dinámicamente una tarea en subtareas, delega cada una a un LLM trabajador y sintetiza los resultados. A diferencia de la paralelización fija, el orquestador decide las subtareas en tiempo de ejecución, lo que lo hace adecuado para tareas complejas cu |
| patterns/output-boundary-encoding@es | Trata todo lo que el modelo emite como entrada hostil para quien lo consuma. Codifica y valida en cada destino —renderizador, shell, consulta, agente aguas abajo— con las reglas de ese destino. Un saneador global no puede hacerlo: el escapado correcto para HTML no significa nada |
| patterns/parallelization@es | La paralelización ejecuta varias llamadas al LLM a la vez y agrega los resultados. Dos variantes: seccionado (dividir una tarea en subtareas independientes en paralelo) y votación (ejecutar la misma tarea varias veces para mejorar fiabilidad o cobertura). Reduce la latencia y pue |
| patterns/prompt-chaining@es | El encadenamiento de prompts descompone una tarea en una secuencia fija de llamadas al LLM, donde cada paso trabaja sobre la salida del anterior. Cambia algo de latencia por mucha más precisión y control, y es el patrón de flujo más simple: úsalo cuando una tarea se divide limpia |
| patterns/recovery-strategy@es | Da al agente un plan explícito para cuando algo falla. Detecta fallos validando salidas y capturando errores de herramientas; luego reintenta con ajuste, recurre a una ruta alternativa, revierte acciones parciales o escala. Acota los reintentos para evitar bucles y costes descont |
| patterns/reflection@es | La reflexión hace que un modelo critique su propia salida y luego la revise, usando la crítica como feedback. Es una forma ligera, de un solo modelo, de atrapar errores y mejorar la calidad en tareas de razonamiento, código y escritura, a costa de llamadas extra. |
| patterns/routing@es | El enrutamiento clasifica una entrada y la dirige al manejador, prompt o modelo especializado más adecuado. Mejora la calidad al optimizar cada camino para su caso y controla el coste enviando peticiones fáciles a modelos baratos y las difíciles a modelos capaces. |
| patterns/sandboxed-execution@es | Ejecuta todo lo que un agente genera o invoca dentro de un entorno aislado y desechable, sin credenciales ambientales, con sistema de ficheros acotado, salida controlada y límites duros de recursos. El sandbox no está porque el agente sea malicioso, sino porque su entrada puede s |
| patterns/semantic-caching@es | La caché semántica almacena respuestas pasadas del modelo y las reutiliza cuando una nueva petición es semánticamente similar a una previa, casando por significado mediante embeddings, no por texto exacto. Reduce coste y latencia en consultas repetitivas o casi duplicadas, comune |
| patterns/supervisor-agent@es | Un agente supervisor es un coordinador persistente que gestiona un equipo de subagentes especializados. Lee el estado de la conversación, decide qué especialista debe actuar a continuación, le enruta los mensajes e integra los resultados hacia el objetivo. A diferencia de un desc |
| patterns/task-prioritization@es | Ordena las tareas candidatas de un agente por valor, urgencia, dependencias y coste en lugar de procesarlas por orden de llegada. Una función de puntuación y una cola de prioridad deciden qué se ejecuta a continuación, de modo que el cómputo, el presupuesto y el tiempo limitados |
| patterns/attributed-memory@pt | Guarde o que um agente lembra como registros que carregam sua origem, um responsável que pode removê-los e um prazo de validade — nunca como um bloco de texto anônimo. A memória é o que transforma um ataque de uma vez só em um que volta a disparar em tarefas futuras sem nenhuma r |
| patterns/context-compression@pt | A compressão de contexto reduz os tokens enviados ao modelo em cada chamada preservando a informação de que ele realmente precisa para agir. Use-a em agentes de longa duração e conversas extensas para cortar custo e latência e permanecer dentro da janela de contexto. As três alav |
| patterns/correlated-run-trace@pt | Um identificador costura a execução inteira de um agente — entradas, modelo e versão, cada chamada de ferramenta com seus argumentos e resultado, a ação final — em um registro que se pode reproduzir meses depois. O difícil não é capturar. É ser completo o bastante para reconstrui |
| patterns/egress-allowlist@pt | Restrinja para onde o tráfego de um agente pode ir. O roubo de dados e a entrega de um payload de injeção terminam ambos em uma requisição de saída, então uma lista de destinos permitidos com negação por padrão é o controle que continua funcionando depois que todos os outros já f |
| patterns/evaluator-optimizer@pt | Um LLM gera uma resposta enquanto um segundo LLM a avalia contra critérios e devolve feedback; o gerador revisa e o laço se repete até a avaliação passar. Eleva a qualidade em tarefas com critérios de avaliação claros, ao custo de chamadas extras. |
| patterns/goal-decomposition@pt | A decomposição de objetivos faz um agente dividir uma meta de alto nível em um conjunto ordenado de subtarefas menores e tratáveis — um plano — antes de agir, e então executar e monitorar esse plano, replanejando quando passos falham. O plano explícito vira um artefato inspecioná |
| patterns/human-approval-gate@pt | Um portão de aprovação humana pausa um fluxo automatizado num ponto de controle definido para que uma pessoa revise, edite ou rejeite uma ação proposta antes de executar, sobretudo em operações de alto impacto, irreversíveis ou reguladas. É a forma operacional da supervisão human |
| patterns/human-escalation@pt | Entrega a tarefa inteira a uma pessoa quando o agente detecta que está além de sua competência — baixa confiança, falhas repetidas, ambiguidade ou situações sensíveis — e repassa o contexto completo para que o humano assuma sem reinvestigar. Diferente de um portão de aprovação, q |
| patterns/least-privilege-tooling@pt | Dê ao agente o conjunto de ferramentas mais estreito, e a cada ferramenta o escopo mais estreito, que a tarefa realmente exige. O padrão assume que a injeção de prompts às vezes terá êxito e limita o que um agente sequestrado pode fazer: você não consegue corrigir o modelo, mas c |
| patterns/long-term-memory@pt | Dá a um agente memória persistente entre sessões para que ele lembre fatos, preferências do usuário e resultados anteriores além de uma única janela de contexto. Um caminho de escrita decide o que armazenar, resume e remove duplicatas; um caminho de leitura recupera apenas as mem |
| patterns/orchestrator-workers@pt | Um LLM orquestrador decompõe dinamicamente uma tarefa em subtarefas, delega cada uma a um LLM trabalhador e sintetiza os resultados. Diferentemente da paralelização fixa, o orquestrador decide as subtarefas em tempo de execução, o que o torna adequado para tarefas complexas cuja |
| patterns/output-boundary-encoding@pt | Trate tudo o que o modelo emite como entrada hostil para quem o consome. Codifique e valide em cada destino — renderizador, shell, consulta, agente a jusante — com as regras desse destino. Um sanitizador global não dá conta: o escape correto para HTML não significa nada para um s |
| patterns/parallelization@pt | A paralelização executa várias chamadas ao LLM ao mesmo tempo e agrega os resultados. Duas variantes: seccionamento (dividir uma tarefa em subtarefas independentes em paralelo) e votação (executar a mesma tarefa várias vezes para melhorar confiabilidade ou cobertura). Reduz a lat |
| patterns/prompt-chaining@pt | O encadeamento de prompts decompõe uma tarefa numa sequência fixa de chamadas ao LLM, em que cada passo trabalha sobre a saída do anterior. Troca um pouco de latência por muito mais precisão e controle, e é o padrão de fluxo mais simples: use-o quando uma tarefa se divide limpame |
| patterns/recovery-strategy@pt | Dê ao agente um plano explícito para quando algo falha. Detecte falhas validando saídas e capturando erros de ferramentas; depois reenvie com ajuste, recorra a um caminho alternativo, reverta ações parciais ou escale. Limite as retentativas para evitar laços e custos descontrolad |
| patterns/reflection@pt | A reflexão faz um modelo criticar sua própria saída e depois revisá-la, usando a crítica como feedback. É uma forma leve, de um único modelo, de capturar erros e melhorar a qualidade em tarefas de raciocínio, código e escrita, ao custo de chamadas extras. |
| patterns/routing@pt | O roteamento classifica uma entrada e a direciona ao manipulador, prompt ou modelo especializado mais adequado. Melhora a qualidade ao otimizar cada caminho para seu caso e controla o custo enviando requisições fáceis a modelos baratos e as difíceis a modelos capazes. |
| patterns/sandboxed-execution@pt | Execute tudo o que um agente gera ou invoca dentro de um ambiente isolado e descartável, sem credenciais ambientais, com sistema de arquivos limitado, saída controlada e limites rígidos de recursos. O sandbox não existe porque o agente seja malicioso, mas porque a entrada dele po |
| patterns/semantic-caching@pt | O cache semântico armazena respostas passadas do modelo e as reutiliza quando uma nova requisição é semanticamente similar a uma anterior, casando por significado via embeddings, não por texto exato. Reduz custo e latência em consultas repetitivas ou quase duplicadas, comuns em p |
| patterns/supervisor-agent@pt | Um agente supervisor é um coordenador persistente que gerencia uma equipe de subagentes especializados. Ele lê o estado da conversa, decide qual especialista deve agir em seguida, roteia mensagens para ele e integra os resultados em direção ao objetivo. Diferente de um decomposit |
| patterns/task-prioritization@pt | Ordene as tarefas candidatas de um agente por valor, urgência, dependências e custo em vez de processá-las por ordem de chegada. Uma função de pontuação e uma fila de prioridade decidem o que roda em seguida, de modo que computação, orçamento e tempo limitados vão para o trabalho |
| patterns/attributed-memory@fr | Stockez ce dont un agent se souvient sous forme d'enregistrements indiquant leur origine, un propriétaire capable de les supprimer et une durée de vie — jamais sous la forme d'un bloc de texte anonyme. La mémoire est ce qui transforme une attaque ponctuelle en une attaque qui se |
| patterns/context-compression@fr | La compression de contexte réduit les tokens fournis à un modèle lors de chaque appel tout en préservant les informations dont il a réellement besoin pour agir. Utilisez-la sur des agents à exécution longue et des conversations prolongées pour réduire les coûts et la latence, et |
| patterns/correlated-run-trace@fr | Un identifiant unique relie toute une exécution d'agent — entrées, modèle et version, chaque appel d'outil avec ses arguments et son résultat, l'action finale — dans un enregistrement que vous pouvez rejouer des mois plus tard. Le plus difficile n'est pas la capture. C'est d'être |
| patterns/egress-allowlist@fr | Restreignez les destinations autorisées pour le trafic d'un agent. Le vol de données et la livraison de charges utiles d'injection se terminent tous deux par une requête sortante, de sorte qu'une liste de destinations autorisées avec refus par défaut est le contrôle qui fonctionn |
| patterns/evaluator-optimizer@fr | Un premier LLM génère une réponse tandis qu'un second l'évalue par rapport à des critères et renvoie des commentaires ; le générateur la révise et la boucle se répète jusqu'à ce que l'évaluation soit validée. Cela améliore la qualité sur les tâches dotées de critères d'évaluation |
| patterns/goal-decomposition@fr | La décomposition d'objectifs consiste à faire en sorte qu'un agent décompose un objectif de haut niveau en un ensemble ordonné de sous-tâches plus petites et gérables — un plan — avant d'agir, puis exécute et surveille ce plan, en replanifiant lorsque des étapes échouent. Le plan |
| patterns/human-approval-gate@fr | Une porte d'approbation humaine suspend un flux de travail automatisé à un point de contrôle défini afin qu'une personne puisse examiner, modifier ou rejeter une action proposée avant son exécution — en particulier pour les opérations à fort impact, irréversibles ou réglementées. |
| patterns/human-escalation@fr | Confiez l'intégralité de la tâche à un humain lorsque l'agent détecte qu'il est dépassé — faible confiance, échecs répétés, ambiguïté ou situations sensibles — et transmettez tout le contexte pour que la personne puisse prendre le relais sans avoir à tout réanalyser. Contrairemen |
| patterns/least-privilege-tooling@fr | Attribuez à un agent l'ensemble d'outils le plus restreint, et à chaque outil la portée la plus étroite, dont la tâche a réellement besoin. Ce modèle accepte le fait que l'injection de prompt réussira parfois et limite ce qu'un agent compromis peut faire — vous ne pouvez pas corr |
| patterns/long-term-memory@fr | Dotez un agent d'une mémoire persistante d'une session à l'autre afin qu'il se souvienne des faits, des préférences de l'utilisateur et des résultats antérieurs au-delà d'une simple fenêtre de contexte. Un chemin d'écriture décide de ce qu'il faut stocker, le synthétise et suppri |
| patterns/orchestrator-workers@fr | Un LLM orchestrateur décompose dynamiquement une tâche en sous-tâches, délègue chacune à un LLM worker, et synthétise les résultats. Contrairement à la parallélisation fixe, l'orchestrateur décide des sous-tâches au moment de l'exécution — ce qui le rend adapté aux tâches complex |
| patterns/output-boundary-encoding@fr | Traitez tout ce que le modèle émet comme une entrée hostile pour tout ce qui la consomme. Encodez et validez au niveau de chaque destination — moteur de rendu, shell, requête, agent en aval — en utilisant les règles propres à cette destination. Un outil d'assainissement global un |
| patterns/parallelization@fr | La parallélisation exécute plusieurs appels de LLM en même temps et agrège les résultats. Deux variantes : le sectionnement (diviser une tâche en sous-tâches indépendantes exécutées en parallèle) et le vote (exécuter la même tâche plusieurs fois pour améliorer la fiabilité ou la |
| patterns/prompt-chaining@fr | L'enchaînement de prompts décompose une tâche en une séquence fixe d'appels de LLM, où chaque étape travaille sur le résultat de la précédente. Il échange un peu de latence contre une précision et un contrôle bien plus élevés, et constitue le pattern de workflow le plus simple : |
| patterns/recovery-strategy@fr | Donnez à l'agent un plan explicite en cas de panne. Détectez les défaillances en validant les sorties et en interceptant les erreurs des outils ; puis réessayez avec ajustement, basculez vers un chemin alternatif, annulez les actions partielles ou escaladez. Limitez les tentative |
| patterns/reflection@fr | La réflexion consiste à faire critiquer par un modèle sa propre sortie, puis à la réviser en utilisant cette critique comme retour d'expérience. C'est un moyen léger, basé sur un seul modèle, de détecter les erreurs et d'améliorer la qualité des tâches de raisonnement, de codage |
| patterns/routing@fr | Le routage classifie une entrée et la dirige vers le gestionnaire, le prompt ou le modèle spécialisé le plus approprié. Il améliore la qualité en permettant d'optimiser chaque chemin pour son cas d'usage, et maîtrise les coûts en envoyant les requêtes simples vers des modèles éco |
| patterns/sandboxed-execution@fr | Exécutez tout ce qu'un agent génère ou invoque au sein d'un environnement isolé et jetable, sans identifiants ambiants, avec un système de fichiers restreint, une sortie contrôlée et des limites strictes de ressources. Le bac à sable n'est pas là parce que l'agent est malveillant |
| patterns/semantic-caching@fr | La mise en cache sémantique stocke les réponses passées des modèles et les réutilise lorsqu'une nouvelle requête est sémantiquement similaire à une précédente — en faisant correspondre le sens via des plongements (embeddings), et non par texte exact. Elle réduit les coûts et la l |
| patterns/supervisor-agent@fr | Un agent superviseur est un coordinateur persistant qui gère une équipe de sous-agents spécialisés. Il lit l'état de la conversation, décide quel spécialiste doit intervenir ensuite, lui oriente les messages et intègre les résultats renvoyés pour atteindre l'objectif. Contraireme |
| patterns/task-prioritization@fr | Ordonner les tâches candidates d'un agent par valeur, urgence, dépendances et coût plutôt que de les traiter selon le principe du premier entré, premier sorti (FIFO). Une fonction de score et une file d'attente prioritaire déterminent l'exécution suivante, afin d'allouer les ress |
| patterns/attributed-memory@de | Speichern Sie das, woran sich ein Agent erinnert, als Datensätze, die ihre Herkunft, einen Eigentümer, der sie entfernen kann, und eine Lebensdauer enthalten – niemals als anonymen Text-Blob. Das Gedächtnis macht aus einem One-Shot-Angriff einen Angriff, der bei zukünftigen, nich |
| patterns/context-compression@de | Die Kontextkomprimierung reduziert die Token, die einem Modell bei jedem Aufruf übergeben werden, während die Informationen, die es tatsächlich zum Handeln benötigt, erhalten bleiben. Nutzen Sie sie bei langlebigen Agenten und langen Konversationen, um Kosten und Latenzzeiten zu |
| patterns/correlated-run-trace@de | Ein einziger Identifikator verknüpft einen gesamten Agenten-Run – Inputs, Modell und Version, jeden Tool-Aufruf mit seinen Argumenten und Ergebnissen, die finale Aktion – zu einem Datensatz, den Sie Monate später erneut abspielen können. Der schwierige Teil ist nicht die Erfassun |
| patterns/egress-allowlist@de | Schränken Sie ein, wohin der Traffic eines Agenten fließen darf. Datendiebstahl und die Übertragung von Injection-Payloads enden beide in einem ausgehenden Request. Eine Default-Deny-Liste zugelassener Ziele ist daher die Kontrollmaßnahme, die selbst dann noch greift, wenn alle a |
| patterns/evaluator-optimizer@de | Ein LLM generiert eine Antwort, während ein zweites LLM diese anhand von Kriterien bewertet und Feedback zurückgibt; der Generator überarbeitet die Antwort und die Schleife wiederholt sich, bis die Bewertung erfolgreich ist. Dies steigert die Qualität bei Aufgaben mit klaren Bewe |
| patterns/goal-decomposition@de | Bei der Goal Decomposition zerlegt ein Agent ein übergeordnetes Ziel vor dem Handeln in eine geordnete Reihe kleinerer, handhabbarer Teilaufgaben – einen Plan –, führt diesen Plan aus, überwacht ihn und plant neu, wenn Schritte fehlschlagen. Der explizite Plan wird zu einem überp |
| patterns/human-approval-gate@de | Ein Human-Approval-Gate pausiert einen automatisierten Workflow an einem definierten Kontrollpunkt, sodass eine Person eine vorgeschlagene Aktion überprüfen, bearbeiten oder ablehnen kann, bevor sie ausgeführt wird – insbesondere bei folgenschweren, unumkehrbaren oder regulierten |
| patterns/human-escalation@de | Übergeben Sie die gesamte Aufgabe an einen Menschen, wenn der Agent erkennt, dass er überfordert ist – bei geringem Vertrauen, wiederholtem Scheitern, Mehrdeutigkeit oder sensiblen Situationen – und übermitteln Sie den vollständigen Kontext, damit die Person die Aufgabe ohne erne |
| patterns/least-privilege-tooling@de | Geben Sie einem Agenten die minimal erforderliche Auswahl an Tools und jedem Tool den engsten Scope, den die Aufgabe tatsächlich benötigt. Das Pattern akzeptiert, dass Prompt Injections manchmal erfolgreich sein werden, und begrenzt, was ein gekaperter Agent tun kann – Sie können |
| patterns/long-term-memory@de | Geben Sie einem Agenten ein persistentes Gedächtnis über Sitzungen hinweg, sodass er sich an Fakten, Benutzerpräferenzen und frühere Ergebnisse über ein einzelnes Kontextfenster hinaus erinnert. Ein Schreibpfad entscheidet, was gespeichert wird, fasst es zusammen und dedupliziert |
| patterns/orchestrator-workers@de | Ein Orchestrator-LLM zerlegt eine Aufgabe dynamisch in Teilaufgaben, delegiert diese jeweils an ein Worker-LLM und führt die Ergebnisse zusammen. Im Gegensatz zur festen Parallelisierung entscheidet der Orchestrator zur Laufzeit über die Teilaufgaben – was ihn für komplexe Aufgab |
| patterns/output-boundary-encoding@de | Behandeln Sie alles, was das Modell ausgibt, als feindliche Eingabe für das nachfolgende System. Codieren und validieren Sie an jedem Ziel – Renderer, Shell, Query, nachgelagerter Agent – unter Verwendung der spezifischen Regeln dieses Ziels. Ein einziger globaler Sanitizer kann |
| patterns/parallelization@de | Parallelisierung führt mehrere LLM-Aufrufe gleichzeitig aus und aggregiert die Ergebnisse. Zwei Varianten: Sektionierung (Aufteilen einer Aufgabe in unabhängige, parallel ausgeführte Teilaufgaben) und Voting (mehrfaches Ausführen derselben Aufgabe zur Verbesserung der Zuverlässig |
| patterns/prompt-chaining@de | Prompt Chaining zerlegt eine Aufgabe in eine feste Sequenz von LLM-Aufrufen, bei der jeder Schritt auf der Ausgabe des vorherigen aufbaut. Es tauscht ein wenig Latenz gegen eine deutlich höhere Genauigkeit und Kontrolle ein und ist das einfachste Workflow-Muster: Nutzen Sie es im |
| patterns/recovery-strategy@de | Geben Sie dem Agenten einen expliziten Plan für den Fall, dass Fehler auftreten. Erkennen Sie Fehler, indem Sie Ausgaben validieren und Tool-Fehler abfangen; führen Sie dann einen erneuten Versuch mit Anpassungen durch, weichen Sie auf einen alternativen Pfad aus, machen Sie Teil |
| patterns/reflection@de | Bei Reflection kritisiert ein Modell seine eigene Ausgabe und überarbeitet sie anschließend, wobei es die Kritik als Feedback nutzt. Es ist eine leichtgewichtige Methode für ein einzelnes Modell, um Fehler zu finden und die Qualität bei Denk-, Codierungs- und Schreibaufgaben zu v |
| patterns/routing@de | Routing klassifiziert eine Eingabe und leitet sie an den am besten geeigneten spezialisierten Handler, Prompt oder das passende Modell weiter. Es verbessert die Qualität, indem jeder Pfad für seinen spezifischen Fall optimiert werden kann, und kontrolliert die Kosten, indem einfa |
| patterns/sandboxed-execution@de | Führen Sie alles, was ein Agent generiert oder aufruft, in einer verworfenen, isolierten Umgebung ohne implizite Anmeldedaten (Ambient Credentials), mit einem begrenzten Dateisystem, kontrolliertem Egress und harten Ressourcenlimits aus. Die Sandbox existiert nicht, weil der Agen |
| patterns/semantic-caching@de | Semantisches Caching speichert frühere Modellantworten und verwendet sie wieder, wenn eine neue Anfrage einer vorherigen semantisch ähnlich ist – der Abgleich erfolgt über die Bedeutung mittels Embeddings, nicht über exakten Text. Dies senkt Kosten und Latenz bei sich wiederholen |
| patterns/supervisor-agent@de | Ein Supervisor-Agent ist ein persistenter Koordinator, der ein Team von spezialisierten Sub-Agenten verwaltet. Er liest den Konversationsstatus, entscheidet, welcher Spezialist als Nächstes agieren soll, leitet Nachrichten an diesen weiter und integriert die zurückgegebenen Ergeb |
| patterns/task-prioritization@de | Ordnen Sie die potenziellen Aufgaben eines Agenten nach Wert, Dringlichkeit, Abhängigkeiten und Kosten, anstatt sie nach dem First-In-First-Out-Prinzip zu verarbeiten. Eine Scoring-Funktion und eine Priority Queue entscheiden, was als Nächstes ausgeführt wird, sodass begrenzte Re |
| patterns/attributed-memory@ja | エージェントが記憶する内容を、匿名のテキストの塊としてではなく、そのオリジン(発生元)、削除権限を持つオーナー、および有効期間を保持するレコードとして保存します。メモリは、単発の攻撃を、将来の無関係なタスクで再トリガーされる攻撃へと変えてしまう要因です。アトリビューション(属性定義)こそが、それを可逆的なものにします。 |
| patterns/context-compression@ja | Context Compressionは、モデルが動作するために実際に必要な情報を保持しながら、各呼び出しでモデルに提供されるトークン数を削減します。長期稼働するエージェントや長い会話で使用することで、コストとレイテンシを削減し、コンテキストウィンドウ内に収めることができます。3つの手段は、履歴の要約、無関係なコンテキストの整理、およびプロンプトの圧縮です。主なリスクは、重要な詳細を1つ落としてしまうという、情報の非可逆性(ロス)です。単に節約されたトークン数だけでなく、保持された情報を測定してください。 |
| patterns/correlated-run-trace@ja | 単一の識別子が、エージェントの実行全体(入力、モデルとバージョン、引数と結果を伴うすべてのツール呼び出し、最終的なアクション)をスレッド化し、数ヶ月後でも再現可能な記録としてまとめます。難しいのはキャプチャすること自体ではありません。実行を再構成できるほど完全でありながら、トレースストアが記述対象データの単なる二重コピーにならないよう抑制を効かせることです。 |
| patterns/egress-allowlist@ja | エージェントのトラフィックの送信先を制限します。データの窃盗もインジェクションペイロードの配信も、最終的には外部へのリクエストに行き着くため、許可された送信先のみを定義するデフォルト拒否(default-deny)リストは、他のすべてのコントロールが失敗した後に機能する最後の砦となります。 |
| patterns/evaluator-optimizer@ja | 1つのLLMが応答を生成し、2つ目のLLMが基準に照らしてそれを評価してフィードバックを返します。生成器(ジェネレーター)が修正を行い、評価をクリアするまでループが繰り返されます。追加の呼び出しコストが発生する代わりに、明確な評価基準を持つタスクの品質を向上させます。 |
| patterns/goal-decomposition@ja | ゴール分解(Goal Decomposition)では、エージェントが行動を起こす前に、高レベルのゴールを処理可能な小さなサブタスクの順序付きセット(計画)に分解します。その後、その計画を実行および監視し、ステップが失敗した場合には再計画を行います。明示的な計画は、レビュー、ゲート制御、デバッグが可能な「検査可能なアーティファクト」になります。このパターンは、ゴールに複数の依存ステップが必要であり、その場しのぎで一歩ずつ進むリアクティブなエージェントでは方向性を見失ったり失速したりする場合に使用します。単純なワンショットのタスクではスキップしてください。 |
| patterns/human-approval-gate@ja | 人による承認ゲートは、定義されたチェックポイントで自動化されたワークフローを一時停止し、提案されたアクションが実行される前に、人がそれをレビュー、編集、または拒否できるようにするものです。これは特に、影響が大きく、不可逆的、または規制対象となる操作に有効です。これは、Human-in-the-Loop(人間関与)による監視を運用可能な形にしたものです。 |
| patterns/human-escalation@ja | エージェントが自身の能力を超えている(信頼度の低さ、繰り返される失敗、曖昧さ、または機密性の高い状況など)と検出した場合、タスク全体を人間に引き渡し、十分なコンテキストを渡すことで、その人が再調査することなく引き継げるようにします。1つのアクションをサインオフのために一時停止する承認ゲートとは異なり、エスカレーションは所有権を移転するため、エージェントは処理の主導を停止します。難しいのは、過剰なエスカレーションとエスカレーション不足の両方を避けるためにトリガーを調整することです。 |
| patterns/least-privilege-tooling@ja | エージェントにはタスクが実際に必要とする最も狭いツールのセットを、各ツールには最も狭いスコープを提供します。このパターンは、プロンプトインジェクションが成功することがあるという前提を受け入れ、乗っ取られたエージェントができることを制限します。モデルにパッチを当てることはできませんが、モデルがアクセスできる範囲を決定することはできます。 |
| patterns/long-term-memory@ja | エージェントにセッション間で永続する記憶を提供し、単一のコンテキストウィンドウを超えて事実、ユーザーの好み、過去の結果を記憶できるようにします。書き込みパスは保存すべき内容を決定し、要約して重複を排除します。読み取りパスは、必要なときにのみ関連する記憶をコンテキストに取得します。再計算をスキップするために回答全体をキャッシュするセマンティックキャッシュとは異なり、長期記憶は永続的な事実と状態を保存し、毎回それらを新しい推論に再構成します。 |
| patterns/orchestrator-workers@ja | オーケストレーターLLMがタスクを動的にサブタスクに分割し、それぞれをワーカーLLMに委譲して、結果を統合します。固定された並列化とは異なり、オーケストレーターは実行時にサブタスクを決定するため、事前に分解方法がわからない複雑なタスクに適しています。 |
| patterns/output-boundary-encoding@ja | モデルが出力するすべてのものを、それを消費するシステムに対する敵対的な入力として扱います。レンダラー、シェル、クエリ、下流のエージェントなど、各宛先において、その宛先独自のルールを使用してエンコードと検証を行います。単一のグローバルなサニタイザーではこれを行うことはできません。HTMLにとって正しいエスケープ処理は、シェルにとっては無意味だからです。 |
| patterns/parallelization@ja | 並列化は、複数のLLM呼び出しを同時に実行し、その結果を集約します。これには2つのパターンがあります。セクショニング(タスクを独立したサブタスクに分割して並列実行する)と、ボーティング(信頼性やカバレッジを向上させるために同じタスクを複数回実行する)です。これにより、レイテンシが短縮され、品質が向上します。 |
| patterns/prompt-chaining@ja | プロンプトチェーニングは、タスクを固定された一連のLLM呼び出しに分解し、各ステップで前のステップの出力を処理します。わずかなレイテンシと引き換えに、精度と制御性を大幅に向上させることができます。これは最もシンプルなワークフローパターンであり、タスクを順序付けられたサブタスクに明確に分割できる場合は常に使用すべきです。 |
| patterns/recovery-strategy@ja | エージェントに対して、問題が発生した際の明示的な計画を提供します。出力の検証やツールのエラーのキャッチによって失敗を検出し、調整を伴う再試行、代替パスへのフォールバック、部分的なアクションのロールバック、またはエスカレーションを行います。無限ループやコストの急増を防ぐために再試行回数を制限し、アクションを冪等(べきとう)にし、一時的な失敗と永続的な失敗を区別します。目標は、クラッシュやサイレントな誤り(誤った結果をそのまま出力すること)を避け、段階的に機能を縮小(グレースフルデグラデーション)させることです。 |
| patterns/reflection@ja | リフレクションは、モデルに自身の出力を批判(レビュー)させ、その批判をフィードバックとして使用して修正させる手法です。これは、追加の呼び出しコストと引き換えに、推論、コーディング、執筆タスクにおける誤りを検出し、品質を向上させるための、単一モデルによる軽量なアプローチです。 |
| patterns/routing@ja | ルーティングは、入力を分類し、最も適切な専用のハンドラー、プロンプト、またはモデルに転送します。各パスをそのケースに合わせて最適化できるようにすることで品質を向上させ、簡単なリクエストは安価なモデルに、難しいリクエストは能力の高いモデルに送信することでコストを制御します。 |
| patterns/sandboxed-execution@ja | エージェントが生成または呼び出すものはすべて、環境固有の資格情報(ambient credentials)を持たず、制限されたファイルシステム、制御された送信(egress)、および厳格なリソース制限を備えた、使い捨ての隔離環境内で実行します。サンドボックスが存在するのは、エージェントが悪意を持っているからではなく、エージェントへの入力が悪意を持っている可能性があるからです。 |
| patterns/semantic-caching@ja | セマンティックキャッシュは、過去のモデルの応答を保存し、新しいリクエストが以前のリクエストと意味的に類似している場合にそれを再利用します。これは、正確なテキストではなく、埋め込み(embeddings)を介して意味でマッチングを行います。本番環境でよく見られる、繰り返されるクエリやほぼ重複するクエリのコストとレイテンシーを削減します。 |
| patterns/supervisor-agent@ja | スーパーバイザーエージェントは、専門化されたサブエージェントのチームを管理する永続的なコーディネーターです。会話の状態を読み取り、次にどのスペシャリストが動作すべきかを決定し、メッセージをルーティングし、返された結果を統合して目標に向かって進めます。ワンショットのデコンポーザー(分解器)とは異なり、スーパーバイザーは多数のターンにわたってループ内にとどまり、機能ごとに委任し、タスクが完了するかユーザーに返されるまで再計画を行います。 |
| patterns/task-prioritization@ja | エージェントの候補タスクを先入れ先出し(FIFO)で処理するのではなく、価値、緊急度、依存関係、およびコストに基づいて順序付けします。スコアリング関数と優先度付きキューが次に実行するタスクを決定するため、限られた計算リソース、予算、時間を最も重要な作業に割り当てることができます。状態の変化に応じて再スコアリングを行い、キューに上限を設けて無制限に肥大化するのを防ぎます。 |
| patterns/attributed-memory@zh | 将智能体记住的内容存储为包含其来源、可将其删除的所有者以及生命周期的记录,绝不能存为匿名的文本块。记忆会将单次攻击转变为在未来无关任务中重复触发的攻击;而归属化正是让这种影响可逆的关键。 |
| patterns/context-compression@zh | 上下文压缩在减少每次调用时输入给模型的 token 数量的同时,保留了模型实际执行操作所需的信息。在长期运行的智能体和长对话中使用它,可以降低成本和延迟,并保持在上下文窗口限制之内。其三大手段是总结历史记录、剪裁无关上下文以及压缩提示词。核心风险是信息有损:遗漏了那一个至关重要的细节。应衡量保留的信息量,而不仅仅是节省的 token 数量。 |
| patterns/correlated-run-trace@zh | 一个标识符将整个智能体运行过程串联起来——输入、模型及版本、每次工具调用及其参数和结果、最终动作——形成一条可在数月后重新播放的记录。难点不在于捕获,而在于既要足够完整以重构运行过程,又要足够克制以避免追踪存储库成为其所描述数据的第二份副本。 |
| patterns/egress-allowlist@zh | 限制智能体的流量允许流向何处。数据窃取和注入有效载荷的传递都以出站请求结束,因此默认拒绝的允许目标地址列表是在其他所有控制措施都失效后仍然有效的控制手段。 |
| patterns/evaluator-optimizer@zh | 一个 LLM 生成响应,而第二个 LLM 根据标准对其进行评估并返回反馈;生成器进行修改,循环重复,直到评估通过。它以增加额外调用为代价,提高了具有明确评估标准的任务的质量。 |
| patterns/goal-decomposition@zh | 目标分解让智能体在行动之前,将高层目标拆分为一组有序的、易于处理的子任务(即计划),然后执行并监控该计划,在步骤失败时重新规划。显式计划会成为一个可检查的产物,供您进行评审、把关和调试。当目标需要多个相互依赖的步骤,且反应式、逐步执行的智能体容易偏离方向或停滞不前时,请使用此模式;对于简单的单次任务,请跳过此模式。 |
| patterns/human-approval-gate@zh | 人工审批关卡在定义的检查点暂停自动化工作流,以便人员在执行建议的操作之前进行审查、编辑或拒绝——特别是针对高影响、不可逆或受监管的操作。它是人机回环(human-in-the-loop)监督的运行形式。 |
| patterns/human-escalation@zh | 当智能体检测到自身无能为力时(置信度低、重复失败、存在歧义或敏感情况),将整个任务移交给人类,并传递完整的上下文,以便人员无需重新调查即可接管。与暂停单个操作以等待签字批准的审批关卡不同,升级会转移所有权,使智能体停止主导。难点在于校准触发器,以避免过度升级和升级不足。 |
| patterns/least-privilege-tooling@zh | 为智能体提供任务实际所需的最窄工具集,并为每个工具赋予最窄的范围。该模式承认提示词注入有时会成功,并限制了被劫持的智能体所能执行的操作——您无法修补模型,但可以决定它能够触及的内容。 |
| patterns/long-term-memory@zh | 为智能体提供跨会话的持久化记忆,使其能够在单个上下文窗口之外记住事实、用户偏好和先前的结果。写入路径决定存储什么、对其进行摘要并去重;读取路径在需要时仅将相关的记忆检索到上下文中。与缓存完整答案以跳过重复计算的语义缓存不同,长期记忆存储持久的事实和状态,并在每次进行新的推理时重新组合它们。 |
| patterns/orchestrator-workers@zh | 编排器 LLM 动态地将任务分解为子任务,将每个子任务委派给工作器 LLM,并综合结果。与固定的并行化不同,编排器在运行时决定子任务,这使其适用于无法提前预知如何分解的复杂任务。 |
| patterns/output-boundary-encoding@zh | 将模型输出的所有内容都视为对其消费端的恶意输入。在每个目标端(渲染器、shell、查询、下游智能体)使用该目标端自身的规则进行编码和验证。单一的全局净化器无法做到这一点:对 HTML 正确的转义对 shell 来说毫无意义。 |
| patterns/parallelization@zh | 并行化同时运行多个 LLM 调用并汇总结果。它有两种形式:分段(将任务拆分为独立子任务并并行运行)和投票(多次运行同一任务以提高可靠性或覆盖率)。它能降低延迟并提高质量。 |
| patterns/prompt-chaining@zh | 提示词链式调用(Prompt Chaining)将任务分解为固定的 LLM 调用序列,其中每一步都基于上一步的输出进行处理。它以少许延迟为代价换取极高的准确性和控制力,是最简单的流式工作流模式:只要任务可以清晰地拆分为有序的子任务,即可使用该模式。 |
| patterns/recovery-strategy@zh | 为智能体提供明确的应对故障的计划。通过验证输出和捕获工具错误来检测故障;然后通过调整进行重试、回退到备用路径、回滚部分操作或进行升级。限制重试次数以避免失控循环和成本超支,使操作具备幂等性,并区分瞬态故障与永久故障。其目标是实现优雅降级,而不是崩溃或产生隐蔽的错误结果。 |
| patterns/reflection@zh | 反思让模型批判自己的输出,然后以该批判作为反馈进行修改。这是一种轻量级的、单模型的方法,用于在推理、编码和写作任务中发现错误并提高质量,代价是需要额外的调用。 |
| patterns/routing@zh | 路由对输入进行分类,并将其引导至最合适的专用处理器、提示词或模型。它通过让每条路径针对其具体情况进行优化来提高质量,并通过将简单的请求发送给便宜的模型、将困难的请求发送给能力更强的模型来控制成本。 |
| patterns/sandboxed-execution@zh | 在一次性的隔离环境中运行智能体生成或调用的所有内容,该环境不提供环境凭据,具有受限的文件系统、受控的出站流量和严格的资源上限。引入沙箱并不是因为智能体本身具有恶意,而是因为智能体的输入可能具有恶意。 |
| patterns/semantic-caching@zh | 语义缓存存储以往的模型响应,并在新请求与先前请求语义相似时重新使用它们——通过嵌入(embeddings)按含义进行匹配,而非精确文本匹配。它降低了生产环境中常见的重复或近乎重复查询的成本和延迟。 |
| patterns/supervisor-agent@zh | 主管智能体是一个持久的协调器,用于管理一个由专业子智能体组成的团队。它读取对话状态,决定下一个应该由哪个专家执行,将消息路由给它,并整合返回的结果以实现目标。与一次性分解器不同,主管智能体在多轮对话中始终保持在控制流中,按能力进行委派并重新规划,直到任务完成或交还给用户。 |
| patterns/task-prioritization@zh | 根据价值、紧急程度、依赖关系和成本对智能体的候选任务进行排序,而不是按照先进先出(FIFO)的方式进行处理。通过评分函数和优先级队列决定下一步运行什么,从而将有限的算力、预算和时间投入到最重要的工作中。随着状态的变化重新评分,并限制队列大小以防止其无限制增长。 |
| architectures/customer-service-agent@en | A reference architecture for an enterprise customer-service agent that resolves common requests end to end — answering from a grounded knowledge base, acting in the CRM and ticketing systems through tools, and escalating to a human when confidence is low or the action is high-imp |
| architectures/enterprise-knowledge-assistant@en | A reference architecture for an internal knowledge assistant that answers employee questions from the company's own documents — wikis, policies, tickets, code — with citations and respecting each user's access permissions. It combines hybrid retrieval and reranking for grounding, |
| architectures/sales-copilot@en | A sales copilot is an agent that assists reps end to end: it researches accounts from CRM and product data, drafts personalized outreach and follow-ups, logs activity, surfaces next-best-actions, and prepares meeting briefs. Everything is grounded in the company's CRM, deal, and |
| architectures/ai-workforce@en | An AI workforce is an orchestrated team of specialized agents that collaborate on multi-step business processes under a supervisor. The supervisor decomposes a goal, prioritizes and delegates subtasks to specialist agents (research, drafting, QA), and they share state through a c |
| architectures/operations-center@en | An operations center is an agentic AIOps system that watches monitoring signals and alerts, correlates and triages them, diagnoses likely root cause, and executes only vetted runbook remediations — keeping destructive or novel actions behind human approval. It cuts alert fatigue |
| architectures/agentic-immune-system@en | A reference architecture for running enterprise AI agents without concentrating trust in any one of them. Five layers — identity, least privilege, containment, oversight and recovery — assume that some agent will eventually be wrong or subverted, and make that event survivable in |
| architectures/customer-service-agent@es | Una arquitectura de referencia para un agente empresarial de atención al cliente que resuelve solicitudes comunes de extremo a extremo: responde desde una base de conocimiento fundamentada, actúa en el CRM y los sistemas de tickets mediante herramientas, y escala a un humano cuan |
| architectures/enterprise-knowledge-assistant@es | Una arquitectura de referencia para un asistente de conocimiento interno que responde preguntas de los empleados desde los propios documentos de la empresa —wikis, políticas, tickets, código— con citas y respetando los permisos de acceso de cada usuario. Combina recuperación híbr |
| architectures/sales-copilot@es | Un copiloto de ventas es un agente que asiste a los representantes de principio a fin: investiga cuentas a partir del CRM y de los datos de producto, redacta correos personalizados y seguimientos, registra actividad, propone próximas mejores acciones y prepara informes para reuni |
| architectures/ai-workforce@es | Una fuerza laboral de IA es un equipo orquestado de agentes especializados que colaboran en procesos de negocio de varios pasos bajo un supervisor. El supervisor descompone un objetivo, prioriza y delega subtareas a agentes especialistas (investigación, redacción, control de cali |
| architectures/operations-center@es | Un centro de operaciones es un sistema agéntico de AIOps que vigila las señales de monitoreo y las alertas, las correlaciona y prioriza, diagnostica la causa raíz probable y ejecuta solo remediaciones de runbooks validados, manteniendo las acciones destructivas o novedosas detrás |
| architectures/agentic-immune-system@es | Arquitectura de referencia para operar agentes de IA en la empresa sin concentrar la confianza en ninguno de ellos. Cinco capas —identidad, mínimo privilegio, contención, supervisión y recuperación— dan por supuesto que algún agente acabará equivocándose o siendo subvertido, y ha |
| architectures/customer-service-agent@pt | Uma arquitetura de referência para um agente empresarial de atendimento que resolve solicitações comuns de ponta a ponta: responde a partir de uma base de conhecimento fundamentada, age no CRM e nos sistemas de tickets via ferramentas, e escala para um humano quando a confiança é |
| architectures/enterprise-knowledge-assistant@pt | Uma arquitetura de referência para um assistente de conhecimento interno que responde perguntas dos funcionários a partir dos próprios documentos da empresa —wikis, políticas, tickets, código— com citações e respeitando as permissões de acesso de cada usuário. Combina recuperação |
| architectures/sales-copilot@pt | Um copiloto de vendas é um agente que assiste os representantes de ponta a ponta: pesquisa contas a partir do CRM e dos dados de produto, redige mensagens personalizadas e follow-ups, registra atividade, sugere próximas melhores ações e prepara briefings para reuniões. Tudo é fun |
| architectures/ai-workforce@pt | Uma força de trabalho de IA é uma equipe orquestrada de agentes especializados que colaboram em processos de negócio de várias etapas sob um supervisor. O supervisor decompõe um objetivo, prioriza e delega subtarefas a agentes especialistas (pesquisa, redação, controle de qualida |
| architectures/operations-center@pt | Um centro de operações é um sistema agêntico de AIOps que observa sinais de monitoramento e alertas, correlaciona e prioriza, diagnostica a causa raiz provável e executa apenas remediações de runbooks validados, mantendo ações destrutivas ou inéditas atrás de uma aprovação humana |
| architectures/agentic-immune-system@pt | Arquitetura de referência para operar agentes de IA na empresa sem concentrar a confiança em nenhum deles. Cinco camadas — identidade, privilégio mínimo, contenção, supervisão e recuperação — partem do princípio de que algum agente acabará por errar ou ser subvertido, e tornam es |
| architectures/customer-service-agent@fr | Une architecture de référence pour un agent de service client d'entreprise qui résout les requêtes courantes de bout en bout : il répond à partir d'une base de connaissances ancrée, agit dans le CRM et les systèmes de tickets via des outils, et escalade vers un humain lorsque le |
| architectures/enterprise-knowledge-assistant@fr | Une architecture de référence pour un assistant de connaissances interne qui répond aux questions des employés à partir des propres documents de l'entreprise — wikis, politiques, tickets, code — avec des citations et dans le respect des autorisations d'accès de chaque utilisateur |
| architectures/sales-copilot@fr | Un copilote de vente (sales copilot) est un agent qui assiste les commerciaux de bout en bout : il effectue des recherches sur les comptes à partir du CRM et des données produits, rédige des messages de prospection et de suivi personnalisés, consigne l'activité, suggère les meill |
| architectures/ai-workforce@fr | Une main-d'œuvre IA est une équipe orchestrée d'agents spécialisés qui collaborent sur des processus métier multi-étapes sous la direction d'un superviseur. Le superviseur décompose un objectif, hiérarchise et délègue les sous-tâches à des agents spécialisés (recherche, rédaction |
| architectures/operations-center@fr | Un centre d'opérations est un système d'AIOps agentique qui surveille les signaux et alertes de monitoring, les corrèle et les trie, diagnostique la cause racine probable et exécute uniquement des remédiations de runbook validées — tout en soumettant les actions destructrices ou |
| architectures/agentic-immune-system@fr | Architecture de référence pour exploiter des agents d'IA en entreprise sans concentrer la confiance sur aucun d'eux. Cinq couches — identité, moindre privilège, confinement, supervision et récupération — partent du principe qu'un agent finira par se tromper ou être détourné, et r |
| architectures/customer-service-agent@de | Eine Referenzarchitektur für einen Enterprise-Kundenservice-Agenten, der häufige Anfragen End-to-End löst – er antwortet auf Basis einer fundierten (grounded) Wissensdatenbank, agiert über Tools in CRM- und Ticketing-Systemen und eskaliert an einen Menschen, wenn das Vertrauen (C |
| architectures/enterprise-knowledge-assistant@de | Eine Referenzarchitektur für einen internen Wissensassistenten, der Fragen von Mitarbeitenden auf Basis unternehmenseigener Dokumente – Wikis, Richtlinien, Tickets, Code – beantwortet, inklusive Quellenangaben und unter Berücksichtigung der jeweiligen Zugriffsberechtigungen. Sie |
| architectures/sales-copilot@de | Ein Sales Copilot ist ein Agent, der Vertriebsmitarbeiter End-to-End unterstützt: Er recherchiert Accounts aus CRM- und Produktdaten, entwirft personalisierte Kundenansprachen und Follow-ups, protokolliert Aktivitäten, schlägt Next-Best-Actions vor und bereitet Meeting-Briefings |
| architectures/ai-workforce@de | Eine AI Workforce ist ein orchestriertes Team spezialisierter Agenten, die unter der Leitung eines Supervisors bei mehrstufigen Geschäftsprozessen zusammenarbeiten. Der Supervisor zerlegt ein Ziel, priorisiert und delegiert Teilaufgaben an spezialisierte Agenten (Recherche, Entwu |
| architectures/operations-center@de | Ein Operations Center ist ein agentisches AIOps-System, das Monitoring-Signale und Warnmeldungen überwacht, diese korreliert und triagiert, die wahrscheinliche Ursache diagnostiziert und ausschließlich geprüfte Runbook-Fehlerbehebungen ausführt – wobei destruktive oder neuartige |
| architectures/agentic-immune-system@de | Referenzarchitektur, um KI-Agenten im Unternehmen zu betreiben, ohne das Vertrauen auf einen einzelnen zu bündeln. Fünf Schichten – Identität, minimale Rechte, Eindämmung, Aufsicht und Wiederherstellung – gehen davon aus, dass irgendein Agent irgendwann falsch handelt oder unterw |
| architectures/customer-service-agent@ja | 一般的なリクエストをエンドツーエンドで解決する、エンタープライズ向けカスタマーサービスエージェントのリファレンスアーキテクチャです。グラウンディングされたナレッジベースに基づいて回答し、ツールを介してCRMやチケット管理システムでアクションを実行し、確信度が低い場合や影響の大きいアクションの場合は人間にエスカレーションします。安全性のためにグラウンディング用の検索とリスクベースの人間による承認を組み合わせ、すべての会話を評価・改善できるようにオブザーバビリティ(可観測性)を確保しています。 |
| architectures/enterprise-knowledge-assistant@ja | 社内文書(Wiki、ポリシー、チケット、コードなど)から、各ユーザーのアクセス権限を尊重し、引用元を明示しながら従業員の質問に回答する社内ナレッジアシスタントのリファレンスアーキテクチャです。グラウンディングのためのハイブリッド検索とリランキング、セキュリティのための権限対応フィルタリング、そして回答の品質を推測ではなく測定可能にする評価ハーネスを組み合わせています。難しいのはモデルではなく、検索の品質、アクセス制御、および評価です。 |
| architectures/sales-copilot@ja | セールスコパイロット(Sales Copilot)は、営業担当者をエンドツーエンドで支援するエージェントです。CRMや製品データからアカウントを調査し、パーソナライズされたアウトリーチやフォローアップのドラフトを作成し、アクティビティを記録し、ネクストベストアクションを提示し、ミーティングブリーフを準備します。機能や価格に関するハルシネーション(事実に基づかない主張)を防ぐため、すべてが自社のCRM、ディール、製品ナレッジにグラウンディング(根拠付け)されます。営業担当者が常にコントロールを保持します。すべてのアウトバウンドアクションの手前に人間の承認ゲ |
| architectures/ai-workforce@ja | AIワークフォースとは、スーパーバイザー(監督者)のもとで、複数ステップのビジネスプロセスを協調して実行する、専門化されたエージェントのオーケストレーションされたチームです。スーパーバイザーは目標を分解し、優先順位を付けて、専門エージェント(調査、起草、QAなど)にサブタスクを委任します。各エージェントは共通のストアを介して状態(ステート)を共有します。エージェントは自身の能力を超える場合に人間へエスカレーションし、すべてのステップが観察可能(オブザーバブル)かつガバナンスの対象となります。これはデジタルワーカーの管理として捉えるべきです。成功するかどう |
| architectures/operations-center@ja | オペレーションセンターは、監視シグナルやアラートを監視し、それらを関連付けてトリアージし、可能性の高い根本原因を診断して、検証済みのランブックによる修復のみを実行する、エージェント型AIOpsシステムです。破壊的なアクションや新しいアクションは、人間の承認を必要とするように制限します。安全な読み取り主体の診断を自動化する一方で、リスクの高い書き込みアクションをオンコールエンジニアにエスカレーションすることで、アラート疲れを軽減し、平均修復時間(MTTR)を短縮します。すべてのアクションは監査可能で、取り消し可能です。成功の尺度は、自動化の量ではなく、MT |
| architectures/agentic-immune-system@ja | 特定のエージェントに信頼を集中させずに企業で AI エージェントを運用するためのリファレンスアーキテクチャ。アイデンティティ、最小権限、封じ込め、監督、復旧という五つの層は、いずれかのエージェントがいつか誤るか乗っ取られることを前提とし、その日を壊滅ではなく生存可能な出来事にする。防御の単位は個々の実行であり、群ではない。 |
| architectures/customer-service-agent@zh | 企业级客户服务智能体的参考架构,可端到端地解决常见请求——基于可靠的知识库进行回答,通过工具在 CRM 和工单系统中执行操作,并在置信度较低或操作影响重大时升级给人工处理。它将用于知识对齐(grounding)的检索与基于风险的人工审批相结合以确保安全,并具备可观测性,以便对每次对话进行评估和改进。 |
| architectures/enterprise-knowledge-assistant@zh | 内部知识助手的参考架构,该助手可根据公司自身的文档(Wiki、政策、工单、代码)回答员工的问题,并提供引用出处,同时遵循每个用户的访问权限。它结合了用于 Grounding 的混合检索与重排、用于保障安全的权限感知过滤,以及一个评估系统(evaluation harness),从而使回答质量能够被量化评估而非凭空假设。难点不在于模型,而在于检索质量、访问控制和评估。 |
| architectures/sales-copilot@zh | Sales Copilot 是一款端到端辅助销售代表的智能体:它能根据 CRM 和产品数据研究客户,起草个性化的外联和跟进内容,记录活动,提供“下一步最佳行动”建议,并准备会议简报。所有内容都基于公司的 CRM、交易和产品知识,以避免对功能或价格产生幻觉。销售代表始终保持控制权:在执行任何外发操作之前都有人工审批环节,因此智能体只负责起草,绝不会自行向客户发送。成功是通过销售代表的生产力和对销售管线(pipeline)的影响来真实衡量的,而不是通过虚荣的活动数量。 |
| architectures/ai-workforce@zh | AI 员工是由专业智能体协同组成的编排团队,在主管智能体的领导下协作处理多步骤业务流程。主管智能体负责分解目标,并将子任务按优先级分配给专业智能体(如研究、起草、QA),它们通过公共存储共享状态。当智能体能力不足时会升级上报给人类,且每个步骤都是可观测和受治理的。应将其视为管理数字化员工:成功较少取决于单个智能体,而更多取决于协同、通过智能体注册表确立的清晰权责归属、人类监督以及对整个团队而非局部进行评估。 |
| architectures/operations-center@zh | 运维中心是一个智能体化(agentic)的 AIOps 系统,它监控监控信号和告警,对其进行关联和分诊,诊断可能的根本原因,并仅执行经过审核的运行手册(runbook)修复程序——将破坏性或新颖的操作置于人工审批之后。它通过自动执行安全的、以只读为主的诊断,同时将高风险的写入操作升级给值班工程师,从而减轻告警疲劳并缩短平均恢复时间(MTTR)。每项操作都经过审计且可逆。成功的衡量标准是诚实地评估 MTTR、错误操作率和升级精准度,而不是自动化执行的数量。 |
| architectures/agentic-immune-system@zh | 一套参考架构,用于在企业中运行 AI 智能体而不把信任集中于其中任何一个。身份、最小权限、围堵、监督与恢复这五层,假定总有某个智能体终将出错或被劫持,并让那一天变得可以承受而非灾难性的。防御的单位是单次运行,而不是整支队伍。 |
| governance/eu-ai-act@en | The EU AI Act is the European Union's comprehensive, risk-based law for artificial intelligence. It sorts AI systems into risk tiers — unacceptable (banned), high-risk (strict obligations), limited-risk (transparency duties) and minimal-risk — and adds specific obligations for ge |
| governance/iso-42001@en | ISO/IEC 42001:2023 is the first international, certifiable standard for an AI management system (AIMS). Like ISO 27001 for information security, it defines how an organization should establish, implement, maintain and continually improve the way it governs AI — through a policy, |
| governance/nist-ai-rmf@en | The NIST AI RMF 1.0 is a voluntary, widely-adopted framework for managing AI risk across the lifecycle. It is organized around four functions — Govern, Map, Measure and Manage — and a set of characteristics of trustworthy AI (valid and reliable, safe, secure and resilient, accoun |
| governance/agentic-ai-governance-checklist@en | A practical, vendor-neutral checklist for governing agentic AI in the enterprise — translating the principles of the EU AI Act, ISO/IEC 42001 and NIST AI RMF into concrete controls you can implement in a harness. It covers human oversight, guardrails, audit logging, evaluation, a |
| governance/enterprise-ai-governance-framework@en | An umbrella operating model for governing AI across an organization. It defines the principles, accountability (RACI), AI risk taxonomy, lifecycle gates and policy hierarchy that keep AI use lawful, safe and aligned with risk appetite. It harmonizes the EU AI Act, ISO/IEC 42001 a |
| governance/audit-framework-for-agentic-systems@en | A practical, vendor-neutral framework for making an agent auditable and for auditing it. It defines the evidence an independent reviewer needs — immutable, correlated traces of every decision and tool call, model and version provenance, evaluation reports, approval and incident r |
| governance/human-oversight-and-accountability-policy@en | An operational policy that turns EU AI Act Article 14 human oversight into practice for agentic AI. It assigns a named accountable owner per agent, sets the oversight level (in-the-loop, on-the-loop, out-of-the-loop) by risk, and defines intervention, override and stop authority |
| governance/owasp-llm-top10@en | The OWASP Top 10 for LLM Applications is the shared vocabulary for what goes wrong in systems built on language models. It is not a control framework and does not tell you what to implement — it names the vulnerability classes, from prompt injection through excessive agency to un |
| governance/mitre-atlas@en | MITRE ATLAS is the adversary's side of the map. Where OWASP names the vulnerability classes in your application, ATLAS catalogues the tactics and techniques attackers actually use against AI-enabled systems — reconnaissance of a model, gaining access to it, staging an attack, eva |
| governance/eu-ai-act@es | El Reglamento Europeo de IA es la ley integral y basada en riesgo de la Unión Europea para la inteligencia artificial. Clasifica los sistemas de IA en niveles de riesgo —inaceptable (prohibido), alto riesgo (obligaciones estrictas), riesgo limitado (deberes de transparencia) y ri |
| governance/iso-42001@es | ISO/IEC 42001:2023 es la primera norma internacional y certificable para un sistema de gestión de IA (AIMS). Igual que ISO 27001 para la seguridad de la información, define cómo una organización debe establecer, implementar, mantener y mejorar de forma continua la manera en que g |
| governance/nist-ai-rmf@es | El NIST AI RMF 1.0 es un marco voluntario y ampliamente adoptado para gestionar el riesgo de la IA a lo largo de su ciclo de vida. Se organiza en torno a cuatro funciones —Gobernar, Mapear, Medir y Gestionar— y un conjunto de características de IA confiable (válida y fiable, segu |
| governance/agentic-ai-governance-checklist@es | Un checklist práctico y neutral para gobernar la IA agéntica en la empresa, que traduce los principios del EU AI Act, ISO/IEC 42001 y NIST AI RMF en controles concretos que puedes implementar en un harness. Cubre supervisión humana, guardarraíles, registro de auditoría, evaluació |
| governance/enterprise-ai-governance-framework@es | Un modelo operativo paraguas para gobernar la IA en toda la organización. Define los principios, la rendición de cuentas (RACI), la taxonomía de riesgo de IA, las puertas de ciclo de vida y la jerarquía de políticas que mantienen el uso de IA legal, seguro y alineado con el apeti |
| governance/audit-framework-for-agentic-systems@es | Un marco práctico y neutral para hacer un agente auditable y para auditarlo. Define la evidencia que necesita un revisor independiente —trazas inmutables y correlacionadas de cada decisión y llamada a herramienta, procedencia de modelo y versión, informes de evaluación, registros |
| governance/human-oversight-and-accountability-policy@es | Una política operativa que lleva la supervisión humana del Artículo 14 del EU AI Act a la práctica para la IA agéntica. Asigna un responsable nombrado por agente, fija el nivel de supervisión (en el bucle, sobre el bucle, fuera del bucle) según el riesgo y define la autoridad de |
| governance/owasp-llm-top10@es | El OWASP Top 10 para aplicaciones LLM es el vocabulario común de lo que sale mal en sistemas construidos sobre modelos de lenguaje. No es un marco de controles y no dice qué implementar: nombra las clases de vulnerabilidad, de la inyección de prompts al exceso de agencia y al con |
| governance/mitre-atlas@es | MITRE ATLAS es el mapa visto desde el lado del adversario. Donde OWASP nombra las clases de vulnerabilidad de tu aplicación, ATLAS cataloga las tácticas y técnicas que los atacantes usan de verdad contra sistemas con IA —reconocer un modelo, ganar acceso a él, preparar el ataque, |
| governance/eu-ai-act@pt | O Regulamento Europeu de IA é a lei abrangente e baseada em risco da União Europeia para a inteligência artificial. Classifica os sistemas de IA em níveis de risco —inaceitável (proibido), alto risco (obrigações estritas), risco limitado (deveres de transparência) e risco mínimo— |
| governance/iso-42001@pt | A ISO/IEC 42001:2023 é a primeira norma internacional e certificável para um sistema de gestão de IA (AIMS). Assim como a ISO 27001 para a segurança da informação, ela define como uma organização deve estabelecer, implementar, manter e melhorar continuamente a forma como governa |
| governance/nist-ai-rmf@pt | O NIST AI RMF 1.0 é um framework voluntário e amplamente adotado para gerir o risco da IA ao longo do seu ciclo de vida. Organiza-se em torno de quatro funções —Governar, Mapear, Medir e Gerir— e um conjunto de características de IA confiável (válida e confiável, segura, resilien |
| governance/agentic-ai-governance-checklist@pt | Um checklist prático e neutro para governar a IA agêntica na empresa, que traduz os princípios do EU AI Act, ISO/IEC 42001 e NIST AI RMF em controles concretos que você pode implementar num harness. Cobre supervisão humana, guard-rails, registro de auditoria, avaliação, controle |
| governance/enterprise-ai-governance-framework@pt | Um modelo operacional guarda-chuva para governar a IA em toda a organização. Define os princípios, a prestação de contas (RACI), a taxonomia de risco de IA, os portões de ciclo de vida e a hierarquia de políticas que mantêm o uso de IA legal, seguro e alinhado ao apetite de risco |
| governance/audit-framework-for-agentic-systems@pt | Um framework prático e neutro para tornar um agente auditável e para auditá-lo. Define a evidência que um revisor independente precisa — traços imutáveis e correlacionados de cada decisão e chamada de ferramenta, proveniência de modelo e versão, relatórios de avaliação, registros |
| governance/human-oversight-and-accountability-policy@pt | Uma política operacional que leva a supervisão humana do Artigo 14 do EU AI Act à prática para a IA agêntica. Atribui um responsável nomeado por agente, define o nível de supervisão (no laço, sobre o laço, fora do laço) conforme o risco e estabelece a autoridade de intervenção, a |
| governance/owasp-llm-top10@pt | O OWASP Top 10 para aplicações LLM é o vocabulário comum do que dá errado em sistemas construídos sobre modelos de linguagem. Não é um framework de controles e não diz o que implementar: nomeia as classes de vulnerabilidade, da injeção de prompts ao excesso de agência e ao consum |
| governance/mitre-atlas@pt | O MITRE ATLAS é o mapa visto do lado do adversário. Onde o OWASP nomeia as classes de vulnerabilidade da sua aplicação, o ATLAS cataloga as táticas e técnicas que atacantes de fato usam contra sistemas com IA — reconhecer um modelo, obter acesso a ele, preparar o ataque, evadir d |
| governance/eu-ai-act@fr | L'EU AI Act est la législation complète de l'Union européenne sur l'intelligence artificielle, basée sur le risque. Il classe les systèmes d'IA en différents niveaux de risque — inacceptable (interdit), haut risque (obligations strictes), risque limité (devoirs de transparence) e |
| governance/iso-42001@fr | La norme ISO/IEC 42001:2023 est la première norme internationale certifiable pour un système de management de l'IA (SMI). À l'instar de l'ISO 27001 pour la sécurité de l'information, elle définit la manière dont une organisation doit établir, implémenter, maintenir et améliorer c |
| governance/nist-ai-rmf@fr | Le NIST AI RMF 1.0 est un cadre volontaire et largement adopté pour gérer les risques liés à l'IA tout au long de son cycle de vie. Il s'articule autour de quatre fonctions — Gouverner, Cartographier, Mesurer et Gérer (Govern, Map, Measure, Manage) — et d'un ensemble de caractéri |
| governance/agentic-ai-governance-checklist@fr | Une checklist pratique et neutre vis-à-vis des fournisseurs pour gouverner l'IA agentique en entreprise — traduisant les principes de l'EU AI Act, de l'ISO/IEC 42001 et du NIST AI RMF en contrôles concrets à implémenter dans un harness. Elle couvre la supervision humaine, les gua |
| governance/enterprise-ai-governance-framework@fr | Un modèle opérationnel global pour gouverner l'IA au sein d'une organisation. Il définit les principes, la responsabilisation (RACI), la taxonomie des risques liés à l'IA, les jalons de validation du cycle de vie et la hiérarchie des politiques qui garantissent une utilisation de |
| governance/audit-framework-for-agentic-systems@fr | Un cadre pratique et neutre vis-à-vis des fournisseurs pour rendre un agent auditable et pour l'auditer. Il définit les preuves dont un réviseur indépendant a besoin — des traces immuables et corrélées de chaque décision et appel d'outil, la provenance du modèle et de sa version, |
| governance/human-oversight-and-accountability-policy@fr | Une politique opérationnelle qui concrétise la surveillance humaine de l'article 14 de l'EU AI Act pour l'IA agentique. Elle attribue un responsable désigné par agent, définit le niveau de surveillance (dans la boucle, sur la boucle, hors de la boucle) selon le risque, et détermi |
| governance/owasp-llm-top10@fr | L'OWASP Top 10 pour les applications LLM constitue le vocabulaire partagé pour identifier les défaillances des systèmes basés sur des modèles de langage. Il ne s'agit pas d'un cadre de contrôle et il ne prescrit pas ce qu'il faut mettre en œuvre — il nomme les classes de vulnérab |
| governance/mitre-atlas@fr | MITRE ATLAS représente le côté adverse de la carte. Là où OWASP nomme les classes de vulnérabilités de votre application, ATLAS répertorie les tactiques et techniques que les attaquants utilisent réellement contre les systèmes basés sur l'IA — reconnaissance d'un modèle, obtentio |
| governance/eu-ai-act@de | Der EU AI Act ist das umfassende, risikobasierte Gesetz der Europäischen Union für künstliche Intelligenz. Er teilt KI-Systeme in Risikostufen ein – unannehmbar (verboten), hohes Risiko (strenge Auflagen), begrenztes Risiko (Transparenzpflichten) und minimales Risiko – und führt |
| governance/iso-42001@de | ISO/IEC 42001:2023 ist der erste internationale, zertifizierbare Standard für ein KI-Managementsystem (KIMS bzw. AIMS). Ähnlich wie ISO 27001 für Informationssicherheit definiert er, wie eine Organisation die Steuerung von KI etablieren, implementieren, aufrechterhalten und konti |
| governance/nist-ai-rmf@de | Das NIST AI RMF 1.0 is ein freiwilliges, weit verbreitetes Framework für das Management von KI-Risiken über den gesamten Lebenszyklus hinweg. Es ist um vier Kernfunktionen herum organisiert – Govern (Steuern), Map (Abbilden), Measure (Messen) und Manage (Verwalten) – sowie um ein |
| governance/agentic-ai-governance-checklist@de | Eine praktische, herstellerneutrale Checkliste für die Governance agentischer KI im Unternehmen – sie übersetzt die Prinzipien des EU AI Act, der ISO/IEC 42001 und des NIST AI RMF in konkrete Kontrollmechanismen, die Sie in einem Harness implementieren können. Sie deckt menschlic |
| governance/enterprise-ai-governance-framework@de | Ein übergeordnetes Betriebsmodell für die KI-Governance im gesamten Unternehmen. Es definiert die Prinzipien, Verantwortlichkeiten (RACI), die KI-Risikotaxonomie, Lifecycle-Gates und die Richtlinienhierarchie, die sicherstellen, dass die KI-Nutzung rechtmäßig, sicher und im Einkl |
| governance/audit-framework-for-agentic-systems@de | Ein praktisches, herstellerneutrales Framework, um einen Agenten auditierbar zu machen und ihn zu prüfen. Es definiert die Nachweise, die ein unabhängiger Prüfer benötigt – unveränderliche, korrelierte Traces jeder Entscheidung und jedes Tool-Aufrufs, Modell- und Versionsherkunft |
| governance/human-oversight-and-accountability-policy@de | Eine operative Richtlinie, die die menschliche Aufsicht gemäß Artikel 14 des EU AI Act für agentische KI in die Praxis umsetzt. Sie weist jedem Agenten eine namentlich benannte verantwortliche Person zu, legt die Aufsichtsstufe (In-the-Loop, On-the-Loop, Out-of-the-Loop) je nach |
| governance/owasp-llm-top10@de | Die OWASP Top 10 für LLM-Anwendungen sind das gemeinsame Vokabular für Probleme in Systemen, die auf Sprachmodellen basieren. Es handelt sich nicht um ein Kontroll-Framework und es schreibt nicht vor, was implementiert werden muss – es benennt die Schwachstellenklassen, von Promp |
| governance/mitre-atlas@de | MITRE ATLAS ist die gegnerische Seite der Landkarte. Während OWASP die Schwachstellenklassen in Ihrer Anwendung benennt, katalogisiert ATLAS die Taktiken und Techniken, die Angreifer tatsächlich gegen KI-gestützte Systeme einsetzen – Aufklärung eines Modells, Erlangung von Zugrif |
| governance/eu-ai-act@ja | EU AI Actは、欧州連合(EU)による人工知能に関する包括的かつリスクベースの法律です。AIシステムを、許容できないリスク(禁止)、高リスク(厳格な義務)、限定的なリスク(透明性の義務)、最小限のリスクというリスクティアに分類し、汎用AI(GPAI)モデルに対する特定の義務を追加しています。EU市場にAIを投入するすべての主体に域外適用され、数年かけて段階的に施行されます。最も深刻な違反に対しては、世界年間売上高の最大7%に達する制裁金が科されます。 |
| governance/iso-42001@ja | ISO/IEC 42001:2023は、AIマネジメントシステム(AIMS)に関する初の国際的かつ認証可能な規格です。情報セキュリティにおけるISO 27001と同様に、組織がAIガバナンスを確立、実施、維持、および継続的に改善する方法を、方針、定義された役割、リスクおよび影響評価、管理策のセット、およびPlan-Do-Check-Act(PDCA)改善サイクルを通じて定義します。これは任意かつ認証可能であり、組織が責任あるAI管理を実証するための認められた手段を提供します。 |
| governance/nist-ai-rmf@ja | NIST AI RMF 1.0は、ライフサイクル全体でAIリスクを管理するための、自主的かつ広く採用されているフレームワークです。これは、「Govern(統治)」、「Map(位置づけ)」、「Measure(測定)」、「Manage(管理)」の4つの機能と、信頼できるAIの特徴(妥当性と信頼性、安全性、セキュリティと回復力、説明責任と透明性、説明可能性、プライバシー強化、有害なバイアスが管理された公平性)を中心に構成されています。関連する「Generative AI Profile」は、これをGenAIのリスクに適応させています。EU AI法とは異なり法律 |
| governance/agentic-ai-governance-checklist@ja | 企業におけるエージェント型AIを統制するための、実用的かつベンダーニュートラルなチェックリスト。EU AI法、ISO/IEC 42001、NIST AI RMFの原則を、ハーネスに実装可能な具体的なコントロールに変換します。人間による監視、ガードレール、監査ログ、評価、アクセス制御、プロンプトインジェクション対策、インシデント対応をカバーし、各コントロールをそれを具現化するパターンやナレッジユニットにマッピングします。エージェントを本番環境で動作させる前のレディネスゲートとしてご活用ください。 |
| governance/enterprise-ai-governance-framework@ja | 組織全体でAIを統治するための包括的な運用モデルです。AIの利用を合法かつ安全に保ち、リスク許容度に合わせるための原則、責任(RACI)、AIリスク分類、ライフサイクルゲート、およびポリシー階層を定義します。EU AI法、ISO/IEC 42001、NIST AI RMFを1つの内部プログラムに調和させ(一度の準拠でどこでも再利用可能)、エージェント型ガバナンスチェックリストを具体的なコントロールセットとして構成します。これを使用して、本番環境のすべてのAIシステムに指名された所有者、リスク層、および非準拠のデプロイを実際にブロックできるゲートを割り当て |
| governance/audit-framework-for-agentic-systems@ja | エージェントを監査可能にし、実際に監査を行うための、実用的かつベンダーニュートラルなフレームワーク。独立したレビュー担当者が必要とする証拠(すべての意思決定とツール呼び出しの不変かつ関連付けられたトレース、モデルとバージョンのプロベナンス、評価レポート、承認およびインシデントの記録など)を定義し、コントロールのテスト方法や大量の実行データのサンプリング方法を示します。各証拠タイプはISO/IEC 42001およびNIST AI RMFにマッピングされており、監査人はエージェントが管理された境界内に留まっているかを検証できます。後付けではなく、最初から監査 |
| governance/human-oversight-and-accountability-policy@ja | EU AI Act第14条の人間による監視を、エージェント型AI向けに実践へと落とし込む運用ポリシーです。エージェントごとに明確な責任ある所有者を割り当て、リスクに応じて監視レベル(in-the-loop、on-the-loop、out-of-the-loop)を設定し、介入、オーバーライド、停止権限、およびエスカレーションパスを定義します。監視者が有能であり、行動を起こす時間があることを要求し、形骸化(ラバースタンプ)や自動化バイアスを防ぎます。このポリシーは、2つの失敗、すなわち「人間が不在であること」と、エージェントの行動を実際に理解、オーバーライ |
| governance/owasp-llm-top10@ja | 「OWASP LLMアプリケーションのトップ10」は、言語モデル上に構築されたシステムで発生する不具合に関する共通の語彙です。これは管理策フレームワークではなく、何を実装すべきかを指示するものでもありません。プロンプトインジェクションから過剰なエージェンシー、無制限の消費に至るまでの脆弱性クラスを定義することで、チーム、監査人、ベンダーが同じ前提で議論できるようにします。その実用的な価値は、自社のアーキテクチャに対するチェックリストとして、また検出事項を報告する際の共通言語として機能することにあります。 |
| governance/mitre-atlas@ja | MITRE ATLASは、攻撃者側のマップです。OWASPがアプリケーション内の脆弱性クラスを定義するのに対し、ATLASは攻撃者がAI搭載システムに対して実際に使用する戦術(タクティクス)と手法(テクニック)をカタログ化しています。これには、モデルの偵察、アクセス権の獲得、攻撃の準備、防御の回避、データの持ち出しなどが含まれ、MITRE ATT&CKが従来の侵入を整理するのと同じ方法で整理されており、仮説ではなく文書化されたケーススタディに基づいています。 |
| governance/eu-ai-act@zh | EU AI Act 是欧盟针对人工智能制定的全面的、基于风险的法律。它将 AI 系统划分为不同的风险等级——不可接受(禁用)、高风险(严格义务)、有限风险(透明度义务)和极低风险,并对通用 AI 模型增加了特定合规义务。该法案具有域外效力,适用于任何将 AI 引入欧盟市场的主体,并在数年内分阶段实施,对最严重的违规行为处以最高可达全球年营业额 7% 的罚款。 |
| governance/iso-42001@zh | ISO/IEC 42001:2023 是首个针对人工智能管理体系(AIMS)的国际可认证标准。与用于信息安全的 ISO 27001 类似,它定义了组织应如何建立、实施、维护和持续改进其治理 AI 的方式——通过政策、定义的角色、风险和影响评估、一套控制措施以及“策划-实施-检查-处置”(PDCA)改进循环。它是自愿且可认证的,为组织提供了一种公认的方式来证明其负责任的 AI 管理。 |
| governance/nist-ai-rmf@zh | NIST AI RMF 1.0 是一个自愿采用且被广泛接受的框架,用于管理整个生命周期中的 AI 风险。它围绕四个功能展开——治理(Govern)、映射(Map)、测量(Measure)和管理(Manage),以及一套可信 AI 的特征(有效且可靠、安全、安全且有弹性、可问责且透明、可解释、隐私增强以及管理有害偏见的公平性)。配套的生成式 AI 配置文件(Generative AI Profile)使其适用于 GenAI 风险。与《欧盟 AI 法案》不同,它不是法律,但它是运营 AI 治理的通用支柱。 |
| governance/agentic-ai-governance-checklist@zh | 一份实用且不绑定特定厂商的清单,用于在企业中治理智能体 AI —— 将 EU AI Act、ISO/IEC 42001 和 NIST AI RMF 的原则转化为可在支撑系统中实施的具体控制措施。它涵盖了人工监督、护栏、审计日志、评估、访问控制、提示词注入防御和事件响应,并将每项控制措施映射到使其落地运行的模式和知识单元。在允许智能体在生产环境中运行之前,将其用作就绪性闸口。 |
| governance/enterprise-ai-governance-framework@zh | 一个用于在整个组织内治理 AI 的综合运行模型。它定义了原则、问责制(RACI)、AI 风险分类法、生命周期关卡和策略层级,以确保 AI 的使用合法、安全并符合风险偏好。它将《欧盟 AI 法案》(EU AI Act)、ISO/IEC 42001 和 NIST AI RMF 整合为一个内部项目——一次合规,到处复用——并将智能体治理清单作为其具体的控制集。使用它为每个生产环境中的 AI 系统指定明确的所有者、风险层级以及一个能够真正阻止非合规部署的关卡。 |
| governance/audit-framework-for-agentic-systems@zh | 一个实用且不绑定特定厂商的框架,用于使智能体具备可审计性并对其进行审计。它定义了独立审查员所需的证据 —— 每次决策和工具调用的不可变且关联的追踪记录、模型 and 版本溯源、评估报告、审批和事件记录 —— 以及如何测试控制措施和对高吞吐量运行进行抽样。每种证据类型都映射到 ISO/IEC 42001 和 NIST AI RMF,以便审计员能够验证智能体是否保持在其治理边界内。使用它从一开始就设计可审计性,而不是事后弥补。 |
| governance/human-oversight-and-accountability-policy@zh | 一项将 EU AI Act 第 14 条的人工监督要求转化为智能体 AI(agentic AI)实践的运营政策。它为每个智能体分配一名指定的明确责任人,根据风险设定监督级别(人机协同 in-the-loop、人机监视 on-the-loop、人机脱离 out-of-the-loop),并定义干预、覆盖和终止权限以及升级路径。它要求监督人员具备相应能力并有充足的时间采取行动,同时防范流于形式的审批和自动化偏见。该政策旨在防止两种失败情况:人员缺位,以及无法真正理解、覆盖智能体行为或为其负责的“工具人”式监督。 |
| governance/owasp-llm-top10@zh | OWASP LLM 应用十大安全漏洞是针对基于语言模型构建的系统中可能出现的问题的通用词汇表。它不是一个控制框架,也不会告诉你应该实现什么——它命名了漏洞类别,从提示词注入、过度授权到无限制消耗,以便团队、审计人员和供应商能够基于相同的概念进行讨论。它的实用价值在于作为您自身架构的核对清单,以及作为报告发现问题时的通用语言。 |
| governance/mitre-atlas@zh | MITRE ATLAS 是对抗视角的防御地图。如果说 OWASP 命名了应用程序中的漏洞类别,那么 ATLAS 则编目了攻击者实际针对 AI 系统所使用的战术和技术——包括模型侦察、获取访问权限、策划攻击、规避防御、外发数据等。它按照 MITRE ATT&CK 组织传统入侵的方式进行组织,并基于已记录的案例研究而非假设。 |
| handbook/HRN-001@en | Harness Engineering is the emerging discipline of building reliable agentic systems for enterprise environments — the engineered scaffolding of memory, tools, orchestration, observability, evaluation, governance, and security that surrounds the model. |
| handbook/HRN-002@en | How the field moved from prompt engineering to tool use to agents to harnesses, and why the engineered scaffolding around the model became its own discipline. |
| handbook/HRN-003@en | A structured taxonomy of the harness — memory, tools, planning, orchestration, observability, evaluation, governance, and security — naming each component, its responsibility, and how the parts compose into a reliable agentic system. |
| handbook/HRN-004@en | The core engineering principles of the harness — reliability over capability, determinism boundaries, observability-first, evidence-first, defense in depth, least authority, graceful degradation, and idempotent actuation — that hold across every component. |
| handbook/HRN-005@en | How the harness governs what the model sees and remembers — working, short-term, and long-term memory; the context window as a budget; retrieval, compression, and deliberate forgetting. |
| handbook/HRN-006@en | How to make a non-deterministic, multi-step agent inspectable — traces and spans, token and cost accounting, evaluation hooks, and deterministic replay — so the system can be debugged, measured, and trusted. |
| handbook/HRN-007@en | How to measure whether an agent is actually good and getting better — offline and online evaluation, golden sets, LLM-as-judge, regression suites, and task-completion metrics — turning agent development from craft into engineering. |
| handbook/HRN-008@en | Governance is an engineered harness layer that enforces policy, approvals, and guardrails at runtime, turning enterprise AI obligations into executable controls that gate every agent action. |
| handbook/HRN-009@en | Planning and goal management is the harness layer that decomposes goals into executable plans, represents and tracks plan state, and replans under failure, making agent autonomy directed rather than reactive. |
| handbook/HRN-010@en | Orchestration is the harness layer that drives execution—single vs multi-agent topologies, supervisor/worker delegation, routing, state machines, and durable workflows—turning a plan into reliable, resumable action. |
| handbook/HRN-011@en | Security for agentic systems is the harness layer that defends against prompt injection, sandboxes tools and permissions, prevents data exfiltration, and enforces agent identity and least privilege across every action. |
| handbook/HRN-012@en | Three representative, anonymized composite case studies showing how harness layers—memory, planning, orchestration, governance, security, observability—combine end-to-end to make enterprise agents reliable. |
| handbook/HRN-013@en | A canonical glossary of Harness Engineering and agentic-systems terminology—harness, agent, tool, orchestration, evaluation, span, RAG, MCP, guardrail, and more—with crisp, citable definitions. |
| handbook/HRN-014@en | A curated, themed reading list for Harness Engineering—agents and orchestration, evaluation, security, governance and standards, and protocols—covering foundational papers, industry writeups, and regulatory frameworks. |
| handbook/HRN-001@es | La Ingeniería de Harness es la disciplina emergente que construye sistemas agénticos fiables para entornos empresariales: el andamiaje de ingeniería —memoria, herramientas, orquestación, observabilidad, evaluación, gobernanza y seguridad— que rodea al modelo. |
| handbook/HRN-002@es | Cómo la industria pasó de la ingeniería de prompts a los sistemas agénticos, y por qué el andamiaje alrededor del modelo acabó siendo la disciplina que decide la fiabilidad. |
| handbook/HRN-003@es | Descomposición precisa de los componentes del harness —memoria, herramientas, planificación, orquestación, observabilidad, evaluación, gobernanza y seguridad— y de cómo encajan entre sí. |
| handbook/HRN-004@es | Los principios de ingeniería que se sostienen en todos los componentes del harness: frontera de determinismo, autoridad acotada, degradación elegante y medición antes que optimización. |
| handbook/HRN-005@es | Qué ve el modelo y qué no: recuperación, compresión de contexto, memoria de trabajo y de largo plazo, y las decisiones de olvido que determinan coste y calidad. |
| handbook/HRN-006@es | Convertir cada paso del agente en una traza reproducible: spans, atribución de coste, depuración de bucles no deterministas y las señales que hacen medible la fiabilidad. |
| handbook/HRN-007@es | Cómo pasar de «parece que funciona» a calidad medida y protegida frente a regresiones: conjuntos de evaluación, jueces, métricas de tarea y evaluación continua en producción. |
| handbook/HRN-008@es | Traducir la política en controles aplicados: aprobaciones humanas, trazabilidad, identidad del agente y rendición de cuentas exigibles en un entorno regulado. |
| handbook/HRN-009@es | Descomposición de objetivos, gestión de subobjetivos y replanificación: cuándo deja el harness decidir al modelo y cuándo fija el camino en código. |
| handbook/HRN-010@es | El bucle que gobierna el sistema: quién llama al modelo, con qué contexto, qué ocurre con la salida, y cómo se coordinan varios agentes sin perder control ni trazabilidad. |
| handbook/HRN-011@es | Tratar al modelo como componente no confiable y manipulable: inyección de prompts, exfiltración por herramientas, límites de autoridad y defensa en profundidad del harness. |
| handbook/HRN-012@es | Tres casos compuestos y anonimizados analizados por su harness: qué falló, qué control lo habría evitado y qué se aprendió al llevarlos a producción. |
| handbook/HRN-013@es | Definiciones canónicas de los términos de Ingeniería de Harness usados en todo el manual, para que el vocabulario no derive entre capítulos. |
| handbook/HRN-014@es | Fuentes, literatura de referencia y observaciones de industria en las que se apoya el manual de Ingeniería de Harness. |
| handbook/HRN-001@pt | A Engenharia de Harness é a disciplina emergente que constrói sistemas agênticos confiáveis para ambientes empresariais: o andaime de engenharia — memória, ferramentas, orquestração, observabilidade, avaliação, governança e segurança — que rodeia o modelo. |
| handbook/HRN-002@pt | Como a indústria passou da engenharia de prompts para os sistemas agênticos, e porque o andaime em torno do modelo acabou por ser a disciplina que decide a confiabilidade. |
| handbook/HRN-003@pt | Decomposição precisa dos componentes do harness — memória, ferramentas, planejamento, orquestração, observabilidade, avaliação, governança e segurança — e de como encaixam entre si. |
| handbook/HRN-004@pt | Os princípios de engenharia que se sustentam em todos os componentes do harness: fronteira de determinismo, autoridade limitada, degradação graciosa e medição antes da otimização. |
| handbook/HRN-005@pt | O que o modelo vê e o que não vê: recuperação, compressão de contexto, memória de trabalho e de longo prazo, e as decisões de esquecimento que determinam custo e qualidade. |
| handbook/HRN-006@pt | Transformar cada passo do agente num traço reproduzível: spans, atribuição de custo, depuração de ciclos não determinísticos e os sinais que tornam a confiabilidade mensurável. |
| handbook/HRN-007@pt | Como passar de “parece que funciona” para qualidade medida e protegida contra regressões: conjuntos de avaliação, juízes, métricas de tarefa e avaliação contínua em produção. |
| handbook/HRN-008@pt | Traduzir a política em controles aplicados: aprovações humanas, rastreabilidade, identidade do agente e prestação de contas exigíveis num ambiente regulado. |
| handbook/HRN-009@pt | Decomposição de objetivos, gestão de subobjetivos e replanejamento: quando o harness deixa o modelo decidir e quando fixa o caminho em código. |
| handbook/HRN-010@pt | O ciclo que governa o sistema: quem chama o modelo, com que contexto, o que acontece à saída, e como se coordenam vários agentes sem perder controle nem rastreabilidade. |
| handbook/HRN-011@pt | Tratar o modelo como componente não confiável e manipulável: injeção de prompts, exfiltração por ferramentas, limites de autoridade e defesa em profundidade do harness. |
| handbook/HRN-012@pt | Três casos compostos e anonimizados analisados pelo seu harness: o que falhou, que controle o teria evitado e o que se aprendeu ao levá-los para produção. |
| handbook/HRN-013@pt | Definições canônicas dos termos de Engenharia de Harness usados em todo o manual, para que o vocabulário não derive entre capítulos. |
| handbook/HRN-014@pt | Fontes, literatura de referência e observações da indústria em que se apoia o manual de Engenharia de Harness. |
| handbook/HRN-001@fr | >- |
| handbook/HRN-002@fr | >- |
| handbook/HRN-003@fr | >- |
| handbook/HRN-004@fr | >- |
| handbook/HRN-005@fr | >- |
| handbook/HRN-006@fr | >- |
| handbook/HRN-007@fr | >- |
| handbook/HRN-008@fr | >- |
| handbook/HRN-009@fr | >- |
| handbook/HRN-010@fr | >- |
| handbook/HRN-011@fr | >- |
| handbook/HRN-012@fr | >- |
| handbook/HRN-013@fr | >- |
| handbook/HRN-014@fr | >- |
| handbook/HRN-001@de | >- |
| handbook/HRN-002@de | >- |
| handbook/HRN-003@de | >- |
| handbook/HRN-004@de | >- |
| handbook/HRN-005@de | >- |
| handbook/HRN-006@de | >- |
| handbook/HRN-007@de | >- |
| handbook/HRN-008@de | >- |
| handbook/HRN-009@de | >- |
| handbook/HRN-010@de | >- |
| handbook/HRN-011@de | >- |
| handbook/HRN-012@de | >- |
| handbook/HRN-013@de | >- |
| handbook/HRN-014@de | >- |
| handbook/HRN-001@ja | >- |
| handbook/HRN-002@ja | >- |
| handbook/HRN-003@ja | >- |
| handbook/HRN-004@ja | >- |
| handbook/HRN-005@ja | >- |
| handbook/HRN-006@ja | >- |
| handbook/HRN-007@ja | >- |
| handbook/HRN-008@ja | >- |
TDQS
Scored across 41 tools
Tools are mostly partitioned by domain and by list/get/search/calculate/compare/assess patterns, and descriptions explicitly route between global and domain-specific searches. The main overlap is among search, search_all, search_articles and search_physical_ai, plus generic search vs list browsing, but the guidance is strong enough to avoid most misselection.
Uses a predictable snake_case verb_noun convention: list_*, get_*, search_*, calculate_*, compare_*, assess_*. Minor deviations such as bare search/search_all, recommend_model_for_profession and get_related are readable and do not seriously undermine consistency.
41 tools is high for a single MCP server; although the breadth reflects many federated domains, the surface exceeds the 25+ threshold and forces agents to choose among many list/get/search variants. Consolidation via generic domain parameters or grouped endpoints would improve usability.
Coverage is broad: browse/retrieve/search for core units, articles, benchmarks, labs, physical AI, Homeric atlas and claims, plus graph traversal and calculators. Minor gaps exist around model-level retrieval and invoking arbitrary Lab endpoints, but no major workflow dead ends.