跳到正文
DEV Community· Kent Alstad·· 3 小時前AI 評分50

預先整合分析:停止把知識放進 AI 智能體上下文,改為監察其工作

Pre-emptive integration analysis: stop putting knowledge into your agents' context, watch their work instead

AI 導讀

Kent Alstad主張採用預先整合分析,持續監察 AI 智能體的分支工作,並在問題仍可修正時通知相關智能體,而非一味補充上下文知識。其 shadow merger 投入使用首週在合併前捕捉 79 個問題,此前每週計數為零;他列出的上下文功能,實際引發行動的比例不足 1%。

正文

Part of the write-ups behind my Build Stuff 2026 talk, Control Your Fate at the Metal, Vilnius, 2 December.

For a year, most of our effort went into getting knowledge into agents' context: summaries of every file, insights from earlier sessions, briefings on every prompt, notes on every command. The last parts of this series measured what came of it. Reach went up, and behaviour didn't change. Even my own corrections, captured as rules and fired at the moment they apply, didn't cut the repeats in the first days. They went up.

One thing did work, and it isn't a context feature at all.

What worked: watching the branches

I run many agents at once, each on its own issue branch in its own worktree, across six repositories. The shadow merger merges every open branch together in the background whenever one gets a new commit, and works out what collides: which files, which functions. Each affected agent gets one line before its next command or edit: your branch and #489 both change this file. It also relays failures between agents ("another agent hit this exact error three minutes ago") and warns when two live sessions are working in the same area.

We count problems caught before merge. Every week before this shipped, the count was zero, because nothing looked. In its first week: 79.

Compare the two approaches:

Context features Shadow merger
What it knows general knowledge about the repo a specific fact about this agent's work, right now
When it speaks on every prompt, read, command only when something is actually wrong
What it says "here's what might be relevant" "this collides with that"
Measured effect under 1% acted on 79 caught before merge, from zero

The difference isn't the model or the prompt. It's that the shadow merger watches the work itself and speaks only when it has one specific, true thing to say.

The gap: it only sees commits

The shadow merger reacts to commits. Agents often edit for a long time before their first commit, and everything they do in that stretch is invisible to it. Collisions that already exist in the working tree surface late, sometimes only at merge.

The obvious fix is to tell agents to commit more often. We've learned what telling agents things is worth. So the agents won't be told anything.

Part 1: checkpoint commits, without the agent

At the end of every agent turn, the hook makes a checkpoint commit of the worktree's changes on the agent's own issue branch. It's local, nothing is pushed, and it happens only in issue worktrees, never on the integration branch. The agent isn't interrupted and doesn't know it happened. When the agent makes its real commit, the checkpoints are squashed into it, so history stays clean. It works the same in every runtime we support, because it's one entry in the hook wiring list rather than a feature of one tool.

Now the shadow merger sees work in progress within a minute.

Part 2: pre-emptive integration analysis

Once the combined tree reflects what every agent is doing now, it becomes the place to analyse everything, before anything is integrated. I call it pre-emptive integration analysis: integrate everyone's work continuously in the shadow, analyse the result, and tell each agent what its part broke while it is still writing it.

  • The code watcher: anti-patterns on the syntax tree, duplication, security findings.
  • The SuperSmall point: structure and complexity of each change, recomputed at every checkpoint, so it's a running score while the agent works rather than a verdict at review time.
  • Shared memory, decisions and dead ends that every agent shares: does this change repeat a recorded dead end, or contradict a recorded decision?
  • A build and test of the combined tree on a spare machine, so integration breaks show up before anyone merges.

Each finding goes to the agent whose checkpoint caused it, through the same one-line notice the shadow merger already uses, before that agent's next command or edit. It informs and never blocks. It all runs in the background service, triggered by commits: no watching working trees, no polling, nothing inside the agent's session.

This changes the review step too. By the time an agent reaches "address the ranking", most items have already been raised and fixed while it worked. Review starts from what's left.

Why I think this is the breakthrough

Every context tool, ours included, tries to make the agent smarter before it acts. This does the opposite: it lets the agent act, watches what it actually did, and tells it the one thing that's wrong while it can still fix it. That's how a good senior engineer works with a team. Nobody briefs you on the whole codebase before every task. Someone who can see what everyone is doing says "hold on, that collides with what Sam is doing."

What we'll measure

  • Problems caught before merge, which should rise as checkpoints expose work earlier.
  • Fixes after merge, the outcome: changes that later needed a fix because of something another branch did. It should fall.
  • How soon a finding reaches the agent after the code that caused it was written.
  • Whether the agent acts on it: the edit that follows a notice.

This is filed as an epic with four parts, in order: checkpoint commits; the watcher and the point on the shadow branch; shared-memory checks; the combined build. Part 1 is in design now. I'll report the first numbers when it's running.


I'm Kent Alstad. I build KandiForge, a toolchain for running software projects with AI agents under an evidence-based process. If you run agents in parallel, I'd like to hear how you find out they collided.

來源:DEV Community · dev.to