多 Agent 编排：Triglav 的 Staff/Senior/Reviewer 与 41 个任务复盘

一句话结论：多 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 配额。

二、角色与任务板

任务板才是核心

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 上跑过）：

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 编排的团队：六个检查点

一句话总结：多 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
• 项目仓库（BSL 1.1）：https://github.com/adam-drag/triglav

相关阅读：AI 编程 / Vibe Coding 完全指南 ｜ 子代理交接：compaction / subagent / fold 三种做法 ｜ 28 个 Agent 六天自主循环复盘

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

这是「AI 编程 / Vibe Coding」专题的一部分。完整地图见：AI 编程 / Vibe Coding 完全指南