基于gitlab的multi-agent开发平台探讨

fwerkor · 2026 年7 月 31 日 06:28

本帖用于开发进度标注与想法征集。

起因是一次 gpt 降智，让我们意识到整天玩 lsm 不是长久之计，并且因 dpskv4 的一些传闻而产生了对国模崛起的期待。

我想把gitlab issue/pr 那套管理人类的架构应用于agents，给每个agent一个账号，承担coding、approve之类的任务，人类只要提issue、assign，就可以清晰地看着复杂任务被拆解、逐步完成（甚至可以更好地亲自review）。

fwerkor · 2026 年7 月 31 日 06:35

先附上一份gpt的设计（与我的设计理念尚有出入，我是打算agent数量完全基于你有几个后端，而不是你有几类任务）。

总体判断

这套平台可行，而且可以定位成 “GitLab 作为协作状态机，LSM Remote 作为执行基础设施，Harness Adapter 作为 Agent 运行层”。

不建议重新实现一套 Issue、MR、代码审查和权限系统。GitLab 负责：

任务与讨论：Issue、Epic、Comment
工作成果：Branch、Commit、Merge Request
协作关系：Assignee、Reviewer、Mention
权限边界：Group、Project、Role、Protected Branch
自动化入口：Webhook、System Hook、Pipeline
Agent 身份和审计归属

你的平台主要负责事件路由、Agent 调度、Harness 生命周期、Remote 资源管理和凭据控制。

一个重要的身份设计问题

每个 Agent 使用 GitLab Service Account

GitLab 18.11 起，Service Account 已进入 Free 版；自托管 Free 实例最多可以创建 100 个。它可以拥有独立用户名、项目成员身份、PAT、SSH Key，并执行 Git 操作和 API 操作，正适合“一 Agent 一账号”。

例如：

@agent-planner
@agent-developer
@agent-reviewer
@agent-ci-fixer
@agent-release

但 Service Account 不能登录 GitLab Web UI。它只能通过 Token、SSH、Git 和 API 操作。

因此，“模型登录自己的账号”应定义成：

Agent Runtime
 ├── 以自己的 SSH Key 执行 git clone/push
 ├── 以自己的 API Token 操作 Issue/MR/Comment/Pipeline
 ├── 设置自己的 Git commit identity
 └── 所有 GitLab 行为归属自己的 Service Account

不应让模型填写网页用户名和密码、操作浏览器 UI。绝大部分 GitLab 功能都有 API；浏览器自动化更脆弱，也很难安全限制权限。

人类在无 UI 的机器上登录可以使用 GitLab OAuth Device Flow，但它需要人类在另一台设备上确认，适合 CLI 登录，不适合作为无人值守 Agent 的长期身份机制。

被动触发机制

GitLab Webhook 可以实时发送 Issue、MR、Comment、Push 和 Pipeline 等事件；自托管实例还可以使用 System Hook 监听全实例事件。

建议支持以下触发方式：

触发动作	目标 Agent
Issue 指派给 `@agent-developer`	开发 Agent
评论中 `@agent-reviewer`	审查 Agent
MR Reviewer 指派给 Agent	Code Review Agent
Pipeline 失败	CI Fixer
添加 `agent::plan` Label	Planner
定时任务	Dependency/Release Agent
MR 出现冲突	Rebase/Conflict Agent
Agent 评论中提及另一个 Agent	Agent 间委派

GitLab 自己的 External Agent 功能已经采用了“Mention、Assign、Assign Reviewer 等事件触发 Service Account”的思路，说明这个交互模型与 GitLab 本身是契合的。

Webhook 接收端必须实现：

签名或 Secret 校验
事件持久化
幂等键
重复事件去重
重试
死信队列
项目与事件过滤

GitLab 19.0 已加入 Webhook 签名机制，用于校验来源、内容完整性并降低重放风险；兼容旧版本时可以回退到 X-Gitlab-Token。

Agent 定义格式

每个 Agent 使用一份版本化配置：

apiVersion: agents.fwerkor.com/v1
kind: Agent

metadata:
  name: developer
  displayName: Developer Agent

identity:
  gitlabServiceAccount: agent-developer

harness:
  driver: codex
  image: registry.example.com/agents/codex:latest
  modelProfile: coding-large
  maxRuntime: 45m

triggers:
  - event: issue.assigned
  - event: comment.mentioned
  - event: pipeline.failed
    filters:
      labels:
        anyOf: [agent::autofix]

permissions:
  gitlab:
    projects:
      - group/backend/*
    maxRole: developer
  actions:
    allow:
      - repository.read
      - repository.write_branch
      - merge_request.create
      - issue.comment
      - pipeline.read
    deny:
      - protected_branch.push
      - merge_request.merge
      - project.settings.write

workspace:
  branchPattern: "agent/${agent}/${issue}-${run}"
  cleanup: on-success

remotes:
  selectors:
    - "type=development"
    - "arch=x86_64"
  denySelectors:
    - "environment=production"

completion:
  createMergeRequest: true
  commentOnIssue: true
  assignReviewer: agent-reviewer

这样新增 Harness 或模型时，不需要修改调度器核心。

Harness 接入层

不要让平台绑定某个具体 Agent CLI。定义一个较小的 Harness Driver 接口：

Prepare(runSpec) -> workspace
Start(workspace, goal, credentials)
SendInput(runID, message)
Inspect(runID) -> status/events
Interrupt(runID)
Resume(runID, checkpoint)
CollectArtifacts(runID)
Destroy(runID)

不同实现分别适配：

harness-codex
harness-claude-code
harness-openhands
harness-aider
harness-lsm
harness-custom

统一事件输出：

{
  "type": "tool.finished",
  "run_id": "run_123",
  "tool": "gitlab.create_merge_request",
  "result": "success",
  "timestamp": "..."
}

Harness 本身只处理：

模型会话
工具调用
上下文压缩
Checkpoint
工作目录
Agent 循环

控制面处理：

Agent 选择
权限
身份
Remote 调度
凭据
任务状态
审计

Remote 管理：直接复用 LSM 思路

这部分不应只是“远程 SSH 主机列表”，而应抽象成受控执行资源。

Remote 数据模型

Remote
  id
  name
  endpoint
  labels
  capabilities
  status
  owner
  visibility
  concurrency_limit

RemoteGrant
  principal_type: user | agent | group | project
  principal_id
  remote_id
  role: view | use | operate | administer
  constraints

RemoteLease
  remote_id
  task_id
  agent_id
  exclusive
  expires_at
  resource_request

CredentialRef
  remote_id
  vault_path
  allowed_agent_ids

Remote Capability

shell
files
process
git
docker
incus
gpu
npu
qemu
network
sudo

权限可以细化成：

agent-developer:
  use shell/files/git
  cannot sudo
  cannot restart host

agent-ci-fixer:
  use docker/qemu
  cannot access production

agent-release:
  use production deployment
  requires human approval

agent-admin:
  manage remote configuration

连接方式

建议 Remote Daemon 主动反连控制面：

Remote Daemon ──mTLS/WebSocket/QUIC──> Control Plane

优点：

Remote 不需要开放入站端口
适合 NAT 和动态地址
可以持续上报负载与能力
可以建立审计流
可在平台中统一撤销权限

最合适的实现方式是把 LSM 的 Remote 层抽成独立协议和 SDK：

lsm-remote-protocol
lsm-remote-daemon
lsm-remote-client

原 LSM 和新 Agent 平台都依赖这一层。这样 Remote、文件传输、Terminal、Audit、认证和断线重连不用维护两份。

多 Agent 协作方式

不建议首先构建一个独立的“Agent 群聊”。GitLab 本身就是共享工作区。

典型工作流：

1. 用户创建 Issue，添加 agent::develop
2. Planner Agent 输出实施方案并拆分子 Issue
3. Developer Agent 被指派，创建独立分支
4. Developer 推送并创建 MR
5. Reviewer Agent 自动成为 Reviewer
6. Reviewer 留下 inline comments
7. Developer Agent 根据评论继续提交
8. CI Fixer 在 Pipeline 失败时被触发
9. MR 满足规则后由人类或 Merge Agent 合并
10. Release Agent 根据里程碑执行发布

Agent 之间通过以下 GitLab 原语协作：

Issue assignment
@mention
Reviewer request
Label
Blocking/related Issue
MR comment
Commit status
Pipeline artifact

这会天然保留完整的过程记录，也方便人类中途接管。

权限模型

建议采用类似 GitLab Composite Identity 的交集权限：

实际权限 =
    Agent 被授予的权限
  ∩ 触发者拥有的权限
  ∩ 当前项目策略
  ∩ 当前 Remote 策略

GitLab 自己的 Composite Identity 也是将触发者身份与 Service Account 身份结合，并使用更受限的一侧，防止 Agent 借触发者或机器账号进行权限提升。

例如：

Agent 能访问 Project A、B
用户只能访问 Project A

用户触发该 Agent 时：
  可以操作 A
  不能借 Agent 操作 B

系统级自动任务没有人类触发者时，则绑定一个明确的 Automation Principal，而不是假装由管理员触发。

分支和合并安全

所有写代码的 Agent：

只能推送 agent/<agent-name>/*
不能直接推送 main
不能修改 Protected Branch 规则
默认不能 merge

GitLab Protected Branch 可以禁止直接 Push，并强制通过 MR 流程。

推荐默认规则：

main:
  direct push: nobody
  merge: maintainers
  force push: disabled

agent/*:
  push: corresponding agent
  merge: nobody

release/*:
  push: release agent
  merge: maintainers

开发者 Agent 与 Reviewer Agent必须使用不同账号。至少在逻辑上禁止一个 Agent 审批自己创建的 MR。

部署形态

MVP 不使用 Kubernetes

建议先提供一个 Docker Compose：

agent-platform
postgres
nats-or-redis
worker
remote-gateway
caddy

GitLab 可以：

使用已有 GitLab 实例；
通过可选的 --profile bundled-gitlab 一起部署 GitLab；
接入 GitLab.com，但 Service Account、系统 Hook 和自定义能力会有所区别。

控制面最好做成一个单体服务，Worker 独立扩展：

control-plane: Go 或 Rust 单体
database: PostgreSQL
queue: NATS JetStream
frontend: React/Vite，编译后嵌入单体
worker: OCI container
secrets: 初期加密数据库，正式环境接 Vault

保持：

docker compose up -d

即可运行。

后续再增加：

Kubernetes Worker
多节点调度
Remote GPU/NPU 资源调度
高可用控制面
外部 Vault
OIDC 和企业 SSO

MVP 范围

第一阶段：最小闭环

实现：

连接现有 GitLab。
自动创建和配置 Service Account。
一个 Issue 指派触发器。
一个通用 Harness Adapter。
独立工作目录或 Git Worktree。
Agent 创建分支、提交代码、创建 MR。
LSM Remote 作为执行目标。
Web UI 查看任务状态、日志与 Remote。
Agent、Project、Remote 三者之间的 RBAC。
手动终止和人工接管。

第二阶段：多 Agent

加入：

Planner、Developer、Reviewer、CI Fixer
Agent 间 Mention
MR Review 循环
Pipeline 失败自动触发
Remote Lease 与并发调度
Checkpoint/Resume
完整 Audit

第三阶段：平台化

加入：

Agent Catalog
Harness Marketplace
Model Profile
预算和 Token 限制
组织级 Policy
Secret Broker
Composite Authorization
GitLab 原生 External Agent 兼容层

不建议直接依赖 GitLab Duo External Agent

GitLab 已经提供 External Agent、AI Catalog、Service Account 和 Trigger 等能力，但自托管 Custom External Agent 在部分版本仍受 Feature Flag 控制，并与 GitLab Duo 的配置、Runner 和身份体系绑定。

可以把它作为一个兼容后端：

Native Webhook Backend       默认
GitLab Duo External Backend  可选
GitLab CI Backend            可选

这样平台不会被 GitLab 的 AI 产品路线锁定，同时仍然可以逐渐接入其 Composite Identity 和原生 Agent UI。

最终产品形态

我认为它适合做成：

GitLab Agent Fabric

核心对象只有六类：

Agent
Harness
Task
Project
Remote
Policy

其中最关键的技术取舍是：

GitLab 管理协作与身份；控制面负责调度和权限；Harness 负责模型执行；LSM Remote 负责真实机器。

这样既可以作为 LSM 的上层多智能体平台，也可以独立接入其他 Remote 和 Harness，部署复杂度不会迅速失控。

Dr_osrin · 2026 年8 月 1 日 10:59

嗯……感觉就是一个基于gitlab的agent-subagent？至少GPT的方案看上去就是这样

fwerkor · 2026 年8 月 1 日 12:33

是这样，就这么简单

lsamc · 2026 年8 月 2 日 03:57

可是这么玩的话，就不是免费了

fwerkor · 2026 年8 月 2 日 04:01

所以要想办法让lsm能参与其中。架构设计上需要注意。

这也是这套系统很可能有别于其它系统的地方