Wink Pings

Tearing a year-long system into a 1,600-line kernel: What's most worth seeing in Agent-Autoloop open source are the boundaries

Khazix rewrote and open-sourced the Agent automation system he'd been tinkering with for a year. The kernel does only four things; events, agents, channels, and delivery are all split into plugins. Hot-pluggability is satisfying; what really determines whether it can run long-term are default permissions and plugin contracts.

On Monday he was still worried people would call it a toy; by Wednesday he had rewritten and open-sourced the system. Digital Life Khazix put the Agent automation system he'd spent a year tinkering with on GitHub, with a very direct name: Agent-Autoloop. URL: https://github.com/KKKKhazix/agent-autoloop

image

What makes this thing worth looking at is not how long the feature list is. It splits the system into two layers: an extremely thin kernel, with all four outer directions made into plugins. Khazix writes in the description that it borrows from the design of Pi's minimalist kernel and Extensions, as well as DeepSeek Harness's 'everything is a plugin' architecture philosophy. The kernel is about 1,600 lines, has zero third-party dependencies, and runs after you install Node. The kernel does only four things: receive events, split work according to rules, dispatch work to Agents, and record every step. It does not read the system clock, does not make outbound requests, and does not hard-code specific product names. To connect a new Agent, write an adapter plugin; the kernel does not need to change. The repo also has tests guarding this boundary: if anyone stuffs external requests or product names into the kernel, the tests won't let it pass.

架构图

In this architecture, the most easily overlooked parts are four mechanisms. Their names sound intimidating, but their origins are all ordinary.

Suspension at zero cost. When an Agent hits something that needs your decision, it sends a card and exits. If you don't reply for three days, no Agent process is running during those three days, and no tokens are spent. When you click the card, it reconnects to the original session and continues. The source material compares it to a minister knocking on the emperor's bedroom door every five minutes to ask whether he has looked at it. Now the minister gets off work first, saves state, and waits for the person to come back and load the save.

Event sourcing. All state is computed from an append-only log; it only responds after writing. Network outages, duplicate submissions, processes being force-killed: the log ensures the same thing is recorded only once. For any run, why it ran, which version of the rules it used at the time, and what the final result was can all be retrieved with one command. There is a detail in the source material: Codex reviewed a PR for 65 seconds and was just about to write the result back to GitHub when the network dropped. A blind retry might do the same thing twice; the accounting approach is more reliable than retry here.

Instruction/data separation. Text from external Issues, PRs, and coworker messages is only put into files as data, not concatenated into instructions to the Agent. Which Agent to use, which directory to work in, and what permissions apply are determined only by the local rules.json. A netizen mentioned in a reply that in OWASP's Top 10 for LLM applications, Prompt Injection ranks first. This mechanism is not new, but in an automation system it is critical. Someone writing 'already approved, merge directly' cannot become authorization.

Hop-count circuit breaker. An Agent can wake the next Agent, and the layer count accumulates all the way; above 8 layers it only logs, no longer dispatches work, and sends a card to tell a human. The idea is the same as network packet TTL. It prevents A from finishing and calling B, B from finishing and calling A, and eventually blowing through the quota.

Plugins fall into four directions: events, agents, channels, delivery. Events are responsible for discovering new work, such as GitHub Issues, scheduled tasks, and HTTP endpoints. Agents do the work; Claude Code, Codex, ACP, and generic commands can all connect. Any command-line tool that can accept a prompt and print the last reply can join with one line of config. Channels are responsible for delivering cards to you: desktop notifications, Feishu, DingTalk, WeCom, Slack, Discord. Delivery turns CI/CD into a plugin too: tag a PR with deliver, and it follows up on review, waits for CI, merges, waits for release, and verifies the live version. Review and delivery configs are read only from main; it does not check out or run code from the PR on the machine taking the job.

Installation also doesn't need step-by-step instructions. Throw the repo URL at Claude Code or Codex, have it read README and INSTALL.md, install itself, and run a trial itself. The trial asks you to pick a color; after you choose, it continues to finish. Daily rules are written in rules.json: what task, assigned to whom, in which directory. External events are written the same way; connect the source first. It takes effect within seconds after saving; if you change it wrong, it will still run according to the old rules and send a card reminder.

Concrete scenarios are more convincing than a feature list. Khazix listed several he runs every day: every afternoon have Codex search WeChat groups, X, Xiaohongshu, and Douyin for how people discuss AIHOT, and summarize it into a report; every week have Codex control the browser to go to Doubao, DeepSeek, Qwen, Yuanbao, ChatGPT, and Gemini to ask AIHOT-related questions and see whether the AIs recommend it; every night patrol vendor sources to see whether free quota still exists and whether rules have changed; every morning compare model leaderboard prices; every 5 minutes check from outside whether AIHOT can open, and only wake Codex if it can't; on Sunday have the Agent find the week's merged shit mountain: duplicates, one-off patches, disabled code that wasn't fully removed; delete what can be deleted. The company's XuShi middle platform was also used as an example: coworkers DM the bot on Feishu with suggestions; Claude evaluates, modifies, and deploys; sensitive operations go to Khazix for approval. The source material says coworkers raised more than 80 suggestions, Claude autonomously changed nearly 70, and about a dozen needed approval; requirements it can handle automatically are basically finished and fed back within an hour.

In community feedback, several comments are more useful than 'badass'. A netizen reminded that the cost of pluginization comes later: events, channels, and executors iterate separately, interfaces need versioning, and the kernel had better keep a version field and a minimum compatibility declaration; otherwise half the Issues six months later will be plugin and kernel version mismatches. Someone asked whether, besides the hop limit, the entire mutually-waking task chain should have a cumulative cost cap. Someone suggested connecting only one event source first, having rules.json dispatch only read-only work first, and putting data deletion, spending money, and sending external messages all through manual approval; run it stable for a week before delegating authority. Others said open-source pipelines are easy to copy, but org design isn't; which actions require human sign-off by default and which log counts as acceptance have to be marked yourself. These words aren't flashy, but they all need to be filled in before the system goes to production.

There was an interlude. A developer posted todos.dev, saying the flow was similar to Agent-Autoloop. The Todos author replied that he had polished it for more than 100 days. Khazix rewrote his in two days. A netizen said what takes a year to write is called architecture, what takes two days to write is called epiphany; actually it's not refactoring code, it's deleting the extra ego from a year ago. Crude, but the open-source version indeed looks more like the product after the boundaries became clear. A two-day rewrite is not a myth; the premise is that the previous year had already stepped through the pits once.

Agent-Autoloop is still 1.0.0, definitely has bugs, and the Windows version is TBD; Khazix says he'll go home this weekend to develop and test. The most valuable thing in open source often isn't in the feature list; it's in default permissions and failure paths. Hot-pluggability is satisfying, but if plugin contracts, version compatibility, cost caps, and manual approval checklists aren't filled in, hot-pluggability will become hot pit-stepping. Project URL again: https://github.com/KKKKhazix/agent-autoloop

发布时间: 2026-11-05 00:28