您本打算给团队再加几个席位。不如先加一位 Hedy——一位受治理约束的 AI 员工，基于您的知识库作答、产出报告、评审代码、准备会议。运行在您自己的基础设施上。不是又一个云端席位，也不是会议记录工具——而是一位真正在岗的员工。
$ docker compose up -d · 支持气隙（离线）运行 · 您的模型 key，您的数据
Hedy 是私有化部署的 AI 员工：一位受治理约束的员工完成整个团队的工作——基于您的知识库带引用作答、产出报告、评审代码、分诊 bug、准备会议——通过 Docker、Kubernetes 部署在您自己的基础设施上，或完全气隙运行。它不是云端助手，也不是会议记录工具；它承担一个岗位、主动开展工作，且每个动作都经过审批门禁并写入只增不改的审计日志。名字本身就说明了定位：您需要的是 hedy.one——一位，就够了。
为云端 AI 员工无法服务的团队而建：数据不能离开内网的场景——受监管行业、安全优先的工程组织，以及日常工作在飞书和 Lark 而非 Slack 的团队。
每位 Hedy 都搭载同一套受治理的核心。岗位画像决定她负责什么、携带哪些工具、权限延伸到哪里。
一位员工可以身兼数职。岗位只是同一核心之上的画像——无需重新招聘即可调换职责，也可以运行多位权限彼此独立的员工。
不是一堆提示词——每项技能都自带硬性规则、工具边界与验收测试。
基于您的知识库回答公司问题——混合检索，按提问者做 ACL 过滤。每条论断都附带来源链接。没有引用，就不作答。
入场前一份 60 秒预读简报；会后一份含负责人与行动项的纪要。决策沉淀进记忆，而不是消散无踪。
日报与周报由脚本和 API 汇编——数字来自命令输出，从不来自想象。
结合项目上下文评审合并请求，将 bug 分诊到嫌疑文件并附置信度。写入走白名单；合并始终由人完成。
定时任务显式声明投递目标，由看门狗进程监督。漏跑会告警——沉默从不被当作成功。
重复出现的工作流会被提炼为新的、带版本的技能——验证优先，经您签核后才启用。您的 Hedy 会不断增值。
up -d 到第一份交付物。在一台 VM 上执行 docker compose up -d，或在 Kubernetes 上使用 Helm。搭配本地模型可气隙运行。
对话走飞书、Lark 或 Slack；知识源接入 Git、Notion、Confluence 与您的 wiki。
席位、审批分级、写入白名单、知识 ACL。默认全部拒绝——每扇门都由您主动打开。
第一分钟起群里就有带引用的回答。报告、评审与简报随后按计划跟上。
谁都能演示一个会行动的 agent。难的是一位可被证明不越界的员工——不泄露、不越权、不自作主张。下面每一条限制都落在代码与配置里。提示词不是安全边界。
Compose 或 Helm，部署在您的 VPC 内或完全气隙运行。源码可供审计。在自部署模式下，数据从不离开您的网络。
每个动作都记录执行者、对象与理由。不存在任何更新或删除路径——管理员也没有。
分级授权（L0–L2）存储在数据库中。对外发布、支出与承诺都要等待人工确认。
仓库写入需要显式白名单。代码变更以 Draft PR 提交；合并是只属于人类的动作。
我们测试 Hedy 绝不能说出口的内容：薪资试探、索要凭证、注入尝试。泄露检查与质量评测跑在同一个评测门里——每次发布之前执行。
检索在服务端按提问者身份做 ACL 过滤。对外服务的员工被硬性限定在公开知识层。
所有模型调用都经过唯一的配额网关——预算、降级策略与按员工计量只有一个真源。
这是产品场景，不是客户证言——全部是已交付的行为，第一天就能演示。
昨天的提交、待处理的审批和今天的日程——由 API 汇编、投递到群里，每个数字都可追溯。
负责人、决策与截止时间被提取并归档到文档空间。行动项变成带提醒的跟踪任务。
Hedy 结合项目上下文在合并请求上留下评审意见——以草稿优先、无法合并的评审者身份。仅限白名单仓库。
检索范围限定在提问者可见的内容之内。回答链接其来源文档；被 ACL 过滤的内容会被声明，绝不泄露。
一周的活动台账——完成的评审、回答的问题、节省的工时——汇编成一份老板真的会读的周报。
行为测试随评测门一同交付：薪资试探、索要凭证与注入尝试都会被拒绝并写入审计。
SaaS agent 要求您把知识库、凭证和聊天记录交到它们的云上。Hedy 押注相反的方向。
| Hedy | 云端 AI 员工 | |
|---|---|---|
| 数据存放在哪里 | 您的 VPC——或气隙环境 | 厂商云 |
| 源码可审计 | 可以，由您的安全团队审计 | 少见 |
| 飞书与 Lark 原生支持 | 一等公民，另支持 Slack | 仅 Slack / Teams |
| 红线行为测试 | 已交付，跑在评测门内 | 未披露 |
| 模型 key 与 token 开销 | 归您所有，本地计量 | 归厂商，含加价 |
| 定价模型 | 按席位固定授权费 | 按用量扣额度 credit |
Hedy 列展示的是自部署 / BYO 模式（自带模型 key），即旗舰部署形态。托管模式下模型流量经 Hedy 网关转发，按用量额度 credit 计费——见下方定价。
在您自己的基础设施上、用您自己的模型 key 运行 Hedy——固定授权费，数据从不离开，没有数据次级处理方（sub-processors）。或者由我们托管模型层，几分钟即可启动，像云服务一样计费。同一位员工、同一套治理；由您决定模型在哪里运行、谁能看到流量。
Self-hosted 自部署 · 您的基础设施 · 您的 key · 数据不离开
Managed 托管 · 模型层由我们托管 · 几分钟即可启动
不想操心基础设施？由我们运行模型网关；您几分钟内即可雇到一位员工，按它实际做的工作付费，像云服务一样计费。适合已经可以接受云端 AI 的团队。
数据驻留等级较低，这是设计使然。在托管模式下，模型流量经过 Hedy 的网关——因此它不是气隙环境，也并非没有数据次级处理方：Hedy 与模型提供商会处理这部分流量。网关存储计量元数据（token 数、费用、模型名、延迟）与您的额度 credit 台账，从不存储提示词或回复内容；知识库、记忆与审计日志保留在您自己的部署中。如果您的数据不能离开内网，请选择上方的自部署。哪一种适合您，我们会直说。
开始使用托管模式为什么按员工计价？为什么模型由您选？一位完成整个团队工作的 AI 员工，不应该干得越多收得越多——在自部署模式下计量表归您所有（按员工计的价格还会随席位增加而下降，Team 档从 $500 降到 $380）。托管模式为速度而存在，不是为了让我们悄悄在您的 token 上加价——而且我们坦白说明：它以数据驻留为代价。多数安全优先的团队从自部署起步；这正是 Hedy 存在的意义。