MateClaw

English

中文

English

中文

Appearance

v2.1.0 ​

Stable · 2026-08-15 · Previous stable v2.0.0

The big things in this release ​

2.0.0 taught an Agent Team to decompose, dispatch, and deliver. 2.1.0 addresses what appears after teams are used continuously: how one team request becomes a complete run that can be tracked, delivered, and reviewed — and how skills improve safely from real work.

The release centers on Team Runs, a closed skill-evolution loop, and end-to-end observability:

  • Team Run is now a first-class object. One request, its task DAG, worker executions, final synthesis, and deliverables share one runId. Chat delivers results, Agents observes live execution, and Teams owns history and governance; all three consume the same server projection.
  • Team delivery is outcome-first. Worker conversations no longer flood the normal conversation list, intermediate announcements fold into the run card, and final summaries, deliverables, failures, and approval needs appear before implementation detail.
  • Skills gain a complete evolution loop. Post-conversation reflection, cross-session recurring-request mining, promotion, constrained automatic binding, curator governance, snapshots, and restore points form an observable and reversible improvement chain.
  • Reasoning can be replayed in its real order. Inline <think> spans are extracted live, each iteration can be persisted with wall-clock duration, display and retention are independently controllable, and a linear trajectory can be exported.
  • Employees can proactively notify channels. list_channel_sessions and send_channel_message push explicit alerts, reminders, and asynchronous results to verified IM targets. Cron edits now retain both delivery channel and target.
  • Context budgets are model-specific. Known models use catalogued windows instead of a global 128K guess, with per-model operator overrides and expanded GLM/Kimi coverage.
  • Tool, browser, and streaming reliability improve. Progressive tool disclosure reduces large-schema pressure; browser refs, navigation, waits, and session state are hardened; orphaned WebChat streams are reclaimed; upstream bodies have idle timeouts; action requests cannot claim completion without tool-backed execution.

Also included: batch session deletion, live Feishu execution progress, Qwen3-ASR HTTP recognition, improved TTS/STT diagnostics, date-partitioned uploads and generated media, cross-platform attachment lookup, safe handling of 64-bit ids, numeric tool schemas, and OpenAI-compatible generateKwargs passthrough.

1. Team Run: one identity for one round of team work ​

The 2.0 task board could execute work, but one request could still appear as unrelated objects across Chat, Agents, and Teams. 2.1.0 adds the persistent mate_team_run domain object:

  • runId links the originating request, lead conversation, tasks, worker conversations, events, synthesis, and deliverables;
  • one state machine covers planning → running → awaiting_review → finalizing → completed / partial / failed / cancelled;
  • progress, failures, final summary, and deliverables come from the server projection instead of being independently inferred by each UI;
  • source-message idempotency prevents duplicate runs, dispatch begins only after sealing, and cancelling a run cancels non-terminal tasks;
  • Snowflake ids are serialized as strings at the API boundary.

New management endpoints:

text
GET  /api/v1/team-runs/{runId}
GET  /api/v1/teams/{teamId}/runs
GET  /api/v1/teams/{teamId}/runs/page
GET  /api/v1/conversations/{conversationId}/team-runs
GET  /api/v1/conversations/{conversationId}/team-runs/page
POST /api/v1/team-runs/{runId}/cancel

Reads require at least the viewer role in the current workspace; cancelling a run requires admin. Page endpoints use cursor / limit, and team history also accepts activeOnly.

Chat is the delivery surface, Agents Live is the observation surface, and Teams is the governance surface. Historical 2.0 tasks remain readable; tasks without a runId are never guessed into a false aggregate.

See Agent Teams.

2. Skill evolution: from lessons to a reversible improvement chain ​

  • Routine mining clusters each recent conversation's opening user request per employee; it does not mine a full execution trace. The default gate is at least three occurrences on three distinct days within 30 days. Once enabled, the nightly job automatically promotes qualified candidates (at most two per run by default); admins can also promote early, dismiss, or reopen them.
  • Reflection asynchronously reviews the latest 24 messages after eight new messages have accumulated and at least two assistant turns are present. enabled controls whether transcript/catalog data reaches the reviewer model, while auto-apply independently permits writes. With auto-apply off, it observes without mutating; there is no persisted human-approval queue for reflection plans.
  • Automatic binding only adds a newly authored skill when the source employee already has an explicit, non-empty skill allowlist. Employees inheriting all skills need no row, and an explicit no-skills choice is never overridden.
  • Curator governance and adopt/release use “adopt” to hand a user-owned skill to autonomous curation and “release” to return it to user ownership; this is not a record of which employee uses a skill. Curator starts preview-only and mutates only after admin activation. Consolidation remains a separate opt-in, with umbrella creation and source archiving transactional.
  • Snapshots and restore points are captured before every activated mutating sweep and again before restore; five are retained per workspace by default.
  • Origin/governance policy distinguishes built-in, user, agent, and routine. The origin also controls curation scope, so manual adoption intentionally changes user to agent and drives the managed/unmanaged rosters.

The defaults are intentionally conservative: reflection and routine mining are off until explicitly enabled; reflection review and automatic application are separate opt-ins; curator is preview-only until activated, and consolidation defaults off. Untrusted transcripts and skill bodies are delimited; automatic writes allow precise patches or creates, while full replacement, secret exfiltration, approval bypasses, and cross-workspace operations are rejected.

See Skills.

3. Thinking visibility and trajectory export ​

  • Inline <think> content is separated from the answer on the streaming path.
  • Every ReAct iteration can be stored where it occurred, with real start/end timestamps.
  • “Show thinking” and “show all iterations” are admin-editable system settings; operators choose mate.agent.reasoning.retention=all|terminal for persistence.
  • A conversation owner can call GET /api/v1/conversations/{conversationId}/trajectory for a plain-text export that orders user input, reasoning, tool calls, observations, and the final answer. The export itself does not include duration fields.
  • Pre-tool narration becomes superseded once real output arrives. The current chat UI renders it inline, and the text trajectory preserves it as content superseded="true" for audit.

See Chat & Messaging.

4. Proactive channel messages and targeted Cron delivery ​

Employees first call list_channel_sessions to discover recent, pushable conversations in their workspace, then call send_channel_message with the returned id. The supported adapters are QQ, Telegram, WeChat, Slack, Discord, Feishu, DingTalk, and WeCom. A target is pushable only after the bot has received a message and stored the platform delivery handle; the channel must be running, ids cannot be guessed, workspace boundaries are enforced, and one message is capped at 4096 characters.

This is for explicitly requested alerts, reminders, and asynchronous results. Normal replies still use the current conversation. Cron edits now persist both delivery channel and target instead of silently falling back after an update.

See Channels and Tools.

5. Model windows, request parameters, and tool schemas ​

  • Runtime resolution uses operator override → live local-model probe or provider limit-error cache → built-in model catalog → the existing global fallback. The no-I/O model-list view uses only override and catalog values.
  • Operators can set a model window in the console or with PUT /api/v1/models/{providerId}/models/context-window; clearing it restores catalog behavior.
  • GLM-5V-Turbo, Kimi coding aliases, and the rest of the built-in catalog receive explicit windows where known.
  • Workspace members can read the provider choices they are allowed to bind.
  • OpenAI-compatible requests preserve numeric JSON Schema types. Non-reserved top-level generateKwargs keys pass through to the request body; temperature, token limits, topP, reasoningEffort, search, headers, and path keys use one reserved-key reader. Unknown nested chatOptions keys are not forwarded, and reasoningEffort is sent only to explicitly supported model families.

See Models.

6. Browser, progressive tools, and action completion ​

  • browser_use hardens ref state, navigation guards, session gates, wait conditions, and page snapshots; stale refs are rejected after page changes.
  • A progressive tool bridge expands only the schemas needed for the current task, keeping large tool catalogs usable.
  • Tool-backed action policy retries once when the ledger has no successful substantive call, then returns action_unverified; a failed substantive attempt returns action_failed. It prevents unsupported completion claims but does not prove semantic equivalence between a tool result and the user's goal.
  • Tool-name normalization, lookup caching, and id precision fixes reduce long-loop misrouting.

7. Streaming and channel reliability ​

  • WebChat closes SSE on completion/error, detaches disconnected subscribers, and reclaims orphan runs by policy.
  • LLM stream bodies have an idle timeout for connections that remain open without producing data.
  • SSE ids remain monotonic and JavaScript-safe.
  • Feishu cards show live execution progress; sync IM channels no longer persist provisional pre-tool narration as separate permanent messages.
  • First-token pending state, reconnect replay, optimistic-message deduplication, and superseded-content rendering are consistent.

8. Voice, files, and daily operations ​

  • DashScope STT now uses synchronous Qwen3-ASR HTTP recognition with repaired WAV/PCM decoding. TTS/STT errors expose endpoint, status, and a redacted upstream diagnostic.
  • Attachments and generated media are partitioned by date, with consistent lookup on Linux, macOS, and Windows.
  • Sessions can batch-delete up to 200 selected conversations. The server checks ownership per id and deletes only rows the current user may operate. team_worker conversations stay out of the normal sidebar, so they are not selectable from its batch mode.
  • Wiki, memory, Cron, datasource, and JSON detail paths preserve 64-bit ids without lossy conversion.

Upgrade notes ​

Existing configuration and 2.0 team data remain compatible. Flyway applies V175–V184 for the channel-message tool, routine candidates, skill provenance and snapshots, curator observation time, snapshot workspace scope, team workspace isolation, Team Run tables and indexes, conversation kind, and worker-conversation indexes.

  • Self-evolution stays opt-in. Reflection and routine mining default off; enable them only after reviewing data-sharing and automatic-write boundaries.
  • Old tasks are not falsely grouped. They remain visible, while full Run projections apply to runs created through the new protocol.
  • Thinking is visible by default. A workspace admin can hide it or show only the terminal round; storage-sensitive operators can choose terminal retention.
  • Proactive push requires a known conversation. The bot must have received at least one message from the target first.
  • Model overrides are optional. Known models use the catalog; custom/private models should declare an accurate window.
  • New files are date-partitioned. Legacy paths remain readable; backups should cover the entire workspace storage root.

What this release means for you ​

For Agent Teams, a request is finally one durable work record: outcome, files, progress, members, and evidence live under one run.

For skill operators, real work can improve capabilities without giving up explicit controls, workspace isolation, origin policy, or recovery.

For long-task debugging, every reasoning step, tool action, observation, and team execution can be replayed instead of inferred.

2.0 made teams collaborate. 2.1 turns collaboration into a deliverable, learnable, governable run.