多 Agent——AI 怎么'协作' · 第 06 章

Hidden Agent

用户看不见的'系统级 AI'

约 4500 字读完约 23 分钟craft：B+发布于 2026-06-21

一、原理：title / summary / compaction 这种系统级任务

5.3 章我们讲过——主 agent 派生的 subagent 是"专家咨询"。主 agent 知道这些 subagent 存在、知道自己派生了什么 task、最后收到结果整合。

但 opencode 里还有第三类 agent——用户和主 agent 都不知道存在。它们叫 hidden agent——"系统级 AI"。

我们在 2.5 章简要提过 hidden agent。这一章深入看它们的设计。

opencode 有 3 个 hidden agent：

Title agent——给 session 起标题
Summary agent——给 session 写摘要（不调 LLM，是 diff 算法）
Compaction agent——压缩 session 历史

这 3 个 agent 的共同特征：

特征 1：用户没主动触发

用户不会说"AI 帮我起个标题"——title agent 是 opencode 自己决定要跑的。

用户也不会说"帮我压缩历史"——compaction agent 是系统检测到 context 满了自动启动。

这些都是系统驱动的任务——不是用户驱动。

特征 2：主 agent 不知道它们存在

主 agent（用户在对话的那个 LLM）的 context 里没有 hidden agent 的信息。主 agent 不知道有 title agent 在 background 跑、不知道 compaction agent 刚刚处理了它的历史。

这种"完全隐藏"跟 5.5 章的 background 子 agent 不同——background 子 agent 是主 agent 主动派生的（用 task 工具）、主 agent 知道它存在、最后收到通知。

hidden agent 是系统派生的——主 agent 完全无感知。

特征 3：用户感知不到细节

用户能看到 hidden agent 的输出——session 列表里的标题、session 概要里的 summary——但看不到它们的过程。

用户不知道："title 是谁生成的、什么时候生成的、调用了哪个 LLM、消耗了多少 token"。这些都是系统内部的。

特征 4：跑得快、跑得便宜

hidden agent 做的事都不复杂——起标题（一句话）、写摘要（diff 算法）、压缩历史（结构化 LLM 调用）。它们用 small model、short prompt——成本低、速度快。

特征 5：失败不影响主任务

title agent 失败——session 没标题，但工作还能继续。

summary agent 失败——session 没摘要，但工作还能继续。

compaction agent 失败——可能触发更激进的 fallback（剥离图片、回放历史），但 session 还能继续。

hidden agent 是辅助——失败 graceful degradation，不让主任务崩。

这 5 个特征加起来——hidden agent 是产品 UX 的隐性优化。它们让产品体验更顺畅，但用户从未明确感知到它们存在。

我们看 opencode 怎么实现。

二、案例：opencode 的 3 个 hidden agent 配置

R5-B / R8-02 阶段的研究告诉我们——opencode 在 packages/opencode/src/agent/agent.ts 里定义 7 种 native agent，其中 3 个标记为 hidden: true：

{
  name: "title",
  description: "Generate a session title",
  hidden: true,
  prompt: TITLE_PROMPT,
  permission: { /* 不调工具 */ },
  temperature: 0.5,
}

{
  name: "summary",
  description: "Generate session summary",
  hidden: true,
  // 注意：不调 LLM，是 diff 算法
}

{
  name: "compaction",
  description: "Compact session history",
  hidden: true,
  prompt: COMPACTION_PROMPT,
  permission: { "*": "deny" },  // 全部拒绝——不能调任何工具
}

我们一个个看。

Hidden Agent 1：Title Agent

用途：给每个 session 起标题。

何时跑：session 创建后、第一个完整 turn 之后。

prompt：title.txt（R8-02 阶段读过）。核心约束：

"≤50 characters"
"single line"
"use same language as user message"
"no explanations"
"Never include tool names"
"preserve exact: technical terms, numbers, filenames"

这些约束让 title 输出可控——短、不啰嗦、保留关键信息。

temperature = 0.5——比常规 LLM 调用低（默认 1.0），让输出更稳定。title 不需要 creative——需要 reliable。

权限：不调工具——只是单次 LLM 调用，prompt + completion。

UI：title 出现在 session 列表里。用户点 session 列表能看到所有 session 的标题。

Hidden Agent 2：Summary Agent

用途：给 session 生成摘要——主要是"做了什么文件改动"。

何时跑：第一个 turn 完成后（如果有文件改动）。

实现：不调 LLM——直接用 git diff 算法算前后 snapshot 的文件变化。

返回结构化数据：

{
  files: [
    { path: "src/auth.ts", additions: 12, deletions: 3, status: "modified" },
    { path: "test/auth.test.ts", additions: 25, deletions: 0, status: "added" }
  ]
}

为什么不用 LLM？因为"summarize file changes" 本质是 git 能做的事——git diff 就是答案。让 LLM 写一段自由文本摘要——慢、贵、可能错（漏文件、写错行数）。

让算法做——快、准、结构化。

这是个**"不是所有 AI 任务都需要 LLM"**的经典案例（2.5 章详细讲过）。

Hidden Agent 3：Compaction Agent

用途：把长 session 历史压缩成 anchored summary。

何时跑：检测到 context 接近 limit、PRUNE_MINIMUM 满足时。

prompt：compaction.txt（4.5 章读过）。核心是"anchored summary"——基于上次 summary 增量更新。

权限：{ "*": "deny" }——全部拒绝！compaction agent 不能调任何工具。

为什么？因为 compaction agent 的工作是"读历史写摘要"——纯文本任务，不需要任何工具。如果有工具权限——可能被 LLM "想用一下"，破坏 compaction 的纯粹性。

把权限设为全 deny——是最小权限原则。compaction agent 只做它该做的事，不会越界。

这是个安全防护设计——不是为了功能（compaction 不需要工具），是为了防止意外（万一 LLM 想调工具，系统拒绝）。

把 3 个 hidden agent 合起来——opencode 的 hidden agent 体系是：

title：给 session "命名"——用 LLM
summary：给 session "概览"——用算法
compaction：管理 context——用 LLM 但工具全 deny

每个 hidden agent 的实现方式都不同——根据任务性质选择最合适的（LLM vs 算法、有工具 vs 无工具）。

三、设计启示：用户不看的 AI 怎么做权限设计

这一章的核心论点：Hidden agent 是产品 UX 的隐性投资——用户感知不到细节但能感知到效果。

如果你做 AI 产品考虑加 hidden agent，下面几条原则有用：

1. 识别"系统级任务"

什么任务该是 hidden agent？

用户不会主动触发
但产品体验需要它
失败不影响主任务

常见的 hidden agent 任务：

起标题 / 摘要
历史压缩
自动分类标签
推荐相关内容
检测异常输入
翻译 / 本地化

2. 评估"该用 LLM 还是算法"

每个 hidden agent 都问——这个任务真的需要 LLM 吗？

如果用算法能做（diff、字符串处理、规则匹配）——用算法。便宜、快、可靠。

如果必须 LLM（理解语义、生成自然语言）——用小模型 + 短 prompt + 低 temperature。

3. 最小权限原则

hidden agent 不需要的工具——明确 deny。

{ "*": "deny" } 是个安全姿态——避免 LLM "越界"。

opencode 的 compaction agent 是这个原则的体现。

4. hidden agent 完全隔离主 agent

hidden agent 的 prompt、context、结果——不进入主 agent 的视野。

主 agent 看到的是 hidden agent 的"产物"（标题、摘要、压缩后的历史），不知道产物是谁产生的。

这种隔离让主 agent 聚焦——不被系统内部细节分心。

5. UI 显示效果不显示过程

用户在 UI 上看到 title——但不看 title 怎么生成的。

不要展示 "title generation in progress…" 这种细节——用户不在乎。

让 hidden agent 像魔术——结果出现就够了，过程不重要。

6. 失败 graceful degradation

hidden agent 失败不能影响主任务。

title 没生成——用 fallback（"New session"）。summary 没生成——不显示。compaction 失败——尝试更激进的 fallback（剥离图片、回放）。

不要 throw exception 让主流程崩。

7. 监控 hidden agent 的成本

hidden agent 跑得勤——每个 session 都跑——成本累积可观。

监控每个 hidden agent 的 average token / call、failure rate。如果某个 hidden agent 成本太高——考虑是不是该用算法替代。

8. 让用户能"看到"hidden agent 的痕迹

hidden agent 隐藏过程但不应该隐藏结果。让用户能看到：

session 列表里的 title
每个 session 的 summary
压缩历史的标记（如果显式展示）

这是 hidden agent 的"产品价值传递"——用户感受到价值，即使不知道是谁做的。

最后一个观察。Hidden agent 是 AI 产品最被低估的设计模式之一。

很多产品团队把"用户主动调用的 AI 功能"看作产品价值——但实际上 hidden agent 同样重要。一个 session 列表里有清晰标题——是 hidden agent 在跑。一个 session 概览有简洁摘要——是 hidden agent 在跑。一个长 session 还能继续工作——是 compaction agent 在跑。

这些用户感知不到但影响体验的细节，是产品丝滑感的来源。把 hidden agent 做好——产品体验明显提升。做不好——产品功能"看似齐全"但"用起来不顺手"。

opencode 的 3 个 hidden agent 是这种隐性优化的体现。每个都不复杂——但每个都精心设计（用什么实现、什么时机跑、什么权限）。这种精心是产品质量的真实来源。

下一章 5.7 我们看 session 级别的"分叉"——fork 让一段对话能"分出多条路径"探索不同方向。

← 上一章

Foreground vs Background

Session Fork