跳到正文
DEV Community· Adam Drag·· 3 小時前AI 評分67

Triglav 協調 Claude Code 與 Codex 智能體,處理長任務及分層審查

Triglav: orchestrating Claude Code and Codex agents for long-running work and layered review

AI 導讀

Triglav 是一款本機優先的協調工具,讓 Claude Code 和 Codex 智能體分工處理長任務,並以共享任務板及分層審查管理交付。作者稱,工具在其自有倉庫的首 10 天執行 41 項工作並完成 34 項;本機審查面板累計完成 96 輪,當中 54 輪通過、42 輪要求修改,但這些數字不衡量審查準確度。

正文

AI coding agents can write code. Longer tasks still need coordination and quality control. Someone has to keep track of the objective, settle the open questions, review the changes, and check that the finished work meets the acceptance criteria.

Triglav puts that workflow around Claude Code and Codex.

A Staff agent plans and delegates. Seniors implement separate assignments. A shared job board lets agents ask questions, consult researchers, challenge proposals and record decisions. A local review panel checks every change before delivery. After that comes a Copilot review where it's configured, and a CI check that Staff runs itself.

I'm the Client. I answer the questions the team can't settle, and I decide what ships.

In its first ten days, Triglav ran 41 jobs on my own repositories and finished 34 of them. As of this week it's public.

GitHub logo adam-drag / triglav

Local-first orchestrator that runs Claude Code and Codex agents like a small software consultancy. Staff plans, Seniors build, Reviewers check, Researchers advise. You decide from a dashboard. MCP server, Docker and MySQL, works from Linear, Jira or GitHub tickets.

Triglav

Important

Triglav uses your own Claude Code or Codex account, so its usage counts against your plan.

  • It needs Claude Code and/or Codex, installed and signed in on your machine. Triglav does not include a model, does not call an AI API, and does not ask for an API key. It only orchestrates work: it starts and coordinates the agent CLIs you already have, and they use the account they are signed in with.
  • All usage goes to your own account. Every agent turn, Senior, local code review, researcher run and Operator message is a request through your Claude Code or Codex login. If that login uses an API key, pay-as-you-go billing or extra usage beyond your plan, Triglav's work is billed to you on those terms. The Copilot review loop may also use your GitHub Copilot quota.
  • Some of it starts without a click. Staff wakes up on…

Triglav home page: one decision waiting for the Client, two jobs, five agents online

The screenshots in this post show a demo project, a fictional web shop. The home page, review, and Inbox screenshots come from Triglav's test stack, where the agents and the reviewer output are scripted.

The team

Before I wrote any code, I wrote down the experience I wanted: I set the objective, a Staff engineer agent handles most of the delivery decisions, and I step in only when it's necessary. So Triglav works like a small software consultancy:

  • Staff is a long-running Claude Code or Codex session. It reads the ticket, plans the work, writes the acceptance criteria and starts the Seniors.
  • Seniors are subagents of Staff. Each one takes one assignment, works in its own git worktree and opens a PR.
  • Researchers are short runs that read the job board and advise. They don't own any code.
  • Reviewers check what a Senior hands in.
  • Me, the Client. I approve the plan, answer escalations and merge.

The name comes from Triglav, a three-headed Slavic god. The three heads were the first three roles: Staff, Seniors and researchers. Reviewers came later.

Every action goes through Triglav's MCP tools, so all of it is recorded, and the dashboard is a view over that record.

A shared job board for questions and decisions

This is the core of Triglav.

When a Senior isn't sure about something, it doesn't quietly pick an option. It opens a timed question on the job's board. The question has to carry its own context: the job, the acceptance criteria, the work that's waiting and the options already considered. So a researcher that has never seen the job can still give a useful answer.

Staff and the researchers reply with a stance, for example support or challenge, and anything other than a plain comment needs a reason. The Senior waits for the whole response window, even when Staff answers in ten seconds. If nobody replies, the window extends.

A timed question on the board: a Senior asks how to store guest orders, and a researcher and Staff reply with a stance and a reason

In this exchange, a Senior asks whether guest orders should store the email or create a hidden customer. A researcher and Staff both answer with a stance and a reason before the window closes.

When the window closes, Staff records a binding decision and lists every reply it considered. A reply that came in late is kept and marked as late. If a late reply changes things, Staff has to record a new decision that supersedes the old one. It can't quietly change its mind.

The board keeps the question, the arguments and the final decision with the job. I can check the reasoning later without piecing it together from separate agent conversations.

One job, start to finish

1. Define the objective. You start a job from a Linear, Jira or GitHub issue link, or from a plain prompt. A prompt job starts in a refining stage. Staff turns your sentence into a goal, a scope, non-goals and acceptance criteria, and asks its open questions, each with a recommended answer. You answer and edit until it's right. Planning starts only when you click Approve. Staff can't approve its own proposal.

2. Delegate and consult. Staff splits the work, writes a brief for each Senior and starts them, at most 2 per job and 10 in total. Seniors hold their assignment with a lease. If one stops renewing it, Staff starts a new attempt, and the old one is fenced off. Questions go to the board.

3. Review and fix. Before delivery, every change goes through layered review (the next section).

4. Verify and escalate. A job counts as done only when Staff has checked CI itself on the same commit the Senior reported. Anything the team can't decide comes to me as a decision.

Layered review before delivery

Layer 1: a local review panel. The Senior asks for a review of its commit range. A panel of read-only reviewers reads the diff and the repository. The release default is GPT-6.1-Sol on Codex as the strong seat and Sonnet 5.5 on Claude Code as a cheap second opinion, so one model family checks the work of the other. The panel is a Client setting.

Two local review rounds: round 1 finds a P1 bug that both reviewers reported, round 2 reviews only the fix and passes

The server enforces the gate:

  • submit_review_package and the Copilot review request are refused unless a finished review of exactly that commit has the verdict ok.
  • One piece of work gets at most 3 local rounds, and each later round reviews only the fix.
  • The reviewed ranges of a job form one chain from the merge base, so no commit is skipped between two reviews.
  • A reviewer that crashes or returns something unreadable fails the round, and a failed round never counts as a pass.

So far the panel has finished 96 rounds: 54 passed and 42 asked for changes. That shows the gate is used. It doesn't measure how accurate the reviewers are. To get a feel for that, the repo has an evaluation harness that replays the panel on Triglav's own PRs and compares the findings with Copilot's. Copilot is a benchmark there, and a match doesn't prove a finding is right.

Layer 2: Copilot. Up to 3 Copilot review rounds per PR. Whether this layer runs is the Client's setting: auto uses Copilot where the repository has it, Copilot required refuses a delivery without a clean review, and CI only skips it. The server can't run gh itself, so it relies on the Senior's own report of each round.

Layer 3: CI on the reported commit, checked by Staff before it marks the job done.

Escalation to the human

Most questions never get to me. Staff settles ordinary engineering questions itself. When it really needs me, it raises a decision with the problem, the question, its recommendation, any commands I have to run (each with a Copy button), and the researchers' advice.

A client decision in the Inbox with the problem, the question, a command with a Copy button, the recommendation and the answer buttons

If I agree, it's one click: Accept recommendation. The count of open decisions shows in the browser tab, so I can work on something else and still see when the team is waiting for me.

There's also an Operator page, a Claude Code chat for "why is this job stuck?". It can read, but it can't change anything. When it wants to act, it puts a card in the chat that waits for my Confirm.

Things that bit me

Running a workflow like this for days, not minutes, brings problems a single agent session never has.

Usage limits and duplicate sessions. A Staff hit a usage limit. When the limit reset, Claude Code continued the session by itself under a new session id. I resumed it as well, and two Staff agents were managing the same job. The runner now checks for a running copy of a conversation before it resumes one.

Wake-ups cost more than writing. In the first six days, all agents together wrote about 3.6 million output tokens and read about 3.6 billion from the prompt cache, roughly a thousand to one. Every time a waiting agent wakes up, it re-reads its whole context, and for a Staff that's often 300k to 700k tokens. So Staff now wakes only for events it needs, and it waits up to 50 minutes per call on its one-hour prompt cache. Researchers don't wait at all. They start when there's something to read, answer, and exit.

Context size. Staff compacts its context at about 280k tokens. The Claude Code default for Opus was around 980k, so a long-running Staff never compacted and kept re-reading an ever-growing context.

Permissions and limits

Merging, deploying, force pushing and repository settings stay with the Client. The agents are told never to do them, but that's an instruction, so protect your branches on GitHub as well.

The server runs in Docker and can't start processes on the host. A small host runner does that, and it never runs a command string from the server. It builds every command itself and checks every field first. Reviewers, researchers and the Operator can only read.

Agents run as your OS user, so a determined agent could read .env. The README says this plainly, together with the other things the security model doesn't cover.

Try it

You need Docker, Node 24, pnpm and Claude Code or Codex. I've only run it on Linux.

git clone https://github.com/adam-drag/triglav.git
cd triglav
pnpm install --frozen-lockfile
node scripts/setup.ts          # random keys + a dashboard password
docker compose up -d --build   # server, MySQL and dashboard on :7400
node scripts/runner.ts         # the host runner

Connect your agents to the MCP endpoint (one claude mcp add-json line, it's in the README), open localhost:7400, and click New job. Triglav uses the claude and codex CLIs you already have and picks up the models each one lists.

Every agent turn and every review is a request on your own Claude or Codex plan, and Staff starts Seniors without asking you, so watch the Usage page on your first job. If you run Staff on Codex only, it can write in the repository and sees your GITHUB_TOKEN, with Codex's automatic reviewer as the only check. Use that only on repositories you trust it with.

Triglav is source-available under the Business Source License 1.1. It's free for your own work and for your company's internal work. You can't offer it, or a product or service built mainly on it, to others as a hosted service, a managed service or a redistributed product. It isn't open source, and each version moves to GPL-2.0-or-later after four years.

All the numbers in this post come from me, on my own repositories. That's a lot of real use, but it's one person's use, and I'd like to know how it holds up on yours.


When an AI agent hits a question it can't settle, what should it do: guess, ask another agent, or ask you?

來源:DEV Community · dev.to