作者归档：admin

从 Claude Code到 Gemini CLI，AI Agent 的上下文管理策略

发表回复

对于一个与大型语言模型（LLM）打过交道的开发者来说，上下文管理都是一个绕不开的核心问题。它不仅决定了 AI 的智能程度，也直接关系到系统的性能和成本。

上周研究了各家 Agent 系统的实现，各家的上下文管理策略都不相同。最简单最傻的策略是一个不断累加对话历史，这种策略很快就会遇到 Token 限制和 API 的成本问题。

如果你是一个技术负责人，或者正在开发 AI Agent 相关的产品，需要在性能和成本之间找到平衡点，这篇文章应该对你有一些帮助。

今天所聊的内容是基于对 Claude Code、Manus、Gemini CLI，OpenManus 等多个项目的分析，以及自己在实践中的一些思考。

为什么要做上下文管理？

最新的 LLM 现在提供 128K Token 或更多的上下文窗口。听起来还挺多的，但在真实世界的 Agent 场景中，这通常远远不够。

尤其是当 Agent 与网页或PDF等非结构化数据交互时，Token 数需求会爆炸。

并且，随着 Token 数的增加，模型性能会在超过一定长度后明显下降，这就像让一个人同时记住一本书的所有细节，理论上可能，实际上很难做好。

就算我们的大模型有更多的窗口上下文支持，成本也是一个需要考虑的问题，就算有前缀缓存这样的优化，但传输和预填充每个 Token 都是要付费的。

为了解决这些问题，许多团队选择了压缩策略。但过度激进的压缩不可避免地导致信息丢失。

这个问题的本质在于 Agent 必须根据所有先前状态预测下一个动作——而我们无法可靠地预测哪个观察结果可能在十步之后变得至关重要。从逻辑角度看，任何不可逆的压缩都带有风险。

接下来我们看一看各项目的上下文管理策略，看看从中能否给到各位看官一些启发。

OpenManus 的上下文管理策略

OpenManus 采用了一个相对简单直接的上下文管理方案，主要特点是：

轻量级消息列表机制

使用固定长度（默认100条）的消息列表作为内存存储
采用简单的 FIFO（先进先出）策略，超出限制时截断最早的消息
没有智能的上下文压缩或摘要机制

Token 限制处理

实施硬性 token 检查，超限直接抛出异常终止
缺乏优雅的降级策略或自适应窗口裁剪
在长对话或工具密集场景中容易触碰上限

虽然上下文管理比较简单，但是 OpenManus 为不同使用场景提供了定制化的上下文处理，如浏览器场景会动态注入浏览器状态，截图保存等

总的来说，这是一个原型实现，并不适合作为生产级环境使用，如果要上到生产环境需要自行做精细化的处理和架构。

Manus 的上下文管理策略

Manus 没有开源，但是其官方有发一篇文章出来。

Manus 采用了一种创新的方法：将文件系统作为终极上下文存储，而不是依赖传统的内存中上下文管理。

文件系统作为存储有如下的核心特性：

无限容量：文件系统大小不受限制
天然持久化：数据自动保存，不会丢失
直接操作：智能体可以主动读写文件
结构化记忆：不仅是存储，更是结构化的外部记忆系统

相对于传统的将完整的观察结果保存在上下文中，容易超限，Manus 实现了可恢复的信息压缩：

观察结果指向外部文件（Document X, File Y）
上下文中只保留引用，不保存完整内容
需要时可以从文件系统恢复完整信息

具体实现：

网页内容可从上下文移除，只保留 URL
文档内容可省略，只保留文件路径
实现上下文压缩的同时不会永久丢失信息

Manus 团队认为，如果状态空间模型能够掌握基于文件的记忆管理：

将长期状态外部化而非保存在上下文中
SSM 的速度和效率优势可能开启新型智能体
基于 SSM 的智能体可能成为神经图灵机的真正继任者

与 OpenManus 的简单消息列表管理，Manus 的方案更加成熟：

OpenManus：固定长度消息列表，硬性截断，缺乏智能管理
Manus：文件系统作为无限外部记忆，可恢复压缩，主动记忆管理

Claude Code 的上下文管理

Claude Code 没有开源代码，但是国外有大神反编译其源码（虽然大神自己说:这并非真正意义上的反编译或逆向工程尝试，而更像是对 Claude 团队杰出工作的致敬。）

地址：southbridge-research.notion.site/claude-code…

通过反编译内容的分析，可以大概了解一些其策略和比较巧妙的点：

TodoWrite 工具

Claude Code 引入 TodoWrite 工具，支持模型主动维护自己的 To-Do 列表，替代传统的多 Agent 分工策略。

其优势：

专注：Prompt 中反复提醒模型参考 ToDo，始终聚焦目标。
灵活：「交错思考」机制使得 ToDo 可动态增删。
透明：用户可实时查看计划与进度，提高信任度。

Token 统计的反向遍历

Toke 统计从后往前查找这个细节相当精妙。大部分系统都是傻乎乎地从头遍历，但 Claude Code 意识到了一个关键事实：Token 使用情况的统计信息总是出现在最新的 assistant 回复里。这种”知道去哪找”的优化思路，把原本可能的 O(n) 操作优化到了 O(k)，在高频调用场景下，这种优化带来的性能提升是指数级的。

92% 阈值

留 8% 的缓冲区既保证了压缩过程有足够的时间完成，又避免了频繁触发压缩带来的性能开销。更重要的是，这个缓冲区给了系统一个”反悔”的机会——如果压缩质量不达标，还有空间执行降级策略。

8 段式结构化摘要

Claude Code 的 8 段式结构特别值得借鉴：

markdown

体验AI代码助手
代码解读
复制代码


1. Primary Request and Intent - 主要请求和意图

2. Key Technical Concepts - 关键技术概念

3. Files and Code Sections - 文件和代码片段

4. Errors and Fixes - 错误和修复

5. Problem Solving - 问题解决过程

6. All User Messages - 所有用户消息

7. Pending Tasks - 待处理任务

8. Current Work - 当前工作状态

优雅降级

当压缩失败时，系统不会死板地报错或者强行应用低质量的压缩结果，而是有一整套 Plan B、Plan C。从自适应重压缩，到混合模式保留，再到最后的保守截断——每一步都在努力保护用户体验。这种”永不放弃”的设计理念，让系统在各种极端情况下都能稳定运行。

向量化搜索

长期记忆层引入向量搜索，实际上是在为 AI 构建一个”联想记忆”系统。当用户提出新问题时，系统不仅能看到当前对话，还能”回忆”起过去处理过的类似问题。这种跨会话的知识迁移能力，让 Claude Code 从一个简单的对话工具进化成了一个真正的智能编程助手。

Gemini-cli 的上下文管理

Gemini-cli 的上下文管理走了一条和 Claude Code 相似但更加轻量的路线。它的核心理念很简单：文件系统就是天然的数据库。

三层混合存储架构

与 Claude Code 类似，Gemini-cli 也采用了分层设计，但实现更加简洁：

第一层：纯内存工作区

存储当前会话的聊天历史、工具调用状态、循环检测状态
零延迟访问，不涉及任何 I/O 操作
会话结束即清空，不留痕迹

第二层：智能压缩层

触发阈值：70%（比 Claude Code 的 92% 更保守）
保留策略：最新 30% 的对话历史
压缩产物：5 段式结构化摘要

第三层：文件系统持久化

全局记忆：~/.gemini/GEMINI.md
项目记忆：向上递归查找直到项目根目录
子目录上下文：向下扫描并尊重忽略规则

70/30

Gemini-cli 选择了 70% 作为压缩触发点，30% 作为保留比例。这个比例设计很有讲究：

为什么是 70% 而不是 92%？

更早介入，避免紧急压缩导致的卡顿
给压缩过程留出充足的缓冲空间
适合轻量级应用场景，不追求极限性能

30% 保留的合理性

刚好覆盖最近 5-10 轮对话
足够维持上下文连续性
不会让用户感觉”突然失忆”

5 段式压缩：够用就好

相比 Claude Code 的 8 段式结构，Gemini-cli 的压缩更简洁：

markdown

体验AI代码助手
代码解读
复制代码


1. overall_goal - 用户的主要目标

2. key_knowledge - 重要技术知识和决策

3. file_system_state - 文件系统当前状态

4. recent_actions - 最近执行的重要操作

5. current_plan - 当前执行计划

忽略规则

Gemini-cli 的 .geminiignore 机制是个亮点：

独立但兼容

可以单独在非 git 仓库中生效
与 .gitignore 并行工作，互不干扰
每个工具都有独立的忽略开关

明确的约束

修改 .geminiignore 需要重启会话才生效
这不是 bug，而是 feature——避免运行时状态混乱

Gemini-cli 的设计哲学可以总结为：不求最优，但求够用。

它没有追求理论上的完美压缩比，也没有搞复杂的向量检索，而是用最简单的方案解决了 80% 的问题。这种务实的态度在工程实践中往往更受欢迎——系统简单意味着 bug 少，维护容易，用户上手快。

特别是”文件系统就是数据库”这个理念，虽然听起来有点”土”，但在实际使用中却异常可靠。你不需要担心数据库挂了、连接断了、事务死锁了…文件就在那里，看得见摸得着，出了问题 cat 一下就知道怎么回事。

这种设计思路值得很多过度工程化的项目学习：有时候，简单就是最好的复杂。

小结

上下文是智能的边界，压缩是性能的艺术。

在与大型语言模型打交道的过程中，上下文管理已成为决定智能上限与系统稳健性的关键。虽然现代 LLM 提供了百万级 Token 的窗口，但在实际 Agent 场景中，这远远不够，尤其当涉及非结构化数据（如网页、PDF）时，Token 使用会迅速膨胀。即使有前缀缓存等机制，成本与性能的双重压力仍然存在。因此，上下文压缩成了必选项——但压缩得太激进，又会导致信息丢失，损害 Agent 的决策能力。

聪明的系统不是记住所有，而是记住该记住的。

应对上下文限制的最佳方式不是简单保留或截断历史，而是构建一个具备“记忆力”的智能系统。Claude Code 以三层记忆架构为核心（短期、高速；中期、结构化压缩；长期、跨会话向量化搜索），同时引入 TodoWrite 工具，让模型自我管理计划任务。这使得 Agent 能专注目标、灵活调整、透明运行，形成类人思维般的任务记忆系统。关键机制如 Token 反向遍历、92% 阈值缓冲、8段式摘要结构与优雅降级策略，共同打造了一个稳健又高效的上下文生态。

工程的智慧在于‘够用’，而非‘极致’。

对比 Gemini-cli、OpenManus 与 Manus 的上下文策略，可以看出不同系统在工程实现上的取舍哲学。Gemini-cli 采用实用主义的轻量分层设计，70/30 压缩策略既简单又高效，让用户可控又无需担心性能瓶颈；Manus 则大胆将文件系统作为智能体的“外部大脑”，通过引用而非存储规避 Token 限制；而 OpenManus 则为最小可运行原型提供了基础模板。这些方案展现出一个共识：上下文不一定要复杂，关键在于是否服务于目标。

以上。

Multi-Agent 系统的主从架构

发表回复

最近一年，Multi-Agent 系统持续发热发烫，融资不断，火了起来。

从 AutoGPT 到 MetaGPT，从 CrewAI 到 LangGraph，各种多代理框架层出不穷。国内现象级的 Manus，以及当天由 MetaGPT 的同学开源的 OpenManus。OpenAI 的 Swarm、微软的 AutoGen，还有 Anthropic 的 Claude Code，每个大厂都在探索自己的 Multi-Agent 方案。GitHub 上相关项目的 Star 数动辄上万，社区讨论热度持续攀升。

从这股热潮，我们可以看出 AI 应用的一个重要趋势：从单一模型调用走向多智能体协作。就像软件开发从单体应用演进到微服务架构，AI 系统也在探索如何通过多个专门化的 Agent 协同工作，完成更复杂的任务。

当我们仔细观察这些 Multi-Agent 系统的架构时，会发现一个规律：

MetaGPT 里有个产品经理角色，负责协调其他工程师角色；AutoGen 支持 Manager-Worker 模式；Claude Code 更是明确采用了主循环引擎加子任务代理的设计。在 OpenAI Swarm 中，也能看到 Orchestrator Agent 的影子。

这些系统都采用了某种形式的「主从」架构——有一个 Agent 负责全局协调，其他 Agent 提供专门化支持。

为什么？巧合吗？

今天我们就聊聊 Multi-Agent 系统的主从架构。从大模型的底层原理开始。

1 从大模型的原理说起

1.1 大模型的「注意力」机制

要理解为什么需要主从架构，得先理解大模型是怎么「思考」的。

大模型的核心是 Transformer 架构，而 Transformer 的灵魂是注意力机制（Attention）。简单来说，模型在生成每个 token 时，会「注意」到输入中的所有相关信息（上下文窗口内），然后综合这些信息做出决策。

这里有个关键点：大模型的每次决策都是基于它能「看到”」的全部上下文。

这就像你在做一道数学题。如果题目是”小明有 5 个苹果，给了小红 2 个”，你要回答”小明还剩几个”，你必须同时看到”5 个”和”给了 2 个”这两个信息。如果你只看到其中一部分，就无法得出正确答案。

大模型也是如此。它的智能来源于对上下文的完整理解（其智能还来源于预训练时学到的知识，模式识别、知识迁移等能力）。一旦上下文缺失或者矛盾，模型的输出质量就会急剧下降。

1.2 多个模型协作的挑战

当多个大模型（Agent）需要协作时，如何保证它们都拥有必要的上下文？

假设我们有三个 Agent 并行进行开发部署工作：

Agent A：负责前端开发
Agent B：负责后端开发
Agent C：负责部署运维

理想情况下，它们应该像一个经验丰富的全栈工程师一样，时刻知道其他部分的设计决策。但实际上，每个 Agent 都是独立的大模型实例，它们各自维护着自己的上下文。

这就产生了第一个问题：上下文分裂。

Agent A 决定使用 React，Agent B 决定用 Python Flask，这本来没问题。但当 Agent A 后续生成代码时假设后端返回 GraphQL，而 Agent B 实际提供的是 REST API，最终代码就无法正常工作。

并且大模型有个特性叫「自回归生成」——每个新的输出都依赖于之前的所有输出。这意味着一旦某个 Agent 做出了错误假设，这个错误会在后续生成中不断放大。

2 主从架构的设计哲学

2.1 为什么主从架构有效

主从架构的核心思想很简单：一个指挥，多个执行。一个主 Agent 掌控全局，其他从 Agent 提供子领域专业化的支持。

这个设计直接解决了上下文分裂的问题。主 Agent 始终维护着完整的任务上下文，它知道：

整体目标是什么
已经做了哪些决策
各个部分如何配合
当前的优先级是什么

从 Agent 则像是主 Agent 的「外脑」——当主 Agent 需要专门知识时，会调用相应的从 Agent，但最终的决策和执行都由主 Agent 完成。

在我们做具体实现的时候，每个不同的从 Agent 都有自己的角色和系统 Prompt。

2.2 Claude Code 的实践印证

Claude Code 的设计诠释了主从的理念。根据 Github 上逆向工程的分析，它的架构中：

nO 主循环引擎（主 Agent）负责：

维护完整的代码上下文
协调所有子任务
做最终决策
生成实际代码

I2A 子任务代理（从 Agent）负责：

回答特定问题
提供专业建议
探索可能的解决方案

Claude Code 刻意避免了子 Agent 的并行修改。当需要调查多个方向时，主 Agent 会有限范围内并行地咨询不同的子 Agent，确保每个决策都基于最新的完整上下文。

这种设计看起来「低效」，但实际上避免了大量的错误和重做，总体效率反而更高。

2.3 生物学的启发

并且，主从架构在生物界也是有比较多例子的。

人脑就是一个典型的例子。前额叶皮质充当「主 Agent」，负责高级决策和规划。而各个专门脑区（视觉皮层、听觉皮层、运动皮层等）就像「从 Agent」，处理特定类型的信息。

所有的感官输入最终都会汇聚到前额叶皮质，由它整合信息并做出决策。即使是反射动作，大脑也会在事后「知晓」并可能调整后续行为。

这种中心化的架构经过了数亿年的进化验证。

3 主从架构的技术实现

3.1 上下文管理

实现主从架构，最核心的是上下文管理。主 Agent 需要：

1. 维护完整但精简的上下文

并不是所有信息都同等重要。主 Agent 需要智能地压缩和总结历史信息。Claude Code 使用了一个策略：

当 token 使用量达到阈值的 92% 时，触发压缩机制。关键决策被保留，而从 Agent 的中间探索过程被压缩或丢弃。这样既保持了决策的连贯性，又避免了上下文爆炸。

2. 构建结构化的决策记录

不要只是简单地拼接所有的对话历史。需要结构化地记录：

任务目标和约束
已做出的关键决策
各决策之间的依赖关系
待解决的问题队列

3. 动态调整上下文窗口

根据任务的复杂度和当前阶段，动态调整传递给从 Agent 的上下文量。初期探索阶段可以更开放，后期执行阶段需要更精确。

3.2 Agent 的设计原则

Agent 不是越智能越好，而是要专注和可控：

1. 明确的能力边界

每个从 Agent 应该有清晰定义的能力范围。比如：

代码审查 Agent：只负责发现潜在问题
重构 Agent：只负责改进代码结构
测试 Agent：只负责生成测试用例

2. 标准化的输入输出

从 Agent 的接口要标准化，这样主 Agent 可以用统一的方式调用它们。输出格式也要规范，便于主 Agent 解析和整合。

3. 无状态设计

从 Agent 最好是无状态的，每次调用都是独立的。这样可以避免状态管理的复杂性，也便于并行化（当任务确实独立时）。

3.3 协调机制的关键点

主 Agent 的协调能力决定了整个系统的表现：

1. 任务分解策略

并不是所有任务都要分解。主 Agent 需要学会判断：

简单任务直接处理
复杂任务分解但保持上下文
探索性任务可以并行但结果需要串行整合

2. 冲突检测与解决

即使在主从架构下，从 Agent 的建议也可能相互矛盾。主 Agent 需要：

检测潜在的冲突
评估不同方案的优劣
做出最终决策并保持一致性

3. 优雅降级

当从 Agent 失败或不可用时，主 Agent 应该能够：

尝试从其它从 Agent 获取
降级到自己处理
调整任务策略

4 主从架构的优势与局限

4.1 主从架构的核心优势

1. 全局一致性保证主 Agent 作为唯一的决策中心，天然保证了架构决策的一致性。不只是技术栈的选择（比如统一使用 REST 还是 GraphQL），更重要的是接口约定、错误处理策略、命名规范等细节都能保持统一。这种一致性在复杂项目中价值巨大。

2. 清晰的决策链路每个决策都有明确的来源和依据。你可以在主 Agent 的对话历史中追踪每个架构决定是如何做出的，为什么选择某个方案。这种可追溯性在调试问题或向他人解释系统设计时非常有价值。

3. 优雅的错误处理主 Agent 掌握全局状态，当某个子任务失败时，它可以准确判断影响范围并制定恢复策略。比如，如果数据库设计出错，主 Agent 知道哪些 API 设计需要相应调整。而在去中心化系统中，这种级联影响很难追踪和修复。

4. 上下文利用最大化看似串行的决策流程，实际上优化了整体效率：

避免了重复劳动（多个 Agent 不会各自生成相似的代码）
减少了协调开销（不需要 Agent 间的大量通信）
上下文复用充分（主 Agent 的决策历史可以直接传递给从 Agent）

在 Claude Code 的实践中，这种设计让系统能在有限的 token 预算内完成相当复杂的编程任务。

4.2 主从架构的局限性

1. 主 Agent 成为性能瓶颈所有决策都要经过主 Agent，当需要并行处理多个复杂子任务时，主 Agent 的串行决策会限制整体效率。就像一个项目经理同时管理太多团队，协调成本会急剧上升。

2. 对主 Agent 能力的高度依赖系统的智能上限取决于主 Agent 的能力。如果主 Agent 对某个领域理解不深，即使有专业的从 Agent，整体表现也会受限。这就像一个不懂技术的经理，很难充分发挥技术团队的潜力。

3. 缺乏真正的协作智能主从架构本质上是”分解-执行-组合”的模式，缺少 Agent 之间的平等协商和创造性互动。在需要头脑风暴或多视角探索的任务中，这种层级结构可能限制了解决方案的多样性。

4. 任务分解的粒度难题主 Agent 需要准确判断任务分解的粒度。分得太细，协调成本高；分得太粗，从 Agent 可能无法胜任。而且随着任务复杂度增加，找到合适的分解方式越来越难。

4.3 适用场景分析

主从架构特别适合：

1. 工程化任务

代码生成
系统设计
文档编写

这些任务需要高度的一致性和结构化。

2. 有明确目标的任务

问题诊断
数据分析
流程自动化

目标明确时，中心化协调更高效。

3. 需要可控性的场景

金融交易
医疗诊断
法律咨询

这些领域不能接受不可预测的行为。

不太适合：

1. 创意生成

头脑风暴
艺术创作
探索性研究

2. 大规模并行处理

日志分析
图像批处理
分布式爬虫

3. 对等协作

多人游戏 AI
群体仿真
去中心化系统

5 小结

随着大模型能力的提升，主从架构也在演进：

更长的上下文窗口：GPT-4 已经支持 128K 的上下文，Claude 3 甚至到了 200K。这意味着主 Agent 可以维护更完整的历史，减少信息损失。
更好的指令跟随：新一代模型在指令跟随上有显著提升，从 Agent 可以更准确地理解和执行主 Agent 的指令。
原生的工具调用：模型开始原生支持函数调用，这让主从 Agent 之间的接口更加标准化和可靠。

如果你要实现一个主从架构的 Multi-Agent 系统，以下是一些建议：

1. 设计清晰的 Agent 角色：不要让从 Agent 职责过于宽泛。每个从 Agent 应该像 Unix 工具一样——做一件事，并做好。

2. 实现鲁棒的错误处理

从 Agent 失败是常态，不是异常。主 Agent 需要：

超时机制
重试策略
降级方案
错误隔离

3. 优化上下文传递：控制上下文的边界，并不是所有上下文都需要传递给给到 Agent。根据任务类型，精心设计上下文的内容和格式。

4. 监控和可观测性：记录所有的决策点和 Agent 交互，后面调试和优化用得上。

Multi-Agent 的主从架构，本质上是在解决一个古老的问题：如何组织多个智能体高效地完成复杂任务。

从生物进化到人类社会，从计算机架构到分布式系统，我们一次次地发现：在需要一致性和可控性的场景下，某种形式的中心化协调是必要的。

大模型的出现并没有改变这个规律。相反，由于大模型对上下文的强依赖，主从架构变得更加重要。

随着大模型能力的提升和 Agent 技术的成熟，我们会看到更多创新的架构出现。但无论如何演进，那些基本的原则——上下文一致性、决策可控性、错误可恢复性——都是我们在实践中需要谨慎考虑的。

以上。

架构师必备：要懂点信息架构

发表回复

看信息架构还是很多年前的事情了，大概是在 2010 年吧，有一本叫《Web 信息架构》的书，当时还在一线，想去做一个架构师，看到架构两个字就冲动买了下来。

有道是「买书一时爽，读书火葬场」

当然，这本书后面还是看完了，和想象中的不一样，但是也提升了自己某些方面的认知，现在回想起来还是有一些作用的，至少知道了一些信息架构的基本逻辑，在 battle 的时候也有一些逻辑来讲了。

最近回顾架构师必备的一些知识点，回想起来，也是必备点之一，于是温故一下。

为什么架构师要懂信息架构

大多数技术架构师在设计系统时，90% 以上的精力放在了技术实现上，却忽略了最终用户如何使用这个系统。

以下这样的场景我们应该都见过：

功能强大的 ERP 系统，员工需要培训一个月才能熟练使用
配置灵活的中台管理系统，业务人员宁愿用 Excel 也不愿意打开
技术先进的数据平台，分析师找个报表要点击七八次

这些系统在技术层面可能已经不错了，但在信息组织和呈现上却是不尽人意。

作为架构师，我们不仅要考虑系统怎么实现，还要考虑信息怎么组织、怎么流转、怎么被用户理解和使用。这就是信息架构要解决的问题。

信息架构到底是什么

提到信息架构，很多技术同学的第一反应是：”这不是产品经理或 UX/UI 设计师的事吗？”

有些偏了。用一个简单的类比来解释一下：

如果把系统比作一座大楼，技术架构就像是大楼的钢筋混凝土结构，决定了楼能建多高、承重多少。而信息架构则像是大楼的空间布局和导视系统，决定了人们在楼里能不能找到想去的地方。

更准确地说，信息架构 = 信息 + 架构。

这里的「信息」是指用户需要理解和使用的所有内容：

功能：系统能做什么（订单管理、库存查询、报表统计）
内容：系统展示什么（商品信息、客户资料、交易记录）
概念：系统如何定义事物（什么是”订单”、”客户”、”库存”）
流程：任务如何完成（下单流程、退货流程、审批流程）

同时也包括用户在 Web 上可以看到的文本、图片、影音等元素。

而”架构”则是如何组织这些信息：

分类：按什么逻辑分组（按部门？按流程？按对象？）
层级：分几层，每层放什么
关联：不同信息之间如何连接
路径：用户如何找到需要的信息，如导航，搜索

根据维基百科的定义：信息架构（英语：Information Architecture，缩写IA）是在信息环境中，影响系统组织、导览、及分类标签的组合结构。它是也基于信息架构方法论，并运用内容管理技术来管理和组织信息的一个专门学科。

理查德·索·乌尔曼（Richard Saul Wurman）在 1976 年创造了”信息架构”这个术语。他当时面对的问题，在今天看来更加严峻——信息爆炸。

人类认知的局限与信息架构的价值

人类感官系统每秒可以接收 高达 10 亿比特的信息（如视网膜、听觉系统等能高速采集大量感官数据），但我们大脑用于行为和认知的信息处理速度却极为有限。

根据 2025 年 4 月发表于《Neuron》期刊的综述文章《The unbearable slowness of being: Why do we live at 10 bits/s?》，美国加州理工学院的研究团队通过实验和信息论分析发现：

人类大脑在执行诸如打字、说话、阅读、听力理解等任务时，信息处理速度平均只有约 10 比特/秒。

量化理解大概是这样：

英语听力理解：约 13 比特/秒
打字行为：约 10 比特/秒（100词/分钟 ≈ 10 bits/s）
语言表达、复杂任务处理：也普遍维持在 10 bits/s 左右

这就像：

“感官系统是一个每秒吸入瀑布的超级吸尘器，而大脑处理系统是只能一滴一滴滴水的慢筛子。”

刻意注意一下，你会发现你每天会见到很多的人和事，实际能在你脑海里面留下印象的寥寥无几。

我们大脑处理信息的速度这么慢，其实就像你用一个老旧手机加载高清视频，根本带不动。这时候，最重要的不是往里塞更多内容，而是怎么把内容排好、简化、分清主次。这就是信息架构的价值：它就像一个聪明的「内容管家」，帮你把复杂的信息分门别类、有序呈现，让大脑不至于崩溃。不是你记不住，而是信息没被安排好。

我们刷网页、看报告、看PPT，很多时候不是内容不好，而是太乱，不知道看哪里，不知道重点在哪。大脑每秒只能处理 10 比特的信息，就像一个只能看一小角的手电筒，所以信息架构的作用就是：把重要的东西放在光照能到的地方，其他的先收起来，或者慢慢来。这种结构化的呈现，既是对读者的呵护，也是对注意力的尊重。

无论我们是在做一份 PPT 汇报、写一篇文章，还是在设计一个产品页面，真正的挑战不是“讲得多厉害”，而是让人听懂、记住，并且愿意继续往下看。这就要求我们站在对方的认知角度去思考，用结构帮他减少思考负担。换句话说：做内容不是堆信息，是搭桥——在信息和人之间，搭一座他们能走得过去的桥。

架构师会遇到的信息架构场景

架构师在实际工作中会遇到的信息架构场景：

系统功能菜单设计：虽然通常由产品负责，但架构师需要评估：功能模块如何分组？菜单层级是否合理？是否与底层服务划分一致？
业务概念统一：同一个业务实体在不同模块中的命名是否一致？比如”客户”在 CRM 中叫 Customer，在订单中叫 Buyer，在财务中叫”付款方”，这种不一致会从代码层面影响到用户理解。在实际工作过程中，微服务的拆分和设计，领域建模，数据加设计都需要基于业务概念统一来做。
API 对外暴露的信息组织：对外 API 的资源如何分类和命名？开发者文档的组织结构？这直接影响外部开发者对系统的理解。
错误信息体系：用户能看到的错误提示如何分类？错误码如何设计才能让用户（包括运维人员）快速理解问题？再远一些会涉及监控系统和监控指标的设计。
多端信息一致性：Web、App、小程序等多端的功能和信息如何保持一致？哪些功能在哪些端出现？
系统集成时的信息映射：当多个系统集成时，如何统一不同系统中的概念和术语？如何设计统一的信息视图？

架构师的技术决策会直接影响用户（包括最终用户、运维人员、开发者）对系统的理解和使用。

构建信息架构的核心系统

信息架构不是简单的分类和排序，一般包含四个核心系统：

1. 组织系统：如何分类信息

组织系统是信息架构的基础，它决定了我们用什么维度和逻辑来分类信息。就像图书馆需要决定是按主题、作者还是出版时间来排列书籍，系统设计时也需要选择合适的组织原则——是按业务流程、用户角色、数据对象，还是使用场景来组织功能和内容。这个选择没有绝对的对错，关键在于是否符合用户的心智模型和使用习惯。

常见的组织方式包括：按字母或时间的精确型组织（适合已知查找目标的场景）、按主题或任务的模糊型组织（适合探索式浏览的场景），以及混合型组织。比如电商系统，商品分类采用层级主题（服装>男装>衬衫），订单查询采用时间序列，用户中心采用任务分组（我的订单、我的收藏、账户设置）。每种组织方式服务于不同的用户需求和使用场景。到底按照什么维度进行单一归类还是进行矩阵归类，这就是我们的组织系统要解决的问题。

架构师在设计时最容易犯的错误是按技术实现来组织信息，而不是按用户理解来组织。比如把”用户注册”放在”用户服务”模块下，把”下单”放在”订单服务”模块下，看似合理，但用户可能期望在”开始购物”这个流程中完成所有操作。好的组织系统应该让用户感觉自然和直观，而不是需要理解你的技术架构才能找到想要的功能。

2. 标签系统：如何命名信息

标签系统定义了如何命名系统中的各个信息节点，包括功能名称、按钮文案、图标选择等所有用户可见的标识。它就像路标系统，决定了用户能否快速理解每个元素的含义和作用。一个好的标签应该既准确又易懂，既符合业务语言又贴近用户认知。比如，同样是查看历史数据的功能，叫”数据回溯”还是”历史记录”，给用户的感受完全不同。

标签设计的核心挑战在于平衡专业性和通俗性。企业内部可能习惯了专业术语，比如”SKU管理”、”履约中心”、”清结算”，但对于普通用户来说，”商品管理”、”订单处理”、”对账”可能更容易理解。图标的选择也是如此，一个购物车图标比一个抽象的立方体更能让人联想到”订单”。标签系统需要建立一套统一的命名规范和词汇表，确保同一概念在整个系统中保持一致，避免用户困惑。

架构师虽然不直接负责界面设计，但在定义服务、接口、数据模型时的命名选择，会深刻影响最终的标签系统。同样是”用户”这个概念，在不同模块里分别叫User、Account、Member、Customer，这种不一致性很容易延续到界面层，造成用户理解困难。

3. 导航系统：如何浏览信息

导航系统定义了用户在系统中移动的方式和路径，它不仅包括显式的菜单、面包屑、标签页，还包括隐式的链接、快捷操作、上下文跳转等。一个好的导航系统应该让用户始终知道三件事：我在哪里（当前位置）、我能去哪里（可达路径）、我怎么回去（返回机制）。就像商场的导购图，不仅要标明店铺位置，还要提供多条到达路径，以及紧急出口的位置。

导航设计需要考虑不同用户的使用模式：新手用户倾向于使用全局导航逐层探索，熟练用户更喜欢搜索和快捷入口，专家用户可能需要自定义常用功能。因此，一个完整的导航系统通常包含多个层次：全局导航提供整体框架、局部导航处理模块内跳转、关联导航连接相关内容、面包屑提供位置感和返回路径。比如在订单详情页，除了顶部菜单和面包屑，还应该有”查看客户信息”、”相关订单”、”物流追踪”等关联导航。

架构师在设计系统时，需要预见导航的技术实现需求。单页应用（SPA）还是多页应用（MPA）？URL 路由如何设计才能支持深度链接和分享？页面状态如何保存以支持后退操作？权限控制如何影响导航的显示？这些技术决策都会影响导航系统的用户体验。更重要的是，导航路径往往反映了业务流程，一个清晰的导航系统背后，必然是清晰的业务逻辑和合理的功能划分。

4. 搜索系统：如何检索信息

搜索系统让用户能够直接定位到需要的信息，而不必通过层层导航来寻找。它包括搜索入口的位置、搜索范围的定义、搜索结果的组织和筛选机制等。一个优秀的搜索系统不仅要能精确匹配用户输入，还要能理解用户意图——当用户搜索”退货”时，系统应该同时返回退货政策、退货申请入口、历史退货记录等相关结果。搜索的核心价值在于缩短用户到达目标的路径，特别是当信息量庞大或用户明确知道要找什么时。

搜索系统的设计需要解决几个关键问题：搜索什么（全文搜索还是特定字段）、如何搜索（精确匹配还是模糊匹配）、结果如何排序（相关性、时间、热度）、如何优化（搜索建议、历史记录、热门搜索）。比如在 B 端系统中，订单搜索可能需要支持订单号精确查询、客户名称模糊查询、时间范围筛选、状态过滤等多种方式。搜索结果的呈现也很重要——是简单列表还是分类聚合？是否需要高亮关键词？是否提供”没找到想要的结果”时的引导？

搜索系统和导航系统是互补而非互斥的关系。导航系统适合探索式浏览，帮助用户了解系统全貌和信息关系；搜索系统适合目标明确的查找，让用户快速直达目标。实际使用中，用户常常在两者间切换：先通过搜索快速定位到大概区域，再通过导航浏览相关内容；或者通过导航了解系统结构后，使用搜索来快速访问常用功能。架构师需要确保两个系统使用一致的信息组织逻辑和命名体系，让用户无论通过哪种方式都能找到相同的内容。

不是所有系统都需要搜索功能，但当信息量达到一定规模时，搜索就变得必不可少。

决定是否需要搜索功能，可以考虑三个因素：

内容丰富度：信息量是否足够大
内容性质：是否需要精确查找
使用场景：用户是否有明确的查找目标

比如配置中心，当配置项超过几百个时，分类浏览就不够用了，搜索功能变得必需。

常见的信息架构类型

1. 层级结构（树状结构）

这是最常见的信息架构类型。就像公司的组织架构图，从一个根节点开始，逐层向下展开，每个节点下面有多个子节点。最典型的例子就是 Windows 的文件夹系统，或者企业官网的菜单结构。

当信息之间有明确的从属关系，需要从大类到小类逐步细化时，层级架构能让用户通过逐步深入的方式找到目标。它解决的是”如何把大量信息有条理地组织起来”的问题。

企业官网、电商的商品分类、文档管理系统、组织机构管理等。比如京东的商品分类：家用电器 > 电视 > 液晶电视 > 65英寸。

其优点是结构清晰，容易理解；扩展方便，随时可以加新分类；适合信息量大但关系明确的场景；用户学习成本低。

缺点是层级太深用户会迷失（一般不超过3-4层）；同一个信息可能属于多个分类，不知道放哪里；跨分类查找很困难；移动端展示受限，层级多了不好操作。

2. 矩阵结构

允许从多个维度访问同一信息，像 Excel 表格一样，用多个维度来组织信息，用户可以从不同角度切入找到同一个内容。比如招聘网站，你既可以按职位类型找，也可以按地区找，还可以按薪资范围找，最后都能找到同一个职位。

当同一个信息需要从多个角度访问时，矩阵架构避免了「这个东西到底该放在哪个分类下」的纠结。它解决的是「一个内容多种查找方式」的问题。

电商的筛选功能（品牌+价格+功能）、招聘网站、房产网站、多维度报表系统等。比如链家找房：可以按区域、价格、户型、面积等多个维度组合筛选。

其优点是灵活性高，满足不同用户的查找习惯；信息不用重复存储也能多处访问；特别适合需要多条件筛选的场景；能够展示信息的多个属性。

缺点是维度太多用户会选择困难；实现复杂，需要良好的标签和索引系统；可能产生大量无结果的组合；对信息的标准化要求高。

3. 线性型架构（流程结构）

信息按固定顺序排列，用户只能顺序浏览，像看书一样，从第一页翻到最后一页，用户按照预定的顺序一步步前进。最典型的就是安装向导、注册流程、购物结算流程，用户必须完成当前步骤才能进入下一步。

当任务有明确的先后顺序，需要引导用户一步步完成时，线性架构能确保用户不遗漏任何环节。它解决的是「如何引导用户完成复杂任务」的问题。

注册流程、下单流程、问卷调查、教程引导、多步骤表单等。比如 12306 买票：选择车次 → 选择座位 → 填写乘客 → 确认订单 → 支付。

其优点是用户不会迷路，始终知道在哪一步；适合新手，降低学习成本；确保必要信息都被收集；可以在每步做验证，减少错误。

缺点是不够灵活，用户不能跳过或改变顺序；如果流程太长用户容易放弃；返回修改很麻烦；不适合老用户，每次都要走完整流程。

4. 网状型架构（关系结构）

信息之间没有固定的层级关系，通过标签或关联连接。像维基百科或社交网络，信息之间通过各种关系相互连接，没有固定的层级或顺序。用户可以从任何一点开始，通过链接跳转到相关内容，形成自己的浏览路径。

当信息之间的关系复杂、非层级化，需要展示多对多关系时，网状架构能够灵活地表达这种复杂性。它解决的是”如何表达信息之间的复杂关联”的问题。

知识库系统、社交网络、推荐系统、相关内容展示等。比如知乎的问题页面，会显示相关问题、相似回答、用户的其他回答等多种关联。

其优点是最灵活，能表达复杂关系；鼓励探索，用户可能发现意外的有价值信息；没有死胡同，总有路径可走；适合内容关联性强的场景。

缺点是用户容易迷失方向，不知道自己在哪；没有明确的开始和结束；信息架构难以可视化和理解；搜索和导航设计要求高，否则用户找不到想要的内容。

实际工作中，我们很少只用一种架构类型，通常是混合使用。比如电商网站：商品分类用层级型、商品筛选用矩阵型、购买流程用线性型、商品推荐用网状型。关键是根据不同的信息类型和用户任务，选择最合适的架构方式。

小结一下

信息架构设计要求我们不仅要梳理清楚系统中有哪些信息、这些信息如何命名才能让用户理解，还要思考如何组织这些信息才符合用户的认知模式、如何设计导航和搜索才能让用户高效地找到目标。每一个节点的命名、每一条连线的关系、每一个层级的划分，都会直接影响后续的界面设计和用户体验。

信息架构是连接业务逻辑和用户界面的桥梁。向上，它需要准确理解和表达业务需求，确保所有功能和内容都有合适的位置；向下，它为界面设计提供清晰的框架，让设计师知道需要设计哪些页面、页面之间如何跳转、每个页面应该包含什么内容。一个清晰的信息架构图，能够让团队成员快速达成共识，减少后期因为结构调整带来的返工成本。

作为架构师，我们在设计系统时不能只关注技术实现，还要站在用户视角思考信息的组织方式。好的信息架构应该是”隐形”的——用户使用时感觉自然流畅，不需要思考就能找到想要的功能。这需要我们在前期投入足够的时间去理解用户需求、分析使用场景、设计合理的分类体系和命名规范。只有把信息架构的基础打好，后续的框架层和表现层设计才能水到渠成，最终构建出既强大又易用的系统。