AI 终端助手的设计哲学

过去一年，终端 AI 编程助手领域爆发式增长。iFlow CLI 积累了 5000+ Star 后宣布关停，Claude Code 成为主流选择，Hermes Agent 探索本地化路线。三款工具走了截然不同的路，但它们的架构设计中有一些共通的智慧。

本文不是使用教程，而是提炼这些工具背后的设计思路——哪些决策被证明有效，哪些模式值得在自己的工具和系统设计中复用。

---

一、权限分级：信任不是二元的

现状

多数 CLI 工具对权限的处理是"全给"或"全不给"。用户要么 sudo 一把梭，要么束手束脚。

iFlow CLI 的做法

yolo 模式      → 最大权限，自动执行所有操作
接受编辑模式   → 仅允许文件修改，其他操作需确认
计划模式       → 先出计划再执行，关键决策需确认
默认模式       → 所有操作均需用户确认

四种模式对应四种场景：

模式	适用场景	风险
yolo	信任度高的重复任务	高
接受编辑	日常编码、重构	中
计划模式	架构决策、跨文件改动	低
默认	探索性工作	最低

Claude Code 的做法

通过 permissions 配置实现更细粒度的控制：

{
  "permissions": {
    "allow": ["Bash(git diff *)", "Bash(pnpm test)"],
    "defaultMode": "acceptEdits"
  }
}

可以精确到具体命令，而不是笼统的分类。这种"白名单 + 默认模式"的组合比简单的模式切换更安全。

设计启示

权限设计的关键不是分多少级，而是粒度可控。

好的权限系统应该同时支持：

• 模式切换（快速适配不同场景）
• 白名单（对高频安全操作免确认）
• 命令级粒度（不是整类放行，而是精确到参数）

---

二、Context Window：把压缩变成系统能力

关键认知

AI 编程助手的核心瓶颈不是模型能力，而是上下文窗口。一次复杂任务可能涉及几十个文件，数千行代码，远超窗口上限。

iFlow CLI 的做法

当上下文达到 70% 时触发自动压缩
↓
提取关键信息（任务目标、已完成步骤、当前状态）
↓
压缩为摘要，释放空间
↓
继续执行

这个机制让它在只有 128K 窗口的情况下也能完成跨文件的复杂任务。

Claude Code 的做法

压缩引擎 + 关键信息保护
  ↓
压缩阈值可配（threshold: 0.5, target_ratio: 0.2）
  ↓
保护最近 N 轮对话不被压缩（protect_last_n: 20）

关键设计细节：不压缩最近的对话。因为最近几轮包含当前任务的核心上下文，压缩它们等于让 AI 失忆。

同时通过 TodoWrite 工具让 AI 主动记录进度——即使上下文被压缩，任务进度也不会丢失。

设计启示

上下文压缩的核心不是"存更多"，而是知道什么该忘、什么该留。

一个好的压缩策略至少考虑：

1. 时序权重 — 越近的内容越重要
2. 任务锚点 — 当前目标不能丢
3. 结构化进度 — 用 TodoWrite 等机制在压缩前固化状态

---

三、工具生态：开放市场 vs 内置全家桶

三种路线

工具	策略	表现
iFlow CLI	开放市场 + MCP	一键安装 SubAgent、MCP、自定义指令
Claude Code	Agent + Skill + MCP	内置丰富的 Agent 类型，Skill 可扩展
Hermes Agent	内置全家桶	29 个工具全部自带，无需外部安装

分析

开放市场（iFlow CLI） 的思路最贴近 App Store——降低扩展门槛，让生态自己生长。问题在于需要足够大的社区才能形成正循环。

Agent + Skill（Claude Code） 的思路更务实——内置高质量的基础能力（planner、code-reviewer、tdd-guide），同时通过 MCP 和 Skill 体系保持可扩展性。这避免了开放市场"质量参差不齐"的问题。

内置全家桶（Hermes Agent） 适合个人定制场景——所有工具自己掌控，不依赖任何外部服务。缺点是维护成本全部自己承担。

设计启示

分层扩展是更好的模式：核心能力内置保证质量底线，扩展接口（MCP/Skill）保证灵活性。

理想的架构应该是：

┌─────────────────────────┐
│  自定义 Skill / MCP      │  ← 用户自由扩展
├─────────────────────────┤
│  官方 Skill 库           │  ← 社区贡献 + 审核
├─────────────────────────┤
│  内置 Agent（plan/cr/tdd）│  ← 开箱即用
├─────────────────────────┤
│  CLI 核心（tools/session）│  ← 不可变基础
└─────────────────────────┘

---

四、人机交互：性格化 vs 工具化

有趣的发现

Hermes Agent 内置了 12 种人格：

helpful    → 友好助手
technical  → 技术专家
concise    → 简短精炼
kawaii     → 可爱卖萌
catgirl    → 猫娘风格
pirate     → 海盗风格
noir       → 黑色电影风
shakespeare → 莎士比亚风

这不是噱头。不同的任务场景需要不同的交互风格：

• 生产环境排错 → 需要 concise，一个多余的字都不要
• 学习新技术 → 需要 teacher，耐心解释
• 长时间的重复工作 → 需要一点个性，缓解疲劳
• 正式报告 → 需要 technical，保持专业

Claude Code 的做法

通过 System Prompt 中的 language、规则文件、AGENTS.md 来影响交互风格，但不支持运行时切换。

设计启示

AI 助手的交互风格应该和工作场景匹配，而不是一成不变。

好的设计应该允许用户在任务级别切换交互模式，就像 IDE 可以按文件类型切换配色方案一样。

---

五、Hook 系统：把"每次都要做的事"自动化

三层 Hook 模型

Claude Code 的 Hook 体系是最成熟的参考：

PreToolUse  → 工具调用前（拦截、校验、提醒）
PostToolUse → 工具调用后（格式化、状态更新、日志）
Stop        → 会话结束时（清理、格式化、提测）

实际应用价值

Hook 时机	实际用途
PreToolUse	拦截 npm run dev 在裸终端执行，强制进 tmux
PreToolUse	检测到 rm -rf 时二次确认
PostToolUse	每次编辑后自动 git status
PostToolUse	每次编辑后自动格式化
Stop	会话结束前检查 console.log 残留

设计启示

Hook 的本质是把团队规范编码为自动化检查，而不是靠人记。

一个好的 Hook 系统应该：

1. 支持正则匹配（精确拦截特定命令）
2. 支持链式执行（一个触发可以跑多个检查）
3. fail-open vs fail-close 可选（安全检查 fail-close，提示类 fail-open）

---

六、会话管理：状态不该丢了

iFlow CLI 的独特设计

--resume 恢复上次会话
/chat 查看历史对话

它把"恢复上下文"做成了核心流程的一环。断网、关终端、换机器都不会丢失进度。

Claude Code 的做法

通过 Memory 系统持久化用户偏好、项目上下文，但会话本身不跨进程。

设计启示

将 Memory（长期记忆） 和 Session（短期会话） 分开管理：

Memory（持久化，跨会话）
├── 用户偏好、角色信息
├── 项目背景、架构决策
└── 反馈历史（什么做法有效）

Session（临时，单次会话）
├── 当前任务上下文
├── Todo 进度
└── 中间产物

关停并不可怕，可怕的是好的思路没被记录下来。iFlow CLI 虽然关了，但它的权限分级、自动压缩、开放市场这些设计思路，值得沉淀到下一批工具中去。

---

总结

设计领域	核心原则
权限	模式切换 + 白名单 + 命令级粒度
上下文	时序权重 + 任务锚点 + 结构化进度
生态	分层扩展：核心内置 → 官方库 → 自定义
交互	按场景匹配风格，不是固定人格
自动化	Hook 把规范编码为检查，不是靠人记
状态	Memory 长期 + Session 短期，分而治之

这些模式不仅在 AI 终端工具中成立，在做任何需要"人机协作"的系统时都站得住脚。