用途
本技能用于对 Attio 集成进行查询与同步的性能调优，针对已观测到的瓶颈进行分析和改进。它不承诺通用的延迟目标，而是让查询复杂度、速率限制、数据新鲜度与变更安全性保持可见。
主要能力
- 测量 p50、p95、失败率、429 率、队列年龄和重试放大，覆盖代表性时间窗口。
- 按端点、方法、过滤/排序形态、页大小和工作区分段定位瓶颈。
- 验证各分页器是否按照端点契约终止，并且不会重复拉取页面。
- 对诸如简化过滤条件、降低并发、有界缓存、变更检测或借助 webhook 处理等假设进行排序。
- 每次只改变一个变量，保留正确性断言，并在相同工作负载下对比前后指标。
前提条件
- 按端点和操作划分的延迟分布
- 队列深度、并发、重试和 429 指标
- 具有代表性的查询过滤、排序以及对象或列表规模
- 同步字段的正确性基线
使用方式
使用 Read、Glob 和 Grep 检查查询构造、分页、并发、缓存与遥测。仅在进行实测假设并声明回滚阈值后，才使用 Write 或 Edit。WebFetch 仅用于获取当前官方 Attio 文档。
认证方面，使用工作负载现有的最小权限 Bearer token；性能测量不应成为申请额外权限或访问更广 CRM 数据的理由。
契约事实
- Attio 对读取和写入分别发布全局限额，并对记录和条目查询发布基于分数的限额。
- 复杂过滤和排序可能提高查询分数；原始请求并发并非唯一的负载变量。
- 根据端点不同，分页可能基于偏移量或基于游标。
- 仅在存在明确的新鲜度与失效策略时才缓存对象和属性发现结果。
审批边界
未经责任人批准，不得为了延迟而牺牲正确性、可审计性或数据新鲜度。也不得仅因为公布的全局上限更高就提高并发。
输出
返回基线指标、分段瓶颈证据、所选假设与变更、正确性检查、可比较的变更后指标，以及明确的回滚决策。
错误处理
- 没有代表性基线：先埋点并等待可用证据。
- 查询量低却出现 429：检查基于分数的复杂度以及共享工作区流量。
- 优化改变了结果：回滚并优先恢复正确性。
- 缓存返回过期模式：使其失效并收紧新鲜度策略。
示例
输入：symptom=query queue age；endpoint=record query；window=representative peak
预期交付：bottleneck=filter-score；change=simplified-query；correctness=pass；p95=improved
限制
不承诺统一的延迟目标；需以实测证据为前提。关于价格、平台支持范围等具体信息暂未提供。