> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 多 Agent 编排：Triglav 的 Staff/Senior/Reviewer 与 41 个任务复盘
- URL: https://www.hubwiz.com/blog/triglav-multi-agent-orchestration/
- Published: 2026-10-17T12:42:54.000Z
- Updated: 2026-10-17T12:50:42.000Z
- Description: 10 天 41 个任务、34 个完成。Triglav 用三层评审编排 Claude Code 与 Codex，也暴露了长跑 Agent 的账单。
- Author: admin
- Tags: AI 编程, 多 Agent, Claude Code, Codex

**一句话结论**：多 Agent 编程的难点不在"让 Agent 写代码"，而在**长任务里的协调与质量控制**——谁盯目标、谁解决悬而未决的问题、谁审改动、谁确认验收标准。2026 年 10 月开源的 Triglav 给了一个具体答案：把 Claude Code 和 Codex 组织成一家**小软件咨询公司**——Staff 规划与派活，Senior 各自实现并开 PR，Researcher 只给建议，Reviewer 分层评审，而你（Client）只批准计划、回答升级问题、合并代码。作者在自己仓库上跑了 10 天：**41 个任务，完成 34 个**。它也把长跑 Agent 的真实成本与坑写了出来：前六天所有 Agent 合计**输出约 360 万 token、从 prompt cache 读取约 36 亿 token**，比例约 **1:1000**。

**披露**：本文编译自 Triglav 作者 Adam Drag 的发布文（dev.to，2026-10-17）。Triglav 采用 Business Source License 1.1（源码可见、可自用，不可作为托管/托管服务转售，每个版本四年后转 GPL-2.0-or-later），作者是项目维护者；文中数字来自作者一人在自己仓库上的使用，样本有限。

---

## 一、它解决的不是"写代码"，而是"交付"

AI 编程 Agent 已经能写代码。更长的任务仍然需要协调与质量控制：有人要盯住目标、敲定悬而未决的问题、评审改动、确认完成的工作满足验收标准。

Triglav 把这套工作流包在 Claude Code 和 Codex 外面：

- **Staff** 规划并分派任务；
- **Senior** 实现各自的任务；
- **共享任务板**让 Agent 提问、咨询 Researcher、质疑提案、记录决定；
- **本地评审团**在交付前检查每个改动；
- 之后是配置了的话走 **Copilot 评审**，再由 Staff 自己跑 **CI 检查**；
- **你是 Client**：回答团队解决不了的问题，决定什么能上线。

名字来自斯拉夫神话的三头神 Triglav，最早三个角色是 Staff、Senior、Researcher，Reviewer 是后来加的。**所有动作都通过 Triglav 的 MCP 工具执行，因此全部有记录**，仪表盘只是这份记录的一个视图。

一个必须先说清的成本事实：**它用你自己的 Claude Code / Codex 账号**。Triglav 不含模型、不调 AI API、不要 API key，只负责启动和协调你已经登录的 CLI。每一次 Agent 回合、每个 Senior、每次本地代码评审、每次 Researcher 运行、每条 Operator 消息，都是你账号上的一次请求；超出套餐就按你的计费方式算。Copilot 评审循环还可能消耗你的 GitHub Copilot 配额。

## 二、角色与任务板

| 角色             | 是什么                          | 权限/职责                                         |
| -------------- | ---------------------------- | --------------------------------------------- |
| **Staff**      | 一个长跑的 Claude Code 或 Codex 会话 | 读 ticket、规划、写验收标准、启动 Senior、自己核 CI            |
| **Senior**     | Staff 的子 Agent               | 每人一个任务、独立 git worktree、开 PR；最多 2 个/任务、总共 10 个 |
| **Researcher** | 短时运行                         | 读任务板、给建议；不拥有任何代码                              |
| **Reviewer**   | 只读评审                         | 检查 Senior 提交的改动                               |
| **Client（你）**  | 人                            | 批准计划、回答升级、合并                                  |

### 任务板才是核心

Senior 遇到不确定的事，**不会悄悄选一个**，而是在任务板上开一个**限时问题**。问题必须自带上下文：所属任务、验收标准、正在等待的工作、已经考虑过的选项。这样即使一个从未看过该任务的 Researcher 也能给出有用回答。

Staff 和 Researcher 用"立场"回复，比如支持或质疑；**任何不是单纯评论的回复都必须给理由**。Senior 会等完整个回复窗口，即使 Staff 十秒就答完。**没人回复，窗口就延长。**

窗口关闭后，Staff 记录一个有约束力的决定，并列出它考虑过的每一条回复。**迟到的回复会被保留并标记为迟到**；如果迟到回复改变了结论，Staff 必须记录一个**取代旧决定的新决定**——它不能悄悄改主意。

任务板把问题、论据、最终决定和任务存在一起，事后可以查推理过程，不用从多个 Agent 会话里拼。

## 三、一个任务的完整流程

1. **定义目标。** 从 Linear、Jira、GitHub issue 链接或一句提示开始。提示任务先进入 refine 阶段：Staff 把它变成目标、范围、非目标、验收标准，并提出开放问题——**每个问题都带一个建议答案**。你回答、修改，直到满意。**只有你点 Approve，规划才开始；Staff 不能批准自己的提案。**
2. **分派与咨询。** Staff 拆活、给每个 Senior 写 brief 并启动，最多 2 个/任务、总共 10 个。Senior 用 **lease（租约）**持有任务；停止续租，Staff 会启动新的尝试，**旧的被 fence 掉**（隔离，避免两个 Agent 同时写同一任务）。问题进任务板。
3. **评审与修复。** 交付前，每个改动走三层评审。
4. **验证与升级。** **只有当 Staff 自己在 Senior 报告的那个 commit 上核过 CI，任务才算完成。** 团队决定不了的事，升级成你的决定。

## 四、三层评审：门在服务端，不在提示词里

### 第 1 层：本地评审团

Senior 请求评审自己的 commit 范围。一个只读评审团读 diff 和仓库。发布默认是 **Codex 上的 GPT-6.1-Sol 坐"强评审"席，Claude Code 上的 Sonnet 5.5 做廉价第二意见**——让一个模型家族检查另一个模型家族的工作。评审团是 Client 设置。

服务端强制执行这道门：

- 除非**恰好针对那个 commit** 的评审已完成且结论为 `ok`，否则 `submit_review_package` 和 Copilot 评审请求**会被拒绝**；
- 一个任务最多 **3 轮**本地评审，之后每一轮**只评审修复部分**；
- 一个任务的各次评审范围从 merge base 起形成**一条链**，两次评审之间不能跳过 commit；
- 评审器崩溃或返回不可读内容 → 该轮**失败**，**失败的轮次永远不算通过**。

到目前为止评审团完成了 **96 轮：54 轮通过、42 轮要求修改**。这说明门确实在被使用；但它**不衡量评审器有多准**。仓库里有一个评测 harness，在 Triglav 自己的 PR 上重放评审团，并与 Copilot 的发现对比——Copilot 在这里只是基准，匹配也不证明发现正确。

### 第 2 层：Copilot

每个 PR 最多 **3 轮** Copilot 评审。这一层是否运行由 Client 设置：

- `auto`：仓库有 Copilot 就用；
- `Copilot required`：没有干净的 Copilot 评审就拒绝交付；
- `CI only`：跳过。

**服务器自己不能运行 `gh`**，所以它依赖 Senior 自己报告每一轮结果。

### 第 3 层：Staff 核 CI

Staff 在标记完成前，自己在**报告的那个 commit** 上检查 CI。

## 五、升级到人：决定卡而不是聊天记录

大多数问题到不了你这里，Staff 自己处理普通工程问题。真正需要你时，它提出一个 **decision**，包含：问题、提问、建议、你需要运行的命令（每条带 Copy 按钮）、Researcher 的建议。

同意就一键 **Accept recommendation**。未决决定的数量显示在浏览器标签上，你可以去做别的事，同时知道团队在等你。

还有一个 **Operator** 页面：一个 Claude Code 聊天，用来问"这个任务为什么卡住了？"。它**只能读，不能改**；想执行动作时，会在聊天里放一张卡片等你 Confirm。

## 六、作者真实踩过的坑

连续跑几天而不是几分钟，会出现单次会话没有的问题：

### 1\. 用量上限与重复会话

一个 Staff 撞上用量上限。上限重置后，Claude Code 自己用新的 session id 继续了会话；作者也 resume 了一次——**于是两个 Staff 在管理同一个任务**。现在 runner 在恢复会话前，会先检查是否已有运行中的副本。

### 2\. 唤醒比写代码更贵

前六天，所有 Agent 合计写了约 **360 万输出 token**，却从 prompt cache 读取了约 **36 亿 token**，大约 **1000:1**。每次一个等待中的 Agent 被唤醒，它都要重读整个上下文；对一个 Staff 来说，常常是 **30 万到 70 万 token**。所以现在：

- Staff **只为需要它的事件**醒来；
- 每次调用最多等 **50 分钟**（在它一小时的 prompt cache 内）；
- Researcher 完全不等待：有东西可读时才启动，答完就退出。

### 3\. 上下文大小

Staff 在约 **28 万 token** 时压缩上下文。Claude Code 对 Opus 的默认值是约 **98 万**，所以一个长跑的 Staff 从不压缩，一直在重读不断增长的上下文。

## 七、权限与安全边界

- **合并、部署、force push、仓库设置永远归 Client。** Agent 被要求不做这些，但那只是指令——**仍然要在 GitHub 上保护分支**。
- 服务器跑在 Docker 里，**不能在宿主机上启动进程**。一个小的 host runner 负责执行；它**从不执行来自服务器的命令字符串**，每条命令都由它自己构建，并逐字段校验。Reviewer、Researcher、Operator 都只能读。
- **Agent 以你的操作系统用户身份运行**，所以一个铁了心的 Agent 可以读 `.env`。README 明确写了这一点，以及安全模型没有覆盖的其它内容。

## 八、上手与成本提醒

需要 Docker、Node 24、pnpm，以及 Claude Code 或 Codex（作者只在 Linux 上跑过）：

```bash
git clone https://github.com/adam-drag/triglav.git
cd triglav
pnpm install --frozen-lockfile
node scripts/setup.ts          # 随机密钥 + 仪表盘密码
docker compose up -d --build   # server、MySQL、dashboard 在 :7400
node scripts/runner.ts         # host runner

```

把 Agent 接到 MCP endpoint（README 里有一行 `claude mcp add-json`），打开 `localhost:7400`，点 **New job**。Triglav 使用你已有的 `claude` 与 `codex` CLI，并读取它们列出的模型。

**第一个任务就去看 Usage 页面**：每个 Agent 回合和每次评审都是你账号上的请求，而 Staff 会**不问你就启动 Senior**。如果你只让 Staff 跑在 Codex 上，它可以写仓库、能看到你的 `GITHUB_TOKEN`，唯一的检查是 Codex 自带的评审器——这种组合只该用在你能放心交给它的仓库上。

## 九、这套编排买到了什么，没买到什么

**买到的：**

- **可追溯**：问题、立场、理由、决定、迟到回复、被取代的决定，全在同一条记录里；
- **可执行的门**：评审 `ok` 是服务端状态，不是提示词里的请求；commit 链连续、失败轮次不算通过；
- **人的位置明确**：批准、升级、合并三个动作留给人；
- **长跑可用**：lease + fencing、按事件唤醒、显式压缩阈值。

**没买到的：**

- **评审器准确性**：96 轮只证明门被使用，不证明评审对；
- **模型能力**：它不提供模型，能力上限仍是你账号里的 Claude/Codex；
- **安全隔离**：Agent 仍是你的 OS 用户，`.env` 仍可读；
- **跨平台验证**：作者只在 Linux 上运行过；
- **许可自由度**：BSL 1.1，不是 OSI 开源。

## 十、给准备上多 Agent 编排的团队：六个检查点

| 检查点          | 问什么              | Triglav 的做法            |
| ------------ | ---------------- | ---------------------- |
| 目标由谁批准       | Agent 能否批准自己的计划？ | 只有 Client 能 Approve    |
| 并发怎么写同一任务    | 两个 Agent 同时写怎么办？ | lease + fencing，旧尝试被隔离 |
| 决定怎么留痕       | 争论结束后还剩什么？       | 任务板：问题、立场、理由、决定、迟到标记   |
| 评审是不是硬门      | 评审失败能不能被绕过？      | 服务端拒绝提交，失败轮次不算过        |
| 验证在哪个 commit | CI 跑的是不是交付的那个？   | Staff 在报告 commit 上自己核  |
| 成本从哪来        | 谁在为唤醒付费？         | 按事件唤醒、50 分钟缓存窗口、28 万压缩 |

一句话总结：**多 Agent 编排卖的不是"更聪明"，而是"可追溯 + 可验证"**。如果你只想要一个能写代码的 Agent，单会话就够了；如果你要的是"连续跑几天、交付物能交代清楚"，那值得把上面六个检查点逐条对上。

---

**Sources**

- Adam Drag, *Triglav: orchestrating Claude Code and Codex agents for long-running work and layered review*, dev.to, 2026-10-17：[https://dev.to/adamdrag/triglav-orchestrating-claude-code-and-codex-agents-for-long-running-work-and-layered-review-4npe](https://dev.to/adamdrag/triglav-orchestrating-claude-code-and-codex-agents-for-long-running-work-and-layered-review-4npe?ref=hubwiz.com)
- 项目仓库（BSL 1.1）：[https://github.com/adam-drag/triglav](https://github.com/adam-drag/triglav?ref=hubwiz.com)

**相关阅读**：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/) ｜ [子代理交接：compaction / subagent / fold 三种做法](https://www.hubwiz.com/blog/subagent-fork-fold-context-handoff/) ｜ [28 个 Agent 六天自主循环复盘](https://www.hubwiz.com/blog/agent-loop-964-hours-goodbarber/)

本文由汇智网编译整理，转载请注明出处。文中使用数据来自作者一人在自己仓库上的 10 天实践，不代表普遍效果；成本按你自己的 Claude/Codex 套餐计算。

> **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)