One-Line Summary

16 specialized AI agents analyze a stock from every angle — macro, sector, fundamentals, technicals, sentiment, news, filings — then two agents debate bullish vs bearish cases while a judge moderates. Final buy/hold/sell recommendation backed by recomputable numbers. Supports Chinese A-shares, Hong Kong, and US equities.

System Overview

Core Design: Why 16 Agents?

Ask a single LLM “should I buy this stock?” and you get:

• Hallucination: Made-up financial data
• Tunnel vision: Only technical analysis, or only fundamentals
• Unverifiable: No numeric evidence behind the claim

So we split into 16 specialized agents, each doing one thing, using real data instead of LLM-generated data:

Big Picture

The LLM is the brain, the Harness is the hands, the project code is what gets modified. The LLM never directly touches the filesystem — it only says “I want to do X”, and your code executes it.

The Essence: Three Sentences

1. The LLM is the engine: Feed project code to a language model, let it analyze, suggest improvements, and write code. At its core, it’s just a while loop asking the LLM “what else can be improved?”
2. Tools are the hands: The LLM can’t directly read or write files. It uses Anthropic’s tool_use protocol to tell your code “I want to read this file” / “I want to edit this line”, and your code executes it. You could run the whole thing with just a bash tool.
3. Process restart is the key: Python modules are loaded once at startup and stay frozen in memory. When the LLM modifies its own .py files, the running process still uses the old code. A process restart is the only way to apply improvements. That’s why we have the push → tag → CI deploy → restart loop.

From Simplest to Complete System: Each Layer Solves One Problem

Simplest Version (Conceptual)

1
2
3
4

while True:
    code = read_all_project_files()
    response = LLM("Here's the code, improve it:" + code)
    write_back(response)

This works. But it runs into problems. Each layer below solves the previous layer’s problem:

Overview

Synapulse (Synapse + Pulse) is a self-hosted personal AI assistant that lives in your Discord server. The idea came from OpenClaw — after seeing what it could do, I decided to build the personal assistant I had always wanted, one that is lightweight, transparent, and fully under my control.

• GitHub: GOODDAYDAY/Synapulse

Demo

Weather query	Web search + recommendation

Reminder (notify mode)	Reminder (prompt mode)

File creation + send

Features

Architecture

Tech Stack

Project Structure

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

apps/bot/
├── main.py                    # Entry point
├── config/                    # Settings, prompts, logging
├── core/
│   ├── handler.py             # Bootstrap: wire all components via DI
│   ├── loader.py              # Auto-discover tools and jobs from folders
│   ├── mention.py             # Tool-call loop, memory load/save, summarization
│   └── reminder.py            # Background reminder checker
config/                          # Runtime config (models.yaml, mcp.json, jobs.json)
output/                          # Runtime output (logs, data)
├── provider/
│   ├── base.py                # OpenAIProvider, AnthropicProvider
│   ├── endpoint.py            # EndpointPool: rotation, rate-limit fallback
│   └── copilot/auth.py        # GitHub OAuth Device Flow
├── channel/
│   └── discord/client.py      # Discord bot integration
├── tool/                      # Native tools (auto-discovered)
│   ├── base.py                # BaseTool, OpenAITool, AnthropicTool
│   ├── brave_search/          # Web search
│   ├── local_files/           # Read/write local files (sandboxed)
│   ├── memo/                  # Notes management
│   ├── task/                  # Todo list
│   ├── reminder/              # Reminders
│   ├── weather/               # Weather via OpenWeatherMap
│   ├── shell_exec/            # Shell commands (with safety blacklist)
│   └── mcp_server/            # Manage MCP connections via chat
├── job/                       # Background jobs (auto-discovered)
│   ├── cron.py                # CronJob base with hot-reload
│   ├── gmail/                 # Gmail monitoring
│   ├── outlook/               # Outlook monitoring
│   └── qqmail/                # QQ Mail monitoring
├── mcp/
│   └── client.py              # MCPManager: spawn, discover, route
└── memory/
    └── database.py            # JSON file persistence

Core Loop

The tool-call loop in core/mention.py:

Overview

ChromePilot is a Chrome extension that lets you control any webpage using natural language. Type a command like “click the login button” or “fill in my email”, and ChromePilot executes it automatically — clicking, typing, scrolling, and navigating on your behalf.

• Built with AI (Claude) assistance: 3 hours for the initial prototype, 5 hours to polish into v1.0
• Current status: v1.0 — functional and usable, with room for further optimization
• GitHub: GOODDAYDAY/ChromePilot

Features

Demo

Basic Actions — Click Repetition

Command: “drink water 10 times”

Overview

• MySQL is the most widely used relational database in the world.
• As business grows, a single MySQL instance becomes the bottleneck — both in capacity and reliability.
• This blog traces the evolution of MySQL high availability: from simple replication to consensus-based clustering.

Evolution History: The Long Road to High Availability

Single Node Era

The starting point. One MySQL instance handles everything.

Overview

• The common three cluster modes are Redis(Split Cluster), MySQL(Master-Slave), Kafka(RAFT).
• This blog will introduce from the single node to the cluster mode of Redis.

Evolution History: From Single Node to Cluster

Single Node Era

• This is the common monolithic architecture of Redis.

Master-Slave Replication

• As to reliability, it is easy to think adding some nodes as Master-Slave.