Appearance
需求拆解
用户目标
用户希望扩展现有的 Telegram 机器人功能，使其具备以下核心能力：
进度监听与通知：机器人需要监听 OpenCode 执行过程，实时捕获进度信息，并按照预定义的策略将信息发送给 Telegram 应用端。
进程控制：增加一个机器人指令，当接收到该指令后，能够终止服务器上运行的 OpenCode 进程。
工作流程分析
当前系统的工作流程是：
- 用户通过 Telegram 发送消息
- Bun 启动的 Telegram 机器人接收消息
- 机器人调用
opencode --prompt=<指令>启动 OpenCode - OpenCode 执行任务并返回结果
期望的工作流程是：
- 用户通过 Telegram 发送消息
- Telegram 机器人接收并启动 OpenCode 进程
- 机器人监听 OpenCode 的输出流（stdout/stderr）
- 根据预定义策略，将 OpenCode 的执行进度、结果或错误发送回 Telegram
- 用户可以发送特定指令（如
/kill）来终止正在运行的 OpenCode 进程 - 机器人接收到终止指令后，强制杀死对应的 OpenCode 进程
关键路径
路径一：OpenCode 进程输出监听
这是整个系统的核心挑战。要实现进度监听，需要解决以下技术问题：
输出捕获：OpenCode 作为独立的子进程运行，需要捕获其标准输出（stdout）和标准错误输出（stderr）流。
实时解析：OpenCode 的输出是持续不断的文本流，需要实时解析这些输出以识别关键的进度信息、状态变化和最终结果。
信息过滤与策略：并非所有输出都需要发送到 Telegram。需要实现智能过滤策略，避免发送过多冗余信息，同时确保重要信息不遗漏。
消息格式化：将 OpenCode 的原始输出转换为适合 Telegram 展示的格式（考虑消息长度限制、Markdown 格式等）。
路径二：进程生命周期管理
要实现进程控制功能，需要解决以下问题：
进程追踪：当机器人启动 OpenCode 进程后，需要持久化存储进程 ID（PID）或进程句柄，以便后续终止操作。
多会话管理：如果支持多个并发 OpenCode 会话（根据 OpenCode 的多会话特性），需要管理多个进程 ID，并确保终止指令能够正确对应到目标进程。
权限与安全：确保只有授权用户能够执行终止操作，防止恶意行为导致系统中断。
优雅关闭：尽可能先尝试优雅终止（SIGTERM），失败后再强制终止（SIGKILL）。
核心挑战
挑战一：OpenCode 输出格式不确定性
OpenCode 的输出格式可能是多变的：
- 某些信息输出到 stdout，某些输出到 stderr
- 输出可能包含 ANSI 颜色代码、进度条等控制字符
- 输出内容可能非常长（完整的代码变更、文件内容等）
这给信息过滤和格式化带来了挑战。需要设计鲁棒的解析策略，能够适应不同类型的输出。
挑战二：Telegram 消息限制
Telegram Bot API 有以下限制：
- 单条消息最大长度为 4096 字符
- 频繁发送消息可能触发速率限制
- Markdown 格式需要正确转义
需要实现消息分割、节流和格式化机制，确保 OpenCode 的输出能够安全、完整地传递到 Telegram。
挑战三：进程状态同步
当 OpenCode 进程执行时间较长时，可能出现以下问题：
- 机器人进程崩溃后，OpenCode 进程仍在运行
- 终止指令时无法确认目标进程是否仍然存在
- 多个 OpenCode 进程同时运行时，难以准确追踪
需要设计可靠的进程状态管理机制，包括进程启动时的注册、运行时的监控、异常时的清理。
边界条件
功能边界
本方案的目标是实现 OpenCode 进程的基本监听和控制，但不包括：
- OpenCode 内部执行的深度分析（如解析工具调用、文件操作等）
- 复杂的进度条可视化
- 多用户权限管理（基础权限控制除外）
- 历史记录查询
技术边界
- OpenCode 本身不提供程序化的进度回调 API（假设情况）
- 依赖系统级进程管理（通过 Bun 的 child_process）
- 通过 stdout/stderr 流获取信息，而非 API 轮询
非功能性需求
- 性能：监听和控制不应显著影响 OpenCode 的执行效率
- 可靠性：即使监听机制失败，OpenCode 的核心功能不应受影响
- 可维护性：代码结构清晰，便于后续扩展新的监听策略或控制指令
参考资料
- OpenCode GitHub Repository - OpenCode 开源代码仓库
- OpenCode Official Website - OpenCode 官方网站