Agentic AI 01: Introduction and Basics
Agentic AI = LLM + Tools + Memory + Planning + Control Loop
TLDR
Agentic AI 不是简单的“LLM 调用工具”，而是一类能围绕目标持续做决策、执行动作、观察结果并调整下一步的系统。
它的核心不在于模型说得像不像人，而在于系统是否具备：
- 明确的目标表示
- 可调用的外部工具
- 对环境反馈的观察能力
- 多步任务规划与状态管理
- 必要的人类确认、权限边界和失败恢复机制
如果一个系统只能回答一次问题，它更像 Chatbot。如果它能把任务拆开、选择工具、执行动作、检查结果并继续推进，它才开始接近 Agentic AI。
Chatbot 的核心是生成答案；Agent 的核心是推进任务。
为什么会有 Agentic AI
早期 LLM 应用主要围绕“问答”展开：用户输入问题，模型返回一段文本。这种模式适合解释概念、总结材料、生成草稿，但一旦任务需要跨多个步骤推进，问题就暴露出来了。
比如：
- 读取一份 PDF，提取关键指标
- 查询数据库，补充历史数据
- 调用搜索工具，验证外部信息
- 根据规则生成报告
- 如果缺少字段，继续追问或回退
这些任务不是一次文本生成能完成的。它们需要模型在多个步骤之间保持状态，并根据中间结果决定下一步做什么。
Agentic AI 试图解决的就是这个问题：让 LLM 从“文本生成器”变成“任务执行系统中的决策核心”。
Agentic AI 和普通 LLM 应用的区别
可以把常见 LLM 应用分成几个层级。
| 类型 | 主要能力 | 典型形态 | 局限 |
|---|---|---|---|
| Chatbot | 对话与生成 | 问答助手、写作助手 | 通常是单轮或短上下文 |
| RAG | 检索增强生成 | 知识库问答、文档问答 | 检索后仍主要生成答案 |
| Workflow | 固定流程编排 | 表单处理、报告生成 | 路径通常由开发者预设 |
| Agent | 动态决策与执行 | 研究助手、代码助手、自动化任务系统 | 更难评估和约束 |
RAG 不等于 Agent。Workflow 也不等于 Agent。
RAG 主要解决“模型不知道外部知识”的问题。Workflow 主要解决“任务流程可以被固定编排”的问题。而 Agent 更进一步，它允许模型在运行时决定下一步动作。
如果任务路径稳定、规则清晰、失败代价高，优先用确定性的 Workflow。Agent 适合路径不完全确定、需要根据中间结果调整策略的任务。
一个 Agent 系统的基本组成
一个最小可用的 Agent 系统通常包含五个部分。
1. Model
模型负责理解目标、生成计划、选择动作、解释观察结果。
这里的模型不一定必须是所谓的 LAM。实际工程里，更常见的是使用具备 tool calling / function calling 能力的 LLM，再通过外部系统约束它的输出格式和执行边界。
模型的作用可以理解为：
- 判断当前状态
- 选择下一步动作
- 为工具调用生成参数
- 解释工具返回结果
- 在失败时尝试修正
2. Tools
工具是 Agent 影响外部世界的接口。
常见工具包括：
- 搜索引擎
- 数据库查询
- 文件读写
- PDF 解析
- 代码执行器
- API 调用
- 浏览器自动化
- 消息发送或工单系统
工具越强，Agent 的行动能力越强，同时风险也越高。因此工具接口需要有清晰的 schema、权限边界和失败返回。
3. Memory
Memory 不是简单地把所有历史对话塞进上下文。
更合理的 memory 至少分成几类：
- 短期状态：当前任务进度、中间变量、已完成步骤
- 长期记忆：用户偏好、历史结论、可复用经验
- 外部知识：文档库、数据库、日志、项目材料
实际系统里，很多所谓 memory 其实应该放进结构化状态或数据库，而不是全部交给 prompt。
4. Planning
Planning 负责把目标拆成可执行步骤。
常见方式有两种：
- 一次性计划：先生成完整 plan，再逐步执行
- 边执行边规划：每一步观察结果后再决定下一步
第一种更可控，适合流程比较明确的任务。第二种更灵活，适合探索性任务，但也更容易发散。
5. Control Loop
Control loop 是 Agent 和普通 tool calling 的关键区别。
一个典型循环是：
Goal
-> Plan
-> Act
-> Observe
-> Reflect / Update State
-> Act again
-> ...
-> Final Answer / Final Artifact只要系统允许模型根据观察结果继续选择动作，就需要控制循环。
这也是 Agent 工程里最容易出问题的地方：循环可能跑偏、重复、过度调用工具，或者在错误观察上继续推理。
一个极简 Agent 伪代码
可以用下面的伪代码理解 Agent 的基本结构：
state = {
"goal": user_goal,
"steps": [],
"observations": [],
}
while not done(state):
action = model.decide_next_action(state, tools)
if action.requires_human_approval:
approval = request_approval(action)
if not approval:
break
observation = execute_tool(action)
state["steps"].append(action)
state["observations"].append(observation)
state = model.update_state(state)
result = model.summarize_final_result(state)这个结构看起来简单，但工程难点都藏在细节里：
done(state)怎么判断？action的 schema 是否足够严格？- tool 调用失败怎么恢复？
- 哪些动作需要人类确认？
- 中间状态如何持久化？
- 怎么评估 Agent 是否真的完成任务？
Agentic AI 的常见架构模式
ReAct
ReAct 的核心是让模型交替产生 reasoning 和 action：
Thought: 我需要查询项目预算信息
Action: search_database(...)
Observation: 找到了 3 条记录
Thought: 还缺少项目负责人信息
Action: read_document(...)这种模式直观，适合教学和原型。但在生产系统里，通常不希望模型自由输出任意格式的 Thought 和 Action，而是通过结构化 tool calling 限制动作空间。
Plan-and-Execute
Plan-and-Execute 先生成计划，再交给执行器逐步完成。
优点是更可控，容易展示任务进度。缺点是初始计划可能不可靠，中途遇到新信息时需要 replanning。
Multi-Agent
Multi-Agent 把复杂任务分配给多个角色，例如：
- Researcher 负责收集信息
- Analyst 负责分析
- Writer 负责生成报告
- Reviewer 负责检查结果
这种方式适合复杂任务和协作式产品体验，但不应该默认使用。多个 Agent 会带来额外通信成本、状态同步成本和错误传播问题。
先做 single-agent + deterministic workflow。只有当任务天然需要多角色协作，或者需要并行探索时，再考虑 multi-agent。
判断一个场景是否适合 Agent
可以用几个问题快速判断：
- 任务是否需要多步执行？
- 每一步是否依赖上一步结果？
- 下一步路径是否无法完全预先写死？
- 是否需要调用外部工具或读写外部状态？
- 错误成本是否可以通过权限和确认机制控制？
如果前四个问题大多是“是”，而第五个问题也能被控制，那么这个场景比较适合 Agent。
反过来，如果任务只是“根据固定模板处理固定输入”，Agent 可能会增加不必要的不确定性。
工程落地时最重要的边界
Agentic AI 最吸引人的地方是自动性，最危险的地方也是自动性。
实际落地时，我认为至少要注意这些边界：
- 高风险动作必须有确认，例如发送邮件、提交表单、删除数据、触发支付
- 工具调用要有权限分级，不要把所有能力暴露给同一个 Agent
- 状态要可追踪，最好能回放每一步决策和观察
- 输出要可验证，尤其是涉及数据分析和业务判断时
- 循环要有预算，包括最大步数、最大 token、最大工具调用次数
- 失败要能降级，不能让 Agent 在错误状态里无限尝试
这些约束听起来不够“智能”，但它们决定了 Agent 系统是否能从 demo 走向可用产品。
小结
Agentic AI 可以理解为一种围绕 LLM 构建的任务执行系统。LLM 是决策核心，但真正决定系统能力上限的是工具、状态、流程控制和安全边界。
我现在对 Agentic AI 的理解是：
Agent 不是会聊天的模型，而是一个能在受控环境中持续推进目标的系统。
后续我会继续整理几个方向：
- Tool calling 的接口设计
- LangGraph 这类状态机式 Agent 框架
- RAG 和 Agent 的组合方式
- Multi-Agent 协作系统的产品形态
- Agent 评估与可观测性