Apothem face à la configuration manuelle de Kimi Code
Maintenir à la main le fichier AGENTS.md à la racine du projet et les fichiers de support .kimi-code/ de Kimi Code face à leur rendu depuis le profil partagé d'Apothem.
Kimi Code lit le fichier AGENTS.md à la racine du projet comme son fichier
d'instructions et conserve la configuration du projet sous
<project>/.kimi-code/, y compris la surface MCP .kimi-code/mcp.json, qui
appartient à l'opérateur. Vous pouvez rédiger ce fichier d'instructions et ses
cohortes de support à la main, projet par projet, indéfiniment. L'adaptateur
kimi-code d'Apothem rend la surface de gouvernance dans AGENTS.md sous la forme
d'un bloc géré, à partir du profil partagé, et la garde cohérente entre tous les
environnements et tous les projets. Cette page oppose la maintenance manuelle de
cette configuration à sa gestion avec Apothem.
Comparaison de l'effort
| Tâche | Configuration manuelle | Géré par Apothem |
|---|---|---|
Rédiger la surface d'instructions AGENTS.md | Rédiger et resynchroniser à la main pour chaque projet | Un bloc géré unique, rendu à partir du profil partagé |
| Garder règles, commandes, skills et agents synchronisés | Copie manuelle par projet | Skills et commandes (sous forme de skills) sous <project>/.kimi-code/skills/ ; auxiliaires sous forme de sous-agents sous <project>/.kimi-code/agents/ ; règles, hooks et templates sous <project>/.kimi-code/.apothem/support/, à chaque installation |
| Conserver la prose de l'opérateur lors d'une actualisation | Fusion manuelle | Bloc délimité par des marqueurs sentinelles ; la prose de l'opérateur hors de ce bloc est conservée |
| Garder les règles alignées avec les autres environnements | Manuel, par outil | Automatique lors de apothem update |
| Vérifier que la configuration est correcte | Inspection manuelle | apothem verify --harness kimi-code --project <path> |
Ce qu'Apothem gère
L'adaptateur kimi-code rend les règles partagées et la surface de gouvernance dans
le bloc géré du fichier AGENTS.md à la racine du projet, et installe les
skills, ainsi que les commandes enveloppées sous forme de skills, dans
.kimi-code/skills/, le répertoire de skills de projet que Kimi Code charge. Les
auxiliaires deviennent des sous-agents Kimi Code dans .kimi-code/agents/, avec
leurs noms d'outils traduits vers ceux que Kimi Code reconnaît. Les cohortes de
hooks, de règles et de templates vont sous .kimi-code/.apothem/support/ : Kimi
Code lit les hooks depuis le fichier de portée utilisateur
~/.kimi-code/config.toml, que l'adaptateur n'écrit pas. L'adaptateur ne rédige
pas .kimi-code/mcp.json ; la surface MCP reste la propriété de l'opérateur. Kimi Code lit les instructions du
projet depuis AGENTS.md ou .kimi-code/AGENTS.md ; l'adaptateur n'écrit que le
fichier AGENTS.md à la racine du projet, et la documentation de Kimi Code ne
précise pas lequel des deux fichiers l'emporte lorsque les deux existent. Chaque
changement des règles partagées rend de nouveau les fichiers lors du prochain
apothem update.
Chemin de migration
- Exécutez
apothem profile initpour créer le profil partagé si vous ne l'avez pas encore fait. - Déplacez les règles de votre
AGENTS.mdexistant vers le corpus partagé. - Exécutez
apothem install --harness kimi-code --project <path>pour générer la surface d'instructionsAGENTS.md, les skills de.kimi-code/skills/, les sous-agents de.kimi-code/agents/et l'arborescence de support.kimi-code/.apothem/support/. - Exécutez
apothem verify --harness kimi-code --project <path>pour confirmer que la configuration est bien en place. - Utilisez
apothem update --harness kimi-code --project <path>pour chaque modification ultérieure.
À lire ensuite
Apothem face à la configuration Open-Claw brute
Maintenir à la main la configuration d'Open-Claw plutôt que la gérer via le profil partagé d'Apothem.
Apothem face au câblage brut du backend GLM
Pourquoi faire passer la configuration du backend GLM (Z.ai) par Apothem plutôt que de câbler à la main des variables d'environnement projet par projet.