easyeda-agent: typed schematic and PCB actions for EasyEDA Pro

The problem: raw JavaScript execution is a bad interface for a model

EasyEDA Pro exposes an official eda.* API with 86 namespaces, according to the README. The upstream run-api-gateway project proved that code can run inside EasyEDA and reach that object. The easyeda-agent authors argue that gateway treated bare JavaScript execution as the primary workflow, which they call powerful but too fragile for an AI agent. That is the gap this project claims to fill: instead of handing a model a JavaScript console and hoping, it exposes a typed action catalogue that the daemon validates, routes and records. The intended user is someone who already designs in EasyEDA Pro and wants an agent to do repetitive placement, wiring, export and checking work while leaving an audit trail. It is not aimed at people who want a headless EDA toolchain, and it is not a replacement for the official API: the connector is deliberately thin and only bridges to eda.*, while the Go CLI and daemon own protocol, state, artefacts and validation.

Architecture: a fixed port, a thin connector and a typed action catalogue

The data flow described in the README runs in five steps. A person or a Skill runs an easyeda command. The Go CLI validates the input and submits a typed action to a local daemon. The daemon tracks connected EasyEDA windows, routes each action over WebSocket, and records audit logs, artefacts and validation results. The connector extension running inside EasyEDA calls the official eda.* API. Structured results flow back to the CLI and the Skill, and the next step is planned against the real editor state rather than against a screenshot. The daemon listens on a single fixed port, 60832, and the README states it does not spill over to other ports: if the port is occupied it takes over a stale easyeda daemon. The connector locks to that port, performs a handshake check and reconnects on its own. debug.exec_js still exists, but the README frames it as a scoped, temporary debugging entry point rather than the main workflow. That distinction is the whole design argument. A typed action catalogue means each step can be observed, accepted or replayed; raw JS execution means the model improvises and the failure is silent.

The circuit block library is the actual differentiator

Fixed-function peripheral circuits have fixed internal topologies. A CH340 USB serial stage, an ESP32 auto-download circuit, a debounced button, a USB hub, a buck converter: redrawing them is re-walking the same ground. easyeda-agent collects them into a block library, currently 37 blocks split as 19 ready, 13 verified and 5 draft. The sch block-apply command is claimed to place parts, wire them and reconcile the netlist in one step. You then rebind only the outward ports to your controller nets, and because pins are referenced by functional name the numbering does not change. Blocks carry author and contributors fields, and the README states a block must pass place, wire, check and DRC=0 before it enters the library. Three things are worth noting here. First, the library is embedded in the CLI, so easyeda blocks ls, show and search work offline without a daemon or an open window. Second, the ready/verified/draft split is a real quality signal that you can filter on, and it is more useful than a single "supported" label. Third, the DRC=0 gate is a claim about the contribution process, not a guarantee about your board: the block still has to fit your stackup and your net names.

Getting it running: three components, one installer, one version table

There are three parts that must be installed together: the easyeda CLI and daemon, the connector .eext plugin, and the easyeda-agent Skill. EasyEDA Pro is the host and needs 允许外部交互 enabled, otherwise the connector's WebSocket cannot reach the local daemon. The one-line installer is curl -fsSL https://raw.githubusercontent.com/zhoushoujianwork/easyeda-agent/main/install.sh | bash. It installs or updates the CLI and daemon, detects installed clients and drops the skill into the matching directory: Codex at ~/.codex/skills/easyeda-agent, the Codex Desktop shared directory at ~/.agents/skills/easyeda-agent, and Claude Code at ~/.claude/skills/easyeda-agent. It then prints the .eext import address. Skill installation can be steered with environment variables: EASYEDA_INSTALL_SKILLS=codex,agents,claude to pick targets, EASYEDA_INSTALL_SKILLS=none to skip, EASYEDA_SKILL_PRESERVE=1 to keep local edits, and EASYEDA_VERSION to pin a release and avoid the GitHub API call entirely. After the first install, upgrades go through easyeda update rather than the script. easyeda update replaces the binary with sha256 verification and atomic swap and refreshes the skill directory. easyeda update --check prints a read-only alignment table across cli, skill and connector. easyeda update --check --exit-code returns exit code 10 when CLI, Skill or daemon is not latest, or when a Connector crosses a compatibility line. --version pins, --skill-only and --cli-only narrow the scope. If a large GitHub asset fails three times in a row, the installer and update fall back to https://gh-proxy.com/, but only after checksums.txt has been fetched from GitHub, and the SHA-256 check still applies. EASYEDA_GITHUB_PROXY can point at another mirror or be set to off.

Version alignment is the sharpest constraint in the project

The README is unusually direct about this. CLI, Skill and the running daemon must be exactly equal to latest. The Connector only needs the same major.minor line; a marketplace patch that lags behind does not block use. The .eext is sideloaded, so it has no in-place auto-update and is excluded from easyeda update. When a minor or major compatibility line changes, update stops and prints the re-import address instead of silently proceeding. Dev builds with git-describe version strings are not overwritten unless --force is passed, and a binary sitting in the root directory needs sudo easyeda update. The recommended prompt for agents makes this the first command of a session: run easyeda update --check --exit-code, continue only if CLI, Skill and the live daemon are verifiable and exactly equal to GitHub latest and every Connector shares latest's major.minor, otherwise run easyeda update and restart the daemon. Patch-only updates keep the existing Connector and do not require restarting EasyEDA. Only a minor or major Connector change means installing the .eext from the release, saving documents, fully quitting and reopening EasyEDA. Any component upgrade ends the current agent session. That is a lot of ceremony, and it is the price of a protocol spoken by three separately shipped pieces. If you dislike that discipline, this project will frustrate you.

Where it stops: one editor, one API, and a licence you must read yourself

The wrong tool for headless or CI-only flows. Everything depends on a running EasyEDA Pro instance with external interaction enabled and a connector that has completed its handshake; without a window there is no eda.* to call. The block library is the one part that works offline, and only for listing, showing and searching. The action catalogue is bounded by the 86 eda.* namespaces the vendor exposes, so anything outside them has to go through debug.exec_js, which the project itself treats as a debugging escape hatch rather than a supported path. The connector display name changed to EDA Agent Connector in August 2026 for marketplace naming rules, while the internal package name easyeda-agent-connector and the uuid stayed the same, so existing installs update in place. That is a small thing, but it means screenshots and older tutorials will not match what you see. On licensing: the repository metadata reports NOASSERTION, which means GitHub could not map the file to a known identifier. The material here does not state the terms, so read the LICENSE file before you ship anything built on it, and do not treat this paragraph as legal advice.

A real alternative: the upstream gateway, and what changes if you pick it

The obvious comparison is run-api-gateway, the project this one builds on. Both run code inside EasyEDA Pro and reach the same official eda.* object, so the raw capability ceiling is identical. The difference is the interface. run-api-gateway exposes bare JavaScript execution as the primary workflow, which means the caller composes calls directly against the vendor API and gets whatever the script returns. easyeda-agent inserts a daemon and a typed action catalogue between the caller and eda.*, adds a fixed port with handshake and self-healing reconnect, and records artefacts, screenshots, DRC results and audit logs as first-class outputs. The trade is real in both directions. The gateway has fewer moving parts, no daemon to keep aligned and no version table to satisfy; easyeda-agent has more to install and a stricter upgrade story, but every action is named, validated and replayable, and the block library sits on top of it. If your work is exploratory and you are comfortable reading raw API responses, the gateway is lighter. If you want an agent to run a repeatable sequence and prove it happened, the typed layer is the point.

Maintenance cost and the first thing to verify

Upgrade cost concentrates in three places. The CLI and daemon move together through easyeda update, which verifies sha256 and swaps atomically. The Skill directory is refreshed by the same command, and EASYEDA_SKILL_PRESERVE=1 exists precisely because local edits get overwritten otherwise. The connector is manual: it is not in the auto-update path, so a compatibility-line change means a re-import from the release page and a full EasyEDA restart. The release cadence is fast, with v1.4.6, v1.4.7 and v1.4.8 all published on 2026-09-09, which makes the alignment check worth running rather than assuming. The README also points at docs/release-1.4.md for publication status, build steps and acceptance items that are not yet finished, so the current feature set is not the same as the finished one. Verify three things before you build a workflow on this: the three-way table from easyeda update --check --exit-code, that 允许外部交互 is on in EasyEDA Pro, and the ready/verified/draft status of every block you intend to apply.

Editorial conclusion

Adopt easyeda-agent if you already drive EasyEDA Pro and want an agent to place, wire and audit schematic or PCB work through a typed action catalogue rather than free-form JavaScript, and if you accept that CLI, Skill and daemon must sit on exactly the same release. Do not adopt it as a general EDA abstraction: it targets one editor, one API surface, and the connector .eext is sideloaded so it never auto-upgrades. Before committing, run easyeda update --check --exit-code and confirm the printed three-way table, verify that EasyEDA Pro has 允许外部交互 enabled, and check whether the block you need is listed as ready, verified or draft.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. zhoushoujianwork/easyeda-agent on GitHub