hailin
/
iconsulting
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
236 Commits 1 Branch 0 Tags 3.6 MiB
Commit Graph

14 Commits

Author SHA1 Message Date
hailin 6476bd868f feat(llm-gateway): 新增对外 LLM API 代理服务 — 完整的监管注入、内容审查和管理后台 
## 新增微服务: llm-gateway (端口 3008)

对外提供与 Anthropic/OpenAI 完全兼容的 API 接口，中间拦截实现：
- API Key 认证：由我们分配 Key 给外部用户，SHA-256 哈希存储
- System Prompt 注入：在请求转发前注入监管合规内容（支持 prepend/append）
- 内容审查过滤：对用户消息进行关键词/正则匹配，支持 block/warn/log 三种动作
- 用量记录：异步批量写入，跟踪 token 消耗和费用估算
- 审计日志：记录每次请求的来源 IP、过滤状态、注入状态等
- 速率限制：基于内存滑动窗口的 RPM 限制

### 技术选型
- Fastify (非 NestJS)：纯代理场景无需 DI 容器，路由开销 ~2ms
- SSE 流式管道：零缓冲直通，支持 Anthropic streaming 和 OpenAI streaming
- 规则缓存：30 秒 TTL，避免每次请求查库

### API 端点
- POST /v1/messages — Anthropic Messages API 代理（流式+非流式）
- POST /v1/embeddings — OpenAI Embeddings API 代理
- POST /v1/chat/completions — OpenAI Chat Completions API 代理
- GET /health — 健康检查

## 数据库 (5 张新表)

- gateway_api_keys: 外部用户 API Key（权限、限速、预算、过期时间）
- gateway_injection_rules: 监管内容注入规则（位置、匹配模型、匹配 Key）
- gateway_content_rules: 内容审查规则（关键词/正则、block/warn/log）
- gateway_usage_logs: Token 用量记录（按 Key、模型、提供商统计）
- gateway_audit_logs: 请求审计日志（IP、过滤状态、注入状态）

## Admin 后端 (conversation-service)

4 个 NestJS 控制器，挂载在 /conversations/admin/gateway/ 下：
- AdminGatewayKeysController: Key 的 CRUD + toggle
- AdminGatewayInjectionRulesController: 注入规则 CRUD + toggle
- AdminGatewayContentRulesController: 内容审查规则 CRUD + toggle
- AdminGatewayDashboardController: 仪表盘汇总、用量查询、审计日志查询

5 个 ORM 实体文件对应 5 张数据库表。

## Admin 前端 (admin-client)

新增 features/llm-gateway 模块，Tabs 布局包含 5 个管理面板：
- API Key Tab: 创建/删除/启停 Key，创建时一次性显示完整 Key
- 注入规则 Tab: 配置监管内容（前置/追加到 system prompt）
- 内容审查 Tab: 配置关键词/正则过滤规则
- 用量统计 Tab: 查看 token 消耗、费用、响应时间
- 审计日志 Tab: 查看请求记录、过滤命中、注入状态

菜单项: GatewayOutlined + "LLM 网关"，位于"系统总监"和"数据分析"之间。

## 基础设施

- docker-compose.yml: 新增 llm-gateway 服务定义
- kong.yml: 新增 /v1/messages、/v1/embeddings、/v1/chat/completions 路由
  - 超时设置 300 秒（LLM 长响应）
  - CORS 新增 X-Api-Key、anthropic-version、anthropic-beta 头
- init-db.sql: 新增 5 张 gateway 表的建表语句

## 架构说明

内部服务（conversation-service、knowledge-service、evolution-service）继续直连 API，
llm-gateway 仅服务外部用户。两者通过共享 PostgreSQL 数据库关联配置。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-25 22:32:25 -08:00
hailin 5034ef4a70 feat(admin): add System Supervisor — global system status chat interface 
Add a "系统总监" (System Supervisor) feature that provides admins with
a natural language chat interface to query the entire iConsulting system's
operational status, including all 7 specialist agents, directives, token
usage, conversation statistics, and system health.

Backend:
- SystemSupervisorChatService: Haiku 4.5 with 7 read-only tools
  - get_agent_configs: list all 7 agent model/parameter configs
  - get_agent_execution_stats: execution counts, success rates, latency
  - get_directives_summary: assessment + collection directive overview
  - get_token_usage_stats: token consumption and cost by model
  - get_conversation_stats: conversation counts, conversion rates, stages
  - get_evaluation_rules: quality gate rule configuration
  - get_system_health: circuit breakers, Redis, service availability
- AdminSupervisorController: POST /conversations/admin/supervisor/chat
- Registered in AgentsModule (provider + export) and ConversationModule
- Added AgentExecutionORM to TypeOrmModule.forFeature in AgentsModule

Frontend (admin-client):
- features/supervisor/ with Clean Architecture layers:
  - infrastructure/supervisor.api.ts: HTTP client
  - application/useSupervisor.ts: React Query mutation hook
  - presentation/pages/SupervisorPage.tsx: full-page chat UI
- Quick action buttons: 系统概况, Agent统计, 成本报告, 健康检查
- Route: /supervisor, menu icon: EyeOutlined (between 收集指令 and 数据分析)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-08 20:49:57 -08:00
hailin 8e4bd95dda feat(agents): add Collection Expert specialist + admin directive system 
## Part A: Collection Expert Specialist Agent (7th specialist)
- New specialist: CollectionExpertService (Haiku 4.5, maxTurns 2)
  - Analyzes user info completeness against 12-item weighted checklist
  - Identifies missing fields, recommends next questions
  - Category-specific priority adjustments (QMAS/GEP/IANG/TTPS/CIES/TechTAS)
  - Tools: search_knowledge, get_user_context
  - Admin directive injection: loads active directives from DB before each run
- Prompt: collection-expert-prompt.ts (completeness calc, validation rules, JSON output)
- Coordinator integration: invoke_collection_expert tool + case in executeAgentTool
- System prompt: section 2.6 usage guide, section 4.3 optional invocation reference

## Part B: Admin Directive System (parallel to assessment directives)
- ORM: CollectionDirectiveORM (collection_directives table)
  - Types: general, priority, category, validation
  - Multi-tenant with tenant_id + enabled indexes
- SQL: CREATE TABLE collection_directives in init-db.sql
- Controller: /conversations/admin/collection-directives (10 REST endpoints)
  - CRUD + toggle + reset + preview + AI chat
- Chat Service: CollectionDirectiveChatService (Haiku 4.5 tool loop)
  - 5 tools: list/create/update/delete/reset directives
  - mutated flag for frontend cache invalidation

## Part C: Frontend Admin-Client
- Feature module: features/collection-config/ (5 files)
  - API client, React Query hooks, Config page, Chat drawer
  - Directive types: 通用指令/优先级调整/类别配置/验证规则
- Route: /collection-config in App.tsx
- Sidebar: FormOutlined icon, label '收集指令' in MainLayout.tsx

Files: 11 new, 9 modified | Backend + frontend compile clean

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-08 20:07:33 -08:00
hailin 9feb03153b feat(agents): add admin assessment directive system for dynamic prompt injection 
Admins can now write natural-language directives that get injected into the
assessment expert's system prompt. Directives are stored in DB, loaded per
execution, and support incremental additions, toggling, and full reset.

Backend:
- New assessment_directives table + ORM entity
- Admin CRUD API at /conversations/admin/assessment-directives
- buildAssessmentExpertPrompt() accepts optional adminDirectives param
- AssessmentExpertService loads active directives from DB before each execution
- Fail-safe: missing repo/tenant context → default prompt (no directives)

Frontend (admin-client):
- New "评估指令" page with table, create/edit modals, toggle switches
- Prompt preview panel showing assembled directive text
- Reset-to-default with confirmation
- React Query hooks for all CRUD operations

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-08 18:21:21 -08:00
hailin 85c78b0775 feat(admin): add system observability dashboard with circuit breaker monitoring 
Backend: expose circuit breaker status via new AdminObservabilityController
(health, circuit-breakers, redis endpoints). Frontend: new observability
feature in admin-client with auto-refreshing status cards.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-08 05:28:24 -08:00
hailin b75d607e2b fix(agents): resolve NestJS route collision for evaluation-rules endpoints 
AdminConversationController's GET /:id was intercepting requests to
AdminEvaluationRuleController (matching "evaluation-rules" as an id param).
Similarly, DELETE /:id was matching "cache" as an id.

Changes:
- conversation.module.ts: Register AdminMcpController and
  AdminEvaluationRuleController before AdminConversationController
  (more specific prefixes must come first in NestJS)
- admin-evaluation-rule.controller.ts: Move static routes (POST /test,
  DELETE /cache) before dynamic routes (GET/:id, DELETE/:id)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-06 20:37:40 -08:00
hailin 00a0ac3820 feat(agents): add admin-configurable evaluation gate for agent loop quality control 
Add a configurable evaluation gate system that allows administrators to
define quality rules per consulting stage. The gate checks are executed
programmatically before the agent loop returns a response to the user.

## Architecture

- **Zero-config safe**: Empty rules table = no checks = current behavior preserved
- **Callback-based decoupling**: agent-loop.ts receives an optional callback,
  stays decoupled from database layer
- **Max 1 retry**: On RETRY/SUPPLEMENT failure, recurse once without gate to
  prevent infinite loops
- **Error-tolerant**: Gate exceptions are caught and logged, never block responses

## New files

- `database/migrations/20260206_add_evaluation_rules.sql` — DB migration
- `domain/entities/evaluation-rule.entity.ts` — Domain entity with 6 rule types
  (FIELD_COMPLETENESS, ASSESSMENT_QUALITY, RESPONSE_LENGTH, MUST_CONTAIN,
  STAGE_MIN_TURNS, CONVERSION_SIGNAL) and 4 failure actions (RETRY, SUPPLEMENT,
  WARN_AND_PASS, ESCALATE)
- `domain/repositories/evaluation-rule.repository.interface.ts` — Repository contract
- `infrastructure/database/postgres/entities/evaluation-rule.orm.ts` — TypeORM ORM entity
- `infrastructure/database/postgres/repositories/evaluation-rule.repository.ts` — Repository impl
- `infrastructure/agents/coordinator/evaluation-gate.service.ts` — Core evaluation engine
  with 5-minute rule cache, per-rule-type evaluators, severity-based action resolution,
  and feedback message builder for model retry
- `application/dtos/evaluation-rule.dto.ts` — Create/Update/Test DTOs
- `adapters/inbound/admin-evaluation-rule.controller.ts` — Admin CRUD API with 8 endpoints:
  list, get, create, update, delete, toggle, test (dry-run), clear cache

## Modified files

- `agent.types.ts` — Add optional `evaluationGate` callback to `AgentLoopParams`
- `stream.types.ts` — Add `EvaluationWarningEvent`, `'evaluating'` phase
- `agent-loop.ts` — Insert gate check at termination point (line 315)
- `coordinator-agent.service.ts` — Inject EvaluationGateService, build callback,
  handle `evaluation_warning` event in StreamChunk mapping
- `agents.module.ts` — Register EvaluationRuleORM, repository, EvaluationGateService
- `conversation.module.ts` — Register AdminEvaluationRuleController

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-06 18:56:52 -08:00
hailin 714a674818 feat(mcp): add MCP Server management — backend API + admin UI 
实现完整的 MCP (Model Context Protocol) 服务器管理功能，包括后端 API 和管理界面。

## 后端 (conversation-service)

### MCP 混合架构核心 (新增)
- mcp.types.ts: MCP 类型定义 (McpServerConfig, McpToolDefinition, McpConnectionState 等)
- mcp-config.service.ts: 配置解析 — 支持环境变量 MCP_SERVERS 和租户级配置
- mcp-client.service.ts: MCP 客户端 — 连接管理、工具发现、工具执行、运行时增删改
- mcp.module.ts: @Global NestJS 模块，注册 MCP 服务 + TypeORM 实体 + Repository

### 数据持久化 (新增)
- 20260206_add_mcp_server_configs.sql: 数据库迁移 — mcp_server_configs 表
- mcp-server-config.orm.ts: TypeORM 实体 (tenant_id 支持多租户)
- mcp-server-config.repository.ts: Repository 层 (CRUD + ORM→McpServerConfig 转换)

### Admin API (新增)
- admin-mcp.controller.ts: 11 个管理端点，路由前缀 conversations/admin/mcp
  - GET /overview — 统计信息 (服务器总数、已连接、错误、工具总数)
  - GET/POST /servers — 列表 + 创建
  - GET/PUT/DELETE /servers/:id — 详情 + 更新 + 删除
  - POST /servers/:id/connect — 手动连接
  - POST /servers/:id/disconnect — 手动断开
  - GET /servers/:id/tools — 查看已发现工具
  - POST /servers/:id/test — 测试连接
  - POST /test-config — 测试未保存的配置

### 已有文件修改
- coordinator-tools.ts: getToolsForClaudeAPI() 支持 additionalTools 可选参数
- agent-loop.ts: 支持 additionalTools + additionalConcurrencyMap 透传
- coordinator-agent.service.ts: 注入 McpClientService，工具路由加 MCP 分支
- agents.module.ts: 导入 McpModule
- conversation.module.ts: 注册 AdminMcpController

## 前端 (admin-client)

### API + Hooks (新增)
- mcp.api.ts: Axios API 客户端 + 完整 TypeScript 类型定义
- useMcp.ts: 10 个 React Query hooks (queries + mutations)

### UI 页面 (新增)
- McpPage.tsx: 主页面 — 统计卡片 + 服务器表格 + 操作按钮
- ServerFormDrawer.tsx: 创建/编辑表单 — 基本信息、传输配置、高级设置、连接测试
- ServerDetailDrawer.tsx: 详情抽屉 — 配置展示、工具浏览 (Collapse + JSON Schema)

### 路由 + 导航
- App.tsx: 添加 /mcp 路由
- MainLayout.tsx: 侧边栏添加 "MCP 服务器" 菜单项 (ApiOutlined 图标)

## 依赖
- @modelcontextprotocol/sdk: ^1.0.0 (MCP 协议 SDK)

## 架构设计
- 混合架构: 16 个内置工具保持不变 + MCP 工具动态发现/热插拔
- 工具名前缀 mcp__{serverId}__{toolName} 确保零冲突
- 优雅降级: MCP 连接失败不影响内置工具，仅 log 记录
- 启动加载: 先连接环境变量配置，再连接数据库配置
- 运行时管理: 支持不重启服务即可增删改 MCP Server

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-06 18:29:02 -08:00
hailin 691a3523e8 feat(analytics): add Agent usage analytics to admin panel 
Add full-stack Agent execution tracking and analytics:

**Database (conversation-service)**
- New `agent_executions` table: tracks each specialist Agent invocation
  with agentType, agentName, durationMs, success, tenantId
- Migration: AddAgentExecutionsTable1738800000000
- ORM entity: AgentExecutionORM with indexes on tenant, conversation,
  agentType, createdAt, and (tenant+date) composite

**Data Capture (conversation-service)**
- conversation.service.ts: captures `agent_start` and `agent_complete`
  StreamChunk events in the sendMessage() async generator loop
- Persists agent execution records to DB after each message completes
- Non-blocking: agent persistence failures are logged but don't break
  the main conversation flow

**Admin API (conversation-service)**
- GET /conversations/admin/statistics/agents?days=30
  Aggregated stats per agent type: totalCalls, successCount, failureCount,
  successRate, avgDurationMs, min/max duration
- GET /conversations/admin/statistics/agents/trend?days=7&agentType=
  Daily trend data: date, agentType, calls, avgDurationMs, successRate
- GET /conversations/admin/:id/agent-executions
  Per-conversation agent execution records ordered by createdAt

**Admin Client - Analytics Page**
- New AgentAnalyticsTab component with:
  - 4 summary cards (total calls, success rate, avg duration, top agent)
  - Agent statistics table (Ant Design Table with sortable columns,
    color-coded Tags, Progress bar for success rate)
  - Stacked bar trend chart (Recharts BarChart, color per agent type)
  - Time range selectors (7/14/30/90 days)
- Added as third tab "Agent 使用分析" in AnalyticsPage dimension tabs

**Admin Client - Conversations Page**
- Added "Agent 使用详情" section to conversation detail drawer
  (between Token Usage and Messages sections)
- Shows per-conversation agent execution table with agent name (color Tag),
  duration, success/failure status, and timestamp
- Empty state: "暂无 Agent 使用记录"

Agent color mapping: policy_expert=#1890ff, assessment_expert=#52c41a,
strategist=#722ed1, objection_handler=#eb2f96, case_analyst=#faad14,
memory_manager=#13c2c2

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-06 08:00:55 -08:00
hailin 931055b51f feat(admin): add conversation management with device tracking display 
## Backend (conversation-service)
- Add AdminConversationController with JWT auth for admin API
- Endpoints: list conversations, by user, detail, messages, statistics
- Support filtering by status, userId, date range, conversion
- Add JWT_SECRET environment variable to docker-compose.yml
- Add jsonwebtoken dependency for admin token verification

## Frontend (admin-client)
### New Features:
- Add conversations feature module with:
  - API layer (conversations.api.ts)
  - React Query hooks (useConversations.ts)
  - ConversationsPage with full management UI

### User Management Enhancement:
- Add "最近咨询记录" section in user detail drawer
- Display device info for each conversation:
  - IP address with region
  - User-Agent (parsed to browser/OS)
  - Device fingerprint
- Show conversation status, conversion status, message count

### Navigation:
- Add "对话管理" menu item with MessageOutlined icon
- Add /conversations route

## Files Added:
- admin-conversation.controller.ts (backend admin API)
- conversations feature folder (frontend)
  - infrastructure/conversations.api.ts
  - application/useConversations.ts
  - presentation/pages/ConversationsPage.tsx

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2026-01-25 10:04:17 -08:00
hailin afd707d15f refactor(services): implement 4-layer Clean Architecture for all backend services 
Refactored all 6 backend services to 4-layer Clean Architecture pattern
following knowledge-service as reference implementation.

## Architecture Pattern (4-Layer)

```
src/
├── domain/              # Pure business entities and interfaces
│   ├── entities/        # Domain entities (no ORM decorators)
│   ├── repositories/    # Repository interfaces + Symbol tokens
│   └── value-objects/   # Enums and value types
├── application/
│   ├── dtos/            # Data transfer objects
│   └── services/        # Application services (use case orchestration)
├── adapters/
│   ├── inbound/         # Controllers, gateways (API endpoints)
│   └── outbound/
│       ├── persistence/ # Repository implementations
│       ├── clients/     # External service clients
│       └── storage/     # File storage adapters
└── infrastructure/
    └── database/postgres/
        └── entities/    # ORM entities with decorators
```

## Services Refactored

### user-service
- adapters/inbound: AuthController, UserController
- adapters/outbound/persistence: UserPostgresRepository, VerificationCodePostgresRepository
- application/services: AuthService, UserService
- application/dtos: AuthDto, UserDto

### payment-service
- adapters/inbound: OrderController, PaymentController
- adapters/outbound/persistence: OrderPostgresRepository, PaymentPostgresRepository
- adapters/outbound/payment-methods: AlipayAdapter, WechatPayAdapter, StripeAdapter
- application/services: OrderService, PaymentService
- application/dtos: OrderDto, PaymentDto

### file-service
- adapters/inbound: FileController
- adapters/outbound/persistence: FilePostgresRepository
- adapters/outbound/storage: MinioStorageAdapter
- application/services: FileService
- application/dtos: UploadFileDto

### conversation-service
- adapters/inbound: ConversationController, InternalController, ConversationGateway
- adapters/outbound/persistence: ConversationPostgresRepository, MessagePostgresRepository, TokenUsagePostgresRepository
- application/services: ConversationService
- application/dtos: ConversationDto

### knowledge-service
- adapters/inbound: KnowledgeController, MemoryController, InternalMemoryController
- adapters/outbound/persistence: KnowledgePostgresRepository, MemoryPostgresRepository
- application/services: KnowledgeService, MemoryService
- application/dtos: KnowledgeDto, MemoryDto

### evolution-service
- domain/entities: AdminEntity
- domain/repositories: IAdminRepository (Symbol-based DI)
- domain/value-objects: AdminRole enum
- adapters/inbound: AdminController, EvolutionController
- adapters/outbound/persistence: AdminPostgresRepository
- adapters/outbound/clients: ConversationClient, KnowledgeClient
- application/services: AdminService, EvolutionService
- application/dtos: AdminDto, EvolutionDto
- infrastructure/database/postgres/entities: AdminORM

## Key Improvements
- Symbol-based dependency injection for repository interfaces
- ORM entities separated from domain entities
- Consistent 4-layer structure across all services
- DTOs for API contracts
- Clear separation: domain logic vs infrastructure concerns

## Configuration
- Updated turbo.json: renamed "pipeline" to "tasks" for Turbo 2.0+

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2026-01-24 22:18:22 -08:00
hailin 02954f56db refactor(services): implement Clean Architecture across 4 services 
## Overview
Refactor user-service, payment-service, file-service, and conversation-service
to follow Clean Architecture pattern based on knowledge-service reference.

## Architecture Pattern Applied

```
src/
├── domain/
│   ├── entities/           # Pure domain entities (no ORM decorators)
│   └── repositories/       # Repository interfaces + Symbol DI tokens
├── infrastructure/
│   └── database/postgres/
│       ├── entities/       # ORM entities with TypeORM decorators
│       └── *-postgres.repository.ts  # Repository implementations
└── {feature}/
    └── {feature}.module.ts # DI configuration with Symbol providers
```

## Changes by Service

### user-service (40% → 100% compliant)
- Created: IUserRepository, IVerificationCodeRepository interfaces
- Created: UserORM, VerificationCodeORM entities
- Created: UserPostgresRepository, VerificationCodePostgresRepository
- Modified: UserEntity, VerificationCodeEntity → pure domain with factory methods
- Updated: user.module.ts, auth.module.ts with Symbol-based DI

### payment-service (50% → 100% compliant)
- Created: IOrderRepository, IPaymentRepository interfaces
- Created: OrderORM, PaymentORM entities
- Created: OrderPostgresRepository, PaymentPostgresRepository
- Modified: OrderEntity, PaymentEntity → pure domain with factory methods
- Updated: order.module.ts, payment.module.ts with Symbol-based DI

### file-service (40% → 100% compliant)
- Created: IFileRepository interface
- Created: FileORM entity
- Created: FilePostgresRepository
- Modified: FileEntity → pure domain with factory methods
- Updated: file.module.ts with Symbol-based DI

### conversation-service (60% → 100% compliant)
- Created: IConversationRepository, IMessageRepository, ITokenUsageRepository
- Created: ConversationORM, MessageORM, TokenUsageORM entities
- Created: ConversationPostgresRepository, MessagePostgresRepository,
          TokenUsagePostgresRepository
- Modified: ConversationEntity, MessageEntity, TokenUsageEntity → pure domain
- Updated: conversation.module.ts with Symbol-based DI
- Updated: app.module.ts, data-source.ts entity patterns

## Key Implementation Details

1. **Symbol-based DI Pattern**:
   ```typescript
   export const USER_REPOSITORY = Symbol('IUserRepository');

   @Module({
     providers: [{ provide: USER_REPOSITORY, useClass: UserPostgresRepository }],
     exports: [UserService, USER_REPOSITORY],
   })
   ```

2. **Pure Domain Entities**: Factory methods `create()` and `fromPersistence()`
   for controlled instantiation without ORM decorators

3. **Repository Implementations**: Include `toORM()` and `toEntity()` conversion
   methods for anti-corruption layer between domain and infrastructure

4. **Entity Discovery**: Changed glob pattern from `*.entity` to `*.orm`
   in app.module.ts and data-source.ts files

## Breaking Changes
- None for API consumers
- Internal architecture restructuring only

## Testing
- All 4 services compile successfully with `pnpm build`
- Database schema compatibility verified (column mappings preserved)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2026-01-24 21:18:25 -08:00
hailin e1bcd0145e refactor(evolution): use API instead of shared database tables 
Breaking change: evolution-service no longer directly accesses
conversations and messages tables.

Changes:
- Add internal API endpoints to conversation-service for service-to-service calls
- Create ConversationClient in evolution-service to call conversation-service API
- Remove ConversationORM and MessageORM from evolution-service
- Update evolution.service to use ConversationClient

This follows microservices best practices:
- Each service owns its data
- Services communicate via API, not shared tables

TODO: Apply same pattern to system_experiences (knowledge-service)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2026-01-24 19:48:09 -08:00
hailin a7add8ff90 Initial commit: iConsulting 香港移民咨询智能客服系统 
项目架构:
- Monorepo (pnpm + Turborepo)
- 后端: NestJS 微服务 + Claude Agent SDK
- 前端: React + Vite + Ant Design

包含服务:
- conversation-service: 对话服务 (Claude AI)
- user-service: 用户认证服务
- payment-service: 支付服务 (支付宝/微信/Stripe)
- knowledge-service: 知识库服务 (RAG + Neo4j)
- evolution-service: 自我进化服务
- web-client: 用户前端
- admin-client: 管理后台

基础设施:
- PostgreSQL + Redis + Neo4j
- Kong API Gateway
- Nginx 反向代理
- Docker Compose 部署配置

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2026-01-09 00:01:12 -08:00