用 Claude Code、Codex 这类 CLI 编程代理的人，很快会撞到下一层问题：单机单会话没问题，团队协作一团乱。谁在跑哪个 Agent？这个 bug 修到哪了？三个任务想并行，开三个终端窗口手动盯？Agent 的执行经验散落在每个人本地，团队攒不下资产。

HiFox（官网自称「多人与多 Agent 的协作空间」）就是解这一层的。先把定位说透，因为它最容易被误解：

HiFox 不是新的聊天 Agent，也不替代 Claude Code、Codex、Cursor。 你仍然用自己熟悉的 Agent 干活；HiFox 站在团队层面，负责任务指派、进度追踪、上下文共享和流程自动化。

一句话：Agent 负责执行，HiFox 负责让 Agent 像团队成员一样参与交付。 我在自己的机器上把它当日常面板用了一阵，这篇把产品逻辑、上手路径和进阶玩法一次讲完。

一、核心模型：四块积木

1. 组织与任务看板。 一个 HiFox 组织就是一块人和 Agent 共用的看板：需求、缺陷、支持任务、史诗、迭代、评审、评论、分流——传统研发管理的全套词汇。关键差异只有一个：处理人字段可以填 Agent。填了之后，任务的上下文、执行进展、阻塞和结果回传，全部集中在任务时间线上，团队不用在工具之间来回追问。

2. Computer（执行机器）。 把你的本机（或云主机）注册进组织，本机跑一个守护进程，机器就成为可被指派的执行资源。认证走独立的机器会话（machineSession），配置落在 ~/.hifox/config.yml——机器身份和人的账号是分开的，这个设计对权限审计很友好。

3. Runtime（ACP 运行时）。 这是技术上最有意思的部分：HiFox 通过 ACP（Agent Client Protocol） 适配器驱动你本机已有的 CLI Agent。我这台机器的 ~/.hifox/managed-runtimes/ 下装着三个适配器：claude-agent-acp、codex-acp、zcode-acp。官网列出的支持名单超过 20 个：OpenCode、Gemini CLI、Kimi CLI、Qwen Code、Cursor Agent、Kiro、Goose、Copilot CLI、Cline……只要你的 Agent 支持 CLI 方式使用，大概率接得进来。

4. 并行与隔离。 多个任务同时推进时，每个 Agent 在独立 git worktree 里执行——代码变更互不干扰，不会出现两个 Agent 改同一个文件的惨案。产出统一回到收件箱，人审核后再决定合并。

还有一个对国内团队很实际的点：计费模型。HiFox 产品本身免费，Token 消耗直接走你已有 Agent 工具里的 Coding Plan 或 API Key——它不经手你的模型账单，只做调度。

二、上手教程：从零到第一个 Agent 任务

第 1 步：注册组织、连接机器

到 app.hifox.com 注册组织（SaaS 版不限团队人数），然后在要当「执行机」的电脑上安装 CLI 并登录：

hifox login          # 认证
hifox computer list  # 看组织里的机器
hifox computer status # 本机守护进程状态

本机守护进程起来后，config.yml 里会出现 machine profile，机器就挂到组织名下了。

第 2 步：创建 Agent

在 Web 界面为不同场景配置不同 Agent：Bug 修复、需求拆解、测试补齐、代码整理……每个 Agent 绑定一个 Runtime（比如 claude-agent-acp）、一段角色说明（能做什么、如何汇报），以及可选的技能和连接器。

第 3 步：指派任务

把某个任务的处理人设成 Agent。就这么简单——剩下的它会自己认领：拉起会话、在 worktree 里干活、遇到阻塞把问题写回任务时间线、完成后回传代码变更。

第 4 步：跟踪与合并

进度、阻塞、结果都在任务时间线里，像看同事的进展一样看 Agent 的。代码变更审核通过后再合并进主分支。

安装后建议跑一遍 hifox tldr——这是藏得最深的好功能：固定场景速查，每条场景直接给可复制的命令（agent-overview、automation-trigger、daemon-health……），比翻文档快得多。

三、进阶玩法

自动化：让流程自己转

站会、周报、缺陷分流、状态同步、需求补全——这些高频动作交给自动化触发器：

# 任务进入某个状态时自动触发一条自动化
hifox automation trigger create auto_123 \
  --kind task_event --to-status "In Review" \
  --label "Review handoff" --output json

hifox automation runs auto_123 --output json   # 看触发历史

支持的触发源有定时、任务状态变更、评论事件三类。组合起来就是：每天早上 9 点自动生成站会摘要、新缺陷自动分流补全上下文、任务转评审时自动通知人接手。

连接器市场：给 Agent 装上外部世界

Agent 光会写代码不够，得能摸到公司的其他系统。HiFox 的连接器市场（~/.hifox/connectors-marketplace/）装了一大票现成连接器——我本机数了数，90 个：飞书、高德/百度地图、Apifox、百度网盘、滴滴、携程问答、东方财富、法律数据库、企业 EMR 查询……装上之后，Agent 就能在任务执行里直接调这些工具。

技能市场：把 Prompt 和经验沉淀成资产

技能（Skill）可以在不同 Agent 间安装、发布和分享，装在 ~/.hifox/skill-market/ 下。团队里某个人调教好的「代码评审清单」或「发布前检查」，打包成技能共享出去，别人的 Agent 也能用——这是把个人经验变成团队能力的通道。

与 Jira / TAPD / 云效双向同步

不用迁移工具链：HiFox 可与 Jira、TAPD、PingCode、Teambition、禅道、Linear、云效、ONES、GitHub/GitLab issue 等同步。团队继续用原来的系统，Agent 执行能力从旁边接进去。以官方文档最全的 TAPD 为例，同步的通用套路是四件事：

1. 选凭证。两种模式：平台级 API 账号（TAPD 需付费版，支持双向实时同步）或个人访问令牌（免费版可用，仅 HiFox → 平台单向同步）。绑定页会用黄字写清这个差异，别跳过。
2. 跑五步向导：配置（绑定项目、目标 Space、同步方向，默认双向）→ 映射状态 → 映射用户 → 导入选项 → 确认。核心是概念对照——外部系统的对象落到 HiFox 的哪一层：以 Jira 为例，project 绑定到 Space，Epic 成为「专项」，Sprint 成为「迭代」，其余 issue 全部成为「任务」，Issue Type 匹配或创建「任务类型」。名称相似不代表含义相同，配映射前务必过一遍官方概念对照表。
3. 配 Webhook。建立连接时 HiFox 会自动生成回调地址和密钥，把它们填到对方平台；收到过一次回调即视为配置成功，没收到时同步列表下方会出现黄色提示条引导你重配。
4. 导入 ≠ 同步，两件事分开做。同步只保持「之后」的变更一致，历史数据要单独发起一次历史导入（可加字段筛选、可断点续跑，默认跳过已识别的来源任务，不会重复创建）。持续同步还有一条很贴心的保护：对方平台没改动的字段，不会覆盖你在 HiFox 里的本地修改。

那云效呢？ 官网同步名单里确实列着云效，但截至本文发稿，官方文档（docs.hifox.com）的「导入与集成」目录还没有云效专页——已文档化的项目管理集成是 Jira（含 Jira 兼容 API）、TAPD、禅道、PingCode、Teambition。云效团队眼下有三条务实路径：

• CSV/Excel 桥接（现在就能用）：云效支持把工作项导出为 CSV，HiFox 的导入向导支持按字段映射导入文件——先把需求/缺陷批量搬进目标 Space，Agent 立刻可接活；
• 盯更新日志：官网已把云效列进同步名单，大概率在路线图上，docs.hifox.com/changelog 上线即用——届时照搬 TAPD 的四步套路即可（凭证→向导→Webhook→历史导入）；
• 先在姊妹平台试跑：如果团队同时有 TAPD/禅道/PingCode 项目，可以先用它们把「外部账号承接、状态映射、分拣台」这套同步机制跑顺，经验整体平移。

另外两个同步后才会遇到的细节，提前知道少走弯路：目标 Space 若开启了「分拣台」，同步新建的条目会先进待分拣队列而不是直接上看板；遇到无法对应到组织成员的外部用户，HiFox 会自动创建「外部账号」承接（保留来源身份、可当处理人显示，但不占名额、不能登录）。

CLI 脚本化：一切皆 JSON

hifox CLI 的几乎所有命令都支持 --output json，命令注册表还能用 hifox schema --format json 整体导出。这意味着你可以把 HiFox 嵌进自己的脚本：CI 里查询任务状态、用 cron 拉执行报表、甚至再做一层自己的调度。两个值得知道的会话参数（~/.hifox/config.yml）：acpSessionIdleTtlSeconds: 600（会话空闲 10 分钟回收）、acpSessionMaxAgeSeconds: 7200（最长 2 小时），长任务场景可以按需调大。

四、适合谁，不适合谁

适合：已经在用 AI 编程工具、想把 Agent 纳入日常研发流程的团队；需要多 Agent 并行产出、又怕互相踩脚的场景；想把 Agent 执行经验沉淀成团队资产的组织。个人开发者也用得起——SaaS 免费且不限人数，一台机器一块看板，就是「给所有 CLI Agent 一个统一驾驶舱」。

不适合：完全没用过 AI 编程工具的团队（先解决「会用」再解决「协作」）；任务边界模糊、上下文说不清的工作——这种任务交给 Agent，人或 Agent 都会痛苦。

写在最后

参考：hifox.com 官网（FAQ 与功能页）· CLI 命令与目录结构为本机实测 · 架构图为本刊自绘。

AI 编程的下半场，比的不是谁的模型强，而是编排：任务怎么分、上下文怎么传、结果怎么合。HiFox 选的切口——不造新 Agent、复用你的额度、挂在已有工具链旁边——是聪明且克制的工程判断。如果「管理一堆并行 Agent」正是你的痛点，它值得一个下午的试用。