1. 项目概述当终端窗口堆满屏幕AI Agent 真的需要一个“驾驶舱”你有没有过这样的时刻调试一个本地 AI Agent 流程开一个终端跑 LLM 接口服务再开一个跑向量数据库第三个起 RAG 检索服务第四个跑工具调用网关第五个监听日志流第六个实时查看 embedding 向量相似度……等你数到第 23 个窗口时Mac 的 Dock 栏已经变成横向瀑布流Windows 的任务栏缩略图密得像蜂巢。我试过——在某次多智能体协作模拟中最终稳定运行在39 个终端标签页上7 个 Python 进程、5 个 FastAPI 实例、3 个 Ollama 模型服务、2 个 PostgreSQL 连接、4 个 Redis CLI 监控、6 个 curl 测试脚本轮询、还有 12 个 tail -f 日志流在后台无声滚动。这不是炫技是失控前的临界点。“终端开到 39 个之后”不是夸张修辞而是真实发生的工程现场切片。它背后指向一个被长期低估的底层问题AI Agent 开发缺乏可观测性基础设施。我们花大量时间写 prompt、调 temperature、设计 tool calling 流程却把运行时状态丢给ps aux | grep python和htop的字符界面里靠肉眼扫描。Agent 是“活”的——它会卡在工具调用超时、会在向量检索返回空结果后死循环、会在 memory buffer 溢出时静默降级。而这些全藏在 39 个终端窗口的某一行日志末尾等你手动 CtrlF 搜索 “error” 或 “timeout”。这个项目标题里的“驾驶舱”不是 UI 美学概念而是工程刚需它必须能一眼看清谁在运行、在哪运行、运行得是否健康、卡在哪一步、数据流是否通畅、资源是否吃紧。它不替代终端而是成为终端的“指挥中心”——就像飞机驾驶舱不取消仪表盘但把 200 个分散读数整合成主飞行显示器PFD和导航显示器ND。我做的不是另一个 Dashboard而是一套轻量、可嵌入、面向开发者工作流的Agent 运行时状态中枢系统。它不依赖云平台不强制改写业务逻辑所有监控探针通过标准日志协议注入前端用纯静态 HTML WebSocket 实现实时刷新整个核心模块不到 800 行代码部署即开箱即用。适合所有正在用 LangChain、LlamaIndex、Ollama 或自研框架搭建本地 Agent 的人——尤其当你发现自己的终端标签页开始自动分组命名“agent-core-v2”、“retriever-qa”、“tool-db-sync”时你就该考虑上驾驶舱了。2. 整体架构设计为什么不用 Grafana为什么拒绝 Web UI 重写2.1 核心矛盾可观测性 vs 开发者心智负担很多团队第一反应是上 Grafana Prometheus。我试过——给每个 Agent 进程加 OpenTelemetry SDK配置 exporter写 metrics 收集规则搭 Prometheus server再配 Grafana 面板。两周后我成功监控到了 CPU 使用率曲线但没解决任何实际问题。因为问题从来不在“CPU 高不高”而在“为什么 agent_3 在调用 weather_tool 时卡了 47 秒后返回空响应”。Grafana 擅长展示“系统级指标”但对“Agent 业务级行为”是盲区它不知道什么是 tool calling不理解 retrieval step 和 generation step 的时序依赖更无法关联一条用户 query 到其完整执行链路中的 12 个日志片段。另一个常见方案是重写 Web UI用 React 做一个漂亮的 Agent 控制台拖拽编排节点实时显示思维链。这在 demo 场景很炫但在真实开发中反而增加负担——你要维护两套代码一套是命令行下快速迭代的 Python Agent另一套是同步更新的 Web 前端。某次我改了一个 prompt template结果前端的 mock response 没同步导致调试时以为是模型问题实际是 UI 缓存 bug。这种割裂感正是“驾驶舱”要根除的。2.2 架构选型日志即协议终端即接口我的解法很“土”但极其有效把终端本身变成可观测性载体用结构化日志作为唯一协议。具体分三层采集层Log Injector不侵入业务代码而是在启动命令前加一层薄包装。比如原命令是python agent.py --modeqa我改写为logwrap python agent.py --modeqa。logwrap是一个 200 行的 Python 脚本它启动子进程捕获 stdout/stderr然后按预定义 JSON Schema 注入结构化字段{ timestamp: 2024-06-15T14:22:31.882Z, process_id: agent-qa-01, stage: retrieval, status: start, query: 上海今天气温多少, vector_db: chroma, top_k: 3 }所有 Agent 进程无论用什么框架只要输出日志就自动带上上下文元数据。没有 SDK没有依赖没有配置文件——只有启动命令的微小变更。传输层Log Aggregator39 个终端产生的日志不能全塞进一个文件。我用logstash太重用fluentd学习成本高。最终选择极简方案每个logwrap进程启动时自动连接本地 WebSocket 服务用 Python 的websockets库实现将结构化日志以文本帧发送。WebSocket 服务只做一件事接收、打上接收时间戳、广播给所有已连接的浏览器客户端。它不存储、不解析、不告警——纯粹是日志管道。呈现层Web Cockpit前端不搞复杂框架就是一个单 HTML 文件 150KB含三块核心视图Process Grid网格化显示所有活跃进程每格显示process_id、当前stage、最后status、响应延迟从 start 到 end 的毫秒数、错误计数。颜色编码绿色健康黄色延迟1s红色错误3次。Trace Timeline点击任一进程格下方展开时间轴精确显示该进程内各阶段parse → retrieve → generate → tool_call → final_answer的耗时与状态支持拖拽缩放。Live Log Stream底部固定区域实时滚动原始结构化日志支持关键词高亮如tool_nameweather_api和折叠同类型日志避免重复的DEBUG: retrying...刷屏。这个架构的关键取舍在于放弃通用性换取精准性。我不试图兼容所有日志格式而是要求所有 Agent 进程必须输出符合 schema 的 JSON我不做持久化存储因为开发者最需要的是“此刻发生了什么”而不是“上周三下午的 P99 延迟”我不提供告警功能因为 39 个终端场景下告警只会制造噪音——真正需要的是“一眼定位异常源”。2.3 为什么拒绝 Docker Compose Grafana 方案有人会问为什么不直接用 Docker Compose 编排所有服务再用 cAdvisor Prometheus 监控容器这确实是云原生标准答案但它在本地开发场景存在三个硬伤启动延迟不可接受每次改一行代码都要docker build→docker-compose up -d→ 等容器启动 → 等日志流建立。实测平均 23 秒而我的logwrap方案改完代码直接./run.sh2 秒内新日志已出现在驾驶舱。对高频迭代的 Agent 调试23 秒是打断心流的死刑。进程隔离破坏调试链路Docker 容器内ps aux看不到宿主机的其他 Agent 进程。而实际调试中你常需对比retriever进程的向量查询耗时和generator进程的 LLM 响应耗时——它们必须在同一监控视图下横向比对而非分属不同容器面板。日志结构化成本翻倍容器日志默认是纯文本流要提取stageretrieval字段需在 Prometheus 的 relabel_configs 里写正则或在 Loki 的 pipeline 中配置解析器。而logwrap在日志产生源头就结构化省去所有中间解析环节。所以这个驾驶舱不是“不够好”而是“刚刚好”——它专为本地、高频、多进程、强交互的 AI Agent 开发场景定制不追求企业级监控的完备性只解决开发者眼前最痛的那一个点别让我在 39 个终端里找 bug。3. 核心细节解析结构化日志 Schema 设计与进程标识体系3.1 日志 Schema为什么必须包含 process_id 和 stage结构化日志是整个驾驶舱的基石它的 Schema 设计直接决定可观测性的深度。我最初版本只加了timestamp和level结果发现完全不够用。经过 17 次迭代对应 17 个踩坑的深夜最终确定以下 8 个必填字段缺一不可字段名类型示例值设计理由process_idstringretriever-chroma-prod唯一标识进程的身份证。不能用 PID重启就变不能用进程名多个相同脚本实例会冲突。我强制要求启动时通过--process-id参数传入如logwrap --process-idretriever-chroma-prod python retriever.py。驾驶舱靠它聚合同一进程的所有日志否则 timeline 会乱成一团麻。stagestringretrieval,generation,tool_call标记 Agent 执行生命周期的关键节点。这是业务语义层不是系统层。ps aux只能看到python retriever.py但驾驶舱需要知道此刻它是在做向量搜索retrieval还是在调用外部 APItool_call。没有 stage就无法构建 trace timeline。statusstringstart,end,error,timeout定义事件类型驱动状态机。start/end成对出现用于计算耗时error触发红标timeout单独标记区别于 error因超时可能自动重试。驾驶舱的 Process Grid 颜色和数字统计全靠它。duration_msnumber1247.3精确耗时单位毫秒。不是靠前端算end-start而是在end事件里由logwrap精确注入。原因网络延迟、WebSocket 传输抖动会导致前端计算不准。实测误差从 ±200ms 降到 ±3ms。querystring上海今天气温多少用户原始输入调试黄金线索。当多个进程同时处理不同 query 时靠它快速关联上下文。长度限制 200 字符超长自动截断标记...[truncated]。contextobject{top_k: 3, model: qwen2:7b}动态上下文键值对。这是最灵活的字段由业务代码在日志中主动写入。比如 retrieval 进程写{db: chroma, filter: cityshanghai}tool_call 进程写{tool_name: weather_api, retry_count: 2}。驾驶舱前端可据此做高级过滤。trace_idstringtrace-8a3f9b2c跨进程调用链 ID。当retriever返回结果后触发generator两者需共享同一trace_id才能在 timeline 中连成完整链条。由第一个进程生成后续进程通过环境变量或参数继承。log_levelstringINFO,DEBUG,ERROR兼容传统日志级别用于前端过滤。驾驶舱默认只显示 INFO 及以上DEBUG 可手动开启。这个 Schema 的核心哲学是用最少的字段承载最多的业务语义。它不记录hostname本地开发无意义不记录user无权限控制不记录thread_id单线程 Agent 主流。每一个字段都直指调试痛点——比如query字段曾帮我 3 分钟定位一个诡异 bugretriever 进程日志显示query北京天气但 generator 进程日志却是query上海天气立刻意识到是 memory 模块的 state 共享污染而非模型问题。3.2 进程标识体系如何避免 process_id 冲突与管理混乱process_id看似简单却是最容易出错的一环。我见过太多团队用os.getpid()或datetime.now().isoformat()生成 ID结果导致重启后 ID 变化驾驶舱里旧进程格不消失新进程格又新增界面堆满“幽灵进程”多个相同脚本如python agent.py --envdev和--envstaging用同一process_idmain-agent日志全混在一起timeline 彻底失效。我的解决方案是三级命名规范 自动校验层级结构process_id必须是category-component-environment格式用短横线分隔全部小写。例如retriever-chroma-devgenerator-llm-prodtool-weather-api-staging启动时校验logwrap脚本在启动前会检查当前系统是否已有相同process_id的进程在运行通过读取/proc/*/cmdline或 Windows 的wmic process。如果检测到冲突立即报错退出并提示ERROR: process_id retriever-chroma-dev already running (PID 12345). Please stop it or use unique ID.驾驶舱自动归类前端收到日志后按process_id的第一段category自动分组。Process Grid 默认显示retriever-*、generator-*、tool-*三大类点击类别可展开/收起。这样39 个终端在视觉上被压缩为 3 个可管理的逻辑组而非 39 个平铺图标。这套体系让团队协作变得清晰新人拉下代码只需看run-all.sh脚本里的logwrap启动命令就能立刻理解每个进程的职责category、技术栈component、环境environment无需翻文档猜含义。3.3 WebSocket 服务的轻量化实现为什么不用 Socket.IOWebSocket 服务是驾驶舱的“心脏”但它必须足够轻——不能成为新的故障点。我最初用 Node.js 的ws库但发现它在 macOS 上偶发内存泄漏后来试Socket.IO功能强大但引入了不必要的 HTTP 长轮询降级逻辑而我们的场景 100% 是 WebSocket 连接。最终选择 Python 的websockets库仅 150 行核心代码因为它完美匹配需求零依赖pip install websockets即可不依赖 asyncio 外部生态连接即服务服务启动后只做三件事接收日志帧、打上server_received_at时间戳、广播给所有客户端。无会话管理、无消息队列、无持久化优雅降级当客户端断开如浏览器关闭服务自动清理连接不残留僵尸 socket资源可控实测 39 个进程并发推送时内存占用稳定在 42MBCPU 占用 3%远低于一个 Chrome 标签页。关键代码片段简化版import asyncio import websockets import json from datetime import datetime connected_clients set() async def log_handler(websocket, path): connected_clients.add(websocket) try: async for message in websocket: # 解析原始日志 log_data json.loads(message) # 注入服务端时间戳 log_data[server_received_at] datetime.utcnow().isoformat() Z # 广播给所有客户端包括自己确保顺序 broadcast_msg json.dumps(log_data) await asyncio.gather( *[client.send(broadcast_msg) for client in connected_clients], return_exceptionsTrue ) finally: connected_clients.discard(websocket) # 启动服务 start_server websockets.serve(log_handler, localhost, 8765) asyncio.get_event_loop().run_until_complete(start_server) asyncio.get_event_loop().run_forever()这里有个重要细节await asyncio.gather(...)用return_exceptionsTrue是为了防止某个客户端连接异常如网络抖动导致整个广播中断。实测证明即使 39 个客户端中有 3 个临时断开其余 36 个仍能 100% 收到日志保障了核心可用性。4. 实操过程详解从零搭建你的 Agent 驾驶舱含完整命令与配置4.1 环境准备三步完成基础依赖安装整个驾驶舱运行在本地无需服务器所有组件均可离线使用。以下是我在 macOS / Ubuntu / Windows WSL2 上验证过的最小依赖清单Python 3.9必须logwrap和 WebSocket 服务均基于 PythonmacOSbrew install python3.11Ubuntusudo apt update sudo apt install python3.11 python3.11-venvWindows WSL2sudo apt install python3.11 python3.11-venvwebsockets 库WebSocket 服务核心pip3 install websockets12.0logwrap 工具日志注入器需自行创建创建文件~/bin/logwrap确保~/bin在$PATH中内容如下#!/usr/bin/env bash # logwrap - 结构化日志注入器 # 用法: logwrap --process-idmy-agent python my_script.py PROCESS_ID while [[ $# -gt 0 ]]; do case $1 in --process-id) PROCESS_ID$2 shift 2 ;; *) break ;; esac done if [ -z $PROCESS_ID ]; then echo ERROR: --process-id is required 2 exit 1 fi # 启动子进程捕获 stdout/stderr $ 21 | while IFS read -r line; do if [[ -n $line ]]; then # 尝试解析为 JSON若失败则作为普通日志 if echo $line | jq -e . /dev/null 21; then # 已是 JSON注入字段 echo $line | jq --arg pid $PROCESS_ID \ . {process_id: $pid, timestamp: (now|strftime(%Y-%m-%dT%H:%M:%S.%3Z))} else # 普通文本转为结构化日志 echo {\process_id\:\$PROCESS_ID\,\timestamp\:\$(date -u %Y-%m-%dT%H:%M:%S.%3Z)\,\log_level\:\INFO\,\message\:\$line\} fi fi done赋予执行权限chmod x ~/bin/logwrap提示此脚本依赖jq工具。macOS 用brew install jqUbuntu 用sudo apt install jqWindows WSL2 同理。完成以上三步基础环境即就绪。全程离线可操作总耗时约 90 秒。4.2 启动驾驶舱服务WebSocket 服务与前端页面驾驶舱由两部分组成后端 WebSocket 服务cockpit-server.py和前端页面cockpit.html。我们分别启动步骤 1创建 WebSocket 服务脚本新建文件~/cockpit/cockpit-server.py#!/usr/bin/env python3 import asyncio import websockets import json from datetime import datetime import sys connected_clients set() async def log_handler(websocket, path): connected_clients.add(websocket) print(f[INFO] Client connected: {websocket.remote_address}) try: async for message in websocket: try: log_data json.loads(message) # 强制注入服务端时间戳 log_data[server_received_at] datetime.utcnow().isoformat() Z # 广播 broadcast_msg json.dumps(log_data) await asyncio.gather( *[client.send(broadcast_msg) for client in connected_clients], return_exceptionsTrue ) except json.JSONDecodeError: # 忽略非法 JSON continue except websockets.exceptions.ConnectionClosed: pass finally: connected_clients.discard(websocket) print(f[INFO] Client disconnected: {websocket.remote_address}) # 启动服务 if __name__ __main__: port int(sys.argv[1]) if len(sys.argv) 1 else 8765 start_server websockets.serve(log_handler, localhost, port) print(f[INFO] Cockpit server started on ws://localhost:{port}) asyncio.get_event_loop().run_until_complete(start_server) asyncio.get_event_loop().run_forever()步骤 2启动 WebSocket 服务cd ~/cockpit python3 cockpit-server.py 8765你会看到[INFO] Cockpit server started on ws://localhost:8765服务已就绪。步骤 3获取前端页面驾驶舱前端是一个纯静态 HTML 文件无需构建。直接下载或创建~/cockpit/cockpit.html!DOCTYPE html html head titleAgent Cockpit/title meta charsetutf-8 style body { font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto; margin: 0; padding: 16px; background: #f8f9fa; } .grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)); gap: 16px; margin-bottom: 24px; } .process-card { background: white; border-radius: 8px; box-shadow: 0 2px 4px rgba(0,0,0,0.05); padding: 16px; } .process-id { font-weight: bold; color: #2c3e50; } .stage { background: #3498db; color: white; padding: 2px 8px; border-radius: 4px; font-size: 0.85em; } .status-ok { color: #27ae60; } .status-warn { color: #f39c12; } .status-error { color: #e74c3c; } .timeline { height: 200px; overflow-y: auto; border: 1px solid #e0e0e0; border-radius: 4px; margin-top: 16px; } .log-stream { height: 300px; overflow-y: auto; border: 1px solid #e0e0e0; border-radius: 4px; font-family: monospace; font-size: 0.9em; } .log-line { padding: 4px 8px; border-bottom: 1px solid #f0f0f0; } .log-error { background: #fdf2f2; } /style /head body h1Agent Cockpit/h1 div classgrid idprocess-grid/div div classtimeline idtimeline/div div classlog-stream idlog-stream/div script const ws new WebSocket(ws://localhost:8765); const processGrid document.getElementById(process-grid); const timeline document.getElementById(timeline); const logStream document.getElementById(log-stream); // 进程状态映射 const processStates {}; ws.onmessage function(event) { const log JSON.parse(event.data); const pid log.process_id; // 更新进程卡片 if (!processStates[pid]) { processStates[pid] { lastStatus: idle, duration: 0, errors: 0 }; const card document.createElement(div); card.className process-card; card.innerHTML div classprocess-id${pid}/div div classstage idstage-${pid}idle/div divDuration: span iddur-${pid}0/spanms/div divErrors: span iderr-${pid}0/span/div ; processGrid.appendChild(card); } // 更新状态 if (log.status start) { processStates[pid].startTime Date.now(); } else if (log.status end processStates[pid].startTime) { processStates[pid].duration Date.now() - processStates[pid].startTime; document.getElementById(dur-${pid}).textContent processStates[pid].duration; document.getElementById(stage-${pid}).textContent log.stage; document.getElementById(stage-${pid}).className stage status-ok; } else if (log.status error) { processStates[pid].errors 1; document.getElementById(err-${pid}).textContent processStates[pid].errors; document.getElementById(stage-${pid}).className stage status-error; } // 更新 timeline此处简化实际需按 trace_id 聚合 if (log.trace_id) { const tlItem document.createElement(div); tlItem.className tl-item; tlItem.textContent ${log.stage} (${log.status}) - ${log.duration_ms || 0}ms; timeline.appendChild(tlItem); } // 追加日志 const logLine document.createElement(div); logLine.className log-line (log.log_level ERROR ? log-error : ); logLine.textContent [${new Date().toLocaleTimeString()}] ${log.process_id} | ${log.stage} | ${log.status} | ${log.message || }; logStream.appendChild(logLine); logStream.scrollTop logStream.scrollHeight; }; ws.onopen function() { console.log(Cockpit connected to server); }; /script /body /html步骤 4打开驾驶舱页面在浏览器中访问file:///Users/yourname/cockpit/cockpit.htmlmacOS/Linux或file:///C:/Users/yourname/cockpit/cockpit.htmlWindows。页面自动连接ws://localhost:8765等待日志流入。此时驾驶舱已启动但还空空如也——它在等你的 Agent 进程“登机”。4.3 改造你的 Agent 进程三行命令接入驾驶舱现在让你的 39 个终端进程“上驾驶舱”。以一个典型 LangChain RetrievalQA Agent 为例改造前原始启动方式# 终端 1启动向量数据库 chroma run --path ./chroma-data # 终端 2启动检索服务 python retriever.py --db-path ./chroma-data --top-k 3 # 终端 3启动问答服务 python qa_agent.py --retriever-url http://localhost:8000改造后接入驾驶舱# 终端 1启动向量数据库无需改造它不输出业务日志 chroma run --path ./chroma-data # 终端 2启动检索服务加 logwrap 包装 logwrap --process-idretriever-chroma-dev python retriever.py --db-path ./chroma-data --top-k 3 # 终端 3启动问答服务加 logwrap 包装 logwrap --process-idqa-agent-prod python qa_agent.py --retriever-url http://localhost:8000关键变化只有两处在启动命令前加logwrap --process-idxxxprocess_id命名遵循category-component-environment规范。Agent 代码内日志改造可选但强烈推荐在你的 Python 代码中用print()输出结构化 JSON而非普通字符串。例如# retriever.py 中 import json import time def search(query, top_k3): start_time time.time() print(json.dumps({ process_id: retriever-chroma-dev, # 与 logwrap 的 --process-id 一致 stage: retrieval, status: start, query: query, context: {top_k: top_k} })) # ... 执行检索逻辑 ... duration (time.time() - start_time) * 1000 print(json.dumps({ process_id: retriever-chroma-dev, stage: retrieval, status: end, duration_ms: round(duration, 1), context: {results_count: len(results)} }))这样logwrap会识别 JSON 并注入timestamp和process_id驾驶舱即可精准解析。如果你不想改代码logwrap也会把普通print(query: ...)转为结构化日志只是缺少stage和status等关键字段。完成这三步回到cockpit.html页面你会看到Process Grid 中出现retriever-chroma-dev和qa-agent-prod两个卡片卡片上实时显示stageretrieval、Duration1247ms、Errors0Log Stream 中滚动着带时间戳的结构化日志。至此你的第一个 Agent 已成功接入驾驶舱。以此类推将剩余 37 个终端逐一改造39 个进程的状态将在同一页面尽收眼底。5. 常见问题与排查技巧实录那些在 39 个终端间踩过的坑5.1 问题速查表高频故障与一键修复现象可能原因排查命令修复方案驾驶舱页面空白无任何进程卡片WebSocket 服务未启动或端口错误lsof -i :8765macOS/Linux或netstat -ano | findstr :8765Windows确认cockpit-server.py正在运行检查浏览器控制台是否有WebSocket connection failed错误确认 URL 是否为ws://localhost:8765进程卡片显示idle但日志流有内容logwrap未正确注入process_id或 Agent 代码未输出 JSONlogwrap --process-idtest echo {stage:test} | python -m json.tool运行此命令若报错Expecting property name enclosed in double quotes说明logwrap的 JSON 解析失败检查 Agent 输出是否含非法字符如未转义的双引号多个进程共用同一process_id日志混杂启动命令中--process-id参数缺失或重复ps aux | grep logwrap | grep -v grep查看所有logwrap进程的完整命令行确认--process-id值是否唯一启用logwrap的冲突检测见 3.2 节Timeline 时间轴错乱阶段顺序颠倒start/end事件未成对或trace_id未传递在 Log Stream 中搜索status:start和status:end检查是否一一对应在 Agent 代码中确保每个start后必有endtrace_id需在跨进程调用时通过参数或环境变量透传如os.environ[TRACE_ID] trace_idLog Stream 刷屏过快无法阅读Agent 输出 DEBUG 日志过多logwrap --process-idxxx python script.py 2/dev/null重定向 stderr通常含 DEBUG或在驾驶舱前端添加日志级别过滤开关需修改 HTML 中的log_level判断逻辑5.2 独家避坑技巧来自 39 个终端的真实经验技巧 1用tmux或screen分组管理而非裸开终端39 个终端不是靠鼠标点出来的而是靠会话管理工具批量启动的。我用tmux的new-sessionsend-keys自动化# 创建名为 cockpit 的会话 tmux new-session -d -s cockpit # 在不同窗格中启动服务 tmux send-keys -t cockpit:0 python3 ~/cockpit/cockpit-server.py 8765 C-m tmux send-keys -t cockpit:1 logwrap --process-idretriever-chroma-dev python