核心用法
Outlit 定位为客户智能（Customer Intelligence）基础设施，通过 MCP/Pi 工具或 outlit CLI 为 AI 代理提供结构化的客户上下文能力。其核心工作流包括：
1. 多源数据聚合：自动同步产品活动、邮件、通话、日历、支持工单、CRM 商机、计费记录等，构建统一的客户上下文图谱（Customer Context Graph）。
2. 分层查询接口：
3. 主动通知：outlit_send_notification 支持向 Slack 等渠道推送基于分析结果的告警或洞察（需用户显式触发）。
- 高层语义查询：
outlit_search_customer_context用于主题性/模糊问题；outlit_list_facts浏览结构化智能（如 CHURN_RISK、EXPANSION、SENTIMENT 等）。 - 精确溯源：
outlit_get_source/outlit_list_sources获取原始邮件、通话记录、工单等证据。 - 时序分析：
outlit_get_timeline按时间轴呈现客户事件序列。 - 自定义分析：通过
outlit_schema+outlit_query执行只读 SQL（基于 ClickHouse），支持聚合、队列、时间序列检查。
显著优点
- 证据优先设计：强制区分证据（evidence）与解释（interpretation），要求引用来源类型（customer record、timeline event、source record 等），显著提升 AI 输出的可审计性。
- 多接口适配：原生支持 MCP（远程 OAuth）、Pi 工具包、CLI，覆盖从编码代理到对话式 AI 的多种场景。
- 结构化事实层：预定义事实类型（factTypes）将非结构化对话转化为可查询、可过滤的结构化智能（如识别出 EXPANSION 意向或 CHURN_RISK）。
- 安全约束内建：
- SQL 层强制只读、强制 LIMIT、强制时间过滤；
- 敏感操作（如
integrations remove）需二次确认； - MCP 远程连接使用 OAuth，禁止硬编码 API key 到共享配置。
潜在缺点与局限性
- 数据新鲜度依赖：客户智能质量完全取决于集成同步状态，若数据源未连接或同步延迟，可能产生“静默账户”误判。
- SQL 能力边界：虽支持 ClickHouse，但仅暴露
activity、customers、users、revenue等公共视图，复杂后端表不可见，深度自定义分析受限。 - 通知通道有限：当前主要支持 Slack，其他企业通讯工具（如 Teams、钉钉、飞书）需通过自定义 webhook 或尚未明确支持。
- 学习曲线：事实（Facts）与来源（Sources）与搜索（Search）的三层抽象需要用户理解何时选用哪一层，否则易误用（如用 SQL 做本应通过语义搜索解决的问题）。
适合人群
- 客户成功（CS）与销售人员：需快速掌握账户健康度、识别流失风险与扩展机会。
- Revenue Operations（RevOps）：需跨系统（CRM、计费、产品数据）进行统一分析与报表。
- AI 工程师与 Agent 开发者：需为客户代理提供可信、可溯源的数据基础设施，避免幻觉。
- 数据分析师：需在不直接访问数据仓库的情况下，对客户行为进行临时 SQL 探查。
常规风险
- 数据隐私与合规：聚合邮件、通话、日历等敏感通信数据，需确保符合 GDPR、SOC 2 等合规要求，且工作区级别的访问控制必须严格配置。
- 过度依赖结构化事实：预定义 factTypes 可能遗漏业务特定信号，且 anomaly-detector 类事实（如 CORE_ACTION_DECAY）被设计为内部使用，误用可能导致错误决策。
- 误报与静默风险：若集成断开或 API key 权限不足，系统可能返回空结果，需养成先检查
outlit integrations status的习惯，避免“无数据”被误读为“无活动”。 - 通知滥用：虽工具支持主动通知，但文档明确禁止“默认通知”，需防止代理自动化导致信息过载或敏感信息泄露到公共频道。