本文回答一个问题：ChatBot 会回答问题，Agent 为什么可以围绕一个目标完成任务？

先从一个熟悉的场景开始

你对普通聊天机器人说：

“帮我把这个项目的登录问题修好。”

它可能给你一段排查建议，或者生成一份修改方案。但一个 Coding Agent 可能会继续做这些事：

读取项目目录
  ↓
找到登录相关代码
  ↓
查看配置和依赖
  ↓
定位报错来源
  ↓
修改文件
  ↓
运行测试
  ↓
根据测试结果继续修复

这中间的差别，不是“Agent 使用了一个更像人的模型”，而是系统增加了目标、工具、状态和连续推进机制。

一句工程化定义是：

AI Agent 是一个围绕目标，使用 LLM、Context 和 Tools，通过循环持续推进任务的系统。

可以先记住这个近似公式：

Agent ≈ LLM + Context + Tools + Loop + Goal / Policy

一、Agent 不是“会聊天的机器人”

“Agent”在不同产品和论文里可能有不同定义。对于 AI 应用开发，先使用一个足够实用的判断方式：

系统是否在一个目标下，能够根据当前结果选择下一步行动？

如果系统只是：

输入问题 → 调用模型一次 → 输出答案

它更像普通 ChatBot。

如果系统预先写死：

先调用 A → 再调用 B → 最后调用 C

它更像 Workflow。Workflow 当然可以很强，也更容易预测和测试。

如果系统可以根据任务和中间结果，在允许的工具集合中选择下一步：

目标 → 观察 → 决策 → 行动 → 结果 → 再决策

它才更接近 Agent。

二、Agent 的五个组成部分

1. LLM：生成和推理能力

LLM 负责理解当前输入、生成文本、提出工具调用请求，或者根据工具结果判断下一步。

它是 Agent 的重要组成部分，但不是全部。没有运行时、工具和状态，LLM 本身不会自动读取你的项目或修改数据库。

2. Context：本轮能够看到的信息

模型每次做决策，都依赖当时送入的 Context。Context 可能包括：

• 用户目标；
• 项目规则；
• 之前的对话；
• 已读取的文件；
• 工具执行结果；
• 测试失败信息；
• 当前任务状态。

Agent 的质量很大程度上取决于 Context 是否完整、相关和及时。

3. Tools：可以采取的行动

工具决定 Agent 能做什么。例如：

搜索代码、读取文件、写入文件、运行测试、查询数据库、调用 API

没有工具，Agent 只能提出建议；有了工具，它才可能改变外部世界。但工具权限仍由运行时控制，不能简单理解成模型拥有这些能力。

4. Loop：持续推进任务

Agent 通常不是调用一次模型就结束，而是经历多轮：

看到了什么 → 下一步做什么 → 做完得到什么 → 是否继续

这个循环会在后面的第 09 篇单独展开。

5. Goal / Policy：目标与约束

Agent 不是漫无目的地“自主行动”。它需要一个目标，也需要约束：

目标：修复登录功能
约束：只修改 src/auth 目录，不改数据库 schema
完成条件：测试通过，并给出变更说明
停止条件：需要生产凭证时暂停并请求确认

没有明确的目标和完成条件，循环越多不一定越接近成功。

三、Agent 是如何推进一个任务的

以“修复一个接口测试失败”为例：

目标：修复 UserService 的失败测试
  ↓
读取测试文件和错误日志
  ↓
判断：可能是时间格式转换问题
  ↓
读取相关实现和配置
  ↓
提出修改文件的 Tool Call
  ↓
运行测试
  ↓
测试仍失败：读取新的错误结果
  ↓
重新判断并修改
  ↓
测试通过：生成结果说明

注意，这个过程不是 LLM 一次性“想完了所有步骤”。每一次工具结果都可能改变下一步判断。

这也是 Agent 与一份静态回答的关键区别：它会把行动结果作为下一轮决策的输入。

四、ChatBot、Workflow 和 Agent 怎么选

三者没有简单的“谁更先进”。选择取决于任务的确定性和风险。

类型	主要特点	适合场景	主要代价
ChatBot	一次或少量模型调用，输出文本	问答、改写、摘要	不擅长连续执行
Workflow	步骤预先定义，结果可预测	固定审批、报表生成、数据同步	灵活性有限
Agent	根据目标和中间结果选择下一步	代码排查、开放式研究、复杂协助	成本、风险和测试难度更高

如果流程非常稳定，优先使用 Workflow 往往更容易维护。只有当下一步确实需要根据结果动态选择时，才需要引入 Agent。

五、Agent 的“自主性”到底是什么

“自主”这个词很容易让人误解。工程上的自主性，通常只是：

在规定目标、工具、权限和停止条件内，系统可以选择下一步动作

它不意味着：

• Agent 了解所有背景；
• Agent 永远能做出正确判断；
• Agent 可以绕过权限；
• Agent 可以无限执行；
• Agent 不需要人类确认。

更准确地说，Agent 的自由度来自“可以选择多个允许的动作”，而不是来自没有约束。

六、Single-Agent 和 Multi-Agent

Single-Agent：一个 Agent 负责完整任务

用户目标 → 一个 Agent → 多种工具 → 最终结果

它结构简单，适合大多数入门和中等复杂度任务。工具、上下文和状态都集中管理，调试相对容易。

Multi-Agent：多个角色协作

规划 Agent → 编码 Agent → 测试 Agent → 审查 Agent

多 Agent 适合职责差异明显、任务可以并行或需要相互审查的场景，但也会增加通信成本、状态同步难度和失败排查难度。

不要因为“多 Agent”听起来更复杂，就默认它一定更强。很多任务先用一个边界清楚的 Agent 就足够了。

七、一个最小 Agent 的伪代码

下面的代码把 Agent 的职责压缩成最小形态：

async function runAgent(goal) {
  const state = {
    goal,
    context: [{ role: "user", content: goal }],
    status: "running"
  };

  while (state.status === "running") {
    const decision = await llm.decide({
      goal: state.goal,
      context: state.context,
      tools: allowedTools(state)
    });

    if (decision.type === "finish") {
      state.status = "completed";
      return decision.answer;
    }

    const result = await runtime.execute(decision.toolCall, state);
    state.context.push({ role: "tool", content: result });

    if (runtime.shouldPause(result, state)) {
      state.status = "waiting_for_approval";
    }
  }
}

这里的 llm.decide 负责做判断，runtime.execute 负责执行，state 保存过程信息。它们组合起来，才是一个可运行的 Agent。

八、常见误解

误解一：Agent 就是更聪明的 LLM

Agent 是系统形态，不是单独的模型等级。更强的模型可能提升判断质量，但没有工具、循环和运行时，依然只是一次模型调用。

误解二：有多个工具就一定是 Agent

不一定。一个 ChatBot 也可以让用户手动选择工具。Agent 的关键是围绕目标根据结果持续推进。

误解三：Agent 越自由越好

在真实系统里，权限越宽、停止条件越少，风险越大。可靠的 Agent 通常拥有明确的工具范围和可审计的行为边界。

误解四：Multi-Agent 一定优于 Single-Agent

多 Agent 能解决分工问题，也会引入通信和协调问题。先判断任务是否真的需要分工，再决定架构。

九、本文小结

ChatBot  = 主要负责回答
Workflow = 按预定义步骤执行
Agent    = 围绕目标，根据结果选择下一步行动

Agent 的核心不是人格，也不是无限自主，而是这组工程组件：

目标与约束 + LLM + Context + Tools + Loop

下一步的关键问题是：这个循环究竟如何组织？失败后怎么重试？什么时候停止？

下一篇讲什么

下一篇进入 Agent Loop，把 Agent 的连续行动拆成 Observe、Decide、Act、Result 四个阶段，并说明一个可靠循环必须具备哪些停止和恢复机制。