Agent 知识图谱写入：如何控制审批疲劳

Whether a human should approve what an agent writes into its own memory is close to settled: a store that accepts every extracted claim becomes confident without becoming checkable. The harder question is which writes need that approval, and in a running system the answer is a small minority of them.

Several practitioner write-ups published in August 2026 make the case from different directions. Few of them spend time on what happens to that gate three weeks after it ships, which is where the design actually gets decided.

A gate everything passes through is a queue with your name on it

Approval fatigue is not a soft failure mode. A reviewer who approves forty items a day stops reading them somewhere around the tenth, leaving an audit trail that shows approval and provides no oversight. That is worse than no gate, because it manufactures confidence.

The design question is not whether to gate the write path. It is how few things reach it. Across the five business graphs I run, 735 ingested items produced 1,980 facts, and 87 of those items went through the review queue. The rest never touched it. That proportion is what keeps the gate survivable. Not the review speed.

What was said is not what is true

The instinct is to draw the line between systems and people and trust the systems. It does not survive a real deployment. Chat and mail are systems too, arriving through the same webhooks as everything else.

The line that holds is between observation and interpretation.

"The supplier wrote that the delivery slips" is an observation. It has a message id and stays true regardless of what happens next. Commit it automatically with that id attached and nothing is at risk.

"The delivery date is now October 6" is an interpretation. Someone read the message and promoted it into a claim about the world. That promotion is the judgment step, and it is where a wrong call becomes durable context every later session inherits.

Both extremes fail. Promote every utterance automatically and the store fills with whatever someone said in passing, which is how a low-noise graph dies. Refusing to promote anything leaves a record of who said what and no answer to what is true.

Most facts should never reach the gate

The owner already said it. When the person responsible for a domain states a fact directly in a session, that statement is the approval. Queueing it for them to click is the system asking someone to confirm they meant what they said thirty seconds ago. Record the statement as the authorisation and commit.

The interpretation was settled elsewhere. A merged pull request is an event like any other, so this rule is not an exception to the last section. What makes it safe to promote is that the merge decision resolved the interpretation before the graph ever saw it. The limit is strict: the stored fact must be no broader than what that system decided. A merge settles that a diff was accepted, not that the feature works. Stretch it and you have an unowned promotion wearing a system's authority.

Two independent sources agree. The October 6 date sits pending. Two days later the purchasing system moves that order's promised date to October 6, the second source has done the reviewer's work, and the item commits without a click. Independence is the load-bearing word. If a clerk set that date by reading the same mail, there is one source wearing two hats, and corroboration has to refuse it. The mirror case is easier: if the purchasing system says October 20, the contradiction goes to a person.

Ten of my twenty-three pending items should not be there

What survives all three rules is a short list: inferences the agent drew on its own, third-party claims nothing corroborates, corrections of a system of record, and whatever came out of a phone call no event stream will ever contain. That list is short enough to read properly.

My own numbers are less tidy than the architecture. Twenty-three items are pending, ten of them typed as source facts, the class that should have committed without me. The auto-ratify path is not finished, so I am the bottleneck for facts I already trust. Rule one has a softer spot I have not closed: deciding that an owner stated a fact rather than thought out loud is itself an interpretation, made by the agent unsupervised. The routing rules are the unfinished half of this design, not the gate.

Events carry what was recorded. The gate decides what is true. Everything worth engineering sits in the rules that keep those two apart, because the reviewer's attention is the scarce resource, and a queue nobody reads is indistinguishable from no queue at all.

I write field notes from real builds — AI integration, cron-driven automation, and the parts that break in production. New posts every two weeks; if this one was useful, the human-in-the-loop approval checklist is the companion download.