我已经收集到了关于 Scritty 的足够信息。现在我将为您撰写一篇面向创业者的、有深度的中文产品分析报告。
Scritty 产品深度分析报告：AI Agent 时代的”上下文基础设施”
执行摘要
Scritty 是一款定位独特的本地优先（local-first）、Agent 无关（agent-agnostic）的终端模拟器兼记忆底座。它精准切入了一个被大多数 AI 编程工具忽视的痛点：当 Claude Code、GitHub Copilot CLI、Codex CLI、Antigravity、Aider、Ollama 等多个 AI CLI Agent 并行使用时，它们的对话上下文彼此隔离、互不相通，开发者被迫不断”重新解释决策、重复自己、丢失工作”。
Scritty 通过在所有 CLI Agent 必须经过的”终端”这一 OS 级边界上自动捕获、标记、索引所有交互，构建出一个统一的、可搜索的本地记忆语料库，并通过 Model Context Protocol（MCP）协议将这份记忆反哺给 Agent 本身。它不是又一个 AI Agent，也不是又一款 IDE 插件，而是 AI Agent 时代稀缺的**“上下文基础设施”**层。
一、产品定位：填补”AI 上下文碎片化”的真空
1.1 行业背景
2024—2026 年，AI 编程 Agent 呈爆炸式增长。开发者的工作流已从”单一 Copilot 补全”演变为多 Agent 协同：
- 周一：用 Claude Code 重构鉴权中间件
- 周二：用 Codex 写测试
- 周三：用 Copilot CLI 搭 API 路由脚手架
- 周四：用 Antigravity 调研 OAuth2 PKCE
- 周五：在飞机上用本地 Ollama 收尾
核心痛点：每个 Agent 都运行在各自的”记忆孤岛”中——Claude 的对话存在 Anthropic 平台，Codex 的日志格式不同，Copilot 的历史更不可见。决策无法延续，代码上下文无法跨 Agent 共享，团队知识无法沉淀。
1.2 Scritty 的解决方案
Scritty 选择了一个反直觉但极具战略价值的位置——终端（PTY）层。它不与任何 Agent 厂商合作，不写插件，不做 SDK 包装，而是直接在所有 CLI Agent 必须穿越的 OS 边界上做”无感捕获”。这意味着：
| 维度 | 传统方案 | Scritty |
|---|---|---|
| 集成方式 | 需要 Agent 厂商开放 API/插件 | 零集成，进程级自动识别 |
| 数据归属 | 存于各厂商云端 | 本地存储，用户完全掌控 |
| 跨 Agent | 不支持 | 统一语料库，一次检索全部命中 |
| Agent 反向利用记忆 | 需要各自集成 | 通过 MCP 协议，任意 Agent 都能调用 |
这是一个**“基础设施”型产品**的典型打法——不站队任何 Agent，而是成为所有 Agent 都必须经过的管道。
二、核心功能深度拆解
2.1 Agent 无关的进程级捕获
Scritty 不做”prompt 嗅探”（prompt sniffing），而是通过读取运行中的进程来识别当前终端里跑的是 Claude、Codex 还是 Copilot。这种”基于过程而非内容”的识别方式，避免了被厂商 UI 变化反复打破的脆弱性。
对创业者的启示：这是典型的”在不可控的上游、在不可变的事实层做价值捕获”的策略。终端是 OS 给的稳定接口，绕开了 Agent 厂商的护城河战。
2.2 混合检索：双 ONNX 嵌入 + 关键词 + RRF
Scritty 内置两套本地 ONNX 嵌入模型——一套针对代码优化，一套针对自然语言优化，与 BM25 关键词搜索通过 Reciprocal Rank Fusion 融合。这种”代码/文档双轨”的检索设计，反映了对开发者真实工作流的深刻理解：开发者既要搜”上次 OAuth 决策的逻辑”，也要搜”那个报错信息”。
对创业者的启示：在 RAG 横行的当下，多数产品堆叠单一 embedding 即可。Scritty 选择”双模型 + 离线”是为了严格保障本地优先承诺——数据不出本机，同时不牺牲检索质量。
2.3 可插拔向量后端
默认内置嵌入式引擎，但通过统一 trait 抽象，支持 Qdrant、pgvector、Chroma、Weaviate。这种设计显著降低了”从个人到企业”的扩展摩擦。
对创业者的启示：早期产品坚持”开箱即用”（embedded），规模化后开放”企业可选件”（pgvector/Qdrant），是典型的PLG → Enterprise 路径设计。
2.4 统一规则注入（prompt.toml + 厂商规则文件合并）
Scritty 在消息出站前会自动组装：用户的 standing instructions + 强制约束 + 当前目标 + 厂商自身的 rule file（如 .claude/CLAUDE.md）。换言之，写一次规则，所有 Agent 都遵守。
对创业者的启示：这是”AI 治理”的前瞻性布局。当 Agent 数量增加，“规则一致性”将成为团队生产力的瓶颈。 Scritty 把这件事做成了基础设施。
2.5 多端同步：Desktop + Browser PWA + Mobile QR 配对
终端内嵌 token-secured Web 服务器，支持 PWA 跨端实时同步，且TLS 默认开启，跨 LAN 需显式 opt-in。这意味着你可以在手机上”扫一眼” Claude 跑长任务的实时输出。
对创业者的启示：在 Remote Work、AI Agent 长任务（数小时甚至数天）越来越多的背景下，**“随时随地监管 AI 进程”**将变成强需求。
2.6 团队控制平面
支持多租户隔离、SSO/SAML、审计日志、跨成员联邦搜索（区分私有会话与团队会话）。这让它从”个人工具”无缝过渡到”组织工具”。
三、商业模式分析
3.1 定价模型
| 套餐 | 价格 | 关键参数 |
|---|---|---|
| Personal Pilot | 免费 14 天 | 试用 |
| Personal | $19.99/月 | 10,000 exchange-pairs/月，超出 $5/10k |
| Pro | 未公开 | 25,000 exchange-pairs 或 35 天，3+ 席位 |
| Enterprise | 议价 | 自托管、完整数据主权 |
计费单位：“exchange-pairs”（一次用户输入 + 一次 AI 回复 = 1 对，不重复计费）。官方给出参考：单名深度用户约 4,800 对/月，10 人团队约 60k–100k 对/月。
3.2 商业模式的精明之处
- 按用量而非按席位计费——明确表态”永远不按席位收费”，这是对 SaaS 行业惯例的反叛。它降低了团队规模扩张的边际成本，鼓励全员采用。
- 数据归属即产品——“数据在你机器上”既是技术架构，也是定价哲学。这意味着退出成本高、迁移成本更高。
- Pilot → Paid 的漏斗——14 天免费试用 Personal，转化漏斗设计清晰。
- 没有永久免费层——商业意图明确，避免被”free rider”拖垮。
对创业者的启示：Scritty 的定价是其**“本地基础设施”定位的延伸**——如果数据在用户本地，那么云端订阅费的合理性必须建立在”团队协同 + 联邦搜索 + 审计合规”等网络效应型价值上，而非存储成本。
四、竞品格局与差异化
4.1 直接竞品
| 竞品 | 定位 | Scritty 优势 |
|---|---|---|
| Warp | AI 增强型终端 | Warp 只捕获自家 Agent，Scritty 捕获所有 CLI Agent |
| Cursor / Continue | IDE 内 AI | 索引代码而非对话，绑定 IDE |
| mem0 / Zep | Agent 记忆库 | 要求你自己构建 Agent，Scritty 是即用型 |
| 厂商原生日志 | 各家封闭日志 | 不可跨厂商检索 |
4.2 间接竞品
- tmux + 自建脚本：极客方案，但缺乏 MCP 暴露和统一检索
- Obsidian / Logseq：个人笔记工具，定位不同
- Linear / Notion AI：项目管理工具，与”代码上下文”不重合
4.3 Scritty 的护城河
- 位置独特：终端层是”所有 CLI Agent 的必经之路”，先发者一旦占据，迁移成本极高
- 数据沉淀效应：用得越久，记忆语料库越有价值——典型的数据网络效应
- MCP 协议兼容性：踩在 Anthropic 主导的 MCP 标准上，未来 Agent 互联互通是大趋势
- 本地优先的安全叙事：在数据合规日益严格的当下，“数据不出本机” 是强有力的销售说辞
五、风险与挑战
5.1 来自 Agent 厂商的封堵风险
最大的不确定性是：当 Scritty 变得”过于有用”时，Anthropic、OpenAI 等厂商是否会在自己的 CLI 工具中封堵类似捕获？如果某天 Claude Code 增加”反终端嗅探”机制，Scritty 的核心价值会被削弱。
应对逻辑：Scritty 押注的是”终端作为 OS 通用接口”的稳定性。即便厂商封堵，“Agent 必须读出写入字符”这一物理事实仍然成立。Scritty 的应对空间还包括：与厂商达成”中立基础设施”合作（类似 1Password 与各浏览器的合作模式）。
5.2 GUI Agent 的崛起冲击
当 AI Agent 从 CLI 形态向 GUI 形态（如 Computer Use、IDE 内 Agent）迁移时，“终端”作为统一边界的价值会被稀释。Scritty 需要及时扩展到 GUI Agent 捕获，否则会面临”基础设施空心化”。
5.3 商业模式的天花板
按 exchange-pairs 计费的天花板是单个开发者的 AI 使用量上限。当单 Agent 能处理的任务越来越复杂，每对”交换”的业务价值会上升，但单价未必上涨。
5.4 开源与闭源的平衡
Scritty 选择闭源 + 商业授权，这在开发者工具中是把双刃剑。优点是变现清晰；缺点是失去社区贡献的杠杆。竞争对手若以开源形态入场（如 LibreChat、Open WebUI 的做法），将形成压力。
5.5 早期阶段的市场教育成本
GitHub 上仅 1 star、7 commits（截至搜索时），说明产品仍处于极早期。“教育开发者为什么需要 AI 上下文基础设施”将是一笔巨大的 CAC 支出。
六、对创业者的启示
6.1 产品策略层面
- “基础设施”型创业是一条好路，但极难——你必须找到”所有玩家都必须经过的物理/逻辑层”，并且这层不能被任何上游轻易替换。Scritty 找到了终端。
- 反 SaaS 叙事是差异化的金矿——“数据在你机器上”在云原生时代是反直觉的强主张。
- MCP 是 2025—2026 年必须押注的标准——任何与 AI Agent 协同的工具，都应考虑 MCP 兼容。
6.2 商业模式层面
- 不要按席位计费，要按价值计费——Scritty 的”按 exchange-pairs 计费”是按价值流计费的典范。
- “Pilot → Paid” 漏斗必须简单——14 天免费，转化路径不能超过两步。
- 可插拔架构是 PLG → Enterprise 的桥梁——让小客户能”零成本启动”，让大客户能”无缝扩展”。
6.3 技术决策层面
- 在”不变的事实层”做价值捕获——进程级识别优于内容嗅探，OS 边界优于应用边界。
- 离线优先的检索能力，是”本地优先”承诺的技术底线——如果检索需要联网，“数据在你机器上”就是空话。
- 双模嵌入（代码 + 文本）是垂直深度——单一模型是通用妥协，双模型是专业承诺。
6.4 风险规避层面
- 永远准备 Plan B——当上游封堵时怎么办？ 提前建立”中立基础设施”的合规与法务叙事。
- 从 CLI 起步，但规划 GUI 扩展路径——Agent 形态演进的速度超出多数人预期。
- 闭源必须配以”无锁定”承诺——明确数据导出格式，避免被指控”厂商锁定”。
七、结论
Scritty 是一款**“在正确的时间、正确的位置、做正确的事”的产品。在 AI Agent 工具链日趋碎片化的今天，它扮演的不是”又一款 AI 工具”，而是”AI 工具之间的粘合剂”**——一种稀缺的、底层的基础设施型产品。
对创业者而言，Scritty 的案例提供了三个最值得学习的范式：
- 不要站队，做”必经之路”——选择所有玩家都依赖的中立层，规避生态战
- 用技术架构兑现商业承诺——“数据在你机器上”既是定位，也是定价依据
- 早期即设计”按用量计费 + 可插拔扩展”——为 PLG 到 Enterprise 的跨越预留空间
如果 Scritty 能在未来 18 个月内成功跨越”被厂商封堵""GUI Agent 崛起”两道关卡，它有机会成为 AI 编程时代的 Git for Context——一个开发者再也离不开的上下文版本控制层。
对于关注 AI 基础设施赛道的创业者，Scritty 值得长期跟踪：它不仅是一个产品，更是一个”AI 时代基础设施长什么样”的早期样本。
报告基于 scritty.dev 官网与 GitHub 公开信息整理，数据截至搜索时点。