AI产品架构争论的根源，往往在于一个核心问题：流程的下一步，该由代码决定还是模型决定？本文从跨境支付KYC产品的实战出发，提出一个两条轴、四个象限的选型框架，帮你快速判断该用工作流、路由、自主Agent还是开放对话助手，并附上三个最容易踩的坑与实操口诀。

前段时间的一次架构评审会上，我做了一个让研发有点意外的决定：把方案里的意图路由 RouterAgent整个删掉。

理由只有一句话：我们的状态机永远知道自己在等什么，为什么还要花一次模型调用去猜用户想干嘛？

这是一个跨境支付的 KYC 智能采集产品，说人话：就是一个对话式填表引擎。客户开户要交一大堆材料，系统引导他把一张固定的标准表填完整。项目早期，团队一度想把它做成聊天机器人，配上意图识别、自由对话、多 agent 协作，越做越像一个小号 ChatGPT。直到有次会上用第一性原理把它钉死：“这是一个以固定标准表为目标的填表引擎，不是聊天机器人。”整个架构瞬间瘦身。

后来我发现，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 产品设计，是把模型用在只有模型能干的地方，把代码用在代码就能干的地方。 分清这两者的那条线，就画在这两条轴上。

参考资料

1. Anthropic《Building Effective Agents》：https://www.anthropic.com/engineering/building-effective-agents
2. Anthropic《How we built our multi-agent research system》：https://www.anthropic.com/engineering/multi-agent-research-system
3. OpenAI《A practical guide to building agents》：https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
4. OpenAI × Klarna 案例（AI 助手约合 700 名全职客服）：https://openai.com/index/klarna/
5. Klarna 官方新闻稿（首月承接 2/3 客服对话）：https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/
6. 美国银行新闻稿（Erica 突破 20 亿次交互）：https://newsroom.bankofamerica.com/content/newsroom/press-releases/2024/04/bofa-s-erica-surpasses-2-billion-interactions–helping-42-millio.html