跪拜 Guibai
← All articles
Agent · Next.js

The Four Hard Boundaries That Keep an AI Image Pipeline From Falling Apart

By 倾颜 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Most AI image demos stop at a single fetch. A pipeline that actually ships needs verifiable prompt quality checks, hard cost caps, and a security proxy that treats every provider URL as hostile — and the architecture must let you test the decision graph without spinning up a database.

Summary

Calling an image API is the easy part. The real work sits in the four boundaries around it. AI Mind v0.4.12 uses a Zod schema with `.strict()` to turn user descriptions into a structured ImageBrief that separates explicit requirements from system defaults, so downstream steps never confuse the two. A prompt inspection node then cross-references the generated prompt against that brief using a fixed taxonomy of issue codes and severity levels — the LLM provides a judgment, but the code owns every routing decision.

Hard counters enforce the limits: at most one image generation, one prompt revision, and five planning calls. There is no "try again" loop, because every extra call costs real money and the system prefers to generate nothing over generating uncontrollably. The final boundary is a security proxy that fetches the provider URL server-side through six checks — URL structure, ownership, run status, HTTP response headers, streaming size enforcement, and magic bytes — so the frontend never touches an untrusted URL.

The pipeline explicitly does not support editing, inpainting, or multi-image generation. Those are separate capabilities, not extra parameters, and the system returns a clear unsupported-capability error rather than silently degrading.

Takeaways
User descriptions are not executable prompts; a structured ImageBrief separates explicit requirements from system defaults so downstream steps never confuse the two.
A Zod schema with `.strict()` rejects any LLM-hallucinated field outright — no silent pass-through, no hidden JSON repair, just a hard fail.
Prompt inspection uses a fixed taxonomy of issue codes (missing_subject, conflict, capability_boundary, unsupported_assumption) and three severity levels that directly determine routing.
The LLM provides a judgment; the code owns the routing decision. An outcome of "revise" is ignored if the revision counter is already exhausted.
Hard counters cap the pipeline at one image generation, one prompt revision, and five planning calls — no infinite loops, no hidden retries.
The provider's image URL is never sent to the frontend. A server-side proxy runs six checks: URL structure, ownership, run status, HTTP response headers, streaming size enforcement, and magic bytes.
Magic bytes are the last line of defense: even if Content-Type is forged, JPEG must start with FF D8 FF, PNG with 89 50 4E 47, and WebP with RIFF....WEBP.
Image editing, inpainting, and multi-image generation are explicitly unsupported and return a clear IMAGE_CAPABILITY_UNSUPPORTED error rather than silently degrading.
The three-layer architecture (Orchestrator, Coordinator, StateGraph) keeps the decision graph free of side effects, so all branches can be tested with mocks and no database.
Conclusions

Hard-coding limits like maxImageGenerations=1 is a cost-control strategy disguised as an engineering constraint. The system prefers to generate nothing over generating uncontrollably, which is the opposite of how most AI demos are built.

The `assumptions` field in ImageBrief is a clever piece of factual bookkeeping: it prevents the inspection step from flagging system defaults as missing user requirements, which would otherwise create false-positive blocks.

Using `"Return no reasoning"` in the inspection prompt is a security and simplicity win — it keeps internal execution prompts out of user-facing output and removes noise from the decision pipeline.

The explicit Non-goals (no editing, no multi-image, no HITL) are as important as the features. They prevent scope creep from turning a text-to-image pipeline into an unmaintainable Swiss Army knife.

Refusing to restore images on page refresh is a deliberate product decision, not a bug. It avoids building a persistence layer for temporary artifacts and forces users to download what they want to keep.

Concepts & terms
ImageBrief
A structured, Zod-validated intermediate representation of a user's image request that separates explicit requirements (subjects, mustInclude) from system defaults (assumptions). It serves as the factual anchor for prompt generation and quality inspection.
PromptInspection
A structured LLM output that cross-references a generated prompt against an ImageBrief using a fixed taxonomy of issue codes (missing_subject, conflict, capability_boundary, unsupported_assumption) and severity levels (blocking, fixable, non_blocking). The LLM provides the judgment; application code owns the routing decision.
Magic Bytes
The first few bytes of a file that identify its true format regardless of file extension or MIME type. JPEG starts with FF D8 FF, PNG with 89 50 4E 47 0D 0A 1A 0A, and WebP with RIFF....WEBP. Used as the final verification layer to prevent non-image content from being served as an image.
SSRF (Server-Side Request Forgery)
An attack where a server is tricked into making requests to internal or unintended resources. The image proxy defends against it by rejecting URLs with IP-address hostnames, non-HTTPS schemes, or hostnames outside a preset allowlist.
StateGraph (LangGraph)
A pure decision graph that holds only serializable domain state and performs no side effects (no database, no network, no streaming). This separation allows the entire decision logic to be tested with mocks, independent of infrastructure.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗