MateClaw 2.2.0：把 Agent 身份、运行时与长期任务拆开

预计阅读时间：11 分钟

MateClaw 2.2.0 稳定版于 2026 年 8 月 29 日发布。这个版本的重点不是简单增加一个模型适配器，而是重新整理了 Agent 系统的运行边界：员工身份与执行引擎解耦，任务可以跨请求、跨后端重启恢复，并且不同 Agent 之间能够通过双向 A2A 互联协作。

对于正在构建 AI 团队、自动化工作流或长期任务系统的开发者来说，这些变化意味着 Agent 不再只是一次请求对应一次响应的临时对象，而可以拥有相对稳定的身份、运行时和任务状态。

员工身份不再绑定执行引擎

2.2.0 引入了 Native 与 DeepSeek Harness 两种运行时。结合版本摘要来看，MateClaw 的设计方向是把“谁在工作”和“如何执行”拆开：

Agent 身份描述职责、工具权限、工作空间和协作关系。
Runtime 负责实际的模型调用、工具编排和执行循环。
同一个 Agent 可以根据场景切换不同 Runtime。
Runtime 的变化不会迫使业务层重新定义员工角色。

这一区分对工程系统很重要。比如，一个“代码审查员”可以在开发环境中使用 Native Runtime，在需要特定模型或既有工具链的环境中使用 DeepSeek Harness。业务代码关心的是任务交给哪个 Agent，而不是把模型调用细节硬编码在任务流程里。

可以把这种结构理解为一个运行时策略：

# 示例配置，字段名用于说明接入思路，实际项目请以 MateClaw 2.2.0 的配置定义为准
mateclaw:
  agents:
    code-reviewer:
      display-name: "Code Reviewer"
      role: "Review pull requests and report actionable defects"
      runtime: "native"
      workspace: "/workspaces/review"

    research-assistant:
      display-name: "Research Assistant"
      role: "Collect evidence and prepare research notes"
      runtime: "deepseek-harness"
      workspace: "/workspaces/research"

上面的配置是假设性示例，重点在于配置模型：角色定义与 runtime 分离。实际落地时，还需要为每个 Runtime 明确模型凭证、超时、工具白名单、并发限制和失败重试策略。

Persistent Goal 让任务跨请求继续工作

传统 Agent 接口通常是“发起请求、等待结果、返回响应”。一旦请求超时、用户关闭页面，或者后端重启，执行上下文就可能丢失。2.2.0 的 Persistent Goal 则把目标提升为可持久化的任务实体，使它能够跨请求并在后端重启后恢复。

这类能力适合以下场景：

需要多轮工具调用的代码生成或数据处理。
需要等待外部系统完成的部署、审批或构建任务。
运行时间超过单次 HTTP 请求生命周期的研究任务。
用户提交目标后，稍后再回来查看进度和交付物。

可以这样设计一个最小的任务 API。下面是可运行的 curl 示例，接口路径和字段是用于说明集成方式的假设，接入时应替换为实际 API：

# 创建一个可持续执行的目标
curl -X POST "http://localhost:8080/api/goals" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "research-assistant",
    "goal": "整理本周构建失败的原因，并输出带证据的 Markdown 报告",
    "workspace": "/workspaces/research",
    "deliverable": "build-failure-report.md"
  }'

# 根据返回的 goalId 查询状态
goal_id="replace-with-goal-id"
curl "http://localhost:8080/api/goals/${goal_id}"

从系统设计角度看，Persistent Goal 至少需要持久化以下状态：目标内容、当前阶段、已完成步骤、工具调用结果、交付物状态、运行时信息以及最近一次心跳。恢复逻辑不能只依赖内存中的对话历史，否则后端重启后仍然无法可靠续跑。

持久化也带来新的边界问题。恢复任务时应避免重复执行不可幂等操作，例如重复创建云资源、重复发送通知或重复提交订单。一个可行的实践是为工具调用建立幂等键，并在任务状态中记录执行结果：

operation_id = goal_id + ":" + step_id

if operation_id already has a completed result:
    reuse the recorded result
else:
    execute the tool
    persist result and step state atomically

这段伪代码不是 MateClaw 的固定 API，而是实现持久任务恢复时可以采用的工程策略。

A2A 把协作从内部调用扩展到互联

2.2.0 同时加入双向 A2A 能力。A2A 可以理解为 Agent-to-Agent 通信：一个 Agent 不仅能调用本地工具，还能把任务交给另一个 Agent，并接收对方的状态、结果或进一步请求。

“双向”尤其重要。单向调用只能把请求发出去；双向协作则允许被调用方报告进度、提出补充信息、返回中间产物，或者在遇到权限和资源边界时拒绝执行。这样更接近真实团队协作，而不是简单的函数调用。

一个最小的 A2A 消息可以包含以下信息：

{
  "messageId": "msg-20260829-001",
  "from": "project-manager",
  "to": "code-reviewer",
  "conversationId": "conversation-42",
  "type": "task.request",
  "payload": {
    "goal": "检查支付模块最近一次变更",
    "repository": "payments-service",
    "commit": "abc123"
  },
  "replyTo": null
}

生产环境中不能只关注消息格式，还要处理身份认证、权限委派、超时、重试、消息重复和敏感数据泄露。尤其是跨系统调用时，目标 Agent 的工作空间边界必须保持清晰：调用方可以请求某项工作，但不应自动获得对方全部文件、凭证和工具权限。

Team Run 与交付边界继续加固

MateClaw 2.1.0 引入的 Team Run、交付物完成门和工作空间边界，在 2.2.0 中继续得到加固。这说明 MateClaw 的关注点不只是“让多个 Agent 同时运行”，还包括如何判断一次团队执行是否真的完成。

一个可靠的 Team Run 通常需要区分三种状态：

执行状态：任务是否仍在运行、暂停、失败或恢复中。
交付状态：要求的文件、报告或结构化结果是否已经产生。
验收状态：交付物是否满足格式、内容和质量要求。

只有 Agent 返回一段文本，并不代表任务完成。比如“生成测试报告”至少还应检查报告文件是否存在、是否位于允许的工作空间、是否包含必要字段，以及生成过程是否经过验证。

工作空间边界同样是 Agent 系统的安全基础。建议为每个 Agent 和每次 Team Run 明确：

可读目录与可写目录。
可以使用的命令和外部服务。
交付物的输出目录。
任务之间是否允许共享文件。
Runtime 切换时权限是否保持一致。

采用建议

MateClaw 2.2.0 更适合被当作 Agent 基础设施来评估，而不是普通聊天应用的升级。落地时可以按以下顺序验证：

先为 Agent 身份定义稳定的职责、权限和工作空间。
再选择 Native 或 DeepSeek Harness Runtime，并记录切换条件。
为长任务设计持久化状态、幂等工具调用和恢复测试。
对 A2A 通信增加认证、超时、重试和最小权限控制。
用交付物完成门判断 Team Run，而不是只检查模型是否返回文本。

需要权衡的是，运行时可插拔和任务持久化会增加系统状态数量，A2A 互联也会扩大故障传播和权限管理范围。上线前应重点测试后端重启、网络中断、重复消息、工具部分成功以及交付物缺失等情况。

如果这些边界被明确管理，2.2.0 的价值就不只是多了几个执行选项，而是让 Agent 更像一个可以被调度、恢复、协作和验收的长期软件组件。