mirror of
https://gitee.com/mateos/mateclaw.git
synced 2026-09-21 14:15:55 +08:00
docs: align bilingual docs and sites with v2.3.0
This commit is contained in:
parent
472d184d09
commit
3d48fba1c2
12
README.md
12
README.md
@ -30,7 +30,7 @@
|
||||
|
||||
---
|
||||
|
||||
> **Latest stable: v2.2.0 — a pluggable, recoverable Agent Runtime.** Digital employees can now run on MateClaw's native StateGraph engine or the managed DeepSeek Harness (DSH) runtime while keeping one conversation, policy, tool, persistence, and observability plane. Persistent Goals survive bounded turns and backend restarts, and A2A connects governed employees across systems. Read the [v2.2.0 release notes](https://claw.mate.vip/docs/en/releases/2.2.0).
|
||||
> **v2.3.0 (released 2026-09-20) — JSON acceptance and execution evidence for persistent Goals.** Users can configure required JSON fields and bind checks to current requirements and immutable artifact versions. This release also adds controlled worker intervention and skill document/folder uploads, with fixes for DSH history and output budgets, vLLM reasoning, and SSE framing. [Read the release notes](https://claw.mate.vip/docs/en/releases/2.3.0).
|
||||
|
||||
---
|
||||
|
||||
@ -240,6 +240,16 @@ Full docs at **[claw.mate.vip/docs](https://claw.mate.vip/docs)** — setup, arc
|
||||
|
||||
## Roadmap
|
||||
|
||||
**v2.3.0 (released 2026-09-20) — JSON acceptance and execution evidence for persistent Goals.** Users can configure required JSON fields and bind checks to current requirements and immutable artifact versions. This release also adds controlled worker intervention and skill document/folder uploads, with fixes for DSH history and output budgets, vLLM reasoning, and SSE framing.
|
||||
|
||||
- **Managed JSON acceptance**: users select required fields; the server stores immutable JSON versions, binds checks to requirement revisions and slot generations, and rechecks them at Goal completion.
|
||||
- **Execution evidence**: observe mode records execution and artifacts by default; on-demand version and JSON field diagnostics do not establish Goal acceptance.
|
||||
- **Worker intervention**: handle worker tool approvals, denial, and feedback from team details while retaining conversation governance and exclusive execution.
|
||||
- **Skill uploads**: upload documents, binary files, and folders with directory structure preserved; each file is limited to 10 MiB.
|
||||
- **Reliability fixes**: bounded DSH history/output tokens, vLLM thinking control, SSE line-ending support, bounded spreadsheet extraction, and tool timeouts.
|
||||
|
||||
[↗ v2.3.0](https://claw.mate.vip/docs/en/releases/2.3.0)
|
||||
|
||||
**v2.2.0 (shipped 2026-08-29)** — from one built-in reasoning loop to **a pluggable and recoverable Agent Runtime**:
|
||||
|
||||
- **Runtime contract** — provider registry, session factory, capability validation, normalized event stream, lifecycle, usage, and UI projection decouple employees from execution engines
|
||||
|
||||
12
README_zh.md
12
README_zh.md
@ -30,7 +30,7 @@
|
||||
|
||||
---
|
||||
|
||||
> **最新稳定版:v2.2.0 —— 可插拔、可恢复的 Agent Runtime。** 数字员工现在可以选择 MateClaw 原生 StateGraph 引擎或受管理的 DeepSeek Harness(DSH)运行时,同时复用同一套会话、策略、工具、持久化与可观测面;Persistent Goal 可跨有界回合和后端重启继续,A2A 则让受治理的员工跨系统互联。详见 [v2.2.0 更新记录](https://claw.mate.vip/docs/zh/releases/2.2.0)。
|
||||
> **v2.3.0(2026-09-20 发布)——持久目标的 JSON 验收与执行证据。** 用户可配置 JSON 必需字段,将检查结果绑定到当前要求和不可变产物版本;同时加入团队成员受控干预、技能文档及文件夹上传,并修复 DSH 历史与输出预算、vLLM 推理内容和 SSE 分帧。 [查看完整更新日志](https://claw.mate.vip/docs/zh/releases/2.3.0)。
|
||||
|
||||
---
|
||||
|
||||
@ -240,6 +240,16 @@ mateclaw/
|
||||
|
||||
## 路线图
|
||||
|
||||
**v2.3.0(2026-09-20 发布)——持久目标的 JSON 验收与执行证据。** 用户可配置 JSON 必需字段,将检查结果绑定到当前要求和不可变产物版本;同时加入团队成员受控干预、技能文档及文件夹上传,并修复 DSH 历史与输出预算、vLLM 推理内容和 SSE 分帧。
|
||||
|
||||
- **托管 JSON 验收**:由用户定义必需字段;服务端保存不可变 JSON 版本,按当前要求修订和槽位代次绑定检查,完成目标时重新校验。
|
||||
- **执行证据**:默认观察模式记录执行及产物;按需版本诊断和 JSON 字段诊断不等于目标验收通过。
|
||||
- **团队干预**:在团队详情中处理成员工具审批、拒绝或补充反馈,保留成员会话治理和执行互斥。
|
||||
- **技能上传**:支持文档、二进制文件及文件夹,保留目录结构;单文件最多 10 MiB。
|
||||
- **可靠性修复**:DSH 有界历史及输出 token、vLLM 思考开关、SSE 换行兼容、电子表格提取限制和工具超时。
|
||||
|
||||
[↗ v2.3.0](https://claw.mate.vip/docs/zh/releases/2.3.0)
|
||||
|
||||
**v2.2.0(2026-08-29 发布)** —— 从一套内置推理循环走向**可插拔、可恢复的 Agent Runtime**:
|
||||
|
||||
- **Runtime contract** —— provider registry、session factory、能力校验、统一事件流、生命周期、用量与 UI 投影,让员工身份与执行引擎解耦
|
||||
|
||||
@ -9,6 +9,24 @@ head:
|
||||
|
||||
# Persistent Goals
|
||||
|
||||
## 2.3.0: managed JSON acceptance
|
||||
|
||||
Expand JSON acceptance in the chat Goal panel. An authorized user supplies a requirement key, artifact slot, and required fields (one per line). Active and paused Goals are configurable; terminal Goals are read-only. Requirements belong to the user: model tools cannot change them on the user's behalf.
|
||||
|
||||
1. Select a slot such as `report` and top-level fields such as `summary` and `items`. Requirement keys and slots start with a lowercase letter and contain only lowercase letters, digits, underscores, or hyphens, up to 64 characters.
|
||||
2. The employee calls `getManagedGoalJsonSlots`, then `publishManagedGoalJson` to publish a strict JSON object to a selected slot. The content is stored as a managed version; a workspace file path cannot substitute for publication.
|
||||
3. Call `checkManagedGoalJson` with the current requirement revision, artifact ID, and slot generation. The server derives the result from stored bytes rather than accepting a model-declared PASS.
|
||||
4. Every current requirement needs a matching valid binding, alongside the Goal's existing completion conditions. Changing a requirement or publishing a new generation requires new checks; refresh after a version conflict.
|
||||
|
||||
**Scope and limits:** the current recipe checks only that 1–16 distinct top-level fields exist and are not null; names are 1–128 characters. It is not full JSON Schema, field-type, or business-correctness validation. Each version is limited to 1 MiB UTF-8, each Goal to 32 versions, and versions expire after 24 hours. Expired versions cannot provide a valid completion binding. At the version limit, inspect and reuse a still-valid current version rather than repeatedly publishing.
|
||||
|
||||
### Observation versus acceptance binding
|
||||
|
||||
Execution evidence defaults to `mateclaw.execution-evidence.mode=observe`, recording attempts and artifacts. `off` disables recording; `enforce` is currently rejected. Ordinary artifact version checks and required-field diagnostics run on demand and return `acceptanceEligible=false`; they cannot replace managed JSON bindings. The ordinary checklist still requires every criterion to pass with nonblank evidence.
|
||||
|
||||
Inputs accepted during approval or busy execution retain the selected Goal and requester identity. Recovery rechecks Goal state, account access, and runtime ownership. Queued input cannot automatically revive a terminal Goal.
|
||||
|
||||
|
||||
## Continuous execution (v1)
|
||||
|
||||
New goals default to `persistentExecution=true`; omitted `turnBudget` and `llmCallBudget` become `0` (no cumulative limit). Explicit positive budgets still apply. Existing goals retain legacy mode and do not start automatically after an upgrade.
|
||||
|
||||
@ -18,8 +18,14 @@ hero:
|
||||
- theme: alt
|
||||
text: GitHub
|
||||
link: https://github.com/mateaix/mateclaw
|
||||
- theme: alt
|
||||
text: v2.3.0 Release Notes
|
||||
link: /en/releases/2.3.0
|
||||
|
||||
features:
|
||||
- icon: ✅
|
||||
title: 2.3.0 — Managed JSON acceptance
|
||||
details: Users select required top-level fields; the server binds checks to current requirements and immutable JSON versions. Execution evidence defaults to observation, and ordinary artifact diagnostics do not replace acceptance bindings.
|
||||
- icon: ⚙️
|
||||
title: Employee runtimes, not one Agent loop
|
||||
details: 2.2.0 uses a shared Runtime Contract to decouple employee identity from execution. Native and DeepSeek Harness share conversations, workspaces, tool governance, and event projection; durable Goals recover across requests and backend restarts, while A2A connects external agents.
|
||||
|
||||
@ -9,6 +9,8 @@ head:
|
||||
|
||||
# MateClaw — Self-hosted Multi-Agent AI Operating System
|
||||
|
||||
**v2.3.0 (released 2026-09-20) — JSON acceptance and execution evidence for persistent Goals.** Users can configure required JSON fields and bind checks to current requirements and immutable artifact versions. This release also adds controlled worker intervention and skill document/folder uploads, with fixes for DSH history and output budgets, vLLM reasoning, and SSE framing. [v2.3.0](./releases/2.3.0)
|
||||
|
||||
**Your multi-agent AI. On your hardware. Under your rules.**
|
||||
|
||||
MateClaw is a full AI operating system you deploy yourself. One JAR. One login. You control persisted data and outbound integrations.
|
||||
|
||||
@ -10,7 +10,7 @@ For historical diffs, check the corresponding git tag. For the "why" behind a fe
|
||||
|
||||
| Version | Date | Highlights |
|
||||
|---------|------|------------|
|
||||
| [v2.3.0](./releases/2.3.0) | 2026-09-20 | Managed JSON Goal acceptance and immutable artifact versions · Execution evidence and controlled worker intervention · Approval/queued-input recovery and identity isolation · Skill document/folder uploads · DSH, reasoning-model, and SSE fixes |
|
||||
| [v2.3.0](./releases/2.3.0) | 2026-09-20 | User-configured managed JSON field acceptance and immutable artifact versions · Observe-mode execution evidence and controlled worker intervention · Approval/queued-input recovery and identity isolation · Skill document/folder uploads · DSH, reasoning-model, and SSE fixes |
|
||||
| [v2.2.0](./releases/2.2.0) | 2026-08-29 | **Runtime mainline** — employee runtime contract + provider registry + session lifecycle decouple employees from the built-in reasoning loop; **DeepSeek Harness** joins through an authenticated JSON-RPC child process while tools remain governed by host workspace policy and Tool Guard, with install/configure/verify/enable management; **durable Goals recover across bounded segments and backend restarts** (database queue · supervisor · leases · attempts · accepted-input queue · provider backoff · evidence-gated checklist completion); **bidirectional A2A** (Agent Cards · message send/stream · task get/cancel · `call_a2a_agent` · SSRF/timeout/response caps); hardened Team checkpoints, board recovery, deliverable gates, worker attachments, and long-form output; optional OfficeCLI + ACP prompt timeout + tighter workspace boundaries |
|
||||
| [v2.1.0](./releases/2.1.0) | 2026-08-15 | **Unified Team Runs** — one request, task DAG, worker execution, final synthesis, and deliverables share a `runId`; Chat delivery / Agents observation / Teams governance consume one projection, while worker conversations stay out of the normal sidebar · **closed skill-evolution loop** (cross-session recurring-request mining · reflection · constrained auto-binding · curator governance handover · origin policy · snapshots and restore points, workspace-scoped and conservative by default) · **replayable reasoning** (live `<think>` extraction · UI wall-clock duration · all/terminal display controls · plain-text trajectory export) · proactive channel push + targeted Cron delivery · context-window override/probe/catalog budgeting · progressive tool bridge + action completion policy · hardened browser refs/navigation/waits · WebChat/SSE/LLM stream cleanup and timeouts · Feishu execution progress · Qwen3-ASR HTTP · batch session deletion · date-partitioned files · 64-bit id and numeric tool-schema precision fixes |
|
||||
| [v2.0.0](./releases/2.0.0) | 2026-07-31 | **Agent Teams with a shared task board** — the lead decomposes, members execute in parallel (teams/roles · eight-status kanban · `blockedBy` dependency orchestration · automatic prerequisite hand-off · settled results wake the lead · deliverable registration & download · task timeline + team SSE live board · execution lease heartbeat + cancel-interrupt + `in_review` approval gates) · **Plan-Execute plans hand over to the board** (steps→tasks · dependencies→parallelism · parked-plan resume gate for deterministic synthesis) · Workspace isolation fully sealed (channel-scoped conversation ids · same-named skills coexist per workspace with conversation-scoped runtime resolution) · Channel magic commands (`/new` `/clear` `/status` `/stop` `/model` `/help`) + WeCom event-driven progress bubble (live tool trace · per-stage rolling narration) · Server-side rewind/regenerate semantics · Explainable auto-approval misses (reason codes on audit rows + one-click grant creation + anti-footgun forms) · Policy-driven LLM error recovery (overload vs rate-limit split · `Retry-After`-aware backoff · provider TTL readmission · jitter against retry storms) · In-chat attachment preview (pdf/docx/xlsx/html/text) · Single-source SKILL.md + console bundle-file management · Optional Mem0 plugin memory provider · Knowledge-graph relation schema whitelist |
|
||||
|
||||
@ -169,6 +169,16 @@ Full story: [v2.1.0 release notes](./releases/2.1.0.md); guides: [Team Runs](./t
|
||||
|
||||
Full story: [v2.2.0 release notes](./releases/2.2.0.md); guides: [DeepSeek Harness](./deepseek-harness), [Persistent Goals](./goals), and [A2A](./a2a).
|
||||
|
||||
### v2.3 — JSON acceptance and execution evidence ✅ Released (2026-09-20)
|
||||
|
||||
- **Managed JSON acceptance**: users select required fields; the server stores immutable JSON versions, binds checks to requirement revisions and slot generations, and rechecks them at Goal completion.
|
||||
- **Execution evidence**: observe mode records execution and artifacts by default; on-demand version and JSON field diagnostics do not establish Goal acceptance.
|
||||
- **Worker intervention**: handle worker tool approvals, denial, and feedback from team details while retaining conversation governance and exclusive execution.
|
||||
- **Skill uploads**: upload documents, binary files, and folders with directory structure preserved; each file is limited to 10 MiB.
|
||||
- **Reliability fixes**: bounded DSH history/output tokens, vLLM thinking control, SSE line-ending support, bounded spreadsheet extraction, and tool timeouts.
|
||||
|
||||
[v2.3.0](./releases/2.3.0) · [Goals](./goals) · [Teams](./teams) · [Skills](./skills)
|
||||
|
||||
---
|
||||
|
||||
## Next: Resident runtimes & Team follow-through
|
||||
|
||||
@ -1,5 +1,15 @@
|
||||
# Skills
|
||||
|
||||
## 2.3.0: document and folder uploads
|
||||
|
||||
In skill file management, select `references/`, `templates/`, or `scripts/`, then upload files or choose a folder. The selected folder and descendants remain under that bucket, for example `references/manual/chapter.pdf`. The upload endpoint requires workspace admin access; built-in skill files are read-only. Replacing an existing path requires confirmation.
|
||||
|
||||
- The server limits each file to **10 MiB**. The frontend batch planner allows at most **100 files totaling 50 MiB**.
|
||||
- Text is stored as UTF-8; binary content is stored as Base64 and restored to bytes when synchronized into the skill working directory. Binary files cannot be edited as text; upload a replacement instead.
|
||||
- Paths are validated; traversal, invalid separators, duplicate destinations, and overly long paths are rejected.
|
||||
- Uploading manages skill attachments; it does not establish that an attachment has been read, executed, or content-validated.
|
||||
|
||||
|
||||
**A skill is a tool that thinks in sentences.**
|
||||
|
||||
Tools are atomic — read a file, send an HTTP request, run a command. Skills are compositions — "research this topic and write a brief", "review this code and comment on it", "turn my git log into a standup update". A skill is a `SKILL.md` file that combines instructions, parameters, prompt templates, optional scripts, and a list of tools the skill needs. The runtime loads it, renders it with your inputs, and hands the result to the agent.
|
||||
@ -192,7 +202,8 @@ The database is the source of truth, the filesystem is a materialized cache. Tha
|
||||
| `id` | Primary key |
|
||||
| `skill_id` | FK to `mate_skill` |
|
||||
| `file_path` | Relative path like `scripts/run.py` or `references/cfg.md` |
|
||||
| `content` | UTF-8 text (defaults: ≤1 MB per file, ≤50 MB per bundle — configurable via `mateclaw.skill.upload.max-entry-size-mb` / `max-total-size-mb`) |
|
||||
| `content` | Text or Base64-encoded binary content (2.3.0+); see upload limits above |
|
||||
| `content_encoding` | `utf8` or `base64` (added by V202); synchronization restores the original bytes |
|
||||
| `content_size` | Byte count (so listings don't have to load the blob) |
|
||||
| `sha256` | Content fingerprint, drives the syncer's idempotent diff |
|
||||
|
||||
|
||||
@ -9,6 +9,13 @@ head:
|
||||
|
||||
# Team Runs and Agent Teams (2.1.0+)
|
||||
|
||||
## 2.3.0: controlled worker intervention
|
||||
|
||||
Team run details can resolve a worker's pending tool approval, replay an approved call in its governed conversation, or deny it. Feedback can supply missing information; it is limited to 4000 characters, and pending approvals must be resolved first.
|
||||
|
||||
These operations still validate task, run, worker conversation, and access scope. The member must be idle and the operation must acquire a conversation execution permit; it cannot inject a concurrent turn into a busy worker. If approved replay fails with an uncertain external side effect, the task is parked for review instead of treating approval as an unconditional retry.
|
||||
|
||||
|
||||
> **Before: one employee with sub-tasks. Now: a team around a shared task board.**
|
||||
|
||||
Sub-agent delegation (`delegateToAgent`) solves "one person temporarily calls a helper": synchronous, one-to-one, black-box. But real complex delivery looks like a project: **break down tasks, declare dependencies, run in parallel, gate on approvals, archive deliverables, and see who is doing what at any time**.
|
||||
|
||||
@ -9,6 +9,24 @@ head:
|
||||
|
||||
# 持久化目标
|
||||
|
||||
## 2.3.0:托管 JSON 验收
|
||||
|
||||
在聊天目标面板展开 JSON 验收,由有权限的用户填写要求键、产物槽位和必需字段(每行一个)。活跃或暂停的目标可以配置;终态目标只读。配置入口属于用户,模型工具不能替用户修改验收标准。
|
||||
|
||||
1. 为要求指定一个产物槽位,例如 `report`,填写 `summary`、`items` 等顶层字段。要求键和槽位须以小写字母开头,只含小写字母、数字、下划线或连字符,最长 64 字符。
|
||||
2. 员工先调用 `getManagedGoalJsonSlots`,再用 `publishManagedGoalJson` 向已选择的槽位发布严格 JSON 对象。内容保存在托管版本中,工作空间文件路径不能代替发布内容。
|
||||
3. 调用 `checkManagedGoalJson`,提供当前要求修订、产物 ID 和槽位代次。服务端从存储字节计算结果,不接受模型自行声明的 PASS。
|
||||
4. 所有当前要求均有匹配的有效绑定,且目标原有完成条件也满足后,才可完成目标。修改要求或发布新代次后需要重新检查;发生版本冲突时先刷新。
|
||||
|
||||
**检查范围与限制:**当前 recipe 只检查 1–16 个不同的顶层字段是否存在且非 null;每个字段名 1–128 字符。这不是完整 JSON Schema、字段类型或业务内容正确性校验。每个版本最多 1 MiB UTF-8,每个目标最多 32 个版本,版本有效期 24 小时;过期版本不能用于有效完成绑定。达到版本上限时应先查看并复用仍有效的当前版本,不要盲目反复发布。
|
||||
|
||||
### 观察证据与验收绑定的区别
|
||||
|
||||
执行证据默认使用 `mateclaw.execution-evidence.mode=observe`,记录执行尝试及产物信息;`off` 可关闭记录,当前 `enforce` 配置会被拒绝。普通产物的版本检查及 JSON 必需字段诊断是按需检查,结果 `acceptanceEligible=false`,不能代替上述托管 JSON 绑定。普通清单仍要求全部通过并提供非空证据。
|
||||
|
||||
审批或忙碌期间接收的输入会保留所选目标与请求者身份;恢复时重新检查目标状态、账户和运行所有权。终态目标不能靠排队输入自动复活。
|
||||
|
||||
|
||||
## 持续执行模式(第一版)
|
||||
|
||||
新建目标默认 `persistentExecution=true`,省略预算时 `turnBudget=0`、`llmCallBudget=0` 表示不设累计上限。显式正预算仍生效;已有目标保留旧模式,不会在升级后自动启动。
|
||||
|
||||
@ -18,8 +18,14 @@ hero:
|
||||
- theme: alt
|
||||
text: GitHub
|
||||
link: https://github.com/mateaix/mateclaw
|
||||
- theme: alt
|
||||
text: v2.3.0 更新日志
|
||||
link: /zh/releases/2.3.0
|
||||
|
||||
features:
|
||||
- icon: ✅
|
||||
title: 2.3.0 — 托管 JSON 验收
|
||||
details: 用户指定顶层必需字段,服务端把检查绑定到当前要求与不可变 JSON 版本。默认观察模式的执行证据用于追踪;普通产物诊断不代替验收绑定。
|
||||
- icon: ⚙️
|
||||
title: 员工 Runtime,不只一种 Agent Loop
|
||||
details: 2.2.0 用统一 Runtime Contract 把员工身份与推理引擎解耦。Native 与 DeepSeek Harness 共用会话、工作空间、工具治理和事件投影;持久目标跨请求与后端重启恢复,A2A 连接外部 Agent。
|
||||
|
||||
@ -9,6 +9,8 @@ head:
|
||||
|
||||
# MateClaw — 自部署多智能体 AI 操作系统
|
||||
|
||||
**v2.3.0(2026-09-20 发布)——持久目标的 JSON 验收与执行证据。** 用户可配置 JSON 必需字段,将检查结果绑定到当前要求和不可变产物版本;同时加入团队成员受控干预、技能文档及文件夹上传,并修复 DSH 历史与输出预算、vLLM 推理内容和 SSE 分帧。 [v2.3.0](./releases/2.3.0)
|
||||
|
||||
**你的多智能体 AI,跑在你自己的机器上,按你自己的规则。**
|
||||
|
||||
MateClaw 是一整套可以自部署的 AI 操作系统。一个 JAR 包,一套登录,持久化数据和外发集成由你掌控。
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
|
||||
| 版本 | 日期 | 亮点 |
|
||||
|------|------|------|
|
||||
| [v2.3.0](./releases/2.3.0) | 2026-09-20 | 持久目标 JSON 验收与不可变产物版本 · 执行证据与受控团队干预 · 审批/排队输入恢复与身份隔离 · 技能文档/文件夹上传 · DSH、推理模型与 SSE 加固 |
|
||||
| [v2.3.0](./releases/2.3.0) | 2026-09-20 | 用户配置的托管 JSON 字段验收与不可变产物版本 · 观察模式执行证据与受控团队干预 · 审批/排队输入恢复与身份隔离 · 技能文档/文件夹上传 · DSH、推理模型与 SSE 加固 |
|
||||
| [v2.2.0](./releases/2.2.0) | 2026-08-29 | **Runtime 主线**——员工运行时 contract + provider registry + session 生命周期,把员工与内置推理循环解耦;**DeepSeek Harness** 以认证 JSON-RPC 子进程接入,工具继续经过宿主工作空间策略与 Tool Guard,并提供安装/配置/校验/启停管理;**持久目标跨有界片段和后端重启恢复**(数据库队列 · supervisor · lease · attempt · 输入排队 · provider 退避 · checklist 证据完成门);**A2A 双向互联**(Agent Card · message/send/stream · task 查询/取消 · `call_a2a_agent` · SSRF/超时/响应上限);Team checkpoint / 任务板恢复 / 交付物完成门 / worker 附件与长回答加固;可选 OfficeCLI 引擎 + ACP prompt timeout + 工作空间边界收口 |
|
||||
| [v2.1.0](./releases/2.1.0) | 2026-08-15 | **统一 Team Run**——一次团队请求、任务 DAG、成员执行、最终汇总与交付物共用 `runId`,Chat 成果交付 / Agents 实时观察 / Teams 历史治理读取同一投影,成员子会话不再污染普通会话列表 · **Skill 自进化闭环**(跨会话重复请求 mining · reflection · 受约束自动绑定 · curator 治理移交 · origin 策略 · 快照与恢复点,按工作空间隔离且默认保守) · **推理轨迹可回放**(实时 `<think>` 提取 · UI 真实耗时 · 全部/最终轮次控制 · 纯文本 trajectory 导出) · 主动渠道消息 + Cron 定向投递 · 模型窗口覆盖/探测/目录预算 · 渐进式工具桥 + 行动完成约束 · 浏览器 ref/导航/等待加固 · WebChat/SSE/LLM 流回收与超时 · 飞书执行进度 · Qwen3-ASR HTTP · 会话批量删除 · 按日文件目录 · 64 位 id 与数值工具 schema 精度修复 |
|
||||
| [v2.0.0](./releases/2.0.0) | 2026-07-31 | **Agent 团队与共享任务板**——Lead 拆任务、成员并行执行(团队/角色 · 八状态看板 · `blockedBy` 依赖编排 · 前置结果自动传递 · 结果通报唤醒 Lead · 交付物登记下载 · 任务时间线 + 团队 SSE 实时看板 · 执行租约心跳 + 取消即中断 + `in_review` 审批卡点) · **Plan-Execute 计划整体移交任务板**(步骤→任务 · 依赖→并行 · 停靠恢复门确定性汇总) · 工作空间隔离全面收口(渠道会话 id 编入渠道 · 同名技能跨工作空间共存且运行时按会话工作空间解析) · 渠道魔法命令(`/new` `/clear` `/status` `/stop` `/model` `/help`)+ 企微事件驱动进度气泡(实时工具轨迹 · 分阶段滚动叙述) · 会话回退/重新生成服务端语义 · 自动批准未命中可解释(原因码落审计行 + 一键补策略 + 表单防呆) · LLM 错误恢复策略化(过载/限流分治 · `Retry-After` 回馈退避 · provider TTL 回收 · 抖动防重试风暴) · 聊天附件在线预览(pdf/docx/xlsx/html/文本) · SKILL.md 单一事实源 + 捆绑文件控制台管理 · Mem0 可选插件记忆 provider · 知识图谱关系模式白名单 |
|
||||
|
||||
@ -169,6 +169,16 @@ MateClaw 就是这个东西。
|
||||
|
||||
完整故事:[v2.2.0 Release Notes](./releases/2.2.0.md),使用指南:[DeepSeek Harness](./deepseek-harness)、[持久化目标](./goals)、[A2A 协议](./a2a)。
|
||||
|
||||
### v2.3 — JSON 验收与执行证据 ✅ 已发布(2026-09-20)
|
||||
|
||||
- **托管 JSON 验收**:由用户定义必需字段;服务端保存不可变 JSON 版本,按当前要求修订和槽位代次绑定检查,完成目标时重新校验。
|
||||
- **执行证据**:默认观察模式记录执行及产物;按需版本诊断和 JSON 字段诊断不等于目标验收通过。
|
||||
- **团队干预**:在团队详情中处理成员工具审批、拒绝或补充反馈,保留成员会话治理和执行互斥。
|
||||
- **技能上传**:支持文档、二进制文件及文件夹,保留目录结构;单文件最多 10 MiB。
|
||||
- **可靠性修复**:DSH 有界历史及输出 token、vLLM 思考开关、SSE 换行兼容、电子表格提取限制和工具超时。
|
||||
|
||||
[v2.3.0](./releases/2.3.0) · [持久目标](./goals) · [团队](./teams) · [技能](./skills)
|
||||
|
||||
---
|
||||
|
||||
## 下一站:常驻 Runtime 与团队进阶
|
||||
|
||||
@ -1,5 +1,15 @@
|
||||
# 技能系统
|
||||
|
||||
## 2.3.0:文档与文件夹上传
|
||||
|
||||
在技能文件管理中选择 `references/`、`templates/` 或 `scripts/`,上传文件或选择文件夹。文件夹及子目录保留在所选分类下,例如 `references/manual/chapter.pdf`。上传接口要求工作空间管理员权限;内置技能文件只读。覆盖已有路径前需要确认。
|
||||
|
||||
- 服务端限制单文件 **10 MiB**;前端批量规划限制最多 **100 个文件、合计 50 MiB**。
|
||||
- 文本按 UTF-8 保存,二进制按 Base64 编码存储并在同步到技能工作目录时恢复为字节。二进制文件不能作为文本编辑,可重新上传替换。
|
||||
- 路径经过校验;不接受目录穿越、非法分隔符或重复目标路径。超长路径会被拒绝。
|
||||
- 文件上传是技能附件管理,并不自动代表附件已被读取、执行或通过内容校验。
|
||||
|
||||
|
||||
**一个技能是一个"用句子思考"的工具。**
|
||||
|
||||
工具是原子的——读一个文件、发一个 HTTP 请求、跑一个命令。技能是**组合**——"调研这个话题然后写一份简报"、"审这段代码并给出评论"、"把我的 git log 变成 standup 汇报"。一个技能是一份 `SKILL.md` 文件,把指令、参数、prompt 模板、可选脚本和需要的工具列表组合在一起。
|
||||
@ -192,7 +202,8 @@ scripts:
|
||||
| `id` | 主键 |
|
||||
| `skill_id` | 外键到 `mate_skill` |
|
||||
| `file_path` | `scripts/run.py` 或 `references/cfg.md` 这种相对路径 |
|
||||
| `content` | UTF-8 文本(默认单文件 ≤1 MB、bundle ≤50 MB,可通过 `mateclaw.skill.upload.max-entry-size-mb` / `max-total-size-mb` 调整) |
|
||||
| `content` | 文本内容或 Base64 编码的二进制内容(2.3.0+);单文件上传限额见本页上传说明 |
|
||||
| `content_encoding` | `utf8` 或 `base64`(V202 新增),同步时按编码恢复原始字节 |
|
||||
| `content_size` | 字节数(不用拉 blob 就能列) |
|
||||
| `sha256` | 内容指纹,给同步器做幂等 diff |
|
||||
|
||||
|
||||
@ -9,6 +9,13 @@ head:
|
||||
|
||||
# Team Run 与团队协作(2.1.0+)
|
||||
|
||||
## 2.3.0:受控成员干预
|
||||
|
||||
团队运行详情可处理成员等待中的工具审批,批准后在受控成员会话中回放,或拒绝该调用;需要补充信息时可提交反馈。反馈最长 4000 字符,有待处理审批时须先处理审批。
|
||||
|
||||
这些操作仍校验任务、运行、成员会话和权限归属,并要求成员空闲、获取会话执行许可。不能在成员忙碌时直接插入另一轮执行。若获批工具回放失败且外部副作用不确定,任务会停靠等待复核,不能把再次批准当作无条件重试。
|
||||
|
||||
|
||||
> **以前是"一个员工带子任务"。现在是"一个团队围着一块任务板"。**
|
||||
|
||||
子员工委派(`delegateToAgent`)解决的是"一个人临时叫帮手":同步等结果、一对一、过程黑盒。但真实的复杂交付不长这样——它长得像一个项目:**拆任务、标依赖、并行推进、卡点审批、交付物归档、随时能看谁在干什么**。
|
||||
|
||||
Loading…
Reference in New Issue
Block a user