要把 Presence 试点从“小范围跑得还行”推到更大范围，先别急着看效果指标，先确认后台能不能回答一个问题：出问题时，能不能查到是谁、通过哪条指令、让 Agent 调用了什么、最后执行成什么样。建议的做法是把管理后台里能看、能导的记录类型逐项列出来，再挑一条真实任务从发起人追到执行结果，凡是接不上的位置都记成缺口。缺口只影响复盘细节的，可以考虑带着扩量；缺口导致查不到发起人的，通常先补齐再决定扩量。

判断 Presence 试点能否扩量，标准不是效果，而是可追溯：后台能列出记录类型、字段与保留时长，一条真实任务能从发起人一路追到执行结果，四段对得上。四段中任一段缺失即记为缺口；缺口落在责任归属上先补，落在复盘细节上可以扩量后补，但要有明确记录。保留时长建议覆盖整个试点周期再加一次复盘窗口，短于这个窗口的记录，在事后复盘里基本等于不存在。

在后台把能看、能导的记录类型列全

这一步只做一件事：确认可追溯的范围。建议按“登录与权限、Agent 会话、模型请求、工具调用、数据与文件、导出与分享、错误与告警”几类，在后台逐个页面点开看，能看到什么就写什么，看不到的直接写“未见”，不要假设它存在，也不要凭产品宣传页推断字段。同时确认三件事：页面上的时间戳用哪个时区、导出功能是否有条数或时间窗限制、记录是否会被自动清理以及清理策略写在哪里。

字段清单里建议特别留意四项：操作者是人员账号还是服务账号、有没有贯穿全链路的请求 ID 或 trace ID、指令内容存的是原文还是摘要、调用对象用的是内部别名还是可解析的真实标识。这四项决定了后面三步能不能做下去。

用一个真实任务走一遍全链路

不要用测试用例验证可追溯性，挑一条试点期间真实发生过、且至少调用了一次外部工具的任务。拿到它的请求 ID（或会话 ID）后，按发起人、指令内容、调用对象、执行结果四段逐段去后台找对应记录，四段能一一对上才算通过。断点通常出现在这几处：定时任务或服务账号代操作时发起人被记成系统；指令只在客户端留存、平台侧只有摘要；工具调用日志落在应用自己这边而没有回流到平台；异步任务缺少父请求 ID，子调用找不到归属。

查的时候可以先用一个请求 ID 把各段日志串起来，字段名按自己环境的实际命名替换，这段骨架只是说明检索思路，不依赖任何特定接口：

# 以单个请求 ID 串起四段记录，路径与字段名按实际环境替换
REQ=req_example_0001
for src in gateway agent tool audit; do
  echo "== $src =="
  grep -F "$REQ" /var/log/presence/$src/*.log \
    | head -n 50
done

跑完这一遍，把每一段“有记录 / 记录不完整 / 无记录”写清楚，并把断点位置标到具体字段上，不要只写“查不到”。断点定位到字段，后面的补法才有方向。

把记录缺口分成必须补与可以忍

分级标准建议只看影响面：这个缺口会让责任归属说不清、让复盘无法还原过程、还是只在合规自查时被问到。前两类通常先补，第三类可以排期。另有两条门槛线值得提前定下来：记录保留时长要覆盖试点周期加一次复盘窗口；关键字段（发起人、请求 ID）缺失时，扩量本身会让问题规模变大，补起来的成本也更高。

补法优先考虑在应用侧做，不必等平台侧加字段；但应用侧补记录时要同步确认保留时长和访问权限，否则补出来的记录同样用不上。

写成扩量前的检查清单并留确认位

把前面三步的结论落成一张表，每条都要有确认人和未通过时的处理办法，避免“发现了但没人管”。建议在扩量评审前发出，确认人逐项签字或留评论，未通过项先按替代方案执行，不默认放行。

这张表的价值不在于列全，而在于每一项都有明确的人承接。能追溯，才谈得上扩量；查不清楚的操作记录，规模越大越难补。