healthcheck（主机安全健康检查）Skill 是什么？

主机安全健康检查Skill：把主机硬化拆成可批准、可回滚的分步流程

一句话定位：面向运行 Otto 的主机（笔记本、工作站、树莓派、VPS），先做只读体检，再按你选择的风险容忍度给出硬化方案，改动前必须经过你逐项批准。
核心能力：建立系统上下文（操作系统、权限、访问路径、网络暴露、备份、磁盘加密、自动更新等）、运行 otto security audit --deep 与 otto update status、生成带命令和回滚方案的补救计划、事后复检并出具最终姿态报告。
最大特点：不断开访问是硬性要求——未经确认连接方式不改远程访问设置，防火墙、SSH、端口、装包、服务、用户组、定时任务等操作都必须明确批准。
可选持续能力：支持通过 otto cron 调度周期性审计与版本检查（如 healthcheck:security-audit、healthcheck:update-status），把一次性体检变成长期巡检。
适合谁：把 Otto 部署在自有机器上的个人开发者、独立运维、小团队，以及希望把“安全基线”变成可复述、可留痕流程的用户。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

该技能的中文名是主机安全健康检查Skill，英文名为 healthcheck，技能 ID 为 13587。

它解决的问题非常具体：当你把 Otto 部署在一台真实机器上（个人笔记本、专用工作站、树莓派、公网 VPS），这台机器的安全状态往往是“说不清、也不敢动”的。开不开防火墙？SSH 要不要禁用密码登录？系统自动更新该不该开？磁盘加密有没有生效？备份是不是最新的？这些问题每一个都牵涉到“改坏了会不会连不上机器”。healthcheck 技能的作用，就是把这件高风险的事拆成只读体检 → 风险姿态对齐 → 计划评审 → 逐项批准执行 → 复检验证的固定流程。

一键安装的思路与步骤：

安装前提：你已经部署了 Otto，并在其网关或主机上可以运行 otto 相关命令；你使用的 AI 客户端/代理平台支持“技能（Skill）”的加载与调用；你对目标主机具备管理员或 root 权限（否则技能按规则只会给出推荐，不会执行变更）。
获取技能：在技能市场 / 技能列表中搜索中文名“主机安全健康检查”或英文名 healthcheck，点击添加或安装；若平台以技能包目录形式管理，则按平台文档将技能目录放入指定路径。具体安装入口、命令与目录路径以官方说明为准。
确认加载：安装后在技能列表中确认 healthcheck 处于启用状态，并确保当前会话有权限读写主机信息。
验证是否生效：向代理提出一句自然语言请求，例如“帮我做一次这台运行 Otto 的机器的只读安全健康检查”。如果技能已生效，代理的行为会明显不同——它会先做模型自检、再尝试推断系统上下文，并以一句话请求只读检查权限，而不是直接甩给你一堆命令或立刻动手改配置。
模型建议：技能文档建议使用较先进的模型（例如 Opus 4.5、GPT 5.2+）运行。代理会自检当前模型，若低于该水平会建议切换，但不会阻止执行，因此普通模型也能用，只是推理与计划质量可能打折。

2. 该技能的主要功能和特点

只读上下文建立：在不改动系统的前提下，按顺序确认操作系统与版本（Linux/macOS/Windows、容器还是主机）、权限级别、访问路径（本地控制台、SSH、RDP、tailnet）、网络暴露（公网 IP、反向代理、隧道）、Otto 网关状态与绑定地址、备份系统与状态、部署上下文、磁盘加密状态（FileVault/LUKS/BitLocker）、系统自动安全更新状态、以及机器的使用模式。
标准化的只读检查命令集：Linux 侧如 uname -a、cat /etc/os-release、ss -ltnup、ufw status / firewall-cmd --state / nft list ruleset；macOS 侧如 sw_vers、lsof -nP -iTCP -sTCP:LISTEN、socketfilterfw --getglobalstate、pfctl -s info、tmutil status。技能要求先征得一次只读检查授权，然后默认执行，只对无法推断的项提问。
Otto 安全审计集成：默认运行 otto security audit --deep，并按需提供 otto security audit（更快、非探测）与 otto security audit --json（结构化输出）；可提供 --fix 选项，但会明确说明它只收紧 Otto 默认值与文件权限，不修改主机防火墙、SSH 或系统更新策略。
版本与更新状态检查：运行 otto update status 报告当前通道与是否有可用更新；也提供 npm view otto version 这类发布版本查询方式，便于用户自行决定何时升级。
风险容忍度配置而非死板模板：提供编号选项——家庭/工作站平衡（最常见）、VPS 硬化、开发者便利性、自定义。用户可以用一个数字回复，也可以自定义约束（开放服务、暴露面、更新频率、访问方式）。
可评审的补救计划：计划必须包含目标姿态、当前姿态摘要、差距、逐项命令、访问保留策略与回滚方案、风险与潜在锁定场景、最小权限说明、凭证卫生说明；任何变更前先展示计划。
执行方式可选：①为我做（引导式，逐步批准）②仅显示计划 ③仅修复关键问题 ④导出命令供以后使用。
验证与报告：执行后复检防火墙状态、监听端口、远程访问是否仍然有效，并重新运行 Otto 安全审计，输出最终姿态报告与遗留项。
持续巡检能力：支持用 otto cron 调度定期审计（推荐作业名 healthcheck:security-audit、healthcheck:update-status），创建前会先 otto cron list 并匹配名称，存在则编辑、不存在则新增。
审计留痕与脱敏：记录网关身份与角色、计划 ID 与时间戳、已批准的步骤与确切命令、退出码与修改的文件；日志中编辑敏感信息，绝不记录令牌或完整凭证内容。
和普通“安全扫描脚本”的差别：普通脚本给你一堆告警就结束；这个技能强制“先读后写、先计划后执行、每步可回滚、事后必复检”，并且明确禁止代理声称 Otto 会替它改防火墙/SSH/系统更新。

3. 如何使用该技能？

第 1 步：发起请求（自然语言即可）

示例输入：

帮我检查这台运行 Otto 的 Mac 的安全状况，先只做只读检查，不要改任何东西。

第 2 步：配合模型自检与上下文建立

代理会先自检当前模型能力（不足时建议切换，但不阻止），然后尝试从环境中推断操作系统、权限、访问方式等信息，并用一句话请求只读检查授权。授予后，它会执行标准只读命令并输出摘要。

第 3 步：运行 Otto 安全审计与版本检查

默认执行 otto security audit --deep 与 otto update status，并报告当前通道、是否有更新、审计发现的问题。

第 4 步：选择风险姿态（用数字回复）

代理会给出编号选项，例如回复 2：

2（VPS 硬化：默认拒绝入站、最小化开放端口、仅密钥 SSH、禁止 root 登录、开启自动安全更新）

如果你不想套模板，也可以直接描述约束，比如“80/443 必须对外开放，SSH 只允许 tailnet 访问，每周检查一次更新”。

第 5 步：评审补救计划

计划中会包含目标、差距、逐步命令、回滚方案和锁定风险。此时建议重点确认三件事：SSH 端口与登录方式是否被改动、防火墙默认策略是什么、回滚命令是否真的能执行。

第 6 步：选择执行方式

回复 1（为我做，逐步批准）、2（仅显示计划）、3（仅修复关键问题）或 4（导出命令）。选择 1 时，每一步都会展示确切命令、影响说明、回滚方式，并确认访问保持可用；出现意外输出会停下征求你的意见。

第 7 步：复检与报告

代理重新检查防火墙、监听端口、远程访问连通性并重跑审计，输出最终姿态报告。

第 8 步：决定是否调度定期巡检

代理会主动询问是否通过 otto cron add 调度（例如每日或每周），并询问频率、时间窗口、输出位置，以及是否一并调度 otto update status。未经明确批准不会创建调度任务。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
healthcheck（主机安全健康检查 Skill）	面向 Otto 主机的“对话式安全体检 + 硬化流程编排”	上下文建立、Otto 安全审计、风险姿态配置、分步计划与回滚、复检报告、cron 定期巡检	需已部署 Otto 与支持技能的 AI 客户端；零脚本编写；需管理员权限才能执行变更	个人开发机、专用工作站、树莓派、VPS 的日常安全基线维护	优势：对话式交互、强制批准与回滚、不断开访问；不足：强依赖 Otto 生态，非 Otto 主机只能参考其流程
Lynis	老牌开源主机安全审计工具	系统硬化评分、建议清单、合规检查项	命令行安装，需自行解读报告	Linux/Unix 主机审计与合规初筛	优势：成熟、免费、报告详尽；不足：只诊断不编排，硬化仍需人工逐条执行与回滚设计
OpenSCAP / CIS Benchmark 扫描器	标准合规基线扫描	按 CIS、STIG 等基线逐项评估，可生成合规报告	配置复杂，需理解基线条目与 profile	企业合规、审计取证	优势：标准权威、可量化；不足：门槛高，误报与“改不动”的条目多，缺少对话式引导
云厂商主机安全中心	云上主机的托管式安全运营	入侵检测、漏洞扫描、基线检查、告警	需在云平台开通并安装 agent，通常涉及计费	云上生产主机、团队统一管控	优势：集中管理、告警及时；不足：偏重监控与告警，本机硬化执行仍需人工，且绑定云环境
Ansible 等配置管理硬化剧本	自动化批量硬化	幂等执行防火墙、SSH、更新策略等配置	需编写或维护 playbook，理解变量与幂等性	多机批量、可重复交付	优势：可批量、可版本化；不足：编写与调试成本高，单机临时体检场景偏重

5. 该技能的典型应用场景与实际体验情况

场景一：独立开发者把 MacBook 当作 Otto 常驻机

角色：全栈独立开发者。痛点：机器上跑着 Otto、放着代码与凭证，但 FireVault 是否开启、Time Machine 是否最新、有无意外监听端口，全靠“感觉”。使用方式：发一句“只读检查这台 Mac”，按提示确认风险姿态为“家庭/工作站平衡”，评审计划后选择“仅修复关键问题”。实际体验：上手几乎零成本，全程用自然语言对话；由于技能会明确区分“Otto 能力边界”，不会出现“以为 Otto 帮你关了防火墙”的误解；注意点是首次仍需自己确认 SSH/远程登录是否开启，否则代理按规则只会给建议。

场景二：小团队把 Otto 网关放在公网 VPS

角色：兼职运维的后端工程师。痛点：公网 VPS 是最高风险面，但改 SSH 配置怕把自己锁在外面。使用方式：选择“VPS 硬化”姿态，先看计划中的“访问保留策略与回滚”，确认保留当前会话后再逐步批准。实际体验：价值最大的是“每步先展示命令 + 影响 + 回滚”，把不可逆操作变成了可审计操作；注意事项是必须诚实回答“你是本地登录还是远程连接”，否则计划中的访问保留策略会失真。

场景三：树莓派/家庭实验室设备的安全基线对齐

角色：家庭实验室爱好者。痛点：设备多、系统杂，更新策略和暴露端口长期无人管。使用方式：先用 otto update status 确认版本通道，再按“家庭/工作站平衡”收敛开放端口，最后让代理调度每周 healthcheck:security-audit。实际体验：一次配置、长期巡检的收益明显；注意 cron 输出要存放在用户批准的位置并避免日志中出现秘密，无头调度运行时输出中会附带提示，让用户回到会话里调用 healthcheck 修复问题。

场景四：交付前的合规自查与留痕

角色：需要向客户证明“主机已按基线加固”的技术负责人。痛点：口头说“加固过了”没有证据。使用方式：走完审计与硬化后，使用“导出命令供以后使用”，并把计划 ID、批准步骤、确切命令、退出码整理成摘要。实际体验：可复述、可留痕是这个技能相对脚本扫描的明显优势；注意内存写入属于需用户明确选择加入的能力，且只在私有/本地会话中使用，公开会话下应改为提供可粘贴的摘要。

6. 该技能能为用户带来的价值

把“不敢动”变成“敢动且能退”：硬性要求改动前展示计划、逐项批准、提供回滚方案与锁定风险说明，直接消除了主机硬化中最劝退的心理门槛。
效率提升体现在流程而非单条命令：手工做一次完整的主机体检（系统信息、监听端口、防火墙、备份、磁盘加密、自动更新、Otto 审计、版本状态）通常需要十几条命令加人工汇总；技能把这一串固化为一次对话，并自动生成结构化姿态报告。
降低专业门槛：用“您在使用 Mac、Windows PC 还是 Linux？”“这台机器能从公网访问吗？”这类非技术提问替代术语轰炸，让不熟悉安全基线的人也能完成一次合格体检。
风险可控性提升：明确禁止在未确认连接方式时修改远程访问设置，禁止声称 Otto 会改主机防火墙/SSH/系统更新，从规则层面规避了“AI 幻觉式运维”。
长期价值来自持续巡检：一次硬化会随系统更新、新装服务而失效；通过 otto cron 调度 healthcheck:security-audit 与 healthcheck:update-status，把一次性动作变成可追踪的例行公事。
可审计与合规友好：记录网关身份与角色、计划 ID、批准步骤、命令与退出码，并对用户名、主机名、IP、令牌等敏感信息脱敏，便于事后追溯。

7. 常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认生效？

A：在支持技能（Skill）的 AI 客户端中搜索中文名“主机安全健康检查”或英文名 healthcheck 添加安装；若平台采用技能目录管理，则按平台文档放入指定路径。具体入口、命令与路径以官方说明为准。验证方式是发一句“帮我做一次这台运行 Otto 的机器的只读安全健康检查”，若代理先做模型自检、再以一句话请求只读检查授权，说明技能已生效。

Q2：这个技能收费吗？

A：技能详情中未包含定价信息，是否收费、如何计费请以官方说明为准。需要注意的是，运行过程中会调用 AI 模型进行推理，模型侧的费用取决于你使用的客户端与套餐。

Q3：它会不会改坏配置，把我锁在机器外面？

A：从规则设计上风险是被强约束的：未经确认用户连接方式不修改远程访问设置；防火墙规则、开放/关闭端口、SSH/RDP 配置、安装或移除软件包、启用/禁用服务、用户组修改、定时任务、更新策略变更、访问敏感文件或凭证，全部需要明确批准；优先采用可逆的、分阶段的更改并附回滚计划。此外，代理在任何状态变更前都必须先展示计划，出现意外输出会停止并征求指导。

Q4：它和 Lynis、云厂商主机安全中心有什么区别？该选哪个？

A：Lynis 是“体检报告生成器”，擅长诊断但不负责编排硬化执行；云厂商主机安全中心偏集中监控与告警，本机配置改动仍需人工；healthcheck 的差异在于对话式流程编排——体检、风险姿态对齐、计划评审、逐步批准执行、复检报告一体化。如果你已经在用 Otto，优先用 healthcheck；如果是多云或纯合规取证场景，可将 OpenSCAP/CIS 类工具作为补充。

Q5：适合谁用？个人开发者的普通笔记本有必要吗？

A：适合把 Otto 部署在自有机器上的个人开发者、独立运维和小团队，尤其是那些“机器上有凭证和敏感数据、但安全基线说不清”的场景。个人笔记本同样值得做一次基线体检——重点通常落在磁盘加密（FileVault/LUKS/BitLocker）、系统自动安全更新、备份状态和监听端口四项上。若当前角色/身份无法确认，技能会只给出推荐而不执行变更，安全性有兜底。