MateClaw 1.3.0：当多智能体系统不再只是聊天框

2026-05-13 28 预计阅读时间：1 分钟
来源：oschina.net AI 摘要 原文链接

免责声明：本文为 AI 摘要整理，建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件，不作为官方说明。

预计阅读时间：12 分钟

过去一年，企业 AI 落地最常见的路径是：部署一个对话界面，接入大模型，然后发现它只能回答问题，不能做事。MateClaw 1.3.0 的发布，试图把这条路径拐向另一个方向——从"数字员工"升级为业务流程操作系统。它不再围绕"怎么聊"，而是围绕"怎么干"。

从聊天框到流程 OS，差了什么？

一个典型的企业 AI 聊天框能做的事：回答政策问题、生成一段文案、总结会议纪要。这些场景的共同特征是单轮、无状态、无协作。但真实业务流程不是这样的——审批要流转，数据要跨系统同步，决策要基于历史上下文。

MateClaw 把差距拆成了几个具体的能力层：

  • 数字员工：不是通用聊天机器人，而是绑定角色和职责的 Agent，每个员工有明确的工具集和知识边界。
  • 记忆系统：Agent 能记住上次对话的结论、用户偏好、业务状态，跨会话持续工作。
  • Tool Guard：工具调用不是"想调就调"，而是有审批和审计链路——这在金融、医疗等场景里是硬性合规要求。
  • MCP/ACP 扩展：通过 Model Context Protocol 和 Agent Communication Protocol 把外部工具和跨 Agent 协议标准化接入。

这四层叠加在一起，才构成一个"OS"而非"聊天框"的底层逻辑：有进程（Agent）、有文件系统（LLM Wiki + 记忆）、有权限管控（Tool Guard）、有进程间通信（ACP）。

技术栈与架构选择

MateClaw 选了 Spring Boot + Spring AI Alibaba 作为基础框架，这个组合有几个实际好处：

  1. Spring Boot 的生态成熟度——企业环境里安全、监控、配置管理等基础设施几乎不用从零搭建。
  2. Spring AI Alibaba 的国产模型适配——直接对接通义千问等国产大模型，对数据合规和延迟敏感的场景更友好。
  3. 自部署——整套系统可以跑在企业内网，不依赖外部 SaaS。

架构上，MateClaw 把多智能体编排、知识管理、工具注册、审批流都做成可插拔模块，而不是硬编码在核心路径里。这意味着你可以只启用数字员工 + 记忆系统，先跑最小闭环，再逐步接入 MCP 工具和审批链路。

最小化部署：跑起来一个带记忆的数字员工

下面给出一个基于 Spring Boot + Spring AI Alibaba 的最小项目骨架，模拟 MateClaw 数字员工的核心模式：角色定义 + 工具绑定 + 记忆持久化。你可以直接复制改造。

项目依赖（pom.xml 关键片段）

<dependencies>
    <!-- Spring Boot Web -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <!-- Spring AI Alibaba：对接通义千问 -->
    <dependency>
        <groupId>com.alibaba.cloud.ai</groupId>
        <artifactId>spring-ai-alibaba-starter</artifactId>
        <version>1.0.0-M2</version>
    </dependency>

    <!-- Spring AI：Chat Memory 持久化（基于 JDBC） -->
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-chat-memory-jdbc</artifactId>
        <version>1.0.0-M5</version>
    </dependency>

    <!-- H2 作为演示数据库，生产环境换成 PostgreSQL -->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <scope>runtime</scope>
    </dependency>
</dependencies>

注意：Spring AI Alibaba 和 Spring AI 的版本号仍在快速迭代，实际使用时请查 Maven Central 取最新稳定版。M2/M5 为里程碑版本，生产部署需评估风险。

Agent 角色与工具配置（application.yml）

spring:
  ai:
    alibaba:
      api-key: ${DASHSCOPE_API_KEY}   # 从环境变量读取，不要硬编码
      chat:
        options:
          model: qwen-plus             # 选用通义千问 Plus，平衡速度与能力

  datasource:
    url: jdbc:h2:file:./data/memdb;DB_CLOSE_ON_EXIT=FALSE
    driver-class-name: org.h2.Driver
    username: sa
    password:

# 数字员工角色定义
agent:
  roles:
    finance-assistant:
      name: 财务助手
      description: 处理报销审核、发票校验、预算查询
      allowed-tools: expense-query,invoice-validate
      system-prompt: |
        你是财务部门的数字员工。职责范围仅限报销、发票和预算。
        超出职责的请求，礼貌拒绝并建议用户联系对应部门。
        每次回复前，先确认你掌握的上下文是否足够；不够时主动追问。

数字员工服务类（Java）

@Service
public class FinanceAgentService {

    private final ChatClient chatClient;

    public FinanceAgentService(ChatClient.Builder chatClientBuilder,
                               ChatMemory chatMemory) {
        // 绑定系统提示词 + 记忆存储，每次对话自动携带历史上下文
        this.chatClient = chatClientBuilder
                .defaultSystem("""
                    你是财务部门的数字员工。职责范围仅限报销、发票和预算。
                    超出职责的请求，礼貌拒绝并建议用户联系对应部门。
                    每次回复前，先确认你掌握的上下文是否足够；不够时主动追问。
                    """)
                .defaultAdvisors(
                    new MessageChatMemoryAdvisor(chatMemory)
                )
                .defaultTools(new ExpenseQueryTool(), new InvoiceValidateTool())
                .build();
    }

    /** 与财务助手对话，conversationId 用于区分不同用户的会话 */
    public String chat(String userMessage, String conversationId) {
        return chatClient.prompt()
                .user(userMessage)
                .advisors(a -> a.param("chat_memory_conversation_key", conversationId))
                .call()
                .content();
    }
}

工具定义示例（报销查询）

@Component
public class ExpenseQueryTool {

    @Tool(description = "查询指定员工的报销记录，返回报销状态和金额")
    public String queryExpense(String employeeId, String month) {
        // 实际项目中对接 ERP 或财务系统 API
        // 这里用模拟数据演示
        return """
                员工 %s 在 %s 的报销记录：
                - 报销单 EX-2024-0087：差旅费 3200 元，状态：已审批
                - 报销单 EX-2024-0103：办公用品 580 元，状态：待审批
                """.formatted(employeeId, month);
    }
}

REST 接口暴露

@RestController
@RequestMapping("/agent/finance")
public class FinanceAgentController {

    private final FinanceAgentService service;

    public FinanceAgentController(FinanceAgentService service) {
        this.service = service;
    }

    @PostMapping("/chat")
    public Map<String, String> chat(@RequestBody Map<String, String> body) {
        String reply = service.chat(
                body.get("message"),
                body.getOrDefault("conversationId", "default")
        );
        return Map.of("reply", reply);
    }
}

启动后，POST /agent/finance/chat 即可与财务助手对话。第二次对话会自动携带第一次的上下文——这就是记忆系统在最小形态下的作用。

运行前需要做的事：

  1. 设置环境变量 DASHSCOPE_API_KEY（在阿里云 DashScope 控制台申请）。
  2. mvn spring-boot:run 启动项目。
  3. 测试请求：
curl -X POST http://localhost:8080/agent/finance/chat \
  -H "Content-Type: application/json" \
  -d '{"message": "帮我查一下员工 ZHANGSAN 2024年6月的报销情况", "conversationId": "user-001"}'

Tool Guard：为什么工具调用需要审批链路

上面的例子中，ExpenseQueryTool 是只读查询，风险可控。但一旦 Agent 拥有写操作能力——比如发起付款、修改权限、删除记录——"想调就调"就变成了事故源头。

MateClaw 的 Tool Guard 机制在工具调用前插入审批节点：Agent 提出调用意图 → 审批流判断是否放行 → 放行后执行并记录审计日志。在 Spring AI 的工具机制里，你可以用 Advisor 拦截实现一个简化版：

@Component
public class ToolGuardAdvisor implements CallAdvisor {

    private final AuditLogService auditLog;

    @Override
    public AdvisedResponse adviseCall(AdvisedRequest request, CallAdvisorChain chain) {
        // 检查请求中是否包含工具调用意图
        List<ToolCall> toolCalls = extractToolCalls(request);
        for (ToolCall tc : toolCalls) {
            if (isWriteOperation(tc)) {
                // 写操作需要人工审批，这里返回拒绝消息而非执行
                auditLog.record(tc, "BLOCKED", "写操作需人工审批");
                return blockWithMessage(tc, "该操作需要审批，已提交审批流程。");
            }
        }
        // 只读操作直接放行，记录审计日志
        toolCalls.forEach(tc -> auditLog.record(tc, "APPROVED", "自动放行"));
        return chain.nextCall(request);
    }

    private boolean isWriteOperation(ToolCall tc) {
        // 根据工具名或注解判断是否为写操作
        return tc.name().contains("create") || tc.name().contains("delete") || tc.name().contains("update");
    }
}

这个拦截器注册到 ChatClient.Builder 的 defaultAdvisors 中即可生效。生产环境里审批判断会对接 OA 流程而非硬编码，但拦截模式是一样的。

接入决策：什么时候该考虑 MateClaw？

MateClaw 适合的场景有一个共同特征：AI 需要持续参与多步骤业务流程，而非只做单轮问答。具体判断：

场景 用聊天框够了 需要 Agent OS
内部知识问答 ✅ ❌
单次文案生成 ✅ ❌
报销审批流转 ❌ ✅
跨系统数据同步 ❌ ✅
多角色协作（销售+财务+法务） ❌ ✅
需要审计追溯的工具调用 ❌ ✅

落地建议：

  1. 先跑最小闭环——一个角色 + 一个只读工具 + 记忆系统，验证 Agent 是否真的比纯聊天更有效。
  2. Tool Guard 优先上线——在 Agent 拥有任何写操作之前，先把审批拦截机制部署好。这是合规底线。
  3. MCP/ACP 按需接入——不要一开始就对接十几个外部工具。先让一个 Agent 熟练使用两三个工具，再扩展协议层。
  4. 记忆系统做好隔离——不同用户、不同角色的记忆必须隔离，防止跨角色信息泄露。JDBC Memory 的 conversation_key 参数就是隔离边界，生产环境要加上角色维度的过滤。

MateClaw 1.3.0 的定位清晰：它不是给个人用户做的聊天增强，而是给团队和企业的流程自动化打底。如果你正在评估"AI 怎么真正嵌入业务流程而不是挂在旁边当问答插件"，这个版本值得花一个下午跑起来试试。

相关推荐