AI 编程助手场景
场景描述
AI 编程助手（如 Claude Code、Qoder、Codex）每次打开新会话时，Agent 对开发者的技术偏好、项目架构和历史决策一无所知，导致反复追问"用什么框架？什么 ORM？"。Context0 为编程 Agent 提供跨会话的经验沉淀能力——开发者的对话自动蒸馏为技术画像，新会话启动时秒级恢复上下文。
交互流程
核心链路：
开发者与 Agent 对话，Agent 将消息 ingest 写入 Context0。
后台异步完成 L1 原子事实提取 + L0 用户画像蒸馏（技术栈、偏好、项目决策）。
新会话启动前，Agent 调用 assemble 拉取上下文。
Context0 返回 prompt_blocks（用户画像、活跃决策、相关记忆），Agent 注入 System Prompt。
完整 API 示例
本场景示例中 user_id="alice" 假设使用的 USER Key 已绑定开发者 alice。请求user_id需与该USER Key绑定的终端用户一致。跨用户场景请使用Owner Key。
写入对话（ingest）
代码块
Bash
curl -X POST http://
-H "X-API-Key: ******" -H "Content-Type: application/json" \
-d '{
"session_id": "session-mon-alice",
"user_id": "alice",
"agent_id": "coding-agent",
"messages": [
{"role": "user", "content": "这项目用 TypeScript + Prisma，鉴权用 NextAuth，记一下"},
{"role": "assistant", "content": "已记录：项目技术栈 TypeScript + Prisma + NextAuth"}
]
}'
响应示例：
代码块
JSON
{"code": 0,"data": {"session_id": "session-mon-alice","session_internal_id": 1,"message_ids": [{"id": 1, "seq": 1}, {"id": 2, "seq": 2}],"event_id": 7}}
三天后新会话装配（assemble）
代码块
Bash
curl -X POST http://
-H "X-API-Key: ******" -H "Content-Type: application/json" \
-d '{
"session_id": "session-wed-alice",
"user_id": "alice",
"query": "add user login endpoint",
"token_budget": 6000,
"recall": {"top_k": 8}
}'
响应示例：
代码块
JSON
{"code": 0,"data": {"prompt_blocks": [{"role": "system", "tag": "user_profile", "content": "Alice：TypeScript, Prisma, 简洁代码风格，偏好函数式写法", "tokens": 35, "sources": []},{"role": "system", "tag": "memory_recall", "content": "ORM=Prisma, 鉴权=NextAuth, 测试=Vitest", "tokens": 25, "sources": ["mem_101"]},{"role": "system", "tag": "memory_recall", "content": "Alice 在 session-mon 中确认：路由使用 App Router，API routes 放 /app/api/ 下", "tokens": 40, "sources": ["mem_102"]}],"token_used": 1850,"token_budget": 6000,"trace_id": "a1b2c3d4-..."}}
推荐配置
#LXivOXwphlBH text { white-space: pre; }#LXivOXwphlBH .fb0 { stroke: var(--N900-FG, 0.15); }#LXivOXwphlBH .fb0 {stroke: rgba(31,35,41, 0.15)}#LXivOXwphlBH .fx0 { stroke-miterlimit: 10; }#LXivOXwphlBH .fx0 {stroke-miterlimit: 10}#LXivOXwphlBH .fa1 { fill: rgb(187, 191, 196); }#LXivOXwphlBH .fa1 {fill: rgb(187, 191, 196)}#LXivOXwphlBH .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#LXivOXwphlBH .fx1 {font-style: normal}#LXivOXwphlBH .fx2 { text-anchor: middle; }#LXivOXwphlBH .fx2 {text-anchor: middle}#LXivOXwphlBH .fx3 { dominant-baseline: central; }#LXivOXwphlBH .fx3 {dominant-baseline: central}#LXivOXwphlBH .fx4 { stroke: none; }#LXivOXwphlBH .fx4 {stroke: none}#LXivOXwphlBH .fc0 { fill: var(--text-caption); }#LXivOXwphlBH .fc0 {fill: #646a73}#LXivOXwphlBH .fa2 { fill: var(--text-link-disabled); }#LXivOXwphlBH .fa2 {fill: rgb(187, 191, 196)}#LXivOXwphlBH .fa3 { fill: rgb(229, 229, 229); }#LXivOXwphlBH .fa3 {fill: rgb(229, 229, 229)}#LXivOXwphlBH .fx5 { font: 700 14px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#LXivOXwphlBH .fx5 {font-style: normal}#LXivOXwphlBH .fx6 { text-anchor: start; }#LXivOXwphlBH .fx6 {text-anchor: start}#LXivOXwphlBH .fx7 { dominant-baseline: alphabetic; }#LXivOXwphlBH .fx7 {dominant-baseline: alphabetic}#LXivOXwphlBH .fc1 { fill: rgb(0, 0, 0); }#LXivOXwphlBH .fc1 {fill: rgb(0, 0, 0)}#LXivOXwphlBH .fx8 { font: 400 14px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#LXivOXwphlBH .fx8 {font-style: normal}#LXivOXwphlBH .fx9 { font: 400 14px LarkHackSafariFont, LarkEmojiFont, Menlo, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Helvetica, "Noto Sans", Tahoma, "Nimbus Sans L", Arial, "Liberation Sans", "PingFang SC", "Hiragino Sans GB", "Noto Sans CJK SC", "Source Han Sans SC", "Source Han Sans CN", "Microsoft YaHei", "Wenquanyi Micro Hei", "WenQuanYi Zen Hei", STHeiti, SimHei, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji", system-ui; }#LXivOXwphlBH .fx9 {font-style: normal}#LXivOXwphlBH .fb1 { fill: var(--N900-FG, 0.15); }#LXivOXwphlBH .fb1 {fill: rgba(31,35,41, 0.15)}#LXivOXwphlBH .fb2 { fill: rgb(216, 216, 216); }#LXivOXwphlBH .fb2 {fill: rgb(216, 216, 216)}#LXivOXwphlBH .fa4 { fill: var(--bg-body); }#LXivOXwphlBH .fa4 {fill: #fff}ABC12345项推荐值说明策略预设代码索引Dream 演化6000~8000项目文档 / 架构说明入知识库标准深度召回，技术决策永久保留，偏好类记忆不会被过期清理。编程场景上下文较重，预算可适当放宽。代码本身留在 Git，只把语义索引写入 Knowledge。夜间归纳近期决策变更，合并重复偏好。token_budgetcoding
效果展示
代码块
Plain Text
── 接入前 ──
周三（新会话）
CLI 快捷接入
如果您用 Claude Code / Qoder / Codex 等支持 MCP / 插件的工具，推荐用 CLI 一键接入，无需手写 HTTP 调用：
代码块
Bash
# 安装 CLI（要求 Node.js ≥ 22）
npm install -g @polardbx/ctxdb0
# 绑定编程 Agent（--agent 支持：claude | qoder | codex）
setup 会自动配置 MCP Server，之后正常编程即可—写入/召回全部由 CLI 后台自动完成。
智能客服 / 导购场景
场景描述
客服/导购场景中，用户每次进线都要重新描述问题背景和历史偏好，Agent 缺少跨会话记忆导致上下文丢失。多 Agent 转接时用户同样需要重复说明背景。Context0 为每个用户沉淀持久画像—偏好、情绪标签、历史交互摘要——Agent 接手即知全貌。
交互流程
核心链路：
用户发消息给 Agent。
合并上下文后送 LLM 生成回复。
Agent 并行调用 Context0 assemble 拉取用户画像 + 业务库查订单/商品。
将本轮对话 ingest 回 Context0，异步蒸馏更新 L0 画像（偏好、情绪、消费倾向）。
完整 API 示例
本场景示例中 user_id="cust_001" 假设使用的 USER Key 已绑定到该终端客户。请求user_id需与该USER Key绑定的终端客户一致。若一个 Agent 服务多个客户，请在服务端使用Owner Key并显式传 user_id。
写入用户对话（ingest）
代码块
Bash
curl -X POST http://
-H "X-API-Key: ******" -H "Content-Type: application/json" \
-d '{
"session_id": "sess_789",
"user_id": "cust_001",
"agent_id": "shopping-agent",
"messages": [
{"role": "user", "content": "想送女朋友礼物，预算 500 以内，文艺手工风"},
响应示例：
代码块
JSON
{"code": 0,"data": {"session_id": "sess_789","session_internal_id": 2,"message_ids": [{"id": 3, "seq": 1}, {"id": 4, "seq": 2}],"event_id": 12}}
下次进线装配用户画像（assemble）
代码块
Bash
curl -X POST http://
响应示例：
代码块
JSON
{"code": 0,"data": {"prompt_blocks": [{"role": "system", "tag": "user_profile", "content": "cust_001：女性送礼场景，偏好文艺手工风，预算 500 以内，情绪积极", "tokens": 40, "sources": []},{"role": "system", "tag": "memory_recall", "content": "上次推荐了手工陶瓷杯和手织围巾，用户对陶瓷杯更感兴趣", "tokens": 30, "sources": ["mem_201"]},{"role": "system", "tag": "memory_recall", "content": "sess_789 摘要：礼物推荐-文艺手工风-预算500", "tokens": 25, "sources": ["mem_202"]}],"token_used": 980,"token_budget": 4000,"trace_id": "b2c3d4e5-..."}}
推荐配置
效果展示
代码块
Plain Text
── 接入后 ──
第 1 天（首次进线）
用户: "想送女朋友礼物，预算 500，文艺手工风"
企业知识库 RAG 场景
场景描述
企业的规章制度、技术文档、操作手册散落在飞书、Wiki、Confluence 等多处，员工跨平台检索效率低，且 HR/IT/行政面临大量重复答疑。Context0 知识库让文档"上传即问答"——自动解析、双层分块、语义索引，员工直接用自然语言提问即获答案。
交互流程
核心链路：
管理员上传文档（PDF/Word/Markdown 等）。
Context0 自动解析 → 双层分块（小块精准匹配 + 大块上下文） → Embedding → 索引。
用户提问时，通过 knowledge/search 或 assemble(include=knowledge) 检索。
返回最相关知识片段，拼入 Prompt 由 LLM 生成答案。
完整 API 示例
企业知识库场景中 user_id="employee_wang" 属于终端员工。请求user_id需与该USER Key绑定的终端员工一致。需要代多个员工发起检索的服务，请使用Owner Key。
创建知识库
代码块
Bash
curl -X POST http://
-H "X-API-Key: ******" -H "Content-Type: application/json" \
-d '{"name": "公司制度库", "graph_enabled": false}'
响应示例：
代码块
JSON
{"code": 0,"data": {"id": 1,"name": "公司制度库","graph_enabled": false,"document_count": 0,"created_at": "2024-12-01T10:00:00Z"}}
上传文档
代码块
Bash
curl -X POST "http://
-H "X-API-Key: ******" \
-F "file=@/path/to/差旅费报销制度.pdf" \
-F "title=差旅费报销制度 v3.2"
响应示例：
代码块
JSON
{"code": 0,"data": {"document_id": 42,"title": "差旅费报销制度 v3.2","ingest_status": "pending","file_size": 1048576}}
检索知识
代码块
Bash
curl -X POST http://
-H "X-API-Key: ******" -H "Content-Type: application/json" \
-d '{"query": "出差报销流程和标准", "kb_ids": [1], "top_k": 5}'
响应示例：
代码块
JSON
{"code": 0,"data": [{"chunk_id": "chunk_42","document_id": "42","title": "差旅费报销制度 v3.2","snippet": "国内出差报销标准：住宿费一线城市≤600元/晚，二线≤400元/晚；交通费凭票实报实销，500元以上需提前审批...","score": 0.92,"position": 1},{"chunk_id": "chunk_47","document_id": "42","title": "差旅费报销制度 v3.2","snippet": "报销流程：出差结束5个工作日内，登录OA系统→填写差旅报销单→上传票据扫描件→直属主管审批→财务复核...","score": 0.88,"position": 2}]}
通过 assemble 统一装配（推荐）
代码块
Bash
curl -X POST http://
-H "X-API-Key: ******" -H "Content-Type: application/json" \
-d '{
"session_id": "sess_kb_001",
"user_id": "employee_wang",
"query": "出差到上海住宿标准多少",
"token_budget": 4000,
"context_scope": "knowledge_only",
"recall": {"top_k": 5}
}'
响应示例：
代码块
JSON
{"code": 0,"data": {"prompt_blocks": [{"role": "system", "tag": "knowledge", "content": "国内出差住宿标准：上海属一线城市，住宿费上限600元/晚。超标需事前申请特批，附部门总监审批邮件。", "tokens": 50, "sources": ["runbook.pdf"]},{"role": "system", "tag": "knowledge", "content": "酒店预订须通过公司协议平台（差旅宝），自行预订的需提供平台无房证明方可报销。", "tokens": 45, "sources": ["runbook.pdf"]}],"token_used": 620,"token_budget": 4000,"trace_id": "c3d4e5f6-..."}}
推荐配置
效果展示
代码块
Plain Text
── 接入后 ──
员工: "出差到上海住宿标准多少？"
问答 Bot: "上海属一线城市，住宿费上限 600 元/晚。
质量保障机制
多 Agent 协作场景
场景描述
复杂业务中，多个专职 Agent 各管一段流程（接待、技术、账单、升级等），对用户呈现为一条连贯的服务线。但传统实现中，Agent 间转接时上下文无法传递，用户需要重复描述已提供的信息。Context0 通过同 Workspace 多 Member 架构，让多 Agent 共享同一份用户画像与交互事实。
交互流程
核心链路：
多个 Agent 注册为同一 Workspace 下的不同 Member（各持独立 API Key）。
用户与接待 Agent 对话：接待 Agent ingest 写入事实（含情绪标签）。
路由到技术 Agent：技术 Agent assemble 即获得接待记录 + 用户画像。
技术 Agent ingest 排查结论 → 路由到升级 Agent → 升级 Agent assemble 获得全链路上下文。
L0 用户卡自动 merge 所有 Agent 的发现，形成统一画像。
架构设计
代码块
Plain Text
关键判断：两个 Agent 是否需要看到对方记下的内容？
•
需要：同 Workspace 不同 Member。
•
不需要（独立产品，数据严格隔离）：分不同 Workspace。
完整 API 示例
多 Agent 协作场景中，各 Agent 使用自己的 USER Key（绑定到不同 member），但面向同一个终端客户 customer_zhang 提供服务。这里需要使用Owner Key（或不绑定到具体终端用户的 服务端 Key）才能在请求中显式传入 user_id="customer_zhang"；若误用已绑定到其他用户的 USER Key，服务端会返回 403。
接待 Agent 写入对话（ingest）
代码块
Bash
响应示例：
代码块
JSON
{"code": 0,"data": {"session_id": "sess_transfer_001","session_internal_id": 3,"message_ids": [{"id": 5, "seq": 1}, {"id": 6, "seq": 2}],"event_id": 31}}
技术 Agent 装配上下文（assemble）
代码块
Bash
curl -X POST http://
-H "X-API-Key: $SK_TECH" -H "Content-Type: application/json" \
-d '{
"session_id": "sess_transfer_002",
"user_id": "customer_zhang",
"query": "查询物流状态和延迟原因",
"token_budget": 4000,
"recall": {"top_k": 10}
响应示例：
代码块
JSON
{"code": 0,"data": {"prompt_blocks": [{"role": "system", "tag": "user_profile", "content": "customer_zhang：情绪焦虑，关注物流时效，VIP客户", "tokens": 30, "sources": []},{"role": "system", "tag": "memory_recall", "content": "接待 Agent 记录：客户反映订单 ORD-20241205 三天未发货，情绪急躁，需查物流状态", "tokens": 45, "sources": ["mem_301"]},{"role": "system", "tag": "memory_recall", "content": "订单 ORD-20241205：12月5日下单，状态=仓库拣货中，应发货日=12月6日（已超时2天）", "tokens": 40, "sources": ["mem_302"]}],"token_used": 1320,"token_budget": 4000,"trace_id": "d4e5f6a7-..."}}
技术 Agent 写入排查结论（ingest）
代码块
Bash
curl -X POST http://
-H "X-API-Key: $SK_TECH" -H "Content-Type: application/json" \
升级 Agent 获得全链路上下文（assemble）
升级 Agent 时，assemble 会返回接待记录 + 技术排查结论 + 用户画像的完整链路：
代码块
Bash
{
"code": 0,
推荐配置
效果展示
代码块
Plain Text
── 接入后 ──
客户只说了 3 轮话，被 3 个 Agent 处理过：
客户 → 接待 Agent: "订单三天没发货，很着急"
接待 Agent: 记录情绪+诉求 → 路由技术 Agent
客户 → 技术 Agent: "能帮我看看什么原因吗"
技术 Agent: 已获知接待记录+情绪标签 → 查到暴雪原因 → 路由升级 Agent
客户 → 升级 Agent: "能补偿吗"
常见问题
支持哪些平台？
•
AI 编程工具：Claude Code、Qoder、Codex 等支持 MCP / 插件的工具，可用 ctxdb0 CLI 一键接入。
•
自研 Agent / 后端服务：任何语言直接调用数据面 REST API（ingest / assemble / 记忆 / 知识）。
•
Mem0 生态：提供 /v1/memories、/v1/memories/search 等兼容端点，现有 Mem0 客户端可直接对接。
记忆有上限吗？
单条 ingest 每批最多 100 条消息。记忆总量本身没有硬上限—这正是三层记忆模型的价值：原始对话逐级蒸馏为 L1 事实和 L0 画像，Token 占用随时间稳定，不会因为记得越多就喂给 LLM 越多。真实使用中，一个用户用一年，召回给 LLM 的上下文量依然稳定可控。
不同 API Key 的记忆是否隔离？
隔离的核心锚点是 (workspace_id, member_id)，而非 API Key 本身：
•
跨 Workspace：索引层面物理隔离，完全查不到对方数据。
•
同 Workspace 不同 Member：记忆默认可见（这是多 Agent 协作的基础），可通过 recall.scope 控制召回范围。
•
同 Workspace 不同 user_id：recall.scope=user 时，不同终端用户的记忆互不可见。
需要严格隔离的独立产品，应分配到不同 Workspace。
文件格式和大小限制？
•
支持格式：PDF / Markdown / Word / Excel / PPT / RTF / EPUB / 图片 / 音频等。
•
单文件大小：默认上限 50 MB（可通过 MAX_FILE_SIZE 环境变量调整），请求整体上限为单文件上限 + 5 MB。
•
Markdown 内嵌图片可通过 images 字段一并上传，Vision 模型会自动为图片生成描述。
token_budget 设多少？
token_budget 范围 [1, 32000]，默认 32000，服务端保证永不超预算。经验值：
预算内如何分配可用 budget_allocator 微调（memory_ratio / knowledge_ratio / history_ratio / system_ratio），三维比例自动归一化。
如何删除所有记忆？
用 DELETE /v1/memories/clear，危险操作需显式加 confirm=true：
警告
query 和 body 中都必须携带 confirm=true 才会执行不可逆批量删除，任一缺少均返回 400。
代码块
Bash
# 清除某用户全部记忆
curl -X DELETE "http://
-H "X-API-Key: ******" -H "Content-Type: application/json" \
-d '{"scope": "all", "user_id": "user_001", "confirm": true}'
scope 支持三种模式：all（全部）、before_date（某时间点之前，需传 before_date）、by_session_ids（指定会话，需传 session_ids）。也可用 DELETE /v1/memories/{id} 删除单条。
与 Mem0 的兼容迁移？
Context0 提供 Mem0 兼容端点，现有 Mem0 应用可平滑迁移：
•
POST /v1/memories：创建记忆（从对话提取原子事实），行为对齐 Mem0。
•
POST /v1/memories/search / /v2/memories/search / /v3/memories/search：语义搜索，/v3 兼容 Mem0 v1.1 SDK（entity params 走 filters map）。
•
/v1、/v2 系列直接返回裸 JSON（不包信封），兼容 Mem0 SDK 解析。
迁移时通常只需把 base URL 指向 Context0 数据面、换上 Context0 的 API Key 即可。相比原生 Mem0，您会额外获得三层记忆蒸馏、混合召回、Token 预算控制与企业级隔离等能力。
多场景能混合使用吗？
可以。策略预设（coding / chat / rag-only / agent）是 per-request 级别的参数，同一 Workspace 内不同请求可使用不同策略。典型做法：
•
编程 Agent 用 coding 策略 ingest + assemble。
•
同 Workspace 内的知识搜索用 rag-only 策略 assemble。
•
跨 Agent 协作场景用 agent 策略 assemble。