跳到正文
DEV Community· Jukka Blomberg·· 3 小時前AI 評分56

Jukka Blomberg 的 13 個 AI 智能體出現測試無法捕捉的故障:一項工作未列入任何智能體指示

My AI agents had a bug that no test could catch: a job nobody's instructions knew about

AI 導讀

Jukka Blomberg 的 13 個 AI 智能體因交接沒有寫入接收方指示,令一項工作連續 10 天未有執行。他提出三項規則:交接須寫入接收智能體的指示;智能體被取代、合併或結束時記錄接手者及時間;面向人的輸出須指定呈現者。他用小型腳本每晚核對責任清單、實際運行狀態及各智能體指示,若交接在接收端沒有負責人便報錯。

正文

Jukka Blomberg

I run my companies with a standing fleet of 13 AI agents and no employees. Each agent has a written contract, a schedule and a run log. They hand work to each other through queues, and every item they touch lands in one append-only ledger.

In August the fleet went quiet in a way that looked healthy. Nothing crashed. Every agent ran on time and wrote its log. And for ten days, a job I had asked for simply did not happen.

What went wrong

I had decided that one agent should draft a daily alert and another, the one that builds my morning summary, should show it to me. The decision was written down. It was in the shared files. It was even in the planning document that describes who does what.

It was not in the morning agent's own instructions.

So the morning agent kept doing exactly what its instructions said, perfectly, every day. In ten days it rendered the alert zero times. Nobody was wrong, and nothing worked.

When I went looking, it was not a one-off. Around the same date I found the same failure in four places:

  • the alert above (10 days, never shown)
  • a recurring defect, logged four nights in a row, with no agent responsible for fixing it
  • a response log that one agent wrote and nothing ever read back
  • two agents I had retired that, from the files alone, looked exactly like two agents that had silently broken

Why tests do not catch this

Every one of those agents passed its own checks. The bug was not inside any agent. It lived in the space between them: a handoff that existed on paper and nowhere in the instructions of the agent that had to act.

With people, this is the meeting where everyone nodded and nobody owned the action item. With agents it is worse, because an agent never "picks up" an unassigned job out of good sense. If the duty is not in its instructions, it does not exist.

The three rules I use now

  1. A handoff is real only if the receiving agent's own instructions carry it. Writing the decision in a shared file does not count. When I add a new handoff, the same session edits the receiver's instructions, and only then records the handoff.
  2. Nothing is just "turned off". An agent is active, replaced, merged into another, or finished, and the last three must name what took over and when. A switched-off agent with no successor written down is treated as a defect, not a decision.
  3. Every output with a human reader names its renderer. Before a new kind of output is allowed to exist, someone answers: who shows this to whom, where, and on which day. A producer and a reviewer without a renderer make an invisible lane, and an invisible lane looks exactly like a quiet, healthy one.

Checked, not believed

The map of who owns what is one file. A small script checks it every night against what actually runs and against each agent's instructions, and exits with an error when a handoff has no owner on the receiving end. I run it before trusting the map.

The cost of all this is a few minutes per change. The cost of not doing it was ten days of a job I thought was running.

The fleet and the rules, in public

If you run agents in a team and have seen your own version of this bug, I would like to hear it: hello@jukkablomberg.com.

來源:DEV Community · dev.to