Agent 是什么

Agent 不是“会聊天的大模型升级版”，而是一种围绕目标持续推进任务的系统形态。它和普通 Chatbot 的区别，不在于回答更长，而在于它会根据目标、上下文和反馈决定下一步是否要查资料、调用工具、更新状态，或者直接结束任务。

理解 Agent，关键不是先背定义，而是先分清边界。很多人第一次接触 Agent，会把它和 Chatbot、AI Workflow、自动化脚本混在一起。真正进入工程实现时，这几者的差别会直接影响你该不该用 Agent、该把复杂度放在哪里、又该怎样控制风险。

什么时候才需要 Agent

不是所有 AI 功能都需要 Agent。下面这些情况，才说明你面对的是一个真正的 Agent 问题：

• 用户给的是目标，不是一步就能执行完的明确指令。
• 系统需要根据中间结果决定下一步，而不是沿固定节点一路走到底。
• 过程里可能要结合知识、工具、状态和用户反馈。
• 任务可能中断、重试、回退，系统还要知道自己做到哪一步了。

如果你的任务路径已经固定，输入输出也很清晰，通常优先用普通 Workflow。只有当“下一步做什么”本身需要系统判断时，Agent 才开始成立。

它和 Chatbot、Workflow 到底差在哪

很多误解，都是因为只看表面现象。它们都可能调用模型、都可能接知识库、都可能访问工具，但职责不同。

• Chatbot 的核心是一次对话里的问答体验。它可以带上下文，但通常不负责长期推进任务。
• Workflow 的核心是把既定流程走稳。步骤先写好，条件先定义好，系统只是按图执行。
• Agent 的核心是让系统在约束内判断下一步。它不是没有流程，而是流程里有一部分决策权交给了模型和状态。

如果把这个差异说得更直接一点：Workflow 更像“我已经知道怎么做，请系统帮我执行”；Agent 更像“我只知道目标，请系统边判断边推进”。

一个 Agent 的最小闭环长什么样

从系统视角看，一个最小 Agent 闭环通常至少包含这几步：

接收目标
  -> 理解当前上下文
  -> 判断是否需要知识或工具
  -> 执行动作
  -> 观察结果
  -> 更新状态
  -> 决定继续还是结束

这里最关键的不是“调用了多少工具”，而是系统有没有把结果再喂回自己的决策里。只要没有观察结果并据此决定下一步，那就更像一条固定链路，而不是 Agent。

当你设计或评估 Agent 时，真正要管的是什么

Agent 难的不是把模型接进来，而是把不确定性关进笼子里。一个可上线的 Agent，至少要回答这些问题：

• 它能调用哪些工具，哪些不能调。
• 每次调用前后，状态如何记录。
• 哪些动作必须人工确认，哪些可以自动执行。
• 失败时怎么停住，而不是硬着头皮继续。
• 如何保留日志、引用、参数和结果，方便复盘。

这也是为什么 Agent 从来不只是“Prompt 写得更聪明”。真正的复杂度，在工具边界、状态管理、权限校验和失败恢复里。

最容易高估 Agent 的地方

Agent 最容易让人高估的，不是效果，而是适用范围。

• 它不等于“比 Workflow 更高级”。
• 它不等于“模型自己会规划，所以系统可以少设计”。
• 它不等于“只要接上工具就能自动完成复杂业务”。

很多场景里，Agent 的自由度越大，排查、审计和成本控制就越难。真正稳的系统，往往是只把必须交给 Agent 的那部分决策开放出来，把其他部分继续留给确定性工程逻辑。

一句话先记住

Agent 不是一种模型能力，而是一种让系统在约束下持续推进目标的方式。

继续阅读

如果你准备继续理解 Agent，可以顺着这条线往下读：

• 06-agent/002-function-calling.md：先看模型怎样把“想做什么”变成可校验的工具调用。
• 07-langchain-langgraph/003-langgraph-overview.md：再看多步骤状态和动态分支怎样落到实际框架里。
• 09-ai-agent-engineering/001-ai-engineering-overview.md：最后再回到日志、成本、评估和安全，理解 Agent 为什么不能只看 Demo。