是智能體造成的嗎？如何對照核心數判讀系統負載、每核心 CPU、記憶體與温度

This article was prepared with AI assistance, using ccdeck’s source code and documentation to check the technical details.

I build ccdeck, a local dashboard for Claude Code and Codex sessions. Its This machine panel is the worked example here. The Linux facts come from the linked man pages and kernel documentation. The panel examples were checked against 3.48.0 and rechecked against the public README on 1 November 2026. All pictured readings, including the cover, are demo data rather than measurements of a real workload.

The fans spin up and the laptop gets hot under your wrists. Nothing you started is heavy. But four agents are running, and in the last ten minutes each of them decided the right next step was to run the test suite, a type check and a bundler, all at once.

The questions are old ones: is the machine actually overloaded, by what, and how hot is it? The numbers that answer them are easy to misread. Here is how to read each one, with ccdeck's panel as an example of putting them next to the sessions that cause them.

Load average is a queue, not a percentage

The first three fields of /proc/loadavg count runnable tasks and tasks in uninterruptible I/O waits, averaged over 1, 5 and 15 minutes (proc_loadavg(5)). The figures are not divided by CPU count: the same load can mean very different things on a one-core and a sixteen-core machine.

So the number only means something next to your core count:

awk -v n="$(nproc)" '{ printf "1-minute load %.2f on %d cores: %.2fx\n", $1, n, $1/n }' /proc/loadavg

Above 1.00x, the average count of running or waiting tasks exceeds the number of available logical CPUs. That is a reason to investigate, not a diagnosis by itself. Two cautions:

• On Linux, the queue includes tasks waiting for disk (state D). A high load with idle CPUs points at I/O; top's wa field is "time waiting for I/O completion".
• Windows publishes no load average, so there is no such figure to read there.

ccdeck's panel does this division for you: when the one-minute load is above your core count, a line says by how much, as in 1.2× more work queued than cores to run it.

Demo data: a 16-core Linux computer while the demo sessions run their tests.

One pinned core hides in the total

On a 16-core machine, one single-threaded build at 100% is 6.25% of the whole. The total looks calm while that build is as fast as it will ever be.

Look per core instead. In top, the 1 key is the "Single/Separate-Cpu-States toggle"; mpstat -P ALL 1 (from sysstat) prints the same every second. ccdeck's panel draws one column per logical core under the total for this reason, and never colours CPU as a warning: at 90%, the computer is doing the work you asked for.

A process's %CPU is per core, and ps averages over its lifetime

Two tools, two meanings:

• top: a multithreaded process can exceed 100% in Irix mode. Solaris mode divides the figure by the number of CPUs; I switches between them.
• ps: %cpu averages CPU time over the process's elapsed lifetime. A test runner that has been busy for ten seconds and idle for an hour looks quiet in ps.

So 312 in a per-core column is a little over three cores, and a ps figure is history, not now. ccdeck's Busiest processes list uses the per-core convention: the 40 busiest processes by CPU and the 40 largest by memory, with the resident size, the figure ps and Task Manager show.

Demo data: one session's tests, bundler and type check are the three busiest.

Finding the session behind a process is the step no single number gives you. On Linux, the process tree does:

ps -eo pid,ppid,pcpu,rss,args --forest | less -S

--forest draws the tree ("ASCII art process tree"), so a vitest shows up under the claude or codex process that started it, and pwdx <pid> prints its working folder, which you can match to a session. ccdeck's list does not make that link for you; you see vitest at 312 and a session running tests, and connecting the two is still yours. It also cannot end a process; that belongs to a terminal, Activity Monitor or Task Manager.

Memory: trust "available", not "used"

/proc/meminfo has a field made for the question "can I start more work?": MemAvailable, an estimate of memory available to new applications without swapping. On Linux, total minus available gives a pressure-oriented view of physical memory in use. The example panel shows this as Physical and turns its bar amber from 90%. It shows swap separately; on Windows that second row is Commit, a different measure from physical RAM.

GPUs: ask the driver

An NVIDIA card's own figures come from its driver's nvidia-smi, on Linux and Windows. ccdeck's panel asks it every 5 seconds for each GPU's utilization, video memory used and total, temperature and power, and draws a section per GPU; with no nvidia-smi on the PATH it draws none and installs nothing. It keeps no history of these, and they are the GPUs in your computer, not the ones running a cloud model.

Temperature: where each system keeps it, or does not

Linux: sysfs, in millidegrees

Two places, both readable without root:

• hwmon: each /sys/class/hwmon/hwmonX has a name (such as coretemp or nvme) and tempY_input files, in "millidegree Celsius" (kernel ABI).
• thermal zones: /sys/class/thermal/thermal_zoneX/temp, also in millidegrees, with a type such as acpitz, "an ACPI thermal device" (kernel ABI).

for h in /sys/class/hwmon/hwmon*; do
  printf '%-12s %s\n' "$(cat "$h/name")" "$(cat "$h"/temp*_input 2>/dev/null | head -1)"
done

On Intel, the kernel also reports thermal throttling per CPU under /sys/devices/system/cpu/cpuX/thermal_throttle/: event counts and cumulative active time, including core_throttle_total_time_ms and its package counterpart (kernel docs). Sample an active-time counter twice and divide its increase by the elapsed time to estimate the fraction of that interval spent throttling. ccdeck reads hwmon first, then thermal zones; its Linux throttling reading uses changes in package_throttle_total_time_ms, not the event count alone.

macOS: readable on Intel, private on Apple silicon

On an Intel Mac, ioreg gives the GPU and pmset says how much of the CPU's speed is held back to cool it. On an M-series Mac, no command that ships with macOS prints a temperature: powermetrics needs root, pmset -g therm records nothing there, and the sensors sit behind a private API only native code can call. macmon reads them without sudo.

ccdeck does not ask you to install it. When the Mac's own sensors give nothing, it downloads macmon's published binary from GitHub once, verifies it against the SHA-256 the release publishes, checks that it runs, and keeps it in ~/.agents-deck/tools/macmon. That is skipped if macmon is already on your PATH or from Homebrew, on an Intel Mac, and under AGENTS_DECK_NO_DOWNLOAD=1 or AGENTS_DECK_NO_INSTALL=1.

Windows: often nothing, and that is the honest answer

The places an ordinary program can look are a performance counter, MSAcpi_ThermalZoneTemperature, and LibreHardwareMonitor's web server if you happen to run it. On many Windows laptops, all of them come up empty. ccdeck's README documents one such machine, a Windows 11 laptop with an Intel i5-9300H, checked as a normal user and as an administrator:

• Its firmware declares zero ACPI thermal zones, so the performance counter exists but has no instances.
• MSAcpi_ThermalZoneTemperature answers Not supported, even to an administrator.
• Win32_TemperatureProbe exists, but every field reads 32768, WMI's value for "unknown".
• The sensors are real, managed by Intel Dynamic Tuning, which publishes them where only an administrator can read.

That is a class of machine, not a fault. There is no standard user-mode Windows API for CPU temperature, which is why HWiNFO, Core Temp and LibreHardwareMonitor all install a kernel driver.

And a thermal zone is not the CPU. It measures whatever the firmware wired it to, and on many laptops nothing: Intel's reference firmware then reports a fixed 27.85 °C, so the zone reads 28 °C however hot the CPU is. A figure that never moves is a placeholder. ccdeck draws a zone only once its value has changed, and calls the row Thermal zone, never CPU.

Virtual machines often expose no temperature sensor. When a sensor is unavailable, displaying 0 °C would confuse a missing value with a measurement; leave the reading unavailable instead. A constant value deserves investigation rather than automatic treatment as a real CPU temperature.

Keep a little history, at the right resolution

A spike you did not see is the one you are asking about. ccdeck keeps up to a day of each reading in memory, one point per minute holding that minute's highest value, so a short spike is not averaged away; dashed lines mark where memory, swap and the queue turn amber or red. It is memory only, so it starts again when the deck restarts. If you log your own, keep the maximum per bucket, not the mean.

The machine readings are local and served on 127.0.0.1. The panel's latency indicator additionally performs a DNS lookup and TCP handshake to api.anthropic.com:443 about every 30 seconds while it is open on a machine with Claude Code; it sends no application payload. An Apple silicon Mac may also need the macmon download described above. These are the machine panel's network operations, not an inventory of the entire application's traffic.

The short version

• Divide the 1-minute load by nproc. Above 1, work is queued; on Linux, check wa before blaming the CPU.
• Look per core. One pinned core is invisible in the total.
• In top, 312% is about three cores; in ps, %CPU is a lifetime average.
• Trust MemAvailable, not "used".
• Temperatures live in sysfs on Linux, behind a private API on Apple silicon, and often nowhere an ordinary program can reach on Windows laptops. No reading is a valid answer; a fixed 28 °C is not a reading.