DEV Community: Fenju Fu

Astron Agent dolphin-mcp-pilot: a real FAILURE-to-SUCCESS recovery trace

Fenju Fu — Wed, 12 Aug 2026 12:10:50 +0000

What does it look like when an Agent does more than describe a failed data pipeline? This article documents a real, isolated local run in which Astron Agent called dolphin-mcp-pilot, inspected a failed Apache DolphinScheduler process, drilled into the failed task log, submitted one rerun after a human fixed the external dependency, and kept polling until the scheduler reported SUCCESS.

The screenshots are captures from the running software. This is not a production deployment, and it is not a claim of fully autonomous remediation.

What dolphin-mcp-pilot is

dolphin-mcp-pilot is an open-source MCP tool layer for Apache DolphinScheduler. Instead of asking a model to invent shell commands or scrape a UI, an MCP client can discover structured tools for projects, workflow definitions, process instances, task instances, schedules, resources, logs, monitoring, and raw API access.

Version v0.3.0 registers 58 tools in its source. That number describes the source-registered tool surface in the tested version; it is not a claim that every tool was exercised in this run.

The tested chain

The system under test was:

Astron Agent v1.1.1
dolphin-mcp-pilot v0.3.0
Apache DolphinScheduler 3.2.2
a local standalone, isolated test project
a custom Streamable HTTP MCP endpoint configured in an Astron ReACT decision node

The project also supports stdio, but this recording demonstrates Streamable HTTP. It does not claim an SSE run, production readiness, or end-to-end Token authentication. No credential is shown in the evidence.

1. Connect the MCP endpoint

The Astron ReACT decision node was configured with a custom MCP URL reachable from the Astron runtime. If Astron runs in a container, the endpoint must be addressed from that container's network context; localhost inside a container is not automatically the host machine.

Astron then discovered the 58 tools registered by the tested dolphin-mcp-pilot source. The useful point is not the count alone: the ReACT node can select and invoke a structured operation while preserving the tool name and returned data in the trace.

2. Observe a real FAILURE

The test process instance was deliberately allowed to enter the real DolphinScheduler terminal state FAILURE. This is scheduler evidence, not a recreated status card.

3. Use next_action correctly

The tool response included next_action, which led the Agent to inspect task nodes and the failed-task log. There is an important boundary here: next_action is a static hint generated by code from the current state. It is not a diagnosis produced by the model.

The failed-task log provided the evidence needed to locate the controlled external dependency. The external condition was then fixed by a human. The demo does not claim that the Agent repaired that dependency itself.

4. Rerun once, then keep checking

After the human fix, the Agent made one ds_rerun_from_failure call. DolphinScheduler returned submitted.

submitted is not success. In this trace it only means that DolphinScheduler accepted START_FAILURE_TASK_PROCESS. The Agent continued polling instead of treating the accepted request as the final result. Recovery was claimed only after the real scheduler state reached SUCCESS; the run count changed from 1 to 2.

Compatibility note: the isCache workaround

In the tested pairing of dolphin-mcp-pilot v0.3.0 and DolphinScheduler 3.2.2, task parameters generated by ds_create_workflow and ds_create_dag_workflow omitted the isCache field required by DolphinScheduler 3.2.2. The demo therefore created the workflow definition through ds_raw_post with a complete payload containing isCache.

This is an observed workaround for this version pair. It should not be generalized to every DolphinScheduler version, and the demo does not imply that either builder succeeded in this environment.

What the run demonstrates

The evidence supports five concrete capabilities:

Pipeline inspection from a natural-language request through a real MCP tool call.
Fault localization by moving from a failed process to its task nodes.
Log drill-down through structured Agent-callable operations.
Controlled recovery with a human fix before a single rerun-from-failure request.
Result verification by polling to a real terminal scheduler state.

The same pattern can support supervised data-engineering and ETL operations: routine inspection, failure triage, log collection, controlled recovery, and post-action verification. Moving it into production would still require deployment-specific authentication, authorization, network controls, approval gates, idempotency, audit logging, retry policy, and operational testing.

Watch the bilingual demos

Sources

Your Agent Can Think. But Can It Click? Why RPA Is the Missing Execution Layer

Fenju Fu — Tue, 11 Aug 2026 22:27:42 +0000

Today's GitHub Trending (2026-08-12) tells a clear story: the Agent ecosystem is growing up. But it's growing up in a very specific direction — toward the workplace.

Let me break down what's trending and what's missing.

What's Hot: Three Layers of Agent Infrastructure

Layer 1: Agent Management at Work

paperclipai/paperclip bills itself as「the open-source app everyone uses to manage agents at work.」The keyword isn't「manage」— it's「at work.」Agents have left the lab and entered the office. But once they're there, someone needs to manage who runs what, where results go, and who's responsible when things break.

Layer 2: Parallel Agent Fleets

stablyai/orca is an「ADE for working with a fleet of parallel agents.」Run any coding agent with your own subscription, on desktop, mobile, and VPS. The「fleet」metaphor is deliberate — it's not one agent, it's a squadron. And「your own subscription」hits developers right in the anti-lock-in sweet spot.

Layer 3: Long-Running Autonomous Tasks

PrimeIntellect-ai/prime-agent is「a self-improving RLM agent for coding workflows and long-running autonomous tasks.」Two keywords stack here: self-improving (gets better over time) and long-running (doesn't break after 5 minutes). Both address the hardest part of Agent autonomy — sustaining quality over time.

The Missing Layer: Execution

Here's what nobody on today's trending list is talking about: execution.

An Agent can analyze data and decide:「Extract fields from these 50 PDFs, fill out this web form, submit to the legacy CRM, and email the confirmation.」

But who actually:

Opens the PDFs and extracts the fields?
Navigates the web form UI?
Clicks submit in the legacy CRM?
Sends the email?

The Agent thought about it. The RPA does it.

Without an execution layer, you get an Agent that's all brain and no hands. It can plan the perfect workflow but can't push a single button.

RPA: The Hands of the Agent

This is where iflytek/astron-rpa comes in. It's an Agent-ready RPA suite with out-of-the-box automation tools, designed for both individuals and enterprises.

Think of it this way:

Layer	What it does	Today's trending example
Brain	Decides what to do	`PrimeIntellect-ai/prime-agent`
Management	Tracks who does what	`paperclipai/paperclip`
Scheduling	Runs agents in parallel	`stablyai/orca`
Execution	Actually does the work	`iflytek/astron-rpa`

Each layer solves a different problem. The Agent ecosystem doesn't need another brain — it has plenty. It needs hands.

The Human-Agent Collaboration Pattern

The real power isn't Agent-only or RPA-only. It's the combination:

Agent decides — analyzes the task, breaks it into steps, handles exceptions
RPA executes — clicks buttons, fills forms, moves files, runs batches
Human oversees — reviews results, intervenes on edge cases, approves critical actions

This is what「human-agent collaboration」actually means in practice. Not a human typing prompts and an Agent returning text. A human reviewing an Agent's plan, the RPA executing it, and the human checking the result.

Why This Matters Now

Today's trending repos prove the Agent ecosystem is maturing past the「can it think?」phase. The questions are now:

Can it run long enough? (prime-agent)
Can it run in parallel? (orca)
Can it be managed at work? (paperclip)
Can it actually do the work? ← this is the RPA question

If you're building Agent workflows and hitting the「Agent thought about it but can't execute」wall, you're not alone. The execution layer is the next frontier.

🔗 Check out: iflytek/astron-rpa — Agent-ready RPA suite, open source, enterprise-friendly.

And if you need the brain to go with those hands: iflytek/astron-agent — enterprise-grade agentic workflow platform for building SuperAgents.

Astron Open Source · Bi-Weekly Report (Jul 27 – Aug 9, 2026)

Fenju Fu — Tue, 11 Aug 2026 03:49:05 +0000

🌟 Highlights

Astron Agent climbed to # 4 on OSS Insight's three-month Java trending board, with 106 stars, 4 forks, 57 pushes, and 4 PRs in the snapshot. SkillHub ranked # 8, recording 46 stars, 19 forks, 92 pushes, and 4 PRs.
Three releases landed during the cycle: Astron Agent v1.1.1, SkillHub v0.2.15, and SkillHub v0.2.16.
The three core repositories merged 82 PRs: Astron Agent 24 · SkillHub 51 · Astron RPA 7.
Astron Agent expanded MCP interoperability and runtime resilience; SkillHub deepened its production deployment and governance capabilities.
HER Hack-Astron # 2 opened a ¥500 Langfuse observability bounty.

👥 Top 10 Active Community Contributors

Based on message volume across the open-source discussion groups (automated accounts such as the Astron Q&A bot and the welcome bot excluded); display-name aliases normalized and nicknames anonymized. Thank you to everyone who answered questions, asked questions, and built alongside us 🙌

📦 SkillHub v0.2.15 and v0.2.16

SkillHub merged 51 PRs and published two releases.

v0.2.15 — production Kubernetes and Redis HA

The new official Helm Chart covers PostgreSQL and Redis dependencies, external services, Ingress/TLS, S3, autoscaling, disruption budgets, upgrade safeguards, and OCI distribution through GHCR (# 445).
Redis can run standalone, in Cluster mode, or with Sentinel (# 505).
OAuth Device Flow, API-token errors, stale login bundles, rejected-version re-upload, label search indexing, CLI namespace coordinates, and PostgreSQL initialization all received reliability fixes (# 607, # 610, # 601, # 592, # 608, # 367).

v0.2.16 — base paths, built-in Skills, and observability

Deploy safely under reverse-proxy paths such as /skillhub/, including deep links, assets, APIs, and auth redirects (# 576).
A reviewed starter Skill collection now has deterministic package validation and runtime bootstrap checks (# 635, # 636).
Request/message correlation, selectable tracing, safer logging, and observable index rebuild failures improve production diagnosis (# 664, # 684).
React 19 overlays, label navigation, CJK ClawHub redirects, client errors, and version deletion received targeted fixes (# 624, # 625, # 674, # 685, # 641).

Ten contributors were highlighted as first-time contributors across the two release notes. Welcome! 🙌

🤖 Astron Agent v1.1.1

Astron Agent merged 24 PRs and published v1.1.1 on Aug 7.

MCP clients gained Streamable HTTP with safe SSE fallback. Auto mode does not retry authentication, TLS, or post-initialization failures across transports, preventing duplicate tool calls (# 1552).
CoT/streaming correctness improved for mixed reasoning and content chunks, usage-only chunks, and duplicate-call prevention (# 1581, # 1582, # 1589).
Workflow history, SSE disconnect behavior, callback isolation, and large LLM protocols became safer (# 1579, # 1584, # 1585, # 1595).
RAGFlow ingestion gained terminal-state protection, timeout/retry safeguards, parser-config application, and stronger large-document coverage (# 1597, # 1602).

⚙️ Astron RPA

Astron RPA merged 7 PRs. Team-market invite/application context was repaired (# 830, # 832); rpa-auth now defaults to the open-source Maven profile (# 833); and community troubleshooting for cloud desktops, client builds, scheduled tasks, and Agent ↔ RPA connectivity moved into the repository (# 824, # 829).

💬 What the community asked

Anonymized WeCom records surfaced recurring questions that are useful beyond a single environment:

Publish child workflows and complete required metadata before invoking them from a parent.
For workflow API attachments, upload to reachable storage, pass the URL, and use a plugin/dedicated service for parsing when the code sandbox cannot fetch or parse it.
JSON may display Chinese as \uXXXX escapes while still being transported as UTF-8; consumers must parse the JSON body.
A Skill upload's malformed input can come from invalid YAML frontmatter or non-UTF-8 archive paths.
SkillHub v0.2.16 supports reverse-proxy sub-path deployment when the web, public, and API base paths agree.
Deploying Astron RPA services does not install the desktop client; build/download and configure the client separately.

🏆 HER Hack-Astron # 2

The new challenge asks contributors to bring Langfuse observability to Astron Agent through native workflow instrumentation, extensible runner callbacks, or an OpenTelemetry/OTLP bridge. The winning contribution receives ¥500 RMB and the HER Hack-Astron # 2 Champion title; accepted submissions should include real trace evidence, disclose AI assistance as requested, and link the PR with Closes # 1575.

👉 Claim issue # 1575

🔗 Explore the ecosystem

Originally published in the iFLYTEK open source community discussions: https://github.com/orgs/iflytek/discussions/9

dolphin-mcp-pilot: Let AI Agents Actually Operate Apache DolphinScheduler via MCP (53+ tools)

Fenju Fu — Tue, 11 Aug 2026 02:27:51 +0000

The Model Context Protocol (MCP) has made it easy to give AI agents tools. But when it comes to Apache DolphinScheduler, most public MCP servers stop at read-only operations — list projects, start a workflow, stop it. That's fine for a demo, not for real data-engineering work.

dolphin-mcp-pilot is a production-ready MCP server built for the operations reality.

Beyond read-only: 53+ tools

It exposes 53+ tools across projects, workflows, DAG creation, schedules, instances, resources, logs, monitoring and raw API passthrough:

Create SQL and complex DAG workflows (multiple task types) in one call
Manage schedules — create / online / offline / delete (cron-based)
Full instance lifecycle control — pause / resume / rerun / rerun-from-failure / delete
View task logs, force task success, skip failed task
Resource content management, workflow version rollback and clone
Raw API passthrough as a safety valve for uncovered edge cases

Built for real, multi-tenant operations

Two auth modes: API Token (X-DS-Token) or User/Password (X-DS-User + X-DS-Password)
Multi-tenant HTTP mode: each caller can use its own credentials per request
FastMCP, Python 3.10+, Apache-2.0 licensed

Quick start

git clone https://github.com/iflytek/dolphin-mcp-pilot.git
cd dolphin-mcp-pilot
cp .env.example .env   # set DS_URL and DS_TOKEN (or DS_USER/DS_PASSWORD)
docker compose --profile dev up -d dolphin-mcp-pilot-dev

The service comes up at http://localhost:8001/mcp/ — point your MCP client (Claude Desktop, CodeBuddy, etc.) at it and your agent can start driving pipelines.

Why it matters

Data pipelines are exactly the kind of repetitive, error-prone, recovery-heavy work agents should help with — but only if they can do more than look. dolphin-mcp-pilot gives agents safe, credentialed hands on DolphinScheduler.

It's part of the iFLYTEK Astron open-source ecosystem. Repo: https://github.com/iflytek/dolphin-mcp-pilot

The Market Has Moved Past Build Your Own Agent — Here's Why That Matters

Fenju Fu — Mon, 10 Aug 2026 22:22:36 +0000

If you looked at GitHub Trending today, you'd notice something: three of the fastest-growing repositories aren't agent frameworks. They're agent products.

msitarzewski/agency-agents — 141K+ stars, described as a complete AI agency at your fingertips. Each agent comes with a personality, a process, and proven deliverables. You're not building anything. You're deploying a team.

addyosmani/agent-skills — 85K+ stars, offering production-grade engineering skills for AI coding agents. The keyword isn't skills — it's production-grade. As in: not a toy, not a demo, not a weekend experiment.

semantica-agi/semantica — nearly 1,000 stars in a single day, positioning itself as Graph-Native Infrastructure for Context and Accountable AI Systems. The keyword here is accountable. The market isn't just asking can the agent do it? — it's asking can the agent explain why it did it?

The pattern: from engine blueprints to car keys

For the past two years, the open-source AI agent ecosystem has been dominated by a single narrative: build your own agent. Frameworks, orchestration layers, memory systems, tool-calling abstractions — all necessary, all valuable, all aimed at the developer who wants to construct an agent from components.

But today's trending data suggests a pivot. The fastest-growing repositories aren't giving people better tools to build agents. They're giving people agents that are already built and ready to use.

This makes sense. The developer who was excited to build an agent in 2024 has, by mid-2026, likely built several. They've hit the same walls: agents that hallucinate, workflows that break at step 7, context windows that overflow. The novelty of I made an agent has worn off. The question now is: Can I actually use this thing to get work done?

What ready to use actually looks like

This is where iFLYTEK's approach stands out. Rather than offering another framework, iFLYTEK ships two working assistants:

AstronClaw — a cloud-based AI assistant
Loomy — a desktop AI assistant

Both are packaged products, not construction kits. And the tutorial repository at https://github.com/iflytek/astronclaw-tutorial doesn't teach you how to build an agent. It teaches you how to use one.

The distinction matters. When msitarzewski/agency-agents lists roles like frontend wizard and reality checker, it's not teaching you to build a frontend wizard. It's handing you one. When AstronClaw's tutorial walks you through voice transcription, OCR extraction, document translation, and proofreading, it's not teaching you to build a transcription engine. It's showing you where the button is and what happens when you press it.

The skills layer: where useful gets defined

An assistant is only as good as the tasks it can handle. addyosmani/agent-skills recognized this for coding agents — it's not about the agent's reasoning ability, it's about whether it has the craft to do code review, write tests, or refactor properly.

iFLYTEK's equivalent for assistant scenarios lives at https://github.com/iflytek/iFly-Skills — a collection of official capabilities covering voice recognition, OCR, translation, proofreading, and multimodal processing. These aren't abstract APIs. They're the concrete skills that AstronClaw and Loomy draw on when you ask them to do something useful.

Think about what this means in practice. You're not wiring up a speech-to-text pipeline. You're opening Loomy, saying something, and getting text. You're not configuring an OCR model. You're pointing AstronClaw at an image and getting extracted text. The skills are already there. The tutorial just shows you the scenarios.

The accountability question

Back to semantica-agi/semantica for a moment. Its rapid growth — nearly 1,000 stars in one day on a base of just 4,000 — signals something important: users want AI systems they can hold accountable. What did the agent do? Why did it do that? Can I trace its decision?

This is where tutorials have an underappreciated role. A good tutorial doesn't just teach how to use — it teaches how to verify. When you follow the AstronClaw tutorial and learn to run a translation task, you also learn what the output should look like, where it might go wrong, and how to check it. That's the accountability layer that separates a usable assistant from a black box.

Where to start

If you've spent the last year building agents and are ready to just use one:

Open https://github.com/iflytek/astronclaw-tutorial — pick a scenario that matches your daily work (voice, OCR, translation, proofreading).
Follow the walkthrough. No framework setup, no model configuration.
If you want to understand what's under the hood, explore https://github.com/iflytek/iFly-Skills for the underlying capability layer.

The market has spoken. The next wave of AI tooling isn't about building better agents — it's about making existing agents more useful. AstronClaw and Loomy are betting on that. The tutorial is your starting point.

Long-Running Agent Isn't About Being Smarter — It's About Not Breaking Mid-Workflow

Fenju Fu — Sun, 09 Aug 2026 22:14:09 +0000

Today's GitHub Trending tells a clear story. The #1 repo by daily stars, PrimeIntellect-ai/prime-agent, puts「long-running autonomous tasks」right in its tagline. pranshuparmar/witr asks「Why is this running?」— bringing process-level observability to developers. addyosmani/agent-skills ships「production-grade engineering skills」so agents actually know what to do at each step.

Three different repos, one shared signal: the Agent ecosystem has moved past「can it run?」to「can it finish?」

The Real Pain of Long-Running Workflows

Here's a scenario every enterprise developer has lived through:

You build a 6-step workflow — OCR a document → extract key fields → compare against a database → translate → proofread → archive. At step 5, a translation API times out. The entire workflow crashes. Steps 1–4? Gone. No breakpoint saved. No state persisted. You start over from OCR.

The problem isn't that the agent isn't smart enough. The problem is that there's no resumability. No checkpoint. No execution trace. When it breaks, you can't even tell which request in step 5 failed — you just see a wall of logs and start guessing.

What「Long-Running」Actually Means in Enterprise

When PrimeIntellect-ai/prime-agent says「long-running autonomous tasks,」it's making a promise: this agent won't die on you mid-run. That's a strong foundation.

But enterprise workflows need more than one resilient agent. They need a workflow orchestration platform that can:

Persist state at every step — so when step 5 fails, steps 1–4's outputs are still there
Resume from breakpoint — not restart from scratch
Trace every step's input and output — so「why did this step run?」is answerable in seconds, not hours of log diving
Retry failed steps independently — without re-running the entire chain

This is exactly what iflytek/astron-agent is built for. It's not trying to be a smarter agent. It's trying to be a workflow platform that doesn't lose your work when something breaks halfway through.

🔗 Repo: https://github.com/iflytek/astron-agent

The Execution Layer: RPA That Knows Where It Stopped

Observability isn't just for system processes — it's for automation workflows too. pranshuparmar/witr traces「who started this process?」for system-level debugging. The same question applies to RPA: who triggered this automation? Where did it stop? Why did it stall?

iflytek/astron-rpa brings this observability to the execution layer — an Agent-ready RPA suite that integrates with the orchestration platform above it. When astron-agent says「resume from step 5,」astron-rpa is the hands that actually execute step 5 again, with full visibility into what happened the first time.

🔗 Repo: https://github.com/iflytek/astron-rpa

The Triangle of Long-Running Agent Stability

Today's trending repos map perfectly to the three pillars of long-running agent stability:

Pillar	Today's Trending Repo	Astron Solution
Knows what to do	`addyosmani/agent-skills` (production-grade skills)	Skill layer (iFly-Skills, SkillHub)
Doesn't crash mid-run	`PrimeIntellect-ai/prime-agent` (long-running autonomy)	`astron-agent` (breakpoint resume, state persistence)
Traceable when things go wrong	`pranshuparmar/witr` (「why is this running?」)	`astron-rpa` (execution-layer observability)

The takeaway: a long-running agent isn't one piece. It's a triangle — skills + resumability + observability. Miss any corner, and your workflow becomes a workflow you run 3 times.

HER Hack-Astron #2: a bounty to bring Langfuse observability to astron-agent

Fenju Fu — Sun, 09 Aug 2026 11:20:56 +0000

When a multi-agent workflow returns a wrong answer, can you quickly answer these?

Which LLM call started drifting from what you expected?
Which tool execution or handoff node slowed the whole chain?
How many tokens, how much cost, and how much time did one workflow actually consume?
After a model or prompt change, did quality improve — or quietly regress?

As agents move from demo to production, the hard part is rarely "make it run." It's seeing how it runs, why it fails, and what each change did. HER Hack-Astron #2 opens exactly that engineering problem to the community: bring Langfuse observability to the enterprise-grade agent workflow platform astron-agent (already listed in the CNCF Landscape).

What the challenge asks for

Integrate Langfuse across astron-agent's workflow execution path so a full run becomes traceable:

Hierarchical traces — nest LLM calls, tool executions, retrieval, agent steps and handoffs into one traceable chain.
Cost & latency monitoring — token usage, model cost, per-node and end-to-end latency.
Evaluation — LLM-as-a-judge, custom scores and user feedback, so quality regressions have evidence.
Enterprise deployability — Langfuse self-hosts, which fits data, audit and compliance requirements.

This isn't a "add a doc page" or "stub an interface" task — it's a contribution that can land in the main tree and serve real production debugging and quality governance.

Three routes (pick one, or combine)

1. Native instrumentation. Wrap workflow execution nodes with the Langfuse SDK, writing key LLM / tool / retrieval / agent calls into traces, plus config for toggle, keys and host. Most direct path to a complete, usable chain.

2. Callback / hook. Give the workflow runner an extensible callback interface, then implement a Langfuse callback on top. Solves this integration and leaves a clean boundary for future observability backends. More about interface abstraction and compatibility.

3. OpenTelemetry bridge. Reuse the repo's existing OpenTelemetry infrastructure — export via OTLP with semantic conventions into Langfuse. Can stay compatible with Jaeger, Grafana and the wider OTel ecosystem at the same time.

Whichever route, a submission should include: substantive code changes; config + usage docs; a reproducible run example; and real Langfuse traces (or equivalent verification evidence).

What counts as "done"

The bar is real, runnable, reproducible — not lines of code. A PR must provide at least one of:

A screenshot or short video of real traces in the Langfuse dashboard, showing nested LLM / tool / retrieval / agent-step info.
Local run logs with full repro steps — config, launch, and the command that triggers a trace.
Concrete Langfuse output: trace IDs, cost / latency data, or evaluation results.

Stub code, empty docs or placeholder PRs don't count. If you used AI assistance, disclose the agent / model, main prompts, and what you personally designed and verified at the top of the PR description — tooling can speed you up, but you own the design, verification and final code.

Rewards

Champion (1): 500 RMB cash / equivalent gift card, plus the "HER Hack-Astron #2 Champion" title.
Outstanding contributions (several): an Astron swag pack, 5000 Loomy points, or a coffee voucher.

Who can join

HER Hack-Astron is an open-source challenge built to support women developers' participation and growth — individuals or teams welcome. The one hard requirement: women contributors must account for at least 50% of the code changes in the PR. You don't have to be a Langfuse or astron-agent veteran; familiarity with any of Python, agent workflows, OpenTelemetry, distributed tracing or evaluation systems is enough to start from the issue discussion.

How to submit

Read Issue #1575 for the goal and acceptance criteria.
Fork iflytek/astron-agent, do the code + docs + example on a branch.
Open a PR titled [HER Hack-Astron #2] Langfuse integration + <your highlight>.
Add Closes #1575 to the PR description.
Attach reproducible steps and real trace evidence, then wait for maintainer review.

Commenting your intended route and rough design on the issue before coding usually saves everyone a duplicated implementation.

Get started

Challenge & acceptance criteria: Issue #1575
Project repo: iflytek/astron-agent
About HER Hack-Astron: call for partners
Community discussions: iflytek discussions

Observability decides whether an agent system can be debugged, evaluated, and ultimately trusted in production. If you want one clean, end-to-end infrastructure contribution that lands in a real open-source project, HER Hack-Astron #2 is waiting.

Her Code, Her Impact.

Agent Skill Packs Are Booming — But They're All Coding Skills. What About Multimodal?

Fenju Fu — Sat, 08 Aug 2026 22:09:46 +0000

Today's GitHub Trending tells a clear story: agent skill packs are hot. Three repos on the list — addyosmani/agent-skills (84K+ stars), google/skills (16K+ stars), and mattpocock/skills (209K+ stars) — all package skills that AI coding agents can use.

The skills they cover? Code review, refactoring, test generation, clean architecture patterns, dependency management. All coding. All engineering.

This makes sense. The first wave of AI agents was coding agents — Cursor, Copilot, Windsurf — so the first wave of skill packs naturally serves that use case.

But here's the gap: what about agents that work in offices, not IDEs?

The Multimodal Skill Gap

Imagine an office agent that receives: "Process these invoices, translate the contract from Chinese to English, and proofread the report before submission."

What skills does it need?

OCR: Extract text from tilted, photographed, or scanned invoices — not clean PDFs, real-world paper.
Translation: Handle contracts with nested tables, mixed languages, and domain-specific terminology.
Proofreading: Catch typos, grammar issues, and formatting inconsistencies in formal documents.
Speech: Transcribe meeting recordings, convert voice notes to structured text.

None of these are coding skills. They're multimodal capabilities — and there's no trending skill pack for them.

Why Multimodal Skills Are Harder to Package

Coding skills are text-in, text-out. A refactoring skill is a prompt template with some context. Relatively easy to package, version, and share.

Multimodal skills are different:

OCR needs to handle image quality, tilt, lighting, and layout complexity.
Translation needs domain models (legal, medical, technical) — not just general-purpose NMT.
Proofreading needs to understand document structure, not just string matching.

This is why most skill pack repos skip multimodal: it's harder to make a generic prompt template for "OCR this tilted invoice" than for "refactor this function."

The Official + Vertical Approach

Two patterns from today's Trending are worth noting:

"Production-grade" trust anchor (addyosmani): Labeling skills as "production-grade" signals "not a toy." Developers trust it.
Official backing (google/skills): Google's official label builds instant trust. Developers prefer "official" over "community-sourced" for critical capabilities.

Both patterns apply to multimodal skills — arguably even more strongly. You don't want to OCR financial documents with an unverified community script. You want an officially maintained, enterprise-tested capability.

This is the approach behind iflytek/iFly-Skills — an official skill collection covering speech recognition, OCR, translation, proofreading, and multimodal capabilities. Not community-sourced prompt templates, but officially maintained capabilities from a team that has been building these specific technologies for years.

The Composition: Skills + Orchestration

Skills alone aren't enough. A coding skill pack + a coding agent = a working coding workflow.

Similarly, a multimodal skill pack + an orchestration platform = a working office workflow.

This is where iflytek/astron-agent comes in — an enterprise-grade agentic workflow platform for building SuperAgents. It handles the orchestration: "OCR these invoices → extract amounts → translate the contract → proofread the summary → archive everything."

PrimeIntellect-ai/prime-agent (today's #1 with 2,483 stars) proves that developers want agents that "run long and self-improve." But long-running coding agents and long-running office agents need different things — one needs refactoring skills, the other needs OCR skills.

The Takeaway

The skill pack ecosystem is maturing — but it's lopsided. Coding skills have three trending repos and 300K+ combined stars. Multimodal skills have zero.

If you're building office agents, not coding agents, your skill layer needs to look different. And if you're packaging multimodal capabilities for agents, the bar is higher — but so is the opportunity.

Links:

Multimodal skills: https://github.com/iflytek/iFly-Skills
Agent orchestration: https://github.com/iflytek/astron-agent

Cloudflare Gave Your Agent a Computer. But Who Teaches It the Workflow?

Fenju Fu — Fri, 07 Aug 2026 22:21:31 +0000

Today's GitHub Trending (Aug 8, 2026) sends a clear signal: the Agent ecosystem has moved past "can it think?" to "can it actually do the work?"

Three repos tell the story:

cloudflare/computer (+894⭐ today) — "Give your agent a computer 👾." A cloud desktop with a browser, filesystem, and GUI. Your agent finally has hands.

PrimeIntellect-ai/prime-agent (+2,271⭐ today, the highest daily gain) — A self-improving RLM agent for coding workflows and long-running autonomous tasks. Your agent can now run for hours without breaking.

addyosmani/agent-skills (+1,131⭐ today) — Production-grade engineering skills for AI coding agents. Your agent now has domain knowledge.

Add google/skills (+305⭐) and mattpocock/skills (+2,180⭐) to the mix, and the pattern is clear: agents have hands, stamina, and skills.

The Missing Layer

But let's paint a real picture.

Imagine an operations specialist. Every morning at 9 AM, they: log in to the OA system, export yesterday's sales data from ERP, paste it into a daily report template, post it to a team chat, then scan expense receipts and enter them into the financial system.

Forty minutes. Every single day. Same sequence. Same buttons.

Now, with cloudflare/computer, your agent has a desktop. With prime-agent, it can run long enough. With agent-skills, it has coding knowledge.

But who tells the agent: "First click the OA login button, then navigate to the ERP export page, then download the CSV, then open the report template, then paste, then send to chat group #daily-ops"?

That orchestration — the workflow layer — is the gap.

Enter RPA + Agent

This is exactly what iflytek/astron-rpa is built for.

Not "give your agent a computer and let it figure out the GUI." But "give your agent a ready-to-use RPA toolkit that already knows the workflow sequence."

astron-rpa is an Agent-ready RPA suite — out-of-the-box automation tools for individuals and enterprises. The idea is simple: you define the workflow (login → export → fill → submit), and the agent executes it unattended. No GUI exploration, no "let me figure out where the button is." The RPA layer already knows.

The Skills Layer for Office Automation

Today's trending repos also show that "skills" are becoming a first-class concept. addyosmani/agent-skills gives coding agents engineering skills. google/skills provides skills for Google products.

But office automation needs office skills — OCR for receipt scanning, translation for cross-border documents, proofreading for outgoing reports.

That's where iflytek/iFly-Skills fits in. As iFLYTEK's official skill collection, it provides voice, OCR, translation, proofreading, and multimodal capabilities — exactly the capabilities that RPA workflows call most frequently.

The Stack Is Forming

Layer	What It Does	Today's Trending Example
Execution environment	Give the agent a computer	`cloudflare/computer`
Long-running capability	Let the agent run for hours	`PrimeIntellect-ai/prime-agent`
Domain skills	Teach the agent domain knowledge	`addyosmani/agent-skills`, `google/skills`
Workflow orchestration	Tell the agent what sequence to execute	`iflytek/astron-rpa`
Office capabilities	OCR, translation, proofreading	`iflytek/iFly-Skills`

The first three layers are well-covered by today's trending repos. The last two — workflow orchestration and office-specific capabilities — are where astron-rpa and iFly-Skills fit.

If you're building office automation with agents, check them out:

iflytek/astron-rpa — Agent-ready RPA suite
iflytek/iFly-Skills — Official iFLYTEK skill collection

The Missing Layer in Today's Agent Stack: Multi-Agent Orchestration

Fenju Fu — Fri, 07 Aug 2026 01:28:27 +0000

Today's GitHub Trending page reads like a shopping list for building a single Agent's body:

cloudflare/computer (+2,802 stars today) — give your Agent a computer, a screen, a browser, a filesystem. Now it can operate GUI environments.
TencentCloud/TencentDB-Agent-Memory (+1,057 stars today) — a team-level memory hub turning conversations, docs, and code into four reusable memory assets shared across Agents and frameworks.
addyosmani/agent-skills (+593 stars today) — production-grade engineering skills for AI coding agents.
obra/superpowers (+858 stars today) — an agentic skills framework and software development methodology that works.

Each of these repos solves one piece of the puzzle. And they're all excellent at what they do.

But here's the question nobody on today's Trending is answering:

When a complex enterprise task requires multiple Agents to collaborate — who decomposes the task, who orchestrates the flow, who manages the handoffs?

The gap in the stack

Imagine a scenario: your team needs to process a batch of customer feedback into a quarterly report. This involves:

Agent A — collects and classifies raw feedback from multiple channels
Agent B — performs sentiment analysis and topic clustering on the collected data
Agent C — generates a structured report with charts and recommendations

Each Agent needs different capabilities: A needs data collection skills, B needs NLP skills, C needs document generation skills. They need to run in sequence, but with conditional branching — if B finds an anomaly, it might loop back to A for deeper collection.

cloudflare/computer gives each Agent a computer to operate. TencentDB-Agent-Memory lets them share what they've learned. addyosmani/agent-skills and obra/superpowers give them individual capabilities.

But none of them answers: who decides Agent A runs first, who routes A's output to B, who handles the conditional branch from B back to A, who knows when the whole flow is done?

This is the orchestration layer

This is exactly the gap that iflytek/astron-agent fills — an enterprise-grade, commercially-friendly agentic workflow platform for building SuperAgents.

The core idea: you define a complex task, and the platform decomposes it into a multi-Agent workflow with:

Task decomposition — break a complex goal into sub-tasks, each assigned to the right Agent
Flow orchestration — define execution order, conditional branches, loops, and parallel paths
Handoff management — manage intermediate results passing between Agents, with verifiable handoff points
Execution scheduling — handle long-running workflows with durable state, so a multi-step flow doesn't lose progress if something restarts

Orchestration + Execution = Full Pipeline

For the execution layer, iflytek/astron-rpa provides Agent-ready RPA automation — open-box tools for browser and desktop operations. So your orchestrated multi-Agent workflow can actually「do things」in real environments, not just reason about them.

Think of it this way:

cloudflare/computer gives a single Agent an environment to operate in
iflytek/astron-rpa gives a single Agent the tools to operate with
iflytek/astron-agent orchestrates multiple Agents into a collaborative workflow

The first two are about individual Agent capability. The third is about team-level coordination — and that's the layer today's Trending is missing.

The signal from today's Trending

When you see Cloudflare, Tencent Cloud, Addy Osmani, and the superpowers team all shipping Agent infrastructure on the same day, the signal is clear: single-Agent capabilities are becoming commodity infrastructure. The next differentiator is not「my Agent is smarter」but「my multi-Agent workflow is better orchestrated.」

If you're building Agent systems for enterprise use cases, the question to ask today is not「what new capability can I give my Agent」but「how do I orchestrate multiple Agents to handle complex, multi-step, real-world tasks?」

That's the layer astron-agent lives in.

🔗 iflytek/astron-agent: https://github.com/iflytek/astron-agent
🔗 iflytek/astron-rpa: https://github.com/iflytek/astron-rpa

Your AI Agent Has a Computer and Memory — But Who Manages Its Skills?

Fenju Fu — Thu, 06 Aug 2026 08:30:54 +0000

Today's GitHub Trending tells an interesting story about what AI agents are missing.

cloudflare/computer gives your agent a computer — a cloud desktop with a browser, file system, and GUI. Your agent finally has hands.

TencentCloud/TencentDB-Agent-Memory gives your agent a team-level memory hub — turning conversations, docs, and code into four governable memory assets. Your agent finally has a persistent brain.

obra/superpowers gives your agent a skills framework — a structured collection of agentic capabilities with a development methodology. Your agent finally has... abilities.

But here's the question nobody is answering: who governs those skills?

The gap in the stack

Let me paint a picture. Imagine a five-person team, each member writing skill packs for their agents. One writes an OCR extraction skill. Another writes an email classification skill. Everyone maintains their own, iterates on their own.

One day, someone pushes a breaking change to their skill pack. Nobody else knows. The agent breaks in production. Two hours of log-diving later, they trace it back to an unversioned, untracked skill modification.

This isn't a hypothetical problem — it's the reality for most teams building with AI agents today. Skills are scattered across local repos, shared via Slack, versioned by filename (skill_v2_final_FINAL.py), with no access control and no audit trail.

What a skill registry actually does

This is where iflytek/skillhub comes in. It's a self-hosted, open-source skill registry for AI agents that handles three things nobody else covers independently:

Skill package publishing & version management — every skill has a version number, every change is trackable, breaking changes are visible before deployment.
RBAC permissions — not everyone on the team can publish or modify skills. Roles are defined, access is controlled.
Audit logs — when a skill breaks in production, you know who changed it, when, and what the diff is.

Why this matters now

The trending repos today prove that agent infrastructure is maturing. We have environments (cloudflare/computer), memory (TencentDB), frameworks (superpowers), and even security shields (uber/ADR). But the skill layer — the actual capabilities agents use to do work — is still the Wild West for most teams.

addyosmani/agent-skills curates production-grade engineering skills for AI coding agents. It's a great collection. But a collection isn't a registry. A GitHub repo of skills doesn't tell you who modified what, who has permission to deploy, or which version is safe to use in production.

A skill registry is the missing layer between having a bunch of skills and having governable, version-controlled, auditable agent capabilities.

The full picture

If you're building agent systems, the stack is shaping up to look like this:

Environment: where your agent runs (cloudflare/computer)
Memory: what your agent remembers (TencentDB-Agent-Memory)
Skills: what your agent can do → needs a registry (iflytek/skillhub)
Orchestration: how your agent coordinates tasks (iflytek/astron-agent)
Security: how your agent is protected (uber/ADR)

Each layer is independently important. Today, the skills layer is the one most teams are leaving to chance.

If your team is managing agent skills as loose files, it might be time to give them a registry: https://github.com/iflytek/skillhub

Collection, harness, registry: where each agent-skills project actually sits

Fenju Fu — Wed, 05 Aug 2026 12:17:17 +0000

A question that keeps coming up from people arriving here after using one of the big skill projects: "I already get my skills from a collection, and my agent already installs them — what does a registry add?"

Fair question. Here is the honest map, written as a landscape rather than a pitch.

Three layers, not three competitors

The agent-skills ecosystem has settled into three distinct layers. Most projects are excellent at exactly one of them.

1. Content — curated collections. anthropics/skills popularized the Agent Skill format itself (a SKILL.md with name / description frontmatter plus supporting files). mattpocock/skills is opinionated taste applied to that format — skills kept deliberately small, composable and model-agnostic, shipped straight from a working .agents directory. Its two install paths are a genuinely interesting design fork: the Claude Code plugin gives you a managed, read-only bundle you subscribe to, while skills.sh copies editable files into your project so you can fork and hack. Subscribe-vs-fork is a real distribution philosophy question, and both answers are defensible.

2. Runtime — the harness. openclaw/openclaw is where skills actually execute: cross-platform, personal-assistant-shaped, shipping a large first-party skills/ tree of its own, with ClawHub as its distribution and publishing path. The harness owns invocation, sandboxing and the user-facing loop.

3. Infrastructure — the registry. That is SkillHub. It is a registry and governance platform, not a skill collection. It answers a different question from the two above: when the skills are yours and private, who may publish them, which version is running in production, who approved it, and what happened last Tuesday?

	Curated collection	Harness	SkillHub
Owns	The skills and their taste	Execution + the user loop	Hosting, versioning, access control
Source of truth	A public Git repo	The local install tree	Your own deployment, behind your firewall
Versioning	Git history	Whatever was installed	Semantic versions, `beta`/`stable` tags, `latest` tracking
Access	Public	Local	Namespaces, RBAC, review workflow, audit log
Distribution	Clone / copy / plugin subscribe	Harness-native install	Full-text search + CLI install

None of this is a criticism of layers 1 and 2. A registry is the wrong tool for distributing taste, and a curated public collection is the wrong tool for distributing your company's internal deployment runbook to 300 engineers with an approval trail.

The interop already exists — and that's the point

Same format. SkillHub speaks the same SKILL.md layout, so a skill from any Agent Skill folder publishes straight into a private registry without repackaging.
ClawHub-compatible endpoints. The server ships a compatibility layer so existing ClawHub-style registry clients keep working against a SkillHub deployment. Native CLI APIs are the primary interface; the compat surface exists so nobody has to rewrite a client to try this.
A harness-neutral install target. CLI 0.1.9 added installation into the user-level ~/.agents/skills directory, usable on its own or alongside agent-specific locations such as ~/.codex/skills and ~/.claude/skills, with canonical-path checks to stop conflicting destinations. .agents/ is quietly becoming the cross-harness convention — it is, after all, the directory the collections themselves are shipped from.

What we are explicitly not trying to do

Out-curate anyone. Skill quality is editorial work and the collections are better at it. If your team's answer is "we just install a public collection and it's great" — that is a complete answer, and you do not need a registry until you have private skills plus someone who has to sign off on them.

The question we actually want answered

If you run skills across more than one harness, we would like to hear about the concrete incompatibilities you have hit — not opinions, but reproducible ones:

A SKILL.md frontmatter field that one harness requires and another rejects.
A package that validates in one toolchain and fails in another.
A metadata block a harness needs (invocation hints, permission declarations) that has nowhere to live in the shared format.

Cross-harness skill validation is the part of this problem we have the most direct experience with, and concrete breakages are far more useful than a standards debate.

Discussion thread: https://github.com/iflytek/skillhub/discussions/691