做智能体项目最常见的浪费，不是技术不行，而是方案错配：问答类需求上了多智能体编排，复杂联动业务又用裸模型硬扛。这篇把选型判断、底层架构、落地链路和一条可执行的学习路径串起来讲，重点给出"什么时候该升级方案"的判定方法。
选型的第一问：流程能不能预先枚举
单智能体方案的配置极简：一个文生文大模型加若干定制工具函数，就能覆盖简单问答、单工具调用、基础数据查询。判断标准很朴素——任务的执行路径能不能在写代码时枚举清楚。能枚举的，固定流程加单智能体就够了，开发快、测试容易、故障好定位。
路径枚举不出来、需要按中间结果动态决策的，才轮到多智能体串联。多智能体开发两条路各有位置：
| 方案 | 代表 | 优势 | 局限 | 适用 |
|---|---|---|---|---|
| 源码自研 | LangGraph | 自由度高、扩展性强，任意复杂串联逻辑 | 要写代码，周期长 | 商业化复杂产品 |
| 低代码平台 | Dify、Coze | 上手快，原型极速 | 复杂逻辑受限 | 快速验证、简单业务 |
一个被反复验证的坑：低代码平台搭的原型验证通过后，团队经常直接把原型推上生产，结果复杂分支做不进去再回头重写。原型和生产的代码资产要分开评估，低代码验证思路、源码承接落地，迁移成本提前算进排期。
底层架构：两层结构一条链路
无论单还是多智能体，底层都是两层：核心能力层是文生文大模型，负责理解、推理和指令生成；工具资源层是它的手脚——工具函数、MCP 协议服务，往后还能挂 RAG 知识库和数据库。
MCP 有个流行的误解要纠正：把它说成"封装后的 HTTP 工具接口"只对了一半。它是一套标准协议，除了接口封装，还定义了能力发现、能力描述和会话语义——客户端能动态查询服务端有哪些工具可用。这才是各家愿意接它的原因：不是省一层 HTTP 代码，是换来了跨厂商的工具互认。
落地链路是固定的四段：LangGraph 组装架构 → Python 本地调试 → NodeJS 封装 HTTP 服务 → 终端走流式接口实时输出。每段都有各自的验收点：本地阶段看功能正确性，服务化阶段看接口契约和超时处理，流式阶段看首 token 延迟和断连重连。
多智能体的两个高频故障
上了 LangGraph 之后，故障集中在这两处：
- 状态字段冲突：多个节点写同一个 state key，后写的覆盖先写的，下游节点拿到被污染的状态。对策是状态 schema 一次定义清楚，每个节点声明自己读哪些写哪些，公共字段只允许单一写者。
- 循环图没有终止条件：分支回环后没有设置退出判据，Agent 永远跑不完。每个环必须带终止谓词加最大轮数兜底——循环内的工具调用都在花钱，死循环烧的是真金白银。
学习路径：三阶段别倒序
阶段一，大模型调用打底：远程方案走阿里云百炼，开箱即用；本地方案走 Ollama 私有化，数据不出内网。两条都过一遍，选型时才知道边界在哪。阶段二，加能力：函数调用、MCP 服务接入、业务知识库注入，让智能体从会聊升级到会干活。阶段三，上多智能体：LangGraph 图结构串联，同时横向对比各低代码平台的工作流能力，做到懂原理、会选型。
顺序不能倒：跳过阶段一直接玩编排框架，出问题时分不清是模型能力不行还是编排逻辑有错，排查成本翻倍。
最后一句选型心法：轻量场景单智能体快速落地，复杂场景 LangGraph 源码定制，原型验证交给低代码提速。方案跟着场景走，跟风上架构只会增加维护成本。
评论0