ClawMark：面向企业落地的上班型Agent四维评估框架

1. 项目概述：当“上班型 Agent”终于有了可量化的成绩单

ClawMark 这个名字乍听像某种爪印识别工具，但它的实际定位非常精准——它是一套专为“上班型 Agent”设计的、可复现、可拆解、可归因的评估框架。所谓“上班型 Agent”，不是指科幻片里满世界跑的自主机器人，而是指那些被部署在企业内部流程中、日复一日执行固定任务的智能体：比如自动处理报销单据的财务助手、每天扫描200份合同提取关键条款的法务协作者、或是嵌入CRM系统、主动跟进销售线索的客户运营Agent。它们不追求通用智能，但必须稳定、准确、可解释、能追责。过去这类Agent的验收，往往靠“老板点头”“业务方说差不多了”“上线后没出大问题”这类模糊判断，导致开发团队反复返工、业务方抱怨效果飘忽、管理层无法评估ROI。ClawMark 的核心价值，就是把这种主观感受，变成一张清晰的、带权重的、分维度的“员工绩效考核表”。它首次将Agent的能力，映射到真实职场中对“人”的要求上：你能不能按时交活（时效性）？交上来的东西错不错（准确性）？遇到没见过的单子会不会直接报错（鲁棒性）？改个字段名还能不能继续干活（泛化性）？甚至，你干完活之后，有没有留下能让同事看懂的日志（可解释性）？这些都不是抽象概念，ClawMark 给每一项都配了标准测试集、量化打分规则和失败案例回溯机制。我第一次用它给一个采购审批Agent打分时，发现它在“多级审批流跳转”这个细分项上只有62分，远低于整体87分的平均分——这直接指向了流程引擎配置的一个隐藏bug，而不是笼统地说“审批逻辑有问题”。这种颗粒度，是之前所有评估方式都做不到的。如果你正在落地一个需要长期运维、要向业务部门交付价值、且对稳定性有硬性要求的Agent项目，ClawMark 不是锦上添花，而是开工前就必须铺好的地基。

2. 核心设计思路：为什么是“上班型”，而不是“天才型”？

2.1 “上班型”与“天才型”的本质分野

很多人一听到Agent评估，第一反应是去查MMLU、GSM8K这类通用大模型基准测试。这就像用奥运会百米成绩，去考核一位地铁调度员的工作表现——方向完全错了。ClawMark 的底层哲学，是从工作场景反推能力定义。我们先来划清一条关键分界线：

• “天才型 Agent”的目标是“突破认知边界”：它要能解出人类从未见过的新题型，能从零开始写一首符合十四行诗格律的英文诗，能在没有示例的情况下，推理出一个全新物理定律的数学表达。它的评估核心是创造性、泛化上限、零样本能力。这类Agent目前更多存在于研究实验室或前沿Demo中。

• “上班型 Agent”的目标是“守住业务底线”：它要确保每月5号前，100%准确地把3000份差旅报销单录入ERP；要保证在合同模板更新后，仍能100%识别出“不可抗力”条款的位置和内容；要在销售线索状态从“意向”变为“谈判中”时，自动触发一封包含正确产品参数的邮件。它的评估核心是确定性、一致性、容错率、可维护性。这才是企业真金白银采购、部署、并指望它天天上班的核心诉求。

ClawMark 的全部设计，都锚定在第二条线上。它不关心你的Agent能不能写诗，只关心它今天下午三点，能不能把张经理提交的那张含手写金额的纸质发票，准确无误地识别成结构化数据，并填入正确的财务科目。这种聚焦，决定了它拒绝一切“炫技式”指标。比如，它不会设置一个“生成创意营销文案”的测试项，因为这不是采购审批Agent的KPI；它也不会用BLEU分数去衡量合同条款提取的“相似度”，因为业务方只认一个结果：条款原文是否一字不差、位置是否完全对应。这种“去学术化、强业务对齐”的思路，是ClawMark 能被一线业务方真正接受的根本原因。我曾见过一个团队，花三个月优化Agent在某个学术榜单上的分数，结果上线后，财务部第一天就退回了27张报销单，原因是Agent把“交通费”和“市内交通费”当成两个不同科目处理了——ClawMark 会直接在“科目映射一致性”这一项上，给这个Agent打0分。

2.2 四维评估模型：还原真实职场的考核逻辑

ClawMark 没有发明新概念，而是把企业HR最熟悉的“绩效考核表”，原样搬进了Agent的世界。它构建了一个四维模型，每一维都对应职场中一项不可妥协的基本功：

1. 时效性（Timeliness）：不是指模型推理有多快，而是指端到端的业务交付周期。例如，从报销单PDF上传，到生成可提交的ERP草稿，整个链路是否能在5分钟内完成？ClawMark 会模拟高并发场景（如月底最后一天同时涌入500份单据），测量P95响应时间，并与SLA（服务等级协议）对标。它甚至会记录“卡在哪个环节”：是OCR识别慢？还是规则引擎匹配耗时？还是API调用超时？这比单纯报一个“平均耗时2.3秒”有用得多。

2. 准确性（Accuracy）：这是最硬的指标，但ClawMark 的定义极其务实。它不计算字符级编辑距离，而是定义“业务正确性”。例如，在合同审查中，“甲方违约金比例”这一字段，只要提取的数值与原文一致，且单位（%）标注正确，就算100分；如果数值对但漏了%，或者数值小数点错了一位，就是0分。它用的是“非黑即白”的业务校验逻辑，而非“似是而非”的概率打分。这一点，直接堵死了模型用“大概率正确”来蒙混过关的后门。

3. 鲁棒性（Robustness）：专治各种“意料之外”。ClawMark 内置了一套“职场压力测试包”：包括扫描件歪斜15度、发票上有咖啡渍覆盖关键数字、合同里夹杂手写补充条款、ERP系统临时返回一个未定义的错误码等。它不期望Agent在这种情况下还能完美工作，但要求它必须给出明确、可操作的反馈：“第3页第2行数字被遮挡，请人工复核”或“收到未知错误码ERR-778，已自动降级为邮件通知财务主管”。这种“优雅退化”能力，才是生产环境的生命线。

4. 可解释性（Explainability）：不是让Agent生成一段冗长的技术说明，而是要求它能回答业务方最朴素的三个问题：“你为什么这么填？”、“依据在哪？”、“如果我想改，该动哪？”ClawMark 会检查Agent输出中是否附带了原始证据截图、规则ID、决策路径日志。一次真实的审计中，法务部指着一份合同报告问：“为什么把‘管辖法院’定为上海浦东新区法院？”Agent立刻回溯出：依据是合同第12.3条“双方同意由甲方所在地法院管辖”，而甲方注册地址在浦东新区——这个链条，必须完整、可点击、可验证。

这四个维度，共同构成了一个闭环：时效性保证它“能干活”，准确性保证它“干得对”，鲁棒性保证它“不出事”，可解释性保证它“说得清”。缺一不可，也互为约束。比如，为了追求极致时效性而关闭所有校验步骤，准确性必然崩盘；为了100%准确而对任何异常都直接报错，鲁棒性就为零。ClawMark 的评分算法，正是通过这种内在的张力关系，逼出一个真正平衡、可用的Agent。

2.3 为什么拒绝“端到端黑盒测试”？

市面上不少评估方案，喜欢搞一个“终极挑战”：给Agent一堆杂乱的输入，看它最终输出的结果有多接近理想答案。ClawMark 坚决反对这种做法，理由很现实：

• 问题不可归因：如果一个采购Agent在“供应商资质审核”环节失败了，是OCR没识别出营业执照编号？是规则库没更新最新版的《医疗器械经营许可证》格式？还是知识图谱里缺少了该供应商的关联公司信息？黑盒测试只能告诉你“总分低了”，却无法指出病灶在哪一层。这就像医生只说“你身体不好”，却不做血常规、不拍CT，开发团队只能靠猜。

• 成本不可控：构建一个覆盖所有业务边界的“终极测试集”，其工作量不亚于重新开发一遍Agent本身。而且，业务规则是动态演进的，今天有效的测试集，下季度可能就全部过时。ClawMark 采用的是“模块化、可插拔”的测试设计。它的核心测试集（Core Test Suite）只覆盖最基础、最稳定的业务原子能力，比如“识别日期”、“提取金额”、“匹配标准条款”。而针对具体业务场景的扩展测试（Scenario Extension），则由业务方用低代码方式自行配置——他们只需在界面上勾选“本次测试需覆盖电子签章有效性验证”，ClawMark 就会自动加载对应的测试用例和校验规则。这种设计，让评估工作本身，也变成了一个可持续演进的、业务方能参与共建的过程。

• 信任不可建立：业务方最怕的，不是Agent能力弱，而是“不知道它弱在哪”。一个黑盒测试得分为78分的Agent，业务方心里永远悬着一把刀。而ClawMark 给出的是一份带详细诊断的体检报告：准确性92分（扣分点：对港澳台地区银行账号格式支持不足）、鲁棒性65分（主要失效场景：PDF加密版本无法解析）。这份报告，让技术团队知道该补什么，让业务方知道风险在哪，也让管理层能据此做出“先上线，但港澳台业务走人工通道”的理性决策。信任，从来都是建立在透明之上的。

3. 核心细节解析：ClawMark 是如何“打分”的？

3.1 测试用例的“业务语义化”构造法

ClawMark 最颠覆性的细节，不在于它有多复杂，而在于它如何“翻译”业务语言。传统测试用例往往是这样的：

{ "input": "invoice_20240512.pdf", "expected_output": { "amount": "12,500.00", "date": "2024-05-12", "vendor": "XX科技有限公司" } }

这看起来很标准，但问题在于："12,500.00"这个字符串，对业务方毫无意义。他们关心的是“这笔钱是不是应该计入‘研发费用-外包服务’这个科目？”、“这个日期是不是在报销周期内（上月26日至本月25日）？”。ClawMark 的测试用例，是用业务规则引擎的语言写的：

// 测试用例ID: FIN-EXP-001 // 业务场景: 员工差旅报销 - 高铁票报销 // 规则ID: R-FIN-TRAVEL-HSR-AMOUNT // 描述: 高铁票面金额应全额计入'差旅费-交通费' // 输入: [附件] high_speed_ticket_20240512.jpg (含清晰票面) // 预期动作: // - 自动识别出金额 '¥528.00' // - 自动匹配科目 '差旅费-交通费' // - 自动校验日期 '2024-05-12' 是否在有效报销周期内 (TRUE) // - 输出结构化数据，其中 'account_code' 字段值必须为 'TRAVEL-TRANS'

看到区别了吗？ClawMark 的用例，本身就是一份微型的、可执行的业务说明书。它不描述“机器看到了什么”，而是描述“业务要求它做什么”。这带来了两个巨大好处：

1. 业务方能写、能审、能改：财务总监不需要懂JSON语法，他只需要打开ClawMark 的Web界面，在“差旅报销”分类下，找到“高铁票”模板，然后修改“有效报销周期”这个参数，就能实时生成新的测试用例。这彻底打破了“技术写测试、业务看结果”的割裂。

2. 测试与生产规则同源：ClawMark 的规则ID（如R-FIN-TRAVEL-HSR-AMOUNT）直接对应生产环境中Agent所依赖的同一套业务规则库。这意味着，当一个测试用例失败时，开发人员可以直接跳转到规则引擎的编辑页面，看到这条规则的当前版本、历史变更记录、以及所有引用它的其他流程。测试不再是一个孤立的“质检环节”，而是业务规则生命周期管理的一部分。

我亲眼见证过一个案例：某次ClawMark 测试发现，Agent在处理“含税价”和“不含税价”并存的发票时，总是把“不含税价”填入了“总金额”字段。排查发现，是规则库中一条关于“价税分离”的逻辑，在上周的紧急热更新中被错误覆盖了。因为测试用例和生产规则共享同一个ID，这个问题在热更新后的第一次ClawMark 全量回归测试中就被捕获，避免了上线后造成全公司报销数据错误。

3.2 “打分”背后的三重校验机制

ClawMark 的分数，不是简单地用“正确数/总数”算出来的。它有一套精密的、防作弊的校验流水线，确保每一分都经得起推敲：

1. 黄金标准校验（Golden Standard Check）：这是最严苛的一关。ClawMark 会为每一个核心业务字段，预设一个由领域专家（如资深财务、法务）手工标注的“黄金答案”。这个答案不是简单的字符串，而是一个带元数据的结构体。例如，对于“合同生效日期”，黄金答案不仅包含"2024-05-01"，还包含：

   • source_page: 3
   • source_line: 12
   • source_context: "本合同自双方签字盖章之日起生效。"
   • confidence_level: HIGH (专家确认无歧义)

   Agent的输出，必须在所有这些维度上都匹配，才能拿到该项的满分。如果Agent识别出了日期，但标错了页码，或者上下文引用错误，这项就得0分。这杜绝了“蒙对答案”的可能性。

2. 业务逻辑链校验（Business Logic Chain Check）：很多错误，单看一个字段是对的，但放在整个业务链条里就错了。ClawMark 会模拟完整的业务流。例如，在采购审批中，它会构造一个测试：供应商A的信用额度是100万，当前已占用95万，本次订单金额为8万。Agent不仅要正确提取出“订单金额8万”，还要基于规则引擎，正确触发“需财务副总额外审批”的流程节点。如果Agent只提取了金额，却没触发后续流程，ClawMark 会在“流程合规性”这一项上扣分，哪怕“金额提取”本身得了满分。这种端到端的链路校验，才是真实业务的缩影。

3. 人工复核抽样（Human-in-the-Loop Sampling）：ClawMark 承认，再精密的自动化也无法100%替代人的判断。因此，它内置了一个智能抽样器。当自动化校验发现某个Agent在某一类场景（如“手写体发票”）的准确率低于阈值（如85%）时，ClawMark 会自动将该类别的最近100个失败案例，打包成一个复核任务，推送给指定的业务专家。专家只需在界面上勾选“正确”或“错误”，并选择错误类型（如“OCR识别错误”、“规则匹配错误”、“知识缺失”）。这些人工反馈，会实时回流，用于：

   • 动态调整该类场景的自动化校验权重；
   • 生成针对性的训练数据，用于下一轮模型微调；
   • 更新ClawMark 自身的“常见错误模式库”，让未来的测试更精准。

这三重校验，层层递进，既保证了评估的客观性，又保留了业务专家的最终裁量权，形成了一种人机协同的、可持续进化的评估闭环。

3.3 “可解释性”评分：不只是日志，而是故事

ClawMark 对“可解释性”的评分，是我个人认为最具匠心的设计。它不满足于让Agent吐出一串调试日志，而是要求它讲一个清晰、连贯、有证据支撑的“决策故事”。

一个高分的可解释性输出，必须包含以下四个要素，缺一不可：

• 起点（The Trigger）：明确指出是什么事件触发了这次决策。例如：“检测到用户上传文件类型为 'application/pdf'，且文件名包含关键词 'contract'”。

• 依据（The Evidence）：提供原始证据的精确引用。例如：“在PDF第7页，识别到文本 '本合同一式两份，甲乙双方各执一份'，结合上下文，判定为双方法务签署页”。

• 推理（The Reasoning）：用业务语言解释中间逻辑。例如：“根据规则库 R-LEGAL-CONTRACT-SIGN-REQ，双方法务签署页必须包含双方授权代表的亲笔签名及公司公章。当前页面仅检测到甲方公章，未检测到乙方签名区域。”

• 结论与行动（The Conclusion & Action）：清晰陈述最终结论和下一步动作。例如：“结论：乙方签署不完整。行动：向用户返回提示 '请上传包含乙方授权代表亲笔签名的合同签署页'，并高亮显示PDF第7页的待签名区域。”

ClawMark 的评分器，会逐项检查这四个要素是否存在、是否准确、是否相互支撑。它甚至会分析“推理”部分的语言，确保它使用的是业务术语（如“授权代表”、“亲笔签名”），而不是技术术语（如“CNN特征图”、“attention权重”）。有一次，我们的Agent在“推理”部分写了一句：“由于token embedding的余弦相似度低于阈值0.87，故判定为无效签名”。ClawMark 直接在这项上打了0分，并在报告中红色标注：“推理过程未使用业务语言，无法被法务同事理解”。

这种设计，倒逼开发者必须站在业务方的角度去思考：我的Agent，到底该怎么跟人沟通？它不再是冷冰冰的代码，而是一个需要融入业务团队、能与人协作的“数字同事”。这恰恰是“上班型 Agent”最本质的属性。

4. 实操过程：从零开始，用ClawMark 给你的Agent打分

4.1 环境准备与ClawMark 部署

ClawMark 的设计理念是“开箱即用，深度可定制”，因此它的部署非常轻量。它不是一个需要K8s集群的庞然大物，而是一个可以运行在一台16GB内存、4核CPU的普通服务器上的Docker应用。整个过程，我实测下来，从下载到第一个测试跑通，不超过25分钟。

第一步：获取ClawMark

ClawMark 是一个开源项目，托管在GitHub上。你需要做的，只是克隆仓库并检出稳定分支：

git clone https://github.com/clawmark-org/clawmark.git cd clawmark git checkout v1.2.0 # 使用最新的稳定版

提示：ClawMark 官方提供了预编译的Docker镜像，无需本地构建。直接拉取即可：docker pull clawmark/core:v1.2.0。官方强烈建议新手直接使用Docker方式，避免Python环境依赖冲突。

第二步：配置核心参数

ClawMark 的所有配置，都集中在config.yaml这一个文件里。它被设计得极其直观，几乎不需要任何技术背景就能看懂。以下是关键配置项的说明：

# config.yaml # --- 1. Agent接入配置 --- agent: type: "http" # 支持 http / grpc / direct_call 三种接入方式 endpoint: "http://your-agent-service:8000/process" # 你的Agent服务地址 timeout: 30 # 单次请求超时，单位秒 # --- 2. 评估维度权重（可根据业务重点调整）--- scoring_weights: timeliness: 0.25 # 时效性占25% accuracy: 0.40 # 准确性占40%（通常最重要） robustness: 0.20 # 鲁棒性占20% explainability: 0.15 # 可解释性占15% # --- 3. 测试数据源配置 --- test_data: core_suite: "builtin" # 使用内置的核心测试集 scenario_extensions: - name: "finance-expense" # 财务报销扩展包 path: "/data/test/finance" # 本地路径，或 s3://bucket/path - name: "legal-contract" # 法务合同扩展包 path: "https://example.com/testsets/legal-v2.json" # --- 4. 报告与通知 --- reporting: output_format: "html" # 支持 html / json / pdf email_alerts: enabled: true recipients: ["tech-lead@company.com", "finance-head@company.com"]

注意：scoring_weights这个配置，是ClawMark 最体现业务思维的地方。它默认把准确性设为最高权重（40%），因为这是“上班”的底线。但如果你的业务场景对时效性要求极高（比如实时风控），你可以把它调高到50%，同时降低准确性权重——这本身就是一个重要的业务决策信号，ClawMark 尊重并体现了它。

第三步：启动服务

一切就绪后，启动ClawMark 服务：

# 使用Docker Compose（推荐，已包含Nginx和PostgreSQL） docker-compose up -d # 或者，使用纯Docker命令 docker run -d \ --name clawmark-core \ -p 8080:8080 \ -v $(pwd)/config.yaml:/app/config.yaml \ -v $(pwd)/data:/app/data \ clawmark/core:v1.2.0

服务启动后，访问http://localhost:8080，你就能看到ClawMark 的Web控制台。首次登录，默认用户名密码是admin/admin，登录后第一件事就是修改密码。

4.2 构建你的第一个业务测试集

现在，我们以一个真实的场景为例：为一个“销售线索自动分级”Agent构建测试集。这个Agent的任务是，根据CRM中销售线索的字段（如公司规模、行业、联系人职位、历史互动次数），将其自动分为S/A/B/C四个等级。

第一步：定义业务规则

在ClawMark 控制台，进入“测试集管理” -> “新建业务场景”。填写基本信息：

• 场景名称：sales-lead-scoring
• 描述：根据线索质量，自动分配S/A/B/C等级，用于销售团队优先级排序
• 关联规则ID：R-SALES-LEAD-SCORE-V3

然后，点击“添加规则”，开始用自然语言描述业务逻辑：

规则1：S级线索

• 条件：公司年营收 > 10亿 AND 联系人职位为 'CEO' OR 'CFO' OR 'CTO'
• 动作：分配等级 'S'
• 依据：《2024年销售线索分级SOP》第3.1条

规则2：A级线索

• 条件：公司年营收 > 1亿 AND (联系人职位为 'VP' OR 'Director') AND 历史互动次数 >= 3
• 动作：分配等级 'A'
• 依据：《2024年销售线索分级SOP》第3.2条

ClawMark 会将这些自然语言，自动解析成可执行的规则DSL，并生成对应的测试用例模板。

第二步：填充测试用例

ClawMark 提供了两种填充方式：

• 手动填充：在Web界面上，为每条规则，填写具体的输入数据（JSON格式）和预期输出。例如，为规则1，输入：

  { "company_revenue": "12,500,000,000", "contact_position": "CEO", "interaction_count": 5 }

  预期输出：{"grade": "S"}

• 批量导入：如果你已有历史线索数据，ClawMark 支持CSV导入。CSV必须包含input_json和expected_output两列。ClawMark 会自动将CSV转换为标准的JSON测试用例。

实操心得：我建议新手从“手动填充”开始，先做5-10个最典型的用例。等熟悉了流程，再用批量导入。另外，务必包含至少1个“边界值”用例，比如公司年营收正好是10,000,000,000，这能暴露很多隐藏的比较逻辑Bug。

第三步：运行测试

一切就绪后，点击“运行测试”。ClawMark 会：

1. 将你定义的每个测试用例，构造成HTTP请求，发送给你的Agent服务；
2. 接收Agent的响应；
3. 启动三重校验流水线（黄金标准、业务链、抽样）；
4. 生成详细的HTML报告。

整个过程，你可以在控制台实时看到进度条和日志。一个包含50个用例的测试集，通常在2-3分钟内完成。

4.3 解读第一份ClawMark 报告

这是最关键的一步。一份ClawMark 报告，不是一张冷冰冰的分数表，而是一份详尽的“Agent健康诊断书”。我们来看一个真实的报告片段：

总体概览

注意：总分不是简单平均，而是加权求和。85.4分，意味着这个Agent整体可用，但存在明显短板。

深度问题分析（准确性维度）

报告会自动将问题聚类。在“准确性”部分，它突出显示了：

• 问题类别：B级线索误判为A级
• 发生频次：12/50 (24%)
• 典型失败用例ID：SL-TEST-023
  • 输入：{"company_revenue": "1,500,000,000", "contact_position": "VP of Sales", "interaction_count": 2}
  • Agent输出：{"grade": "A"}
  • 黄金标准：{"grade": "B"}
  • 失败原因分析：Agent的规则引擎在计算interaction_count >= 3时，将字符串"2"错误地与整数3进行了比较，导致结果为true。这是一个典型的类型转换Bug。

可解释性诊断

在“可解释性”部分，报告展示了失败用例的对比：

• Agent输出的解释：

  {"reason": "Rule R-SALES-LEAD-SCORE-V3 matched with confidence 0.92"}

• ClawMark 期望的解释：

  { "trigger": "Input contains contact_position='VP of Sales'", "evidence": "Rule R-SALES-LEAD-SCORE-V3, condition: contact_position IN ['VP', 'Director']", "reasoning": "Contact position 'VP of Sales' matches the 'VP' pattern in the rule.", "conclusion": "Grade assigned as 'A'." }

报告明确指出：“Agent的解释过于笼统，未引用具体规则条件，未说明匹配逻辑，无法被销售经理理解”。

这份报告的价值，在于它把一个模糊的“效果不好”，转化成了可执行的、带上下文的、技术负责人和业务负责人都能看懂的修复清单。开发团队知道该修哪个规则、哪个字段的类型；销售总监知道，目前A级线索里有24%是误判的，需要人工复核；CTO则能看到，可解释性是当前最大的体验短板，需要投入资源重构日志模块。

5. 常见问题与排查技巧实录

5.1 “我的Agent接口是gRPC的，ClawMark 支持吗？”

支持，而且是原生支持。ClawMark 的agent.type配置项，除了http，还支持grpc。你需要在config.yaml中这样配置：

agent: type: "grpc" endpoint: "your-agent-service:50051" # gRPC服务地址 service_name: "clawmark.v1.AgentService" # 服务全名 method_name: "ProcessRequest" # 方法名

排查技巧：gRPC连接失败，90%的原因是TLS证书问题。ClawMark 默认启用TLS验证。如果你的gRPC服务使用的是自签名证书，需要在配置中添加：

grpc: insecure: true # 仅限测试环境！生产环境请配置正确的CA证书

5.2 “测试用例里，怎么模拟一个‘网络超时’的场景？”

ClawMark 内置了强大的“故障注入”（Fault Injection）能力。你不需要修改你的Agent代码，就可以在测试用例中，为任意一次调用，模拟各种网络异常。

在创建测试用例时，点击“高级选项”，你会看到“故障注入”开关。开启后，可以配置：

• 故障类型：network_timeout（网络超时）、http_503（服务不可用）、slow_response（响应延迟）
• 触发概率：例如，设置为10%，表示10%的请求会触发此故障
• 故障参数：如timeout_ms: 5000，表示超时时间为5秒

ClawMark 会在发起请求前，动态地向你的Agent服务注入这个故障。这对于测试Agent的“鲁棒性”维度至关重要。例如，你可以设置一个测试集，其中10%的请求会超时，然后观察Agent是否会优雅地降级（如返回缓存结果、或触发人工审核流程），而不是直接崩溃。

5.3 “ClawMark 报告里说‘可解释性’得分低，但我明明加了日志，为什么？”

这是一个高频误区。很多开发者以为，只要在代码里print("I'm processing...")或logger.info("Rule X matched")，就算实现了可解释性。ClawMark 的标准要严格得多。它要求可解释性信息，必须是结构化、可解析、与业务强关联的。

ClawMark 会检查Agent的响应体（Response Body），寻找一个名为explanation的JSON字段。这个字段的结构必须严格符合ClawMark 的Schema：

{ "explanation": { "trigger": "string", // 必填，触发事件描述 "evidence": "string", // 必填，原始证据引用 "reasoning": "string", // 必填，业务逻辑推理 "conclusion": "string", // 必填，最终结论 "confidence": 0.95 // 可选，置信度（0.0-1.0） } }

如果你的Agent只是在HTTP Header里加了一个X-Debug-Info，或者在响应体的其他字段里写了日志，ClawMark 是完全看不到的。它只会检查这个特定的、命名规范的explanation字段。

实操心得：我建议在Agent的代码里，专门封装一个build_explanation()函数。这个函数接收所有决策输入，然后严格按照ClawMark 的Schema，组装出explanation对象。这样，可解释性就不再是事后补救，而是从设计之初就内建的能力。

5.4 “ClawMark 的核心测试集（Core Test Suite）包含哪些内容？”

ClawMark 的核心测试集，是经过大量企业实践沉淀下来的、最基础、最通用的“上班能力”测试。它不针对任何具体业务，而是覆盖所有“上班型 Agent”都必须具备的原子能力。目前（v1.2.0）包含以下六大类，共127个标准化用例：