AI 工程设计（一）：模型编排不是流程图，而是系统控制面

AI 工程设计（一）：模型编排不是流程图，而是系统控制面

flowchart TD
    A([开始]) --> B[API 调用]
    B --> C{停止原因？}

    C -->|结束轮次| D([中断 / 完成])
    C -->|工具调用| E[执行工具]
    E --> F[追加结果]
    F --> B

一、从 AI 到 Agent 的工程认知

1.1 什么是 AI

很多人问，什么是 AI。

如果站在软件工程的视角，我越来越倾向于把它理解成一个接口，甚至就是一个函数：

llm(prompt)

在传统软件里，系统行为依赖开发者预先写死的规则。

输入什么，走哪条分支，调用哪个服务，返回什么结果，几乎都是确定的。

但有了大模型之后，这种固定规则开始被一种新的能力替代：

推理能力。

也就是说，开发者不再需要穷举所有业务分支，而是可以把问题本身交给：

llm()

由模型基于上下文、目标和已有信息，动态推导出下一步动作。

从这个角度看，AI 的本质其实很简单：

它提供的是一个“可推理的接口能力”。

1.2 什么是 Agent？

那什么是 Agent？

如果说 AI 只是“大脑”，那 Agent 更像是把这颗大脑真正装进一个可工作的系统里。

我更喜欢把它理解成：

Agent = AI 能力的工程化封装。

它很像一个真正可以工作的“人”。

AI 提供的是思考能力，而 Agent 工程则进一步给它补齐了：

• 身体（运行时）
• 工具（外部能力）
• 记忆（上下文）
• 行动路径（任务流程）
• 状态（当前做到哪一步）

只有这样，它才能真正完成任务，而不是只停留在“回答问题”。

简单的例子

举一个很简单的例子。

假设现在我们给员工 A 一个任务：

帮我查看今天的新闻，并整理出 10 条热点，输出到文档里。

一个真实的人在收到这个任务后，第一反应不会是立刻写结果，而是先思考：

1. 去哪里看新闻
2. 用什么方式记录
3. 怎么筛选热点
4. 最终输出到哪里

也就是说，他会先基于目标，规划行动路径，再调用自己手上的工具完成任务。

Agent 的工作方式，本质上也是一样的。

如果要让一个 Agent 完成这件事，开发者至少需要给它提供两个基础工具：

• read_news()：读取新闻内容
• write_news()：写入热点文档

然后把下面这些信息一起交给模型：

• 用户任务
• 当前上下文
• 可用工具列表
• 当前执行状态

模型就会开始推理：

第一步应该先调用 read_news() 获取新闻。

拿到新闻结果后，系统再把：

• 原始任务
• 新闻内容
• 当前状态
• 可用工具

再次交给模型。

模型继续推理下一步：

调用 write_news() 生成热点新闻文档。

直到任务闭环完成。

而这整个过程，真正关键的已经不是：

“工具有没有调用成功”

而是另一个更核心的问题：

系统如何决定下一步该做什么。

这也是我为什么越来越觉得：

模型编排不是流程图，而是整个 Agent 系统的控制面。

二、正文开始

很多人第一次做 Agent，看到刚才这个新闻案例，第一反应通常是：

这不就是一个简单的工作流吗？

先读取新闻，再整理内容，最后写入文档。

看起来就是一个非常标准的流程：

read_news -> summarize -> write_news

于是很多系统在设计“模型编排”时，很自然就会往流程图的方向走：

• 拖几个节点
• 配几条连线
• 设置几个条件分支
• 把工具接进去

一个最基础的 Agent Demo 很快就能跑起来。

从演示效果看，这样完全没有问题。

但真正进入生产环境后，你会很快发现：

问题从来不在流程能不能跑通，而在系统是否真正可控。

比如还是刚才那个新闻整理任务。

如果今天 read_news() 失败了怎么办？

如果新闻来源太少，需要自动切换到另一个资讯渠道怎么办？

如果热点数量不够 10 条，是继续补充搜索，还是允许降级输出？

如果写文档失败，是只重试写入步骤，还是从读取新闻重新开始？

如果不同用户有不同权限，哪些人允许调用外部新闻源？

这些问题，本质上都已经不是流程图能解决的问题了。

它们真正考验的是：

系统如何控制任务路径、维护状态、处理异常，以及在不确定环境里持续推进任务。

这也是我现在对“模型编排”的一个核心理解：

编排的重点从来不是节点顺序，而是系统控制能力。

流程图解决的是：

理想情况下怎么走。

而模型编排真正要解决的是：

系统在复杂、不确定、可失败的真实环境里，如何始终知道下一步该做什么。

这也是为什么我越来越倾向于把它理解成：

AI 系统的控制面（Control Plane）

而不是一个简单的流程设计器。

三、模型编排真正要解决的四类控制问题

3.1 路径控制（Flow Control）

决定下一步动作：

• 推理
• Tool
• RAG
• Human
• End

3.2 状态控制（State Control）

系统必须知道：

现在做到哪一步

包括：

• 当前任务阶段
• 工具结果
• 中间结论
• Token 使用
• 重试次数

3.3 策略控制（Policy Control）

这是体现“控制面”的关键。

包括：

• 模型路由策略
• 成本预算策略
• 风险审批策略
• 用户级别策略

3.4 恢复控制（Recovery Control）

重点讲：

• Checkpoint
• Resume
• Retry
• Fallback
• Saga Compensation

四、一个好的模型编排架构，应该如何分层

4.1 Planner（规划层）

目标拆解：

• 长任务规划
• 子任务生成
• 执行树

4.2 Router（路由层）

负责：

• 模型路由
• Tool 路由
• 风险路由
• 用户策略

4.3 Executor（执行层）

执行：

• LLM
• Tools
• SQL
• Search
• MCP

4.4 State Store（状态层）

持久化：

• Workflow State
• Checkpoint
• Tool Result
• Memory

4.5 Observer（观测层）

记录：

• Trace
• Token
• Latency
• 决策链
• 错误恢复