Recherche multi-perspectives
Une recherche plate répond à « que dit le web sur X ? ». Cette compétence répond à « quelles parties de X sont corroborées de manière indépendante, et lesquelles ne reposent que sur une seule source ? ».
Le mécanisme, abstrait de STORM de Stanford (vérifié par rapport à la source stanford-oval/storm) :
(perspectives × budget) → récupérer → (preuve | refus) → réécrire → redemander
répéter M tours, N+1 voies indépendantes, convergence à la fin
↓
working-report.md (mécanisme visible, piste d'audit)
↓
reader-report.md (mécanisme invisible, le produit)
↓
réponse à l'utilisateur = reader-report.md textuellement, rien ajouté
Toute la valeur réside dans quatre aspects que la plupart des tentatives de recherche ignorent : les perspectives doivent provenir de l'extérieur du modèle, chaque question doit se concrétiser par une recherche réelle, la convergence doit être notée, pas supposée, et le résultat noté doit ensuite survivre à une lecture par quelqu'un qui n'était pas présent.
Quand déclencher
Déclenchez cette compétence sur toute expression suivante, provenant des propres mots de l'utilisateur — l'utilisateur n'a jamais besoin de nommer la compétence :
- Mots-clés explicites : 深度调研 / 深度研究 / 深度分析 / 深入研究 / deep-research / deep research / deep dive / 深入调研.
- Demandes avec adverbes de qualité : 仔细调研 / 认真调研 / 调研得仔细一点 / 多查几个来源 / 别只给一个来源 / 要确定性结论 / 确定性调研 / 查得踏实一点 / 帮我彻底搞清楚 X / 把 X 查透 / X 到底怎么样 / 不要泛泛而谈.
- Demandes de méthode : 多维度调研 / 多视角 / 全景分析 / 正反双方梳理 / 交叉验证 / 多方观点对比 / 交叉比对来源 / 标注"哪些结论有多来源印证、哪些只有单一来源".
- Forme implicite : toute demande de recherche où l'utilisateur signale qu'une réponse unique ne suffit pas.
Règle de chevauchement : anysearch et agent-reach sont propriétaires des 调研/搜索/查一下 génériques (ils sont les moteurs de récupération et cette compétence les utilise comme outils). Dès que la demande comporte un qualificatif de profondeur / soin / certitude / validation croisée, cette compétence est propriétaire de la demande et pilote ces moteurs à l'intérieur de ses voies. En cas de doute, préférez cette compétence : le coût d'une recherche excessive est le temps, le coût d'une recherche insuffisante est une réponse fausse avec assurance.
Pas pour : les vérifications ponctuelles rapides de faits, "查一下这个 API 是什么", ou les consultations d'une seule page.
Les deux artefacts
Les étapes 1 à 5 produisent un rapport de travail : un artefact à mécanisme visible où voie, A–E, requête, tour et les phrases d'orthogonalité constituent l'essentiel. Il est correct, et illisible pour quiconque ne l'a pas exécuté.
L'étape 6 produit le rapport lecteur : ce que vous remettez réellement. Mêmes preuves, même honnêteté, mêmes sources — mais la mécanique a disparu et la structure est reconstruite autour de ce dont un lecteur a besoin pour prendre une décision.
Conservez les deux artefacts, et ne laissez jamais l'étape 6 remplacer l'étape 5.
- Le rapport de travail est la piste d'audit : c'est ce qui vous permet (à vous ou à une passe ultérieure) de vérifier qu'aucune affirmation n'a dérivé, qu'aucun niveau n'a été amélioré et qu'aucune ligne vide n'a été remplie de mémoire. Il est écrit dans un fichier (par exemple
working-report.md) et n'est jamais collé dans la réponse. - Le rapport lecteur est le livrable, enregistré sous
reader-report.md: c'est ce qu'une personne peut réellement utiliser, en une seule fois, sans glossaire.
Règle de livraison (stricte) : la réponse finale à l'utilisateur est le contenu textuel et complet de reader-report.md — rien ajouté, rien modifié, rien enveloppé autour. Voir §Livraison ci-dessous. Pas de préambule ("J'ai terminé, voici le rapport"), pas de signature, pas de résumé, pas de ligne de vérification, pas de commentaire décrivant ce que vous avez fait ou quels fichiers existent. Lisez le fichier et émettez exactement ses octets comme corps de votre message. Tout ce que vous souhaitez ajouter appartient au rapport de travail, pas à la réponse.
Fusionner les deux en un seul document échoue dans les deux sens. Gardez la mécanique et les lecteurs rebondissent ; retirez la mécanique sans les règles de l'étape 6 et la validation croisée disparaît silencieusement — le lecteur ne peut plus distinguer « quatre chemins indépendants se sont rencontrés ici » de « un coup de chance répété », ce qui était l'objectif même de la compétence.
Non-négociables
- Les perspectives sont lues, pas inventées. Vous devez les dériver d'artefacts réels que vous avez récupérés (rapports existants, documents de concurrents, tables des matières, catégories de forums, titres réglementaires). Ne vous demandez jamais simplement « quels sont trois angles sur ce sujet ».
- Chaque question doit produire une recherche. Une question qui ne peut pas être décomposée en requêtes atteignant des sources réelles n'est pas une recherche, c'est une spéculation. Dites-le et abandonnez-la.
- Les voies ne communiquent pas entre elles pendant l'exécution. L'indépendance est la seule chose qui rend l'accord informatif. La convergence se produit une fois, à la fin.
- Le refus est un signal, pas un échec. Lorsque les recherches d'une voie reviennent vides, enregistrez-le et laissez-le orienter la question suivante. Ne comblez pas le vide avec la mémoire paramétrique.
- Rapportez le niveau de corroboration par affirmation. « Trois sources indépendantes sont d'accord » et « un blog le dit » ne doivent jamais se ressembler dans le rapport lecteur.
- Le mécanisme est invisible dans le rapport lecteur, mais les preuves ne le sont pas. Un lecteur ne doit jamais avoir besoin de savoir ce qu'est une voie ; un lecteur doit toujours pouvoir demander « qui le dit, et quelqu'un d'autre l'a-t-il dit ? ».
- La réponse est le rapport lecteur, inchangé. Le message final à l'utilisateur est
reader-report.mdcopié en entier — pas de préambule, pas de signature, pas de résumé, pas de ligne de garde, pas de commentaire. Si vous voulez que l'utilisateur voie quelque chose de différent, modifiez le fichier et réémettez-le ; n'éditez jamais à la sortie.
Étape 1 — Ancrer les perspectives
Ne commencez pas par le sujet. Commencez par la façon dont ce sujet est déjà structuré dans le monde.
Récupérez 2 à 4 artefacts réels dont vous pouvez emprunter la structure :
| Type de sujet | Où lire la structure |
|---|---|
| Une entité, un produit, un événement | Les sections de sa page Wikipédia + les sections de 2 pages voisines/concurrentes |
| Un marché, une industrie | Deux tables des matières de rapports d'analystes, un index de dépôt réglementaire, un ordre du jour de conférence |
| Une approche technique | La barre latérale de la documentation amont, les titres README de deux projets rivaux |
| Un sujet controversé | Les titres de l'article le plus favorable, les titres de l'article le plus défavorable |
| Une personne, une organisation | La structure de leur propre site par rapport à la structure de la couverture critique |
Dérivez ensuite 3 voies (plus la voie 0, ci-dessous). Chaque voie est une raison différente de se soucier du sujet, pas un sous-sujet différent :
- ✅ « Quelqu'un qui doit faire fonctionner ceci en production, se souciant des modes de défaillance et du coût »
- ✅ « Quelqu'un financièrement exposé à cette décision, se souciant de qui paie »
- ❌ « Aspects techniques » / « Aspects économiques » / « Aspects sociaux » — c'est le même a priori portant trois chapeaux
Vérifiez l'orthogonalité avant de dépenser le budget. Pour chaque paire de voies, écrivez une phrase : « La voie A demanderait X ; la voie B demanderait-elle jamais X ? » Si oui pour une paire, fusionnez-les et redérivez. Si deux voies généreraient les trois mêmes premières questions, elles ne sont qu'une seule voie. Cette vérification est la seule minute au rendement le plus élevé de toute la procédure — ignorez-la et vous obtenez quatre paraphrases d'une seule recherche.
La voie 0 est obligatoire : une voie simple « quelqu'un qui a besoin des faits de base non controversés, des dates, définitions, chiffres ». C'est le socle de couverture qui empêche toutes les autres voies de se spécialiser au point de devenir hors de propos.
Enregistrez les artefacts d'ancrage et les phrases d'orthogonalité ; ils vont dans le rapport de travail (étape 5) comme provenance de l'ensemble des perspectives. Ils n'apparaissent pas dans le rapport lecteur (étape 6).
Étape 2 — Fixer le budget avant de le dépenser
Écrivez le budget explicitement, puis respectez-le :
| Élément | Valeur par défaut | Justification |
|---|---|---|
| Voies | 3 + voie 0 = 4 | Plus de voies dilue plutôt que diversifie ; 4 est le point optimal empirique |
| Tours par voie | 3 | Assez pour un suivi ; au-delà, une voie est généralement perdue |
| Requêtes par question | 2–3 | Une requête est un billet de loterie, cinq est un fusil de chasse |
| Résultats par requête | 3–5 | Lisez les premiers, n'accumulez pas |
| Mots de preuve par tour | ~1000 | Forcez-vous à ne garder que les phrases porteuses |
| Mots de contexte de voie | ~2500 | Conserve les détails récents, supprime les détails obsolètes |
| Voies parallèles | ≤4 | La concurrence est l'objectif ; les limites de débit sont la contrainte |
Budget total de récupération ≈ 4 × 3 × 3 = 36 requêtes. Lorsqu'il est épuisé, arrêtez de chercher et commencez à converger. Épuiser le budget est un événement conçu, pas un accident.
Étape 3 — Exécuter les voies en parallèle, indépendamment
Lancez toutes les voies dans le même tour — utilisez des sous-agents parallèles lorsque disponibles (subagent / workflow), un par voie. Chaque voie reçoit : le sujet, sa description de voie, le budget et les règles ci-dessous. Ne donnez à chaque voie aucune visibilité sur les autres voies.
À l'intérieur d'une voie, pour chaque tour :
- Posez une question à la fois, dans la voix de la voie. Contraintes non optionnelles :
- interroger sur le sujet, pas sur des sujets adjacents (anti-dérive)
- ne pas redemander quelque chose déjà demandé (anti-répétition)
- s'il ne reste rien qui vaille la peine d'être demandé, arrêtez la voie — ne fabriquez pas une question pour remplir le tour
- Décomposez la question en 2 à 3 requêtes de recherche. Une question qui ne se décompose pas est une mauvaise question ; réécrivez-la.
- Cherchez, puis récupérez réellement. Les extraits sont une piste, pas une preuve. Récupérez la page pour tout ce qui est porteur.
- Répondez uniquement à partir de ce que vous avez récupéré. Chaque phrase traçable jusqu'à une URL. Si les sources ne répondent pas, écrivez le refus textuellement : « aucune source trouvée pour cette question ».
- Écrivez le tour dans le contexte de la voie — le squelette de la question toujours, le détail de la réponse pour les derniers tours seulement. C'est ce qui fait de la question suivante un suivi au lieu d'un redémarrage.
Tenez un journal par voie avec, pour chaque source récupérée : url, titre, requête qui l'a trouvée, tour et l'affirmation exacte qu'elle soutient. Les champs requête et tour sont ceux que tout le monde oublie et dont l'étape 4 a besoin.
La boucle de refus : lorsque les recherches d'un tour reviennent vides ou inutiles, cela entre dans le contexte de la voie et la question suivante doit s'en éloigner. Ne comblez jamais un trou avec ce que vous croyez déjà.
Étape 4 — Converger et noter la convergence
Maintenant, et seulement maintenant, rassemblez les voies.
4a. Fusionnez par source, pas par résumé. Indexez chaque élément de preuve par URL (normalisée : supprimez les paramètres de tracking, les fragments, la barre oblique finale). Même URL provenant de deux voies → une source, union des affirmations qu'elle soutient. C'est la première convergence et la moins coûteuse, et c'est là que vous découvrez que deux voies ont atterri indépendamment sur la même page.
4b. Construisez la matrice affirmation × voie. Regroupez les affirmations extraites en assertions atomiques (un fait par ligne). Pour chaque affirmation, enregistrez quelles voies et combien de sources distinctes la soutiennent :
affirmation | URLs de soutien | sources distinctes | voies qui l'ont trouvée | conflits
4c. Notez la corroboration. C'est l'épine dorsale du livrable :
| Niveau | Condition | Comment le formuler |
|---|---|---|
| A — Convergée | trouvée par ≥2 voies indépendantes, ≥2 domaines distincts | énoncer clairement |
| B — Corroborée | ≥2 sources distinctes, même voie | énoncer avec sources attachées |
| C — Source unique | 1 source seulement | énoncer + signaler source unique |
| D — Contestée | des sources crédibles ne sont pas d'accord | présenter les deux, ne pas faire la moyenne |
| E — Non trouvée | cherché, rien trouvé | le dire explicitement ; ne pas combler de mémoire |
Une affirmation n'est A que si les voies étaient véritablement indépendantes — si deux voies ont toutes deux cherché le nom du sujet et ont toutes deux obtenu la page Wikipédia, c'est une voie deux fois, pas une convergence.
4d. Pesez, ne comptez pas. Regroupez par domaine, pas par URL. Dix pages citant le même communiqué de presse ne sont qu'une source. Deux pages de la même organisation sont une source. Notez les dépendances amont (relate à, selon) — une corroboration par écho n'est pas une corroboration.
4e. Cherchez les conflits explicitement. Le mode de défaillance mesuré de STORM n'est pas l'hallucination, c'est le lien entre des faits qui n'ont fait que cooccurrer. Avant d'écrire, scannez la matrice pour les affirmations dont les sources de soutien ne relient pas réellement les deux choses qui sont reliées. Marquez tout lien de ce type comme inféré-par-moi, jamais comme sourcé. Recherchez les lignes de niveau D et assurez-vous que chacune est visible dans le rapport plutôt que résolue silencieusement.
Étape 5 — Rapport (rapport de travail, mécanisme visible)
Écrivez un fichier Markdown. Nom par défaut : working-report.md (si l'utilisateur ou l'appelant a spécifié un autre répertoire de sortie ou nom de fichier pour le rapport, respectez-le — définissez WORKING = <ce chemin> et READER = <chemin du rapport> au début et utilisez ces deux variables pour le reste de l'exécution, afin que la réponse émette le bon fichier).
Structure requise :
# <Sujet>
## Résumé de la corroboration
<comptes : N affirmations convergées / corroborées / source unique / contestées / non trouvées>
## Comment les perspectives ont été choisies
<les artefacts d'ancrage réellement récupérés + les phrases d'orthogonalité + la liste des voies>
## Résultats
### <Thème>
<prose ; chaque affirmation marquée A/B/C/D/E en ligne ; citations sous forme [n]>
## Points contestés
<chaque ligne de niveau D, les deux côtés, sources attachées>
## Affirmations à source unique
<chaque ligne de niveau C — lisez-les comme des pistes à vérifier, pas comme des faits>
## Ce qui a été cherché et non trouvé
<lignes de niveau E, avec les requêtes utilisées>
## Sources
[n] <url> — trouvée par <voie>, tour <k>, via requête "<q>"
Conservez la provenance trouvée par voie / tour / requête dans la liste des sources. Cela ne coûte presque rien à enregistrer et c'est la seule chose qui permet à un lecteur de distinguer « quatre voies indépendantes ont convergé ici » de « un coup de chance répété ».
C'est l'artefact que vous auditez, pas l'artefact que vous remettez. Passez à l'étape 6.
Étape 6 — Polir en rapport lecteur (mécanisme invisible)
Écrivez le résultat dans reader-report.md (ou <READER> comme fixé à l'étape 5). Exécutez ceci en une passe séparée avec un contexte frais — un sous-agent qui ne reçoit que le rapport de travail, pas les invites de voie, pas les journaux de voie, pas votre raisonnement. Une passe qui a vu la mécanique fuira la mécanique.
6a. Traduisez chaque terme du mécanisme dans le langage du lecteur
Il s'agit d'un mappage fixe, pas d'un jugement. N'inventez pas d'alternatives.
| Rapport de travail | Rapport lecteur |
|---|---|
| voie | perspective ou angle de recherche |
| tour | cycle de recherche |
| convergence | accord entre perspectives indépendantes |
| niveau de corroboration A–E | force de la preuve : confirmé par plusieurs sources / corroboré / source unique / contesté / non trouvé |
| orthogonalité | perspectives qui ne se chevauchent pas |
| budget | nombre total de recherches effectuées |
| refus | aucune source trouvée pour cette question |
6b. Restructurez le rapport de travail autour du parcours du lecteur, pas autour de la procédure
Le rapport lecteur doit permettre à une personne de décider si elle fait confiance à chaque affirmation sans jamais avoir à connaître la méthode.
# <Titre centré sur le sujet, pas sur le processus>
## Résumé des résultats
<principales conclusions et la force globale de la preuve en une phrase>
## Contexte
<ce que le lecteur doit savoir pour comprendre les sections suivantes — faits de base, définitions, chronologie>
## Résultats détaillés
### <Thème 1>
<affirmations et leur force, avec citations entre crochets>
### <Thème 2>
<...>
## Où les sources ne sont pas d'accord
<chaque point contesté, présenté avec les deux côtés>
## Ce qui n'est pas encore clair
<affirmations qui reposent sur une source unique ou que les recherches n'ont pas trouvées>
## Sources
[n] <url> — <titre> (pas de mention de voie, de tour ou de requête)
6c. Règles pour la passe de polissage
- Ne supprimez jamais une affirmation. Si elle est dans le rapport de travail, elle est dans le rapport lecteur, même au niveau E. Sinon, cacher une affirmation vide est la porte ouverte à remplir le vide de mémoire.
- N'améliorez jamais un niveau de corroboration. Si une affirmation est C dans le rapport de travail, elle est C dans le rapport lecteur. Le modèle n'a pas le droit de décider que quelque chose est « bien connu » et de le passer en B sans nouvelle source.
- Ne mettez jamais les sources ensemble. A et B provenant de sources différentes doivent toujours être listés séparément ; le lecteur doit pouvoir les compter. Ne dites pas « plusieurs sources confirment », dites « La source [1] et la source [2] confirment ».
- Traduisez, ne faites pas la moyenne. Au niveau D, présentez les deux affirmations et leurs sources côte à côte. Une phrase comme « la position de la plupart des experts est X, bien que Y ait été avancé par [source] » est un effacement de conflit — écrivez plutôt « [source] affirme X. [source] affirme Y, ce qui est en contradiction. »
- Supprimez le balisage de processus. Aucune mention de chemin, tour, budget, orthogonalité, converge, artefact d'ancrage, passe, sous-agent, contexte. Aucune phrase de balisage de processus ne survit.
6d. Vérifiez le résultat
Avant de terminer, relisez le fichier en tant que personne qui n'a pas effectué la recherche. Pour chaque affirmation :
- Puis-je voir qui le dit ? (pas une référence, une citation réelle)
- Puis-je voir combien de sources le disent séparément ?
- Si deux sources ne sont pas d'accord, est-ce que je vois les deux, ou le modèle a-t-il choisi un camp ?
- Si le rapport dit « aucune source trouvée », le crois-je ? (Il n'y a aucun moyen de prouver un négatif — c'est une question d'honnêteté)
- Puis-je prendre une décision en utilisant cette page ? Si non, elle a besoin de plus de structure ou d'exemples concrets.
§Livraison — la seule règle qui compte vraiment
À la fin de l'étape 6, le fichier reader-report.md (ou l'emplacement que vous avez fixé au début) contient le livrable. Votre réponse finale est ce fichier, textuellement.
<lisez reader-report.md et émettez exactement son contenu>
Absolument rien d'autre. Pas de :
- ❌ « J'ai terminé la recherche approfondie multi-perspectives. Voici le rapport final. »
- ❌ « Le rapport a été enregistré dans reader-report.md. »
- ❌ « Veuillez trouver ci-joint le rapport. Tout commentaire est le bienvenu. »
- ❌ Aucune phrase de fermeture, pas même un simple « Terminé. »
- ❌ Aucune sortie de débogage, aucun journal de progrès, aucune trace de processus.
Si vous souhaitez montrer un message supplémentaire en plus du rapport lecteur (par exemple, un avertissement que le budget de recherche était insuffisant, ou une suggestion pour une prochaine étape), écrivez-le dans le rapport de travail et placez-le dans la réponse avant ---, mais ceci n'est qu'un conseil — la règle stricte est toujours que le message final est le rapport lecteur, textuellement.
<lisez reader-report.md et émettez exactement son contenu>
Aucune exception. Aucun préambule. Aucune signature. Le rapport lecteur est le produit ; tout le reste est un commentaire sur la façon dont il a été fabriqué.
Guide de dépannage rapide
« Les voies n'étaient pas indépendantes »
- Les voies se sont-elles vu les requêtes des unes des autres ? Oui ? Elles n'étaient pas indépendantes.
- Une voie a-t-elle été formulée comme une demande de résumé, produisant les mêmes résultats que les autres ? Représentez le sujet en termes de quelqu'un dont les intérêts sont en conflit avec les autres voies.
« Tous les résultats de niveau E »
- Les requêtes fonctionnent-elles dans le moteur de recherche que vous utilisez réellement ? Testez-en une.
- La voie est-elle trop étroite ? Élargissez la description de la voie plutôt que de répéter la même requête avec une formulation différente.
- Le budget est-il trop petit ? Si toutes les voies reviennent vides avec le budget par défaut, le portefeuille de requêtes doit être élargi, pas le budget augmenté.
« Le niveau A et le niveau C se ressemblent dans le rapport lecteur »
- Vous avez probablement écrit « Plusieurs sources confirment » au lieu de lister les URL. Le rapport de travail a une matrice de preuves ; copiez-la dans la section Sources du rapport lecteur avec des étiquettes claires. Le lecteur doit voir deux lignes distinctes :
[1] URL Aet[2] URL B.
« Le modèle a rempli le niveau E avec ce qu'il croit »
- La passe de polissage (étape 6) a-t-elle vu le rapport de travail uniquement ? Si elle a vu les invites de la voie ou votre raisonnement, elle les a traités comme des sources supplémentaires. Recommencez l'étape 6 avec un sous-agent frais qui ne reçoit que les octets du rapport de travail.
- Une phrase du niveau E disant « il n'y a pas de consensus » est remplir le vide. Écrivez plutôt « Aucune source n'a été trouvée. Les bases de données interrogées n'ont pas renvoyé de résultats pour les termes X, Y, Z. »
« Le conflit a disparu »
- L'étape 4e a-t-elle été sautée ? Retournez à la matrice, trouvez les paires de sources qui se contredisent, et marquez-les comme niveau D avant de passer à l'étape 6. C'est une étape délibérée de recherche de conflit ; le sauter garantit un rapport plat.
Annexe A : Exemples de décomposition de voie
Le but de la décomposition de voie est de produire des questions de recherche qui diffèrent par leur intention, pas seulement par leur surface.
| Sujet : « Le marché des voitures électriques en Indonésie » |
| Voie 0 (faits de base) : Quelle est la taille actuelle du marché ? Quels sont les principaux constructeurs ? Quelles sont les politiques gouvernementales ? |
| Voie 1 (opérateur de flotte) : Quels sont les problèmes de disponibilité des pièces détachées ? Quelle est la capacité du réseau de recharge ? Coût total de possession par rapport aux véhicules à essence ? |
| Voie 2 (investisseur) : Quelles subventions sont en place et pour combien de temps ? Quels sont les plans de fabrication locale de batteries ? Quels modèles de tarification des concurrents ? |
| Voie 3 (écologiste) : Quel est le mix énergétique de production d'électricité en Indonésie ? Que deviennent les batteries usagées ? Combien de véhicules électriques ont déplacé des véhicules à essence ? |
Vérification d'orthogonalité : L'opérateur de flotte demanderait-il le mix énergétique ? Non. L'investisseur demanderait-il le coût total de possession ? Oui — fusionnez les voies 1 et 2 ou redéfinissez les limites. Solution : la voie de l'investisseur s'intéresse au coût du capital et à l'évolution des prix des batteries (macro), la voie de l'opérateur s'intéresse aux coûts d'exploitation quotidiens (micro) — des questions de recherche différentes, conservez les deux.
| Sujet : « PostgreSQL 17 est-il prêt pour la production ? » |
| Voie 0 (faits de base) : Date de sortie, nouvelles fonctionnalités, compatibilité descendante, configuration minimale requise. |
| Voie 1 (administrateur de base de données) : Changements de verrouillage, impact sur la réplication, régression des performances de requête, procédure de mise à niveau. |
| Voie 2 (développeur d'application) : Nouveaux types de données, améliorations SQL/JSON, avec quelle API les pilotes fonctionnent-ils, modifications des schémas ? |
| Voie 3 (responsable des opérations) : Rapports de bugs bloquants, correctifs de sécurité, support du fournisseur de cloud, engagement de la communauté en matière de maintenance. |
Les mauvaises voies pour n'importe quel sujet : « Avantages », « Inconvénients », « Risques », « Opportunités » — ce sont des étiquettes de section, pas des perspectives. Une perspective décrit qui pose la question et pourquoi elle la pose.
Annexe B : Considérations techniques
Exécution parallèle : Lorsque l'environnement le permet, utilisez le parallélisme au niveau de la voie (par exemple, subagent pour chaque voie). Ce n'est pas une optimisation facultative ; c'est ce qui fait de la variante une variante. Exécuter les voies en série permet à la voie k+1 de voir les résultats de la voie k, ce qui détruit l'indépendance. Si vous ne pouvez pas exécuter en parallèle, réduisez le nombre de voies à 2 + voie 0.
Partage de contexte : Chaque voie doit avoir son propre emplacement de contexte ou sa propre fenêtre d'invite, écrit sans connaissance des autres. Le rapport de travail rassemble tout ; rien n'est partagé avant cela.
Limites de fenêtre de contexte : Le rapport de travail contient toutes les preuves (≈3600 mots de contexte de voie + les preuves récupérées). Le rapport lecteur est plus court (≈1500–2500 mots). Si la fenêtre de contexte est serrée, produisez le rapport de travail d'abord, puis exécutez l'étape 6 dans un contexte frais qui n'a que le rapport de travail.
Moteurs de recherche : Cette compétence utilise anysearch/agent-reach comme backends de récupération. Elle n'effectue pas de recherche directement ; elle émet des requêtes vers ces outils avec la voie et le tour attachés comme métadonnées. Si le moteur de recherche back-end prend en charge l'opérateur de site (site:), la négation (-terme) ou la plage de dates, utilisez-les pour réduire le bruit.
Limites de débit : Si le taux de requêtes par voie est limité, ajustez Résultats par requête à 3 et Requêtes par question à 2 pour rester en dessous tout en maintenant la diversité des requêtes.
Format des citations : Utilisez des citations par numéro entre crochets [n] dans tout le texte, avec les URL rassemblées dans une section Sources à la fin. Chaque numéro doit pointer vers exactement une URL — ne regroupez pas les sources. Si une affirmation est soutenue par plusieurs URL, citez chaque numéro [1][2][3].