Open Source Radar · 2026-11-02: Agent infrastructure is splitting into replaceable parts

By Renchao Wu. Originally published on widechaos.cn.

For this issue I picked five projects from GitHub Trending and topic-search candidates, 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-11-02.

All five point at the same thing: infrastructure for agents; retrieval, a knowledge base, a skills directory, an evolution loop, and one course that turns evaluation into a specification.

1. sahenjp/RustXNG ⭐ 471 · Rust

GitHub: https://github.com/sahenjp/RustXNG

In one line: A self-hosted search service that returns ranked results and page text in a single request, built to be an agent's retrieval layer.

What it is: Written in Rust, AGPL-3.0-or-later, a port of SearXNG with a SearXNG-compatible response shape and a browser UI on port 8888. The repository was created on 18 October 2026 and reached v0.26.0 in two weeks, with two releases on 1 November.

What stands out:

• Text comes back with the results. With include_raw_content=1 it returns about 32,000 characters from the top five pages, so an agent can inspect extracted text without fetching every page separately. Extraction does not establish source accuracy, completeness or permission to republish it.
• Several upstream engines with per-engine failure handling. 226 engine types, 352 settings entries, 180 enabled by default; each engine has its own timeout, failed engines are suspended with backoff, and engines that keep returning nothing are rested.
• The project documents default SSRF checks. The documented policy restricts fetching to public addresses. I have not tested redirects, DNS changes or the full network boundary; it is not an independent security guarantee.
• Ops surface included. /healthz, OpenMetrics /metrics, response cache, image proxy, bot rate limiting, and idle timeout for sidecars.

Compared with: The relationship to SearXNG is a port, not a fork in spirit; compatible interface, engines carried over, plus page-text fetching, SSRF protection and a ranking pass (term coverage, site authority, identifier match). Those additions are documented by the project; I did not re-check them against SearXNG item by item. Against hosted search APIs the difference is self-hosting and text volume: the README reports a 100-question comparison on one machine, hit@1 of 79–83 versus Exa 77 and Tavily 34; about 32,000 characters per request versus about 9,000 and about 1,200; 0.01 s for a repeated query versus 0.6 s and about 1 s. Those are the project's own numbers, not my tests, and it notes they move a few points between runs.

Recent updates: v0.26.0 (1 November) published a ghcr.io image and made the English README primary; v0.25.0 the same day repositioned the project as an agent retrieval layer. All three release notes are one line about checksums, so the substance is in the commit messages.

Who it's for: Anyone who wants to host an agent-search endpoint. The metasearch service still sends queries to enabled upstream engines and fetches third-party pages; self-hosting does not make retrieval offline or eliminate third-party data exposure. Two conditions apply: Google is unavailable in this build (the WML endpoint returns 403, the HTML endpoint needs JavaScript, headless browsers get detected), so replacement engines need testing; and the license is AGPL-3.0-or-later, whose exact terms should be checked for the intended deployment. The README specifically discusses source obligations for a modified network-service version; network access alone is not a complete licence analysis.

My take: ⭐⭐⭐. Collapsing "found it" and "got citable text" into one request is the right subtraction; whether it replaces an existing setup depends on results without Google.

Checked: README, three release notes, recent commits and docs/COMPARISON-EXA.md; not installed.

2. undefined-ui/second-brain-os ⭐ 1,170 · HTML

GitHub: https://github.com/undefined-ui/second-brain-os

In one line: A plain-Markdown knowledge base an agent maintains for you, plus a course and toolkit for building that agent.

What it is: 130 pages; a guide, a seven-module agents course and five handbooks; with a toolkit of 18 skills, 72 slash commands, 6 subagents, 4 scripts, a plugin and a starter vault. MIT. Obsidian is a viewer, not a dependency. It implements the llm-wiki pattern Karpathy published as a gist on 4 April 2026: the wiki is primary and raw sources are an archive; new sources get compiled into existing pages; three operations; ingest, lint, query.

What stands out:

• Compilation, not side-by-side summaries. A concept page is rewritten and thickened by new sources instead of becoming a list of excerpts. That is a maintenance choice; I have not measured long-term accuracy or upkeep.
• Maintenance is a command, not a reminder. 72 slash commands cover creating pages, merging, health checks and graph export; /metrics, /health and /graph-export run from scripts inside the vault.
• Health has script-generated indicators. The health and graph-export entry points provide observable indicators. A health score or graph export does not by itself detect every contradiction or establish that stored claims are true.
• The resource list is dated. Every entry in resources/ carries one line on why it belongs, and the README states it was checked on 1 November 2026 with stars from that day's API.

Compared with: The README compares this file-maintenance approach with memory servers and retrieval-based context assembly. This one is a methodology document plus a copyable vault plus a command set, and its bet is that an agent maintains files through fixed operations. It names Basic Memory 1.0, ai-memory 3.0 and Hindsight 1.0 and explains how it differs; that is its own account, and I did not read those repositories. The checkable dimensions are three: whether writes leave evidence, whether pages are compiled, and whether lint actually runs.

Recent updates: No releases; main-branch iteration. On 2 November the graph recommendation moved from Kuzu to Ladybug (Kuzu was archived in October 2025; the project describes Ladybug as a continuation with embedded CSV support; I have not independently verified migration compatibility), and the README was reorganised by level with a "new this month" section. A companion site went up on 14 October.

Who it's for: People already keeping file-based notes who want an agent to take over filing and linking. It assumes Claude Code's directory conventions (.claude/skills, commands, agents); another agent means changing how they load. If you want "install it and it organises itself", this is not that; it gives process and scripts, and you still feed it the first ten sources.

My take: ⭐⭐⭐. The method matters more than the tooling, and here the method is written as executable commands.

Checked: README, the llm-wiki pattern document and recent commits; not installed.

3. ant-research/AntOmniEvo ⭐ 1,221 · Python

GitHub: https://github.com/ant-research/AntOmniEvo

In one line: A framework that treats a system's tunable parts as a directory of files, has a coding agent rewrite them from failure trajectories, and keeps the loop and the audit trail.

What it is: Python, Apache-2.0. The division of labour is "you define, the framework controls, AI does the work": you supply how to run the system, an evaluator, train/val data, a directory mapping for the tunable artifacts, and a starting point; the framework handles scheduling, budgets, selection and persistence; a coding agent acts as the Proposer. Tunable artifacts can be a skill's SKILL.md plus scripts, a pipeline's pipeline.json plus node code, or a single-file algorithm plus its description. The system being optimised need not contain an LLM; the Proposer must be able to write code.

What stands out:

• Optimisation becomes file editing. Prompts, skills, DAG topology and node implementations all go through one mechanism because they share one property: they are files.
• The scoring rule is the objective. The evaluator returns 0 to 1, train and validation are split, and the README insists on a held-out set rather than gains on the training split.
• The design records edits alongside failure evidence. The deliverable includes lineage linking changes to the failure material used by the proposer. This records a rationale, not proof that the edit caused an improvement.
• Candidate state is persisted for interruption and resumption. Candidates, runs, analyses and changelogs land in a CandidateStore. I have not tested crash recovery, partial external effects or exact replay behaviour.

Compared with: OpenEvolve is another evolutionary-code-optimisation project; its reported gains are tied to its own tasks and evaluation conditions, which I did not reproduce. This project widens the object to skills, prompts, pipeline configs and node code inside a directory, restricts the editor to a coding agent reading failure trajectories, and treats the change-to-failure mapping as part of the deliverable. These descriptions do not establish that the projects have mutually exclusive optimisation targets or that either is more effective. I only read both READMEs and ran neither.

Recent updates: No releases. On 29 October the visualiser gained an English/Chinese switch; on 28 October a trajectory-model document landed along with a note that the paper's experiment scripts and datasets will be open-sourced separately. The paper is Mara Chain (arXiv 2609.35855).

Who it's for: Teams with a repeatable, reasonably cheap evaluation whose optimisation target can be expressed as a directory of files. The docs are explicit about the mismatch cases: a handful of scalar parameters, an evaluation that is not repeatable or is very expensive, or output with strict compliance requirements (it edits files in a sandbox, so audit the permissions yourself).

My take: ⭐⭐⭐. Treating auditability as a hard requirement is worth more than the evolutionary machinery itself.

Checked: README, docs/when-to-use.md, recent commits and the paper entry; not installed.

4. wanghao-SunSky/cs329z-chinese ⭐ 407 · HTML

GitHub: https://github.com/wanghao-SunSky/cs329z-chinese

In one line: A Chinese-language course on engineering AI agents, built around Stanford CS329Z's public materials: 19 lessons, four exercises, readable offline.

What it is: 19 lessons, four hands-on exercises, Markdown sources, a single-file offline HTML reader, and scripts to build and verify publication. The order follows the engineering chain: agent landscape, LLMs for builders, RAG, tool use and function calling, orchestration, context management, memory architecture, multi-agent systems, system optimisation, evaluation engineering, data selection and quality, LLM judges, safety, coding agents, proactive agents, open problems. The README states plainly that this is an independent Chinese study guide, not an official Stanford translation, and that rights to the original course and code stay with their authors; open revisions live in a separate editorial-notes file. There is no license file at the repository root.

What stands out:

• Evaluation is written as a specification. Lesson 13 formalises agent evaluation as a four-tuple; request, environment, stopping criteria, scorer; and lists four difficulties: non-unique solution paths, stateful environments with side effects, compounded non-determinism, and cost plus safety constraints.
• Scaffolding is called out. The same model with a different token budget or tool set cannot be compared directly; realistic scaffolding needs controlled variables. That one line is useful when reading anyone else's leaderboard.
• Dense per lesson. A lesson runs several thousand characters with stated learning goals, not a bullet outline.
• Offline. The single-file HTML does not depend on the site.

Compared with: Among Chinese agent courses it chose to reproduce one course lesson by lesson rather than spread a roadmap wide; the cost is narrow coverage. Against the original English course the increment is Chinese phrasing and engineering organisation, and I did not compare coverage lesson by lesson. There is a practical constraint: the text is organised from public course materials, the repository carries no license, and rights stay with the original authors; public availability does not establish permission to redistribute or use the material commercially; check the applicable rights.

Recent updates: First release on 28 October, then per-lesson descriptions and Chinese search improvements on 31 October. Five days in: 407 stars, 45 forks.

Who it's for: Python developers who want to fill in agent engineering concepts systematically, especially evaluation and safety. If you want a runnable codebase, that is not the shape here; there are exercises, but the body is lecture material.

My take: ⭐⭐. Solid as a Chinese-language evaluation text; as an engineering reference it needs code alongside.

Checked: README, lesson 13, and the repository file list; did not run the build scripts.

5. heilcheng/awesome-agent-skills ⭐ 6,332 · TypeScript

GitHub: https://github.com/heilcheng/awesome-agent-skills

In one line: A cross-vendor directory of agent skills; 388 entries; with six quality criteria attached.

What it is: An 82 KB README with 388 links in six languages, plus a companion site. Two halves: official and vendor directories (AI platforms and models, cloud and infrastructure, developer tools and frameworks, the Google ecosystem, business and marketing, security and web intelligence; six sections with 47 vendor groups), and community skills (16 groups covering vector databases, data and analytics, cloud storage, marketing and more). Its claim is to list skills real teams use rather than bulk-generated ones; the compatibility list names Claude Code, Codex, Antigravity, Gemini CLI, Cursor, GitHub Copilot and Windsurf.

What stands out:

• Organised by who published it. Vendor-maintained skills come first, then third-party ones; a useful provenance distinction, not a substitute for inspecting the contents.
• Six quality criteria. Unambiguous instructions, one focused task, a working example, documented trade-offs, SKILL.md under 500 lines, verified on the target agent. Usable directly as acceptance checks.
• Translations are a pipeline. Commits show translated READMEs and site data synced from the main README rather than six hand-maintained copies.
• Submissions pass an automated gate. Every pull request triggers a checker script: only README.md may change, changes must be additive, at most five lines per PR, a fixed line format, duplicate detection, the repository must exist and not be archived, it must contain a SKILL.md, have at least 20 stars and be at least 14 days old; failures get a needs-fixes label. Entries come from outside contributors, but code enforces the floor.

Compared with: Against a plain link list it adds two concrete things; six stated quality criteria and an automated gate that actually rejects submissions (the rules above are the script's rules); against each vendor's own marketplace it is a horizontal index, and its compatibility list names intended hosts. It does not establish that each listed skill was tested on every host or version. What the gate verifies is entry compliance and repository availability; it cannot verify a claim like "verified on the target agent", which still depends on the author or your own test.

Recent updates: On 2 November it synced multilingual READMEs and site data, tidied a triage batch, and added claude-code-skills-zh, motionboard, mobbin/skills and others (#641 to #647). Created on 29 December 2025; 6,332 stars since.

Who it's for: People looking for existing skills, or wanting acceptance criteria for their own. Start with the vendor sections; check third-party entries' maintenance yourself.

My take: ⭐⭐. Fine as an index, not as a quality endorsement.

Checked: README structure, the quality-standards section, the pull-request checker script and recent commits; installed no skills.

At a glance

Notes from this issue

• Agent infrastructure is being split into replaceable parts. Retrieval, knowledge bases, skill directories and evolution loops each have their own projects, and the interfaces look more like services an agent calls than interfaces a person uses. When choosing, ask about the interface shape before the feature list.
• The projects make auditability part of their design. An evolution framework requires every edit to carry a failure trail; a knowledge base makes lint a mandatory operation. Those choices make changes easier to inspect; I have no evidence here about the authors' prior losses or the effectiveness of the checks.
• Stating limits has become part of the documentation. One says outright that Google is unavailable in this build; another says the framework does not fit systems with only a few scalar parameters. Sentences like these help more than a performance table.