先看它站在哪里
HelloAGENTS 不是又一个 CLI，而是在 Claude Code、Gemini CLI、Grok Build、Cursor 和 Codex CLI 之上加的一层工作流。它把自己说成「锚定智能体为有能力的执行者」：拦住甩锅、拦住过早停止、把计划从聊天记录搬到磁盘。
README 里那张对照表最能说明它的取舍。没有它时，智能体给出建议就结束；有它时，要继续进入构建、验证和收尾。质量不稳定被归因于「取决于每条提示词」，解法是 14 项质量技能按任务类型自动激活。完成定义模糊被归因于「自然语言说做完了」，解法是交付检查依据状态、证据和验证。
它要解决的问题不算新奇，取舍却很明确——用一层规则和文件，换掉命令行里那些不可复核的口头承诺。
一条真实链路：从澄清到提交
假设要在一个既有仓库里加 JWT 登录。我不直接写一句提示词，而是走它的 ~ 命令链路。
第一步是 ~ask。它是交互式澄清，通过问答锁定目标、方向、范围和约束，而且不写文件。这一步的产物是共识，不是代码。对「加登录」这种需求，先问清是会话 cookie 还是无状态 token、要不要刷新令牌，比直接开写省事得多。
第二步是 ~plan。它会产出需求、方案设计、任务拆解和计划包。计划包不是聊天里的一段话，而是落到磁盘上的一组文件：requirements.md、plan.md、tasks.md、contract.json。其中 contract.json 决定 qaMode、qaFocus、可选的 advisor 检查，以及可选的可视化验证。
第三步是 ~build，按当前请求或已有计划实现，并跑本地检查。
第四步是 ~qa。这是统一质量循环：审查、验证命令、修复、收尾。它的价值在于不把「测试通过」和「任务完成」当成一回事——交付还可能要求计划覆盖、任务清单状态、评审证据、顾问证据和视觉证据。
第五步是 ~commit，生成 conventional commit 信息，并同步项目知识。
这条链路还有个偷懒入口：~auto 会选择主路径并持续推进，直到交付或遇到真正的阻塞。没耐心分五步时，它就是那条自动流。
.helloagents/ 里到底存了什么
真正让我觉得这套设计有分量的，是它把上下文落到了磁盘。~init 在仓库内初始化项目工作流，写入项目级载体标记，准备项目状态，创建或更新知识库。
.helloagents/ 下常见的载体包括：context.md（项目概览、技术栈、架构、模块索引）、guidelines.md（从仓库推断出的非显而易见编码约定）、verify.yaml（lint、test、build 等验证命令）、CHANGELOG.md、DESIGN.md，以及 modules/ 下的模块笔记、plans/ 下的进行中计划包和 archive/ 下的归档。
验证命令的检测顺序也有讲究：先看逻辑上的 .helloagents/verify.yaml，再看 package.json 这类包管理器脚本，最后才是自动检测。
这里有个容易被忽略的开关：project_store_mode。默认是 local，知识就放在项目里。改成 repo-shared 后，本地 .helloagents/ 只保留项目本地状态和运行时文件，稳定的知识文件和计划文件会移到 ~/.helloagents/projects/<repo-key>/。好处是同一个 git 仓库的多个工作树可以共享同一份稳定知识——多 worktree 并行开发时，这一点比想象中重要。
需要说明的是，运行时状态仍然留在当前工作项目里：state_path、sessions/active.json、runtime.json 和 artifacts/*.json 都不跟着走。状态与知识被刻意分开了。
视觉证据与交付门禁
UI 项目上这个设计更直观。所有 UI 工作先遵循共享的 UI 质量基线；在宿主全局模式、已初始化项目或显式 UI 工作流中，hello-ui 会在基线之上追加设计契约执行、设计系统映射和视觉验证。
需要视觉证据时，它会记录到当前会话的 artifacts/visual.json。配合 contract.json 里的 ui.visualValidation.required，视觉验证就成了交付的硬条件，而不是一句「我看着没问题」。更重的 UI 工作还可以要求 ui.styleAdvisor.required，用 artifacts/advisor.json 收口。
这套「证据落盘」的思路贯穿它的所有交付环节。运行时状态刻意保持精简：STATE.md 只留人类可读的恢复快照，runtime.json 只给机器用，artifacts/*.json 只限于结构化回执，events.jsonl 仍是可选且默认关闭。标准运行时证据和临时运行时状态 72 小时后过期；长时运行的 Codex goal 流程在工作流明确需要时，仍保留 720 小时的上限。
它的取舍，以及你要付的代价
这套东西不是没有成本。安装前必须先看清几件事。
详情页安全扫描标了 🔴 高危，共 21 处证据，且尚无人工评估。判定依据是「静态扫描发现安装期即执行代码，或命令参数由运行时变量拼接，参数来源无法静态判定，从严处理」，能力项包括命令参数由运行时变量拼接、读写/删除本地文件。这不是说它一定有问题，而是说它需要你自己评估后再决定。
周下载量只有 85（npm 全网口径，含 CI、镜像与爬虫，不代表装机数）。最近一次提交在 27 天前，算活跃。许可证是代码 Apache-2.0、文档 CC BY 4.0。
版本谱系也不要记错：v2.x 的旧 Python 分支已归档到 helloagents-archive，v3 是完全重写的版本，基于 Node.js + Markdown 规则 + 技能 + 少量运行时脚本。当前 npm 包是 helloagents@4.0.3，Node 引擎要求 >=18。它只覆盖五个宿主 CLI，docs/ 也可能落后于实现——运行时行为由源码、规则模板、技能、模板与测试定义。global 模式还会写入多个 CLI 的宿主配置。
总结
HelloAGENTS 的取舍是拿一层可复核的规则文件，换掉命令行里的口语承诺；想对照同类插件的中文清单与安装形态，见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：需要把需求澄清、计划、实现、质检、提交串成可复核链路的多步项目；用多个 worktree 并行开发、希望共享同一份项目知识的仓库；UI 交付需要视觉证据留痕的项目；已经在用 Claude Code / Codex 等宿主、想要更严格交付门禁的人。
不适合：只是偶尔问一句代码怎么写的轻度使用者，装它等于给简单任务额外加一层开销；无法接受安装期执行代码与运行时拼接命令参数风险、又不愿意先读扫描证据的人；需要覆盖这五个宿主以外 CLI 的场景。
标签：HelloAGENTS、DeepSeek Harness、AI 编程工作流、应用实践
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。