跳到正文
DEV Community· 十方空烬 · Ember ☄️·· 1 天前AI 評分53

Open Source Radar · 2026-10-28:審批由提示詞轉入流程

Open Source Radar · 2026-10-28: Approval moves from the prompt into the pipeline

AI 導讀

本期 Open Source Radar 梳理五個 GitHub 專案,指出 Ovis、Kortix 和 DramaClaw 分別把提示選項核對、合併審批及付費生成前檢查納入流程。三者管控的事項不同,並非同一層審批;文章亦指出,五個項目中有三個採用附加限制或條款的授權,並比較 OXR 基準測試的整體分數與細項表現。

正文

By Renchao Wu. Originally published on widechaos.cn.

Each day I pick five projects from GitHub's candidate pool, which mixes the Trending page with topic searches, mostly AI agents and developer tools. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-28.

1. devswha/ovis ⭐ 1,561 · TypeScript

GitHub: https://github.com/devswha/ovis

In one line: turns the coding agents running on your own machine into conversations you can approve from a browser or a phone.

What it is: Ovis is a front end for herdr. herdr describes itself as the runtime that coding agents live on: it keeps the terminals of Claude Code, Codex, OpenCode and similar tools in a background server so they survive a closed client or a dropped SSH connection, and it marks each pane as working, blocked or idle. Ovis opens a window onto that: browser, Mac app and phone all see the same sessions. The project was created on 2026-09-17 and has 1,561 stars now; it is TypeScript on Bun, with React and xterm.js in the front end.

What stands out:

  • Prompts are cards, re-checked against the live menu before they are sent. The README says prompt cards are "checked as still current before your answer is sent", and the guide is more specific: supported cards are verified against the current menu before anything is typed. Menus in a terminal interface change; answering from a cached copy means making a decision the agent never asked for.
  • It reads session files instead of adding a layer. Ovis renders the agent's own transcript files, folding work per turn for Claude Code, Codex, OpenCode, pi, omp, gjc and identifiable Devin CLI panes; agents without a native reader fall back to a terminal-text view. There is no account system and no hosted relay of its own. No relay of its own does not mean nothing leaves the machine; the next point covers that.
  • The terminal is the same pane. What opens on the phone is the pane herdr is running, with a key bar, not a read-only mirror.
  • Data does leave the machine. Session files stay on the computer running each agent, but their contents are sent to the browsers connected to the app. Voice input sends recordings to the configured transcription service, and without a configured key the browser's speech recognition may use the vendor's own service. Push alerts are relayed by the browser vendor's push service. With Portal on, every connection goes through the relay you chose, and that relay sees connection addresses, timing and volume. The privacy notes spell these out; having no relay of its own is not the same as sending nothing.
  • Push alerts cover two events. An agent asks something, or an agent finishes, and the alert arrives with the app closed, through the browser vendor's push service as an encrypted notification. Anonymous usage counts are on by default; settings show what is sent and turn it off, as does OVIS_TELEMETRY=0.
  • The cost is stated up front. herdr 0.9.0 or newer, your own computer switched on, and a phone that can reach it by one of several routes: Tailscale, a LAN address, an SSH tunnel, a reverse proxy or a Portal tunnel.

Compared with: the project's own FAQ names the alternatives. collie is a mobile terminal for herdr, tmux and zellij, with a status dashboard, key pad, quick replies and voice input, served by its own bridge; roamgate is a browser client for herdr with a file explorer and diff annotations; herdr-remote is a macOS menu-bar app with a Telegram bot behind a relay and a free tunnel. Against Happy, Paseo and CloudCLI UI the split is architectural: those start and manage agents through their own wrapper, daemon or server and ship their own apps, while Ovis only acts as a window. These are the project's claims; I did not install the others to check them.

Recent updates: v0.4.19 (2026-10-27) lets you update an older Ovis on a given PC from its own card, brings Antigravity chat to Windows, shows pictures from omp sessions and Codex tools, renders OpenCode subagents as background tasks, and can revoke every paired device at once. The same day shipped remote-v38, which gives the SSH remote bridge runtimes a SHA-256 manifest. A checksum manifest alone does not establish publisher authenticity.

Who it's for: people already using herdr across several machines who are often away from the keyboard. Without herdr, look elsewhere.

My take: ⭐⭐⭐. It invents no new capability; it moves the moment when an agent is stuck waiting for one sentence onto a phone, and its documented live-menu check addresses stale options. I have not tested races between verification and submission.

Checked: read the README, docs/guide.md, the v0.4.18 and v0.4.19 release notes and the last five commits; did not install.

2. SoMarkAI/OXR ⭐ 1,904 · Python

GitHub: https://github.com/SoMarkAI/OXR

In one line: a 1.3B-parameter document parsing model that turns PDFs and document images into Markdown or JSON with layout coordinates.

What it is: OXR comes from the SoMark team and was created on 2026-10-05. It splits the job in two: a layout analysis model cuts regions, and the OXR model handles recognition with reading order folded into that stage. The README says this is the main difference from comparable tools, which either give layout to the recognition model or use a dedicated model that also handles reading order. Output is Markdown or JSON, with bounding boxes per element.

What stands out:

  • Layout analysis is replaceable. The built-in layout model can be swapped for a custom one while OXR keeps handling recognition and reading order. The reasoning is that layout requirements vary most across document domains and need the most customization, so the layout component can be replaced. Recognition interfaces may remain the same, but end-to-end quality still needs re-evaluation.
  • Thirteen element types. Beyond body text, titles, tables, figures, formulas and headers/footers, it covers stamps, code blocks, chemical equations (LaTeX with \ce and mhchem syntax) and chemical structures (SMILES or images).
  • Post-training runs a self-improvement loop. It targets samples the model gets wrong or handles weakly instead of relying on human annotation; the README calls this a first for document parsing, a novelty claim I have not independently established.
  • The free API and local deployment are different paths. The free API needs no key and no signup, but requests are queued, stability is not guaranteed and the project says not to use it in production. Running locally takes Linux, an NVIDIA card with BF16 support, a CUDA 13.0 driver, 24GB of GPU memory to start and 48GB or more recommended for long documents or higher concurrency.
  • The web demo cache expires. Temporary files last one hour by default and are renewed while processing; after that the results are gone.

Compared with: the project's benchmark document gives full component tables for three benchmarks, with an accuracy snapshot dated 2026-10-05, and notes that peer scores come from published papers, model cards and a pinned commit of the relevant leaderboard README. Overall scores are 87.84 on olmOCR-bench (second place Infinity-Parser2-Pro at 87.60), 97.18 on OmniDocBench (second place TeleOCR at 96.91) and 87.76 on DocParsingBench (second place PaddleOCR-VL-1.6 at 85.17). The three reported overall margins are 0.24, 0.27 and 2.59 points, but the components do not all lead. On OmniDocBench, Formula CDM is only 0.85 points ahead of the runner-up TeleOCR (97.44 against 96.59), and Table TEDS is actually 0.20 points behind (96.62 against 96.82). On DocParsingBench, Formula leads by 10.17 points (85.76 against 75.59). Which component is strongest cannot be read off the total, so fit depends on which element types dominate your documents. All of these numbers are the project's own; I ran no evaluation and did not reproduce them on another machine.

Recent updates: no formal release; main still sits on the 10-05 launch. Commits from 10-19 to 10-24 are README, badges and community links (a WeChat QR code, LinkedIn), with no code movement.

Who it's for: people whose documents are table-heavy and who must process them locally; the README's examples include financial reports, exam papers, newspapers and handwriting. The documented local setup starts at 24GB; I have not tested lower-memory alternatives. Check permission and data-handling terms before submitting confidential scans to a hosted API.

My take: ⭐⭐⭐. The part worth learning is the module split: layout on its own, replaceable, with recognition and reading order bound together. That the top score leads by 0.24 points says more than the top score itself.

The model uses Apache 2.0 with additional terms, according to its licensing documents. Those terms address consolidated commercial thresholds for the user and affiliates, attribution for online services, and a separate written licence for a competing hosted API. Read the exact code and model grants for the intended use.

Checked: read the README, the full docs/benchmark.md, the additional license terms and the last five commits; did not install or run any evaluation.

3. elayadesign/ai-design-skills ⭐ 9,722 · Markdown

GitHub: https://github.com/elayadesign/ai-design-skills

In one line: a design skill collection for coding agents, currently one skill, where 18KB of Markdown spends half its length on what a page should say and half on visual values that are not up for debate.

What it is: the repo is organised one folder per skill, and you install only what you need: copy into .claude/skills/ for Claude Code, download into .cursor/rules/ for Cursor, paste into AGENTS.md for Codex, .windsurfrules for Windsurf, .clinerules for Cline, or straight into a system prompt. The whole repo is 38KB of text with no code. landing-page-design has two parts: Part A covers strategy and structure, Part B is the visual system. The opening fixes precedence: when this file conflicts with a framework default, the file wins; when the user's explicit request conflicts with it, the user wins.

What stands out:

  • Ask before drawing. Four groups of questions come first: the one primary action, who does not convert and why, which logos and numbers exist, and the brand voice. If the answers are missing, make a reasonable assumption, state it in one line and continue rather than stalling.
  • A fixed twelve-section skeleton. Five above the fold (headline, subheadline, primary CTA, one proof signal, hero visual), four in the middle (problem to solution, three to five benefits, a three-step process, social proof), three at the bottom (six to twelve FAQs, risk reversal, a final CTA identical to the top).
  • Visual values leave no room. Only Geist, Manrope, Geist Mono and Poppins are allowed; Inter, Roboto, Arial, Open Sans and Helvetica are banned, as are italics and 900 weights; every font size must land on a Tailwind scale step, and a size that does not is snapped to the closest step below; spacing may only use values from the table; copy may not contain hyphens or leave an orphaned word.
  • Every page needs a tagline reveal. A separate large-type section, at least two lines, where words go from 25 to 35 percent opacity to full text colour as the section scrolls into view, triggered per word with IntersectionObserver and never an unthrottled scroll listener.
  • Content realism has hard targets. No Lorem Ipsum and no "Your headline here"; names are specific and fit the region, prices carry decimals or odd final digits, dates in a list vary; these conventions do not justify inventing customers, endorsements, prices or results; words such as revolutionize, supercharge, cutting edge and effortless are banned.

Compared with: it divides work with the same author's redesign-skill rather than competing with it: that one diagnoses why an existing site looks template-generated, this one builds from scratch, and each points at the other. The content realism and motion ideas are adapted from Leon Lin's taste-skill (MIT); the SKILL.md appends that license in full and notes that overlapping sections were rewritten. What is unusual is how prescriptive it is: it turns design choices into values and prohibitions, and decides who wins a conflict.

Recent updates: no release. On 10-25 a design-to-motion skill was added; on 10-26 it gained guidance for screenshot sources and a small entrance animation for site heroes, and on the same day the sections overlapping taste-skill were rewritten with credit; on 10-27 that skill moved to its own repository. So the collection grew one skill and lost it within two days, and still holds one.

Who it's for: people who want explicit landing-page layout defaults rather than selecting every value during generation. One-pass correctness is not established. It is tied to the Tailwind scale, so outside Tailwind the snap-to-step rule needs a replacement scale; the style is locked down as well, which makes pages look like each other.

My take: ⭐⭐. The content is not new; what interests me is the specificity of its instructions and file structure; a Markdown rule is not runtime enforcement: strategy first, values after, a design-values block at the end that changes the whole file when edited.

Checked: read the README, the full SKILL.md, the LICENSE and the last five commits; did not generate a page from it.

4. kortix-ai/suna ⭐ 20,323 · TypeScript

GitHub: https://github.com/kortix-ai/suna

In one line: a self-hosted agent platform that treats a company as a git repository, with each session on its own sandbox and branch and every artefact landing through a change request.

What it is: the repository is still named suna; the product is now Kortix, created 2024-10-05. A project is a git repo plus a kortix.yaml holding agents (role instructions in Markdown), skills, memory, connectors and triggers. Each session gets a disposable Linux sandbox in the cloud on its own branch, where the agent can install and run software within the configured permissions, with committed repository changes preserved. External calls and side effects are not undone by discarding a branch; reaching main requires a change request that a person reviews.

What stands out:

  • Merge is default-deny for agents. That is the README's wording. An agent may edit its own configuration and propose the change on the session branch, but the documented default requires human review before it reaches the trunk. I have not audited bypass paths or deployed this policy.
  • Permissions go down to arguments. Each tool can be set to Allow, Ask or Block; Ask holds that call until a person approves it and then the agent continues. The README also says approval gates are off until you set them. Keep the two separate: the merge gate is closed by default, while the per-tool Ask gate is not on by default.
  • Connector credentials and secrets are handled differently. Connector credentials are brokered server-side through one scoped token covering 3,000+ apps plus MCP, OpenAPI, GraphQL and raw HTTP, and those credentials do not enter the sandbox. Secrets are the other case: encrypted at rest with a per-project key, granted per agent, and injected into that session's sandbox at runtime as real environment values, so a granted agent can read them in its own session. "Secrets never enter the machine" is not what the README says.
  • The entry points are where people already are. Mentioning the bot in Slack or Microsoft Teams starts a session in that thread, and follow-ups stay in the same session; the email channel is marked experimental.
  • Self-hosted is not the same as disconnected. kortix self-host start pulls images from Docker Hub, and the README says so directly.
  • The license is Elastic 2.0. Read it, fork it, self-host it. What it restricts is providing the software itself to third parties as a hosted or managed service that gives them access to a substantial set of its features. Running your own business on it and selling what you produce are a different matter.

Compared with: the README names n8n, OpenHands, Paperclip and Onyx-style chat tools. Its split: n8n fits fixed flows; OpenHands is a coding-agent control centre for engineering teams; Paperclip adds an org chart, budgets and a task board on top of existing Claude Code or Codex runs; Onyx-style tools are a chat window over documents. Kortix wants the platform to run the agents, one cloud computer per session, all configuration in one repo. The table is marked as reflecting publicly documented behaviour as of July 2026, and I did not check each competitor's docs; what can be verified independently is the mechanism: per-session sandbox, branch per session, merge through a change request, configuration in git, all of which match the CLI commands (kortix sessions new, kortix cr ls, kortix ship).

Recent updates: v0.14.8 (2026-10-23) makes every new session run pi and marks OpenCode deprecated while existing sessions keep it, and adds sharing of a single assistant response. v0.14.7 (10-22) adds project transfer between organisations or accounts, a per-project default reasoning effort, and running a session on your own machine through kortixd with a ChatGPT subscription.

Who it's for: teams that want agents with audit trails and approvals; any proposed hosted-service use needs review of the actual licence and any separate grant. The stack is not light: cloud sandboxes, SSO and a connector broker all have to land.

My take: ⭐⭐. The institution is the thing to copy: configuration in git, changes through a change request, merge denied by default. The stack itself is too heavy for a single user.

Checked: read the README, the LICENSE, the v0.14.7 and v0.14.8 release notes and the last five commits; did not deploy it.

5. dramaclaw/dramaclaw ⭐ 6,502 · Python

GitHub: https://github.com/dramaclaw/dramaclaw

In one line: a self-hostable production line for AI short drama, with an infinite canvas for experimentation and a pipeline that covers episode planning, scripts, storyboards, voice-over and the final cut.

What it is: created 2026-03-27. Two surfaces share one asset library and one built-in agent. XiaHua is a node-based infinite canvas with 18 node types where you generate, edit and connect images, video, audio, 3D sets and scripts, then promote what works back into a series; XiaJi is the pipeline that takes a manuscript or screenplay through episode planning, scripts, storyboards and first frames, voice-over and export; Xia Director spans both, turning a creative brief into a node graph that runs after confirmation, with progress tracking and failure recovery.

What stands out:

  • The documented gateway-based pipeline needs no local inference GPU. The documented standard inference path goes through an OpenAI-compatible gateway (the official RelayClaw service or a bundled dramaclaw-gateway routing to providers you configure); 2 vCPU and 4GB is the recommended floor, started with Docker Compose; ports 8080 for the web UI, 8780 for REST, 3000 for the gateway admin UI; no Postgres, Redis, Celery or Ray, with state in local SQLite and files. Only the optional 3D world feature needs a GPU.
  • Skills and recipes are portable units. Eleven workflow skills and 60 recipes cover short drama, e-commerce ads, IP character ads and social content, and can be installed, exported and shared.
  • There is an MCP surface for outside agents. Agent Kit exposes the same production workflows to MCP clients such as Codex and Claude Code: the product does not build another agent, it lets existing agents drive the pipeline.
  • Scene consistency runs through 3D. An image can become a 3D Gaussian splat set or a 360 panorama node that locks spatial structure, to guide spatial consistency across shots. I have not measured consistency or generation failures.
  • Every step is decomposable. Each stage is an independent async task that can run in order, be skipped or resumed from a checkpoint, and the orchestrator can be replaced; a task centre tracks status, progress, logs, cancellation and retries.
  • The pipeline documents preflight checks before generation. v2.0.5 added reference-media validation (duration limits and the like) before generation, and later commits add a media storage preflight before paid generation. These checks do not cap all provider charges or make retries free.

Compared with: the README includes a capability table where competitor names are partly masked (L*TV, R*Hub, T*Now, S*ko, U*dream and others) and the note says the comparison is based on publicly available product docs and positioning. Masked names cannot be matched to specific documents and the ticks have no published criteria, so I do not accept a claim such as "the dual track is unique to it". What can be checked sits at the mechanism level: canvas nodes keep their own generation history, the asset library and the series project onto each other, skills are exportable, and Agent Kit speaks MCP.

Recent updates: v2.0.6 (2026-09-28) adds video extension that keeps the original aspect ratio, model-backed resolution and frame-rate enhancement including interpolation, and MP3 output for separated audio. v2.0.5 (09-17) lets archived generated media be delivered and accessed instead of relying on expiring links, and adds two LingShan image models to the community edition. Releases stop at 09-28 while main keeps moving, with the storage preflight and Portuguese localization on 10-26.

Who it's for: small teams with a script who want to assemble a short-drama or e-commerce video line themselves. Watch the license: the project describes Elastic 2.0 as source-available and permitting standalone and commercial use subject to its terms, and keeping the Powered by DramaClaw notice in the UI is what the project asks for. What it restricts is providing the software itself to others as a hosted or managed service using its features; the README says the hosted-SaaS grant is not open yet. Trademarks and brand assets are not licensed with the code.

My take: ⭐⭐. The engineering is substantial, but the comparison table cannot be verified and the license has its own terms; read both before deciding.

Checked: read the README, the NOTICE, the LICENSES directory and the head of license-inventory.csv, the v2.0.4 to v2.0.6 release notes and the last five commits; did not deploy it.

At a glance

Project What it is Most distinctive point Who it's for Worth a deep look
ovis Browser and phone client for agent sessions Prompt cards re-checked against the live menu before sending People running herdr across machines ⭐⭐⭐
OXR Document parsing model Layout analysis is separate and replaceable, reading order folded into recognition Table-heavy documents processed locally ⭐⭐⭐
ai-design-skills Landing page design skill Strategy and visual values split, with precedence fixed Getting an agent to build a page in one pass ⭐⭐
suna Self-hosted agent platform Merge denied by default for agents Teams needing audit and approval ⭐⭐
dramaclaw AI short-drama production line Canvas and pipeline share one asset library Small teams with a script ⭐⭐

This week's notes

  • Several projects moved a decision into code. Ovis re-checks whether a prompt card's options are still valid before sending it, Kortix denies agent merges by default and can hold a tool call for a person, DramaClaw preflights storage and reference media before paid generation. Each governs something different; what they share is turning a reminder into a check that can fail, not a single approval layer.
  • Licensing is no longer two tiers. Three of these five are not under a standard open source license: two use Elastic 2.0 (source-available; the restriction is on providing the software itself to third parties as a hosted or managed service, not on all commercial use) and one is Apache 2.0 with added terms (the commercial threshold is measured on a consolidated basis for you and your affiliates, online services need attribution, and a competing hosted API needs a separate written license in advance). The boundary of the word "open source" is something you confirm in the LICENSE.
  • What a top leaderboard spot is worth depends on the component. OXR reports overall margins of 0.24, 0.27 and 2.59 points in its benchmark snapshot, while its components do not all lead: on OmniDocBench its Table TEDS is 0.20 points behind the runner-up. When the totals are close, the component table says more about fit than the total does.
  • Skills are becoming portable assets. On one side, 18KB of Markdown holds a strategy, a set of numeric prohibitions and a design-values block; on the other, skills and recipes are packaged as units that can be exported, shared and installed, with an MCP surface for outside agents. Both answer the same question: how does a body of practice keep running after it leaves the author's head.

來源:DEV Community · dev.to