日志记录的目的
作为模型接入产品，35m.ai 需要通过适度的日志与运行信息回答三类问题：请求发到了哪、花了多少、为什么成功或失败。
- 用于调试请求链路、错误恢复与基本运维排障
- 用于解释价格、成功率、耗时和供应商执行结果
- 用于比较不同供应商、入口与部署方式的运行表现
Data & Logging
数据与日志说明
35m.ai 强调价格、成功率和耗时的可见性，但“可见”并不等同于“无限记录”或“无限保留”。本页说明日志的用途、默认边界以及托管与自托管环境中的差异。
默认记录边界
日志能力应服务于产品可用性、成本透明和支持排障，而不是无限制保留用户内容。公开站点与 API 请求链路也应分开理解。
- 可能记录请求时间、请求路径、调用入口、供应商路由、基础错误信息与聚合指标
- 公开页面不应泄露请求级敏感信息、供应商密钥或用户私有业务内容
- 提示词、输出内容、保留时长和可访问范围应按产品层策略或部署约定单独判断
托管与自托管差异
托管、自托管和代理部署的日志边界并不完全相同，实际控制权也有所区别。
- 在托管模式下，平台侧可能保留必要的运行与支持日志以保障服务可用性
- 在自托管模式下，日志保留、访问控制和导出策略通常由部署方自行决定
- 代理部署的日志边界还会受到网络架构、出口节点和外部网关策略影响
可见性与保留原则
公开强调可见性，并不意味着默认保留所有原始数据。更合理的原则是最小必要、按用途区分和按权限访问。
- 价格、成功率和耗时的可见性，应优先通过聚合指标和运行结果实现
- 日志保留应遵循最小必要原则，并结合支持、计费、审计或部署需求设定边界
- 如需更细的日志、审计或保留要求，应通过部署方案或商务流程单独确认