> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/agentic_ai_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/agentic_ai_guide/di-san-bu-fen-gong-cheng-shi-jian-yu-luo-di/09_agentops/9.10_agent_or_automation.md).

# 9.10 智能体还是自动化：为需求匹配最简形态

前九节讲的都是怎么把智能体**建好**：设计模式、Harness、可观测性、成本优化、企业集成、失败处理、反模式、上生产、量自主度。本节是这一章的判断力收尾——**知道什么时候不该建智能体，和知道怎么建同样重要**。这不是反对智能体，而是给它划一条不被滥用的边界：只有把最简形态用尽之后，自主智能体才真正开始增值。

## 9.10.1 需求侧的错位：要“一个智能体”的人，通常在描述一个自动化问题

一个在本书别处没有专门点破、却在落地时反复出现的现象是：**提出需求的人开口要的是“一个智能体”，拆开看要的却是一个确定性结果**。

* “做一个完全自主的 AI 前台” → 真实需要的是一段工作流：读入表单、按规则路由到对应处理人。
* “做一个全自动的财务副驾” → 真实需要的是在差异进入争议队列前自动对账——一次 LLM 调用读非结构化备注，其余全是普通代码。
* “做一个 AI 自动营销工具” → 真实需要的是一个定时任务：监控某类事件、触发一条固定动作。

三个需求开口都说智能体，交付的最优解都是自动化。原因很简单：智能体是当下最惹眼的形态，demo 里自己规划、自己动手，观感极强；但**观感最强的形态，和交付结果最经济、最可靠的形态，是两回事**。

> **重要**：需求评审的第一步不是选模式，而是把“要什么技术”翻译回“要解决什么问题”。需求一旦从**机制**（agent）还原成**结果**（outcome），大多数会落回确定性自动化的射程。把这一步做在设计之前，能省掉后面九节的大部分工程代价。

这与后面几节讨论的简化决策是**不同的轴**，容易混淆，先说清楚：

* 9.7.3 讲的是**单体 vs 多智能体**——在证明单体不够之前不要多智能体化；
* 本节讲的是**智能体 vs 自动化**——在证明自动化不够之前不要智能体化。

两者是同一种克制在不同层级的应用：9.7.3 问“要不要加一个团队”，9.10 问“要不要用团队里的这个人”。

## 9.10.2 采纳形态阶梯：先把最简形态用尽

把实现同一个结果的形态排成一条阶梯，从左到右，**决策空间**（留给系统自己拿主意的余地）逐级放大，灵活性、成本、延迟和审计难度也一起抬升。

```mermaid
graph LR
    A["固定脚本/规则<br/>if-else、报表"] --> B["确定性工作流<br/>DAG、RPA、定时任务"]
    B --> C["受约束工作流+LLM节点<br/>routing/固定编排"] --> D["自主智能体<br/>自行规划下一步"]
    style A fill:#f6ffed,stroke:#52c41a,stroke-width:2px
    style B fill:#f6ffed,stroke:#52c41a,stroke-width:2px
    style C fill:#fff7e6,stroke:#fa8c16,stroke-width:2px
    style D fill:#e6f7ff,stroke:#1890ff,stroke-width:2px
```

图 9-23：采纳形态阶梯（决策空间从左到右放大）

| 形态              | 决策空间               | 可靠性 / 成本              | 适合的任务             |
| --------------- | ------------------ | --------------------- | ----------------- |
| 固定脚本 / 规则       | 无                  | 100% 可复现、近零成本、毫秒级、可审计 | 分支少、规则清楚、几乎不变     |
| 确定性工作流          | 无（路径固定）            | 高可靠、低运营成本、每步留痕        | 路径可枚举、要的是吞吐       |
| 受约束工作流 + LLM 节点 | 局部（在固定编排里由模型填空/分流） | 中等，需评测线兜底             | 少数环节要语义理解，整体流程仍固定 |
| 自主智能体           | 大（自行规划步骤与工具）       | 概率化、需成本预算与失败处理、难审计    | 输入不可枚举、每步都要判断     |

选择原则是一句老话，本书在多处以不同粒度说过，这里把它落到形态层：**从最简单够用的那一档开始，只有当固定流程确实无法应对需求的变化时，才向右移一档**（9.1.3 的 “Start Simple” 与 9.1.4 的行业共识）。规则与智能体之间的可操作判定树（图 9-22）、以及“订单分类用规则、复杂查询应答用智能体”两个标杆案例，已在 [9.8.6 节](/agentic_ai_guide/di-san-bu-fen-gong-cheng-shi-jian-yu-luo-di/09_agentops/9.8_experiment_to_production.md)给出，本节不重画，只强调：**决策树要从阶梯最左端往右走，而不是默认落在最右端再往回砍**。这条阶梯也可以对齐 [1.4.2 节](/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/01_paradigm/1.4_cognitive_levels.md) 的认知层级——层级越高成本越高，不要盲目追高。

## 9.10.3 为生产可靠性约束决策空间

智能体在 demo 里出彩、在生产里翻车，根因往往只有一个：**给了它过大的决策空间**。给一个目标让它自己想办法，凌晨两点在真实客服系统里，它可能给出的就是一条没人预料到的动作。这引出本节要点名的一条一等原则——

> **约束决策空间以换取生产可靠性**：好的自动化，每一步只有一个决策点，每个分支都有明确规则，行为可预测、可回放、可审计；智能体则把多个决策点交给概率模型，可靠性随决策空间指数级变难保证。因此**能用确定性形态锁死的决策，就不要留给模型即兴发挥**。

这不是新观点，而是本书早期教训的操作化：[1.1.4 节](/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/01_paradigm/1.1_shift.md) 记录的幻觉传递、无限循环、上下文爆炸、错误处理缺失，本质上都是决策空间失控的表现。工程上收敛决策空间的手段，本章前面已经给全：受约束的静态编排（9.1）、防御性时间/迭代预算（9.6/9.7）、结构化输出的约束解码、以及人在关键决策点的介入。把它们叠加起来看，会发现一个反直觉的结论：**一个“生产级智能体”的大部分工程量，恰恰是在给智能体做减法、把它压回到尽可能像确定性自动化的形态**。

## 9.10.4 让形态匹配技术当前所处的位置

最后一层判断是时间维度：形态选择不只匹配任务的可变性，还要匹配**技术当前的可靠性位置**，而且这个位置在移动。Anthropic 在《[Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents)》中给出的建议正是这条线的权威表述——**先找最简单的解决方案，只有当更强的自主性能被证明确实改善结果时，才引入它**；能用单次 LLM 调用加检索解决的，就不要上智能体。

因为前沿能力的可靠性、价格和延迟每隔几个月都在变，形态的判决是**滚动**的：今天只配用受约束工作流的任务，随着模型在该类任务上的可靠性越过阈值，明年可能就值得放开成自主智能体。反过来也成立——不要因为技术上“能做智能体”就现在做，为不成熟的自主性付出的可靠性代价，往往吃掉它带来的灵活性收益。

> **提示**：把形态选择写成一条可复查的记录（当前选了哪一档、依据的任务判据与技术判据是什么、下次在什么信号下重判），而不是一次性拍板。这与 9.9 “部署后监控优于预先规范” 是同一种工程纪律：让判断跟着实测数据滚动更新。

一句话收束本节：**先问该不该建智能体，再问怎么建**——多数“想要智能体”的需求，用确定性自动化交付得更可预测、更可回放、更好守住生产边界；把最简形态用尽、把决策空间压到最小，是这一章所有工程手段共同服务的目标，也是对智能体真正的尊重。

***

**下一节**: [本章小结](/agentic_ai_guide/di-san-bu-fen-gong-cheng-shi-jian-yu-luo-di/09_agentops/summary.md)