MateClaw 1.7.0 的关键词不是“又接了一个模型”或“又多了一个入口”，而是生产化加固。上一阶段它已经把数字员工、LLM Wiki、工作流、触发器、技能、MCP、ACP、多渠道入口、桌面端和 WebChat 收进同一套 Spring Boot Agent Harness。到了 1.7.0，问题变得更硬：审批不能挂死，长任务不能黑盒，Token 花销不能看不见。
从“功能齐全”进入“故障可控”
Agent 平台在 Demo 阶段最容易展示的是能力编排：用户提问，Agent 查资料、调工具、跑工作流，然后输出结果。可一旦放进团队日常流程，真正危险的往往不是“不会回答”，而是下面这些状态失控：
- 审批节点卡住，后续任务全部等待，没有超时、重试或人工接管路径。
- 长任务跑了十几分钟，用户和运维都不知道当前卡在检索、工具调用、外部 API 还是模型生成。
- Token 消耗被藏在日志角落，月底才发现某个自动触发器烧掉预算。
- 本地模型、远程模型、多渠道入口混在一起，排障时缺少统一的运行视图。
MateClaw 1.7.0 的价值就在这里：它把注意力从“Agent 能做什么”转到“Agent 出问题时团队能不能看见、能不能停住、能不能恢复”。这类变化没有炫技，但它决定了平台能不能进入生产链路。
审批不能挂死：Human-in-the-loop 要有超时和兜底
很多 Agent 工作流都会引入审批：发邮件前确认、执行高风险命令前确认、同步客户数据前确认。审批本身没有问题，问题是审批节点一旦没有生命周期管理，就会变成队列里的石头。
在生产环境里，审批至少需要三类状态：
PENDING：等待处理，但必须有创建时间、过期时间和负责人。APPROVED/REJECTED：明确的业务结果，可以驱动后续工作流。EXPIRED/ESCALATED：没人处理时的系统行为，不能无限等待。
可以这样实践：即使你还没有完整接入 MateClaw，也可以先在外围服务里为审批任务建立一个可观测的状态表，避免“等人点一下”变成永久阻塞。
CREATE TABLE agent_approval_task (
id BIGSERIAL PRIMARY KEY,
workflow_id VARCHAR(128) NOT NULL,
step_id VARCHAR(128) NOT NULL,
assignee VARCHAR(128) NOT NULL,
status VARCHAR(32) NOT NULL DEFAULT 'PENDING',
reason TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
expires_at TIMESTAMPTZ NOT NULL,
decided_at TIMESTAMPTZ
);
CREATE INDEX idx_agent_approval_pending
ON agent_approval_task (status, expires_at)
WHERE status = 'PENDING';
如果你的 Agent Harness 是 Spring Boot 服务，可以用一个定时任务扫过期审批。下面示例是可改造的最小形态，重点是把“过期”变成显式状态，而不是让线程或工作流无限挂起。
package com.example.agentops;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;
@Component
public class ApprovalTimeoutJob {
private final JdbcTemplate jdbcTemplate;
public ApprovalTimeoutJob(JdbcTemplate jdbcTemplate) {
this.jdbcTemplate = jdbcTemplate;
}
@Scheduled(fixedDelayString = "${agent.approval-timeout-scan-ms:30000}")
public void expirePendingApprovals() {
int expired = jdbcTemplate.update("""
UPDATE agent_approval_task
SET status = 'EXPIRED', decided_at = now(), reason = 'approval timeout'
WHERE status = 'PENDING'
AND expires_at < now()
""");
if (expired > 0) {
System.out.println("expired approval tasks=" + expired);
}
}
}
运行前需要把表名、数据源和工作流回调逻辑替换成你自己的实现。真实生产里还应该补上审计日志、通知、幂等回调和权限校验。
长任务不能黑盒：进度、阶段和外部调用要能追踪
Agent 的长任务通常跨多个系统：知识库检索、MCP 工具调用、ACP 协作、业务 API、LLM 生成、多渠道回推。任何一个环节慢，都可能让用户看到一个没有意义的“处理中”。
生产级长任务应该记录两种信息：
- 面向用户的阶段：例如
retrieving_context、calling_tool、waiting_approval、generating_answer。 - 面向工程排障的事件：模型名、工具名、耗时、错误码、重试次数、Token 用量。
可以这样实践：为 Agent 执行链路加一个轻量事件上报接口，前端、WebChat、桌面端或运维面板都从这个接口读状态。
curl -X POST http://localhost:8080/api/agent-runs/run_20250101_001/events \
-H 'Content-Type: application/json' \
-d '{
"stage": "calling_tool",
"message": "Calling CRM customer lookup",
"tool": "crm.findCustomer",
"elapsedMs": 842,
"inputTokens": 1200,
"outputTokens": 180
}'
对应的事件结构可以保持克制，不要一开始就设计成复杂追踪系统：
{
"runId": "run_20250101_001",
"stage": "calling_tool",
"message": "Calling CRM customer lookup",
"tool": "crm.findCustomer",
"elapsedMs": 842,
"inputTokens": 1200,
"outputTokens": 180,
"createdAt": "2025-01-01T10:00:00Z"
}
这类事件的好处很直接：用户知道任务还活着，运维知道慢在哪里，研发能复盘某次异常执行。MateClaw 1.7.0 强调长任务不再是黑盒，落地时就应该把“运行中”拆成可观察的阶段。
Token 花销要可见：预算是系统边界，不是财务报表
Agent 平台接入多模型后，Token 成本很容易从“单次请求几分钱”变成“自动触发器全天运行”。尤其是 LLM Wiki、工作流、技能和多渠道入口统一之后，调用来源更多，成本归因更难。
生产环境里，Token 统计不应该只留在模型网关日志中。建议至少按以下维度打点：
tenant：哪个团队或租户。agent：哪个数字员工或工作流。channel：WebChat、桌面端、触发器、API 等入口。model：具体模型或本地模型标识。input_tokens/output_tokens：输入输出分开算。
可以这样实践：用 Prometheus 暴露 Token 指标，并在调用模型后递增计数器。
package com.example.agentops;
import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.MeterRegistry;
import org.springframework.stereotype.Service;
@Service
public class TokenUsageRecorder {
private final MeterRegistry registry;
public TokenUsageRecorder(MeterRegistry registry) {
this.registry = registry;
}
public void record(String tenant, String agent, String channel, String model,
int inputTokens, int outputTokens) {
Counter.builder("agent_llm_tokens_total")
.tag("tenant", tenant)
.tag("agent", agent)
.tag("channel", channel)
.tag("model", model)
.tag("direction", "input")
.register(registry)
.increment(inputTokens);
Counter.builder("agent_llm_tokens_total")
.tag("tenant", tenant)
.tag("agent", agent)
.tag("channel", channel)
.tag("model", model)
.tag("direction", "output")
.register(registry)
.increment(outputTokens);
}
}
配合 Spring Boot Actuator，可以这样打开指标端点：
management:
endpoints:
web:
exposure:
include: health,info,prometheus
metrics:
tags:
service: mateclaw-agent-harness
然后用 Prometheus 抓取：
scrape_configs:
- job_name: mateclaw-agent-harness
metrics_path: /actuator/prometheus
static_configs:
- targets:
- localhost:8080
这里的边界要讲清楚：Token 指标不是完整成本系统。不同模型价格不同，本地模型还有机器成本，缓存命中也会改变账单。但没有这层基础指标，团队连“谁在花、花在哪、什么时候暴涨”都看不见。
本地模型进入平台后，运维复杂度会上来
摘要里提到本地模...，虽然细节未展开，但方向很明确：Agent 平台不再只依赖远端模型 API，本地模型会成为生产部署的一部分。它带来的价值是数据边界、延迟控制和成本弹性；代价是容量规划、GPU/CPU 资源、模型版本和降级策略都要由平台自己承担。
可以给本地模型接入设一个最小检查清单：
- 模型服务是否有健康检查，而不是只看进程是否存在。
- Agent 调用是否有超时、熔断和备用模型。
- 本地模型版本是否进入审计日志，方便复盘回答差异。
- Token、耗时、错误率是否和远端模型用同一套指标口径。
- 多渠道入口是否共享限流策略，避免某个入口把本地推理资源打满。
对于团队来说，本地模型不是“省钱按钮”，更像是把一部分基础设施责任拿回自己手里。MateClaw 1.7.0 的生产化语境下，这件事必须和观测、审批、预算一起设计。
采用建议：先把失控路径补齐，再扩大 Agent 覆盖面
如果你已经在试用 MateClaw 或类似 Spring Boot Agent Harness，1.7.0 这类版本最值得验证的不是聊天效果，而是故障场景。
上线前可以按这个顺序检查：
- 找一个真实长工作流，强制制造工具超时、审批无人处理、模型调用失败，确认系统能结束、能告警、能复盘。
- 给每个 Agent 入口打上
tenant、agent、channel标签，避免成本和错误率混在一起。 - 把审批任务从“消息通知”升级为“有状态资源”，让过期、拒绝、升级都有明确路径。
- 为本地模型和远端模型使用统一的调用日志与指标，不要形成两套排障语言。
- 先把高风险工作流放进灰度环境，观察 Token、耗时和人工介入比例，再扩大到更多团队。
Agent 平台从“能用”到“敢放进生产”，差的不是一个更会说话的模型，而是这些无聊但关键的控制面。MateClaw 1.7.0 把重点放在审批、长任务、Token 成本和本地模型运维上，说明它正在处理真实团队会遇到的硬问题。对于工程团队，这比又多一个炫目的演示更值得关注。