Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los agentes declarativos son versiones personalizadas de Microsoft 365 Copilot que le ayudan a crear experiencias personalizadas al declarar instrucciones, acciones y conocimientos específicos. Para escribir instrucciones efectivas para su agente declarativo, considere las siguientes preguntas:
- ¿Qué objetivo debe lograr su agente?
- ¿Por qué flujos de trabajo cree que pasarán sus usuarios finales?
- ¿Hay alguna lógica empresarial que quieras incorporar?
- ¿Hay alguna experiencia deseada del usuario final que desee incorporar?
- ¿Pueden proporcionar instrucciones paso a paso para el agente en cada flujo de trabajo?
Si su agente declarativo también tiene complementos de API como acciones, el documento OpenAPI para su complemento ayuda al agente a comprender cualquier instrucción que se refiera a la API. Para obtener más información, consulte Cómo hacer que un documento OpenAPI sea eficaz para ampliar Copilot.
Esta guía se aplica a los desarrolladores y creadores que usan Agent Builder en Microsoft 365 Copilot o el Kit de herramientas de agentes de Microsoft 365 para crear agentes declarativos. Para obtener más información sobre cómo escribir instrucciones para los agentes de Copilot Studio, consulte Configuración de instrucciones de alta calidad para la orquestación generativa.
Importante
Microsoft 365 Copilot realiza periódicas transiciones a modelos más recientes. Dado que estas actualizaciones son automáticas, espere algún cambio de comportamiento con el tiempo y prepárese para adaptar las indicaciones e instrucciones donde la precisión importa. Los cambios de modelo pueden afectar a la forma en que el agente declarativo entiende y responde a las instrucciones, especialmente en escenarios estructurados o paso a paso.
Componentes de instrucciones
Un conjunto de instrucciones bien estructurado garantiza que el agente comprenda su función, las tareas que debe realizar y cómo interactuar con los usuarios. Los componentes principales de las instrucciones del agente declarativo son:
- Objetivo
- Directrices generales, incluidas direcciones generales, tono y restricciones
- Aptitudes
Cuando sea pertinente, incluya también los siguientes componentes en las instrucciones:
- Instrucciones detalladas
- Control de errores y limitaciones
- Comentarios e iteración
- Ejemplos de interacción
- Términos no estándar
- Seguimiento y cierre
El siguiente diagrama muestra los componentes principales de las instrucciones del agente declarativo.
Importante
No almacene ni descargue instrucciones de agente declarativo en documentos de SharePoint (o cualquier otra fuente de conocimiento) para evitar el límite de instrucciones de 8000 caracteres. El contenido de la fuente de conocimiento no es contenido de instrucciones creado por creadores de confianza y está sujeto a clasificadores de ataques de inyección entre mensajes (XPIA): el lenguaje tipo directiva se puede bloquear, truncar o desinfectar en tiempo de ejecución, lo que provoca un comportamiento impredecible del agente. Este patrón también expande la superficie expuesta a ataques: cualquier persona con acceso de edición al documento al que se hace referencia puede modificar el comportamiento del agente en tiempo de ejecución, sin pasar por alto los controles de creación, control de versiones y gobernanza del manifiesto. Las fuentes de conocimiento están diseñadas para fundamentar respuestas fácticas, no para servir como instrucciones a nivel de sistema, y la plataforma no garantiza que se cumplirán como instrucciones del agente.
Procedimientos recomendados para instrucciones de agente
Usa un lenguaje claro y práctico
- Céntrate en lo que Copilot debe hacer, no en lo que debes evitar.
- Usa verbos precisos y específicos, como "pedir", "buscar", "enviar", "comprobar" o "usar".
- Complemente con ejemplos para minimizar la ambigüedad.
- Defina los términos que no sean estándar o únicos de la organización en las instrucciones.
Crear flujos de trabajo paso a paso con transiciones
Divida los flujos de trabajo en pasos modulares, inequívocos y sin conflictos. Cada paso debe incluir:
- Meta: El propósito del paso.
- Acción: Qué debe hacer el agente y qué herramientas utilizar.
- Transición: criterios claros para pasar al siguiente paso o finalizar el flujo de trabajo.
Usar una estructura estricta
La estructura es una de las señales más fuertes utilizadas para interpretar la intención:
- Use secciones para agrupar las tareas relacionadas en categorías lógicas, sin implicar secuencia.
- Usa viñetas para tareas paralelas que se puedan completar de forma independiente. Evite la numeración que podría introducir un orden no deseado.
- Use pasos para las acciones que deben producirse en una secuencia requerida y resérvelos solo para flujos de trabajo verdaderos.
Hacer que las tareas sean atómicas
Divida las instrucciones de acción múltiple en unidades claramente separadas. Este enfoque reduce la ambigüedad e impide que el modelo combine o reinterprete tareas.
- En lugar de: Extraer métricas y resumir los hallazgos.
- Siga pasos independientes:
- Extraer métricas.
- Resumir los hallazgos.
Especificar siempre el tono, la verbosidad y el formato de salida
Si no especifica el tono y el nivel de detalle, el modelo de lenguaje puede inferir estos atributos, lo que puede conducir a un comportamiento incoherente entre los modelos. Por ejemplo, especifique:
- Tono: profesional y conciso.
- Resultado: tres viñetas por sección.
- Devuelva solo el formato solicitado; Sin explicaciones.
Instrucciones de estructura en Markdown
Para proporcionar énfasis y claridad en el orden de los pasos, use Markdown.
- Use
#,##y###para los encabezados de sección. - Úselo
-para listas no ordenadas y1.para listas numeradas. Use listas no ordenadas a menos que el orden de los pasos sea importante, en cuyo caso, use listas numeradas. - Resalte los nombres de herramientas o sistemas (por ejemplo,
Jira, ,ServiceNowTeams) utilizando comillas invertidas ('''''). - Poner las instrucciones críticas en negrita usando
**.
Los encabezados claros y las estructuras de lista coherentes ayudan al modelo a comprender la jerarquía prevista. Evite mezclar tipos de lista de formas que puedan introducir interpretaciones no deseadas.
Proporcionar vocabulario de dominio
Defina términos especializados, fórmulas, acrónimos y lenguaje específico del conjunto de datos. Esta definición evita la inferencia incorrecta y garantiza una interpretación coherente.
Referencia explícita a funcionalidades, conocimientos y acciones
Indique claramente los nombres de las acciones, capacidades o fuentes de conocimiento involucradas en cada paso.
-
Acciones: por ejemplo, "Se usa
Jirapara capturar vales". -
Conocimiento del conector de Copilot: por ejemplo, "Usar
ServiceNow KBpara artículos de ayuda". - Conocimiento de SharePoint: Por ejemplo, "Referencia a documentos internos de SharePoint o OneDrive".
- Email mensajes: por ejemplo, "Comprueba los correos electrónicos de los usuarios para obtener información relevante".
- Mensajes de Teams: por ejemplo, "buscar en el historial de chats de Teams".
- Intérprete de código: por ejemplo, "Usar el intérprete de código para generar gráficos de barras o circulares".
- People knowledge: Por ejemplo, "Use el conocimiento de las personas para obtener el correo electrónico del usuario".
Respuestas terrestres a fuentes de conocimiento configuradas
Los modelos de lenguaje tienen conocimiento integrado de sus datos de entrenamiento. En muchos escenarios de agente, desea que el agente confíe solo en los orígenes de conocimiento que configure, no en el conocimiento interno del modelo. Este enfoque garantiza que las respuestas sean precisas, coherentes y rastreables a los datos de la organización.
La forma recomendada de evitar que el modelo recurra a su conocimiento integrado es establecer la discourage_model_knowledge propiedad true en el special_instructions objeto del manifiesto del agente. Cuando se habilita, el agente hace todo lo posible para evitar generar respuestas a partir del conocimiento del modelo y, en su lugar, se basa en las fuentes de conocimiento configuradas. Para obtener más información, consulte el objeto Instrucciones especiales.
Proporcionar ejemplos
Los ejemplos ayudan al agente a comprender las instrucciones.
- Para escenarios sencillos, no es necesario dar ejemplos.
- Para escenarios complejos, los agentes declarativos funcionan mejor con indicaciones de pocos disparos. Es decir, dar más de un ejemplo para ilustrar diferentes aspectos o casos extremos.
Controlar el razonamiento a través de la redacción
Su redacción indica cuánto razonamiento desea que aplique el modelo.
Razonamiento profundo
Para aumentar la profundidad:
- Usar verbos de razonamiento explícitos (analizar, derivar, evaluar, justificar).
- Agregue señales de metarazonamiento (piense paso a paso, reflexione, verifique la lógica).
- Estructurar las tareas en varios pasos dependientes.
Use deep reasoning. Break the problem into steps, analyze each step, evaluate alternatives, and justify the final decision. Reflect before answering.
Task: Determine the optimal 3-year migration strategy given constraints A, B, and C.
Para detectar cuándo se seleccionó el razonamiento profundo:
Before answering, report in one sentence whether you needed deep reasoning or minimal reasoning to solve this. Then provide the final answer only.
Razonamiento moderado (equilibrado)
Para equilibrar el razonamiento:
- Pide una explicación concisa pero estructurada.
- Proporcione restricciones claras, pero no señales de metarazonamiento.
Provide a concise but structured explanation. Include a short summary, 3 key drivers, and a final recommendation. No step-by-step reasoning required.
Task: Explain the tradeoffs between solution X and Y.
Razonamiento rápido y mínimo
Para reducir la profundidad:
- Brevedad de la señal. Especificar una respuesta corta y rápida; sin razonamiento / explicación.
- Evite los verbos analíticos y las estructuras de varios pasos.
- Utilice frases imperativas de una sola intención y una sola fase.
Short answer only. No reasoning or explanation. Provide the final result only.
Task: Extract the product name and renewal date from this paragraph.
Evitar errores comunes de aviso
Tenga en cuenta los siguientes escollos y sus soluciones para evitar fallas comunes.
-
Uso excesivo de herramientas
- Problema: El modelo llama a herramientas sin las entradas necesarias.
- Solución: Agregar instrucción "Solo llame a la herramienta si hay entradas necesarias disponibles; de lo contrario, pregúntele al usuario".
-
Frases repetitivas
- Problema: El modelo reutiliza textualmente las frases de ejemplo.
- Solución: fomentar respuestas variadas y lenguaje natural. Considere agregar más de un ejemplo en lugar de solo uno (solicitud de pocos disparos). Experimente quitando el ejemplo para ahorrar tokens.
-
Explicaciones detalladas
- Problema: El modelo explica en exceso o proporciona un formato excesivo.
- Solución: Para limitar la verbosidad o el formato, agregue restricciones y ejemplos concisos.
Agregar un paso final de autoevaluación
Un paso de autocomprobación refuerza la integridad y garantiza que el agente verifique la alineación con sus instrucciones antes de responder. Por ejemplo: antes de finalizar, confirme que todos los elementos de la sección A aparecen en el resumen.
Aplique un encabezado estabilizador cuando sea necesario
Cuando un agente muestra signos de deriva de inferencia o reordenación de pasos, agregue un encabezado corto que indique al modelo que interprete las instrucciones literalmente y evite la inferencia. Para obtener más información, vea Patrón 8: aplicar un encabezado de ejecución literal para estabilidad inmediata.
Repite tus instrucciones
El desarrollo de instrucciones para agentes declarativos es a menudo un proceso iterativo. Por lo general, consta de los siguientes pasos:
- Cree instrucciones y temas de conversación para su agente siguiendo la estructura y el formato descritos en este artículo.
- Publique su agente. Las prácticas de IA responsable (RAI) se integran en el proceso de validación para garantizar que los agentes respeten los estándares éticos. Para más información, vea:
-
Prueba a tu agente.
- Para confirmar que el agente aporta valor añadido al responder, compare los resultados con Microsoft 365 Copilot.
- Compruebe que los temas de conversación funcionan según lo previsto con la guía paso a paso.
- Compruebe que el agente actúa de acuerdo con las instrucciones proporcionadas.
- Confirme que las consultas de usuario fuera de los inicios de la conversación se controlan correctamente.
-
Siga las instrucciones para explorar si puede mejorar aún más el resultado.
- Modifique las instrucciones para cambiar el comportamiento del agente.
- Intente agregar conocimientos como búsqueda web, OneDrive/SharePoint o conectores de Microsoft 365 Copilot, si es necesario mediante Agents Toolkit o Copilot Studio.
El siguiente diagrama ilustra el proceso iterativo para crear y refinar instrucciones de agente declarativo.
Sugerencia
Work IQ Dev Tools (versión preliminar) — Work IQ Dev Tools admite la creación de evaluaciones para agentes declarativos para que pueda medir cómo los cambios en las instrucciones afectan el comportamiento de los agentes. Cree evaluaciones para los comportamientos que desea probar y ejecútelas con un agente aprovisionado a medida que refina sus instrucciones. Para obtener más información, consulte la documentación de Dev Tools de Work IQ.
Instrucciones de ejemplo
Las siguientes instrucciones de ejemplo son para un agente que puede ayudar a resolver problemas comunes de TI.
# OBJECTIVE
Guide users through issue resolution by gathering information, checking outages, narrowing down solutions, and creating tickets if needed. Ensure the interaction is focused, friendly, and efficient.
# RESPONSE RULES
- Ask one clarifying question at a time, only when needed.
- Present information as concise bullet points or tables.
- Avoid overwhelming users with details or options.
- Always confirm before moving to the next step or ending.
- Use tools only if data is sufficient; otherwise, ask for missing info.
# WORKFLOW
## Step 1: Gather Basic Details
- **Goal:** Identify the user's issue.
- **Action:**
- Proceed if the description is clear.
- If unclear, ask a single, focused clarifying question.
- Example:
User: "Issue accessing a portal."
Assistant: "Which portal?"
- **Transition:** Once clear, proceed to Step 2.
## Step 2: Check for Ongoing Outages
- **Goal:** Rule out known outages.
- **Action:**
- Query `ServiceNow` for current outages.
- If an outage is found:
- Share details and ETA.
- Ask: "Is your issue unrelated? If yes, I can help further."
- If yes, go to Step 3. If no/no response, end politely.
- If none, inform the user and go to Step 3.
## Step 3: Narrow Down Resolution
- **Goal:** Find best-fit solutions from the knowledge base.
- **Action:**
- Search `ServiceNow KB` for related articles.
- **Iterative narrowing:** Don't list all results. Instead:
- Ask clarifying questions based on article differences.
- Eliminate irrelevant options with user responses.
- Repeat until the best solution is found.
- Provide step-by-step fix instructions.
- Confirm: "Did this help? If not, I can go deeper or create a ticket."
- If more info is provided, repeat this step.
- If ticket needed, go to Step 4.
- If resolved/no response, end politely.
## Step 4: Create Support Ticket
- **Goal:** Log unresolved issues.
- **Action:**
1. Map **category** and **subcategory** from the `sys_choice` SharePoint file.
- Use only valid pairs. Leave blank if not clear.
2. Fetch user's UPN (email) with the people capability.
3. Fill the ticket with:
- Caller ID (email)
- Category, Subcategory (if mapped)
- Description, attempted steps, error codes, metadata
- **Transition:** Confirm ticket creation and next steps.
# OUTPUT FORMATTING RULES
- Use bullets for actions, lists, next steps.
- Use tables for structured data where UI allows.
- Avoid long paragraphs; keep responses skimmable.
- Always confirm before ending or submitting tickets.
# EXAMPLES
## Valid Example
**User:** "I can't connect to VPN."
**Assistant:**
- "Are you seeing a specific error?"
(User: "DNS server not responding.")
- "Let me check for outages."
(No outage.)
- "No outages. Searching knowledge base…"
(Finds articles. Asks: "Are you on office Wi-Fi or home?")
(User: "Home.")
- "Try resetting your DNS settings. Here's how…"
- "Did this help? If not, I can create a support ticket."
## Invalid Example
- "Here are 15 articles I found…" *(Overwhelms the user)*
- "I'm raising a ticket" *(without confirming details)*
Plantillas de instrucciones y patrones de diseño
Esta sección proporciona patrones y plantillas que puede agregar a las instrucciones del agente declarativo. Los ejemplos mostrados no son prescriptivos. Utilícelos como punto de partida y adáptelos a los requisitos de su caso de uso.
Patrón 1: Convertir solicitudes ambiguas a varias tareas en flujos de trabajo deterministas
Con este patrón, se elimina la ambigüedad definiendo pasos atómicos, fórmulas explícitas y validación necesaria. Este enfoque garantiza un comportamiento estable y repetible en todas las versiones del modelo.
## Task: Metrics and ROI (Deterministic)
### Definitions (Do not invent)
- Metrics to compute: [Metric1], [Metric2], [Metric3]
- ROI definition: ROI = (Benefit - Cost) / Cost
- ROI scope: [e.g., 12 months, Product X only, Region Y]
- Source of truth: Use ONLY the provided document(s) for inputs
### Steps (Sequential — do not reorder)
Step 1: Locate inputs for [Metric1-3] in the document. Quote the section/table name where each input came from.
Step 2: Compute [Metric1-3] exactly as defined above. If any input is missing, stop and ask ONE question listing what's missing.
Step 3: Compute ROI using the ROI definition above. Do not substitute other ROI formulas.
Step 4: Output ONLY the table in the format below.
### Output format
Return a single Markdown table with columns: Metric | Value | Source (section/table) | Notes
### Final check (Self-evaluation)
Before finalizing: confirm every metric has (a) a value, (b) a source, and (c) no assumptions. If assumptions exist, stop and ask the user.
Patrón 2: Estructura paralela versus secuencial correcta
Al usar este patrón, se asegura de que el modelo separa la lógica paralela y secuencial. El modelo ejecuta flujos de trabajo correctamente sin agregar ni reordenar pasos.
Section A — Extract Data
- Extract pricing changes.
- Extract margin changes.
- Extract sentiment themes.
Section B — Build the Summary
Step 1: Integrate all findings from Section A.
Step 2: Produce the 2 page call prep summary.
Patrón 3: Reglas de decisión explícitas
Con este patrón, se agregan reglas explícitas para el caso si/entonces que impiden la interpretación no deseada del modelo y aplican resultados deterministas. Este enfoque impide que el modelo de lenguaje intente resolver la lógica condicional ambigua por sí mismo, lo que puede dar lugar a ramas combinadas ("hacer ambas cosas") o a la selección de la ruta condicional incorrecta.
Read the product report.
Check category performance.
If performance is stable or improving, write the summary section.
If performance declines or anomalies are detected, write the risks/issues section.
Patrón 4: Contrato de salida
Los contratos de salida proporcionan forma, estructura, tono y contenido permitido, lo que garantiza la coherencia. Sin restricciones de salida explícitas, el agente puede producir explicaciones demasiado largas, respuestas demasiado concisas o cambiar de forma impredecible entre versiones.
Buena precisión:
Produce a 2-page call-prep briefing:
Page 1 → key metrics: revenue, margin, YoY deltas (calculate as needed).
Page 2 → top themes, risks, opportunities, customer signals.
Tone: Professional. Reasoning: none unless calculation required.
Contrato de salida:
## Output Contract (Mandatory)
Goal: [one sentence]
Format: [bullet list | table | 2 pages | JSON]
Detail level: [short | medium | detailed] — do not exceed [X] bullets per section
Tone: [Professional | Friendly | Efficient]
Include: [A, B, C]
Exclude: No extra recommendations, no extra context, no “helpful tips”
Example shape:
- Section 1: ...
- Section 2: ...
Use este patrón cuando el resultado deba seguir:
- Un formato preciso (viñetas, tabla, JSON, resumen de varias páginas).
- Un nivel de detalle especificado (corto, medio, detallado).
- Una plantilla de cumplimiento, auditoría o orientada al cliente.
- Un proceso empresarial que requiere un formato coherente en todos los equipos.
Patrón 5: Estructura de Markdown limpia
Markdown limpio e intencionado garantiza que el modelo pueda analizar tus instrucciones de forma fiable. Las listas mal anidadas, los encabezados poco claros o el formato incoherente provocan pasos combinados, jerarquías no deseadas o secciones contraídas.
## Section A — Extract Data
- Extract pricing changes.
- Extract margin changes.
- Extract sentiment themes.
## Section B — Build the Summary (Sequential)
**Step 1:** Integrate findings from Section A.
**Step 2:** Produce the 2 page call prep summary.
Patrón 6: Puerta de autoevaluación
Al agregar un paso de autocomprobación explícito, anima al modelo a validar la integridad, comprobar la alineación con las instrucciones y corregir las omisiones antes de responder. Este paso aumenta la coherencia y la confiabilidad.
## Section A: Extract Data (Non-Sequential)
Perform these tasks when the user requests data extraction from the document:
- Extract pricing changes.
- Extract margin changes.
- Extract sentiment themes.
Use the **Vocabulary Reference** SharePoint document to interpret acronyms, domain specific terms, and company specific vocabulary.
## Section B: Build the Summary (Sequential)
Perform these steps **in order** when the user requests a call prep summary:
Step 1: Integrate all extracted elements from Section A.
Step 2: Produce a clear, well structured 2 page call prep summary.
## Final Check: Self Evaluation
Before finalizing the output, review your response for completeness, ensure that all Section A elements are accurately represented, check for inconsistencies or uncertainty, and revise the answer if needed.
Patrón 7: Razonamiento de modo automático de dirección
Las señales de razonamiento explícito le dan control sobre cuánto pensamiento se aplica el modelo. Sin esta orientación, tu agente podría explicar en exceso las respuestas sencillas o subestimar las decisiones complejas.
Desencadenar un razonamiento profundo:
Use deep reasoning. Break the problem into steps, analyze each step, evaluate alternatives, and justify the final decision. Reflect before answering.
Task: Determine the optimal 3-year migration strategy given constraints A, B, and C.
Forzar un razonamiento rápido y mínimo:
Short answer only. No reasoning or explanation. Provide the final result only.
Task: Extract the product name and renewal date from this paragraph.
Use este patrón cuando el flujo de trabajo requiera:
- Razonamiento más profundo (planificación, evaluación de alternativas, lógica de varios pasos).
- Recuperación rápida o extracción con una explicación mínima.
- Cambiar entre resúmenes de alto nivel y análisis más profundos.
- Profundidad consistente en múltiples agentes o casos de uso.
Patrón 8: Aplicar un encabezado de ejecución literal para estabilidad inmediata
Un encabezado de ejecución literal ayuda a estabilizar temporalmente un agente existente. Este patrón es especialmente útil como corrección provisional mientras se actualiza el conjunto de instrucciones completo.
Always interpret instructions literally.
Never infer intent or fill in missing steps.
Never add context, recommendations, or assumptions.
Follow step order exactly with no optimization.
Respond concisely and only in the requested format.
Do not call tools unless a step explicitly instructs you to do so.
Use este patrón cuando:
- Observa reordenamientos, pasos agregados o razonamiento excesivo en las respuestas de su agente.
- Necesita una mitigación rápida a corto plazo antes de aplicar mejoras estructurales más profundas.
- Desea diagnosticar si la ambigüedad de inferencia o instrucción es la causa del problema.
Patrón 9: Evaluar las instrucciones de agente declarativo existentes
Use una solicitud de evaluación estructurada para auditar rápidamente un agente existente, identificar debilidades específicas y generar correcciones precisas.
You are reviewing Data Access (DA) agent instructions for stability.
INPUT
<instructions>
[PASTE CURRENT INSTRUCTIONS]
</instructions>
TASK
Concise audit. Identify ONLY issues and exact fixes.
CHECKS
- Step order: identify ambiguity, missing steps, or merged steps → propose atomic, numbered steps.
- Tool use: identify auto-calls, retries, or tool switching → add "use only in step X; no auto-retry".
- Grounding: detect inference, blending, or citation gaps → add "cite only retrieved; no inference; no cross-document stitching".
- Missing-data handling: if retrieval is empty or conflicting → add "stop and ask the user".
- Verbosity: identify chatty or explanatory output → replace with "return only the requested data/format".
- Contradictions or duplicates: resolve discrepancies; prefer explicit over implied.
- Vague verbs ("verify", "process", "handle", "clean"): replace with precise, observable actions.
- Safety: prohibit step reordering, optimization, or reinterpretation.
OUTPUT (concise)
- Header patch (3–6 lines)
- Top 5 changes (bullet list: "Issue → Fix")
- Example rewrite (≤10 lines) for the riskiest step
Use este patrón cuando:
- Está auditando a un agente existente que se comporta de forma incoherente.
- No está seguro de qué partes del conjunto de instrucciones son frágiles o ambiguas.
- Desea un proceso de evaluación repetible para varios agentes declarativos en toda la organización.
- Necesita una forma rápida de identificar qué problemas son estructurales, estilísticos o de seguridad.