人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载本指南深入解析 IronClaw 中产品命令列车Product Command Train的完整设计——它统一了 Slack、Telegram、WebUI 三端的命令输入补齐了命令表面的三大缺口并堵住了/model set等租户级控制命令无角色校验的安全漏洞。读完本文你将掌握 IronClaw 命令系统的共享管线架构、CommandAudience角色门控模型、WebUI 命令面板的服务端驱动实现以及 Slack 原生/ironclaw斜杠命令的传输层归一化方案并能直接对照仓库源码定位每一处落点。背景命令表面上的三个缺口与一个安全漏洞设计文档 2026-07-29-product-command-train-design.md 开篇列出了在规划命令表面时发现的四个问题前三个是体验缺口第四个是安全漏洞Slack 体验缺口命令必须以带前导空格的形式/status输入才能生效。因为 Slack 客户端会拦截裸/text用于自己的斜杠命令系统未注册的命令会在客户端侧直接报错永远到不了应用。WebUI 体验缺口Web 聊天输入框完全没有命令支持——在 web 聊天里输入/status会作为一条普通 LLM 轮次提交。管理员后门安全/model set与/model set-provider会执行LlmConfigService::set_active这是一次全租户范围的 LLM provider/model 热切换但命令路径上没有角色检查reborn_services.rs::execute_product_model_command→invoke_llm_active_set。同理十个生命周期命令extension_configure、skill_install等也是租户级操作却合法出现在任意渠道 manifest 的commands [...]声明中validate_declared_product_command接受整个注册表。内置的 Slack/Telegram 清单今天只声明了[status]所以漏洞在第一方渠道上是潜伏的——但任何第三方扩展 manifest 都可能把租户级控制暴露给配对的 DM 用户。在深入各 PR 之前先建立当前状态基线文档标注于 main 分支 2026-07-29通用骨干已经落地对应 PR #6816 及其邻接提交分类ironclaw_extension_host::extension_ingress在每条归一化渠道消息上运行classify_channel_inbound_text定义于ironclaw_host_api::product_adapter::inbound/cmd args变为携带归一化InboundCommandPayload的ChannelInboundClassification::Command准入ironclaw_assistant::DirectConversationCommandAdmission——仅限直接会话 渠道 manifest 声明的命令集合失败即关闭fail-closed拒绝帮助只列出已声明命令分发类型化的ProductCommand→ProductSurface::invoke操作product.model.command、product.status.command、product.lifecycle.command绑定解析提供binding.actor_user_idworkflow.rs::dispatch_product_command结果CommandResultViewtitle/fields/lines由RunDeliveryObserver作为渠道消息投递帮助文本通过with_enabled_commands限定范围注册表ironclaw_assistant::commands——描述符只带名称 别名无 title/description/usage清单一度是model、status别名progress 十个生命周期命令。设计文档同时记录了一个前置 PR#6678分支alpine-fightOPEN、CONFLICTING它早于已落地的骨干仍包含本列车上需要的未落地切片描述符元数据、GET/POSTWebUI 命令路由、以及 composer 斜杠菜单。决策总览八项关键取舍设计文档用一张决策表固定了八项取舍它们是后续所有实现细节的锚点#决策选择1#6678 的去向Rebase到 main 作为 PR-2 载体冲突一律以 main 已落地的形态为准。2Slack 原生命名单一/ironclaw分发器/ironclaw status、/ironclaw model set …。Slack 命令命名空间是 workspace 全局的内置/status无法覆盖生态惯例是应用命名分发器/github …、/jira …。不注册别名未来新命令无需任何 Slack 应用改动。仅限 SlackTelegram 命令命名空间是 per-bot 的bot DM 中/status无歧义群聊用/statusBotName原生消歧所以 Telegram 保留直连命令——分发器只是 Slack 的呈现层不是管线词汇。3管理命令现在做角色门控product 决策 remove-vs-gate 待定选 gate 使两个结果都可达。按动作粒度/model裸读是 Userset/set-provider及生命周期族是 Admin。4可见性处处按角色过滤WebUI 清单按调用者角色过滤Slack 只原生注册面向用户的命令渠道帮助文本统一过滤为用户受众命令对所有角色一致按角色过滤是 WebUI 面板的职责准入是兜底。准入拒绝是最终防线——隐藏从来不是控制手段。5列车顺序Gate → Palette → SlackPR-1 → PR-2 → PR-3堆叠推进。不存在浏览器或 manifest 暴露未门控租户控制的窗口期。6WebUI 结果临时system-notice 气泡类 Slack沿用 #6678 的形态。按事件规则明确为临时事件不是持久时间线事件持久渲染留待未来决策。7内置清单声明[model, status]在 PR-1 中与门控同批。生命周期命令在内置渠道上保持未声明管理员从 WebUI 管理扩展。第三方 manifest 可以声明它们由准入把关。8别名PR-1 中删除。progress是注册表唯一别名且处处无效声明是精确 token无人声明它。整个机制随之移除aliases描述符字段、别名匹配分支、别名不隐式启用校验规则及其 pins、#6678 的前端别名匹配。如日后真出现同义词需求可从 git 复活。值得注意仓库现状已经超越了这张表的部分内容——/new、/stop、/interrupt三个命令现已随注册表 audience 模型落地见 commands.rs 的COMMAND_SPECSSlack 清单也已声明[model, status, new, stop, interrupt]。这与文档Delivered follow-up一节的规划一致。共享管线一个中心薄边缘设计文档用一个 ASCII 架构图定义了命令系统的核心哲学渠道从不解析或执法命令它们只负责解包传输。所有解析、权限策略、执行与结果塑形只定义一次Slack slash POST Telegram DM WebUI composer /ironclaw status … /status … /status … │ │ │ [slack adapter] [telegram adapter] │ dispatcher unwrap → envelope only │ text /status … (text unchanged) │ └───────────┬───────────┘ │ ▼ ▼ generic ingress sink (extension_host) POST /threads/{id}/commands → shared slash parser (host_api) → same shared parser │ │ ▼ ▼ ┌────────── shared command center (ironclaw_assistant) ──────────┐ │ registry: names metadata audience (commands.rs) │ │ typed parse: ProductCommand::from_payload │ │ policy: direct-conv declared set required_audience × │ │ actor role (channel door: admission service role port; │ │ webui door: same audience table, authenticated caller) │ │ execute: ProductSurface::invoke → per-command handlers │ │ result: CommandResultView (title/fields/lines) │ └──────────────────────────────────────────────────────────────┘ │ │ ▼ ▼ observer renders delivers bot msg ephemeral system-notice (per-channel display prefix on help) (generic renderer)两道门、零漂移两扇入口渠道准入门与 WebUI 门查询的是同一个注册表、同一张 audience 表、同一组操作——策略只定义一次从两个入口共用。这是整个设计最关键的架构约束也是后续三个 PR 的公共地基。PR-1 — 角色门控的命令准入PR-1 是列车的第一节负责把谁可以执行什么命令变成强制的、有源码落点的安全边界。它由四个部分组成。注册表audience 双表commands.rs新增CommandAudience { User, Admin }枚举commands.rsProductCommandDescriptor增加audience: CommandAudience字段——这是列示audience。model、status为User所有LifecycleCommandKind描述符为Admin。它驱动帮助文本与PR-2 中面板清单。仓库现状中描述符还同时携带title/description/usage元数据commands.rs这正是 PR-2 设计要补上的部分在落地实现中已与audience并存required_audience(ProductCommand) - CommandAudience——这是执行audience按动作感知commands.rs 中Model{Status|Use|Default}→ UserModel{Set|SetProvider}→ AdminStatus/New/Stop→ UserLifecycle{..}→ AdminUnknown→ UserUnknown永不执行——准入会在 audience 步骤前拒绝未声明 token因此不能藏到 admin 门后。它与解析规格同居一个文件保证两张表由单一文件持有别名机制整体删除决策 8progress别名、aliases描述符字段、名称匹配中的每个别名分支command_spec_for_name、validate_declared_product_command、ProductCommand::descriptor都被移除连同别名不启用契约 pins。当前源码中的command_spec_for_namecommands.rs只做精确名称匹配印证了这一点。角色解析端口Role resolution portironclaw_assistant中新增 trait与ProductCommandAdmissionService并排从准入上下文的installation_idexternal_actor_ref解析绑定用户的AdminUserRolereborn_services/admin_users.rsOwner | Admin | Memberis_admin()。渠道宿主组装crates/ironclaw_extension_host/src/channel_host.rs提供实现渠道身份绑定 → 绑定用户 id → admin-users 角色查询组合层负责装配。AdminUserRole的定义与is_admin()语义位于 admin_users.rsOwner与Admin通过管理员授权边界Member不通过账户状态另有AdminUserStatus { Active, Suspended }。失败即关闭fail-closed语义有三条正向解析出非管理员 →永久AccessDenied解析器报错→ 可重试的失败通知绝不把管理员静默当成员、也绝不把成员静默当管理员未配对/未知 actor 根本到不了准入上游的配对拦截器先拒绝。准入服务command_admission.rsDirectConversationCommandAdmission的执行顺序源码admit方法command_admission.rs直接会话检查route_kind_for_trigger(context.trigger) ! Direct→ 以PolicyDenied拒绝commands are limited to direct conversations声明集合检查requested_command不在allowed_commands构造时经validate_declared_product_command校验、BTreeSet存储→ 以InvalidRequest拒绝附内部帮助文本declared_command_help_text——注释明确说明这是内部 reasonobserver 永不回显audience 检查仅当required_audience为 Adminself.roles.actor_role(context)解析角色非is_admin()→ 以ProductRejectionKind::AccessDenied永久拒绝admin-audience command from a non-admin actor。新拒绝通知使用独立的文案族this command needs an admin account与直接会话通知分离。敏感命令永远不会到达其处理器。帮助文本是角色安全的observer 的静态帮助只包含用户受众的已声明命令对每个角色一致准入拒绝只携带内部原因observer 从不回显。管理员拒绝复用线缆稳定的ProductRejectionKind::AccessDenied键。清单与测试第一方清单crates/ironclaw_first_party_extensions/assets/slack/manifest.toml与.../telegram/manifest.toml声明commands [model, status]按决策 7与门控同批落地。仓库现状中Slack 清单 manifest.toml 的声明已演进为commands [model, status, new, stop, interrupt]——生命周期命令仍然未声明管理员继续从 WebUI 管理扩展。PR-1 的测试矩阵覆盖四层契约层注册表 audience 表 pinned列示 执行与描述符 1:1工作流调用者准入矩阵member/model读允许member/model set以 admin 通知拒绝admin/model set允许解析器报错 → 可重试失败直连限制保留observer/run-delivery 契约静态命令帮助排除 admin-audience 命令对每个 actor 统一不按角色——见决策 4AccessDenied拒绝投递固定文案而不泄漏内部原因channel-host e2emember/model set→ 拒绝通知投递且零命令面调用记录admin 路径恰好执行一次product.model.commandinvoke作为绑定用户两者都穿过一个记录型ProductSurfacedouble两种情况下都零轮次提交。PR-2 — WebUI 命令面板#6678 的 rebasePR-2 把 WebUI composer 变成与 Slack 同级的命令入口同时修复了 PR-1 终审发现的一个角色解析器不对称问题。Rebase 姿态main 优先注册表留在ironclaw_assistant::commands丢弃 PR 中迁往ironclaw_host_api::product_commands的移动——ironclaw_extension_host已为校验依赖ironclaw_assistantDirectConversationCommandAdmission保留丢弃PairedDmCommandAdmission已落地切片分类、manifest opt-in、observer 范围化脱落。存活切片描述符元数据title/description/usage加入 main 的描述符结构与 PR-1 的audience并列——仓库现状 commands.rs 已确认此形态、WebUI 后端、前端面板。隐式所有者规则扩展到两道门PR-1 审计修复PR-1 终审发现渠道角色解析器ChannelActorRoleResolver::actor_rolecrates/ironclaw_extension_host/src/channel_command_roles.rs缺少环境 bearer 操作者旁路没有 admin 目录记录的操作者会被永久拒绝渠道管理命令而 WebUI 门RebornServices::authorize_admin及新的caller_is_command_admin已把caller.operator_config当作隐式 admin。PR-2 关闭该缺口当解析出的绑定用户等于解析器的operator_user_id、且 admin 目录完全没有记录Ok(None)时解析器也返回Ok(Some(AdminUserRole::Owner))。只要存在持久化目录记录——包括Suspended——就仍以记录为准新分支只在无记录时触发。两道门仍有一个不对称点WebUI 的caller.operator_config旁路在目录查询之前短路且完全没有记录管治行为因此 Suspended 操作者记录会被渠道解析器拒绝、却仍能从 WebUI 门进入。该不对称被跟踪而非修复记录于 issue #6877。后端reborn_services/product_commands.rsfacade webui_v2 路由GET /api/webchat/v2/commands—— 带元数据的清单按已认证调用者的AdminUserRole过滤直接查询无渠道端口对照列示 audience。Member 得到modelstatusAdmin 得到 生命周期族。环境 bearer 操作者调用者caller.operator_config在这里同样是隐式 admin无需目录记录。仓库中的路由落点见 handlers.rs 与描述符投影 descriptors.rsPOST /api/webchat/v2/threads/{thread_id}/commands—— 共享解析器 → 与渠道准入完全相同的required_audience策略函数表面不可漂移→ 相同的类型化操作。/status保留线程所有权探测但外来线程与从未创建的线程都解析为同一个常量空闲CommandResultView——永不 404。设计评审裁定这种不可区分的空闲响应与原本计划的外来线程 404 等价甚至更优404-vs-200 的分裂会让调用者逐次猜测其他用户的线程 id。Member 的/model set得到同样的永久AccessDenied形态处理器永不被触达。生命周期命令在此路由上仅列示——execute将每个ProductCommand::Lifecycle以InvalidRequest拒绝与/status、/model帮助路径使用的角色过滤帮助文本同源即使是对已通过 audience 门的 admin 调用者也是如此管理员从 WebUI 的 Extensions 页管理扩展而不是 composer。前端crates/ironclaw_webui/frontend/src/pages/chat/全程服务端清单驱动无硬编码名称保留 PR 的chat-commands.ts匹配器/菜单/渲染器与useChatCommands因决策 8 简化无别名匹配。Composer 菜单升级到 Slack 质量输入框上方锚定弹出层行渲染/name— title — description匹配前缀高亮选中行显示 usage 提示↑/↓ Enter/Tab 补全 Esc 关闭支持 hover/click随输入实时重新过滤。结果以通用 system-notice 气泡渲染临时性决策 6。未知/text按普通消息提交与渠道一致。rebase 的alpine-fight切片之上还落了两处修复(1)EmptyState落地视图的 composer在任何线程存在之前挂载没有把commandsprop 转发给嵌套的ChatInput导致全新线程的第一个 composer 打不开面板——chat.tsx现在把commands{activeThreadId ? chatCommands : []}同时传给EmptyState与ChatInputEmptyState转发它用专门的EmptyStateprop 转发测试 pinned(2)chat.commandFailedlocale 键en中为Couldnt run that command.跨全部 11 个 locale 文件加入供useChat.ts的runCommand客户端执行失败路径使用但评审抓到的缺陷一度让它死接线catch 块调用的是通用failureMessageForRequestError辅助函数而不是这个键且测试 mock 了该辅助函数断链保持绿灯。修复方式是让 catch 直接调用t(chat.commandFailed)并给测试解除 mock、绑定真实翻译器使该键真正可达。PR-2 测试面WebUI 调用者分层member vs admin 清单过滤含操作者隐式 admin 用例/status在自有线程返回渲染视图、外来线程与从未创建的线程不可区分都落到常量空闲视图永不 404member/model set得到AccessDeniedadmin 的生命周期命令执行尝试仍得到InvalidRequest对 admin 也保持仅列示前端 vitest 覆盖键盘导航与元数据渲染、落地 composer 转发修复、locale 键一致性描述符→DTO 投影契约 pinned。PR-3 — 原生 Slack 斜杠命令PR-3 把 Slack 从前导空格变通方案升级为原生/ironclaw分发器且不改动任何 manifest schema 或宿主。传输层复用唯一的签名[channel.ingress]events路由——Slack 允许每个斜杠命令指向任意 Request URL且 HMAC 配方对原始 body 签名、与内容类型无关验证先于内容类型分支发生因此表单 body 上的伪造签名与伪造 JSON body 在同一入口层被拒绝。无需 manifest schema 或宿主改动。crates/ironclaw_slack_extension/src/payload.rs新增normalize_slack_inbound兄弟入口仓库落点在 payload.rs按宿主转发的Content-Type 头分支——application/x-www-form-urlencoded→ 新的斜杠命令表单解析器其他一切含缺失头→ 原样委托给现有normalize_slack_event两个入口共享恰好一份 JSON 解析实现。表单分支内部一个极简的全Optionssl_check探测先于完整斜杠命令表单解析Slack 的ssl_check端点验证 POST 只携带ssl_checktoken从不携带真实调用所必需的channel_id/user_id/command/trigger_id所以探测必须先跑否则握手必然失败于必填字段校验源码顺序见 payload.rs。归一化分发器映射唯一注册命令是/ironclaw其text才是真正的命令。适配器把表单 payload 映射为与事件相同的归一化入站消息command/ironclaw、textstatus …→ 归一化文本/status …对修剪后的 text 前置/防御性剥离用户可能输入的引导/因此/ironclaw /status也可用裸/ironclaw或/ironclaw help→ 归一化文本/help—— 不是注册命令所以确定性地走现有未知命令拒绝路径投递角色过滤的 Available commands 帮助若将来真加入help命令此映射会优雅升级为执行它指向同一 Request URL 的其他已注册命令应用配置错误——第二个斜杠命令对准同一签名端点按{command} {text}原样透传而非映射——适配器不猜测意图由通用分类/准入层以未声明命令拒绝并附角色过滤帮助payload.rs 的slash_command_dispatch_text精确实现这三条分支actor 取user_id会话取channel_id事件 id 为slack-{installation}-slash-{trigger_id}与 event_callback id 空间分命名空间每次调用唯一——Slack 不像 Events API 那样重投斜杠命令payload.rsTrigger 是推导的从不硬编码仅当斜杠表单指示真实 DMchannel_name directmessage或D前缀的channel_id——适配器既有is_dm_channel语义时才是DirectChat否则为BotCommand映射到 Shared 路由由直接会话准入拒绝。硬编码DirectChat会静默击穿非 DM 拒绝边界和 connect-nudge 门——它们都依赖同一 trigger 分类。下游——分类、配对、PR-1 准入、分发、observer bot-DM 投递——与空格前缀路径完全一致。入口 200 在持久化准入之后确认命令执行本身在入口请求内同步完成只有回复投递是异步的通常远在 Slack ≤3s 规则之内路由 20s 截止上限是既有退化后端暴露在 PR 中值一行说明不构成新风险。可见结果就是 bot 的 DM 消息。帮助渲染按渠道的调用前缀中性帮助渲染/model但在 Slack 里裸敲/model会失败被客户端拦截。ChannelPresentationchannel.rs增加可选command_prefix: OptionString字段在 manifest 的[channel.presentation]节声明与supports_markdown/max_message_chars并列Slack 清单设置command_prefix /ironclaw 仓库落点 manifest.toml于是帮助与拒绝通知在那里渲染为/ironclaw model。其他渠道留None保持裸/name渲染。ChannelDescriptor::validate拒绝空值、不以/开头、含控制字符或超过 32 字节的声明前缀ChannelDescriptorError::InvalidCommandPrefixchannel.rs。空格形式的/model路径作为未文档化回退继续工作。帮助文本渲染的 prefix 支持在 commands.rs 的declared_command_help_text_with_prefix中实现——prefix 按声明原样渲染/ironclaw 加model得/ironclaw model。行为边界bot DM 之外调用斜杠走同一管线直接会话准入拒绝observer 的命令反馈路径把拒绝通知直接投到调用渠道envelope.external_conversation_ref()——独立于任何共享会话绑定或slack_allowed_channels允许名单解析因此即使渠道从未在那里配置也能送达。只有 Slack 自身拒绝发帖bot 不是该特定渠道成员时用户才什么也看不到——接受的 MVP 限制PR 中注明response_url投递可消除该依赖是未来修复方向未配对用户走既有 connect-nudge 路径原生注册但 manifest 未声明的命令以角色过滤帮助拒绝。声明是唯一事实源Slack 注册只是呈现层。注册文档而非代码docs/internal/reborn/setup-slack-for-reborn-binary.md与docs/channels/slack.mdx增加一条 app-manifest 注册项注册/ironclaw描述 用法提示status | model set model | help——Slack 在自动补全中渲染这些指向 events URL并说明理由命名空间是 workspace 全局的、内置/status无法覆盖、应用命名分发器是生态惯例。Admin/生命周期命令不注册、不提用法提示决策 4。Slack 清单的声明集合保持[model, status]——声明管的是底层命令不是分发器拼写。Telegram 不变。PR-3 测试适配器一致性分发器映射/ironclaw status …→/status …、引导斜杠剥离、裸/help→/help、字段、trigger、事件 idssl_check短路畸形表单拒绝JSON 事件不受影响测试落点 payload_normalized.rschannel-host e2e签名斜杠形 body 对配对 DM 跑通/ironclaw status端到端 → 渲染的 status 结果投递、零轮次裸/ironclaw→ 帮助通知以/ironclaw显示前缀渲染非 DM 斜杠 → 直连拒绝签名失败仍在入口拒绝pin 扩展到表单 body。跨切面错误处理角色解析器失败 → 可重试、消毒后的通知member 拒绝 → 永久的AccessDenied admin 账户文案任何通知都不含后端字符串、路径或 provider 细节沿用既有ProductSurfaceError分类法所有新拒绝文案都流经既有 observer 通知路径WebUI 返回同样的消毒ProductSurfaceErrorKind族。范围外与标记的后续项设计文档明确列出的后续工作对理解边界很重要WebUI Inference 页角色缺口llm-config 路由LlmConfigService似乎也没有角色门——同样的租户级漏洞经浏览器 Settings 可达。属兄弟修复待产品决策不在本列车Sergey 决策的应急方案若产品决策是remove而非 gateaudience 词汇表使增量很小——删除生命周期描述符/解析臂注册表校验随即对任何声明它们的 manifest 失败关闭保留/model set的 audience 机制。PR-2/PR-3 什么都不用改Telegram 原生命令setMyCommands可以编程注册命令菜单——如需则是 PR-3 的廉价兄弟Slack 直接/model注册无内置冲突若日后想要更短拼写纯粹是分发器旁的增量response_url投递用于 DM 外斜杠拒绝WebUI 时间线中的持久命令结果决策 6 的 revisit已交付后续/new、/stop、/interrupt现已搭载同一注册表 audience 模型连续渠道通过非破坏性轮换外部绑定来重置WebUI/new则开启全新任务仓库现状 commands.rs 已确认这三个命令的 User 级描述符与解析器未来用户命令/compact、Telegram/start深链搭载同一注册表 audience 模型。源码地图快速定位每一处落点设计元素源码落点命令注册表、audience 双表、描述符元数据commands.rs准入服务直连 声明集 audiencecommand_admission.rsAdmin 角色模型与is_admin()admin_users.rs渠道角色解析器含隐式 owner 旁路channel_command_roles.rsChannelPresentation.command_prefix与校验channel.rsSlack 斜杠表单归一化、分发器映射、ssl_checkpayload.rsSlack 清单commands 声明 /ironclaw前缀manifest.tomlWebUI 命令路由与描述符投影handlers.rs、descriptors.rsWebUI 前端命令菜单/匹配器chat-commands.test.ts、chat.tsx命令面契约测试product_command_surface_contract.rs、webui_v2_handlers_contract.rs、e2e_tests.rs结语一节列车三道门一个中心Product Command Train 的核心贡献不是加了三个功能而是把命令系统收敛为**一个中心registry audience 双表 共享解析器 统一操作面、两道门渠道准入门与 WebUI 门、薄边缘渠道只解包传输**的架构。角色门控把此前潜伏的租户级控制漏洞变成源码级强制的安全边界WebUI 面板让浏览器获得与 Slack 同级、且全程服务端清单驱动的命令体验原生/ironclaw分发器在不改管线词汇的前提下解决了 Slack 客户端拦截问题。对后续命令/new、/stop、/compact、Telegram 深链而言它们都只是往同一注册表和 audience 模型里再添一行的增量——这正是这份设计最持久的价值。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐DeepSeek Harness TUI /skill: 斜杠命令让用户按需加载 Skill 指令的设计与实践DeepSeek Harness TUI /skill: 斜杠命令让用户按需加载 Skill 指令的设计与实践 本文以 DeepSeek Harness 仓库人工智能AI AgentAgent 框架DeepSeekDify Web 命令面板实战Goto Anything 的状态所有权、类型化搜索与斜杠命令体系Dify Web 命令面板实战Goto Anything 的状态所有权、类型化搜索与斜杠命令体系 Dify 的前端 web/ 内置了一个全局命令面板 Go人工智能大模型LLMOpsAI 应用RAGAI Agent低代码MoviePilot Agent 斜杠命令分发实战command-dispatch Skill 与 slash API 网关全解析MoviePilot Agent 斜杠命令分发实战command dispatch Skill 与 slash API 网关全解析 MoviePilot 内置后端AI AgentMCP 服务AI 技能上一篇bookdown多语言支持国际化技术文档的编写技巧下一篇Apache SkyWalking 10.0.1 版本解析SBOM 引入、JDBC 驱动组件库扩展与关键缺陷修复创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考