DeepSeek Harness 爆火之后，再看 MateClaw 2.1.0：企业级 Agent Harness 如何做到“一切皆插件、协作皆可治理”

MateCloud微服务

337人浏览 · 2026-08-17 21:10:52

MateCloud微服务 · 2026-08-17 21:10:52 发布

摘要： MateClaw 2.1.0 正式发布。本次升级以 Team Run 统一多 Agent 执行，引入可回放 trajectory、可回滚的 Skill 自进化，以及受权限与审计约束的插件化能力，尝试解决 Agent 从“能运行”走向“可长期运营”的工程问题。

在这里插入图片描述

前言：为什么大家突然开始讨论 Harness？

最近，DeepSeek 官方开源、目前仍处于 Developer Preview 的 DeepSeek Harness 获得了大量关注。它在 README 中用一句话概括自己的架构：

Everything is a Plugin.

这句话带火的不只是“插件”概念，更是 Agent Harness 这个长期被模型能力遮住的工程层。

如果把大模型看作大脑，那么 Harness 就是让它真正工作的环境：上下文怎样组织、工具怎样发现和调用、执行状态怎样保存、失败怎样重试、记忆怎样注入、危险动作怎样审批、结果怎样交付。

模型决定能力上限，Harness 决定这些能力能否稳定进入真实工作。

MateClaw 从一开始就把自己定位为 Agent Harness。它并不建立在 DeepSeek Harness 之上，两者的产品方向也不相同；值得关注的是两者对架构趋势的判断趋于一致：模型可以更换，工具可以扩展，但承载工作的运行时必须稳定。

MateClaw 2.1.0 进一步把这个判断落到多 Agent 团队场景：

一切都可以是插件，但一切执行都必须进入统一的运行、权限、审批和审计边界。

一、多 Agent 系统缺的往往不是 Agent，而是“运行”

2.0.0 已经让 MateClaw 的多个数字员工围绕共享任务板工作：Lead 拆任务，成员并行执行，Reviewer 负责审核，任务之间通过 blockedBy 描述依赖。

但任务板解决的是“如何执行”，没有完全回答“这一批任务共同属于哪一次用户请求”。

当任务持续时间变长、参与成员增加后，系统很容易出现几种割裂：

Chat 中看到一份回答；
Agents 页面看到多个成员运行；
Teams 页面看到一批任务；
交付文件散落在不同消息和任务记录里；
每个前端页面根据局部数据推测整体状态。

这也是不少多 Agent Demo 进入生产环境后的典型问题：Agent 很多，消息很多，但缺少一个稳定的业务实例。

二、Team Run：用一个 runId 串起完整团队工作

MateClaw 2.1.0 新增持久化 Team Run。一次团队请求会获得稳定的 runId，用于关联：

用户目标
 ├─ Lead 会话
 ├─ 任务 DAG
 ├─ 成员子会话
 ├─ 工具调用与运行事件
 ├─ 审批、证据和异常
 └─ 最终摘要与交付物

在这里插入图片描述

Team Run 使用统一生命周期：

planning
→ running
→ awaiting_review
→ finalizing
→ completed / partial / failed / cancelled

进度、失败数、最终摘要和交付物由后端统一投影。Chat、Agents Live 和 Teams 不再分别猜测运行状态，而是读取同一份服务端数据：

Chat：成果交付面，优先展示摘要、文件和需要用户关注的问题；
Agents Live：实时观察面，按 runId 聚合正在工作的成员；
Teams：历史与治理面，下钻任务、时间线、证据和审批记录。

管理 API 包括：

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

读取接口至少要求当前工作空间 Viewer 权限，取消整个运行要求 Admin 权限。Snowflake ID 对外按字符串返回，避免 JavaScript 对 64 位整数的精度损失。

这个设计看起来只是多了一张 mate_team_run 表，但其意义更接近传统业务系统里的订单、工单或工作流实例：每一次团队工作终于有了可以追踪、取消和审计的身份。

三、成果优先：别让成员会话淹没最终交付

多 Agent 系统很容易把“过程透明”做成“过程刷屏”。

成员接受任务、开始分析、调用工具、等待依赖、重新尝试，可能分别形成一条消息。最终结果反而埋在大量中间通报里。

2.1.0 对交付层级进行了调整：

team_worker 子会话不再进入普通会话侧栏；
中间进度聚合到 Team Run 卡片；
最终摘要和交付文件优先显示；
失败任务、异常和待审批项重点提示；
成员轨迹、证据和任务详情按需展开。

这并不是减少可观测性，而是把不同信息交给真正需要它的人：普通使用者先拿成果，团队管理员查看过程，排障人员继续追到工具和事件级证据。

四、Skill 自进化：Agent 可以学习，但必须可控、可回滚

Agent 长期处理真实工作后，会积累大量重复请求和经验。如果每次都从零开始，系统并没有真正形成组织能力。

MateClaw 已经使用 SKILL.md 描述技能，并用 LESSONS.md 记录经验。2.1.0 补齐了持续改进闭环：

Reflection：异步审阅近期对话，提取可复用经验；
Routine Mining：聚类跨会话重复出现的用户请求；
候选晋升：把稳定模式转化为新 Skill；
受约束自动绑定：只在员工已有的明确技能边界内补充绑定；
Curator 治理：管理来源、采纳、释放与合并；
Snapshots / Restore Points：变更前捕获快照，必要时恢复。

在这里插入图片描述

这一链路的重点不是“让模型随便修改提示词”，而是把自动改进变成可治理的工程流程。

默认策略是保守的：

Reflection 和 Routine Mining 默认关闭；
审阅与自动应用分别 opt-in；
Curator 激活前只预览，不执行生命周期变更；
自动写入仅允许精确 patch 或 create；
跨工作空间修改、整篇覆盖、秘密外发和绕过审批会被拒绝；
默认每个工作空间保留 5 个恢复点。

这使“Agent 会学习”从一句营销描述，变成可以打开、关闭、观察、回滚和审计的系统能力。

五、trajectory：执行过程不再靠聊天记录猜

ReAct Agent 的真实执行通常是：

推理 → 工具调用 → 观察结果 → 再次推理 → 工具调用 → 最终回答

如果只保存最终回答，长任务失败后几乎无法判断模型在哪一步走偏。

2.1.0 支持：

实时提取内联 <think>；
按发生顺序持久化每轮推理；
保存工具调用和观察结果；
记录各阶段真实耗时；
按配置保留全部轮次或最终轮次；
通过 trajectory API 导出线性记录。

在这里插入图片描述

导出接口：

GET /api/v1/conversations/{conversationId}/trajectory

另一个容易被忽略的问题是“文本声称已经完成，但工具根本没有调用”。

2.1.0 为行动型请求增加了完成约束：运行账本不存在成功的实质性工具调用时，系统先重试；仍未调用则标记 action_unverified，调用失败则标记 action_failed，不能只用一句“操作成功”结束。

它还不能证明工具结果与用户目标在语义上完全等价，但至少消除了最基础的“没有行动却声称完成”。

六、“一切皆插件”在 MateClaw 中是什么？

MateClaw 的插件理念并不等于“所有东西都打包成同一种 JAR”。不同扩展层解决不同问题：

扩展层	作用
Java Plugin SDK	通过 `ChannelAdapter`、`Tool`、`MemoryProvider`、`Hook` 等 SPI 扩展进程内能力
MCP	通过 stdio、SSE 或 Streamable HTTP 接入外部工具服务
SKILL.md	组合指令、工具和经验，形成可学习的业务能力骨架
ACP	将 Claude Code、Codex 等专业 Agent 接入为数字员工
Provider 接口	替换或增加模型、搜索、记忆和多模态供应商
Channel Adapter	接入飞书、钉钉、企业微信、Telegram、Slack 等消息入口

MateClaw 默认提供完整运行时，并不是只提供一个等待拼装的空壳。插件化的目的，是让核心运行时保持稳定，让外围能力可以按团队环境持续生长。

对于企业场景，插件还必须进入统一边界：

哪个工作空间安装和使用；
哪位员工可以看到；
是否需要人工审批；
调用了什么工具；
产生了哪些文件和外部动作；
失败后能否定位和恢复。

所以 MateClaw 2.1.0 对“一切皆插件”的补充是：能力可以自由组合，执行必须接受治理。

七、更多生产级更新

除三条主线外，2.1.0 还包括：

单模型上下文窗口目录和管理员覆盖；
渐进式 Tool Schema 披露；
OpenAI 兼容 generateKwargs 顶层参数透传；
integer/number 类型 Tool JSON Schema 修复；
browser_use 的过期 ref、导航和等待机制增强；
WebChat/SSE 断连清理和 LLM 响应体 idle timeout；
飞书流式执行进度；
Qwen3-ASR HTTP 识别链路；
会话批量删除；
上传和生成文件按日期分区；
工具输入及 JSON 详情中的 64 位 ID 精度保护。

八、技术栈与快速部署

MateClaw 后端基于 Spring Boot 3.5 和 Spring AI Alibaba，Agent 运行时使用 StateGraph，前端采用 Vue 3 + TypeScript。项目使用 Apache 2.0 许可证。

Docker Compose 启动：

git clone https://github.com/mateaix/mateclaw.git
cd mateclaw
cp .env.example .env
docker compose up -d

访问：

http://localhost:18080

默认账号：

admin / admin123

首次登录后请立即修改密码。

2.1.0 与现有 2.0.0 配置和团队数据兼容，Flyway 会自动执行数据库迁移。旧任务仍可查看，但只有升级后创建的运行具备完整 Team Run 投影。

写在最后

Agent 应用正在从“选择哪个模型”进入“怎样构建 Harness”的阶段。

模型能力会持续变化，但团队真正需要长期积累的是另一层资产：工具、技能、记忆、工作流、权限策略、执行记录和交付标准。

MateClaw 2.1.0 希望把这些能力收进一个可以自部署、可以扩展、也可以治理的 Java Agent Harness：

一切皆插件，协作皆可治理。

所有评论(0)

查看更多评论

MateCloud微服务

@bufegar0

已为社区贡献2条内容

DeepSeek Harness 爆火之后，再看 MateClaw 2.1.0：企业级 Agent Harness 如何做到“一切皆插件、协作皆可治理”

MateCloud微服务

前言：为什么大家突然开始讨论 Harness？

一、多 Agent 系统缺的往往不是 Agent，而是“运行”

二、Team Run：用一个 runId 串起完整团队工作

三、成果优先：别让成员会话淹没最终交付

四、Skill 自进化：Agent 可以学习，但必须可控、可回滚

五、trajectory：执行过程不再靠聊天记录猜

六、“一切皆插件”在 MateClaw 中是什么？

七、更多生产级更新

八、技术栈与快速部署

写在最后

所有评论(0)

温馨提示：您尚未绑定手机号

MateCloud微服务