Summary
Ship a Feishu/Lark bot that exposes DeepSeek TUI as a chat-platform participant. Not a new backend — a thin webhook layer over the existing runtime_api.rs / runtime_threads.rs / task_manager.rs stack. The TUI is one frontend; a Feishu bot is another.
Why chat platforms
DeepSeek's user base lives in Feishu / WeCom / WeChat, not in terminals. A TUI asks a Chinese knowledge worker to leave their workflow. Specs are in Feishu Docs, discussion in chat threads, voice notes are real input, code review often happens in-thread before Gitee. The task already lives in chat — putting the agent there isn't distribution, it's meeting users where the work is.
Why the "driving" metaphor works better in chat
In a TUI, co-presence requires inventing dashboard panels and ghost cursors. In a chat thread, co-presence is the default:
- The agent is just another participant in a persistent, bidirectional, multi-user thread
- Dashboard = what the bot posts. Structured updates, progress cards, diff previews
- Engagement dial maps naturally:
@mention for an assist/command for a focused task- "go run this overnight" for autopilot
- Teammate grabs the wheel by replying
- Teaching is social. "Try DSPy here" — whole team sees it and learns together
- Voice input is the sleeper. "Describe it while I'm on the subway, agent works while I keep meeting" — untouchable by terminal-first tools
Why the backend is already built
| Component |
What it provides |
How the bot uses it |
runtime_api.rs |
HTTP/SSE API server |
Webhook receiver → API call → SSE response streamed to chat |
runtime_threads.rs |
Durable, replayable threads with monotonic event sequences |
One Feishu thread = one runtime thread. State survives restarts |
task_manager.rs |
Persisted async task queue |
/autopilot drops a task; bot polls and updates the thread |
No refactor needed. The bot is a new client of the existing API surface.
Three platform options
| Platform |
Reach |
Capabilities |
Effort |
Priority |
| Feishu / Lark |
China tech/startup dominant; Lark = global/SEA via ByteDance |
Best bot SDK, native code-block rendering, file uploads, rich threading, mobile + desktop |
Medium |
First |
| WeChat Mini Program |
Mass market — every phone has WeChat |
Sandboxed: no shell, no filesystem, restricted networking. Best as mobile remote for autopilot sessions on a backing host |
Medium-Large |
Second (pairs with A) |
| WeCom (企业微信) |
Enterprise/PM teams |
Architecturally same as Feishu; different SDK |
Small (fast follow) |
Third |
Feishu first: heaviest DeepSeek-user overlap, best SDK, global reach via Lark. WeChat Mini Program as the mobile companion — "kick off a task from desktop, supervise from your phone." WeCom as a fast follow for enterprise teams.
Technical approach
- Webhook receiver — Feishu sends message events to a configurable endpoint. The bot receives
@mention and /command triggers.
- Session mapping — Feishu thread ID ↔ runtime thread ID. One-to-one, persisted via
runtime_threads.rs.
- Message translation — Feishu rich text → internal
Message format. Bot responses → Feishu card messages (code blocks, diffs, progress).
- Streaming — SSE from
runtime_api.rs → incremental Feishu message edits (reply-and-edit pattern).
- Voice → text → prompt — Feishu already transcribes voice messages. Bot receives the transcription as text.
- File pass-through — Files uploaded to Feishu thread → workspace attachment (within sandbox policy).
Scope
v0.8.15: Feishu bot proof-of-concept. Single-thread, single-user. @mention → agent responds in-thread. No voice, no file upload, no multi-user yet.
v0.8.16+: Voice transcription passthrough, file upload, WeChat Mini Program remote, multi-user thread awareness.
Summary
Ship a Feishu/Lark bot that exposes DeepSeek TUI as a chat-platform participant. Not a new backend — a thin webhook layer over the existing
runtime_api.rs/runtime_threads.rs/task_manager.rsstack. The TUI is one frontend; a Feishu bot is another.Why chat platforms
DeepSeek's user base lives in Feishu / WeCom / WeChat, not in terminals. A TUI asks a Chinese knowledge worker to leave their workflow. Specs are in Feishu Docs, discussion in chat threads, voice notes are real input, code review often happens in-thread before Gitee. The task already lives in chat — putting the agent there isn't distribution, it's meeting users where the work is.
Why the "driving" metaphor works better in chat
In a TUI, co-presence requires inventing dashboard panels and ghost cursors. In a chat thread, co-presence is the default:
@mentionfor an assist/commandfor a focused taskWhy the backend is already built
runtime_api.rsruntime_threads.rstask_manager.rs/autopilotdrops a task; bot polls and updates the threadNo refactor needed. The bot is a new client of the existing API surface.
Three platform options
Feishu first: heaviest DeepSeek-user overlap, best SDK, global reach via Lark. WeChat Mini Program as the mobile companion — "kick off a task from desktop, supervise from your phone." WeCom as a fast follow for enterprise teams.
Technical approach
@mentionand/commandtriggers.runtime_threads.rs.Messageformat. Bot responses → Feishu card messages (code blocks, diffs, progress).runtime_api.rs→ incremental Feishu message edits (reply-and-edit pattern).Scope
v0.8.15: Feishu bot proof-of-concept. Single-thread, single-user.
@mention→ agent responds in-thread. No voice, no file upload, no multi-user yet.v0.8.16+: Voice transcription passthrough, file upload, WeChat Mini Program remote, multi-user thread awareness.