循环的每一轮运行方式都一样,无论触发它的是 webhook、时钟,还是有人直接提及哥布林。本页讲的就是从触发到合并请求之间发生了什么。
1. 触发抵达
TaskGoblin 找到或创建这件工作的线程——一个 issue、一个合并请求或一个循环的对话——并把本轮记录为其中的一条消息。针对正在进行的工作的后续请求会并入已有线程,而不是另开一个。这就是哥布林从不要求你重新解释一遍的原因。
2. 沙箱启动
这次运行会拿到一个隔离的云端容器,里面有你仓库的检出。沙箱是持久的,并在同一线程的各轮之间复用,所以后续请求落进的环境里已经有仓库和上一轮的状态——哥布林是接着干,而不是从空盒子开始。
沙箱通常是预热好的,这就是为什么一次运行通常在几秒内就开始工作,而不用等冷启动容器。云端沙箱深入讲解隔离、持久化与自托管。
3. 先读,再写
在动代码之前,哥布林会收集上下文:触发它的 issue 或 diff、线程历史、上一个哥布林留下的交接笔记,以及你组织的约定。对事件循环来说,你的常驻指令会叠加在事件自身的上下文之上。
这一步区分了"有用的改动"和"看起来像那么回事的改动"。一个能看到上次改动是怎么被审查的、以及先前方案为何被回滚的智能体,比一个在空房间里起步的智能体做出更好的判断。
4. 由真正的编码智能体动手
沙箱里跑的是一个真正的编码智能体——Claude Code、Codex 或 Gemini,取决于本次运行使用的模型账号。它拥有开发者的工具:读写文件、执行命令、跑你的测试。它不是在自动补全一个 diff,而是在解决问题。
5. 分支、提交、推送、合并请求
哥布林遵循你团队已有的工作流:
- 它在专用分支上工作——GitLab 或 GitHub 上 issue 142 对应
142-taskgoblin,Jira 键对应proj-123-taskgoblin——绝不在你的默认分支上。 - 它提交并签署自己的工作,让痕迹清晰可读,然后推送分支。
- 它打开合并请求(GitLab)或拉取请求(GitHub),并把链接汇报回工作开始的地方。
例外是在现有合并请求上触发的运行:那种情况下它会推送到该 MR 自己的分支,而不是另开一个竞争分支。
因为产出是分支和合并请求,审查就还是你对人类贡献做的那件事。没有你的点头,什么都不会合并。
6. 它在你已经在看的地方汇报
运行过程中,哥布林通过这件工作所属的场所反馈:Linear issue 上的活动、合并请求上的行内评论、Slack 或 Teams 中一张会自我更新的卡片。你不用盯终端,也没有另一个需要你记得打开的面板。
7. 它记下发生了什么
哥布林做的最后一件事——在回复发出之后,绝不在之前——是记录一份交接笔记:学到了什么、决定了什么、还有什么悬而未决。下一轮会先读它。
这就是循环会累积而不是重复的原因。参见大脑。
密钥不进入智能体
哥布林从不会看到你的凭据。沙箱内的 git 访问在运行时按组织下发——GitLab OAuth 令牌,或新签发的 GitHub 安装令牌——并注入到智能体周围的环境中,而不是交给它读取。它能使用克隆和推送所需的访问权限,而你的密钥从不会进入它的上下文或记录。
那个令牌仅用于 git 传输。评论、审查和 issue 更新都走 TaskGoblin 自己的集成,这样它们是以哥布林的身份发布,而不是以你的身份。
出错的时候
失败的运行不会凭空消失。哥布林会在你触发它的那个场所把情况说清楚,失败被记录在这次运行上,交接笔记也会带上它撞到的那堵墙,好让下一轮不必重新发现。一个从未拿到沙箱的运行——比如因额度耗尽而被拦下——永远不计费。