用途：把 Procore API 的调用量、工时、传输和积压视为可测量成本，找出并削减浪费的请求容量。注意：Procore 虽记录请求限制和活动报告，但没有统一的单次调用价格，因此费用结论必须来自使用者自身的基础设施与合同。
主要能力：
- 建立分母：按归一化路由统计总调用、失败调用、载荷量和工时，区分必要业务流量与重试、轮询、适配器缺陷。
- 消除失败浪费：优先修复反复出现的 400、403、404，因为失败请求也消耗速率预算；对私有或废弃路由应移除而非重试。
- 谨慎替换轮询：用 webhook 做变更提示，保留低频对账同步保证完整性；不应声称 webhook 是可靠的事件日志。
- 合并重复读取：缓存稳定的公司与项目元数据，改用集合请求而非逐条读取，只用有文档说明的过滤器、分页或同步操作。
- 量化节省：对比每个有效变更记录的调用数、失败占比、计算时间、传输、积压时长和基础设施成本；供应商费用需单独列出。
- 守护新鲜度：执行全量对账并比较状态哈希，任何遗漏记录、延迟必要更新或扩大权限的优化都要回滚。
认证：优化后的请求继续使用现有 OAuth 2.0 Bearer 令牌和公司范围；增加凭据不是成本或速率控制手段，也绝不可用于绕过限制。
工具纪律：用 Read 和 Grep 检查活动报告、指标、调用点和端点契约；Write 或 Edit 仅用于已批准的优化、测试、预算或凭据；成本分析期间不要修改 Procore 数据。
输出：路由级浪费与成本分母；带正确性证据的已批准优化；优化前后的 API、基础设施、新鲜度和回滚指标；报告实测节省并明确标注未知成本项。
示例：某集成每小时轮询大多返回未变更的 RFI，同时 404 重试消耗容量；修复访问缺陷后改用 webhook 提示读取，并保留夜间对账证明无记录遗漏。
错误处理：供应商价格未知时只报告请求与基础设施测量值，不臆造货币费率；出现 webhook 缺口时提高对账覆盖并修复投递处理；缓存返回过期授权数据时缩短或失效缓存，访问正确性优先于节省；调用减少却遗漏记录时回滚并恢复最近一次完整同步策略。
资源（第一方来源说明）：API Call Activity Report、速率限制、webhook 可靠性。