sundynix/sundynix-agentix
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
390 Commits 5 Branches 0 Tags
main
Commit Graph

9 Commits

Author SHA1 Message Date
Blizzard 9e2ff6007f docs(deploy): 微信 token 中控文档改回实际采用的 B 方案（宝塔 nginx + IP + 密钥） 
用户腾讯云未配域名、用宝塔。文档从 frp stcp 改成实际走的：宝塔计划任务换 token
+ nginx 站点(IP)+ 密钥头。附强密钥提醒与 frp 隧道备选（token 走公网明文的固有代价）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-21 10:39:39 +08:00
Blizzard cbd0a96ce7 docs(deploy): 微信 token 中控改用 frp stcp 隧道（不上公网，无需域名） 
用户腾讯云未配域名、frp 是 toml。改成：腾讯云 token 服务只绑 127.0.0.1，
经 frp stcp（点对点加密隧道）让 132 拉取，token 全程不上公网、不用证书。

- 说明书给出 toml 版 frp 配置（腾讯云 [[proxies]] stcp + 132 [[visitors]]）、
  cron 换 token 脚本、切换验证步骤。
- compose：gateway 加 extra_hosts host.docker.internal:host-gateway —— 容器里的
  127.0.0.1 是容器自己，token 落在宿主机 127.0.0.1:9099，须经 host.docker.internal 访问。

代码侧（PullToken + accessToken 中控分支）无改动，沿用上一提交。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-21 10:02:09 +08:00
Blizzard a1c68ec6b2 feat(auth): 微信 access_token 走中控服务器（腾讯云静态 IP 换 token） 
隐患：gateway 换 access_token 时微信看到的是本地宽带出网 IP（106.58.232.43，
动态会变），一变白名单就失效、二维码建不出来（40164）。

按微信官方推荐的「中控服务器」架构解决：腾讯云静态 IP 统一换 token，gateway 拉取
使用。微信 IP 白名单只限制换 token 这一步，拿 token 建二维码不查 IP —— 所以
换 token 挪到中控、建二维码仍在 gateway 本地，白名单只填腾讯云 IP，永不失效。

- wechat.PullToken：从中控 HTTPS 端点拉 token（Bearer 密钥鉴权），坏响应/403/空
  token 一律报错不当成功；中控没给 expires_in 时按 7200 兜底。
- handler.accessToken：配了 WECHAT_TOKEN_URL 就只从中控拉、绝不自己 FetchAccessToken
  （微信要求单点刷新，多点各自换会互相顶掉 token）；不配维持直连，零副作用可回退。
- compose：gateway 加 WECHAT_TOKEN_URL / WECHAT_TOKEN_SECRET（从宿主机 .env 注入）。
- deploy/wechat-token-zhongkong.md：腾讯云侧 cron 脚本 + nginx 配置 + 切换验证步骤。

本地验证（假中控 httptest + 真 gateway）：建票时 Redis 缓存的是中控给的 token
（FAKE_TOKEN_FROM_ZHONGKONG），gateway 未直连微信换 token；随后拿该 token 调
qrcode/create（假 token 报 40001 属预期）——证明「中控换 token → 本地建二维码」链路成立。
4 组 PullToken 单测覆盖正常/403/坏JSON/兜底。

真机验证（部署后）：把本地 IP 从白名单删掉、只留腾讯云 IP，扫码仍能登录即坐实
qrcode 不受 IP 限制；若建二维码报 40164 则退回 tinyproxy 正向代理备选。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-21 09:53:27 +08:00
Blizzard a8a497b4ce feat(gateway): 支持微信域名校验文件（为网页授权登录铺路） 
微信公众平台配置「JS接口安全域名 / 网页授权域名」时会下发 MP_verify_xxx.txt，
要求能从域名根目录直接访问。文件放宿主机 /home/workspace/wechat-verify，
只读挂进容器（不进镜像、不进 git —— 它随时可能重发，且属站点凭证类文件）。
未设 WECHAT_VERIFY_DIR 时这段完全不生效。

**第一版写成了独立路由 `/:mpfile`，直接把官网打挂**：它匹配所有单段路径，
于是 /pricing、/download 全变 404（实测确认）。改为并进 NoRoute 的 SPA 兜底里，
在"已排除 /api/ 与内嵌静态文件"之后、回退 index.html 之前处理。

文件名白名单：必须 MP_verify_ 前缀 + .txt 后缀、不含路径分隔符与 ..，
否则落 SPA 兜底 —— 避免把挂载目录变成任意文件下载口子。

回归验证：/ /pricing /download /admin 均 200，校验文件取到正确内容，
/passwd.txt 与路径穿越都只拿到 index.html。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 17:20:02 +08:00
Blizzard c1420b5665 fix(rag): 全文索引在容器里根本没持久化 —— 补 /data 卷 + BLEVE_PATH 
排查「fulltext 路 0 命中」时发现的真问题，比原以为的分词器问题严重得多。

现状：mcp-go 容器**没有任何 volume**，也没设 BLEVE_PATH，于是索引落到相对
CWD 的 .data/bleve。而运行阶段没有 WORKDIR（CWD=/）、进程又是非 root(uid 10001)，
两种结局都糟：
  - 在 / 下建不了目录 → openBleve 静默退回内存索引，重启即清零；
  - 就算建得了，也只是写进容器可写层，每次发版重建容器一样清零。
更糟的是它不报错：混合检索少一路只表现为召回变差，看不出故障。

改动：
  - Dockerfile：建 /data 并 chown 给 app，WORKDIR 设为 /data；
  - 两份 compose：BLEVE_PATH=/data/bleve + 挂持久卷（132 那份此前连
    顶层 volumes 段都没有）；
  - .env.example：写清默认相对路径相对的是**启动目录**——本地从仓库根起
    和从 sundynix-mcp-go/ 起会写出两份互不相干的索引，排查时极易被坑。

附带澄清：中文分词本身没问题。直接开落盘索引验证过，mapping 里 text 字段
确实是 cjk，实测「星间链」命中 4 条、「海关监管」命中 104 条，BM25 打分正常。
a4852c3 那次修复是有效的，之前怀疑分词器的判断作废。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 13:40:31 +08:00
Blizzard ac4fd00e28 fix(deploy): gateway 挂载微信支付证书目录(容器读不到宿主机路径) 
证书在 132 宿主机 /home/workspace/wechat-pay-cert,但 gateway 跑在容器里、没挂任何卷,
LoadPrivateKeyWithPath 直接读磁盘 → 路径不存在 → 商户私钥加载失败、微信渠道隐藏。

只读挂进 gateway(只有它碰支付,dispatcher/mcp-* 不用):
  /home/workspace/wechat-pay-cert → /etc/sundynix/wechat-cert (ro)

⚠️ admin「系统配置 → 支付」里填的必须是**容器内路径** /etc/sundynix/wechat-cert/xxx.pem,
填宿主机路径会失败。私钥不进镜像、不进 git。部署时 compose 变更会让 up -d 重建容器生效。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 10:19:32 +08:00
Blizzard 6b45adbbd2 chore(deploy): 三机部署 compose 拆分 + NATS 3 节点集群 
126=MinIO(已部署)、128=基础设施、132=应用。

- deploy/128-infra:NATS 3 节点集群(独立卷+cluster routes,暴露4222/4223/4224)+PG/Redis/
  Milvus(自带etcd+自带内部minio,不复用126)/Neo4j/Jaeger;端口对局域网暴露、卷持久化。
- deploy/nats-cluster/nats{1,2,3}.conf:max_payload 一致 + jetstream + cluster。
- deploy/132-app:仅 gateway(3000:8080)+dispatcher+mcp-go+mcp-py,无 admin nginx;env 指向
  126/128;mcp-go 补齐 MINIO env(本会话 blob 遗漏);NATS_STREAM_REPLICAS=3;.env.example 模板。
- docker-compose.prod.yml(单机):删 admin 服务(已内嵌)、mcp-go 补 MINIO env。
- 三个 compose 均 docker compose config 校验通过;.env 已 gitignore、.env.example 可提交。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-18 14:45:24 +08:00
Blizzard 3550a22557 feat: 文件入库 — docx/xlsx/pdf/csv 经 mcp-py 解析 → RAG 
入库从纯文本升级为多文件类型：解析(mcp-py 算法层)与切块/embedding 解耦。
上传文件 → Gateway 按类型路由 → mcp-py parse_document 解析为文本 → kb_ingest。

- mcp-py: parsers.py(docx=python-docx / xlsx=openpyxl / pdf=pypdf / csv / txt→文本)；
  parse_document 工具做真(base64 文件→文本，线程池跑 CPU 密集解析)；pyproject 加依赖
- gateway: POST /api/v1/kb/ingest_file(multipart)；parseFile 文本类直读、office/pdf→mcp-py
- nats-server.conf: max_payload 8MB(容纳 base64 文件经工具调用；大文件应走对象存储)
- frontend: KbView 加文件上传(accept docx/xlsx/pdf/csv...)；api.ingestFile
- 验证: 全模块 build✓ + e2e PASS; live——4 类文件上传→mcp-py 解析→入库→检索命中:
  docx(营收报告)/xlsx(销量表行)/pdf(Q2计划)/csv(城市人口) 全部正确
- 边界: 扫描件/版面 OCR(MinerU/PaddleOCR)推迟；大文件 base64 走 NATS 受 max_payload
  限，生产应走对象存储(MinIO)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-11 10:10:07 +08:00
Blizzard c7a02c3905 feat: 初始化 sundynix-agentix 分层式 AI Agent 平台脚手架 
5 层 + 1 条 NATS 零拷贝消息总线的 monorepo（Monolith First → Microservices Morph B）。
纵向主干（任务流 + Token 流回流）已真实跑通，横向各层能力为带注释的桩。

已贯通（real code）:
- sundynix-shared: 共享契约 + JetStream/core NATS 真实收发(bus) + 内嵌 NATS(devnats) + e2e 测试
- sundynix-gateway: Gin 接入 + DSL 解析组装 + NATS Publish + SSE 流式输出
- sundynix-dispatcher: NATS 消费 + Eino Orchestrator 流式回流 + 熔断器 + LLM Pool 占位流式
- 链路: HTTP POST → DSL → sundynix.tasks.* → Dispatcher → Token 经 sundynix.streams.<id> 回流 → SSE
- 基础设施: docker-compose(nats/postgres/redis/neo4j/milvus) + Makefile(make demo/e2e)

待填(桩):
- Eino 图编排 compose.NewGraph、LLM Pool 接 vLLM/Ollama
- Gateway store 换真实 pgx/redis
- sundynix-mcp-go: Bleve+Milvus+Neo4j 混合检索 / UniOffice / 外部 API
- sundynix-mcp-py: gVisor 沙箱 / MinerU(PaddleOCR) / Docker 解释器
- sundynix-desktop: React Flow 画布 → DSL 导出 → SSE 展示
 2026-06-10 11:00:29 +08:00