@mindstudio-ai/agent 0.1.112 → 0.1.113
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli.js +62 -8
- package/dist/index.d.ts +102 -1
- package/dist/index.js +58 -3
- package/dist/index.js.map +1 -1
- package/dist/postinstall.js +62 -8
- package/llms.txt +30 -1
- package/package.json +1 -1
package/llms.txt
CHANGED
|
@@ -19,7 +19,7 @@ For specific use cases:
|
|
|
19
19
|
- **Pre-built agents**: Call `listAgents()` to see what's available → `runAgent({ appId })` to execute one. **Important:** Not all agents are configured for API use. Do not try to run an agent just because it appears in the list — only run agents the user specifically asks you to run.
|
|
20
20
|
- **Model selection**: Call `listModelsSummary()` or `listModelsSummaryByType("llm_chat")` to browse models, then pass the model ID as `modelOverride.model` to actions like `generateText`. Use the summary endpoints (not `listModels`) to keep token usage low.
|
|
21
21
|
- **Cost estimation**: AI-powered actions (text generation, image generation, video, audio, etc.) cost money. Call `estimateStepCost(stepType, stepInput)` before running these and confirm with the user before proceeding — unless they've explicitly given permission to go ahead. Non-AI actions (data lookups, OAuth connectors, etc.) are generally free.
|
|
22
|
-
- **Task agents**: For multi-step tasks that need autonomous tool use (research, content creation, data enrichment), use `runTask()`. Provide a prompt, input, tools, an output contract, and a tool-use model id. The SDK runs a tool-use loop — calling the model, executing tools, feeding results back — until structured output is produced. Tools are SDK action names
|
|
22
|
+
- **Task agents**: For multi-step tasks that need autonomous tool use (research, content creation, data enrichment), use `runTask()`. Provide a prompt, input, tools, an output contract, and a tool-use model id. The SDK runs a tool-use loop — calling the model, executing tools, feeding results back — until structured output is produced. Tools are SDK action names, your own app methods written as `{ appMethod: "save-vendor", description: "when to use it" }`, and/or inline functions written as `{ name, description, inputSchema, execute }` — the function runs in your process when the model calls it, and a thrown error goes back to the model as tool output to work around. App methods run as the user who invoked the method that started the task, with their roles, so the agent can read and write app state on their behalf. Prefer `outputSchema` for the output contract: plain JSON Schema (`type`/`properties`/`required`/`enum`/`items`; nullable via type arrays like `["string","null"]` — no `oneOf`/`$ref`/`nullable`). Output is validated every turn with automatic repair, `result.output` is fully typed from the schema (no generic argument, no `parsedSuccessfully` check), and the call throws `MindStudioError` code `task_output_schema_mismatch` if the agent cannot produce conforming output. Example: `runTask({ prompt: "Research this restaurant and save it", input: { name: "Tartine" }, tools: ["searchGoogle", "fetchUrl", { appMethod: "saveRestaurant", description: "Persist the researched restaurant." }], outputSchema: { type: "object", properties: { name: { type: "string" }, url: { type: ["string", "null"] } }, required: ["name"] }, model: yourModelId })`. The legacy `structuredOutputExample` option (an example object the model imitates) still works but is unvalidated — check `result.parsedSuccessfully` before using its output. Pass a current tool-use model id (call `listModels` or ask). Don't hardcode one.
|
|
23
23
|
|
|
24
24
|
## Install
|
|
25
25
|
|
|
@@ -1961,3 +1961,32 @@ Grammar: `metrics` from `pageviews | visitors | visits | events`; `dimensions` i
|
|
|
1961
1961
|
**Retention split — the one thing to get right:** queries whose filters are all `is` and touch at most one dimension read a rollup kept forever (full lifetime history, exact unique visitors). Cross-dimension intersections, `is_not`, and `contains` scan raw events retained for 90 days; the server clamps the window and reports it. Check `meta`: `source` (`rollup` vs `events`), `clamped`, `window.served`, and `metricsOmitted` — metrics a shape can't carry (e.g. `visits` on grouped reads) are omitted there, never returned as silent zeros. `meta.total` carries the unpaginated group count for paging.
|
|
1962
1962
|
|
|
1963
1963
|
Specials (same `dateRange`/filter-triple grammar): `analytics.live()` → `{count, countries, sparkline}` right now; `analytics.sources(opts?)` → per-session first-source ranking (UTM > referrer > direct) classified by category/vendor incl. AI assistants; `analytics.map(opts?)` → city lat/lon points; `analytics.aiSources(opts?)` → AI-assistant referrals per vendor; `analytics.crawlers.overview()/timeseries()/recent()` → bot/AI-crawler ingestion of the app's pages.
|
|
1964
|
+
|
|
1965
|
+
#### `events` — server→client realtime (publish/subscribe)
|
|
1966
|
+
|
|
1967
|
+
Publish to named channels from any backend code (a method, a cron, a webhook handler); connected clients receive the payloads instantly over a platform-held stream — live dashboards, notifications, chat, multi-tab/device sync, with no polling and no WebSocket code. Different from `stream()`, which narrates ONE invocation to the caller currently waiting on it: events reach clients that were not part of the invocation at all. Backend only (hook token).
|
|
1968
|
+
|
|
1969
|
+
```typescript
|
|
1970
|
+
import { auth, events } from '@mindstudio-ai/agent';
|
|
1971
|
+
|
|
1972
|
+
// The subscribe door is one of YOUR methods — auth checks first, then mint.
|
|
1973
|
+
// The grant is the ENTIRE subscribe-side authorization: whoever holds the
|
|
1974
|
+
// token receives those channels' events for its lifetime.
|
|
1975
|
+
export async function watchInbox() {
|
|
1976
|
+
auth.requireRole('member');
|
|
1977
|
+
return await events.grant(`user:${auth.userId}`); // { token, expiresAt, ttlSeconds }; ttlSeconds? 60–3600, default 900
|
|
1978
|
+
}
|
|
1979
|
+
|
|
1980
|
+
// Anything can publish — one call, up to 500 channels:
|
|
1981
|
+
const members = await RoomMembers.where({ roomId });
|
|
1982
|
+
const { delivered } = await events.publish(
|
|
1983
|
+
members.map((m) => `user:${m.userId}`),
|
|
1984
|
+
{ type: 'message', roomId, msgId },
|
|
1985
|
+
);
|
|
1986
|
+
```
|
|
1987
|
+
|
|
1988
|
+
The frontend consumes with `events.connect({ getToken, onEvent, onConnect })` from `@mindstudio-ai/interface` — `getToken` calls the minting method, and the SDK handles reconnection and grant renewal.
|
|
1989
|
+
|
|
1990
|
+
**A channel is an audience, and a method decides who is in it.** Never put two users' data on one channel. Default to per-user channels with publish-time fan-out (as above) for membership-gated audiences — removing someone stops their events immediately; reserve a shared channel for genuinely broadcast content (a ticker, a live blog), where revocation waits out the grant TTL. For anonymous visitors `auth.userId` is null — key their channels on `session.visitorId` instead, or `user:null` becomes one channel shared by every anonymous user.
|
|
1991
|
+
|
|
1992
|
+
**Events are at-most-once nudges.** Nothing is buffered while a client is disconnected and nothing replays on connect — clients refetch state in `onConnect` (subscribe for speed, reconcile for truth). `delivered: 0` means nobody is listening right now: normal, never an error. Payloads cap at 32k serialized chars — publish ids (`{ type, id }`), let the client fetch. Channels are exact strings (letters, digits, `: _ - .` — no wildcards), ≤500 per publish, ≤100 per grant. Publishes and grants are scoped to the execution's environment (live/preview/dev) automatically, so a dev-session publish can never reach live users. Debug with `remy-admin events tail | publish | channels list`.
|