背景
code-bee 的定位应当保持极简:它不是平台控制器,也不负责替编码智能体读取 Issue、回复 Issue 或判断是否开工。
目标
实现一个极简调度器:
code-bee 只负责告诉编码智能体去哪里查看 Issue
code-bee 只负责告诉编码智能体当前平台可用什么工具
- 读取 Issue、回复 Issue、判断是否接单、是否开工、如何开发,全部由编码智能体自己完成
code-bee 只做最小轮询:如果智能体确认完成,则退出;否则继续下一轮
职责边界
1. code-bee 负责
- 接收
repo 和 issue 参数
- 给编码智能体下发任务
- 提供平台技能包说明
- 轮询智能体是否已完成
2. 编码智能体负责
- 自己查看 Issue
- 自己调用平台工具(如 GitHub 下的
gh)
- 自己回复接单确认或阻塞说明
- 自己完成开发、自验、提 PR
- 自己判断当前是否已经完成
平台技能包
internal/platform 的职责不是封装平台操作细节,而是提供“平台技能包接口”。
也就是说:
- 平台层只告诉编码智能体“你在这个平台可以使用哪些工具”
- 具体如何调用这些工具,由编码智能体自己决定和执行
例如在 GitHub 平台下,可以告诉智能体:
- 如何使用
gh issue view
- 如何使用
gh issue comment
- 如何使用
gh pr create
但这些命令不应由 code-bee 代替执行。
验收标准
背景
code-bee的定位应当保持极简:它不是平台控制器,也不负责替编码智能体读取 Issue、回复 Issue 或判断是否开工。目标
实现一个极简调度器:
code-bee只负责告诉编码智能体去哪里查看 Issuecode-bee只负责告诉编码智能体当前平台可用什么工具code-bee只做最小轮询:如果智能体确认完成,则退出;否则继续下一轮职责边界
1. code-bee 负责
repo和issue参数2. 编码智能体负责
gh)平台技能包
internal/platform的职责不是封装平台操作细节,而是提供“平台技能包接口”。也就是说:
例如在 GitHub 平台下,可以告诉智能体:
gh issue viewgh issue commentgh pr create但这些命令不应由
code-bee代替执行。验收标准
code-bee不直接读取 Issue 内容code-bee不直接回复 Issuecode-bee不判断是否具备开工条件code-bee仅通过最小轮询判断智能体是否完成任务