先用一句话说清楚
AI Agent 不是“更会聊天的 ChatGPT”，而是一个能围绕目标反复推理、调用工具、读取上下文、根据结果继续行动的系统。
如果普通 LLM 调用像“问一次、答一次”，Agent 更像“给它一个目标，它可以自己走几步，中途查资料、改文件、调用 API，必要时停下来问你确认”。
这张图可以先当成入门地图：从左到右，系统的自主性越来越高，成本、延迟和风险也会一起上升。真正做项目时，不要一上来追求“全自动 Agent”，而是先判断任务到底需要停在哪一层。
三个容易混淆的概念
| 概念 | 它在做什么 | 适合什么任务 |
|---|---|---|
| 单次 LLM 调用 | 输入一段提示词，得到一次回答 | 改写、总结、分类、简单问答 |
| Workflow（工作流） | 按预设步骤串联多个模型调用和工具 | 流程明确、可拆成固定步骤的任务 |
| Agent（智能体） | 由模型动态决定下一步和要用的工具 | 步骤难预判、需要环境反馈的开放任务 |
Anthropic 把 Workflow 和 Agent 统一放在 Agentic Systems 这个大类下。对新手来说，最重要的区别不是名字，而是：
- Workflow 的路线主要由人写好的代码决定。
- Agent 的路线更多由模型根据中间结果决定。
- 路线越自由，越需要测试、权限控制、日志和人工确认。
Agent 的核心循环
一个最小可理解的 Agent，通常由四个部分组成：
- 目标：用户真正希望完成什么。
- 模型：理解目标、规划下一步、判断工具结果。
- 工具：搜索、读写文件、查数据库、调用外部 API。
- 反馈：工具返回结果、测试输出、人类确认、失败信息。
典型循环是这样的：
Goal -> Model -> Tool call -> Observation -> Model -> Next step -> Result
这里的关键不是“模型有多聪明”，而是它能不能从真实环境拿到反馈。比如代码 Agent 会读文件、修改代码、运行测试；客服 Agent 会查订单、核对规则、必要时转人工。
Agent 多出来的能力是什么
和普通对话相比，Agent 的增量主要有四类：
| 能力 | 说明 | 新手判断标准 |
|---|---|---|
| 工具调用 | 能操作外部系统，而不只是生成文本 | 是否需要查资料、改文件、调 API |
| 多步规划 | 能把目标拆成步骤并持续推进 | 是否一步回答不了 |
| 状态与记忆 | 能保留任务过程和用户偏好 | 是否需要跨轮次保持上下文 |
| 检查点 | 能在关键操作前暂停确认 | 是否存在误操作成本 |
如果一个任务不需要这些能力，直接用一次 LLM 调用通常更便宜、更快、更稳定。
什么时候应该用 Agent
值得使用
- 任务是开放式的，很难提前写死所有步骤。
- 任务需要使用外部工具，例如文件、网页、数据库、业务系统。
- 任务有可验证结果，例如测试通过、表格生成、订单状态更新。
- 你能提供沙箱、权限边界、日志和人工确认。
不建议使用
- 只是总结一段文本、改写一句话、回答一个常识问题。
- 延迟非常敏感，不能接受多轮调用。
- 成本很敏感，不能承担多次模型调用和工具调用。
- 没有测试、回滚、权限边界，却希望它直接改生产数据。
一句入门法则：先把任务做成最简单的 LLM 调用；只有当简单方案明显不够时，再加工作流；当步骤无法预判时，再考虑 Agent。
两个真实应用例子
客服 Agent
客服场景适合 Agent，因为它既有对话，又有动作：查订单、查知识库、处理退款、转人工。它的边界也比较清楚：问题是否解决、用户是否满意、是否触发了高风险操作。
代码 Agent
代码场景也适合 Agent，因为结果可以被测试验证。一个代码 Agent 可以读 issue、定位文件、修改代码、运行测试、根据失败信息继续修复。但它仍然需要人类审查，尤其是架构取舍、安全和业务语义。
新手最该记住的判断题
看到任何“Agent 方案”时，先问四个问题：
| 问题 | 为什么重要 |
|---|---|
| 它的目标是什么？ | 没有明确目标，Agent 容易兜圈子 |
| 它能调用哪些工具？ | 工具决定能力边界，也决定风险边界 |
| 它如何知道自己做对了？ | 没有反馈，就只能靠模型自信地猜 |
| 哪些步骤需要人确认？ | 权限越大，越不能全自动放行 |
把这四个问题想清楚，比背任何框架名字都更重要。