人工智能AI Agent多智能体Agent 工作流深度研究AI 评测【免费下载链接】PRAXISTAutonomous research system for measurable, computer-executable research.项目地址https://gitcode.com/gh_mirrors/pr/PRAXIST点击查看免费下载PRAXIST 是一套面向可度量、可在计算机上执行的自主研究系统。本文将围绕官方插件 API 参考docs/reference/plugins.md与通用插件指南docs/guides/plugins.md展开系统讲解 PRAXIST 的可执行通用插件体系插件清单plugin.yaml的字段语义、稳定性与信任的边界、最小可执行插件的形态、插件自带的资源、插件内容哈希与回放一致性以及 discovery / resolve / load 三段式加载链路。读完本文你将掌握如何阅读插件 API、如何判断一段代码该放插件还是任务项目、如何为插件编写测试并能直接对照 praxist/plugins/ 目录下的真实插件清单动手实践。一、插件 API 参考的定位与阅读方式docs/reference/plugins.md是 PRAXIST 官方文档站中的API Reference 页见 mkdocs.yml 的导航配置它通过mkdocstrings指令见 mkdocs.yml从源码 docstring 自动生成每个插件的适配器adapterAPI。文档站启用mkdocstrings插件并配置paths: [.]因此参考页中的::: praxist.plugins.xxx.adapter会被渲染为对应模块的完整 API 文档。参考页按插件类别组织共六组类别覆盖的插件模块Agent RuntimesAgent 运行时claude_sdk.adapter、codex_sdk.adapterAPI Providers模型提供方openrouter、orcarouter、anthropic_messages、openai_compatible、deepseek_alias、cloudflare、groq_alias、mistral_alias、xai_aliasWorkflow Stage工作流阶段research_loop.startup、research_loop.stage、research_loop.c5_materializer、reviewer_stub.adapterTools工具evaluation_tools、finding_graph_query、frontier_tools、memory_tools、prior_work_tools、literature_lookupGraph Maintainer知识图谱维护者finding_graph_mvp.adapter、finding_graph_mvp.engine、finding_graph_mvp.cliBudget Policy预算策略budget_policies.default_basic.policy这些被引用的模块都能在 praxist/plugins/ 目录树中找到对应实现。参考页本身是入口真正刻画插件契约语义的是各插件目录下的plugin.yaml清单文件与 praxist/core/registry.py 中的加载器实现——下文将逐一展开。二、插件是什么可复用的系统组件PRAXIST 中的通用插件Generic Plugin是指位于praxist/plugins/**随系统捆绑或其它显式插件根目录下、可跨任务项目复用的系统组件。任务项目也可以在task_path/.praxist/plugins/下携带自己的通用插件这类插件仅当通过--task-path选中该任务时才会以sourcetask_project被发现边界规则详见 Task Projects → Boundary Rules。从 praxist/core/registry.py 可以看到插件系统当前支持 12 种 kind每种 kind 对应praxist/plugins/下的一个复数目录名KIND_DIRS { role: roles, audit_rule: audit_rules, evaluation: evaluations, panel_topology: panel_topologies, agent_runtime: agent_runtimes, budget_policy: budget_policies, workflow_stage: workflow_stages, tool_server: tools, ontology: ontologies, budget_unit: budget_units, model_provider: model_providers, graph_maintainer: graph_maintainers, }其中role、audit_rule、evaluation、panel_topology、agent_runtime、budget_policy、workflow_stage属于V1_STABLE_KINDS要求v1_stable稳定性tool_server、ontology、budget_unit、model_provider、graph_maintainer属于EXPERIMENTAL_KINDS默认experimental稳定性两者的差异详见下文稳定性一节。参考页列出的六类插件正是这 12 种 kind 中与执行强相关的六类Agent 运行时agent_runtime、模型提供方model_provider、工作流阶段workflow_stage、工具tool_server、图谱维护者graph_maintainer、预算策略budget_policy。三、插件清单 plugin.yaml字段语义详解每个插件都必须携带一份plugin.yaml清单声明插件 kind 与名称版本与稳定性可执行入口entrypoint或仅清单契约manifest-only依赖与兼容性参与回放哈希replay hash覆盖的代码与资源。registry.py 中的PluginMetadata.from_manifest定义了清单字段的解析逻辑与默认值字段类型默认值语义schema_versionint1清单模式版本namestr必填插件名必须与插件目录名一致kindstr必填插件类别必须与目录 kind 一致versionstr0.1.0插件版本用于版本约束求解protocol_versionint1协议版本当前强制为1stabilitystr按 kind 默认接口契约的稳定性承诺descriptionstr插件说明compatibilitydict{}兼容性约束praxist_core、python等dependencieslist[]依赖的其它插件 refkind:namecapabilitieslist[]插件提供的能力标记用于执行前能力校验entrypointstr | nullNone可执行入口格式为module:functioncodelist[]参与内容哈希的代码文件/globassetslist[]参与内容哈希的资源文件/glob以一个真实的捆绑插件为例——Claude SDK 运行时 praxist/plugins/agent_runtimes/claude_sdk/plugin.yamlschema_version: 1 name: claude_sdk kind: agent_runtime version: 0.1.0 protocol_version: 1 stability: v1_stable description: Claude SDK runtime adapter with AgentRunRequest execution, legacy BaseAgent compatibility, and redacted transcript conformance. compatibility: praxist_core: 0.1.0,1.0 python: 3.11 dependencies: [] capabilities: - runtime.claude_sdk - runtime.agent_run_request - runtime.executable_legacy_adapter - runtime.mock_transcript_conformance runtime: execution_modes: - native_agent_run_request - legacy_base_agent_compat compatible_model_providers: - model_provider:anthropic_messages - model_provider:openrouter - model_provider:orcarouter - model_provider:deepseek_alias cache_strategy: runtime_auto_cache event_schema: praxist.agent_event.v1 usage_reporting: usage_or_usage_unknown entrypoint: adapter:create_runtime code: - adapter.py assets: []注意两点约定其一不同 kind 允许携带 kind 专属的顶层字段如agent_runtime的runtime、model_provider的provider、panel_topology的topology、tool_server的tool_server、workflow_stage的contracts它们由各自 kind 的消费方解析不会写入通用元数据其二entrypoint声明的入口模块必须出现在code列表中否则校验直接失败见 registry.py 的_validate_metadata。3.1 稳定性是接口契约信任来自来源stability描述的是插件承诺的接口契约——schema、prompt 形态、角色 API 向后兼容性——而不是该插件是否可信执行。信任由插件的**来源source**决定通过TRUSTED_EXECUTION_SOURCES即bundled与task_project把关SOURCE_PRIORITY {task_project: 0, project: 1, user: 2, bundled: 3} TRUSTED_EXECUTION_SOURCES frozenset({bundled, task_project})两条路径的稳定性校验策略不同对应 registry.py 的实现捆绑插件bundled必须声明其 kind 要求的严格稳定性。例如panel_topology、agent_runtime、workflow_stage属于V1_STABLE_KINDS其stability必须是v1_stable否则报错stability must be v1_stable, got ...。因为捆绑插件影响每一个任务项目契约必须成立。任务本地插件task_project位于task/.praxist/plugins/下作用域隔离于单个任务项目且设计上允许高频变更因此可以声明任意stability通常是v0_experimental而不会触发 kind 匹配检查——此时信任轴是来源本身。从源码注释看这一设计issue #80的动机是如果对任务本地插件叠加稳定性检查任务作者要么过早地声明v1_stable要么被迫携带手动覆盖项都不合理。3.2 兼容性、依赖与能力标记compatibility目前主要用于声明praxist_core与python的版本区间仓库内所有捆绑插件均声明praxist_core: 0.1.0,1.0、python: 3.11。dependencies使用kind:name形式的插件 ref 声明依赖。解析器在选插件时会递归展开依赖并做环检测——若出现依赖环会抛出Plugin dependency cycle: a - b - aregistry.py。真实的依赖例子evaluation_tools工具声明依赖workflow_stage:research_loop与graph_maintainer:finding_graph_mvp见 praxist/plugins/tools/evaluation_tools/plugin.yaml。capabilities是执行前的能力声明消费方通过require_execution_pluginregistry.py校验已选插件是否具备某 capability缺失则拒绝执行。例如tool_server类插件用required_capability声明其依赖的系统能力运行时runtime类插件用runtime.agent_run_request表示支持 AgentRunRequest 执行协议。四、最小可执行插件目录形态与入口契约一个可执行插件通常具有如下形态源自 docs/guides/plugins.mdpraxist/plugins/kind_plural/name/ plugin.yaml adapter.py README.md # 可选复杂插件建议提供plugin.yaml声明插件 ref、兼容性、入口entrypoint以及参与源码哈希的代码文件adapter.py暴露一个与 kind 契约匹配的小型工厂factory或适配器对象。entrypoint必须是module:function格式。加载器load_plugin_entrypointregistry.py会解析module:function校验入口模块不得逃逸插件根目录若插件位于捆绑根目录则按praxist.plugins.kind_dir.name.module直接importlib.import_module否则基于插件路径与内容哈希生成确定性模块名_praxist_plugin_kind_name_hash16用spec_from_file_location加载并临时把插件根目录插入sys.path结束后还原校验工厂可调用。工厂的实例化遵循统一约定instantiate_plugin_entrypointregistry.py工厂要么零参数要么接受一个SelectedPlugin参数位置或关键字否则报错。例如claude_sdk、codex_sdkentrypoint: adapter:create_runtimeopenrouter、orcarouter、anthropic_messages等entrypoint: adapter:create_providerresearch_loopentrypoint: stage:create_stageevaluation_tools等工具entrypoint: adapter:create_tool_pluginfinding_graph_mvpentrypoint: adapter:create_graph_maintainerdefault_basicentrypoint: policy:create_policy。以工具插件为例finding_graph_query/adapter.py 的create_tool_plugin工厂返回一个描述 MCP 工具服务器的字典包含tool_server_ref、server_name、factory指向真正创建 MCP server 的函数、tool_names、visibility、required_capability与handlers映射。这种方式让插件清单与可执行实现分离——清单描述契约adapter 提供执行物。4.1 内容哈希与回放一致性插件的内容哈希compute_plugin_content_hashregistry.py覆盖清单本身 code/assets中声明匹配的所有文件使用 SHA-256哈希路径集合 {plugin.yaml}∪ 由code/assets中每个 pattern支持 globrecursiveTrue展开出的文件所有文件必须位于插件根目录内任何逃逸路径绝对路径、含..、glob 匹配到根外文件都会抛错未在清单中声明的被导入模块或资源不参与该插件的内容哈希——这是回放可复现性的边界务必把参与行为的文件全部声明进code/assets。这一点在 research_loop/plugin.yaml 中有直观体现它的code覆盖stage.py、startup.py、c5_materializer.py与backend/**/*.pyassets覆盖backend/**/*.jinja2与backend/**/*.md——模板和文档资源也纳入哈希因为它们在运行期被加载进提示词。4.2 命名建议不要习惯性地把所有实现文件都命名为plugin.py而应使用能描述插件内部结构的名字如adapter.py、engine.py、cli.py、stage.py、policy.py。这也与测试约束呼应tests/conformance/test_plugin_executable_closure.py断言捆绑插件清单中的code必须包含对应文件如research_loop的stage.py/startup.py/c5_materializer.py/backend/**/*.py都必须真实存在。五、插件自带的资源Plugin-Supplied Assets部分插件 kind 允许随清单携带资源通过专用清单字段声明而不是临时路径。目前可见的典型是panel_topology插件可以在清单中声明topology.prompts_dir随插件自带供BasePI与ChairArbiter使用的 Jinja 提示词模板多 Agent 首席研究员PI面板的捆绑提示词作为 fallback插件未覆盖的部分回退到捆绑模板。详见 Panel Topology Prompts。其解析逻辑在 praxist/core/panel_topology.py 的panel_topology_from_manifest与_resolve_prompts_dirL242-L267中提供plugin_path时相对prompts_dir基于插件目录解析为绝对路径绝对prompts_dir无条件接受plugin_path未知例如单元测试单独解析清单时声明相对prompts_dir会直接抛ValueError避免产生一个后续找不到模板的残废拓扑。捆绑的 Multi-PI 拓扑 legacy_multi_pi_two_round/plugin.yaml 未声明prompts_dircode/assets均为空即完全使用捆绑提示词而它的topology区块完整定义了topology_ref、chair_role_ref、peer_memo_visibility: anonymized、high_stakes_triggers关键词列表、三种运行模式mini/full/high_stakes对应的角色集合、roles的角色映射含model_profile_ref: strong_reasoner、private_pack_key、visibility各轮可见性以及rounds四轮编排evidence_freeze → independent_memos → cross_review → chair_synthesis含并行度与超时秒数。这正是清单即契约的完整范例。当插件携带资源时请把路径声明到code/assets中使其参与回放源码哈希即本文 4.1 节。六、发现、解析与注册三段式加载链路插件加载器PluginLoaderregistry.py实现发现 → 解析 → 加载三段式流程6.1 发现discoverPluginRoots.defaults()registry.py构建四类插件根来源默认根路径备注bundledrepo/praxist/pluginsPRAXIST_BUNDLED_PLUGIN_ROOTS系统捆绑projectworkspace/.praxist/pluginsPRAXIST_PLUGIN_ROOTS项目级user~/.praxist/plugins用户级task_projecttask_path/.praxist/plugins仅当传入task_pathdiscover()按task_project → project → user → bundled顺序遍历各根目录下KIND_DIRS的 kind 子目录对每个kind_dir/*/plugin.yaml读取清单并做一致性校验清单kind必须匹配目录 kind、清单name必须匹配插件目录名。发现过程对单个插件的异常是非致命的——坏清单被记录进warnings而不是中断整个发现registry.py。6.2 解析resolveresolve()对kind:namerefs 求解核心规则来源优先级task_project(0) project(1) user(2) bundled(3)数值越小越优先同来源取更高版本、路径字典序靠前者_choose_candidateregistry.py。来源过滤ref 可携带source约束PluginRef支持kind:namesource或 dict 形态只匹配指定来源的候选。版本约束支持、、、、及逗号分隔的复合约束_version_satisfiesregistry.py。执行策略enforce_bundled_executionTrue时对HARDCODED_EXECUTION_KINDS即全部 12 种 kind仅保留TRUSTED_EXECUTION_SOURCESbundled/task_project中的候选——这正是测试中验证的执行解析过滤项目级与用户级覆盖行为见 tests/conformance/test_core_plugin_contracts.py。必选性ref 默认requiredTrue找不到候选时抛Required plugin not found: kind:namerequiredFalse则静默跳过。依赖展开与环检测选中插件后递归解析其dependencies同时记录dependency_edges供审计。遮蔽记录shadowed同一kind:name若存在多个来源的候选未被选中的候选会进入shadowed列表记录selected_*与shadowed_*的 source/version/path 对照便于审计为什么选了这个版本_shadowed_recordsregistry.py。解析结果是一份praxist.plugin_resolution.v1清单algorithm_version: 2包含selected、shadowed、dependency_edges、content_hash_algorithm: sha256、warnings、errors等字段。每个选中插件都携带source、path、content_hash与selected_by记录由谁触发选择。resolve同样支持disabled_optional以禁用可选插件。6.3 加载load与冻结注册表load()从解析清单重建PluginRegistry对每个选中记录若声明了entrypoint则实例化插件对象否则仅保留元数据字典。PluginRegistryBuilder.add()拒绝重复 keyfreeze()之后注册表只读。PluginRegistry提供get可空查询、require缺失即抛KeyError、descriptor/descriptor_for_ref取选中描述、list(kind)按 kind 列出等接口。消费方通过require_execution_plugin(registry, ref, kind..., capability...)做执行前校验kind 不匹配、非信任来源且无入口、缺少能力标记三种情况都会抛错registry.py。此外assert_bundled_execution_manifestregistry.py会在运行开始时对解析清单做整体审计保证可执行插件的选择来自受信来源。6.4 兼容性路径对只走兼容路径的旧场景static_resolution_manifest与static_selected_pluginregistry.py会生成确定性静态描述sourcebundled、pathbuiltin://static/...、基于kind:name:0.1.0的固定 SHA-256 摘要用于兼容性占位不带任何可执行入口。七、六类插件的 API 与真实清单对照参考页将插件 API 划分为六类下面结合仓库真实清单逐一说明其契约要点。7.1 Agent Runtimes运行时适配器claude_sdkplugin.yamlClaude SDK 运行时适配器runtime.execution_modes支持native_agent_run_request与legacy_base_agent_compat两种模式compatible_model_providers白名单包括anthropic_messages、openrouter、orcarouter、deepseek_aliasevent_schema: praxist.agent_event.v1、cache_strategy: runtime_auto_cache。codex_sdkplugin.yaml官方 Codex Python SDK 运行时基于长生命周期本地 app-server 客户端runtime.compatible_model_providers覆盖 OpenAI 兼容体系openai_compatible、openrouter、orcarouter、deepseek_alias、cloudflare、groq_alias、mistral_alias、xai_alias其注释说明 Cloudflare Workers AI 走 OpenAI 兼容的 codex relay 通道因无 Anthropic 路由而被刻意排除在 claude_sdk 白名单之外能力标记包含runtime.managed_credentials、runtime.mcp_stdio等code声明了adapter.py、_auth.py、_events.py、_mcp.py、_relay.py、_sandbox.py六个文件。运行时契约的一致性由runtime_for_ref与event_types_for_conformance见 praxist/core/runtimes.py统一支撑事件形状如agent_run_started、assistant_text、final_result有共享的 conformance 校验见 tests/conformance/test_core_plugin_contracts.py。7.2 API Providers模型提供方适配器九个 provider 插件全部位于 praxist/plugins/model_providers/统一kind: model_provider、stability: experimental、entrypoint: adapter:create_provider。provider区块声明api_format、default_model、cache_strategy、usage_reporting、model_profilescheap_peer/strong_reasoner与compatible_model_patterns。举例openrouterplugin.yamlapi_format: openrouterdefault_model: anthropic/claude-opus-4.7cheap_peer: anthropic/claude-sonnet-4.5compatible_model_patterns: [*/*]orcarouterplugin.yamlapi_format: orcarouter默认与两个模型画像均为orcarouter/autoanthropic_messagesplugin.yamlapi_format: anthropic_messagescache_strategy: provider_explicit_cacheexplicit_cache_strategy: anthropic_messages_cache_controlcompatible_model_patterns: [claude-*]。provider 的模型契约被 conformance 测试直接断言见 test_plugin_executable_closure.py 对 openrouterdefault_model/model_profiles.cheap_peer的校验说明清单中的模型画像会被下游建模层消费相关归一化逻辑见 praxist/core/modeling.py。7.3 Workflow Stage工作流阶段research_loopplugin.yaml必选的研究循环阶段entrypoint: stage:create_stage能力包括workflow.research_loop、workflow.synthesis_trigger、workflow.stop_signal_drain、workflow.experiment_survival_guards其code/assets覆盖stage.py、startup.py、c5_materializer.py与整个backend/**见 praxist/plugins/workflow_stages/research_loop/ 目录。reviewer_stubplugin.yaml默认禁用的本地审阅阶段contracts.enabled_by_default: false声明了输入manuscript_artifact、evidence_refs、artifact_index、trajectory、run_summary、输出review_artifact、reviewer_findings、artifact schemacore:review_artifact.v1与执行模式local、artifact、run_artifact、claim_check、review等promotion_effect: none。参考页分别引用research_loop.startup、research_loop.stage、research_loop.c5_materializer三个模块——对应 startup.py、stage.py、c5_materializer.py它们分别承载阶段启动逻辑、阶段主对象与 C5 素材化materializer逻辑。7.4 Tools工具服务器参考页引用evaluation_tools、finding_graph_query、frontier_tools、memory_tools、prior_work_tools、literature_lookup六个工具插件的adapter。工具插件统一kind: tool_server、stability: experimental、entrypoint: adapter:create_tool_plugin。tool_server区块声明server_name、tool_names、visibility如peer、panel与required_capability。例如 finding_graph_query/plugin.yaml 声明 MCP 服务器finding-graph-query与三个只读工具get_finding_neighbors、get_finding_subgraph、get_unlinked_recent_findings并依赖research_loop与finding_graph_mvp其 adapter 工厂在 adapter.py 中把handlers映射到具体处理函数。evaluation_tools/plugin.yaml 则暴露log_experiment_metrics、share_finding、get_leaderboard、wait_for_file、read_tool_result五个工具服务于 findings、metrics 与受约束的任务自有文件就绪检查。7.5 Graph Maintainer知识图谱维护者finding_graph_mvpplugin.yaml是现有 finding graph 引导引擎的兼容描述符stability: experimental依赖workflow_stage:research_loop能力标记graph.finding_graph、graph.sidecar_index、graph.prompt_guidance、graph.unlinked_recent_diversity、graph.agent_declared_links、graph.non_blocking。code声明adapter.py、atomic_io.py、engine.py、cli.py、viz.py参考页分别引用adapter、engine、cli三个模块。7.6 Budget Policy预算策略default_basicplugin.yaml是内部冒烟测试用的通用确定性预算策略别名stability: v1_stable、capabilities: [budget.decide]、entrypoint: policy:create_policy、code: [policy.py]。conformance 测试要求其注册对象具有decide方法见 test_plugin_executable_closure.py预算策略的语义由 praxist/core/budget.py 统一承载。八、什么该进插件什么该进任务项目参考指南给出了两条决策测试Decision Test新增插件前问两个无关的任务项目能否在不复制任务事实的前提下复用这段代码。如果答案是否定的它更可能属于任务项目。向 core 添加代码前问这个行为能否通过插件被选择、替换或禁用。如果能它就属于插件。适合做成通用插件的内容包括运行时适配器runtime adapters、API 提供方适配器API provider adapters、工具服务器tool servers、工作流阶段workflow stages、图谱维护者graph maintainers、通用预算策略generic budget policies。反之基准测试专属的研究事实、任务本地的角色契约不应塞进通用插件——它们属于任务项目。这一点在测试中也有镜像test_plugin_executable_closure.py断言自动研究运行时代码必须活在插件边界内praxist/plugins/**/*.py在SOURCE_PATTERNS中而auto_research/...路径被禁止存在并断言 core 分发层不得内嵌插件元数据表tests/conformance/test_plugin_executable_closure.py。九、插件测试四层保障插件改动应当补充测试默认测试路径不得依赖真实模型密钥、网络、GPU 或外部任务检出插件本地单元测试插件有真实代码时必写kind 专属 conformance 测试位于tests/conformance/——仓库中的 test_plugin_executable_closure.py 与 test_core_plugin_contracts.py 就是这类测试的现成范本前者验证插件代码闭合于插件边界、清单 code 文件真实存在、核心插件可解析可实例化、工厂签名可用、provider 模型契约正确后者验证来源优先级project user bundled、执行解析过滤 project/user 覆盖、运行时事件形状共享、provider 归一化与缓存哈希、预算策略 conformance 案例工作流冒烟测试插件参与启动或运行执行时必写praxist/testing/fake_workflow_fixture.py提供了run_fake_workflow_fixture这类离线假工作流夹具回放/哈希测试插件代码或资源影响运行可复现性时必写。十、结语从 API 参考到自定义插件docs/reference/plugins.md是进入 PRAXIST 插件世界的目录页真正的契约细节沉淀在每份plugin.yaml与 praxist/core/registry.py 的加载链路中。梳理本文要点清单即契约kind/name与目录强一致stability承诺接口兼容、source决定执行信任entrypoint必须module:function且入口模块列入code内容哈希覆盖一切运行时输入把会参与行为的代码与资源全部声明进code/assets否则回放哈希存在盲区来源优先级与执行过滤task_project → project → user → bundled的解析顺序、TRUSTED_EXECUTION_SOURCES的执行门槛是理解谁能执行的关键六类插件各有专属区块runtime、provider、tool_server、topology、contracts分别描述运行时模式、模型画像、工具清单、拓扑编排与阶段契约。若想基于这些边界编写自己的可执行插件推荐先阅读 Generic Plugins 指南 与 Task Projects 边界规则再对照 praxist/plugins/ 下与目标 kind 同类的真实清单复制改造最后用tests/conformance/中的既有测试作为 conformance 基线确保新插件通过解析、实例化与执行能力校验。赞分享人工智能AI Agent多智能体Agent 工作流深度研究AI 评测【免费下载链接】PRAXISTAutonomous research system for measurable, computer-executable research.项目地址https://gitcode.com/gh_mirrors/pr/PRAXIST点击查看免费下载相关推荐Anarlog Hooks 插件权限参考run_event_hooks 命令的 ACL 授权机制与执行边界Anarlog Hooks 插件权限参考run_event_hooks 命令的 ACL 授权机制与执行边界 本文以 plugins/hooks/permissAI 应用人工智能语音本地部署桌面应用音频Netcatty 插件开发实战以 Hello Netcatty 示例掌握插件清单、运行时 SDK 与终端 Provider 机制Netcatty 插件开发实战以 Hello Netcatty 示例掌握插件清单、运行时 SDK 与终端 Provider 机制 导读 Netcatty 是集3步解决PC游戏手柄兼容问题AntiMicroX全面配置指南3步解决PC游戏手柄兼容问题AntiMicroX全面配置指南 还在为PC游戏不支持手柄而烦恼吗想用游戏手柄畅玩所有PC游戏却总是遇到兼容性问题AntiMi桌面应用GUI 自动化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
