从 Chatbot 到 Agent：什么是“可执行的 AI”，以及它为什么更难

面向：开发者 / 技术负责人

目标：把“Agent”讲清楚（不是噱头），并给出可落地的工程分层与检查清单。

TL;DR

Chatbot 主要是“回答问题”；Agent 是“为了目标去执行任务”，会调用工具、做计划、读写状态。
Agent 之所以难，不在“模型更聪明”，而在工程约束：权限、状态、失败恢复、评测、观测、成本。
落地建议：用“工作流优先 + Agent 兜底”的混合架构，把不确定性关进笼子。

1）你以为的 Agent vs 真实的 Agent

很多团队第一次做“智能体”，会把它想象成：

把一个更强的模型接上几个插件，它就会自动完成任务。

现实更接近另一句话：

Agent = 在不确定世界里运行的自动化系统，模型只是其中的一个“决策器”。

Chatbot 的输入输出相对单一：

输入：用户问题（多为一次性）
输出：一段回答（最多带引用/格式化）

而 Agent 的输入输出是“过程型”的：

输入：目标（Goal）+ 约束（Constraints）+ 环境状态（State）
输出：一个或多个动作（Actions）+ 中间结果（Artifacts）+ 最终交付（Outcome）

一旦进入“动作世界”，你就必须面对：

工具会失败（超时、限流、权限不足、接口变更）
任务会分叉（需要澄清、需要人类确认）
结果难定义（什么叫成功？怎么验收？）

所以，Agent 的难点从来不是‘能不能生成’，而是‘能不能可靠地完成’。

2）Agent 的最小组成：模型 + 工具 + 状态 + 策略

要让 Agent 不至于“看起来很会说、做起来很飘”，建议用一个最小模型拆解：

2.1 模型（Model）：负责推理与选择

模型做两件事：

理解用户目标与上下文
在候选动作里做选择（或生成下一步计划）

但模型本质上是“概率系统”。因此工程上要预期：

它会犹豫、会绕路、会自信地犯错（幻觉）

2.2 工具（Tools）：把语言变成行动

常见工具类型：

信息类：搜索、数据库查询、日志检索
操作类：创建工单、发消息、写文档、调用内部 API
外部系统：浏览器自动化、支付/下单、代码仓库

工具一多，系统风险也随之扩大：

权限边界（能不能写？能写到哪里？）
副作用（重复执行会不会造成事故？）

2.3 状态（State）：任务不会只做一步

Agent 必须“记得自己做过什么”，否则会：

重复调用工具
不断在同一步打转
产出无法复现

状态最常见的三类：

会话状态：本次对话上下文
任务状态：步骤、产物、依赖、已完成/未完成
业务状态：用户资料、订单、库存、权限、审批流

2.4 策略（Policy）：把不确定性关进笼子

策略是 Agent 的“安全带”，包括但不限于：

允许调用哪些工具、哪些参数范围
什么时候必须向人类确认
最大步数/最大成本/最大延迟
失败怎么退避、怎么降级

一句话：策略决定了它是‘可控的自动化’还是‘不可控的随机游走’。

3）为什么 Agent 比 Chatbot 难：5 个工程真相

下面 5 点，是很多团队第二个月才痛感到的“真实成本”。

真相 1：任务成功率不是模型分数，而是“端到端成功率”

Chatbot 你可以用人工评审“回答像不像”。

Agent 你要看的是：

从目标到交付，端到端成功率是多少？
失败主要卡在：计划、工具、权限、数据、还是验收？

真相 2：失败是常态，关键在“可恢复”

工具失败/接口超时/限流几乎每天发生。

你需要：

超时与重试策略（指数退避）
幂等设计（重复执行不出事）
断路器与降级（别把下游打崩）

真相 3：权限设计比提示词重要 10 倍

Agent 一旦能“写”——写数据库、发通知、改配置——就必须“最小权限”。

推荐做法：

读写分离：默认只读，写操作必须二次确认
工具白名单 + 参数约束 + 审计日志
对高风险动作引入审批（人类在环）

真相 4：评测体系决定迭代速度

没有评测，你每次改 Prompt/策略都像“凭感觉”。

至少要有：

任务集（真实案例抽样）
指标：成功率、平均步数、平均成本、P95 延迟、人工介入率
回放与对比：同一任务不同版本的轨迹对比

真相 5：观测与追踪是上线门槛，不是锦上添花

Agent 的 bug 不是“报错”，而是“做错事”。

你需要能回答：

它为什么做了这个动作？（决策依据）
这一步是谁触发的？（链路追踪）
花了多少钱、耗时多久？（成本与延迟）

4）一套可落地的分层架构（推荐）

我更推荐的架构不是“全 Agent 化”，而是：

工作流（Workflow）优先 + Agent 兜底

4.1 把确定的部分做成工作流

适合确定性的部分：

固定流程：报销、入职、工单分流
强约束：字段校验、权限校验、业务规则

优点：

可预测、可测试、可审计

4.2 把不确定的部分交给 Agent

适合不确定性的部分：

需求不清：先澄清再行动
信息散落：跨系统找资料并汇总
文本密集：生成摘要、比较差异、提取要点

4.3 关键：把 Agent 放在“受控沙盒”里

建议强制三道闸：

工具闸：能用什么工具
参数闸：参数范围/写入范围
人类闸：高风险动作必须确认

5）典型场景：哪些适合 Agent，哪些不适合

适合（高 ROI）

企业知识助理（RAG + 任务）：先查再答，必要时发起工单/生成文档
研发助理：读日志→定位模块→给出复现与修复建议（最后由人合并）
运营/客服半自动化：信息汇总 + 草拟回复 + 一键发送（人确认）

不适合（高风险/低收益）

任何“不可逆写入”且缺少审批的操作（删库、付款、发布生产配置）
业务规则极其复杂、且缺少可靠数据源的场景
你无法定义验收标准的场景（最后只会变成争论）

6）常见误区与反模式

误区 1：用更大的模型解决流程问题（结果是更贵、更慢、还不稳定）
误区 2：不做状态机，只靠对话上下文（迟早循环、重复执行）
误区 3：没有评测就上线（每次改动都在“赌博”）
误区 4：让 Agent 直接碰生产写接口（事故只是时间问题）

7）上线前清单（Checklist）

你可以把下面当成“能不能上线”的最小门槛：

目标与验收

[ ] 任务成功是什么？失败是什么？有明确验收标准
[ ] 任务集（至少 50 个真实样本）可回放

工具与权限

[ ] 工具白名单与参数约束
[ ] 写操作默认需要人类确认
[ ] 审计日志：谁、在何时、做了什么动作、结果是什么

可靠性

[ ] 超时、重试、退避、降级策略
[ ] 幂等与重复执行保护
[ ] 断路器：下游异常时快速失败

评测与观测

[ ] 指标：成功率/成本/延迟/人工介入率/平均步数
[ ] 版本对比与回归测试

结语

Agent 不是“更会聊天的模型”，而是一个把模型放进生产系统后的自动化工程。

把确定性留给工作流，把不确定性留给 Agent；把权限、状态、评测、观测做扎实——你就能从“Demo 很惊艳”走到“上线能赚钱”。

参考（建议你发布时补链）

可补：OpenAI/Anthropic 关于 tool use、function calling 的公开资料
可补：LangChain / LlamaIndex 的架构文章（如你允许引用）

从 Chatbot 到 Agent：什么是‘可执行的 AI’，以及它为什么更难