Skip to content

This is the multi-page printable view of this section. .

Return to the regular view of this page.

Introduction

Eventboat 是什么、为什么存在、解决什么问题。

1 - What is Eventboat?

A Go single-binary DAG event router designed for AI agents to operate end-to-end.

Eventboat routes events through directed acyclic graphs (DAGs) of transforms — from sources (Kafka, HTTP, cron, SQL, files) to sinks (Kafka, HTTP, files), with at-least-once delivery, dead-lettering, and replay.

It is agent-native: every capability is accessible through MCP (Model Context Protocol), CLI, and a language server — so AI agents can write, verify, deploy, and operate pipelines autonomously.

What makes it different

DimensionApproach
PredicatesCEL (Kubernetes standard) — zero custom DSL, huge training corpus
TransformsStarlark (Python dialect, sandboxed, deterministic)
VerificationFour machine gates: verify, test, explain, operate
ReliabilitySeven invariant tests, spool/settle/checkpoint engine on SQLite
JobsCron scheduling, catchup windows, typed parameters, backfill
ExtensionCEL → Starlark → WASM → gRPC out-of-process plugins
InteropCESQL dialect (CloudEvents), official TCK 100%

The one-line pitch

Eventboat lets AI agents build and run event pipelines that don’t lose messages — because machines verify every step before it goes live.

2 - Architecture

How the Eventboat engine works: three-layer pipeline, spool+settle+checkpoint reliability, and the four-gate verification model.

Three-layer model

YAML (+overlay) → Config (typed) → Static IR → Runtime Engine
                                          ↓
                              Source → Transform → Sink plugins
  • Config layer: YAML parsing, strict schema validation, variable substitution
  • Static IR: validated DAG + precompiled CEL programs + Starlark programs + schema
  • Runtime: spool + settle + checkpoint engine, consuming only the IR

Reliability model

source → [spool: append-only durable queue] → in-memory DAG → sinks
                │                                  │
                └── checkpoint ←── settle tracker ←── terminal states
  • Spool: every message hits SQLite before the DAG sees it (invariant 1)
  • Settle: each message settles when all branches reach terminal state
  • Checkpoint: advances only over settled prefix (invariant 2)
  • Crash recovery: kill -9 → restart → replay from checkpoint, never lose (invariant 3)
  • Dead letters: exhausted retries → DLQ store with query + replay CLI

Seven invariant tests

Each has a dedicated test that must pass in CI:

  1. Spool before visible
  2. Checkpoint advances only after settle
  3. Kill -9 replay covers all unsettled
  4. Dead-letter write failure blocks settle
  5. required: false edges don’t block siblings
  6. Redelivery keeps message ID stable
  7. Cursor watermark never exceeds settled

Four machine gates

GateCommandWhat it does
verifyeventboat verifySchema, topology, CEL+Starlark compile, lint — static, zero side effects
testeventboat testContract tests against the real engine — fixture in, assertions out
explaineventboat explain --message sample.jsonDeterministic path walkthrough with real CEL evaluation and Starlark dry-run
operateeventboat mcpMCP server: 15 tools covering the full agent lifecycle