过去一年，各种 Agent 框架层出不穷，但大部分数字员工本质上还是个聊天助手——你问一句，它答一句，对话结束，任务也结束。MateClaw v1.4.0 想打破这个循环：让数字员工记住目标、拉人协作、在飞书里直接干活。这不是加几个按钮的小版本，而是从"被动响应"到"主动执行"的架构跃迁。
从问答到目标驱动：最关键的变化
旧版 MateClaw 的典型交互是这样的：
用户：帮我查一下上周的销售数据
员工：上周销售额为 128 万，同比增长 12%
用户：好的，谢谢
对话结束，员工就"下班"了。没有人追踪这个数据后续要不要做分析、要不要发报告、要不要提醒相关负责人。
v1.4.0 引入了目标锚定机制。员工不再只回答当前问题，而是会绑定一个持续追踪的目标状态：
用户：跟进本周客户回访进度，确保覆盖率达到 80%
员工：目标已锚定。当前覆盖率 45%，剩余 12 家客户待回访。
我会在每天 10:00 汇报进度，覆盖率不足时主动提醒负责人。
目标没完成，员工不会消失。它会按节奏检查、汇报、催办，直到目标达成或被手动关闭。
多员工协作：能找同事帮忙
单兵作战的 Agent 很快会遇到瓶颈——一个员工既懂销售又懂法务又懂财务，这不现实。v1.4.0 支持员工之间的跨角色协作：
- 销售员工发现合同条款有风险，可以主动呼叫法务员工审核
- 法务员工审核完，把结果推回销售员工继续推进
- 整个过程对用户透明，用户只看到最终结果
这背后是一个轻量的任务分发与回传协议，不是简单的 prompt 拼接。
团队权限与飞书落地
数字员工进了团队，就不能谁都叫它干活、什么都让它看。v1.4.0 加了角色权限体系：
- 不同团队成员对同一员工可见的能力范围不同
- 管理者可以审批员工发起的敏感操作（比如发送外部邮件、修改系统数据）
- 员工在飞书里以卡片形式推送审批请求，管理者点击"同意"或"拒绝"，员工才继续或终止
飞书集成不只是"能聊天"，而是真正嵌进了工作流：
- 收文件：员工可以从飞书群聊中拉取用户上传的附件进行处理
- 发卡片：审批、进度汇报、异常告警都以交互式卡片呈现
- 等审批：敏感动作挂起，等人在飞书里点一下才放行
实践示例：用 MateClaw 配一个目标驱动的回访员工
下面是一个最小化的配置示例，展示如何定义一个带目标追踪、能呼叫法务同事、在飞书发审批卡片的数字员工。假设你已经安装了 MateClaw CLI（pip install mateclaw），以下 YAML 可以直接改造使用：
# employee.yaml — MateClaw v1.4.0 数字员工配置
employee:
name: 客户回访专员
role: sales_followup
description: 跟进客户回访进度，确保覆盖率达标，遇合同风险呼叫法务审核
# 目标锚定配置
goal_tracking:
enabled: true
metric: 客户回访覆盖率
target: 80%
check_interval: daily # 每天检查一次进度
report_channel: feishu_card # 进度汇报发飞书卡片
alert_on_stagnation: true # 进度停滞时主动告警
# 跨角色协作
collaboration:
can_call:
- role: legal_review
trigger: 合同条款存疑 # 触发条件
task: 审核合同风险并返回结论
# 权限与审批
permissions:
visible_to: [sales_manager, sales_rep]
actions_require_approval:
- send_external_email # 发外部邮件需审批
- modify_crm_record # 修改 CRM 记录需审批
approval_channel: feishu_card # 审警请求发飞书卡片
# 飞书集成
feishu:
receive_files: true # 可从飞书群拉取附件
card_templates:
- id: progress_report # 进度汇报卡片
fields: [metric, current, target, remaining]
- id: approval_request # 审批请求卡片
fields: [action, reason, risk_level]
actions: [approve, reject]
用 CLI 启动这个员工：
# 初始化并注册员工
mateclaw register --config employee.yaml
# 在飞书群中绑定该员工
mateclaw bind --employee 客户回访专员 --feishu-group "销售回访群"
# 查看员工当前目标状态
mateclaw status --employee 客户回访专员
启动后，员工会在每天 10:00 自动检查回访覆盖率，低于目标时往飞书群发进度卡片。遇到合同风险，它呼叫法务员工审核；需要发外部邮件，它先发审批卡片等你点"同意"。
注意：以上 YAML 结构基于 v1.4.0 发布说明中的功能描述推导而来，具体字段名和 CLI 命令请以官方文档为准。建议先跑
mateclaw --help确认你安装版本的参数格式。
落地前想清楚的三件事
-
目标要可量化。目标锚定机制依赖明确的指标（覆盖率、完成数、响应时间），"提升客户满意度"这种模糊目标会让员工反复追问定义，反而增加沟通成本。先定好数字，再交给它追踪。
-
审批边界要提前划定。不是所有动作都需要人审批——过度审批会让数字员工变成一个不停发卡片的打扰者。建议只对涉及外部通信、数据修改、财务操作的动作设审批，内部查询和汇报直接放行。
-
协作链路别太长。A 呼叫 B，B 呼叫 C，C 又呼叫 A——三个员工互相等对方返回，任务卡死。设计协作时，控制链路深度在两层以内，超过的环节直接让人介入。
从问答助手到目标驱动的协作员工，这个转变不是功能堆叠，而是架构重写。如果你之前觉得 Agent 框架"能用但不像真的同事"，v1.4.0 值得重新评估——至少，它开始记住你交代的事了。