这几个月出现了很多 AI coding agent，也出现了很多围绕 agent 的辅助工具。

  • 有的负责模型路由；
  • 有的负责会话和提示词；
  • 有的负责任务执行和审批；
  • 有的负责 diff、trace、artifact 或成本统计；
  • 还有一些专门去包第三方 agent CLI。

工具一多，问题也会跟着出现：真正难管的往往不是“让 agent 跑起来”，而是“让一整段 agent 工作变得可监督、可回看、可审批、可追责”。

今天想记下的 hecatehq/hecate，就是沿着这个方向在做。它把自己定义成一个 local AI operations console for supervised agent work。和很多强调“替你自动写代码”的项目不同，Hecate 更像一个本地优先的操作面，试图把模型网关、任务运行、外部 agent 监督、项目上下文、记忆、审批和证据链收进同一套界面里。

按 GitHub 仓库页、README 和 releases 页在 2026-06-25 的公开信息，这个仓库当前约有 21 stars、1 fork，主要由 Go 和 TypeScript 构成，仓库创建于 2026-04-20，最近一次公开更新出现在 2026-06-25。项目采用 MIT 许可证，最新预发布版本是 v0.2.0-alpha.4，发布时间为 2026-06-18。

项目概览

属性详情
仓库hecatehq/hecate
定位本地优先的 AI operations console
Stars21
Forks1
主要技术栈Go、TypeScript
创建时间2026-04-20
最近公开更新2026-06-25
LicenseMIT
最新版本v0.2.0-alpha.4
版本状态Pre-release / public alpha
版本日期2026-06-18

它想解决的不是“怎么再造一个 agent”，而是“怎么把 agent 工作收口”

README 对 Hecate 的描述很直接：它运行在你的机器上，位于 AI client、模型提供方、coding agent 和工作区工具之间，让项目工作可以被协调、路由、审批、追踪和复盘。

这个定位很关键。

因为很多同类工具的中心问题仍然是：

  • 怎么把 prompt 发给模型；
  • 怎么调工具；
  • 怎么让 agent 多走几步。

而 Hecate 的问题更偏运维和协作层：

  • 这次任务是直接模型对话，还是带工具的 task run；
  • 谁在调用哪个 provider；
  • 哪一步需要人工批准；
  • 外部 agent CLI 到底改了什么；
  • 某个项目上下文、记忆和 handoff 是否能留档；
  • 这次输出背后的 diff、artifact、trace 和成本在哪里看。

换句话说，Hecate 不是主要去争“谁是最强 coding agent”，而是在做一个 agent work 的监督台。

它最有意思的地方，是把很多原本分散的层压成同一个 operator surface

README 里列出的几条能力线，拼起来其实很完整：

  • Gateway：统一接 OpenAI-compatible Chat Completions、Anthropic 风格消息、模型发现、failover、usage 可见性；
  • Console：浏览器或桌面端操作界面；
  • Runtime：排队任务、agent_loop、审批、artifact、重试与恢复；
  • External Agent supervision：监督外部 coding-agent CLI 的长会话；
  • Project orchestration：项目身份、工作记录、handoff、项目记忆、context packet；
  • Evidence：trace、route report、diff、日志、截图和最终输出。

这比“一个带侧边栏的 chat 应用”更像一个本地运行的调度与审计层。

尤其是它没有把外部 agent 当成黑盒一接了之。README 里明确写了对 Codex、Claude Code、Cursor Agent、Grok Build 这类外部 ACP 会话的监督能力，包括 readiness/version check、prompt-first approval、adapter diagnostics 和 Git diff review。

这个方向很务实。

因为团队真正头疼的，常常不是 agent 会不会调用一个工具，而是：

  • 它是通过哪个 CLI 在跑；
  • CLI 用的是谁的账号和计费；
  • 它的权限是否过大；
  • 它写进工作区的改动是否可以快速 review；
  • 某次失败到底是模型、provider、adapter 还是任务运行时出了问题。

Hecate 试图把这些问题放进统一界面里，而不是把每一层都丢给不同终端窗口。

local-first 的“运营形态”很清楚，但它并不假装自己是完全离线工具

我觉得 README 里有一句话很重要：Hecate 是 local-first in the operational sense。

它的意思不是“只在本地、绝不碰云”，而是：

  • runtime 和 UI 跑在本机；
  • Hecate 自己的状态默认存本地；
  • gateway 默认只绑定 loopback；
  • 但它仍然可以把请求路由到云模型提供方；
  • 也可以监督使用各自账号的外部 agent CLI。

这比很多模糊的“本地优先”说法更诚实。

它没有把“本地”包装成安全万能药，而是把边界说清楚：默认只监听本地回环地址，如果你要向外暴露，就自己加访问控制、反向代理或防火墙。README 和文档也明确提醒，当前的 sandbox policy 不是容器级隔离。

这点反而让我更愿意认真看它。因为真正能落地的工具，通常都会把自己的安全边界讲得没那么好听。

项目、上下文和记忆这条线，是它区别于普通 chat UI 的地方

Hecate 现在的一个重点，不只是“会话”，而是 project-scoped work。

README 里把这部分拆得很细：

  • 项目有稳定的本地身份；
  • 项目可以关联 workspace roots；
  • source metadata、work items、handoff、memory entries 都是项目级对象；
  • 每次调用前会生成 context packet snapshot；
  • memory candidate 需要显式人工提升为正式记忆；
  • 外部 agent 的私有记忆不会自动写回 Hecate。

这套设计说明作者关心的不是单轮提示词，而是 长期、可追踪的项目工作流。

很多 agent 工具到最后都会碰到同一个问题：历史上下文越来越多，但哪些是真正该保留的长期记忆，哪些只是这次任务的临时证据，边界会越来越糊。

Hecate 在这点上至少有明确态度：

  • context packet 是调用证据，不等于长期记忆；
  • 记忆不会自动写入；
  • 记忆提升需要 operator 批准；
  • provenance 要保留。

对于真的想把 agent 拉进团队流程里的人，这比“无限追加上下文”要靠谱得多。

它现在已经能跑，但 alpha 边界也写得很明白

README 没有把项目说成已经稳态完成。相反，它明确标了 public alpha，而且直接点出还在设计或早期 alpha 的部分：

  • workflow runbooks；
  • 更丰富的 agent profiles；
  • browser QA；
  • sandbox hardening。

这很重要，因为 Hecate 想碰的东西天然比较重：

  • 模型网关；
  • 桌面端和 Web 控制台；
  • 任务运行时；
  • 外部 agent 监督；
  • 项目与记忆模型；
  • 审批和证据链；
  • OpenTelemetry 可观测性。

这些模块随便哪一个单独做都不算轻。现在把它们收拢在一起，说明项目方向很有野心，也说明实际使用时必须接受 alpha 期的不稳定性。

从 quick start 看，它已经给了三种路径：

  • 桌面应用；
  • Docker；
  • 从源码启动。

其中 README 明确写到：

  • macOS Apple Silicon 是主要 launch-tested 路径；
  • Linux 和 Windows bundle 目前还是实验性；
  • Docker 反而是 Linux/Windows 上更稳妥的 alpha 方案。

这意味着它已经不是“只给架构图不让你跑”的阶段，但也还没到可以当团队底层基础设施无脑上生产的程度。

最新 alpha.4 说明项目仍在快速收边

最新预发布版本 v0.2.0-alpha.4 是 2026-06-18 发布的。release 页面能看到这版的 changelog 不算夸张，比较核心的一条是修复 UI 里的 provider alias 解析，并同步更新 release 引用。

我会把这看作一个信号：它还处在快速迭代、不断补细节的阶段。

这类项目最怕的是概念很大，但实际可用性长期停在 demo 水平。Hecate 现在更像是在把一个很大的“监督台”概念，持续往真实可操作的软件收。

适合什么人关注

我觉得 Hecate 比较适合这些场景：

  • 你已经不满足于“直接开一个 agent CLI 跑完就算了”；
  • 你希望把模型调用、任务运行、外部 agent、审批和证据放进统一界面；
  • 你在意项目级上下文、handoff 和记忆边界；
  • 你想保留 trace、diff、artifact 和 usage 作为操作证据；
  • 你愿意在 alpha 期试用一个更像操作系统层而不是单点 agent 的工具。

如果你只是想找一个“开箱即用、自动帮我写代码”的极简 agent，Hecate 可能反而显得偏重。

它的边界也要看清

Hecate 不是：

  • 生产级稳定的 agent 基础设施；
  • 容器级安全隔离产品；
  • 只靠一个按钮就能代替现有团队工作流的万能控制台；
  • 单纯更换皮肤的 chat UI。

它更像一个还在成形中的 本地 AI 运维台：把原本分散在模型网关、chat、task runtime、外部 agent、项目上下文和观测链路里的碎片，尽量拉回同一张操作台上。

小结

hecatehq/hecate 现在最值得看的，不是它“又支持了哪个模型”，而是它试图解决一个更难但也更现实的问题：

当团队里开始同时使用模型、工具调用、外部 agent CLI、项目记忆和审批流程时，能不能有一个统一的本地监督面来管理这整段工作。

从 README 透露出来的结构看，Hecate 已经把这件事拆成了几个很清楚的部件：

  • 模型网关；
  • 聊天与任务运行时；
  • 外部 agent 监督；
  • 项目、上下文和记忆模型；
  • 审批、artifact、trace 与 usage 证据链。

它当然还远没到“稳态平台”的程度，但如果你最近也在思考 agent 工具为什么总是越用越分裂、越难审计，那这个仓库值得认真翻一遍。