运行与观测
分析
基于同一份遥测数据的两个视图：/analytics 上的工作区级成本分析，以及按运行维度的集群可观测性——它会逐节点回放一次集群执行。
成本分析
分析页开头是四个数字——本月累计消费、总令牌数、平均延迟、活跃智能体数——之后是：
- 支出趋势 ——所选时间窗内每日消费的走势图。出现尖峰值得当天就去查；通常是某一次实验、某一个循环，或某一份过大的上下文。
- 按提供商统计成本 ——钱花在了哪里：ZenStudio AI、OpenAI、Anthropic，以及你接入的各家自带密钥提供商。
- 按智能体统计成本 ——意外几乎总出在这张图里：往往是某一个智能体用了某一个贵模型，把总量拉走了大半。
这些是估算值，而且可能偏低
成本是按每次调用、依据令牌数和该模型的存档单价算出来的——不是从提供商账单反向读取的，所以它与一份自带取整、折扣和起步价的账单不会完全对得上。用这些图去找那个贵的智能体；用账单去核定金额。
更尖锐的一点：价目表不认识的模型会被记为 零，而零一旦画进图里就与「便宜」无从区分。这类调用在追踪上会标记为
更尖锐的一点：价目表不认识的模型会被记为 零，而零一旦画进图里就与「便宜」无从区分。这类调用在追踪上会标记为
pricing_missing ；而令牌数是估算而非提供商上报的调用，会标记为 tokens_estimated ——于是看起来偏低的合计可以去核实，而不是靠猜。参见 成本是怎么算出来的.集群可观测性
集群运行有自己的深度检查视图，位置在 分析中心 → 集群追踪。打开一次运行会看到三个页签：
- 画布
- 运行当时那一版的集群图，于是你能看清实际执行的是什么形状——包括那些你后来又改过的集群的历史运行。
- 时间线
- 逐节点的执行顺序，附每一步的类型与模型。点击某一步会展开它的明细：输入、输出、思考过程和工具调用。
- 数据流
- 每一条跨越连线的消息——由哪个节点产出、被哪个节点消费。上下文窗口的问题就是在这里显形的：你能确切看到交给每个节点的文本有多少。
真正有回报的做法是：每次跑出值得一看的集群运行之后，打开它的时间线，找出最慢的一步和最贵的一步。这两个节点几乎总是下一个值得优化的对象——换更便宜的模型、把提示词收紧，或者改成并行分支。
审计时间线
时间线在读取时合并了 三个 来源，这也是为什么某个动作会出现在这里、却在任何单张表里都找不到对应记录：
| 数据源 | 贡献内容 |
|---|---|
audit_events | 用户与管理员的活动——登录、发布、授权、删除、智能体对话 |
execution_traces | 模型调用，呈现为 model.call 动作 |
swarm_runs | 集群执行，呈现为 swarm.run |
非管理员只能看到自己的记录——这个范围限定是由行级安全策略完成的，不是靠查询语句——而超级管理员能看到整个工作区。
保留期
| 设置项 | 默认值 | 取值范围 | 说明 |
|---|---|---|---|
audit_retention_days | 365 | 1 – 365 | 审计事件在被定时清理之前保留多久。 |
trace_retention_days | 0（永久保留） | 0 – 3650 | 零表示完全不清理追踪。请慎重设置——追踪里可能存有提示词正文。 |
AUDIT_ARCHIVE_ON_PURGE | off | 环境变量 | 清理时归档事件，而不是直接丢弃。 |
追踪默认永久保留
trace_retention_days 出厂值是 0，意味着什么都不会被清理。再叠加 PERSIST_PROMPT_BODIES，就可能意味着完整的提示词与响应无限累积——而在繁忙的实例上， execution_traces 和 swarm_runs 是你所有表里增长最快的。请在此设一个窗口： 管理 → IAM → 设置 → 追踪保留期。清理任务一直都在定时维护轮次里跑；只要那个字段还是零，它就无事可做。另见 预算与成本.导出
审计日志导出为 NDJSON——每行一个 JSON 对象——无需转换即可流入大多数日志管道，文件很大时也仍然可读。