v1.5.0
正式版 · 2026-06-04 · 上一稳定版本 v1.4.0
这一版做了三件大事
让我直接说。
v1.4.0 我们让员工更自主——你定一个目标，它锁住、自检、自己续命。但那个"自检"是模糊的：evaluator 给一个 0~1 的分，到底差在哪、还有几条没做完，你看不清。
这一版我们把焦点放在让自主变得可验证、让知识库会自己维护、让整个系统真正多人可用这三件事上。
第一，目标长出了清单（checklist）。 不再是一个模糊的分数。员工把目标拆成几条可以逐条验证的准则，每轮答完，evaluator 一条一条勾。全勾完才算完成——没有"差不多 95% 就放过"。头像旁边那圈光 hover 出来，是一张能看到每一条勾没勾的清单。
第二，Wiki 学会了自己维护自己。 页面之间用 [[wikilink]] 互联、改名/删页自动级联修链、坏链一键体检；知识分"事实层 / 经验层"，事实页改了，依赖它的经验页自动标记"待复核"；页面类型（pageType）能配 schema 和权限，不同员工能读/能写哪类页各自受控；还能挂处理流水线，页面到达某个条件就自动跑一段 LLM 或技能；本地目录能挂成知识源，定时增量同步。
第三，记忆认人了。 以前一个员工的记忆是一锅粥——谁聊的都往同一个 MEMORY.md 里堆。这一版每条记忆带一个 owner_key（主人标识）和可见性范围（个人 / 团队 / 全局）。同一个员工服务一群人时，每个人的私人记忆互不串台；第三方 API 还能透传终端用户身份，按终端用户隔离。
外加两件中等的事：每个员工可以绑一个主知识库，模型选择真正听你的偏好提供商。还有一堆打磨。
就这样。
一、目标长出了清单——从"打个分"到"逐条勾"
v1.4.0 的目标系统，evaluator 每轮给一个完成度分数（0~1）和一句"还差什么"。问题是：0.8 是什么意思？ 哪些做完了、哪些没做、还剩几步——你看不清，员工自己也只是凭一个模糊的数字判断该不该继续。
这一版我们把它换成清单（checklist）。
目标 = 一组可独立验证的准则。 你说"把博客部署到 fly.io"，员工（或 evaluator）把它拆成几条具体准则：DNS 解析正确、SSL 证书有效、健康检查通过、冒烟测试全绿。每一条都是一句人能看懂、LLM 能判的话。
evaluator 有两种模式：
| 模式 | 什么时候跑 | 干什么 |
|---|---|---|
| bootstrap（拆解） | 还没有准则时 | 把目标拆成清单，每条初始为"未通过" |
| verdict（裁决） | 已有准则时 | 逐条判：这条满足了吗？给出证据 |
两种模式都用结构化输出——evaluator 必须返回一个带类型的对象（准则 id + 通过与否 + 证据），不是一段自由文本让我们去猜。
完成判定变成确定性的。 以前可能有个模糊阈值。现在：只有当每一条准则都通过，才判完成。 20 条里过了 19 条（0.95 分）依然是"继续"，不是"完成"。差一条，就还差一条。
自动延续盯着剩余准则。 开了 autoFollowup 之后，员工答完一轮如果还没全勾完，注入的续命 prompt 会明确列出还没过的那几条——"5/8 已完成，剩余：① …… ② ……，去做剩下的"——而不是一句笼统的"继续"。
头像旁的光，hover 出来是一张清单卡。 没有清单时是一句话 tooltip（标题 + 还差什么）；有清单时是一张卡片：标题 + X/Y 进度，下面每条准则前面一个 ○（未完成）或 ✓（绿色已完成，文字带删除线）。评估中头像周围有沙金色呼吸光晕。
Evaluator SPI。 评估逻辑实现了 Spring AI 的 Evaluator 接口，既能做目标专用的 checklist 裁决，也能被当成通用评估器复用。失败的 evaluator 调用照样计入 LLM 预算（不白嫖），所以预算账目是准的。
新增一个工具 + 一个 API 端点：
- 员工工具
addGoalCriterion——往进行中的目标追加一条准则，不用重开目标 - REST
POST /api/v1/goals/{id}/criteria——程序化追加准则 - 创建目标时也能直接带初始清单：
criteria: ["...", "..."]（省去 bootstrap 那一轮）
几个新增配置项（mateclaw.goal.*）：default-auto-followup（创建时默认是否开自动延续）、allow-auto-followup（运行期总开关，关掉则谁都不注入续命）、max-followups-per-run（单次 graph 运行内自动延续的硬上限，默认 8）。
完整说明见 持久化目标。
v1.4.0 的目标是"员工记住它在干什么"。v1.5.0 的目标是"员工知道具体还差哪几条"。从一个分数，到一份能逐条勾的清单。
二、Wiki 学会了自己维护自己
这是这一版工作量最大的一块。Wiki 从"一个能搜的知识库"长成"一个会自己维护一致性、自己分层、自己跑流水线的知识引擎"。
页面之间能互联了——[[wikilink]]
页面正文里写 [[目标页 slug]] 或 [[slug|显示文字]]，就建立一条指向另一页的链接。
- slug 优先解析——链接按 slug 精确匹配（大小写不敏感），不做模糊猜测。代码块（``` 围栏和
行内）里的[[...]]不当链接处理。 - 改名 / 删页自动级联——给一页改 slug，同一个事务里把全 KB 指向旧 slug 的 wikilink 全部改写过去，别名文字（
[[旧slug|甲]]→[[新slug|甲]]）保留。级联删除会一并清理引用。 - 坏链体检——
POST .../lint/broken-links起一个异步扫描任务，扫完把每页的坏链结果持久化到页面行上，重启不丢。GET .../lint/broken-links拿聚合结果（多少页有坏链、共多少条坏引用）。 - 聊天里的 wikilink 能点——聊天回答里渲染出来的 wikilink 可点击，跨 KB 查找后跳转到目标页。
知识分层了——事实 vs 经验
每页可以标一个知识层：
fact（事实层）——"是什么"：基础事实页（不标的默认按事实处理）experience（经验层）——"意味着什么"：综合、分析、个人洞见，依赖一组事实页
失效会传播。 经验页声明它依赖哪些事实页（按页面 id 存边，改名不断链）。当某个事实页在 ingest 时被更新，所有依赖它的经验页自动被标记 stale（待复核）+ 一段失效原因。wiki_stale_pages 工具能列出当前所有待复核的页。
搜索可以按知识层过滤（只搜事实 / 只搜经验 / 全部）。
页面类型有了 profile 和权限
pageType profile（页面类型档案，KB 级）——为一个知识库定义有哪些页面类型（如"概念 / 教程 / 决策记录"），每种类型可以带：结构化字段 schema、路由/创建/合并阶段的提示词、Markdown 模板。新页落库时会按 schema 校验元数据并记下校验状态。每个 KB 至多一个启用的 profile；没配的 KB 用内建默认档案。
pageType 权限（per-agent）——可以为"某个员工 + 某个 KB + 某种页面类型"配读/增/改/删四个开关，外加写策略（allow 立即 / approval_required 走审批 / deny 禁止）。page_type='*' 是 KB 级默认，精确匹配优先于通配。读和写的默认回退不一样：读未匹配时回退 KB 级默认读策略（默认 allow_all，所以升级后仍全可读）；写是 opt-in 收紧的——没配任何规则时默认 allow，一旦配了任意一条，这个 KB 进入"锁定"模式，没匹配到规则的页面类型按 deny 处理（fail-safe）。
知识库能挂流水线了
Wiki Pipeline——给知识库定义一段处理流程，由页面事件自动触发：
- 触发器：
page_type_count（某类页面数量达到阈值）、page_created（新建某类页面）、stale_marked（页面被标记失效） - 步骤执行器：
llm（把输入过一遍模型，输出作为本步结果）、skill（在受限技能集内跑一个技能，以 owner agent 身份） - 定义用 YAML 或 JSON 写，有 CRUD + 校验接口；每次运行和每一步都有持久化记录可查（
.../pipelines/{id}/runs、.../pipeline-runs/{runId}），按(definition, trigger, subject, bucket)去重保证幂等。
本地目录能挂成知识源——可插拔 + 定时增量
Ingest-Source SPI——知识源做成了可插拔接口（WikiIngestSourceProvider），内建一个文件系统实现：给 KB 配一个 source_directory，目录里的文件就被吸进知识库。
- 定时增量同步——后台调度器（
@SchedulerLock保证多节点只跑一份）周期扫描，按内容哈希检测变更，只重新吸入新增/改动的文件（文本和二进制都覆盖）。 - 安全是 fail-closed 的——路径先规范化再
toRealPath()解析软链（堵 TOCTOU），按允许根目录白名单校验；生产 profile 下空白名单默认拒绝一切。 - 状态可查 + 手动触发——
GET .../source-watcher看 watcher 状态，POST .../source-watcher/scan立即扫一次。
新的 Wiki 工具
wiki_update_page——就地编辑一页（保留 slug），受 pageType 的"改"权限门禁wiki_stale_pages——列出当前所有被标记待复核的页
所有 wiki 写工具（创建 / 更新 / 归档 / 删除）现在都过 pageType 权限门禁；读工具按 pageType 可读性过滤列表和搜索结果（不可读的类型直接当不存在，不泄露）。
后台多了一个 Wiki 高级管理面板（五个子页：页面类型档案 / 分层与失效 / 权限 / 知识源 watcher / 流水线）。完整说明见 LLM Wiki 知识库。
三、记忆认人了——per-owner 隔离
以前一个员工的记忆是共享的：不管是网页登录的你、还是飞书群里的同事、还是第三方 API 接进来的终端用户，聊出来的记忆都堆进同一个 MEMORY.md。一个员工服务多个人时，记忆会串台。
这一版给每条记忆加了主人（owner）和可见范围（scope）。
统一的 owner_key。 不管身份从哪来，都归一成一个带前缀的字符串：
| 来源 | owner_key |
|---|---|
| 网页控制台 | user:<用户id> |
| IM 渠道（飞书/钉钉/企微…） | <渠道>:<发送者id> |
| 第三方 API（带 endUserId） | api:<endUserId> |
| 系统 / cron | system |
三档可见性：
- PERSONAL（个人）——只有匹配的 owner 能读。对话里抽取出来的记忆默认进这档。
- TEAM（团队）——用这个员工的人都能读。员工配置文件（AGENTS.md / SOUL.md / PROFILE.md）、历史回填的数据在这档。
- GLOBAL（全局）——跨员工/工作空间始终可见。预置事实、系统参考资料。
召回偏好个人记忆。 系统提示里只烤进 TEAM/GLOBAL 的共享记忆（可缓存）；每轮再按当前 owner_key 预取他个人的记忆文件注入——所以问"我的项目用什么栈"时，员工优先回忆这个人的私人记忆，而不是知识库里的泛泛资料。（事实召回查询同样支持 owner 可见性过滤；自动事实投影的 per-owner 化仍在补齐中。）
第三方 API 能透传终端用户身份。 /api/v1/chat 和 /api/v1/chat/stream 的请求体新增可选字段 endUserId（字符串，保大整数精度）。一个 PAT 认证的接入方代表一个 MateClaw 用户，但可以为每个终端用户传不同的 endUserId，记忆按终端用户自动隔离。
这是一个可开关的特性。 总开关 mate.memory.lifecycle-mediator-enabled——Java 属性裸默认值是 false，但随发行版打包的 application.yml 设成了 true，所以默认安装下隔离是开着的。要回到旧的共享行为（所有写入走 TEAM），在配置里显式设为 false。
迁移 V137 给 mate_workspace_file / mate_memory_recall / mate_fact 三张表加了 owner_key + scope 列，历史行回填为 TEAM（保证升级后没有记忆被藏起来）。完整说明见 记忆系统。
四、每个员工绑一个主知识库
员工编辑器新增"知识库"标签页，可以为每个员工指定一个主知识库。
- 知识库仍是工作空间共享资源。 绑定不改变 KB 的归属或可见性——其他员工照样能访问同一个 KB。
- "主知识库"只是个默认值。 它告诉 wiki 工具：调用时不显式指定
kbName/kbId时，默认去这个 KB。不指定就回退到工作空间里最近更新的那个 KB。
底层用 mate_agent.primary_kb_id 存（迁移 V130）。1.5.0 之前的版本把这个关系写在 mate_wiki_knowledge_base.agent_id 上（一对一独占），V130 把旧值回填到了 primary_kb_id，老字段保留作 fallback 读取。详见 API 参考 和 Agent 引擎。
五、模型选择真正听你的
偏好提供商决定主模型。 给员工配了偏好提供商（mate_agent_provider_preference，按 sortOrder 排序）之后，主模型选择会真的按这个偏好走。完整优先级链：
- 会话钉选模型最高——聊天头部给这个会话单独绑了模型就用它
- 其次是 per-agent 的模型覆盖（modelName）——员工自己钉死了某个模型
- 再次是全局默认模型
- 以上都没有时，才进入偏好提供商路由——按偏好挑提供商的主模型
偏好提供商路由里有一道能力门禁：如果员工绑定的技能声明了 requires-model: vision 这类需求，路由会先挑能满足这些模态的提供商；满足不了再无约束回退。
新增 Claude Opus 4.8 系列模型条目（迁移 V131）：Anthropic 直连的 claude-opus-4-8 / claude-opus-4-8-fast、OpenRouter 透传的对应条目、以及 Claude Code OAuth 通道的条目。两个变体都支持 xhigh 思考档。默认不设为默认模型——新装后由管理员显式指定。
详见 模型配置。
还有一些事
聊天体验：
- 执行计划 & 工具调用详情查看器——计划面板每个步骤、每个工具调用行，右侧多了"查看详情"图标，点开是一个带毛玻璃背景的弹窗，显示完整的请求参数和响应输出（内联预览会截断的部分），带复制按钮。数据存在消息元数据里，刷新页面也还在。
- 聊天里的
/skill斜杠菜单——输入框打一个/弹出可搜索的技能选择器：↑↓ 选、Enter/Tab 确认、Esc 关。选中后往输入框插一句Use the "技能名" skill:，你接着补充上下文发出去，员工据此load_skill拉起这个技能。列表走GET /api/v1/skills/enabled（含 MCP/ACP 派生的虚拟技能）。
生成文件不再因为重启就失效（#243）：
- 工具生成的文件（文档/图片/音频…）现在落盘到
data/generated-files/，带 7 天保留窗口 + 6 小时定时清理，内存里再放一层 LRU。下载链接重启后依然有效，也不再受原来 10 分钟内存窗口限制。 - 前端用一个全局点击代理拦截
/api/v1/files/generated/{id}下载：成功就走鉴权 fetch → blob 下载，失败（404/410/过期）弹个 toast——不再因为一个失效链接把整个 SPA 卡死。
渠道 / 模型可靠性：
- MCP 工具读超时默认 30s → 60s（#247）——单次 callTool 往返合法地跑久一点的工具不再被掐断；每台 MCP 服务仍可在 UI 里单独调（5–300s）。
- 统一的入站媒体管线——目前微信和企业微信已接入这层共用的入站媒体下载器 + 魔数（magic-byte）类型识别 + 指数退避重试（其它 IM 渠道后续接入）。文件类型从内容字节判定（不再硬编码
image/*），HEIC/WEBP/DOCX/XLSX 等都能正确识别。 - 飞书：跟进文本自动带上最近的文件（#201）——飞书群里先发一个文件（哪怕没 @ 员工），再发一句文字，缓存的文件会自动作为内容片段塞给员工（每群 5 个文件、60 分钟 TTL）。
- 修好 DashScope 工具调用——
web_search工具改了内部名（DashScope 原生协议把search当保留字会整条请求拒掉）；同时收窄了错误分类——非法工具名之类的InvalidParameter不再被误判成"模型不存在"而把一个健康模型踢出故障转移池。 - Plan-Execute 拆解判据重平衡——是否拆成多步，现在按"目标是否由多个明显独立的子任务组成"判断，而不是按难度；多目标不再被硬塞成单步。
完整清单：git log v1.4.0..HEAD。
升级路径
配置完全兼容。 升级前后你的所有 agent / skill / wiki / channel / cron / 工作流 / 触发器 / 目标都不动。
新增 schema 由 Flyway 自动迁移。 目标清单列（mate_agent_goal.criteria，V140）、记忆 owner/scope（V137）、员工主知识库（V130）、Claude 4.8 模型条目（V131）、Wiki 坏链/分层/页面类型/权限/流水线（V129、V133–V136）、MCP 默认超时（V139）等第一次启动自动迁移，已有库自动 baseline。
已经在生产用 v1.4.0 的用户：
- 目标清单是增量的——你现有的目标继续按老逻辑跑；新目标才用 checklist。完成判定改成"全勾完"后，自动延续会更"较真"地把剩余准则做完——预算耗尽即停，行为可控。
- 记忆隔离默认开——随发行版打包的
mate.memory.lifecycle-mediator-enabled是true，升级后对话抽取会按 owner 写入 PERSONAL 记忆、召回按 owner_key 过滤。想保留旧的共享行为，在配置里显式设为false（Java 属性裸默认值即为false）。 - Wiki 权限默认全开——一个员工对某 KB 没配任何 pageType 权限规则时，全可读可写（旧行为不变）。要收口某个 KB，去 Wiki 高级面板加规则。
- 知识源 watcher 默认按配置走——只有给 KB 配了
source_directory且开启 watcher 才会扫描；生产 profile 下建议配mate.wiki.allowed-source-roots白名单。 - MCP 读超时默认变 60s——已有的 MCP 服务行记录保留各自存的值，新建的默认 60s。
这一版对你意味着什么
如果你是普通用户——
给员工定个有清单的目标。"把这篇文章翻译、发布、回复评论"——它会拆成几条，一条条勾给你看，全勾完才停。hover 头像那圈光，能看到还差哪几条。
如果你在攒一个知识库——
把本地一个文档目录挂成知识源，定时增量同步；页面之间用 [[wikilink]] 织成网，改名删页不再留一地死链；把"会随事实变化的结论"标成经验层，事实一改它自动提醒你复核。
如果你管理一个团队——
打开记忆隔离，让一个员工服务全组而每个人的私人记忆互不串台；用 pageType 权限控制谁能往知识库哪类页面写。
如果你是开发者——
POST /api/v1/goals/{id}/criteria 程序化追加准则；/api/v1/chat 带 endUserId 给你的每个终端用户做记忆隔离；Wiki 流水线 + Ingest-Source SPI 让你把知识库接进自己的数据流。
如果你跑生产环境——
升级。生成文件落盘让下载链接扛得住重启；MCP 超时放宽到 60s 让慢工具不被掐；DashScope 工具调用和错误分类修复让 qwen 系模型的工具使用真正能用。
One more thing.
清单。分层。主人。
一个员工凭一个模糊分数判断"差不多了"，是估算。一个员工把目标拆成几条、一条条勾、全勾完才停，是验收。
知识库也一样。一堆能搜的文档，是仓库。一个页面互联、会分层、事实一改就提醒你复核相关结论的知识网，才是知识。
记忆也一样。一锅谁聊的都往里堆的粥，迟早串台。一份认得出"这是谁的记忆"的记忆，才敢给一群人用。
这一版做的，就是让"自主"变得可验证，让"知识"变得会自维护，让"记忆"变得认人。