接入你的智能体
发布者自己的命令。不是 PlugMCP 端点。
用我们的密钥与日志托管一份副本。
npx -y [email protected]Claude Code 没有针对本地命令的安装链接。复制下方命令并在终端中运行。
claude mcp add awb-agent-manager -- npx -y awb-agent-manager@1.6.342在终端中运行。
{ "mcpServers": { "awb-agent-manager": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}claude_desktop_config.json
远程 URL 还是本机命令？ 两种安装方式的区别
来自发布者
Run AI CLI sessions on your own machines, give agents a queue of work, and follow the results in one place.
AWB is a self-hosted platform for working with AI agents. Start with a native CLI session, turn work into tickets when you need a queue and an audit trail, or give a larger mission to a team. The browser is your work interface; your Runtime Hosts run the CLIs and hold their native session history.
Runtime Host for AWB agents, including Hermes ACP and managed CLI runtimes
Each ticket has one assignee, a fixed status, tags, and an optional project. Ready tickets start automatically when that assignee has capacity. Agents use MCP (Model Context Protocol) to read instructions, report results, and update work. Despite the project name, there are no configurable board or column objects: Tickets offers a kanban view of fixed statuses and a list view.
Work pages combine the accounts you can access. Accounts govern ownership, membership, credentials, execution policy, and budgets; you do not need to switch accounts to find your work.
Supported execution runtimes include Claude Code, Codex, DeepSeek, Antigravity, Pi, OpenCode, and Hermes. Features vary by runtime and the binaries/adapters installed on a host. The UI uses reported capabilities and model options. See CLI modules and runtime configuration.
The work UI adapts to phones, tablets, and desktops. On smaller session screens, open Settings for runtime controls; the prompt fills its own row above the attachment/voice/send controls. Notifications can be muted from the top bar. See the session guide.
flowchart LR
User[Browser] <-->|REST + SSE| Server[AWB server]
Client[External MCP client] <-->|Streamable HTTP /mcp| Server
Server <--> DB[(PostgreSQL or SQLite)]
Server <-->|SSE + REST| Host[Runtime Host: awb-agent-manager]
Host <--> CLI[Installed CLIs / ACP adapters]
CLI <-->|MCP tools| Server
CLI <--> Files[Repositories + native session history]
awb-agent-manager. It supervises CLI processes, handles sessions and terminals, and reports capabilities. It can be your laptop, workstation, or a server.The server and a Runtime Host can run on the same machine. Installing the server gives you the UI and work management; connect a host with a configured CLI to execute AI work. CLI installation, provider login, and model usage billing are separate from AWB installation.
The source requirement covers the manager's Node 22 requirement and Vite's Node 22.12 minimum. The Dockerfile uses Node 22. Compose supplies PostgreSQL; local development uses SQLite through sql.js without a database service.
git clone https://github.com/parnmanas/ai-workflow-board.git
cd ai-workflow-board
cp docker-compose.env.example .env
Edit .env and replace DB_PASS with your own database password. Then start:
docker compose pull
docker compose up -d
docker compose ps
Open http://localhost:7701. The same server serves the UI, /api/*, /mcp, and /api-docs.
Compose runs PostgreSQL 16 and the AWB server. It persists the database in pgdata and server files, including the generated credential encryption key, in awbdata. It publishes ports 7701 and 5432; adjust mappings if those ports are in use or the database should only be reachable inside Docker.
The supplied Compose file uses ghcr.io/parnmanas/ai-workflow-board:latest. Pulling that image does not build your checkout. To run the source you just cloned, build the image locally and start it without pulling over it:
docker build -t ghcr.io/parnmanas/ai-workflow-board:latest .
docker compose up -d --pull never
git clone https://github.com/parnmanas/ai-workflow-board.git
cd ai-workflow-board
npm ci --ignore-scripts
cp apps/server/.env.example apps/server/.env
The example uses SQLite and port 7701. No provider token or development authentication bypass is needed to open the UI and complete setup.
Start the server and client from the repository root:
npx turbo run dev --filter=server --filter=client
Vite proxies /api and /mcp to NestJS. SQLite files are created under the repository's database/ directory. Stop the process normally to flush pending writes.
You can also run npm run dev:server and npm run dev:client in separate terminals. The root npm run dev starts all three workspaces, including agent-manager, and its predev script clears ports 7700, 7701, and 7702. Use the filtered command above when you only want the web application.
Manage ownership under Settings → Ownership and membership under Settings → Members. Account membership and permission to operate hosts/sessions/terminals are separate checks. Sessions, terminals, and voice are administrator-only by default; administrators can grant the corresponding permissions.
Do this on the machine where your repositories and AI CLI will run. For a Docker-hosted AWB server, the manager normally runs separately on the execution machine.
Install and sign in to the CLI you intend to use. Confirm it works as the OS user who will run the manager. Install Git for repository worktrees.
In AWB, open Hosts (/hosts) → Runtime Hosts and create a token with Pair manager…. The token/display code is single-use and expires after ten minutes.
On the execution machine, install and pair the manager:
npm i -g --ignore-scripts awb-agent-manager
awb-agent-manager setup
Enter the server base URL and token. On the same machine, use http://localhost:7701; on another machine, use the server's reachable hostname or HTTPS URL. Enter the base URL without /mcp. The manager can drive several CLIs; setup does not ask you to choose one.
Start it in the foreground to check the connection:
awb-agent-manager
Confirm the host appears online and its CLI/session capabilities are available. After a successful connection, stop the foreground process and optionally install it as a service:
awb-agent-manager service install
The manager stores pairing configuration in its platform configuration directory (~/.config/awb-agent-manager/ on Linux by default). Keep it private: it contains the host API key. A paired host can execute authorized work across accounts; its pairing account is not a scope switch.
For Linux, macOS, Windows, or Synology services, configuration overrides, and updates, see the manager quickstart and Runtime Host reference.
For a new session, AWB uses the applicable account/host/CLI defaults. The first open pins its owner, credential, configuration, and backend. Changing account defaults later does not silently change an existing session; explicit changes in that session are retained on resume.
Without an AWB credential binding, sessions use the host's CLI login. With a binding, the manager prepares a separate CLI home; it does not overwrite the operator's login files. History remains on the host. See Agent Sessions.
Use tickets for work with a clear outcome, queue position, and durable result.
A Project represents one repository. Resources hold documents, images, and links. With a registered host folder, ticket execution creates a worktree under <main-clone>/.awb/wt/<ticket8>; the main clone is not reset or cleaned. Without one, the manager uses its base-repository preparation path. See Tickets & Projects.
backlog while preparing it; move it to todo when ready.in_progress and dispatches it. The agent reads the ticket via MCP, performs the work, and records results in comments.review for human inspection or done when complete. Move a reviewed ticket back to todo to request another pass.The default capacity is one active, non-pending ticket per runtime identity in an account. Queued work is ordered by priority, position, and creation time. Unassigned, pending, archived, and confirmed duplicate tickets do not start. Checklist subtasks are handled by their parent ticket's assignee and are not independently dispatched.
Use pend for an operator decision, prerequisites for other tickets, or CI waits for build results. Account settings can pause dispatch or change capacity. Completion can release dependent work, queue a next_ticket, invoke on-done Actions, and trigger an opted-in QA rerun.
shared folders for a prepared common tree, or isolated for a separate provisioned folder/checkout per step. Shared is the default; coordinate simultaneous edits through dependencies.Ownership follows the selected account-owned team/project. Global-team standalone work uses the default accessible account. Teams coordinate durable missions; runtime-native subagents perform bounded execution within an agent's work. See Orchestration.
For browser-launched managed work, agent-manager prepares the MCP connection. You can also connect an existing MCP client directly for tool access.
/mcp URL and Authorization: Bearer <key>.For a client accepting Claude-style mcpServers JSON:
{
"mcpServers": {
"awb": {
"type": "http",
"url": "http://localhost:7701/mcp",
"headers": {
"Authorization": "Bearer YOUR_AWB_API_KEY"
}
}
}
}
Use your deployed HTTPS URL remotely. Configuration format and file location depend on the client. A direct MCP connection provides tools; it does not by itself make that client a Runtime Host receiving the execution queue.
Discover current tools through MCP tools/list. Categories cover accounts, tickets, projects, comments, chat, resources, QA/Security, Actions/Functions/Schedules, missions/steps, skills, builds, deployments, and ontology queries. Canonical names include list_accounts, create_ticket, move_ticket, save_project, and create_automation_schedule. Registration lives in tools/index.ts; /api-docs describes REST, not MCP JSON-RPC.
For development, npm run mcp starts standalone stdio and npm run mcp:http starts separate HTTP on 7702 by default. Prefer integrated /mcp when the web server is running. With SQLite, do not run separate server processes against the same file; give standalone processes their own absolute SQLJS_DB_PATH and SQLJS_ONTOLOGY_DB_PATH, or use PostgreSQL.
Source npm scripts run the backend in apps/server, where dotenv/config loads apps/server/.env. Compose reads the repository-root .env for substitutions in docker-compose.yml. Adding a variable to Compose's .env only reaches a container when the service forwards it.
To forward a custom origin with Compose, for example, add compose.override.yaml:
services:
server:
environment:
CORS_ORIGIN: https://awb.example.com
Embeddings use EMBEDDING_PROVIDER=openai, OPENAI_API_KEY, and optionally EMBEDDING_MODEL (default text-embedding-3-small), or their System Settings equivalents. Voice needs configured STT/TTS engines; see Voice. QA and Security schedules have separate controls in their scheduler references.
Before upgrading, back up both the database and the credential encryption key/data volume. The current server runs TypeORM schema synchronization in production and development, followed by data migrations. Recent board/Agent removal migrations are destructive; rollback requires a backup. See the ownership migration runbook.
For a Compose database backup:
docker compose exec -T db sh -c 'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' > awb-backup.sql
Back up awbdata separately, or preserve your configured ENCRYPTION_KEY. A database backup cannot recover encrypted credentials if their key is lost. For SQLite, stop the writer before copying database/data.db and database/ontology.db, and preserve the server data directory too. Native CLI history and repositories need host-side backups.
To update Compose after making backups:
docker compose pull
docker compose up -d
docker compose logs --tail=100 server
For a source deployment, update your checkout, reinstall from the lockfile, run npm run build, and restart npm start with production/PostgreSQL configuration. The built server serves apps/client/dist on port 7701. Merging into main alone does not update another user's deployment; this repository does not include a general server auto-deployment workflow.
PostgreSQL instant columns now use timestamptz. Existing databases are converted before schema synchronization, preserving their previous timezone interpretation. Back up first and stop old server instances; review the legacy timestamp conversion and rollback procedure before upgrading.
agent-manager releases independently through the npm workflow. Versions are computed at publish time; do not manually bump its source package version. Hosts report running and installed versions separately; an installed update may need a restart. See release procedure and self-update policy.
Use HTTPS for remote browser access. Reverse proxies must allow long-lived SSE for /api/events/stream and MCP streaming; response buffering or short idle timeouts interrupt live sessions. Microphone input requires a browser secure context (HTTPS or localhost).
Passwords are hashed with bcryptjs; stored credentials use AES-256-GCM; managed API keys are hashed and displayed once. Feature permissions and account membership determine access. A browser terminal acts as the manager's OS user, so grant terminals.use only to users who should operate that machine.
For a corrupt local sql.js database, startup reports the failing path. Preserve the file for recovery first. If an empty database is acceptable, automatic recovery backs up the corrupt file and creates a fresh one:
AWB_DB_AUTORECOVER=1 npm run dev:server
This loses the active contents of the recreated database; restore a known-good backup when you need the data. To try separate fresh files:
SQLJS_DB_PATH=/absolute/path/data-fresh.db \
SQLJS_ONTOLOGY_DB_PATH=/absolute/path/ontology-fresh.db \
npm run dev:server
The guard only applies to local sql.js files; it does not replace a PostgreSQL database. See host troubleshooting for CLI/update problems.
Local sql.js runs every write through one queue, so one stuck write holds up all the others. When writes stall, look for a [DB] sql.js write queue (<file>) warning. It names what holds the queue, for how long, and how many writes wait behind it. It also lists the waiting writes in two groups: those already waiting when the held turn started, and those queued after it started. Writes with the same name and call site are listed once with a count; without recorded call sites, writes with the same name are counted together, and the entry says they may be different writes. INSERT, REPLACE, UPDATE and DELETE statements are named with their table (INSERT accounts). Some writes record only TypeORM frames as their call site — repo.insert(), upsert(), and a write whose promise is returned without await — so those writes are told apart only by table, and writes into the same table from different callers count together. Each group lists up to five entries in the order they first queued, each with how long its first turn has waited, and examines only its first 1,000 turns. A later released after line means a slow callback. If no release line ever follows, the turn is stuck — usually a deadlock: a transaction callback waiting for another request's write (a long migration also stays held until it ends). Which group that write is in depends on when it was issued. It is in the second group if it was issued after the held turn started, which is the usual case when the callback called or awaited the request it comes from. It is in the first group if it was issued while the held turn was still waiting for its turn, for example by a request holding a lock the callback waits for. After the first warning, new arrivals trigger another report once the first new write has waited the threshold. Only writes queued since the previous report are listed, with the same grouping and limits. The minimum interval between reports starts at the threshold and doubles after each follow-up (30s, 60s, 120s … by default); an unchanged queue does not repeat. These new arrivals record call sites even without the stack flag. Long migrations can also trigger these reports; they do not prove a deadlock. A write can be missing while the next report is not yet due, if five other entries come before it in its group, or if it is beyond the first 1,000 turns of its group, so its absence does not rule out a deadlock. A turn the watch could only see after it ended (for example while the event loop was blocked) is reported once, with before it was released; that report only counts the waiting writes. To see where the turn was opened and where the listed writes were queued, restart with SQLJS_TURN_STACKS=1 and reproduce.
Older sql.js versions could disable foreign-key enforcement after flushing to disk, leaving children behind when parents were deleted. Instance migration now checks the sql.js source with PRAGMA foreign_key_check and rejects the run before importing anything if migrated tables contain violations. The error lists each table's distinct orphan row count and FK violation count (one row can violate multiple constraints). allow_merge and skip_attachments do not bypass this source integrity check.
Back up the source database and stop source writes before repair. On a backup copy, run PRAGMA foreign_key_check;: each result identifies the child table, rowid, parent table and FK id. Use PRAGMA foreign_key_list('child_table'); to identify the columns. Restore missing parents where possible, or remove only orphan rows you have confirmed are disposable. Repeat the check until it returns no violations in migrated tables, then retry migration against the repaired source. Preflight never deletes or skips rows automatically. A clean check is a point-in-time diagnosis; keep source writes stopped for the actual cutover.
PostgreSQL/MySQL sources do not run this SQLite check. Older source servers omit the diagnostic field and remain compatible, so upgrade the source to obtain this protection.
apps/client/ React UI, Vite, browser/client tests
apps/server/ NestJS API, MCP tools, entities, migrations, server tests
apps/agent-manager/ Host runner, CLI/ACP adapters, sessions, terminals, npm package
services/voice-server/ Optional self-hosted speech service
skills/ Built-in versioned skill pack
docs/ Feature contracts, architecture, operational runbooks
scripts/ Development and CI helpers
database/ Local SQLite files (generated at runtime)
There is no root npm test script. Suites are defined in each workspace; PostgreSQL concurrency/dialect checks complement sql.js tests. See server QA tests and client tests.
The stack is React 18, React Router 7, Vite 8, NestJS 11, Express 5, TypeORM 0.3, TypeScript, Zod, the MCP SDK, and Turbo. Workspace manifests and package-lock.json give exact resolved versions.
Read AGENTS.md, ownership, and the relevant feature contract before changing implementation. Ticket writes go through TicketService, dispatch through TicketDispatchService, and models through HostModelsService/useHostModels. Server/manager wire changes belong together; see CLI wiring and MCP wiring.
The documentation index distinguishes current guides from historical designs/audits.
Legacy /ws/... bookmarks and workspace owner fields/headers/tool names remain aliases. New integrations use account_id, X-Account-Id, account MCP tools, and automation schedule tools. Existing IDs and CLI home/history paths are preserved. Filesystem workspace_folder still means a working directory.
All rights reserved for the main project. The separately distributed awb-agent-manager package includes its own MIT license.
Runtime Host for AWB agents, including Hermes ACP and managed CLI runtimes
{ "mcpServers": { "awb-agent-manager": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}工具
暂无工具列表。远程服务器在首次健康检查后会获得工具列表。
常见问题
在本页复制适用于 Cursor、Claude Desktop、Claude Code 或 VS Code 的 stdio 配置。它使用发布者的安装方式，而不是 PlugMCP 代理。
此记录未列出必需的环境变量。
Awb Agent Manager 通过 stdio 在本地运行。
上次检查时间：2026-11-14。 Runtime Host for AWB agents, including Hermes ACP and managed CLI runtimes