11：Agent：从聊天机器人到任务执行系统

上一篇讲 Tool Use 时，我们得到了一个核心判断：

模型负责理解意图并生成工具调用；
运行时负责验证、执行和返回观察结果；
工具结果回到上下文，影响模型下一步生成。

这已经让模型具备了行动能力。

但很多真实任务不是一步完成的。

用户不会只说：

查一下这个订单。

他们更可能说：

帮我分析这个客户为什么退款，
看一下历史沟通和订单状态，
如果符合政策就起草处理方案，
必要时创建一个客服工单，
最后给我一个可确认的结论。

这类任务里，关键不只是「调用哪个工具」。

关键是：

目标是什么；
当前进展到哪一步；
下一步应该做什么；
每一步是否成功；
失败后如何调整；
什么时候应该停下来；
哪些动作需要人确认。

这就是 Agent 要解决的问题。

Agent 不是一个更会聊天的模型，而是一个围绕目标持续推进任务的执行系统。

理解这句话，才能避免把 Agent 神秘化。

一、Agent 要解决的不是「回答问题」，而是「推进任务」

普通聊天机器人的默认模式是：

用户提问
↓
模型回答
↓
对话结束或等待下一轮

即使它能写得很好，本质上仍然是一次语言生成。

Tool Use 让这个过程多了一步：

用户提出请求
↓
模型调用工具
↓
工具返回结果
↓
模型回答

而 Agent 的任务形态更接近：

用户给出目标
↓
系统拆解任务
↓
模型选择下一步行动
↓
工具执行并返回观察
↓
系统更新状态
↓
模型根据新状态继续行动
↓
直到满足完成条件，或需要人类介入

比如「帮我整理一份竞品调研」。

聊天机器人可能直接生成一份看似完整的报告。

工具调用系统可能搜索几个网页，再总结结果。

Agent 系统则应该更像一个初级研究员：

明确调研目标；
列出竞品范围；
搜索公开资料；
提取功能、定价、定位和用户评价；
发现信息缺口；
补查关键缺口；
整理表格；
写出结论；
标注证据来源；
提示哪些判断仍不确定。

这里的重点不是模型单次输出有多漂亮。

重点是系统能不能持续维护任务状态，并把任务一步步推向完成。

二、聊天机器人、工作流和 Agent 有什么区别

理解 Agent，最好先把它和两个相近概念区分开：

聊天机器人；
固定工作流；
Agent。

聊天机器人的核心是回答。

它通常不维护复杂状态，也不主动规划后续步骤。

固定工作流的核心是流程。

它把步骤提前写死：

先查订单；
再查政策；
再判断条件；
再生成回复；
再等待确认。

这很稳定，也很容易审计。

但它不擅长处理开放任务。

如果中途发现订单异常、资料缺失、用户目标改变，固定流程要么分支爆炸，要么回到人工处理。

Agent 位于两者之间。

它不是完全自由发挥的聊天。

也不是每一步都写死的流程。

更准确地说：

Agent 把目标、状态、工具和约束交给模型，
让模型在受控边界内选择下一步行动。

因此 Agent 的优势不是「更神奇」。

它的优势是：

在目标明确但路径不完全确定的任务中，
动态选择步骤并持续推进。

这也是为什么 Agent 适合研究、排障、代码修改、数据分析、运营处理、客服协作等任务。

这些任务都有目标，但路径会随着观察结果变化。

三、Agent 的第一性原理：目标、状态、行动、观察、停止

从第一性原理看，一个 Agent 至少需要五个要素：

目标；
状态；
行动；
观察；
停止条件。

目标回答：

系统最终要完成什么？

状态回答：

现在已经知道什么？
已经做过什么？
哪些事情还没做？
有哪些约束？

行动回答：

下一步可以做什么？
调用哪个工具？
问用户什么问题？
生成什么中间产物？
是否需要等待外部结果？

观察回答：

行动之后外部世界返回了什么新事实？
成功了吗？
失败了吗？
结果是否改变原计划？

停止条件回答：

什么时候可以交付？
什么时候必须暂停？
什么时候应该请求用户确认？
什么时候应该放弃当前路径？

把这五个要素放在一起，Agent 就不再是一个抽象名词。

它可以被写成一个循环：

读取目标和当前状态
↓
选择下一步行动
↓
执行行动
↓
读取观察结果
↓
更新状态
↓
判断是否停止
↓
如果未停止，继续下一轮

所以 Agent 的本质不是「模型突然有了自主意识」。

它的本质是：

在一个受控循环里，让模型根据目标和状态，反复选择下一步行动，直到任务完成或触发停止条件。

四、计划不是答案，而是临时假设

很多 Agent 系统都会先让模型生成计划。

比如：

1. 阅读需求
2. 搜索相关资料
3. 整理对比表
4. 写出结论
5. 检查缺口

计划很重要。

但计划不应该被当成不可变的答案。

因为 Agent 面对的是开放世界。

行动之后，系统可能发现：

资料不存在；
接口失败；
权限不足；
用户给的信息有歧义；
第一步的判断错了；
任务目标需要重新澄清；
成本超过预期；
某个动作风险太高。

如果计划被写死，Agent 就会在错误道路上越走越远。

更合理的理解是：

计划是当前信息下的工作假设。

它的作用是让系统先有方向。

但每次观察之后，计划都应该允许被修正。

比如一个代码修改 Agent 可能先计划：

1. 找到报错文件
2. 修改类型定义
3. 运行测试
4. 提交修改

但测试失败后，它应该更新计划：

类型问题只是表层；
真正问题在数据结构；
需要回到调用链上游检查输入；
先不要提交。

这就是 Agent 和固定工作流的差异。

固定工作流强调按预设步骤执行。

Agent 强调在目标不变的情况下，基于观察修正路径。

五、状态和记忆：上下文不是全部记忆

Agent 必须管理状态。

否则它就无法回答：

我已经做到了哪一步？
哪些信息已经确认？
哪些工具已经调用过？
哪些尝试失败了？
下一步为什么要这么做？

很多人会把状态直接等同于上下文窗口。

这不够。

上下文窗口是模型当前可见的工作区。

但 Agent 的任务可能很长。

它可能跨越很多轮对话、很多次工具调用、很多个文件、很多小时甚至很多天。

如果所有状态都塞进上下文，会遇到几个问题：

上下文会变长，成本上升；
旧信息会被截断；
无关细节会干扰模型判断；
关键决策缺少结构化记录；
系统重启后状态丢失。

所以更稳妥的做法是把记忆分层：

短期上下文：当前这一步必须看到的信息；
任务状态：目标、待办、已完成、阻塞、决策记录；
长期记忆：用户偏好、项目背景、历史经验；
外部记录：数据库、文件、工单、日志、版本控制。

模型不应该独自背下所有东西。

系统应该把重要状态结构化保存，并在需要时重新放进上下文。

这和 RAG 的思想类似：

不是把所有信息永远塞给模型，
而是在需要时把相关信息取出来。

长任务里通常会同时用两种方式回收上下文。第一种是检索式：把历史记录、文件、工单、日志存在外部系统里，需要时再按关键词或语义检索回来。第二种是压缩式：把已经完成的长过程总结成更短的任务摘要、决策记录和当前状态，避免上下文无限膨胀。

对 Agent 来说，记忆不是神秘能力。

记忆是状态管理。

六、工具和环境：Agent 的行动空间

Agent 能做什么，取决于它能访问什么环境。

一个只会聊天的模型，行动空间只有：

生成文本。

一个有工具的模型，行动空间会扩大：

搜索；
读取文件；
写入文件；
运行代码；
查询数据库；
调用业务 API；
打开浏览器；
发送通知；
创建工单。

但行动空间越大，风险也越大。

因此 Agent 系统不能只问：

模型够不够聪明？

还要问：

它能看到什么？
它能改什么？
哪些动作需要确认？
哪些工具只能读不能写？
哪些环境是沙盒？
哪些日志必须保留？
哪些操作可以回滚？
哪些操作永远不能自动执行？

从产品角度看，Agent 的能力边界主要由四件事决定：

模型能力；
工具集合；
状态记忆；
环境权限。

模型越强，越能理解复杂目标。

工具越完整，越能真正行动。

状态越清晰，越能跨步骤保持连续性。

权限越清晰，越能安全落地。

缺少任何一个，Agent 都会变形。

只有模型没有工具，它只是会说。

只有工具没有模型，它只是自动化脚本。

只有模型和工具没有权限边界，它就会变成不可控风险。

七、观察和纠错：失败不是异常，而是循环的一部分

Agent 一定会遇到失败。

这不是设计缺陷，而是开放任务的常态。

失败可能来自很多地方：

模型误解目标；
工具选择错误；
参数填写错误；
外部系统超时；
权限不足；
数据缺失；
测试失败；
用户目标改变；
环境状态和假设不一致。

一个不成熟的 Agent 会把失败包装成漂亮的话：

我已经完成了。

一个成熟的 Agent 应该把失败当成观察结果：

这一步失败了；
失败原因是什么；
是否可以重试；
是否应该换工具；
是否需要补充信息；
是否已经产生副作用；
是否需要暂停并让人决定。

例如代码修改任务里，测试失败不是终点。

它是下一轮推理的输入：

测试失败在哪个文件；
错误信息是什么；
是类型问题、逻辑问题还是环境问题；
刚才的修改是否导致新问题；
应该继续修改还是回滚部分改动。

这就是为什么 Agent 的观察结果必须结构化。

如果工具只返回：

失败了。

模型很难做正确判断。

如果工具返回：

{
  "status": "error",
  "step": "run_tests",
  "code": "ASSERTION_FAILED",
  "message": "Expected 3 items but received 2.",
  "file": "cart.test.ts",
  "failed_assertion": "Expected cart to contain 3 items after filtering, but received 2.",
  "related_test": "cart item filtering"
}

模型就更容易把失败转化成下一步行动。

Agent 的可靠性，很大程度上取决于它如何处理失败。

八、停止条件：能停下来和能行动一样重要

如果一个系统会持续行动，那么「什么时候停」就是核心问题。

没有停止条件的 Agent 很危险。

它可能：

无限循环；
反复调用工具；
越权尝试；
消耗过多 token 和费用；
在不确定时编造完成状态；
把低置信度动作继续执行下去；
在需要人工确认时擅自推进。

所以 Agent 至少需要几类停止条件。

第一类是完成条件：

目标是否已经满足；
交付物是否生成；
检查是否通过；
用户是否已确认。

第二类是风险条件：

动作是否会产生不可逆副作用；
是否涉及支付、删除、发送、提交、审批；
是否需要用户明确确认；
是否触发权限或合规边界。

第三类是资源条件：

最多执行多少步；
最多调用多少次工具；
最多消耗多少时间；
最多花费多少成本。

第四类是阻塞条件：

缺少必要信息；
权限不足；
外部系统不可用；
多次重试失败；
当前证据不足以继续判断。

一个好的 Agent 不只是会继续。

它也要会停、会问、会交接。

在产品里，这通常表现为：

展示当前计划；
展示已完成步骤；
解释阻塞原因；
给出可选下一步；
等待用户确认高风险动作；
在低置信度时转人工。

行动能力需要边界。

停止条件就是边界的一部分。

九、产品和工程：Agent 是系统，不是提示词

做 Agent 产品时，最常见的误区是：

写一个很长的 prompt，让模型自己规划和执行。

Prompt 很重要。

但 Agent 不能只靠 prompt。

一个可用的 Agent 系统通常需要这些层：

任务入口：用户目标、范围、约束、确认方式；
状态管理：计划、进度、待办、已完成、阻塞、决策记录；
工具运行时：schema、权限、参数校验、执行、错误返回；
环境隔离：沙盒、只读模式、写入确认、回滚能力；
观察日志：每一步调用、结果、耗时、成本和用户反馈；
评估体系：任务是否完成、步骤是否合理、风险是否受控；
人类介入：确认、审批、接管、纠错和最终验收。

这也解释了为什么 Agent 产品的难点不只是模型能力。

真正的难点在于端到端系统设计。

例如一个代码 Agent 不只是要会写代码。

它还要能：

理解仓库结构；
定位相关文件；
避免覆盖用户改动；
运行测试；
解释失败；
控制修改范围；
在不确定时暂停；
让用户知道改了什么。

一个客服 Agent 不只是要会说话。

它还要能：

读取用户身份；
查询订单；
匹配政策；
保护隐私；
区分建议和正式操作；
让高风险动作经过确认；
把处理过程写入工单。

所以 Agent 的工程问题，本质上是：

如何让概率模型参与确定性业务流程，
同时保留可控性、可解释性和责任边界。

十、Agent 的能力等级

不是所有 Agent 都应该拥有同样的自主权。

我们可以粗略分成几个等级：

这个分级不是行业标准。

它只是提醒我们：

Agent 的自主权应该和风险匹配。

很多产品不需要一上来做「全自动 Agent」。

更现实的路径往往是：

先让模型读；
再让模型建议；
再让模型在确认后写；
再让模型自动执行低风险步骤；
最后才扩展到长周期任务。

这比直接追求「完全自主」更可靠。

十一、常见误解

误解一：Agent 就是加了工具调用的聊天机器人。

不够准确。工具调用是 Agent 的基础能力之一，但 Agent 还需要目标、状态、计划、观察、停止条件和执行循环。

误解二：Agent 越自主越好。

不一定。自主权必须和风险匹配。读操作可以更自动，写操作、高风险动作和不可逆操作必须有确认、权限和审计。

误解三：只要模型足够强，就不需要工作流。

不对。模型越强，越需要清晰边界。工作流、权限、工具 schema 和评估不是替代模型，而是让模型能力可控落地。

误解四：计划写出来就应该照着执行。

不对。计划是当前信息下的临时假设。观察结果变化后，计划应该允许被修正。

误解五：Agent 的记忆就是把所有历史塞进上下文。

不对。记忆应该分层管理：短期上下文、任务状态、长期偏好和外部记录分别处理。

误解六：Agent 完成任务时，用户不需要看过程。

也不对。任务越高风险，越需要展示计划、关键动作、结果、成本、失败原因和确认点。

十二、总结：Agent 是持续行动的受控循环

现在我们可以把 Agent 压缩成几句话：

聊天机器人主要生成回答；
Tool Use 把语言意图连接到外部系统；
Agent 在目标、状态、工具和约束之间形成持续执行循环；
计划是临时假设，不是固定答案；
观察结果会更新状态，并改变下一步行动；
记忆本质上是结构化状态管理；
停止条件和人类确认决定 Agent 的安全边界；
Agent 产品的难点是端到端系统设计，不只是 prompt。

如果再压缩成一句话：

Agent 的本质，是让大模型在受控边界内，围绕目标持续选择行动、读取观察、更新状态，并在合适的时候交付、暂停或请求人类确认。

理解 Agent 后，我们再看现代 AI 产品，就会发现它们正在从「回答型产品」走向「任务型产品」。

模型负责理解、生成和选择下一步。

RAG 负责带入外部证据。

Tool Use 负责连接外部行动。

Agent 则把这些能力组织成一个持续推进任务的系统。

但任务执行系统越强，工程问题就越重要：

推理成本；
上下文管理；
KV Cache；
并发执行；
工具延迟；
状态持久化；
可观测性；
部署架构。

下一篇，我们继续进入大模型工程：为什么同样是生成 token，成本、延迟和部署系统会成为 AI 产品能否规模化的关键。