In-depth analysis · About 5 min read
AnolisOS-SysDiag packages diagnostic work for agents, with a human decision at the end
OpenAnolis’s October 19 showcase describes four-resource collection and OS-specific advice; its walkthrough is not a universal repair-time benchmark.
- Source published
- Published here
- Source checked
An OpenAnolis community article dated October 19 features Wang Yangke’s AnolisOS-SysDiag Skill. It aims to turn repeated command collection and interpretation into an agent-callable diagnostic workflow. This is a developer’s tool account, not a new operating-system release or proof that an agent can safely repair any Linux host. We read the full article without running its commands or software.
Listen to the news
Read this article aloud or keep listening to the news.
Preparing the reader…
Device voice
Speech is handled by your browser or device. AISubHub does not send the text to an audio API. Voice availability and playback with a locked screen vary by device.
Resuming may repeat a short phrase.
At a glance
- The proposed workflow combines CPU, memory, disk I/O and network signals, then produces an explanation and suggested action. Correlated signals still require validation before being treated as a confirmed cause.
- The author’s three-minute scenario is not an independent MTTR study. eBPF integration, historical comparisons, cluster-wide diagnosis and preinstallation are described as future ambitions.
A focused diagnostic skill, not an all-purpose operator
The article defines four areas: CPU usage, load and scheduling signals; memory, cache, swap and out-of-memory records; disk IOPS, throughput, latency and queues; and network traffic, connections, retransmissions and loss. The intended output is a report linking observations to a proposed cause and fix, rather than a collection of unrelated terminal output. The author deliberately narrows the scope instead of building a universal system toolbox. Our interpretation is that this focus can make evidence easier to review, but a complete-looking report does not demonstrate that all relevant failure modes were observed.
The sample report supports a hypothesis, not certainty
The walkthrough shows page cache at 78%, available memory below 5%, three reclaim events and average disk await of 45 milliseconds. The author connects these to reclaim-related I/O delay. Those are figures in a published example, not readings from our server or a universal threshold. The article also tells an earlier troubleshooting story lasting nearly forty minutes and later illustrates a report in three minutes; they are not a controlled before-and-after experiment. We would ask an operator to validate timing, competing causes and relevant workload evidence before accepting the causal explanation or reporting a speedup.
Anolis-specific guidance should not become generic tuning
The Skill is described as detecting Anolis and selecting dedicated knowledge about Group Identity scheduling, an SLO scheduler and the sysAK toolchain. The author argues that generic Linux advice may be unsuitable for customized kernels. That is precisely why a parameter recommendation should retain its operating-system and workload context. The sample includes kernel-setting changes and service restarts, but we do not reproduce them as instructions for an unknown host. Our analysis is to separate observation, proposed intervention and post-change verification, preserving approval and recovery rather than assuming a suggested value is universally safe.
Client integration does not settle execution permissions
The article names Claude Code, Cursor, Gemini CLI, Windsurf and OpenCode as supported clients and says the tool portion can be exposed as an MCP server. That describes an integration option, not a server we installed or tested. The piece explains structured instructions and interpretation in SKILL.md, rather than simply listing commands. Before adopting such a workflow, a team should inspect the actual code, required privileges, data handling and supported host versions. This is our evaluation advice, not a claim that we completed that inspection or verified every client combination.
An automation loop still needs an accountable operator
The author describes combining the Skill with SysOM Agent: an anomaly triggers diagnosis and a report is sent to DingTalk. The stated final decision remains with a person. That scenario should not be presented as proof of autonomous remediation or as authorization to message a group. An operator would need to establish trigger ownership, recipients, approval for changes and what happens when evidence is incomplete. The article’s submission discussion also concerns format and conventions; passing a community format review cannot alone establish production correctness. We did not configure an alert, send a message or execute a repair.
Keep future plans separate from today’s description
The near-term list proposes eBPF-based kernel diagnosis, historical comparison and batch cluster checks. Longer-term ideas include cooperation with other skills and entry into an Agentic OS preinstallation pool. These are plans, not delivered features verified here. A bounded trial should therefore start with the currently described four-resource report, a known test case and a human-reviewed acceptance rule. The release gives a concrete example of packaging diagnostic expertise, but does not publish a general repair SLA, subscription price or independently established safety guarantee. Code and license review are still needed before deployment.
Why it matters
The useful idea is to make collection and interpretation repeatable while preserving an operator’s judgment. A pilot could test whether a report supplies enough evidence to confirm or reject its diagnosis before approving any change.
Limits and availability
These capabilities and examples are the author’s description, not AISubHub measurements. We did not read the linked Skill implementation or license, install an MCP server, collect host telemetry or alter a system. Compatibility, permissions and repair effectiveness remain unverified.
Sources and evidence
Source published: Oct 19, 2026 · Source checked: Oct 20, 2026
AI-assisted editorial articles checked against linked primary sources. Vendor claims are attributed; inclusion is not endorsement.