最近好多人在做所谓的"agent"，不管什么项目都要加个agent，显得高级，那到底什么样的才叫agent呢？接下来就来简单科普下。

一句话判据：Agent = LLM 不再是"一次性问答机"，而是一个在环境中持续运转的决策单元：能拿反馈、能改下一步、能朝着目标跑直到完成（或失败/兜底退出）。

下面列的三种形态里，只有第3种触及了Agent的门槛，但还差几块关键拼图。下面把这件事拆开讲清楚。

---

1) 先划一条硬边界：Agent vs 非Agent

你看到的系统	本质	是不是Agent
纯 LLM + prompt（单次/多轮对话）	Stateless Q&A / tool-augmented chat​	❌ 严格说不算（顶多是"增强对话"）
加记忆层（vector DB / KV记忆）	带上下文持久化​	⚠️ 仍不够——缺自主执行循环​
ReAct / 规划+工具调用	引入 action + observation 循环​	✅ 跨进Agent门槛（但仍分强弱）

真正让它"成为Agent"的三个必要条件（缺一个就退化回pipeline）：

1. Goal-driven：有一个相对明确的任务/目标，而不是等用户每句追问

2. Action interface（可执行面）：能调用工具/API/代码/文件/浏览器等改变外部状态

3. Closed-loop with feedback：

   thought → act → observe → reflect → next act … until done

很多"看起来像Agent"的产品其实只是 workflow/pipeline + LLM节点，它们稳定可靠，但控制流是写死的；Agent的卖点是控制流可由模型在运行时决定。

---

2) 一个更清晰的成熟度分层（比"三种形式"更好用）

L0 · Prompt-only / Chat

• 每次请求无状态或仅靠上下文窗口

• 没有稳定的长期目标执行循环

典型：客服话术生成、总结、翻译、Copilot补全

L1 · Memory-augmented Assistant（记忆层）

• 加了：长期记忆（向量检索 / 结构化档案）、用户画像、会话状态

• 但仍然：执行路径是人/规则编排的

典型：RAG知识库问答、"记住你上次说的"助手

L2 · Tool-augmented Actor（工具执行者）

• LLM可以选工具：search / query_DB / run_code / send_msg

• 但通常是 single-shot or fixed-turn：调用一次→拿到结果→回答

这是很多"Function Calling"系统的天花板

L3 · Agentic Loop（真正的Agent下限）✅

出现一个运行时循环：

while not done:
    action = policy(observation, memory, goal)
    observation = env.step(action)
    check termination / human_approval

代表形态：

• ReAct / CoT+act

• planner-executor

• task被拆解成子目标并逐步推进

L3的及格线特征：

• 有明确的 stop condition（完成/失败/超时/次数上限）

• 有 observation回流（不只是"假装执行成功"）

• 有 guardrails（防无限循环、权限、回滚）

L4 · Multi-Agent / Persistent Agent OS（高阶）

• 多角色协作（orchestrator / worker / critic / sandbox）

• 长时间运行（schedule、重试、学习/更新策略、版本化工具）

• 人仍然在关键决策上（approval gates）

---

3) 三种形式：差在哪里、怎么补

1）LLM + prompt

这只是一个更强的模板引擎。

要"升级为Agent"，至少要补两样东西：

• 可行动接口：函数调用/工具集 + 执行沙箱

• 循环与终止条件：别让用户靠聊天手动推进步骤

2）LLM + 经验记忆层

记忆解决的是"它知道过去"，但没解决"它自己决定接下来干什么并推进"。

记忆是Agent的燃料之一，不是Agent的充分条件。

记忆层常见该有的三件套：

• 短期：会话上下文 / scratchpad（推理草稿）

• 中长期：episodic（发生了什么事）+ semantic（学到的知识/实体）

• 程序性（可选）：成功轨迹可沉淀为 plan template / SOP

3）LLM + ReAct 自主决策

这已经踩到Agent门内了，但很多人卡在"真·闭环 vs 伪·闭环"：

伪ReAct（常见翻车）

• 模型只是"语言上描述动作"，你在外层if-else硬走流程

• observation不严谨（你拼一段文字糊弄回去）

• 没终止策略 → 打转/死循环

• 工具不可靠却没retry/backtrack → 幻觉式报成功

真Agent（至少要做到）

目标输入
│
├─ Planner/Scheduler（可选）: 拆子任务
│
├─ Loop:
│   ├─ Think（含scratchpad / 近期obs / tools schema）
│   ├─ Act（call_tool / write_code / click_browser…）
│   ├─ Exec真实环境 → 拿结构化obs（status, diff, error, return）
│   ├─ Reflect/自我纠错（parse error → 修正重试）
│   ├─ Guardrails（max_steps / budget / permission）
│
└─ Done → Commit / Report / Handoff to human

---

4) 最小可行Agent（MVA）的检查清单

一个项目想"理直气壮叫Agent"，建议你按这份清单自检：

必须

• [ ] 给定目标后能连续多步推进（不是一步ask-then-answer）

• [ ] 有明确done/fail/timeout

• [ ] 工具调用是真实执行且有返回

• [ ] observation以结构化/可校验方式回传（不是自由文本骗自己）

强建议

• [ ] sandbox / dry-run / approval（尤其写操作）

• [ ] retry + 简短反思（"刚才为什么失败→换策略"）

• [ ] trace/日志（每一步的输入输出、tool call、返回值、token cost）

---

5) 一个很实用的说法（帮你对外解释/定位产品）

• Pipeline/Workflow：流程是作者写的，LLM填空

• Agentic System：LLM影响流程走向，但仍在约束轨道里（常见最优解）

• Autonomous Agent：LLM在运行时主导控制流，面向目标自驱闭环

大多数落地项目的最优位置其实是 "Agentic System（约束型Agent）"：

给Agent权力，但用规则/权限/审批把风险框住——这比追求"完全自主"更成熟也更可持续。