ProAgentStore

ProAgentStore Platform

面向服务器驱动型 AI Agent 的市场。创作者构建 Agent 模板，客户端订阅并在自己的数据上运行这些模板。

商店： https://proagentstore.online API： https://api.proagentstore.online MCP： https://mcp.proagentstore.online/mcp 控制台： https://proagentstore.online/console/ GitHub： https://github.com/ProAgentStore 免费套餐： https://freeagentstore.online

这里有什么

platform/
├── packages/sdk/     Internal TypeScript SDK for agents
├── packages/cli/     @proagentstore/cli — init, check, publish, MCP proxy, local runtime
├── packages/browser-runner/ ProAgentStore Playwright + terminal/coding runtime bundled into the CLI
├── workers/api/      Hono API worker (auth, agents, instances, coding, apply, keys, analytics)
├── workers/host/     Marketing site + console + widget
├── workers/mcp/      MCP server for Codex, Claude Code, Cursor, and VS Code
├── store/            Source HTML for all pages
├── skills/           Open Agent Skills source files
├── plugins/          Codex and Claude plugin wrappers
├── agents/           Tier-0 first-party agent sources kept in this repo
└── templates/        Agent scaffolding (worker, cron, api)

Agent 类型

类型	模板	功能
Agent	worker	完整 AI：对话、记忆、知识库、核心工具、Workers AI
Worker	cron	定时任务：每日摘要、监控、批处理
工具	api	无状态端点：转换、生成、分析

快速开始

使用 Agent

# Try any published agent — no sign-up needed
curl -X POST https://api.proagentstore.online/v1/public/agents/chatbot/try \
  -H "Content-Type: application/json" \
  -d '{"message":"Hello!"}'

构建 Agent

npx @proagentstore/cli init my-agent --template worker
cd my-agent
pnpm install && pnpm dev
npx @proagentstore/cli publish

SDK

import { initPro } from '@proagentstore/sdk'

const agent = initPro({ agentId: 'your-id', token: 'your-token' })
const { response } = await agent.chat('Hello!')

嵌入小组件

<script src="https://proagentstore.online/widget.js"
  data-agent="chatbot" data-theme="dark"></script>

MCP

codex mcp add proagentstore --url https://mcp.proagentstore.online/mcp
codex mcp list
# If the server shows "Not logged in":
codex mcp login proagentstore

claude mcp add --transport http proagentstore https://mcp.proagentstore.online/mcp
claude mcp list

npx mcp-remote https://mcp.proagentstore.online/mcp
npx @proagentstore/cli mcp

MCP 有两种运行模式：

• chat_with_agent 调用公开试用端点。可用于发现和冒烟测试。
• subscribe_agent 创建你的私有实例，然后 chat_with_instance 使用你自己的状态、知识和调用方提供的 AI 凭据运行该实例。

典型的用户运行流程：

list_agents -> subscribe_agent -> my_instances -> add_instance_knowledge -> chat_with_instance

缺少用户自有 AI 凭据时，预期响应如下：

Add your Cloudflare Workers AI account ID and API token before running this agent.

这表示实例运行路径正常，并且正确拒绝使用平台的 AI 账户计费。有关完整工具映射、实时测试记录和 OAuth 故障排查，请参阅 MCP Instance Runtime。

以 MCP 为先的完整开发者界面文档见：

• https://proagentstore.online/docs/mcp/
• MCP
• server.json
• .mcp.json
• AGENTS.md

MCP 安全机制在服务器端强制执行。OAuth 支持 read、write、runtime 和 destructive 权限范围；MCP_READ_ONLY=1 会强制启用只读模式；修改类工具在适用时支持 dry_run；覆盖或破坏性工具要求提供完全匹配的 confirm 值；mcp_audit_log 会公开近期的 MCP 写入、运行时、试运行、拒绝和破坏性事件。

架构

当前系统图、运行时边界、数据所有权规则、风险评估和重构路线图见 Architecture。

浏览器运行时（pags up）

具备浏览器和编码能力的 Agent 将 PAGS 用作控制平面的大脑，并将本地 ProAgentStore 浏览器运行时（runtimePlane: "pags"，具备 Playwright、终端和编码能力，打包在 CLI 中）用作双手。一个公开软件包，一个命令——无需 monorepo，也无需隧道二进制文件。

PAGS control plane / MCP / Workflows
  -> task, auth, approval, audit, the LLM brain
ProAgentStore browser runtime (pags up)
  -> Playwright, local files, real browser profile, terminal/coding engines
Real browser / real repo
  -> job boards, uploads, receipts, coding sessions

npm i -g @proagentstore/cli
pags login
pags up            # one runner for every active runtime-capable instance

通过 SSH 或在无头机器上登录（#1157）。 pags login --device 会显示一个链接和一个短代码 （BCDF-GHJK）；在手机或任何已登录 ProAgentStore 的设备上打开该链接，确认 页面显示的是这台机器，然后批准——几秒内机器就会登录。SSH 会话中（任何操作系统）和没有显示器的 Linux 上会自动选择此方式；pags login --browser 会强制使用浏览器。正在运行的 pags up 会保持自己的 登录状态：如果会话在最近 7 天内，它会刷新登录状态；如果无法刷新，会在 pags up 窗口中提示， 而 list_runner_nodes 会对这台机器发出警告——此时仍有时间通过 SSH 运行 pags login --device。

每台机器只需安装一次。 从 CLI 0.4.63 起，npm 安装的 pags 是一个小型引导程序存根（#862）：每次运行 pags up 都会向 npm 查询最新的 @proagentstore/cli，将更新版本下载到 ~/.config/proagentstore/cli/<version>/ 并运行它——因此机器无需再次运行 npm i -g，无论落后多久，也不管是否听说过 runner_update。runner_update（#859）会在 pags up 持续运行时远程更新同一缓存。使用 0.4.62 或更早版本的机器，可通过最后一次 npm i -g @proagentstore/cli 获取存根（或者在 0.4.62 上通过 runner_update 获取）。PAGS_NO_SELF_UPDATE=1 会关闭检查；源码检出不会自动更新。 远程更新会重启整个进程，而不只是 runner（#860）。 runner_update 安装版本后，pags up 会使用相同的标志重启自身（包括 supervisor），并让每个 Agent 重新连接。（较旧的 pags up 只会重启 runner，而 runner_update 在 supervisor 中的响应也会说明这一点。）如果 runner 不是通过 pags up 启动的，只要有机制能在它退出后再次启动它，也可以远程更新：

• launchd / systemd — 使用 PAGS_SERVICE=1 和失败时重启配置运行 pags runner connect <any-instance-id> --watch-instances（launchd KeepAlive → SuccessfulExit: false；systemd Restart=on-failure）。更新后 runner 会以代码 75 退出，服务管理器会启动新版本。runner 使用已保存的 pags login 会话登录。
• 其他方式（tmux 脚本、nohup）——将启动 runner 的 shell 命令设为 PAGS_RESTART_COMMAND；runner 退出时会在脱离终端的状态下运行该命令。

如果两者都没有，runner_update 会拒绝更新，以免停止一个无人重新启动的 runner。无论采用哪种方式，更新前都会等待正在执行回合的编码引擎完成。

pags up 是标准的 runner：一个进程为所有 capabilities.runtime 非 null 的活跃实例提供服务。仅运行于云端的聊天／RAG／连接器 Agent（runtime: null）会被跳过——它们从不需要本地 runner。

成员关系会实时更新，而不是在启动时快照确定。pags up 会传入 --watch-instances（CLI ≥ 0.4.30），因此 runner 每 20 秒重新读取一次 /v1/instances/my/instances，并连接新符合条件的 Agent；不再符合条件的 Agent 则会断开连接，无需重启。runner 运行时订阅编码 Agent 会自动生效。（采用轮询而非推送：全新实例没有可接收推送的套接字；#83 跟踪推送路径。）指定范围的 pags up --instance <id> 则有意不监视其他实例——它表示只服务这一个 Agent。

传输采用 WebSocket 中继：runner 向某个实例和节点对应的 RelayDO 发起出站连接——无需 cloudflared、公共服务或入站端口。Cloud -> callRunner() -> RelayDO -> WebSocket -> runner。当前 CLI 没有 --tunnel 标志或隧道回退机制。runner 会为握手生成一个短期有效、限定实例范围的中继令牌；30 天有效的账户 JWT 不会放入 WebSocket URL。

• Coder 可以同时在多台机器上使用同一实例。每个编码会话都会固定到拥有它的 runner 节点；不同代码库可以同时在不同机器上运行。
• pags up --force — 调试过时的本地连接时，替换当前中继套接字
• pags up --instance <id> — 固定到一个 Agent（调试）
• pags up --headless — 无头模式

求职申请支持两种浏览器流程：JOB_APPLY 工作流（见下文）以及 Scout → Tailor → Runner 流程。Coder Agent 会在会话分配的 runner 节点上运行所选引擎（Claude Code、Codex、Gemini CLI、Grok 或本地命令）；Claude 使用持久化的结构化会话，其他引擎则运行一次性回合。

旧版求职申请 Agent（JOB_APPLY，受支持）

“旧版”描述的是它的历史，并不表示它已停止支持：驱动 pags up 浏览器的 Cloudflare JobApplyWorkflow 核心逻辑，是受支持的浏览器求职申请方式，与 Scout → Tailor → Runner 流程并列（#1062）。使用 POST /v1/instances/{id}/apply、聊天中的 submit_job_application 工具，或 MCP apply_to_job 来启动。每次启动都需要一个 Job Application Assistant 实例、一个运行中的 runner，以及已存档的简历；每个实例一次只能运行一个申请，候选人信息只取自你的 Profile，每次运行都会创建一个支出池和一条可停止的运行记录。另一种方式是使用该流程：筛选潜在线索、定制申请材料，然后请求审核，或让 Application Runner 按其配置的提交策略填写申请。

技能和插件

ProAgentStore 通过针对各平台的插件市场发布技能，方便用户在 Codex 和 Claude Code 中查找。

Codex：

codex plugin marketplace add ProAgentStore/platform

Claude Code：

/plugin marketplace add ProAgentStore/platform
/plugin install proagentstore@proagentstore
/reload-plugins

请参阅 技能发布，了解发布目录结构、市场文件以及 Codex/Claude 双平台发布检查清单。

公开发现页面：

• https://proagentstore.online/skills/
• https://proagentstore.online/skills/proagentstore-mcp-operator/
• https://proagentstore.online/llms.txt
• https://proagentstore.online/llms-full.txt
• https://proagentstore.online/skills.json

目录中的 Agent

目录实际所在的位置

权威目录是 D1 中的 agents 表，通过 GET /v1/agents 读取。本仓库中的任何内容都不是它的镜像。仓库中的文件要么是某个目录条目的来源，要么完全不属于目录——两者是不同的概念，本节旨在避免将它们混为一谈。

来源	内容	权威性
D1 中的 agents 表	每个已发布的 Agent、其能力、设置架构和流水线。	**权威。**读取 GET /v1/agents，或使用 MCP list_agents 工具。
workers/api/migrations/*seed*.sql	全新数据库中如何将一方 Agent 加入该表。幂等的 INSERT OR IGNORE。	对其写入的 Agent 具有权威性。编辑 seed 不会更改已写入的条目——这需要后续的 UPDATE 迁移。
agents/<slug>/agent.json	Tier-0 Agent 的清单，其代码由平台自身构建或导入。	仅作为来源。它不会创建目录条目。
store/registry.json	已废弃。见下文。	无。

因此，某个 Agent 可以存在于目录中，但在本仓库中没有对应文件；某个文件夹也可以存在于此处，但没有对应的独立目录条目。这两种情况都很正常。

Tier-0 Agent——本仓库中唯一包含源代码的 Agent

agents/ 中恰好有三个 Agent，由 CI 通过 scripts/check-agents-allowlist.mjs 强制检查：

文件夹	属于 Tier-0 的原因
agents/coder	agents/coder/web 是由控制台导入的 pnpm 工作区成员。
agents/job-application-assistant	apply Agent 的清单。（其 src/ Worker 属于旧版且未部署——请参阅该文件夹的 README。）
agents/repo-chat	Repo Chat Agent 的参考源代码。

其他所有内容都是 ProAgentStore 下的独立组织仓库，本地克隆到 ~/dev/stores/pags/agents/<slug>/。在此处添加第四个文件夹会导致 CI 失败，这是有意为之（epic #50）——此前，monorepo 积累了十份陈旧的 vendored 副本，它们从未被构建或部署。

当前发布的内容

目前已发布 13 个 Agent。按来源分组如下：

由迁移创建 — 在全新数据库中可重现：

Slug	名称	种子	仓库中的来源
coder	Coder	0021	agents/coder
repo-chat	Repo Chat	0032	agents/repo-chat
site-builder	Small Business Website Builder	0057	无 — 完全以声明式配置实现（lib/pipelines/*.json）
coder-repo	Repo Coder	0063	无 — 声明式功能
coder-lead	Coder Lead	0063	无 — 声明式功能
local-repo-chat	Local Repo Chat	0066	无 — 声明式功能
tmux-operator	tmux Operator	0072	无 — 声明式功能
job-application-assistant	Job Application Assistant（JOB_APPLY）	0185、0189、0233	agents/job-application-assistant

由运营者通过 API/控制台创建 — 它们仅存在于 D1 行中，因此全新数据库中不会有这些记录。请将其视为已知偏差，而非设计意图：

Slug	名称	备注
language-buddy	Language Buddy	如果存在，迁移 0041 会设置其 settingsSchema；但不会创建它。
doc-chat	Doc Chat
small-business-website-lead-finder	Small Business Website Lead Finder	独立的组织仓库，克隆到了 pags/agents/。
lead-outreach-tj6qrr	Lead Outreach Assistant	潜在客户链路的中间环节。
facebook-friend-confirmer	Facebook Friends	浏览器运行时 Agent。

由三个 Agent 组成的潜在客户链路为 small-business-website-lead-finder → lead-outreach-tj6qrr → site-builder，通过 agent_connections 连接，而非通过代码连接。

发布受到限制：PUT /v1/agents/:id 和 POST /v1/batch/bulk-visibility 都会拒绝发布烟雾测试夹具（#65、#64），因此目录没有重新累积审计时移除的 16 个夹具和脚手架种子。

store/registry.json 有意保持为空

它是 store/build-details.js 的输入文件，该脚本用于生成静态 Agent 详情页。两者都没有接入任何流程：build-details.js 没有对应的 package.json 脚本，也没有 CI 工作流调用它。Agent 详情页通过 GET /v1/public/agents/:id 动态提供，路径为 /agents/:slug/。 保留这个空存根，是为了避免有人运行已弃用的生成器时发生崩溃。它不是公开发现资源 — 如需公开发现，请使用 GET /v1/agents、store/llms.txt 或 store/skills.json。

从此列表中移除的 Agent

本 README 的早期版本列出了十个 Agent — site-monitor、lead-qualifier、 content-pipeline、competitor-intel、support-escalator、data-analyst、meeting-notes、 seo-auditor、invoice-parser、email-drafter。它们是 agents/ 下随仓库引入的种子副本，已在平台 main 分支的提交 f9980a8 中移除。它们如今都没有种子迁移，也没有已发布的目录条目。请勿将它们重新加入此处。

其中一个仍作为查询键存在，但并非 Agent：种子迁移使用 SELECT owner_id FROM agents WHERE slug = 'data-analyst' AND owner_id LIKE 'google:%' 来解析运营者账户。 这是在生产数据库中查找运营者用户 ID 的方式，查找失败时会回退到 'system'。这并不意味着 data-analyst 是目录中的 Agent。

其他功能

• 双向语音，适用于 Assistant 聊天和 Coder Co-pilot（共用 useVoice hook）——可选择 Dictation（浏览器实时语音转文字）或 Whisper（通过密钥代理调用 OpenAI，准确度最高）进行 STT；可选择浏览器或 OpenAI TTS，并通过语音/语速选择器进行设置；提供单一的分段式 Chat · Tap-to-talk · Hands-free 模式控制（静音是 Hands-free 的子控件；在移动设备上仅显示图标）；支持语音 "repeat" 命令；还可以点击扬声器按钮，重放每轮语音消息保存的录音（R2）——旁边设有 Show what was heard 开关，可对比实时听写结果与已发送的转录文本，并统计转录遗漏的单词数。自适应 VAD，以及暂停、灵敏度和语言设置；支持 iOS 手势。
• 知识库中的一等 Markdown 文档——创建、读取和编辑；Agent 可通过 Assistant 读取和更新这些文档。
• 可观测性——浏览器和服务端错误会写入持久化日志（client:voice*、keys-proxy、job-apply 等），并通过 MCP list_errors 查看；通过 agent_events 和 MCP agent_trace 提供统一的逐次运行时间线。
• 可由 Agent 配置的工作看板——每个实例一个看板；各 Agent 可声明列（capabilities.boardColumns），每个工作项对应一张卡片，并支持移动、重试和查看尝试次数。通过 MCP instance_board 驱动。（取代旧的双看板 /“运行时看板”设计。）

开发

测试——两个项目，而非一个测试池

pnpm test 会运行全部测试。其底层拆分为两个项目（vitest.config.ts）：

项目	内容	运行方式
unit	约 3100 项测试，纯函数和模拟 I/O	并行 fork 池
integration	packages/browser-runner/**——每项测试使用真实 Chrome，通过 CDP、绑定的套接字、启动的 tmux 面板和真实的 git clone	在 unit 之后逐个文件单独运行

integration 中的十项测试耗时比其他约 3100 项加起来还长。它们也是唯一会让人遇到本地偶发失败的测试，因此有必要准确说明原因。

pnpm test               # both, integration last and alone
pnpm test:unit          # the fast ~3100 — what you want in a tight loop
pnpm test:integration   # the real-browser / real-socket set

**这些测试对 CPU 可用性很敏感，与被测代码本身无关。**不存在竞态、端口冲突，也没有文件之间浏览器泄漏。所有已观察到的失败都是在机器空闲时就能通过的代码出现了 Test timed out in Nms。实测：同一个通过的浏览器测试单独运行时耗时 11.4s，在整个测试套件中运行时耗时 20.6s，与另一个完整测试套件同时运行时耗时 39.3s。而且，当机器完全过载时，失败的测试分别是 rate-limit.test.ts、publish.test.ts 和 storage-tools.test.ts——这三个都是纯单元测试文件，不涉及浏览器或套接字。浏览器测试最先因资源不足而无法运行，是因为它们负载最重，并不是因为它们是浏览器测试。

所以，如果你遇到偶发失败，不要放宽断言——先看看还有什么在运行。CI 不受影响，也从未受影响：它在专用运行器上单独执行整个测试套件，因此结果稳定通过。拆分测试是为了适应共享开发机，主要是让真实 I/O 测试获得适合真实 I/O 的超时预算，而不是 vitest 默认的 5s。

如果你添加的测试会启动浏览器或绑定监听套接字，请将它放在 packages/browser-runner/ 下，以便继承相应的超时预算；如果测试出现在其他位置，scripts/check-test-isolation.mjs 会使 CI 失败。

**孤儿 Chrome 进程。**测试运行器被 SIGKILL 时，Playwright 不会执行清理，因此中止的运行会遗留整个浏览器——在本仓库的开发机上测得：174 个正在运行的浏览器配置文件，最旧的已有 26 小时，约 1000 个进程，平均负载 190。它们不会显示出来，却会拖慢之后的每次运行，这也是“偶发失败”显得随机的主要原因。如果本地测试莫名其妙地很慢： ps ax | grep -c playwright_chromiumdev_profile。

文档产物——什么是源文件，什么是生成文件

产物	状态	如何更新
platform-docs/*.md	源文件	直接编辑；在 zensical.toml 的 nav 中添加该页面
store/docs/**	生成文件，不提交	运行 pnpm docs:build；切勿手动编辑，也切勿运行 git add
store/openapi.yaml	源文件	添加或更改路由时编辑
store/llms.txt、store/llms-full.txt	源文件	手动编辑；Agent 会首先读取这些文件
workers/mcp/README.md 工具表格	源文件	注册工具时添加一行
workers/mcp/src/tool-count.ts	数量的唯一可信来源	添加或移除工具时递增或递减

store/docs 与 workers/host/src/pages.ts 一样，都是构建产物：ci.yml 和 deploy-host.yml 都会在读取它之前运行 pnpm docs:build，所以提交副本只会过时——而且确实过时了。在全新检出后、运行 pnpm test:e2e 或 node workers/host/build.js 之前，先运行一次 pnpm docs:build；这两个命令都会读取 /docs/*。

漂移检查

本文档是此代码库中唯一没有其他机制验证的部分，因此会悄然过时，进而向 Agent 传递错误信息。以下两个命令可检查实际影响过我们的类别（#209、#210）：

pnpm docs:drift        # nav ↔ pages, MCP tool table + count, removed commands, docs links,
                       # and (delegated) the route/spec check below
pnpm openapi:coverage  # every Hono route is documented or explicitly excluded, and every
                       # documented path resolves to a real handler

两者都会在 CI 中运行。任一检查失败时，都会指出文件和预期数值——请修正文档，或修正文档所描述的代码，但不要在未调整其监控对象的情况下屏蔽检查。需要有意不记录的路由，请在 scripts/openapi-coverage.mjs 的 EXCLUSIONS 数组中逐一列出，并说明原因。

添加路由时，更新 store/openapi.yaml（或添加排除项）。 添加 MCP 工具时，在 workers/mcp/README.md 中添加对应行，并递增 workers/mcp/src/tool-count.ts——index.test.ts 会将该常量与实际注册结果进行断言，/health 和三处文档也会引用该数量。 添加文档页面时，在 zensical.toml 的 nav 中添加该页面。

质量扫描（VCQA）

pnpm vcqa              # the canonical score: pinned CLI, --skip-tests, repo root

这一行中有两点至关重要。

它会先构建 SDK，原因与 pnpm typecheck 相同：控制台和 Agent UI 会将 @proagentstore/sdk 作为已构建的 dist 导入，因此在尚未构建 SDK 的检出目录中，tsc 会在三个软件包中报告“Cannot find module '@proagentstore/sdk/client'”。VCQA 的 types 检查会调用 tsc，并将其评分设为 0/100。在此实测：仅运行 pnpm --filter @proagentstore/sdk build，无需更改源代码，types 就从 0 升至 100，综合评分从 65 升至 71。这正是 #288 所报告的“类型检查失败”——原因是 dist 尚未构建，而不是代码有问题。如果没有这个前缀，该命令就会在每次全新检出时制造这种误报。

--skip-tests 是有意设置的，报告评分时也会使用此参数。否则，VCQA 的 testing 检查会自行运行测试套件；在这里，这意味着在一次已运行约 35 项其他检查的扫描中，运行 integration 项目——通过 CDP 操作真实 Chrome、绑定套接字，并执行真实的 git clone。运行测试请使用 pnpm test；此命令用于衡量其他所有方面。脚本中固定了 CLI 版本，因此两人对比评分时使用的是同一个扫描器。

扫描结果由三个文件决定，三者不可互换。

文件	适用范围	为什么不能合并到其他文件中
.vcqa.json	VCQA 自身的文件遍历器	ignore 模式，由进程内运行器读取
.gitleaks.toml	secrets 检查	gitleaks 是子进程；.vcqa.json 不会传递给它
biome.json	lint 检查和 pnpm lint	Biome 会在应用任何忽略列表之前解析自己的配置

这种拆分正是关键所在，也解释了为什么看似简单的单文件修复行不通。 在 2026-08-06，于代码库根目录、在一台有 Agent 工作树正在运行的机器上实测：

• pnpm lint 并不是输出太多，而是根本没运行。 Biome 加载根配置后，如果发现其下有嵌套的 根 配置，就会拒绝启动；而 .claude/worktrees/<agent>/ 中包含一份本仓库的 biome.json 副本。它以状态码 1 退出，并提示“Found a nested root configuration”，什么也没检查。通过在 files.includes 中添加 !.claude 修复——而且必须这样写。相邻的每个条目都是 !**/x，但在工作树（位于 .claude/ 下）中工作时，!**/.claude 会匹配某个 上级目录，因此会把整个检出目录排除在自身之外，显示“Checked 0 files”，并以状态码 0 退出。读取内容为空却报告成功，比直接崩溃更糟。!.claude 会以配置根目录为基准解析；已验证从仓库根目录检查 891 个文件，从工作树内部检查 807 个文件。
• 462 条 gitleaks 发现中，有 451 条（97.6%）来自 .claude/worktrees/**——同样的 3 个文件在每个 Agent 会话中都被重复报告，25.4 秒扫描了 338 MB。secrets 得分为 25/100，是报告中最差的检查项，几乎全因重复内容。使用 .gitleaks.toml 后：11 条发现，17.5 MB，1.7 秒。这 11 条是实际源代码中的真实路径，因此有意保留并公开。

Lint 是一道门禁，现在每个代码树都纳入其中（#326）。 即使让 pnpm lint 运行起来，所有规则仍只是建议——它并未纳入任何工作流，因此 300 条发现不断累积，却从未被告知是回归问题。ci.yml 会运行 pnpm exec biome check --error-on-warnings packages workers store agents/coder，这些目录目前均为 0 个错误、且 0 条警告。使用 --error-on-warnings，是因为这些代码树以往的每条发现都是警告；忽略警告的门禁毫无保护作用。使用 pnpm exec 而非 npx，确保运行的是锁定版本的 Biome，避免新的上游规则在没有本仓库提交的情况下，让绿色的 main 变红。

这一步最初只涵盖 packages 和 workers/mcp，因为只有当前数量已为 0 的目录才能启用门禁。其余目录于 2026-08-07 纳入：workers/api 的最后一条发现是一个 useOptionalChain，而看起来多得多的 any 技术债务全部来自 *.test.ts 中的 184 处用法；本仓库的 tsconfig 会排除这些文件，因此它们以前也从未经过类型检查。现在 workers 涵盖 api、host 和 mcp，因此新建的 worker 从首次提交起就会纳入门禁，而不是累积一批无人知晓的积压问题。新代码树必须以零问题纳入，或随自身的清理步骤一同纳入；不要过早扩大范围后再使用 continue-on-error，那只会让这一步形同虚设。

仍有意纳入范围的内容。 agents/coder 和 agents/job-application-assistant 属于 Tier-0——它们是由 CI 进行类型检查和构建的 pnpm 工作区成员——因此会被扫描。之前放在它们旁边、不会运行的 vendored 种子副本已于 2026-08-01 删除（f9980a8），而 scripts/check-agents-allowlist.mjs 会确保它们不会被重新纳入；agents/ 下已没有需要排除的陈旧内容，对 agents/** 设置忽略现在只会掩盖要发布的代码。若有人添加此类内容，scripts/check-qa-config.mjs 会使 CI 失败。

**添加忽略模式之前，**请注意，VCQA 不是 glob 引擎。它只理解 prefix/**、*suffix 和普通路径前缀，其他模式一概不支持。**/dist/** 看起来正确，却什么也匹配不到，而且会静默失败；VCQA 已按目录名在任意深度排除 dist（以及 node_modules、.claude、coverage 等），因此你想到的大多数模式其实都已覆盖。保护检查会拒绝永远无法生效的模式。

FreeStore 生态系统的一部分

商店	URL	产品
FreeAppStore	freeappstore.online	PWA 应用
FreeGameStore	freegamestore.online	浏览器游戏
FreeWebStore	freewebstore.online	AI 构建的网站
FreeAgentStore	freeagentstore.online	浏览器 AI 工具
ProAppStore	proappstore.online	付费应用
ProAgentStore	proagentstore.online	服务端 AI Agent

许可证

MIT