持续积累的实践记录。

Agent

qibuddy: Agent hardware console for developers

The problem

Developers may run Claude Code, Codex, Gemini CLI, OpenCode, and other coding Agents at the same time. The difficult part is knowing which Agent is working, which is finished, and which is waiting for permission or an answer across many terminals and sessions.

qibuddy moves that status out of terminal windows and onto an always-visible, low-distraction desktop device that can also accept direct input.

Hardware and desktop

• ESP32-S3 console with an approximately 2.8–3.2 inch TFT display.
• Physical 1 / 2 / 3, BACK, GO, PRAISE / HEART, and FN / MODE buttons.
• A Rust desktop program connects Agents, manages state, and bridges USB serial or a simulator.
• A unified protocol carries Agent, session, state, event, permission, and user-action messages.
• Real hardware, a virtual device simulator, and desktop debugging are supported in parallel.

Core capabilities

• Status overview: Agent name, state, task summary, and elapsed time.
• Permission control: Approve or deny a requested command directly on the device.
• Choice input: Answer 1 / 2 / 3 when an Agent asks the developer to choose.
• Multi-session view: Switch between CLI sessions and prioritize those needing attention.
• Statistics: View tokens, sessions, active work, and waiting tasks.
• Shortcuts: Use GO, BACK, PRAISE, and FN for continue, back, confirm, and mode actions.
• Extensions: Leave room for plugins, JavaScript / Python workflows, and custom macros.

Current status

The project is in planning and implementation. The repository already contains a Rust workspace, desktop app, daemon, protocol, virtual-device simulator, Agent hook integrations, and ESP32-S3 firmware build preparation. Current work is converging the hardware form, screen hierarchy, button interactions, and real-device integration.

ESP32HardwareAgentDeveloper toolsBuilding

Agent

Digital worker platform

The problem

Most chat Agents work for one conversation. They do not reliably receive ongoing tasks, retain context, connect to knowledge, enter team channels, or provide traceable execution and recovery.

The platform is planned as a system where an Agent has a defined role, receives work, follows tool boundaries, and leaves a complete record.

Planned capabilities

• Digital worker profiles, roles, capabilities, and boundaries.
• Task creation, scheduling, execution, retry, pause, and recovery.
• Knowledge, working memory, sessions, and task context.
• Web and messaging channel integrations with a unified wake-up model.
• Usage, billing, audit, logs, and runtime observation.
• Agent runtime, tool calls, and human intervention boundaries.

Current status

The project has entered pilot operation. Digital-worker roles, task scheduling, wake-up, tool calls, knowledge, channels, and run records are being validated in real scenarios. Current work focuses on role boundaries, execution stability, and human takeover.

AgentDigital WorkersWorkflowPlanned

Agent

Yico: Go tournament information and game analysis mini program

Why I built Yico

Amateur Go tournament information is spread across public account articles, QQ groups, spreadsheets, screenshots, and photos. The information exists, but it is not connected.

Yico turns those fragments into a growing tournament archive. Players can query rules, pairings, standings, player records, and promotion information while an event is in progress.

What it does

• Archives tournament rules, dates, groups, formats, scoring, and promotion standards.
• Imports pairings from spreadsheets, Markdown tables, or photographed sheets.
• Builds historical records for players, opponents, rounds, results, and standings.
• Answers questions such as “Who is the next opponent?” and “How many points are needed for promotion?” from stored tournament data.

How Agents are used

Agents turn unstructured tournament material into validated data and help users query existing facts. The current seven scenarios are tournament chat, pairing extraction, promotion-list extraction, image OCR, rulebook extraction, tournament import, and conversation summarization.

Mini ProgramGoAgentData Processing

Agent

xclaw: enterprise Agent control platform

The problem

Real enterprise Agent usage requires runtime control, model routing, knowledge, long-term memory, business-system access, permissions, billing, and audit. Scattered scripts and chat pages cannot provide a durable operating boundary.

Core capabilities

• Agent and Team configuration, release, execution, approval, and recovery.
• User portal, API keys, H5 embedding, and mobile entry points.
• Scheduled jobs, workers, sessions, and run records.
• Markdown Wiki, knowledge trees, entity graphs, and retrieval.
• L0-L3 memory injection, conversation compression, and context management.
• OpenAI-compatible Model Gateway, MCP, and realtime channels.
• External-system Connectors, DLP checks, encrypted provider keys, and audit.
• Amount-based billing, usage reporting, and operations console.

System structure

Hub owns the enterprise control plane and policies, Worker performs governed Agent runs, and Desk is the employee workspace. They coordinate through Run, Event, Tool, Session, and Usage protocols while access to knowledge, memory, models, and business systems stays inside the platform boundary.

AgentEnterprise softwareKnowledgeMemoryConnector