在这里插入图片描述

过去一年,AI Agent 的讨论重心一直在“模型会不会做事”。到了 2026 年 6 月最后一周,行业信号开始更清楚:企业真正要买的不是一个更会聊天的模型,而是一套能把 Agent 接入任务、工具、权限、记忆、成本和协作入口的控制平面。

本周几条资讯放在一起看,很有代表性:

  • OpenAI 发布了关于 agents 如何改变工作的研究,里面提到员工把 Codex 作为“可并行委派的后台同事”,在工作中同时运行多个 agent 任务,并把节省的时间投入到设计、测试和代码审查等更高价值环节。来源:OpenAI: How agents are transforming work
  • Anthropic 推出 Claude Tag,把 Claude 直接带进 Slack 线程,重点不只是“在 Slack 里问 AI”,而是管理员可以集中配置可用工具、Connector、模型选择、使用看板和花费控制。来源:Anthropic: Introducing Claude Tag
  • Slack 正在把桌面端变成 MCP client,让企业工具能以标准方式接入协作场景,同时强调 OAuth、权限与用户批准。来源:Slack: Slackbot and MCP
  • Google Cloud 6 月 Agent Platform release notes 继续推进 Agent Engine、Agent Builder、Agent Assist、可观测与部署相关能力。来源:Google Cloud Agent Platform release notes

这些不是孤立新闻。它们共同指向一个技术判断:Agent 正从“一个聊天入口”变成“企业软件栈里的新运行时”。

一、趋势判断:Agent 的竞争点变了

早期 Agent 产品常见的卖点是:能联网、能调用工具、能写代码、能读文件。今天这些已经不够了。

企业真正关心的问题正在变成:

  1. 任务能不能长时间稳定运行?
  2. 多个 Agent 能不能分工协作,而不是互相污染上下文?
  3. 工具调用能不能被授权、审批、审计?
  4. 记忆和知识能不能按人、按团队、按业务边界隔离?
  5. 成本、模型、渠道和部署能不能由组织集中管理?
  6. 能不能接入 Slack、飞书、企业微信、Webchat、API,而不是只停在一个网页聊天框?

也就是说,技术趋势已经从“模型能力竞赛”进入“Agent 运行时竞赛”。

二、OpenAI 的信号:后台并行 Agent 会改变工作组织方式

OpenAI 本周这篇文章最值得注意的不是 Codex 本身,而是工作方式变化:员工不再把 AI 当成一次问答工具,而是把多个任务交给后台 Agent 并行推进。

这对企业软件提出了新要求:

  • Agent 任务要有状态,不能刷新页面就断;
  • 每个任务要能看到目标、进度、输出和失败原因;
  • 多任务并行时,要能隔离上下文和权限;
  • 结果不能只是一段文字,还要能进入 PR、文档、表格、知识库或审批链路。

这就是为什么“聊天 UI”只是入口,不是系统本身。

MateClaw 在这条线上已经做了几层基础:

  • ReAct + Plan-and-Execute 双模式运行时;
  • 多员工并行委派和多级子员工委派树;
  • 计划面板、子会话时间线、运行时控制台;
  • 工作流 Workflow 与 Trigger 把任务从“人工发起”推进到“事件触发”;
  • v1.5.0 引入 Goal checklist,让目标从模糊评分变成逐项可验证;
  • v1.6.0 增加 execute_code,让员工可以写代码并运行,完成真实计算、转换和核对。

在这里插入图片描述

三、Anthropic 和 Slack 的信号:Agent 正进入协作入口,但入口必须带治理

Anthropic 的 Claude Tag 和 Slack 的 MCP client 说明一件事:企业不会要求员工离开协作工具去使用 AI。AI 会进入 Slack、飞书、企业微信这些原本就承载业务上下文的地方。

但这也带来更现实的问题:

  • 谁可以调用哪个工具?
  • 某个连接器能访问哪些数据?
  • 花费有没有上限?
  • 审计日志在哪里?
  • Agent 在群里误触发怎么办?
  • Bot 自己发出的消息会不会再次触发自己?

这类问题不是 prompt 能解决的,它需要产品和后端系统设计。

MateClaw 的对应能力包括:

  • IM 渠道:钉钉、飞书、企业微信、微信、Telegram、Discord、QQ、Slack;
  • Tool Guard:危险工具调用可配置审批规则;
  • 审批工作流:敏感动作暂停,人批准后继续;
  • RBAC:工作空间内 Owner / Admin / Member / Viewer 等权限模型;
  • Personal Access Token:给自动化脚本和第三方系统使用;
  • Trigger 事件治理:去重、限流、递归保护、未知 pattern fail-closed;
  • per-agent MCP 工具绑定:一个员工能用的工具不会默认泄漏给所有员工;
  • v1.5.0 的 per-owner 记忆隔离:同一个员工服务多人时,个人记忆不串台。

这就是“Agent 进协作入口”背后的工程真相:越靠近日常工作流,越需要权限、审计和边界。

在这里插入图片描述
MateClaw 管理控制台】

在这里插入图片描述

【Tool Guard 安全治理页面】

四、Google Cloud 和 MCP 的信号:Agent 平台会走向协议化

MCP、A2A、Agent Gateway、Connector、Tool Registry,这些词最近密集出现,背后是一个趋势:Agent 不可能永远困在单一厂商、单一 IDE、单一聊天框里。

未来企业里会同时存在多类 Agent:

  • 编码 Agent;
  • 客服 Agent;
  • 销售运营 Agent;
  • 数据分析 Agent;
  • 知识库维护 Agent;
  • 审批与流程 Agent;
  • 嵌入到自家 SaaS 的 end-user Agent。

它们需要用标准协议接工具、接数据、互相委派,且每个系统都要能识别调用者身份和权限边界。

MateClaw 当前的架构选择正贴近这个方向:

  • MCP 支持 stdio / SSE / Streamable HTTP;
  • ACP 可把 Claude Code、Codex 这类编码 Agent 桥接为员工能力;
  • SKILL.md 技能包把 prompt、工具列表、脚本和经验沉淀封装起来;
  • Tool Registry 把内置工具、MCP 工具、技能脚本统一成 Agent 可调用能力;
  • v1.4.0 起有渐进式工具 / 技能披露,避免把全部能力一次性塞进 prompt;
  • v1.6.0 强化 MCP 连接变化时的缓存刷新和非阻塞连接,降低生产部署里的连通性风险。

这套思路不是“我也支持 MCP”这么简单,而是把 MCP 放进更完整的企业运行时里:有员工、有知识、有记忆、有权限、有审批、有审计。

五、MateClaw v1.6.0 的新特性,为什么契合这波趋势

MateClaw 最近的 v1.5.0 和 v1.6.0,重点不是炫模型,而是在补“Agent 真正进入企业现场”需要的基础设施。

1. Goal checklist:自主必须可验证

v1.5.0 把目标系统从模糊评分改成 checklist。员工把目标拆成可验证准则,每轮由 evaluator 逐项裁决。

这很关键。企业任务里,“差不多完成了”没有意义。要么证据满足,要么继续做。

2. Wiki 自维护:知识库不只是向量检索

v1.5.0 的 Wiki 增加了 [[wikilink]]、坏链体检、事实层 / 经验层、pageType profile、权限和流水线。

这让知识库更像一个可维护的企业知识系统,而不是一堆 chunk 的搜索索引。

3. per-owner 记忆:一个员工服务多人时不能串台

Agent 一旦进入 Webchat、IM、API,就会服务多个终端用户。v1.5.0 的 owner_key 和 PERSONAL / TEAM / GLOBAL 可见范围,解决的是多人使用时最基础的记忆隔离问题。

4. 跨轮次视觉:Agent 要能“记得那张图”

v1.6.0 让图片跨轮次留在上下文里,并新增 image_analyze 工具。用户三轮之后追问截图里的某个细节,员工不再只依赖第一次的文字描述,而是可以重新看图。

这对运维截图、报表截图、设计稿评审、合同图片、工单附件都很实用。

5. execute_code:从“生成答案”到“真实执行”

execute_code 让员工写代码并运行,用真实计算和文件处理替代口头估计。

这和 OpenAI 本周强调的后台任务趋势是一致的:Agent 的价值不只是回答,而是把任务推进到可验证输出。

6. PostgreSQL / KingbaseES:部署环境决定企业能不能用

v1.6.0 支持 PostgreSQL 和 KingbaseES。对很多受监管、国产化或数据库标准化的组织来说,这不是“加一个数据库选项”,而是决定能否进入生产环境的门槛。

7. Webchat 多会话与 endUserId:嵌入式 Agent 需要身份边界

v1.6.0 的 Webchat 升级为 Web/API 接入面,支持多会话和按终端用户身份隔离记忆。这让 MateClaw 不只是一个后台控制台,也可以成为企业自己产品里的 AI 接入层。

六、技术架构上,MateClaw 更像 Agent Harness,而不是 Chatbot

MateClaw 的核心定位可以概括成一句话:

用 Spring Boot 方式做一个可私有化部署的 Agent Harness。

它的底座包括:

  • Spring Boot 3.5;
  • Spring AI Alibaba;
  • StateGraph 运行时;
  • ReAct + Plan-and-Execute;
  • MyBatis Plus + Flyway;
  • H2 / MySQL / PostgreSQL / KingbaseES;
  • Vue 3 + TypeScript 管理控制台;
  • Electron 桌面端;
  • Webchat 嵌入组件;
  • MCP / ACP / SKILL.md 扩展体系。

这和单纯的 AI 聊天应用不是一个层级。聊天只是入口,真正难的是运行时:任务怎么跑、工具怎么管、上下文怎么压缩、结果怎么沉淀、权限怎么收口、失败怎么恢复、审计怎么留痕。

七、给开发者的判断:下一代 Agent 平台要有五个层

结合本周资讯和 MateClaw 的演进,我认为企业 Agent 平台至少要有五层。

第一层是模型路由。要支持多供应商、健康检查、故障转移、按能力选择模型。

第二层是工具协议。要支持 MCP、内置工具、技能脚本、外部系统 Connector,并能按员工或用户授权。

第三层是任务运行时。要支持长任务、计划、目标、并行委派、后台任务和可恢复状态。

第四层是知识与记忆。要有 Wiki、引用、事实与经验分层、个人 / 团队 / 全局记忆隔离。

第五层是企业治理。要有 RBAC、审批、审计、成本、运行时控制台、部署适配和网络代理。

MateClaw 的价值就在这里:它不是只在某一层做 demo,而是在尝试把这五层收敛成一个可部署系统。

八、快速开始

git clone https://github.com/mateaix/mateclaw.git
cd mateclaw

# 后端
cd mateclaw-server
mvn spring-boot:run

# 前端
cd ../mateclaw-ui
pnpm install
pnpm dev

默认后端地址:

http://localhost:18088

默认前端地址:

http://localhost:5173

默认登录:

admin / admin123

结语:Agent 进入企业,拼的是控制面

本周的行业动向可以用一句话总结:

Agent 正在从“个人效率工具”进入“企业协作与执行系统”。

OpenAI 讲的是后台并行任务,Anthropic 和 Slack 讲的是协作入口与权限控制,Google Cloud 讲的是平台化部署与管理。它们共同说明:下一阶段的竞争,不只是模型参数和 benchmark,而是谁能把 Agent 放进真实组织里长期运行。

MateClaw 的方向正好踩在这里:数字员工、工作流、触发器、MCP / ACP、Tool Guard、Wiki、记忆隔离、代码执行、跨轮次视觉、多数据库部署。

如果说过去的 AI 产品是在证明“模型能不能帮你”,那么下一阶段的问题会是:

你的组织能不能安全、稳定、可审计地让一群 Agent 真正上岗?

这就是 MateClaw 值得关注的地方。


参考链接

Logo

欢迎加入 MCP 技术社区!与志同道合者携手前行,一同解锁 MCP 技术的无限可能!

更多推荐