这份公开页面用于说明 Your AI Memory / HCK、原生 Hermes Agent 与 Claude Tag 类产品的定位差异：一个是个人 AI 记忆与上下文治理层，一个是 Agent runtime 底座，一个是共享工作流里的虚拟同事。
HCK 的核心定位，是套在 Hermes Agent 之上的个人 Context 全生命周期治理层。
它借助 Hermes Agent 的 Agentic Loop、模型和工具执行能力，治理用户 Context 的学习、召回、验证、升迁与回滚，让 Hermes 成为更懂用户、可自学习、可验证的贴身助理。
Claude Tag 更接近组织共享工作流里的虚拟同事；HCK + Hermes Agent 更接近人类员工身边的个人工作助理。
这张图按“上层产品能力、下层 runtime 底座”来读。框体宽度用于表达能力覆盖范围：HCK + Hermes Agent 的上层能力更厚，原生 Hermes Agent 更接近基础产品形态，Claude Tag 则建立在 Anthropic 托管的 Claude runtime 之上。
在 Hermes runtime 之上提供个人 Context 治理、默认能力和贴身助理体验。
Morning Briefing、低打扰确认、默认 profile、通用 skills、用户风格与 know why。
Source contract、scope safety、candidate、eval、promotion、recall、rollback。
基础产品形态，重点是让 Agent 跑起来。
CLI、TUI、Dashboard、Gateway、Profile、Skill 创建。
profile memory、/learn、runtime trace。
Agentic Loop、模型路由、tools、skills、cron、gateway、session、profile memory、/learn。它同时支撑 HCK + Hermes Agent 和原生 Hermes Agent。
Hermes runtime substrate共享工作流里的虚拟同事，面向团队频道和线程协作。
频道、线程、团队可见协作、routines、watchers。
channel access、service identity、audit、共享记忆和团队权限。
长期运行的 Claude / Claude Code 能力底座，包含模型、sandbox、connected tools 和共享工作流执行环境。
Anthropic hosted runtime substrate矩阵按四个大维度读：Runtime 层只做基础能力对齐；真正的差异主要落在 Context 全生命周期管理、Personal 易用性和能力增强。绿色表示该形态的优势，黄色表示部分具备或需要补强，灰色表示不是主定位或缺原生能力。
| 综合维度 | 细项 | HCK + Hermes Agent | Hermes Agent | Claude Tag |
|---|---|---|---|---|
| Runtime 层 | Agentic Loop | 继承使用 Hermes 的会话、推理、工具调用、profile、skills。 | 有核心 runtime 能力。 | 有Claude 产品内置工作循环。 |
| 模型层 | 有沿用 Hermes 模型/provider，HCK 只记录 route/version 作为证据。 | 有可配置模型/provider。 | 有Anthropic 托管的 Claude 模型体验。 | |
| 工具/外部动作 | 继承 + 治理Hermes 执行动作，HCK 补授权、风险、证据和追溯。 | 有通过 tools/gateway 执行真实动作。 | 有在 channel access 范围内执行。 | |
| 通道/调度入口 | 复用使用 Hermes gateway、cron、skills，再加治理和可靠性约束。 | 有基础可接 gateway/cron，但语义闭环靠实现补齐。 | 有Slack routines/watchers 是产品能力。 | |
| Context 全生命周期管理 | Context 捕获 | 核心把 IM、邮件、日程、待办、文档、session、trace 变成 evidence。 | 有基础会话和 runtime 中有上下文，但缺统一来源契约。 | 有捕获 Slack channel/thread context。 |
| Source Eligibility | 核心每类 source 声明 trust、privacy、scope、idempotency，先判断能不能学。 | 缺原生治理缺少系统化“什么能学/不能学”的准入。 | 有边界按频道权限和产品策略处理，不是用户本地通用 contract。 | |
| Evidence / Provenance | 核心候选带 source hash、content hash、route/version、rollback pointer。 | 有痕迹runtime trace 存在，但不等同可晋升证据包。 | 产品内有 audit / thread 可见性，但不是可替换治理层。 | |
| Scope Safety | 核心区分 user、profile、DM、channel、thread、project、workspace、org。 | 依赖实现profile/channel 可区分，但容易靠配置约定。 | 强项channel/thread/workspace scope 是产品核心。 | |
| Candidate Ledger | 核心学习先成为 candidate，再去重、冲突标记、验证、升迁。 | 缺原生主线learn 结果不天然进入候选状态机。 | 平台内相关能力由产品侧管理，用户侧不可直接治理。 | |
| Recall Evals | 核心用真实 session/caseset replay 验证“学了下次是否更好”。 | 缺原生闭环不能系统证明召回有效。 | 产品内用户看不到完整 recall eval/promotion 链路。 | |
| Promotion / Rollback | 核心proposal-only、manual/on-demand、可回滚，验证通过才生效。 | 有写入但缺完整升迁与回滚治理。 | 产品内由平台管理，不是用户本地可控。 | |
| Personal 易用性 | 服务对象 | 贴身助理服务人类员工，让这个人更懂业务、更少分心、决策更稳。 | Agent 本体提供可运行的个人 Agent，但产品化和治理不足。 | 虚拟同事作为共享频道里的协作主体，服务团队工作流。 |
| Profile / Soul | 治理Profile 成为可维护产品资产，减少不合适规则写入长期行为。 | 有基础profile 是运行配置和人格载体。 | 不同模型以 channel/workspace 记忆和团队上下文为中心。 | |
| 用户本地 Context | 核心work-first、user-owned、profile-local by default。 | profile-local有本地状态，但治理弱。 | 不是定位以 Slack workspace/channel 为中心。 | |
| 低打扰主动服务 | 核心体验Morning Briefing、最小必要确认、先做前置研究再请用户判断。 | 可实现cron 能跑，但交互节制和确认闭环需要规范。 | 有routines/watchers 能主动进入共享工作流。 | |
| 最终用户感知 | 精装房让 Agent 越用越懂用户，形成可靠、自进化、可验证的贴身工作助理。 | 毛坯房让 Agent 跑起来。 | 共享同事让团队能在 Slack 里 @ 虚拟同事处理共享工作。 | |
| 能力增强 | 可靠 IM / Gateway | 增强跨通道 contract、replay/ack/decision evidence、可靠交互闭环。 | 有基础可接消息通道，但可靠性和语义治理靠实现补齐。 | 限定Slack-first，不是通用 IM adapter。 |
| DecisionFrame / 授权 | 核心Policy-as-data；文本/语义只能 warn，不能替代授权证据。 | 可接入需要约束所有 actionable output。 | 有产品授权基于 channel/admin/service identity。 | |
| Skill 自进化 | 治理Meta Skill gate、skill-doctor、case replay、promotion proposal。 | 有 /learn能创建 skill，但缺全生命周期评测。 | 非中心重点不是用户本地 skill 生态。 | |
| 默认能力矩阵 | 产品化预置通用 skills、能力清单、版本巡检和兼容策略，降低用户心智负担。 | 可扩展有 skills 机制，但默认精装能力要另行组织。 | 平台内置能力由 Anthropic 产品定义，不是用户本地可组合能力矩阵。 |