本文旨在探讨AI产品架构选型的核心问题，特别是工作流、路由、自主Agent和开放对话助手等四种主流架构的优缺点。通过分析Anthropic在《Building Effective Agents》中的定义，我们了解到，AI产品的架构选择是一个核心决策点，关系到产品的性能、成本和可扩展性。文章首先指出，所有架构争论的核心在于一个问题：流程的下一步应由代码决定还是模型决定？这个问题的答案将直接影响到产品的设计方向和最终效果。接着，文章提出了一个实用的框架，通过两条轴和四个象限来帮助产品经理快速判断应该采用哪种架构。这个框架强调了在设计AI产品时，应更多地考虑模型的能力，而不是仅仅依赖于预先编写好的代码。同时，文章也提到了一些常见的陷阱，如终点是否明确就决定了使用工作流，起点和终点都确定后是否需要添加意图识别等。最后，文章还强调了在实际产品设计过程中，如何根据需求灵活调整架构，以及如何平衡成本和可控性。
--91likeyou---
后来我发现，AI 产品圈里 80% 的架构争论——要不要上 agent？要不要加意图识别？要不要多 agent 协作？其实都在吵同一个问题。这篇文章分享的就是我从实战里攒出来的一个选型框架：两条轴、四个象限、三个问题。
一、所有架构争论，其实在吵同一个问题
Anthropic 在《Building Effective Agents》里给过一组被广泛引用的定义：
– Workflow（工作流）：用预先写好的代码路径，去编排模型和工具；
– Agent（智能体）：让模型自己动态决定过程和工具的使用。
翻译成一句话：流程的下一步，由代码决定，还是由模型决定？
这就是所有架构选型的第一性问题。代码决定下一步，系统就可预测、可审计、成本可控，但只能处理你预想到的情况。模型决定下一步，系统就能吃下更多不确定性，但更贵、更慢、更难评测，而且一步走错会层层放大。
可控性、成本、评测难度，三者是同一根梯度上的刻度。你不是在选技术方案，你是在决定：把多少决定权交给模型。
二、两条轴，把需求钉在坐标系上
那怎么判断该交出多少决定权？我用两条轴：
横轴：起点：用户进来的那一刻，系统是否已经知道他要办哪件事？（任务/意图的确定性）
纵轴：终点：做成什么样算完成？产出的可结构化程度分三档：有模板（产出的形状可以提前画死，比如一张固定字段的表）> 有裁判（产出形态开放，但有测试、规则或评分器能判对错）>凭感觉（只能靠人的品味打分）。
两条轴一交叉，四个象限，每个象限对应一种主流架构：
右上：起点确定 + 有模板 = 工作流。 代码定流程，模型做固定工作——只在流程节点上干模型擅长的活（抽取、比对、生成话术）。我的 KYC 填表引擎就在这里：入口只有开户这一件事，终点是一张字段完全固定的标准表。可预测、可审计、成本最低，合规过审也最容易。票据处理、单证审核这类流水线同理。
左上：起点不确定 + 有模板 = 路由＋多条工作流。 用户进来可能要办几十种事，但每种事本身流程固定。先把来意收敛成任务，再把每个任务分发给各自的固定流程。
路由不是 AI 时代的新发明。传统产品一直在做路由，只是让用户自己完成——银行 app 首页的【转账】、【查余额】按钮，售后页面的【请选择问题类型】下拉框，本质都是路由。AI 改变的是：把意图识别从用户侧搬到了系统侧，用户不用在菜单里找【我这个问题算哪类】，直接说人话，模型来判断。但也因此，如果你的任务集很小，用按钮做显式路由就够了，比 AI 路由更快、更准、更便宜。
美国银行的 Erica 是教科书案例：2018 年上线，累计交互超 20 亿次，能力全是预定义任务集——查订阅、看余额、盯退款。Klarna 的 AI 客服也是：上线首月承接了三分之二的客服对话，约合 700 名全职客服的工作量。
右下：起点确定 + 有裁判或凭感觉 = 自主 agent。 任务明确，但产出没法写成一张表。给模型一个目标和一箱工具，让它自己【规划—执行—看结果—再规划】。Deep research 类产品、coding agent 都在这里。Anthropic 官方博客写过他们的 Research 功能怎么做的：一个主 agent 拆解问题，派出多个子 agent 并行搜索再汇总。这个象限的代价是：评测和护栏不是可选项，是本体成本——没有它们兜底，agent 的自由度就是事故率。
左下：双不确定 = 开放对话助手。 不知道用户要干嘛，也没法预定义什么叫做完。ChatGPT、Claude 这类通用产品在这里——最灵活，也最贵、最难评测。除非你就是要做通用入口，否则别把产品设计在这个象限。
三、三个最容易踩的坑
框架好记，但真拿去用，有三个坑。都是我自己踩过、或者对着行业案例差点归错类的。
坑 1：终点【确定】，不等于该用 workflow
反例一秒钟就能举出来：修 bug 的 coding agent。起点完全确定（修这个 issue），终点也完全确定、甚至可以机器验证（测试通过就算修好）。按象限该落右上、走工作流——但业界所有人都在用自主 agent。为什么？
因为【终点确定】其实混了两件事：
– 有模板：产出能写成一张表/schema，每个字段怎么填都能预先规定，这才配得上 workflow；
– 有裁判：有测试、规则或评分器能判断做没做成，但产出本身是开放形态（一段任意的代码改动），这只配得上评测兜得住的 agent。
测试通过是成功标准，但不是模板。所以纵轴别用二分法，用三档梯子：有模板 ＞ 有裁判 ＞ 凭感觉。
这个三档还能解释一个行业现象：同在右下象限，为什么 coding agent 比 deep research 商业化成熟得快？因为代码有测试当裁判（第二档），研究报告的质量却在第二、三档之间飘。终点确定性决定的不是要不要 agent，而是agent 能不能被评测兜住。
坑 2：起点、终点都答完了，还要补一问——环境有界吗？
起点确定＋终点可模板化，还不够钉死 workflow。还有第三个不确定性来源：执行路上会遇到什么，是否有界？
我的 KYC 产品能安稳待在右上，不只因为起点终点确定，还因为客户递来的材料花样是有界的，证照就那几类，状态机吃得下。而代码库是无界的，你永远不知道打开一个仓库会看到什么，所以只能 agent。再比如：【帮用户在任意网站上自动填表】这类 RPA 产品，任务和产出都很明确，但每个网站的页面结构千差万别，执行环境无界，也只能走 agent。
坑 3：象限钉的是任务，不是产品
拿整个产品去归象限，一定会打架。前面提到的 Erica，90% 的流量在左上【查余额、看退款】，但长尾问题会掉进左下【我该不该把定期转成基金】；Klarna 2024 年官宣 AI 承接三分之二对话，2025 年就公开回摆、重新为复杂长尾配人工。成熟产品是任务的组合，因此是架构的组合：路由＋多条工作流＋兜底的人工或 agent。
我自己的产品也一样。客户填表填到一半开始闲聊怎么办？团队当时讨论过要不要升级架构去接住闲聊，那等于为 5% 的流量把产品拖向左下。最后的方案是一个轻量挡板：判断用户输入是否匹配当前状态机的期待，不匹配就走一个四分类【闲聊/提问/异议/无关】，礼貌回应后拉回主流程。右上象限的产品里，内嵌了一个微型的左侧任务，用最便宜的方式处理掉。
四、两条叠加规则
规则一：人机协作（HITL）不是某个象限的专利，是每个象限都要过的一道安检。 加多少人工卡点，跟象限无关，跟另一个变量有关：HITL 强度 ≈ 动作的不可逆性 × 产出的不可验证性。同在右下象限，一个只读的研究 agent 和一个能动客户资金的支付 agent，架构要求天差地别——前者生成的报告看看就行，错了也不出事，可以零人工卡点；后者每动一笔钱都不可逆，每一步都要人确认。我的填表引擎里那个【提交前确认清单】，Klarna 遇到监管话题自动转人工，都是这道安检的具体形态。
规则二：往右上收敛，但有两个限定。 好的产品设计会主动把需求往右上推——每挪一格，成本、可控性、合规过审率改善一档。删掉 RouterAgent、用挡板挡闲聊，都是收敛动作。但注意：1、收敛的前提是不牺牲需求本身的价值——deep research 要是收敛成填表，就没人用了，有些产品的价值恰恰是吸收不确定性；2、象限边界会随模型代际移动——前两年要靠 pipeline 拼装的事，现在一个 agent 循环就能做。归类结论有保质期，每代模型出来都值得重估一次。
五、实操口诀：三个问题
下次评审会有人喊：上 agent，按顺序问三个问题：
1. 先问终点：产出能不能定义成一张表/模板/schema？能，右半场；
2. 再问起点：入口是不是单一任务？是，不需要意图路由；否，前面加一层路由；
3. 补问环境：执行中会遇到的材料/环境是否有界？有界，纯 workflow 成立。
三问全是，就是最幸福的右上象限。任何一问是否，才开始考虑 agent，并且把评测和护栏的成本，算进项目本体预算，而不是当成上线后再说。
最后说说这个框架和官方指南的关系。Anthropic 和 OpenAI 的构建指南，给的是供给侧的架构菜单：有哪些模式、各自怎么搭。这个坐标系想补的是需求侧的点菜逻辑：产品经理拿着一个需求，怎么判断该点哪道菜。
一句话总结：好的 AI 产品设计，是把模型用在只有模型能干的地方，把代码用在代码就能干的地方。 分清这两者的那条线，就画在这两条轴上。
参考资料
Anthropic《Building Effective Agents》： Anthropic《How we built our multi-agent research system》： OpenAI《A practical guide to building agents》： OpenAI × Klarna 案例（AI 助手约合 700 名全职客服）： Klarna 官方新闻稿（首月承接 2/3 客服对话）： 美国银行新闻稿（Erica 突破 20 亿次交互）： 题图来自Unsplash，基于CC0协议
🔥 热词：#ai产品及功能介绍 · #ai产品是什么 · #ai架构是什么 · #ai类产品 · #ai模型部署架构 · #ai产品分析 · #ai产品主要有哪两种方式使用 · #ai系统架构