Apothem im Vergleich zur manuellen Kimi-Code-Konfiguration
Die Datei AGENTS.md im Projektstammverzeichnis und die Unterstützungsdateien unter .kimi-code/ von Kimi Code von Hand pflegen, verglichen mit dem Rendern aus Apothems gemeinsamem Profil.
Kimi Code liest die AGENTS.md im Projektstammverzeichnis als seine
Anweisungsdatei und hält die Projektkonfiguration unter <project>/.kimi-code/
vor, einschließlich der dem Operator gehörenden MCP-Oberfläche
.kimi-code/mcp.json. Sie können diese Anweisungsdatei und ihre unterstützenden
Kohorten von Hand verfassen, je Projekt, auf Dauer. Der kimi-code-Adapter von
Apothem rendert die Governance-Oberfläche als verwalteten Block aus dem
gemeinsamen Profil in die AGENTS.md und hält sie über jeden Harness und jedes
Projekt hinweg konsistent. Diese Seite stellt die manuelle Pflege dieser
Konfiguration der Verwaltung mit Apothem gegenüber.
Aufwandsvergleich
| Aufgabe | Manuelle Konfiguration | Von Apothem verwaltet |
|---|---|---|
Die Anweisungsoberfläche AGENTS.md verfassen | Von Hand schreiben und je Projekt neu synchronisieren | Ein verwalteter Block, aus dem gemeinsamen Profil gerendert |
| Regeln, Befehle, Skills und Agenten synchron halten | Manuelles Kopieren je Projekt | Skills und Befehle (als Skills) unter <project>/.kimi-code/skills/; Helfer als Subagenten unter <project>/.kimi-code/agents/; Regeln, Hooks und Templates unter <project>/.kimi-code/.apothem/support/, bei jeder Installation |
| Vom Operator verfassten Text beim Aktualisieren bewahren | Manuelles Zusammenführen | Durch Sentinels begrenzter Block; vom Operator verfasster Text außerhalb davon bleibt erhalten |
| Regeln mit anderen Harnesses abgestimmt halten | Manuell, pro Werkzeug | Automatisch bei apothem update |
| Prüfen, ob die Konfiguration korrekt ist | Manuelle Inspektion | apothem verify --harness kimi-code --project <path> |
Was Apothem verwaltet
Der kimi-code-Adapter rendert die gemeinsamen Regeln und die
Governance-Oberfläche in den verwalteten Block der AGENTS.md im
Projektstammverzeichnis und installiert die Skills sowie die als Skills
verpackten Befehle in .kimi-code/skills/, dem Projekt-Skill-Verzeichnis, das
Kimi Code lädt. Die Helfer werden zu Kimi-Code-Subagenten in
.kimi-code/agents/, wobei ihre Werkzeugnamen in die übersetzt werden, die Kimi
Code abgleicht. Die Kohorten Hooks, Regeln und Templates kommen unter
.kimi-code/.apothem/support/: Kimi Code liest Hooks aus der benutzerweiten
~/.kimi-code/config.toml, die der Adapter nicht schreibt. Der Adapter verfasst
.kimi-code/mcp.json nicht; die MCP-Oberfläche bleibt im Besitz des Operators.
Kimi Code liest Projektanweisungen aus AGENTS.md oder
.kimi-code/AGENTS.md; der Adapter schreibt nur die AGENTS.md im
Projektstammverzeichnis, und die Dokumentation von Kimi Code sagt nicht, welche
der beiden Dateien Vorrang hat, wenn beide existieren. Jede Änderung an den
gemeinsamen Regeln rendert die Dateien beim nächsten apothem update neu.
Migrationspfad
- Führen Sie
apothem profile initaus, um das gemeinsame Profil zu erstellen, falls Sie das noch nicht getan haben. - Verschieben Sie die Regeln aus Ihrer vorhandenen
AGENTS.mdin das gemeinsame Korpus. - Führen Sie
apothem install --harness kimi-code --project <path>aus, um die AnweisungsoberflächeAGENTS.md, die Skills in.kimi-code/skills/, die Subagenten in.kimi-code/agents/und den Unterstützungs-Teilbaum.kimi-code/.apothem/support/zu rendern. - Führen Sie
apothem verify --harness kimi-code --project <path>aus, um zu bestätigen, dass die Konfiguration angekommen ist. - Verwenden Sie
apothem update --harness kimi-code --project <path>für jede spätere Änderung.
Als Nächstes lesen
Apothem vs. rohe Open-Claw-Konfiguration
Die Open-Claw-Konfiguration von Hand pflegen versus sie über Apothems gemeinsames Profil verwalten.
Apothem im Vergleich zur manuellen Verdrahtung des GLM-Backends
Warum Sie die Backend-Konfiguration von GLM (Z.ai) über Apothem leiten, statt Umgebungsvariablen je Projekt von Hand zu verdrahten.