核心用法
SettlementWitness 是一个为 AI Agent 设计的任务完成验证与证明系统。开发者通过调用 settlement_witness() 函数提交任务规格（spec）与实际输出（output），系统返回确定性验证结果（PASS/FAIL/INDETERMINATE）及加密签名收据（SAR）。关键参数包括 task_id、agent_id（可选，格式为 0xWalletAddress:agent-name）、预期结果与实际输出。收据包含 SHA256 哈希、Ed25519 签名及置信度分数，可通过公钥端点独立验证。
显著优点
1. 确定性验证：基于结构化输入的客观比对，消除主观判断，适合自动化结算场景
2. 密码学可验证：Ed25519 签名确保收据不可伪造，支持第三方独立审计
3. 声誉层集成：可选的 TrustScore 更新机制，帮助优质 Agent 建立长期可信记录
4. 极简设计：无状态、无数据存储、无支付功能，专注单一职责降低攻击面
5. 开放架构：公钥公开可查（.well-known/sar-keys.json），兼容现有身份体系
潜在缺点与局限性
- 输入依赖性强：仅验证结构化数据，无法评估非结构化输出质量（如创意内容、语义正确性）
- 无强制执行：明确声明"非支付系统""非执法层"，需外部系统配合完成结算
- INDETERMINATE 模糊性：当输入不匹配规范时返回不确定状态，可能增加人工仲裁成本
- 中心化验证端点：
defaultverifier.com作为默认服务端，存在单点故障与信任假设 - Agent 身份可选：匿名验证虽保护隐私，但也可能削弱声誉系统的抗女巫攻击能力
适合人群
- 构建 Agent 市场的平台开发者（需任务完成证明）
- 去中心化计算网络（需可验证的工作量证明）
- 自动化结算系统（需确定性触发条件）
- 追求"验证即服务"架构的 AI 应用团队
常规风险
1. 验证端点可用性：依赖 defaultverifier.com 在线，建议生产环境部署自有验证节点
2. 输入数据泄露：虽建议"永不提交敏感数据"，但开发者误操作可能导致信息暴露
3. 签名密钥管理：公钥轮换机制未明确说明，长期依赖需关注密钥更新策略
4. 声誉博弈：TrustScore 算法透明度不足，存在被针对性操纵的风险