Une mémoire unique sur toutes les surfaces
La mémoire du compte qui vous suit sur Dropstone Chat, le CLI et le SDK, ce qui la partage et ce qui ne la partage pas, et comment garder l'apprentissage d'une intégration hors de votre propre mémoire.
La mémoire est ce qui relie les surfaces de Dropstone entre elles. Apprenez-lui quelque chose une fois, sur n'importe laquelle d'entre elles, et cela se retrouve sur les autres : une mémoire par compte, pas une par outil.
Ce qui la partage
| Surface | Comment elle fonctionne | Partage la mémoire |
|---|---|---|
| Dropstone Chat | connecté | Oui |
| Le CLI | connecté avec dropstone login | Oui |
| Le SDK, client agent local | démarre un serveur en tant que votre compte | Oui |
| Le SDK, client headless | une clé API contre le point de terminaison public | Non |
| Un chat incognito | lit la mémoire, n'en écrit aucune | Lit, n'écrit pas |
La règle derrière ce tableau est simple : une surface qui fonctionne en tant que vous a votre mémoire, une surface conçue pour les pipelines ne l'a pas, et un mode lit sans écrire. Le point de terminaison headless est sans état par conception, donc la même entrée donne la même réponse, peu importe ce que vous avez appris à Dropstone la semaine dernière. Un chat incognito fonctionne dans l'autre sens : il travaille avec ce que Dropstone sait et ne conserve rien de ce qu'il produit.
Pourquoi cela compte dans le code
Un agent qui connaît vos conventions vaut plus qu'un agent que vous briefez à chaque appel. Une règle que vous définissez dans Chat s'applique dans une session que votre application démarre, et un fait qu'une session SDK enregistre est là la prochaine fois que vous ouvrez le CLI. C'est l'effet cumulatif : plus vous travaillez avec Dropstone, moins chaque surface a besoin d'être informée. Voir Comment un agent apprend en travaillant.
Garder une intégration séparée
Si un service doit avoir sa propre mémoire plutôt que la vôtre, donnez-lui son propre compte, ou un compte de membre d'organisation dédié à cette intégration. Il apprend alors sur l'intégration et rien d'autre, et votre propre mémoire reste la vôtre. Voir Mémoire et votre confidentialité.
L'éditeur et les autres intégrations
L'extension de l'éditeur, l'API et le reste des intégrations sont documentés dans la référence du CLI, qui est le lieu dédié à la configuration spécifique aux surfaces : l'extension VS Code elle-même, la configuration VS Code, l'intégration IDE et l'API HTTP.
Related articles
- Memory across chat, CLI, and SDKDropstone memory belongs to your account, not to one app. A rule you set in the CLI applies in chat, and something learned in chat is available to the SDK. One memory, every surface.
- How Dropstone remembers youDropstone keeps a persistent memory that follows your account across chat, the CLI, and the SDK. Correct it once and it should not need correcting again, anywhere you use it.
- Dropstone SDKA typed TypeScript and JavaScript client for the Dropstone agent, with two entry points: one for headless API calls from CI or a serverless function, one that runs the agent locally with the same account memory as the CLI and Chat.
- Using the API with your planCall Dropstone over HTTP with an API key. The endpoint is OpenAI-compatible, billed pay-per-use from your credit balance, and works from any language. Keys, errors, rate limits, and what the API does not carry.
- Dropstone CLI overviewThe Dropstone CLI is an agent for your terminal that reads your codebase, edits files, runs commands, and shares memory with everything else on your account. Install it in one command. The full reference is at docs.dropstone.io.