Exécutions et attribution des agents
Lorsqu'un agent IA change de travail à Kanera, le dossier l'indique. Ses commentaires, changements de carte et lignes d'activité sont étiquetés avec le nom de l'agent et la personne pour laquelle il a agi, afin que personne ne confonde le résultat de l'agent avec quelque chose qu'un coéquipier a tapé. Pendant qu'un agent travaille sur une carte, il peut ouvrir un exécution: un marqueur vivant sur la tuile de la carte qui indique au reste de l'équipe que le travail est déjà en cours.
Comment le travail des agents est attribué
Kanera enregistre qui a effectué une action en fonction des informations d'identification qui la sous-tendent.
| Connexion | Comment son travail apparaît |
|---|---|
| OAuth, y compris le code de l'appareil | En tant que personne qui a mis l'agent en relation avec un via <agent> insigne. Le nom de l'agent est le nom sous lequel le client AI s'est enregistré, par exemple Claude. |
| Clé API personnelle | En tant que propriétaire de la clé, sans étiquette d'agent. Un script que vous exécutez avec votre propre clé se lit comme vous. |
| Agent autonome ou Clé API de l'espace de travail/du tableau | Sous le nom de connexion ou de clé, pas en tant que personne. |
La distinction réside dans la subvention OAuth interactive, et non dans le transport. Le Kanera CLI prend en charge les deux : connexion au navigateur avec kanera auth login --agent "Claude Code" les étiquettes fonctionnent via l'agent, tandis que la connexion par clé API l'enregistre en tant que propriétaire de la clé ou clé. Voir Travailler avec des agents de codage depuis le terminal pour savoir comment cela affecte un flux de travail de terminal.
Le badge via
Dans le flux d'activité d'une carte, un commentaire écrit par un agent conserve le nom et l'avatar de la personne et ajoute un via <agent> badge à côté. Survolez le badge pour voir qui a écrit le commentaire et pour qui, par exemple Écrit par Claude au nom d'Amelia Hart. Les changements de carte effectués par un agent portent le même badge, avec un Fait par… au nom de… info-bulle.
Le travail d'agent reste soumis au rôle de la personne connectée. Kanera vérifie leur accès actuel sur la carte cible à chaque écriture, de sorte qu'un agent ne peut pas faire quelque chose que sa personne ne pourrait pas faire.
L'agent s'exécute
Une exécution est la session de travail d'un agent sur une seule carte. C'est la façon dont un agent annonce « Je suis là-dessus » avant de commencer un travail en plusieurs étapes, et comment il rend compte des progrès et des résultats.
Commencer une course
Un agent démarre une exécution avec le runs.start Outil MCP, donnant à la carte, un titre court pour le travail, et éventuellement une note de progression plus longue et un lien qu'une personne peut suivre, comme une pull request ou un journal de session. Depuis un shell, le même outil est kanera run start <card> "<title>", avec kanera run update et kanera run done faire rapport et terminer. Les intégrations peuvent utiliser POST /api/v1/cards/{cardId}/agent-runs dans le API publique.
Le démarrage ou la mise à jour d'une exécution nécessite un accès Editeur sur le tableau de la carte et un identifiant capable d'écrire. Une clé en lecture seule ou un Observer ne peut pas ouvrir une exécution.
Avant de commencer, un agent doit appeler runs.list pour vérifier si un autre agent utilise déjà la carte, reprendre sa propre exécution en direct pour la même tâche ou signaler le conflit d'exécution en direct d'un autre agent avant d'effectuer un travail qui se chevauche. Il renvoie les exécutions en direct par défaut, ou l'historique complet des exécutions de la carte avec includeEnded.
La puce sur la tuile de la carte
Lorsqu'une partie est en cours, la tuile de la carte affiche un petit jeton scintillant avant le titre. Survolez-le ou lisez-le avec un lecteur d'écran pour voir l'agent et le travail :
- Travail : <agent> fonctionne : <titre>
- En attente d'une personne : <agent> vous attend : <titre>, et la puce devient orange.
Si plusieurs exécutions sont actives sur la carte, l'étiquette nomme la première et ajoute (+N plus). La puce est mise à jour en temps réel pour tous ceux qui consultent le tableau et disparaît à la fin de l'exécution.
États d'exécution
| Statut | Défini par | Ce que cela signifie |
|---|---|---|
running | L'agent | Travailler. Chaque course commence ici. |
blocked | L'agent | Attendre une personne, comme une question ou une approbation. La puce devient orange et les détails de la carte s'affichent Je t'attends. |
succeeded | L'agent | Terminé. Termine la course. |
failed | L'agent | Impossible de terminer le travail. Termine la course. |
cancelled | L'agent | Arrêté délibérément. Termine la course. |
stalled | Kanéra | L'agent a arrêté de signaler. |
running et blocked sont en direct et montrent la puce. L'agent se déplace entre eux et rapporte la progression, avec runs.update, en gardant le résumé sur une seule ligne sur ce qu'il fait actuellement. succeeded, failed, et cancelled mettre fin à l'exécution de manière permanente : une exécution terminée ne peut pas être modifiée et une nouvelle mise à jour est rejetée.
Définir une course pour blocked change la puce. Il n’envoie lui-même aucune notification à personne. Si l'agent a besoin d'une personne en particulier, il doit également laisser un commentaire sur la carte indiquant ce qu'il attend.
Courses bloquées
Chaque runs.update un appel compte comme un battement de coeur, y compris celui qui ne change rien. Kanera vérifie les courses silencieuses toutes les minutes et marque une course en direct stalled une fois qu'il s'est écoulé quinze minutes sans un battement de cœur. Le runs.update L'outil indique aux agents de se présenter au moins toutes les dix minutes.
Une exécution bloquée n'affiche plus la puce ou n'apparaît plus dans le L'agent s'exécute section, afin qu'un agent en panne ne puisse pas laisser une carte paraître occupée. Le flux d'activité de la carte l'enregistre comme Kanera marquant l'exécution de l'agent comme étant bloquée. Cependant, une exécution bloquée n'est pas fermée : l'agent peut revenir et la terminer avec un statut de terminal, ou la définir sur running pour reprendre.
Le modèle de workflow d'agent
Si vous confiez la majeure partie du travail d'un tableau à des agents, démarrez l'espace de travail à partir du Flux de travail des agents modèle. Ses listes suivent la durée d'une exécution, de sorte que le tableau lui-même montre ce que font les agents :
| Liste | Ce qu'il contient |
|---|---|
| Carnet de commandes | Ouvrage prêt à remettre à un agent. |
| Agent travaillant | Un agent a un running exécuter sur la carte. |
| M'attendant | L'agent a défini son exécution sur blocked et a besoin d'une décision de votre part. Le résumé de l'exécution indique ce dont il a besoin. |
| Examen | Le travail est prêt pour votre examen. Vérifiez le résultat, souvent une pull request dans le Demande de tirage champ. |
| Terminé | Vous avez accepté le travail. Kanera marque la carte comme terminée. |
Les courses ne bougent jamais et ne complètent jamais les cartes par elles-mêmes. Les agents enregistrent la liste originale avant de déplacer une carte, puis relisent la carte et le tableau avant la remise. Ils considèrent la liste originale, les listes actuellement disponibles et leur signification, le travail terminé et le travail restant, et choisissent la liste qui reflète l'état réel de la carte dans le flux de travail de ce tableau. Le retour à la liste originale peut être approprié, mais n'est pas automatique. Les noms de liste et l’ordre ne prescrivent pas de destination. Si le choix n'est pas clair, ils laissent la liste inchangée, enregistrent les autres mises à jour de suivi et demandent.
Une exécution réussie peut couvrir seulement une partie d'une carte. Les agents ne remplissent la carte que lorsque le flux de travail convenu le permet et que ses critères sont remplis ; ce modèle est par défaut l'acceptation humaine. Avant leur réponse finale, ils publient un commentaire sur le résultat avec les modifications, la vérification, les liens, le travail restant et la raison du routage, terminent l'exécution de manière appropriée et vérifient les mises à jour enregistrées. Les requêtes en lecture seule et exploratoires n’entraînent aucune écriture de suivi et les restrictions utilisateur explicites sont prioritaires.
Le modèle ajoute également Caractéristique, Bogue, Corvée, et Recherche des étiquettes et une carte de démarrage expliquant le déroulement. L'agent d'un administrateur d'organisation peut créer l'espace de travail pour vous avec workspaces.create et templateId: "agent-workflow".
Fonctionne dans les détails et l'activité de la carte
Ouvrez une carte avec une exécution en direct et un L'agent s'exécute La section apparaît directement sous la description. Chaque run affiche son titre, l'agent, son statut (Travailler ou Je t'attends), la date de son dernier rapport et sa dernière note d'avancement.
Seules les exécutions en direct apparaissent dans cette section. Lorsqu'une course se termine, elle en disparaît et le résultat devient une ligne dans le flux d'activité de la carte, telle que terminé : <titre> — <résumé de clôture>, ou échoué ou annulé pour les autres fins. Le résumé de clôture est la note que l'agent a laissée à la fin de l'exécution, demandez donc aux agents d'en faire un enregistrement utile de ce qui s'est passé.
Le début d'une course est enregistré, mais l'avance de la carte ne le répète pas ; la section en direct est l'endroit où le travail en vol est présenté.
Notifications sur le travail des agents
Kanera vous laisse normalement en dehors des notifications concernant vos propres actions. Le travail effectué par votre agent via OAuth est l'exception : vous en êtes informé comme vous le seriez pour le travail d'un coéquipier sur une carte que vous regardez ou à laquelle vous êtes affecté, car déléguer le travail n'est pas la même chose que de le regarder se produire.
Une fois qu'un agent a agi pour vous, le tiroir de notification obtient un Agent onglet à côté Non lu et Tout. Il répertorie ce que vos agents ont fait, les notifications non lues ainsi que celles lues au cours des sept derniers jours, et son étiquette indique le nombre de notifications non lues, par exemple Agent (1). Chaque notification porte le via <agent> insigne. Lorsque vous regroupez les notifications par utilisateur, le travail de votre agent forme son propre groupe intitulé <personne> via <agent> plutôt que de fusionner avec le vôtre.
Le début et la fin d'une course sont enregistrés dans l'activité de la carte mais n'envoient jamais de notification. Les notifications couvrent ce que l'agent a réellement fait, comme les commentaires, les mouvements et l'achèvement.
Travail d'agent dans Work Done
Le Travail accompli view maintient la production de l'agent séparée des propres efforts des personnes. Une ligne produite par un agent montre une marque scintillante à côté de la personne et son info-bulle indique : Travaillé par <personne> via <agent>. La pile d'avatars du résumé du jour porte la même marque.
Les lignes d'agent ne sont pas comptées comme le propre travail de la personne. Le filtrage du travail effectué par un membre affiche uniquement les actions de cette personne, de sorte qu'une livraison d'une semaine ne compte jamais tranquillement le travail d'un agent comme les heures de quelqu'un.
Activité de l'agent de recherche
- Notifications : le Agent L'onglet est la file d'attente de révision de tout ce que vos agents ont fait.
- Une carte : le flux d'activité de la carte affiche via <agent> badges et courses terminées. Un agent peut lire l'historique complet des exécutions avec
runs.listetincludeEnded. - Intégrations : webhooks livrer
agentRun:startedetagentRun:updatedévénements pour les automatisations qui réagissent au travail des agents.
Il n'existe pas de filtre à l'échelle du tableau pour l'activité des agents dans le flux d'activité ou le travail effectué.