欢迎使用 FlowZap，快速、清晰、掌控的绘图应用。

AI 架构师缺少的那张图

2026/8/29

Tags: problem-mind-map, mind-map, 智能体架构, problem-first, flowzap

Jules Kovac

Jules Kovac

Business Analyst, Founder

AI 架构师缺少的那张图

 

在设计 AI 系统之前，先把问题说清楚。

客户说：「我们需要一个用于客户服务的 AI 智能体。」

五分钟后，有人画出了：

User → Agent → LLM → RAG → CRM → Human

这看起来像架构。但它不是。它是一个尚未被正确定义的问题的解决方案。

在 AI 架构中，这种区别比以往任何时候都重要。产出一个看似合理的架构如今很容易。任何 LLM 都能在几秒钟内生成一个。任何一个。然而，理解我们真正应该构建什么仍然很难。 这就是为什么我认为 AI 架构师有时应该从一张根本不是架构图开始。

从一张问题思维导图开始。

 

 

问题先于架构

问题优先设计的思想并不新鲜。越来越多的 AI 设计指南强调理解问题、定义成功标准，并且只有在问题空间清晰之后才选择解决方案。

但在说「先定义问题」和真正去做之间，存在一个尴尬的鸿沟。

  • 问题定义长什么样？
  • 在哪里记录它？
  • 如何与利益相关者一起评审它？
  • 如何让不确定性可见？

而最重要的是：当你进入架构阶段时，这个问题定义如何存活下来？

问题思维导图可以给出一个具体的答案。它不是又一份需求文档。它不是又一张检查清单。它是一个问题空间的可视化模型。

 

 

问题空间先于解决方案空间

我发现把 AI 架构看作两个空间之间的递进是很有用的。

 

问题空间

我们面对的是什么？

  • 决策
  • 数据
  • 政策
  • 参与者
  • 系统
  • 约束
  • 风险
  • 未知项

 

解决方案空间

我们应该构建什么？

  • 工作流
  • 智能体
  • 工具
  • 集成
  • 护栏
  • 人在回路控制
  • 架构

错误不在于画架构图。错误在于直接跳到它们。问题思维导图给你一个在投入解决方案之前探索问题的场所。

 

 

什么是问题思维导图？

问题思维导图是问题空间的可视化清单。它回答一个看似简单的问题：

我们到底在应对什么，什么与它相关？

这正是它与我们通常用来设计系统的图表的区别。

  • 工作流图描述需要发生什么。
  • 时序图描述谁与谁交互，以及何时交互。
  • 架构图描述系统是如何组装的。

一张问题思维导图描述的是这些设计所要应对的领域。

它捕获的东西包括：

  • 决策
  • 数据
  • 政策
  • 参与者
  • 现有系统
  • 约束
  • 风险
  • 开放问题

背后还有一条有用的纪律：先用名词，再用动词。

你还没有在设计系统。你是在建立问题的词汇表。

 

 

从信贷决策开始

假设你被要求设计一个 AI 系统，帮助决定是否应该授予客户信贷。自然的诱惑是开始讨论智能体、模型、检索、集成和自动化。相反，把真正的问题放在中心：

决定是否授予信贷

然后映射围绕它的东西。

以下是用于生成上方思维导图的完整示例：

 

credit_decision { # Credit decision
  n1: circle label:"Decide whether to grant credit"
  n2: rectangle label:"Decisions"
  n3: rectangle label:"Data"
  n4: rectangle label:"Policies"
  n5: rectangle label:"Actors"
  n6: rectangle label:"Risks"
  n7: rectangle label:"Constraints"
  n8: rectangle label:"Open questions"
  n9: rectangle label:"Approve / decline"
  n10: rectangle label:"Amount & rate"
  n11: rectangle label:"Human review"
  n12: rectangle label:"Client history"
  n13: rectangle label:"Income & contracts"
  n14: rectangle label:"External score"
  n15: rectangle label:"Thresholds"
  n16: rectangle label:"Exceptions"
  n17: rectangle label:"Regulations"
  n18: rectangle label:"Who has authority?"
  n19: rectangle label:"Customer"
  n20: rectangle label:"Credit officer"
  n21: rectangle label:"Supervisor"
  n22: rectangle label:"Compliance"
  n23: rectangle label:"Hallucination"
  n24: rectangle label:"Bias"
  n25: rectangle label:"Privacy"
  n26: rectangle label:"Liability"
  n27: rectangle label:"Audit trail"
  n28: rectangle label:"Explainability"
  n29: rectangle label:"GDPR"
  n30: rectangle label:"Where do thresholds live?"
  n31: rectangle label:"Dispute: who answers?"
  n32: rectangle label:"Review margin?"

  n1.handle(right) -> n2.handle(left)
  n1.handle(bottom) -> n3.handle(top)
  n1.handle(top) -> n4.handle(bottom)
  n1.handle(left) -> n5.handle(right)
  n1.handle(right) -> n6.handle(top)
  n1.handle(bottom) -> n7.handle(left)
  n1.handle(top) -> n8.handle(right)
  n2.handle(right) -> n9.handle(left)
  n2.handle(bottom) -> n10.handle(top)
  n2.handle(top) -> n11.handle(bottom)
  n3.handle(right) -> n12.handle(left)
  n3.handle(bottom) -> n13.handle(top)
  n3.handle(top) -> n14.handle(bottom)
  n4.handle(right) -> n15.handle(left)
  n4.handle(bottom) -> n16.handle(top)
  n4.handle(top) -> n17.handle(bottom)
  n4.handle(left) -> n18.handle(right)
  n5.handle(right) -> n19.handle(left)
  n5.handle(bottom) -> n20.handle(top)
  n5.handle(top) -> n21.handle(bottom)
  n5.handle(left) -> n22.handle(right)
  n6.handle(right) -> n23.handle(left)
  n6.handle(bottom) -> n24.handle(top)
  n6.handle(top) -> n25.handle(bottom)
  n6.handle(left) -> n26.handle(right)
  n7.handle(right) -> n27.handle(left)
  n7.handle(bottom) -> n28.handle(top)
  n7.handle(top) -> n29.handle(bottom)
  n8.handle(right) -> n30.handle(left)
  n8.handle(bottom) -> n31.handle(top)
  n8.handle(top) -> n32.handle(bottom)
}

 

注意什么被刻意省略了。

这里没有 Agent、没有 LLM、没有 RAG、没有 MCP，没有架构。而这正是重点。

这张图不是在试图回答：「我们应该如何构建系统？」

它是在试图回答：「我们到底在试图解决什么？」

 

 

构建问题思维导图的五个步骤

 

1. 把问题放在中心

这是最重要的决定。不要把技术放在中心。

避免「理赔 AI 智能体」或「自动化客户服务」。这些是伪装成问题的解决方案。相反，描述结果、决策或业务问题：

  • 决定是否授予信贷
  • 解决客户支持请求
  • 将错误路由的工单减少 30%

区别很微妙，但很重要。一旦技术被放在中心，这张图往往会变成对该技术的辩护。以问题为中心的图则保持解决方案的开放性。

 

 

2. 映射与问题相关的东西

现在建立词汇表。

一个有用的起点：

  • 决策 — 必须决定什么？
  • 数据 — 存在哪些信息？
  • 政策 — 什么在支配这些决策？
  • 参与者 — 谁参与其中？
  • 系统 — 已经存在什么？

每个节点使用一个概念。与其写：「智能体应该从 CRM 检索客户信息」，不如写：

  • 客户
  • CRM
  • 客户历史

这是在决定如何导航之前先绘制领土。这一步通常会创造出第一条有用的信息：

  • 「知识」分支可能很单薄。
  • 政策可能分散在多个来源中。
  • 可能没有人同意谁真正拥有某个决策。

这不是图的问题。 这正是图在履行职责。

 

 

3. 映射什么可能毁掉解决方案

真实系统不会在快乐路径上运行。所以要加入那些约束设计或可能导致失败的东西。

约束

什么不能被忽视？

  • 法规
  • 可审计性
  • 可解释性
  • 人工审批
  • 隐私
  • 延迟

风险

什么可能出错？

  • 幻觉
  • 偏见
  • 错误决策
  • 数据泄露
  • 责任

正是在这里，问题图对 AI 架构变得特别有用。一个风险可以变成护栏。一个约束可以变成设计边界。一个合规要求可以变成检查点。这张图开始为架构创造原材料。

 

 

4. 在图上给不确定性一个位置

这可能是练习中最有价值的部分。架构图往往有一个不幸的特性：一切看起来都很确定。

一个框就是一个框。一条连接就是一条连接。一个组件就是一个组件。

但在 AI 项目的早期，有些事情我们就是还不知道。所以要让不确定性显式化。创建一个开放问题分支。

例如：

  • 谁拥有信贷政策？
  • 阈值在哪里？
  • 哪个来源是权威的？
  • 谁来回应争议？
  • 审查余量是多少？

这改变了对话。与其假装架构已经就绪，你可以说：这些是我们在架构就绪之前需要回答的问题。

有时这些问题会揭示：这个项目根本不是一个 AI 问题。也许真正的问题是知识碎片化。也许决策归属不明确。也许没有可靠的事实来源。也许流程本身从未被正确定义。

换句话说，问题图可以揭示你在解决错误的问题。 而这是一个在构建任何东西之前做出的非常有价值的发现。

 

 

5. 让架构从图中浮现

只有现在，你才应该开始设计系统。思维导图超越了头脑风暴，因为它的分支可以被追溯到设计中。

问题图 架构后果
决策智能体范围与成功标准
数据数据需求与集成
政策知识来源与检索
参与者权限与人机交互
系统工具与系统集成
风险护栏与人在回路闸门
约束非功能性需求
开放问题必须解决的决策

 

这种转化不是自动的。它是一个推理步骤。但这张图给了你有价值的东西：可追溯性。架构中的每个主要组件都应该能从问题空间中发现的某件事得到解释。

如果你发现一个架构组件在问题图中没有存在的理由，问：它为什么在这里？

如果问题图包含一个重要分支却没有架构后果，问：它在什么地方被处理？

一个简单的纪律由此浮现：没有发明。没有遗忘。

 

 

从问题到架构

正是在这里，我认为不同图表类型之间的关系变得特别有趣。问题思维导图不是架构图的替代品。它出现在架构图之前。

 

把递进关系想成这样：

思维导图
问题是什么？
↓
工作流
需要发生什么？
↓
时序图
谁与谁交互，何时？
↓
架构
我们应该构建什么？

 

每种表示回答一个不同的问题。它们共同创造了一条从问题定义到系统设计的连续推理链。关键不是强迫一张图做所有事。关键是为每个图表使用它擅于回答的问题。

 

 

什么时候思维导图没有帮助

不是每个问题都需要它。如果：

  • 问题已经被充分理解，
  • 边界已经达成一致，
  • 词汇表是共享的，
  • 利益相关者就构建什么达成一致，

那么画思维导图可能只会让你慢下来。这张图只会是排版更好的拖延。

当问题空间不确定、跨职能、政治上模糊、知识密集，或可能暴露隐藏依赖时，使用它。

不要让它变成一张愿望清单。如果每个节点都变成一个功能请求，你就离开了问题定义，进入了需求收集。问题思维导图是一个思考工具，不是对现实的权威表示。

两位架构师可能以不同方式映射同一个问题。这没问题。价值在于它创造的结构化对话。

 

 

真正的价值不是那张图

一张好的问题思维导图让那些在每个人都急于开始设计时容易被忽略的东西变得可见：

  • 哪些决策重要，
  • 哪些信息重要，
  • 需要哪些知识，
  • 谁参与其中，
  • 已经存在哪些系统，
  • 什么可能出错，
  • 什么约束着设计，
  • 以及你仍然不知道什么。

最后一点很重要。

传统架构说：「这是系统。」

问题图还可以说：「这是我们所知道的、我们所相信的，以及仍未解决的。」

这让这张图超越了头脑风暴练习。它成为一种在不确定性变成返工之前暴露不确定性的方式。

 

 

为什么这在 AI 时代更重要

AI 架构存在一个悖论。AI 越擅长产出解决方案，就越容易跳过问题定义。让 LLM 设计一个支持智能体，它可能会给你一个看似合理的东西。让它设计一个多智能体架构，它会乐意提供一个。输出甚至可能在技术上很复杂。

但复杂不等于相关。稀缺的技能越来越不是：「我能设计一个架构吗？」 而是：「我知道哪个架构应该存在吗？」 这就是为什么问题空间值得一个显式模型。

 

 

从问题到系统的连续模型

这也是图表工具可以超越画框之处。如果问题被表示为结构化数据，它就不必死在白板上。同一个模型可以随着你的理解而演化。问题定义可以导向工作流。工作流可以导向时序图。时序图可以导向架构。工件在每个阶段并不一定被扔掉。

思考被延续下去。 这就是 FlowZap 背后的理念：映射问题。建模行为。设计系统。 按这个顺序。

 

 

最后的思考

最好的 AI 架构不是拥有最智能组件的那个。而是解决正确问题的那个。所以在画系统之前，先试着画问题。你可能会发现你需要一个智能体。你可能会发现你需要一个工作流。你可能会发现你需要更好的数据或更清晰的事实来源。或者你可能会发现你还什么都不应该构建。

这正是架构师应该在方框出现之前做出的那种发现。

 

 

来源

返回所有博客文章