两天时间搓了一个1.0版本，遇到了一点瓶颈，复盘一下。

  • 为什么需要Trace Infra？给谁用？
    不同agent平台采集的trace格式不同，我们想要比较不同平台之间的harness，学习更高效的策略。我们也将这些记录转换为统一对象，并提供检索、窗口、关系、统计和证据回读。
    **直接使用者是分析 Agent、评测链路和工程师；最终受益者是模型、Agent 与产品研发团队。**CLI是平台的核心接口，Skill是agent做好分析的最重要的工具。
  • Trace Infra的接口是做到越细越好，让agent自己组合查询，还是根据需求设计接口？
    由需求驱动，抽象成可组合的通用操作。参考开源平台，取长补短。
  • 在做Trace Infra的过程中，哪些事是重要的？哪些事不是Infra考虑的？
    事实可信、取数稳定、任务状态可观察。针对高频关键词/任务做优化，增强agent调用trace infra相关的能力，如skill,cli。
    不负责评测效果，评测Skill能力。
  • 什么样的showcase能体现infra的功能？
    从多个来源导入一批 Trace，让 Agent 找出重复出现的失败模式，并把每个结论链接回具体证据：
    1. 用户用自然语言要求导入；Agent 发现格式、调用 Adapter，网页展示阶段进度。
    2. Agent 先发现实际工具、Skill 和状态字段，再按条件圈定分析范围。
    3. 找到可疑 Span，一次取前后窗口和相关消息；只读取必要证据。
    4. 跨 Trace 汇总共性，输出问题、受影响 Trace ID、证据及不确定项。
    5. 新增数据后复跑：测试已经写好的adapter是否会被agent自己检索到，旧分析引用保持可追溯，新查询看到新数据。
    showcase必须同时展示正确率、证据引用有效率、API 请求数、读取字节/Token、耗时和失败恢复，最好能和同类开源平台做对比。
    同时我们可以将这个过程记录trace，用我们自己的skill去分析trace，迭代我们的skill和cli，观察各个指标是否会提升。
  • 我做的Trace Infra相比公开的项目，有什么优势？还有哪些缺陷？
    由于没有做对应的实验，我们不能宣称有任何优势。
    当前高频子串冷搜索仍约 2.3～2.5 秒（2000+ trace,3w+关键词命中）
    Adapter 曾通过结构校验却丢失语义。
    我们的服务器缓存相关设计不够先进，只有初步的设计。
  • 如何给Trace Infra写测试？
    这部分需要规范化。