Logo
热心市民王先生

需求拆解

技术研究 人工智能 OpenCode

阶段一：消息接收（仓库A - Telegram Bot） - 用户通过 Telegram 发送消息，格式为 - 仓库A的服务接收到该消息后，解析出研究主题（电动车行业现状） - 仓库A触发跨仓库执行机制，准备调用仓库B的研究能力

用户目标分析

核心工作流程

用户构建了一个跨仓库的自动化研究系统，具体工作流程如下：

阶段一：消息接收（仓库A - Telegram Bot）

  • 用户通过 Telegram 发送消息，格式为 /research 帮我调研电动车行业的现状
  • 仓库A的服务接收到该消息后，解析出研究主题（“电动车行业现状”）
  • 仓库A触发跨仓库执行机制，准备调用仓库B的研究能力

阶段二：研究执行（仓库B - Research）

  • 仓库A执行命令切换到仓库B的目录：cd /path/to/repo-B
  • 仓库A调用 opencode CLI 执行研究任务：opencode --prompt="帮我调研电动车行业现状"
  • opencode 在仓库B环境中运行，生成研究报告文档
  • 研究完成后，仓库B将生成的文档提交到 GitHub 仓库

阶段三：状态同步（关键瓶颈）

  • 当前问题：研究执行完毕后，仓库A无法自动感知任务完成状态
  • 期望行为：
    • 方案1：自动终止当前 opencode 进程，释放资源
    • 方案2：从仓库A触发 opencode 的 /new 方法，开启新对话会话
  • 核心需求：实现跨仓库的进程生命周期管理和会话状态同步

关键路径识别

本次研究的技术关键路径包含以下三个核心障碍：

障碍1：进程状态检测机制

  • opencode CLI 作为子进程运行时，如何可靠地检测其执行完成状态
  • 需要捕获进程的退出码（exit code），区分正常完成和异常退出
  • 跨仓库执行时，如何确保状态检测不依赖手动干预

障碍2：跨仓库通信协议

  • 仓库A（Telegram Bot）和仓库B（Research）运行在不同目录/环境中
  • 需要一个轻量级但可靠的通信机制来传递”研究完成”信号
  • 通信机制应支持携带状态信息（成功/失败）和可选的元数据

障碍3：进程清理或会话重置

  • 方案1要求能够定位并终止特定的 opencode 进程实例
  • 方案2要求能够程序化地触发 opencode 的新会话（/new 命令）
  • 两种方案都需要考虑并发场景（多个研究任务同时进行）

约束条件

技术限制

OpenCode CLI 的限制：

  • OpenCode 原生不提供进程生命周期钩子（Lifecycle hooks），无法通过回调函数感知任务完成
  • 官方文档中未提及 onComplete、onFailure 等事件监听机制
  • 没有暴露用于进程间通信（IPC）的 API 接口
  • 不支持跨会话的状态管理，每个 opencode 进程是独立的执行环境

跨仓库执行的复杂性：

  • 仓库A通过 cd 和命令执行触发仓库B的操作，这是一种松耦合的调用方式
  • 两个仓库之间没有直接的编程接口（API）调用机制
  • 跨目录执行时，环境变量和工作目录的隔离增加了状态同步的难度

进程管理的限制：

  • Linux/Unix 系统中，孤儿进程（orphan process）可能被 init 系统接管
  • 如果 opencode 进程创建了子进程（如 git 提交操作），简单的进程终止可能不彻底
  • 并发执行多个研究任务时，需要精确标识目标进程（通过 PID 或进程名匹配）

业务需求

自动化程度要求：

  • 整个流程必须完全自动化，从消息接收到研究完成通知不应需要人工干预
  • 用户期望的延迟在秒级（从发送消息到收到完成通知）
  • 失败时应有明确的错误通知，而不是静默失败

实时性要求：

  • 研究任务的执行时间不确定（可能从几秒到几十分钟），需要一个非阻塞的异步通知机制
  • Telegram Bot 的超时限制需要考虑（Webhook 方式通常有 60 秒超时）

可靠性要求：

  • 即使研究任务失败（如 opencode 报错、网络问题），也应发送通知告知用户
  • 系统应具备幂等性：如果通知发送失败，应有重试机制
  • 需要日志记录机制以便排查问题（记录每个研究任务的开始时间、结束时间、状态）

参考资料