企业级「数据 + 知识」Agent 平台
一个受治理、可评测、可安全执行的数据智能体，覆盖数据与知识的全生命周期
Cognida 是一个面向企业的 「数据 + 知识」Agent 平台，采用 Go + Python 异构多服务架构。
Cognida = Cognition（认知）+ Data（数据），词根取自拉丁语 cognoscere「去认识、去理解」、cognitio「认知 / 知识」。
- Cogni- 是"认知"的词根——不满足于"存起来、查得到"，而追求理解、推理、沉淀、进化；
- -da 既收束于 Data（数据），也让整个词读起来像一个专有的名字，而非一串功能缩写。
一句话：Cognida 想做的不是"能被查询的数据"，而是具备认知能力的数据与知识——让数据自己会理解、会解释、会积累经验、会越用越好。这正对应了页尾那句 slogan：Build Intelligence into Data & Knowledge。
它用一个企业级硬化的 Agent 内核——口径受治理、操作可管控、过程可审计、质量可评测——统一处理：
- 结构化数据的接入、查询、分析与安全操作
- 非结构化知识的收集、沉淀、问答与溯源
目标是让 Agent 覆盖数据与知识从「进来」到「被用起来」再到「被评估改进」的全过程。
Cognida 不是「又一个能问数据的 bot」。市面上的 ChatBI 只会查结构化数据、RAG 工具只会答文档，且都停在"能不能答"。Cognida 补的是答之后那道信任鸿沟——让企业敢把真实数据和真实决策托付给 Agent，并且能验证它到底好不好。
一句话记忆点：
别人是「能问数据的助手」，Cognida 是「敢把数据和知识托付给它、还能度量它好不好的企业级数据智能体」。
| ChatBI | RAG 机器人 | 数据中台 | Cognida | |
|---|---|---|---|---|
| 结构化数据 | ✅ | ✗ | ✅(底座) | ✅ |
| 非结构化知识 | ✗ | ✅ | 部分 | ✅ |
| 口径受治理(可信 SQL) | ✗ | — | 部分 | ✅ |
| 可安全执行(读/写/ETL 分级) | ✗ | ✗ | ✗ | ✅ |
| 可评测(轨迹级度量) | ✗ | ✗ | ✗ | ✅ |
| 全过程可审计 | ✗ | ✗ | 部分 | ✅ |
| Agent 驱动全生命周期 | ✗ | ✗ | ✗ | ✅(建设中) |
护城河 = 三者的交集：企业级硬化的 Agent 内核 × 数据/知识双栖 × 全生命周期覆盖。 单看每一格都是商品，叠加起来才是"组织敢长期托付、还能持续进化"的数据智能体。
Cognida 的每一项能力都落在一张网上：横轴是 Agent 驱动的数据/知识生命周期，纵轴是处理对象。✅ 已实现 · 🚧 规划中。
| 生命周期 → | ①收集/接入 | ②清洗/达标 | ③沉淀/资产化 | ④分析/决策 | ⑤评测/进化 |
|---|---|---|---|---|---|
| 结构化数据 | 多数据源接入 ✅ 数仓接入分析 🚧 Agent 自动收集 🚧 |
数据质量中心 ✅ 数据清洗 ✅ 数据达标(自动+人工) 🚧 |
指标语义层(治理口径) ✅ Result Store ✅ 数据特征化(自动) 🚧 特征存储 🚧 |
Data Agent(DaDa) ✅ Text2SQL(内核内) ✅ 自我修复(错误分级/schema 引导/列值回注/失败护栏/重规划) ✅ 数仓分析 🚧 A2UI 生成式 UI ✅ |
轨迹级 Agent 评测 ✅ Text2SQL/SQL 评测 ✅ Agent 自进化/经验沉淀(默认关) ✅ 数据漂移检测 🚧 进化回路(评测反哺) 🚧 |
| 非结构化知识 | 知识库上传(多格式/委派 OCR) ✅ Agent 自动收集 🚧 |
非结构化质量评估 ✅ 上传去重 ✅ 数据标注/达标 🚧 |
知识库/智能分块/向量化 ✅ 知识图谱抽取 ✅ 跨轮对话记忆 ✅ 长期记忆(接口预留) 🚧 |
知识库助手(Agentic RAG) ✅ 图谱检索/多跳 ✅ DeepResearch(简化版) ✅ |
RAG 评测(faithfulness 等) ✅ 检索/生成指标 ✅ |
| 贯穿层（两者共用） | \ | Agent 内核(ReAct / DeepResearch / 多 Agent 协作 / 编排 / 反思 / Hooks)、安全与治理(scope 门控/写确认/只读加固)、LLM 统一弹性、多租户 RBAC、审计 + request_id + Loki 可观测、Skill/MCP 扩展 | / |
诚实标注：结构化侧的「①自动收集」「③特征化」是当前主要的"洞"。⑤的经验沉淀链路已接线但默认关（会话蒸馏为唯一进化通道，写侧/读侧/SKILL 落地各自独立门控），真正缺的是「评测结论自动反哺收集/沉淀策略」这段回路——把已有工位之间的传送带接上、并默认打开，这个环才算真正自己转起来。
- ReAct 编排：推理-行动循环，统一 Eino Tool 框架
- 上下文工程：三级压缩（① 单条 >32k 就地压缩 · ② 全对话累计 ≥128k 折叠回 ~64k，按整轮折叠保 tool 配对，A 级观测遮蔽 + B 级摘要 · ③ 陈旧推理驱逐 16k），配套
bpecount真实 BPE 计数（内嵌 DeepSeek-V3 tokenizer，//go:embed）而非字符估算 - DeepResearch：深度研究模式，多步推理生成结构化报告（简化版，多源引用/验证规划中）
- Multi-Agent 协作：任务分解、智能分发、结果聚合；委托含「上下文防火墙」+ 委托轨迹穿透（供评测/审计）
- 编排原语：Sequential / Parallel / Loop / Conditional / Supervisor
- 反思 / 评审（critic）：可插拔 LLM / 规则评审子系统（Actor-Critic-Memory），按 Agent 配置启用
- Agent Hooks：数据结论生成、意图澄清、反思、自我修正护栏、guardrail、工具策略（按预设装配）
- 流式响应：SSE 实时输出，结论/图表边推理边下发
- Agent 自进化（经验沉淀，默认关）：后台异步、不阻塞对话——会话经验蒸馏：空闲会话经 LLM 蒸馏为 SKILL.md + 知识图谱 + 经验库，图谱召回在首答注入历史经验；写侧
EXPERIENCE_DISTILL_ENABLED、读侧EXPERIENCE_RECALL_ENABLED、SKILL 落地EXPERIENCE_SKILL_SINK_ENABLED各自独立（均默认关），非 LLM 客观失败门EXPERIENCE_PREGATE_ENABLED默认开
- Data Agent（DaDa）：单一 ReAct 内核驱动的 取数 → 分析 → 渲染 → 操作 闭环，意图路由 → playbook，分层子代理委派（SchemaExplorer / SQLAuthor / Analysis / Operation / Viz 叶子 + Insight / Report 编排器）
- Text2SQL：运行在 Data Agent ReAct 内核内（
get_schema+sql_execute+semantic_query工具循环 + 下述自我修复），而非独立的 Plan-Execute-Reflect 智能体；Schema 感知、多轮对话、结果解释 - 指标语义层（NL2Semantics）：在 LLM 与数仓之间引入受治理的指标语义层，把「裸写 SQL」升级为「按中心化口径生成 SQL」，附覆盖率统计（covered / cache_hit / fallback）
- 多数据源接入：MySQL / PostgreSQL，凭据 AES-256-GCM 加密、连接池、健康检查、
information_schema内省，外部源视为只读外部资源 - A2UI 生成式 UI：
render_ui随流下发 UISpec，图表/表格/结论实时绘制到结果画布；Result Store 中间结果落库、会话重开恢复画布 - 安全执行：会话按
read / write / etl分级，写操作走危险操作确认卡（二次确认 + 令牌时效）；查询默认只读、自动 LIMIT、关键字黑名单、超时保护 - 自我修复（业务层闭环）：SQL/取数报错时不止于重试——① 结构化错误分级（
syntax / unknown_column / unknown_table / permission / timeout / transient，按 MySQL 错误码，sql_error.goclassifySQLError）；② schema 线索回注（列不存在回传该表可用列、表不存在回传近似候选表，经information_schema现取，buildSchemaHint；并对枚举/取值列回注真实取值columnFactsHint）；③ 重复失败护栏（按tool:error_kind计数，触顶提前收尾并转部分结论，self_repair_guard.go，防无限失败循环）；④ 动态重规划（同一失败签名达阈值注入再规划提示，引导换路径而非原样重试）
- 统一检索能力（
RetrievalCapability）：Agent 工具与 REST 接口同源——Milvus 语义向量 + BM25 全文双路召回，RRF 融合、可插拔重排精排、按知识库有界并发扇出（上限 8）；kb_fetch_chunks支持定位原文片段。HyDE / 查询重写 / 多跳仅作为独立 REST 优化器端点提供，尚未做成 Agent 内可组合工具 - 知识库范围强制：范围经会话入口选定并由 ctx 强制透传，工具层求交拒绝越权
- 知识图谱：文档入库时 LLM 并发抽取实体关系三元组，Neo4j 存储；图谱检索支撑关系/关联/溯源类问答；图谱提取=库级开关、检索=提问级开关；一键补建、图谱管理与可视化
- 知识库管理：PDF / Word / Excel / Markdown / TXT，智能分块、向量化、OCR（委派 Python 文档服务，默认
ExtractImages:false）、按 file hash 去重预检 - 跨轮对话记忆：会话内多轮消息回放注入（
model/memory仅定义长期记忆/偏好接口，暂无落地实现）
- 数据质量中心：完整性 / 一致性 / 准确性 / 有效性 / 唯一性 / 时效性打分（维度由 Python 动态返回）；非结构化质量（可读性/信息密度/语言质量 + PII 检测）；数据清洗（去噪/去重/格式转换）。Go 端为薄代理，实际计算委派 Python gRPC（数据漂移检测规划中）
- 评测子系统：QA / RAG / Agent / Text2SQL(SQL) 四类评测，Go 编排/执行/存储，Python 计算打分，grader 注册表为单一事实源
- 检索指标：Recall@K、Precision@K、MRR、NDCG、MAP
- 生成指标：BLEU、ROUGE、语义相似度
- RAG 专项：faithfulness、context_relevance、noise_ratio
- Agent 轨迹级：答案准确性、工具选择、工具顺序、轨迹匹配、步骤效率
- Text2SQL/SQL：
sql_exact_match、sql_component_match、sql_execution_accuracy（Go 只读执行金标准 + 生成两条 SQL，Python 无序比对结果集；SQL 评测自动剔除 ROUGE/BLEU 生成类评分器） - 规则类：exact / contains / regex / numeric
- LLM-as-a-Judge：多维裁判（事实正确性、内容安全性等）
- 独立 FastAPI 评测服务（默认 :18888），前端指标可视化配置与结果明细一体化
- 多租户：数据与权限隔离、RBAC（
model/user/rbac）、用户管理 - 可观测性：request_id 全链路透传、结构化审计（audit_logs）、Loki 日志采集，同 rid 关联
- LLM 统一弹性：跨目标有序降级链 + 同目标指数退避重试（全抖动）+ per-target 三态熔断，透明装饰、成功路径零改动；eino 化
LLMClient（eino_client.go）承接 OpenAI 兼容 Provider，DeepSeek 原生<｜｜DSML｜｜tool_calls>由chat/dsml.go解析回结构化工具调用 - Skill 系统：Agent 本地精选 skill/playbook 注册表，
skill_invoke/skill_list+ SKILL.md 目录（渐进式披露） - Python 数据分析工具（MCP）：经 MCP 通道调用 Python
analytics（趋势/归因/相关/异常等），缓存 + 指数退避重连 + 健康检查
围绕"把生命周期闭环接通"展开，而非无限加功能：
| 模块 | 能力 | 落在生命周期 | 优先级 |
|---|---|---|---|
| Agent 自动收集数据 | Agent 主动从 Web / API / 文件 / 库表发现并采集数据、自动沉淀为知识与数据集 | ①收集/接入 | P1 |
| 数仓分析 | 接入并分析主流数仓（ClickHouse / Doris / StarRocks / Hive / BigQuery 等），作为消费方而非自建数仓 | ①接入 + ④分析 | P1 |
| 数据达标（自动 + 人工） | 自动清洗 + 人工标注/校准的 human-in-the-loop 达标流程，让入库数据可信可用 | ②清洗/达标 | P1 |
| 数据特征化（自动） | 从达标数据自动抽取特征、沉淀为可复用的特征资产（对接特征存储） | ③沉淀/资产化 | P2 |
| 特征存储 | 离线特征宽表（元数据 + 向量特征），供分析与预测复用 | ③沉淀/资产化 | P2 |
| 进化回路 | 评测结论自动反哺收集/沉淀策略，让"自主进化"从能力变成回路 | ⑤评测/进化 | P2 |
| Agentic RL | Agent 强化学习、自主优化、策略迭代 | ⑤评测/进化 | P2 |
| AI 原生能力 | 数据自描述、自适应处理、模型-数据闭环、自主学习 | 全生命周期 | P3 |
设计原则：一个能力要落在"数据/知识 × 生命周期"这张网上、且能和相邻工位交换产物，才值得做；落不上、不交换的，就是负债。先让一小段环端到端跑通（收集 → 达标 → 沉淀 → 分析 → 评测 → 反哺），再加宽。
┌─────────────────────────────────────────────────────────────────────────────┐
│ API Gateway (REST / gRPC / SSE) │
└─────────────────────────────────────────────────────────────────────────────┘
│
┌────────────────────────────┴────────────────────────────┐
▼ ▼
┌───────────────────────────────────┐ ┌───────────────────────────────────┐
│ Go 主后端 │ │ Python 计算服务 │
│ (API / 编排 / Agent) │ │ (AI/ML / 重计算 / gRPC·MCP) │
├───────────────────────────────────┤ ├───────────────────────────────────┤
│ Agent 内核 │ │ gRPC / HTTP 服务 │
│ ├─ ReAct / DeepResearch │ │ ├─ Document (50051) │
│ ├─ Multi-Agent 协作 / 编排 │ │ ├─ Quality (50051) │
│ ├─ 反思 / Hooks │ │ ├─ Analytics(50053) │
│ └─ 安全与治理(scope/写确认) │ │ ├─ Evaluation(HTTP 18888) │
│ │ │ ├─ ML / 特征化 (TODO) │
│ Data Agent (DaDa) │ │ └─ 数据收集 / 达标 (TODO) │
│ ├─ 语义选表 / 指标语义层 │ │ │
│ └─ A2UI / Result Store │ │ MCP Server │
│ │ │ ├─ Analytics 工具(趋势/归因) │
│ 知识库助手 (Agentic RAG) │ │ │ (相关/异常/统计) │
│ ├─ 混合检索 / RRF / 重排 │ │ └─ (Skill 系统在 Go 端) │
│ └─ 图谱增强 / 跨轮记忆 │ │ │
│ │ │ Document Service │
│ 评测编排 · 质量 · 语义建模 │ │ └─ PDF/Word/OCR/分块/URL │
│ 统一检索 · Chat/Session · LLM 弹性 │ │ │
│ User/Tenant · 审计 · 可观测 │ │ Evaluation / Quality / Analytics │
└───────────────────────────────────┘ └───────────────────────────────────┘
│ │
└────────────────────────────┬────────────────────────────┘
▼
┌──────────┬──────────┬──────────┬──────────┐
│ MySQL │ Milvus │ Neo4j │ Redis │
│ (元数据) │(向量/特征)│ (图谱) │(缓存/队列)│
└──────────┴──────────┴──────────┴──────────┘
依赖方向：handler → service → model ← repository
| 存储 | 用途 |
|---|---|
| MySQL | 元数据、配置、任务状态、语义模型、评测结果、审计日志 |
| Milvus | 知识库向量、检索特征 |
| Neo4j | 知识图谱、实体关系、经验图谱、血缘 |
| Redis | 缓存、任务队列、进度、Result Store、分布式锁 |
| 方式 | 端口 | Python 服务 | 状态 | 用途 |
|---|---|---|---|---|
| gRPC | 50051 | Document Service | ✅ | 文档解析、OCR、分块、URL 抓取 |
| gRPC | 50051 | Quality Service | ✅ | 质量检查、数据清洗 |
| gRPC | 50053 | Analytics Service | ✅ | 趋势、洞察、统计、归因 |
| HTTP | 18888 | Evaluation Service | ✅ | 评测计算（compute-metrics，无状态） |
| HTTP | 8000 | 基础 HTTP 服务 | ✅ | Python main.py 基础接口 |
| MCP | 3000（本地 3100） | Analytics 工具通道 | ✅ | Agent 经 MCP 调用 Python 数据分析能力 |
| gRPC | 50054 | ML / 特征化 Service | 🚧 | 特征抽取、模型推理 |
| gRPC | 50055 | 数据收集 / 达标 Service | 🚧 | 自动收集、标注达标 |
- Proto 单一数据源：仓库根
proto/*.proto（buf 管理，buf.yaml/buf.gen.yaml在根目录），Go / Python 各自生成绑定 - MCP：JSON-RPC 2.0 over HTTP/stdio；Go 端
internal/infrastructure/mcp（客户端），Python 端services/cognida-python/mcp_service（服务端，默认端口 3000，本地占用改用 3100）
| 场景 | 说明 | Cognida 能力 |
|---|---|---|
| 可信智能分析 | 自然语言查数，口径受治理、结果可审计、直接出图 | Data Agent · 语义层 · A2UI ✅ |
| 深度研究分析 | 复杂问题多步推理，生成结构化报告 | DeepResearch（简化版） ✅ |
| 知识问答与溯源 | 企业知识沉淀、检索、关系溯源 | Agentic RAG · 知识图谱 ✅ |
| 数据驱动决策 | 基于分析输出可落地行动建议 | Agent 决策 · 结论生成 ✅ |
| 自动数据沉淀 | Agent 自动收集、达标、沉淀为知识与数据集 | 收集 Agent · 达标 · 特征化 🚧 |
Cognida 的价值在"数据 + 知识 + 受治理执行 + 可评测"叠加时才显现。下面是几个可以真实跑起来的落地样例——绝大多数依赖的能力今天已 ✅，标 🚧 的部分是当前的洞（也正是欢迎参与的地方）。
-
📊 经营分析 / 智能 BI 替身 业务负责人用大白话问「上月各区域毛利环比、掉得最狠的三个 SKU 是什么」，Agent 走指标语义层按中心化口径生成 SQL、只读执行、A2UI 直接画出图表与结论，全过程留
request_id审计。相比传统 ChatBI，多了口径治理（不会各人各口径）和结果可审计（能追责、能复盘）。 -
📚 企业知识助手 / 制度问答与溯源 把制度、SOP、合同、产品手册灌进知识库，员工问「XX 报销标准是多少、依据哪条」，Agentic RAG 混合检索 + 重排给出答案并定位到原文片段；涉及"谁签了这份合同、关联哪个项目"这类关系型问题，走知识图谱多跳溯源。知识库范围按会话强制隔离，越权访问在工具层被拒。
-
🔍 尽调 / 竞品 / 市场深研报告 给一个宽泛课题（如"某赛道近一年格局变化"），DeepResearch 多步推理产出结构化报告（当前为简化版，多源引用与交叉验证 🚧）。适合投研、战略、市场做初稿。
-
⚠️ 风险 / 异常运营洞察 「哪些客户有流失风险、为什么、怎么挽回」——Agent 经 MCP 调 Python analytics 做趋势/归因/异常检测，再由结论 Hook 生成可落地的行动建议，而不止于甩一张表。 -
🛡️ 受管控的数据操作（读 / 写 / ETL 分级） 面向"不只是查、还要改"的场景（批量订正、打标、清洗入仓）：会话按
read/write/etl分级，写操作强制走危险操作二次确认卡 + 令牌时效，查询默认只读、自动 LIMIT、关键字黑名单。让企业敢把"会动数据"的能力交给 Agent。 -
🧪 Agent / RAG / Text2SQL 质量评测平台 团队自研了 AI 问数或 RAG 应用，需要客观回归："这次改 prompt 到底变好还是变坏了？" 用内置评测子系统跑轨迹级 Agent 评测 / RAG faithfulness / Text2SQL 执行准确率，把"感觉变好了"变成可度量的分数与明细。这一块可以独立于主业务单独使用。
-
🧩 数据 + 知识联合问答（双栖场景） 真正区别于"只会查库的 bot"或"只会答文档的 RAG"的场景：一个问题同时需要结构化事实（订单量、金额）和非结构化背景（合同条款、政策说明），Cognida 在同一个 Agent 内核里把两栖数据一起用起来。
-
🔄 自主进化的数据工位（愿景 🚧） 终态目标：Agent 自动收集 → 达标 → 沉淀 → 分析 → 评测 → 把评测结论反哺收集/沉淀策略，让整条流水线自己越转越好。今天各工位大多已 ✅、经验蒸馏链路已接线（默认关），缺的是评测反哺那段回路——见「规划中 🚧」。
适用行业不限：零售/电商（经营分析、流失预警）、金融/投研（尽调、风控、合规问答）、制造/供应链（质量与异常）、SaaS/互联网（增长归因、AI 应用评测）等，凡是"既有库表数据、又有文档知识，且对口径与可审计有要求"的组织都能对号入座。
| 角色 | 典型问题 |
|---|---|
| 管理层 | "本月业务健康度如何？有什么需要关注？" |
| 业务分析 | "分析 A 渠道 ROI 下降的原因" |
| 业务运营 | "哪些客户有流失风险？给出挽回建议" |
| IT/数据 | "报表 X 的数据来源是哪里？口径对不对？" |
| 级别 | 定义 | 状态 |
|---|---|---|
| L1 | 模板化输出：按预设模板生成图表报表 | ✅ |
| L2 | 自然语言交互：对话式输出分析结论 | ✅ |
| L3 | 主动决策：拆解任务、规划路径、验证结果、输出行动建议 | 🚧 演进中（Data Agent 已落地） |
| L4 | 自主进化：自动收集→达标→沉淀→分析→评测→反哺的闭环自转 | 🚧 建设中 |
cognida/
├── services/
│ ├── cognida-go/ # Go 主后端（API / 编排 / Agent / RAG / 图谱 / 语义 / 评测编排）
│ │ ├── cmd/ # 可执行入口：server / migrate-db / seed-*（演示与冷启动灌数）
│ │ ├── internal/
│ │ │ ├── handler/ # HTTP handlers（依赖方向：handler → service → model ← repository）
│ │ │ ├── service/ # 业务逻辑：agent / knowledge / semantic / evaluation / quality …
│ │ │ ├── repository/ # 数据访问实现（MySQL / Milvus / Neo4j / Redis）
│ │ │ ├── model/ # 实体与接口定义
│ │ │ ├── infrastructure/ # 基础设施：llm / mcp / cache / graph / auth / config …
│ │ │ ├── wire/ # 依赖注入装配（google/wire 组合根）
│ │ │ └── prompt/ # 提示词配置（//go:embed 打包）
│ │ ├── migrations/ # golang-migrate 版本化迁移（业务表结构唯一真源）
│ │ ├── skills/ # Agent Skill 定义（SKILL.md，运行时按 ./skills 加载）
│ │ ├── api/ · scripts/ · examples/
│ │ └── go.mod
│ └── cognida-python/ # Python 计算服务（文档解析 / 评测 / 质量 / analytics）
│ ├── grpc_service/ · mcp_service/ # gRPC 服务端 + MCP 服务端
│ ├── services/ · core/ · plugins/ # 业务逻辑 / 内核 / 插件
│ ├── api/ · tools/ · tests/
│ └── main.py · pyproject.toml
├── apps/
│ └── cognida-web/ # Vue 3 前端（Vite）：src / public / docs
├── proto/ # gRPC 契约（buf 管理，单一数据源）
├── deploy/ # 部署与日志采集（Loki 等）
├── .github/ # CI（含 gitleaks 安全扫描门）
├── buf.yaml · buf.gen.yaml # buf 代码生成配置
└── dev.sh # 本地一键起停脚本
- Go 1.25+ · Python 3.11+（uv）· Node 18+ · MySQL 8.0+ · Milvus 2.6+ · Neo4j 5.0+ · Redis 7.0+
- 中间件（MySQL / Redis / Neo4j / Milvus）需预先常驻：本机以 Homebrew services 管理 MySQL/Redis/Neo4j，Milvus 跑在 docker 容器。仓库未提供整套 docker-compose 编排。
dev.sh 是真实的一键启动脚本，负责启停 Go 后端 + 4 个 Python 服务 + 前端，并对中间件做连通性预检。
git clone https://github.com/your-org/cognida.git
cd link
# 先确保中间件在跑（示例：Homebrew + docker）
brew services start mysql@8.0 redis neo4j && docker start milvus-standalone
./dev.sh start # 启动全部服务
./dev.sh status # 查看状态
./dev.sh logs go # 跟踪某个服务日志
./dev.sh stop # 停止全部服务# 1. Go 后端（:8080）
cd services/cognida-go && go run ./cmd/server
# 2. Python 服务（uv）
cd services/cognida-python
uv run python -m grpc_service.server # gRPC 50051(+Analytics 50053)
uv run python main.py # 基础 HTTP :8000
uv run uvicorn services.evaluation.fastapi_app:app --port 18888 # 评测 :18888
MCP_MODE=http uv run python -m mcp_service.server # MCP :3000（本机 MCP_PORT=3100）
# 3. 前端（:5173）
cd apps/cognida-web && npm install && npm run dev| 服务 | 端口 | 说明 |
|---|---|---|
| cognida-go（后端） | 8080 | REST / gRPC / SSE 网关 |
| cognida-python gRPC | 50051 / 50053 | Document+Quality / Analytics |
| cognida-python 基础 HTTP | 8000 | main.py 基础接口 |
| cognida-python 评测 | 18888 | FastAPI 评测计算 |
| cognida-python MCP | 3000（本机 3100） | HTTP 模式 MCP |
| cognida-web（前端） | 5173 | Vite 开发服务器（strictPort，代理 /api→:8080） |
数据库表结构：给 GORM model 加字段/建表后，用
cd services/cognida-go && set -a && source .env && set +a && go run ./cmd/migrate-db幂等同步业务表，替代手动ALTER TABLE。
调用链路：浏览器(:5173) → Go 后端(:8080) → gRPC/HTTP/MCP → Python 服务
- Multi-Agent 协作编排 · 生成式 UI（A2UI）· 意图澄清 · 会话洞察 · 反思机制
- Data Agent（DaDa，单一 ReAct 内核）· Python Skill 集成（MCP）
- Data Agent 自我修复（结构化错误分级 / schema 线索引导 / 重复失败护栏 / 动态重规划）
- 外部多数据源接入 · 指标语义层建模入口 + 治理覆盖统计
- 可观测性（request_id 全链路 + 审计 + Loki）· LLM 统一弹性
- Agent 自动收集数据（Web / API / 文件 / 库表 → 自动沉淀）
- 数仓分析（接入并分析 ClickHouse / Doris / StarRocks / Hive / BigQuery）
- 数据达标（自动清洗 + 人工标注/校准，human-in-the-loop）
- 数据特征化（自动） + 特征存储
- Agent 自进化：会话经验蒸馏（SKILL.md/图谱/经验库），后台异步、默认关
- 两套自进化链路收敛为一套（退役反思异步链路，统一到会话经验蒸馏）
- 进化回路：把评测结论自动反哺收集/沉淀策略（当前缺的一段），并默认打开
- Agentic RL（Agent 强化学习）
- 数据自描述 · 自适应处理 · 模型-数据闭环 · 自主学习
- Go 语言规范 · Python 语言规范 · 全局开发规范
坦诚地说，Cognida 还远没到"完善"——它更像一个把方向想清楚、把主干搭起来、但还有大量待补细节的进行中项目。 我们更愿意如实标注"哪里是洞"，也非常欢迎你来一起把它补上。
当前明显不完善、特别欢迎参与的地方：
- 生命周期还没闭环：结构化侧的自动收集、数据特征化 / 特征存储、数仓分析基本还是空的（见「规划中 🚧」与
TODO服务）；最关键的**「评测结论自动反哺收集/沉淀」这段进化回路**尚未接通——这是让 Cognida"自己转起来"的临门一脚。 - DeepResearch 是简化版：多源引用、交叉验证、检索规划都还比较薄。
- 长期记忆只有接口：
model/memory仅定义了长期记忆/偏好接口，尚无落地实现（当前只有会话内跨轮记忆）。 - 检索优化器尚未 Agent 化：HyDE / 查询重写 / 多跳目前只作为独立 REST 端点，还没做成 Agent 内可组合的工具。
- 部署 / 上手成本偏高：仓库未提供整套
docker-compose编排，中间件需自行常驻；一键脚本dev.sh面向本机开发环境。降低上手门槛本身就是很好的贡献。 - 测试与文档覆盖不均：核心链路有覆盖，但仍有不少模块缺测试、缺文档。
怎么参与：
- 先看 Feature Roadmap 和上面的「规划中 🚧」，认领一块你感兴趣的；
- 单人开发阶段直接在
main上迭代——欢迎 Issue 讨论方向、PR 补实现 / 修 bug / 加测试 / 补文档 / 改进部署； - 遵循 开发规范：
准备 → 评估 → 开发 → 测试 → Review → 提交，核心逻辑请带上测试； - 拿不准要不要做？记住设计原则——一个能力要能落在"数据/知识 × 生命周期"这张网上、且能和相邻工位交换产物，才值得做。
不确定从哪下手也没关系，开个 Issue 聊聊就行。任何让这个环"多转一格"的贡献都受欢迎。🚀
本项目采用 MIT 许可证 - 详见 LICENSE 文件
让数据与知识具备智能 · Build Intelligence into Data & Knowledge