知识 · 概念

1. 什么是 AI Agent?

AI Agent 是一个由 LLM 驱动决策的闭环执行系统。

它能够感知环境、选择动作、调用工具、根据执行结果持续调整，直到完成目标或满足停止条件。

实现方式上，Agent 以 LLM 为决策核心，结合工具调用、状态管理、记忆机制以及循环执行，与外部环境交互，最终完成任务。

Agent ≠ LLM
Agent ≠ Prompt
Agent ≠ 工具集合
Agent ≠ Workflow
 
# 关键：
目标 + 状态 + 模型决策 + 工具执行 + 结果反馈 + 停止条件

OpenAI 当前将 Agent 描述为能够代表用户、相对独立地完成任务，并使用 LLM 执行指令和做决策的系统，参见Agent definitions ；

Agents are applications that plan, call tools, collaborate across specialists, and keep enough state to complete multi-step work.

Google ADK 定义强调 Agent 是为了特定目标自主行动的执行单元，参见Agents；

An Agent, or LlmAgent, in Agent Development Kit (ADK) is a self-contained execution unit designed to act autonomously to achieve specific goals.

注意

行业早期概念泛化很多封装了一个 Prompt，就被称为”智能体“，是不恰当的，从系统设计的角度，这种单次调用通常是：

输入 -> LLM -> 输出
 
# 比如：
文章 -> LLM -> 摘要

比较准确的描述是：LLM 应用、Prompt Chain、AI 功能。

而典型的 Agent 通常是：

用户目标
   ↓
模型判断下一步
   ↓
选择并调用工具
   ↓
观察工具结果
   ↓
继续判断
   ↓
直到满足结束条件

能力结构

Agent
├── 模型 Decision（Model）
├── 指令
├── 工具 Tools
├── 状态 State
├── 执行循环 Loop
├── 控制与验证 Control
│
├── MCP：连接外部工具和数据的一种标准，解决：AI 应用如何用相对统一的协议连接工具和数据源。
└── A2A：不同 Agent 之间通信的一种标准，
解决：分布在不同系统、由不同框架构建的 Agent，如何发现、通信和协作。
主要属于多智能体互操作层。一个单 Agent 完全不需要 A2A。

2. Agent 最基本的组成部分

最小 Agent 可以只有四个核心部分：模型、指令、工具、循环。

Agent = Model + Instructions + Tools + Loop

1. Model：决策核心

主要负责：

理解目标；
判断当前状态；
选择下一步动作；
生成工具参数；
判断是否继续；
组织最终答案；

LLM 不是 Agent，只是 Agent 内部的决策模块。

2. Instructions：行为规则

Prompt 只是 Instructions 的一种表达方式，还包括：

角色和任务范围；
可用工具说明；
操作约束；
输出格式；
成功条件；
禁止事项；
遇到异常如何处理；

比如：

修改代码后必须运行测试。
测试失败时分析错误并继续修复。
不得删除数据库或覆盖生产配置。
连续失败三次后停止并报告。

是 Agent 的运行策略。

3. Tools：行动能力

搜索网页；
查询数据库；
读取文件；
操作浏览器；
调用其他 Agent；
等等。

Tools 本质上就是 Runtime 暴露给模型的一组可执行能力。

4. Loop：执行循环

必须能够根据上一步结果决定下一步，而不只是固定执行一次。

5. State：当前任务状态

比如：

{
    "goal": "修复登录失败问题",
    "filesRead": ["auth.ts", "login.ts"],
    "filesModified": ["auth.ts"],
    "testsRun": ["auth.test.ts"],
    "currentStatus": "test_failed",
    "attemptCount": 2
}

6. Control：运行控制

包括：

最大循环次数；
超时；
Token 预算；
成本预算；
权限控制；
人工审批；
错误重试；
完成条件；
Guardrails；
日志和 tracing；

生产 Agent 中，控制层往往和模型本身同样重要。OpenAI 当前的 Agent 架构也把工具、handoff、guardrails、运行循环和 tracing 作为重要组成。

Memory、Planning、Workflow 是不是必需？

不一定。

一个最简单的 Agent：

可以没有长期记忆；
可以没有显式规划；
可以没有复杂工作流；
可以没有多个 Agent；

所以更准确的分类是：

类型	内容
核心	Model、Instructions、Tools、Loop、State、Control
可选增强	Memory、Planning、RAG、Workflow、Multi-agent、MCP、A2A

3. Agent 为什么需要工具？

工具是输入来源，也是 Agent 改变外部世界的执行接口。

读取型工具，用于获得信息，比如：搜索网页、读取文件等等，用来感知环境；

操作性工具，改变外部状态，比如：修改文件、执行命令、提交代码、重启服务等等，用来做用于环境；

LLM 生成的是决策或动作请求；
工具运行时才真正产生外部效果；

比如，LLM 输出：

{
    "tool": "run_shell",
    "arguments": {
        "command": "pnpm test"
    }
}

本身不会运行任何测试，必须由 Agent 的 Runtime 执行工具，才能真正运行测试。

解析模型输出；
检查工具是否合法；
校验参数；
执行 pnpm test；
收集 stdout、stderr 和退出码；
将结果重新传给模型。

就是：模型负责决定，Runtime 负责执行。

4. Agent 是怎样调用工具的？

用户目标
↓
系统把工具定义提供给模型
↓
模型决定是否使用工具
↓
模型生成结构化工具调用请求
↓
Agent Runtime 校验参数
↓
Runtime 真正执行工具
↓
工具返回结果
↓
结果加入上下文
↓
模型判断下一步

比如，用户说：“查看服务器日志，找出最近一次数据库连接失败的原因。”

模型看到工具定义：

{
    "name": "read_server_log",
    "description": "读取指定服务的服务器日志",
    "parameters": {
        "service": "string",
        "lines": "number",
        "keyword": "string"
    }
}

LLM 可能生成

{
    "name": "read_server_log",
    "arguments": {
        "service": "api-server",
        "lines": 500,
        "keyword": "database"
    }
}

假如 Runtime 执行后返回：

connection refused 10.0.0.8:5432

LLM 继续判断：

目前只知道连接被拒绝，还不能确认是数据库停止、端口错误还是网络问题。

于是继续调用：

check_port
check_process
read_database_log

最后才形成结论。所以，工具调用不：

调用工具 -> 直接回答

而是：

调用工具 -> 观察结果 -> 判断证据是否充分 -> 决定继续还是结束。

LLM 决定做什么，Runtime 决定能不能做，并真正执行。

5. 什么是 Agent Loop？

ReAct：Reasoning + Acting

经典的概念是：让模型在推理和行动之间交替：

Thought → Action → Observation

工程化的表达是：

目标
 ↓
读取当前状态
 ↓
模型决定下一步
 ↓
调用工具
 ↓
观察结果
 ↓
更新状态
 ↓
判断是否完成
 ├── 否：继续循环
 └── 是：输出结果

伪代码：

while not finished:
    decision = model.run(
        goal=goal,
        state=state,
        available_tools=tools,
    )
 
    if decision.type == "tool_call":
        result = execute_tool(decision.tool, decision.arguments)
        state.add_observation(result)
 
    elif decision.type == "final_answer":
        finished = True

OpenAI Agents SDK 中的 runner 就负责这样的 tool loop，并在任务完成、发生 handoff 或需要人工批准时停止或暂停。

通常复杂的任务无法一次完成，每一步都会产生之前未知的新信息，需要反复调用工具、更新状态，直到满足结束条件。

Agent Loop 必须包含停止条件，比如：

任务成功
无可执行动作
需要用户补充信息
达到最大循环次数
超过时间或成本预算
触发安全限制
工具连续失败
需要人工审批

没有停止机制，Agent 可能：

无限重试
重复读取同一文件
反复修改代码
不断消耗 Token
在错误方向上持续行动

6. Workflow 和 Agent 的区别

LangChain 的定义是：

Workflow 的执行路径主要由代码预先规定； Agent 的执行路径主要由模型根据当前状态动态决定。

Workflow 的路径由开发者决定，即使每一步调用了 LLM，仍然是 Workflow，模型只负责节点内部的内容生成，不负责整体路径。

Workflow 追求的是确定性。 Agent 更强调自主决策。

二者不是完全对立，通常是：

Workflow 外壳 + Agent 节点。 Agent 外层决策 + 确定性工具内部流程

7. Memory 到底是什么？

1. Context：本次模型调用能看到的内容

例如：

system prompt
当前对话
工具定义
刚刚读取的文件
工具返回结果
检索到的文档片段

Context 是：当前这一次推理时，放进模型上下文窗口的内容，它不一定被持久保存。

Memory 不等于 Context。Memory 只是 Context 的一个来源。Context 是当前模型真正看到的全部内容。

2. State：当前任务正在发生什么

为了让任务继续运行而维护的动态状态。

Google ADK 将 session state 描述为单次交互或会话中的 scratchpad，用于保存当前过程中不断变化的信息。

3. Short-term Memory：当前会话记忆

例如：

用户刚刚说了什么
当前任务目标
前几次工具执行结果
已经尝试过哪些方案

通常与：

conversation history
session
checkpoint
state

紧密相关。

Google ADK 中，Session 用来跟踪一条具体会话线程，使 Agent 不必每轮都从零开始。

4. Long-term Memory：跨会话保留的信息

例如：

用户习惯使用 pnpm
项目使用 Next.js 静态导出
用户不希望自动执行生产部署
上一次任务的最终结论
某项目长期存在的架构约束

这些内容跨任务、跨会话仍然有效。

5. Knowledge：外部知识

例如：

技术文档
企业知识库
产品手册
数据库记录
GitHub 仓库代码

这些通常不应全部叫 Memory。

更准确地说：

Memory：系统为后续交互保留的经验或用户信息。
Knowledge 通常不是直接放进模型上下文，需要经过 Retrieval 后，才会变成当前 Context。

内容	更准确的类别
当前对话刚说过的内容	Context / Short-term Memory
用户长期偏好	Long-term Memory
Agent 上一次执行结果	Task State 或 Episodic Memory
数据库里的历史记录	可能是 Knowledge，也可能是 Memory
从文档搜索出来的内容	Retrieved Context / Knowledge，不一定是 Memory

关键：这个信息在系统中承担什么作用。

8. RAG 和 Agent 的关系

传统 RAG 的检索过程通常由系统预先控制，而不是模型自主决定。

用户问题
→ 固定执行向量检索
→ 返回相关片段
→ 将片段放入 Prompt
→ LLM 回答

Agentic RAG 则是：模型可以自主决定：

是否需要检索
搜索哪个知识库
使用什么关键词
是否修改查询
是否继续搜索
是否交叉验证多个来源

RAG 是一种知识获取机制，Agent 是一种决策和执行架构，二者不是同一级别的概念，Agent 可以使用 RAG，但 Agent 不等于 RAG；RAG 也不一定是 Agent。

9. Agent 为什么会失败？

Agent 失败不是简单的“模型推理不够好”或“工具失败”，是一个系统性问题。

目标理解错误，Goal ambiguity，Task misinterpretation；
上下文不足或错误，Agent 的质量高度依赖被送入模型的上下文；上下文是有限资源，需要筛选和管理；
工具选择错误；
工具调用失败，不能只判断“工具被调用了”，还需要判断“工具是否真正成功”；
推理或规划错误；
状态管理错误；
循环控制错误；
验证机制缺失；
权限和安全设计不足；

10. Done Criteria（完成条件）

完成不由 Agent 的语言声明决定，而由可验证的成功条件决定。

例如：修复登录功能。

这个目标太模糊，更好的完成条件：

1. 用户使用正确账号密码可以登录；
2. 错误密码返回 401；
3. 现有鉴权测试全部通过；
4. 项目构建成功；
5. 不修改无关文件；
6. 不改变现有 Token 数据结构。

然后把条件转成可验证证据：

成功条件	验证方法
正确密码可登录	集成测试
错误密码返回 401	API 测试
没破坏已有功能	回归测试
项目可编译	build
无无关修改	git diff
页面表现正常	浏览器操作或截图

由三方共同决定是否完成任务。

用户，决定业务目标：

最终要解决什么问题？
哪些行为算成功？
哪些结果不可接受？

开发者或系统设计者，把业务目标转成可执行规则：

需要跑哪些测试？
什么退出码算成功？
哪些操作需要审批？
最多允许尝试几次？

Agent，在运行过程中补充局部验证：

是否还需要检查某个边界条件？
是否发现新的风险？
是否需要增加额外测试？

11. Runtime

LLM 不会直接执行任何事情。真正执行工具的是 Runtime，比如：

暴露工具
校验参数
执行工具
获取结果
更新 State
控制 Loop
超时
权限
Guardrails
Retry
Checkpoint

LLM 决策，Runtime 执行。

12. Agent 的执行生命周期

Goal
↓
Plan
↓
Observe
↓
Think
↓
Act
↓
Update State
↓
Evaluate
↓
Finish