Agent 的第一性原理：从概念到范式演进
Agent 的第一性原理：从概念到范式演进
一、为什么要从第一性原理理解 Agent
过去几年，Agent 这个词被大量使用：AI Agent、LLM Agent、AutoGPT、Multi-Agent、GUI Agent、Coding Agent、Personal Agent、Workflow Agent。概念越热，越容易被泛化成一句话：只要大模型能调用工具，就是 Agent。
这个说法太粗糙。
如果从第一性原理出发，Agent 不是某个框架、某种 Prompt 写法，也不是“模型 + 工具调用”的简单拼装。Agent 的底层问题是：
一个系统如何在环境中围绕目标持续感知、决策、行动、反馈，并在边界内调整自己的行为？
这句话里有五个不能再拆的基本元素：
| 第一性元素 | 核心问题 | 工程含义 |
|---|---|---|
| 目标 | 系统要完成什么 | 任务定义、成功标准、停止条件 |
| 环境 | 系统面对什么世界 | 外部信息、工具结果、用户约束、运行状态 |
| 决策 | 下一步该做什么 | 推理、规划、工具选择、重规划 |
| 行动 | 如何影响环境 | API、文件、代码、浏览器、数据库、消息系统 |
| 反馈 | 怎么知道做得对不对 | 验证、观测、错误处理、人工确认 |
所以，Agent 的最小定义可以写成：
Agent 是一个在给定边界内，为了完成目标而自主规划、调用工具、执行动作、检查结果并持续调整的系统。
更工程化地说：
Agent = 目标 + 状态 + 计划 + 工具 + 执行 + 验证 + 权限 + 记忆 + 观测
这个定义有意把“模型”放在组件层，而不是本体层。因为模型只是 Agent 的认知核心，Agent 真正成立依赖的是一个闭环系统。
二、Agent 的第一性结构：目标闭环
一个 Agent 的最小闭环可以概括为：
目标 -> 上下文 -> 计划 -> 工具 -> 执行 -> 反馈 -> 状态更新 -> 输出或继续
如果执行结果不满足目标，就进入下一轮：
反馈 -> 调整计划 -> 再次执行 -> 再次验证
这就是 Agent 与普通问答系统的根本区别。普通聊天系统通常是一次性生成：用户输入，模型输出。Agent 则是一个带状态的任务推进系统：它会把目标拆成步骤，选择动作，读取结果，更新状态，再决定是否继续。
可以把最小闭环拆成六个动作：
| 动作 | 说明 | 失败时会发生什么 |
|---|---|---|
| Observe | 观察上下文、环境和工具结果 | 信息不足，需要询问或检索 |
| Orient | 理解目标、约束和当前状态 | 误解目标，后续计划会偏航 |
| Plan | 形成下一步或多步计划 | 步骤过大、顺序错误、遗漏验证 |
| Act | 调用工具或执行动作 | 参数错误、权限不足、工具失败 |
| Verify | 检查结果是否达标 | 输出看似完成但不可用 |
| Update | 记录进度、经验和状态 | 无法连续推进或复盘 |
从这个角度看，Agent 不是“更会聊天的模型”，而是“用模型驱动的闭环控制系统”。它既继承了控制论中“反馈调节”的思想，也继承了人工智能中“感知-规划-行动”的传统。
三、Agent 的范式演进：从符号系统到 LLM
Agent 并不是大模型时代才出现的概念。它在人工智能史中一直存在，只是过去长期停留在研究系统、规则系统或特定环境中。LLM 的出现，让 Agent 从“可定义”走向“可泛化使用”。
3.1 符号主义时代：智能是规则推理
早期人工智能深受数理逻辑、形式语言和计算机科学影响。研究者相信，只要能把世界知识写成符号规则，再配合推理机，就能得到智能行为。
这一阶段的典型思想是：
智能 = 符号表示 + 逻辑推理 + 搜索规划
代表形态包括：
- 通用问题求解器，把问题看作状态空间搜索。
- 专家系统，把领域知识写成产生式规则。
- 早期机器人系统，把感知、规划和动作串成流水线。
- 棋类程序，把规则、评估函数和搜索结合起来。
这一阶段的贡献很大：它确立了“Agent 可以被形式化”的基本框架，即一个系统可以拥有状态、目标、规则和动作，并通过推理选择行为。
但它的根本限制也很明显：
| 限制 | 表现 |
|---|---|
| 知识获取瓶颈 | 大量知识需要专家手工编码 |
| 环境脆弱 | 规则外的情况很难处理 |
| 语义贫乏 | 符号能推理，但不自然理解语言和常识 |
| 泛化不足 | 换一个任务或领域就要重新建模 |
符号系统的 Agent 很像一个严谨但僵硬的官僚系统：在规则覆盖范围内表现稳定，一旦遇到开放世界问题，就会暴露“不会理解，只会匹配”的缺陷。
3.2 反应式与行为主义：智能来自环境耦合
符号主义的问题促使研究者转向另一种路线：智能不一定来自复杂的内在推理，也可以来自系统与环境的实时耦合。
反应式 Agent 更强调：
感知到刺激 -> 触发行为 -> 环境变化 -> 继续反应
这种范式减少了对完整世界模型的依赖，更适合机器人、控制系统和实时场景。它的优势是快速、鲁棒、工程上可落地；缺点是缺少长期目标、抽象规划和复杂推理能力。
这条路线提醒我们：Agent 不是只有“大脑”，还必须有感知、行动和反馈。没有与环境互动的能力，再强的推理也只是离线计算。
3.3 强化学习时代：智能来自试错和奖励
强化学习把 Agent 建模为一个在环境中行动并最大化累计奖励的系统：
状态 -> 动作 -> 奖励 -> 新状态 -> 策略更新
它给 Agent 带来了一个非常清晰的数学框架：MDP、策略、价值函数、探索与利用。游戏、机器人控制、推荐系统、资源调度等场景都可以在这个框架下表达。
强化学习的贡献在于，它让 Agent 不再完全依赖人类写规则，而是可以从交互经验中学习策略。
但强化学习也有自己的瓶颈：
| 问题 | 说明 |
|---|---|
| 奖励设计困难 | 很多真实任务难以定义明确奖励 |
| 样本效率低 | 需要大量交互和试错 |
| 泛化有限 | 在特定环境中学到的策略很难迁移 |
| 语言能力弱 | 难以处理开放自然语言目标 |
强化学习解释了“如何通过反馈学习行动”，但没有解决“如何理解开放任务、常识和人类意图”。
3.4 传统自动化与工作流时代：智能被压缩进流程
在企业软件和业务系统中，Agent 的许多需求长期由脚本、工作流引擎、RPA、低代码平台承担。
它们的共同特点是：
把任务路径提前确定下来，再由机器稳定执行
这类系统非常有价值。定时任务、ETL、审批流、报表生成、表单录入，都不需要 Agent。一个稳定脚本往往比一个“聪明”的 Agent 更便宜、更可靠、更容易审计。
但自动化系统也有边界：
- 输入必须高度结构化。
- 路径必须提前设计好。
- 异常通常需要人工处理。
- UI 或接口变化会导致失败。
- 不擅长理解模糊自然语言目标。
- 不擅长跨源整合信息并形成判断。
所以传统自动化解决的是“已知流程的执行问题”，而 Agent 要解决的是“开放目标下的决策执行问题”。
3.5 LLM 时代：语言模型成为通用认知引擎
大语言模型改变了 Agent 的关键前提。
在 LLM 之前，Agent 最大的问题是认知层不够通用：符号系统需要手工规则，强化学习需要环境和奖励，工作流需要提前编排。它们都很难直接理解一句自然语言目标：
帮我分析这个产品最近用户流失的原因，并给出三个优先级最高的改进建议。
LLM 的出现提供了一个新的认知引擎。它具备几类以前分散在不同系统里的能力：
| 能力 | 对 Agent 的意义 |
|---|---|
| 自然语言理解 | 可以接收模糊目标，而不只接收结构化指令 |
| 常识与领域知识 | 可以在缺少显式规则时做初步判断 |
| 任务分解 | 可以把复杂目标拆成子任务 |
| 代码与工具理解 | 可以生成参数、解释错误、选择工具 |
| 多轮上下文推理 | 可以维护任务过程中的局部状态 |
| 反思与改写 | 可以基于反馈修正计划和输出 |
因此，大模型让 Agent 从“专用系统”转向“通用任务接口”。这就是 LLM Agent 成立的核心历史原因。
四、LLM Agent 为什么成立
LLM Agent 不是因为大模型“像人”，而是因为它补上了 Agent 闭环中长期缺失的通用认知层。
4.1 LLM 是认知引擎，不是完整 Agent
LLM 本身更接近一个函数：
f(上下文) -> 下一个文本片段或动作意图
它可以理解、推理、生成计划、构造工具参数，但它自己并不会真正行动，也不会天然拥有长期状态、权限边界、成本预算、验证机制。
所以更准确的关系是：
LLM 提供认知能力
Agent 系统提供目标闭环
工具提供外部行动能力
记忆提供状态延续能力
权限和验证提供可靠边界
如果只有 LLM，没有工具，它是聊天模型。
如果只有 LLM 和工具，没有目标、状态、验证、权限，它只是工具增强助手。
如果一个系统能围绕目标自主推进任务、调用工具、根据反馈修正，并在风险边界内停下或请求确认，它才更接近 Agent。
4.2 Tool Calling 把语言意图转成外部动作
LLM 的输出默认是文本。工具调用把文本意图转换成结构化动作：
{
"tool": "search_public_web",
"arguments": {
"query": "LLM Agent planning memory tool use survey"
}
}
这一步非常关键。它让模型不再只是“说”，而是可以“查、算、写、读、跑、改、发起请求”。工具是 Agent 的手和眼睛。
但工具越强，风险越高。因此工具系统必须有：
- schema，限制参数结构。
- 权限，限制能做什么。
- 超时和重试，限制成本。
- 副作用标记，区分只读、写入、删除、外发。
- 执行日志，支持追踪和复盘。
没有这些工程边界，Agent 会从“能行动”变成“不可控地行动”。
4.3 上下文与记忆让任务可以连续推进
Agent 必须知道自己现在在哪里：
- 用户目标是什么。
- 已经做过哪些步骤。
- 工具返回了什么。
- 哪些假设被验证或推翻。
- 还有哪些待办事项。
- 当前预算和风险状态如何。
这就是状态管理。
如果说工具让 Agent 能影响外部世界，那么记忆让 Agent 能把多轮行动组织成连续任务。它解决的不是“模型能不能记住聊天记录”，而是三个更工程化的问题：
当前正在做什么？
过去有哪些信息对现在仍然有用？
哪些新信息值得沉淀给未来使用？
因此，Agent 记忆不是单纯的“把聊天记录存起来”，而是一套围绕任务连续性、个性化和可靠性设计的工程系统。
最基础的分层是：
| 记忆类型 | 负责什么 | 典型内容 | 生命周期 |
|---|---|---|---|
| 短期记忆 | 当前正在做什么 | 当前目标、对话上下文、工具结果、计划、待办 | 当前任务或会话 |
| 长期记忆 | 过去哪些信息可复用 | 用户偏好、项目事实、历史决策、经验教训 | 跨会话保存 |
| 记忆调度器 | 什么时候查、什么时候写、怎么注入 | 检索触发、排序、压缩、冲突处理 | 贯穿任务执行 |
短期状态支撑当前任务，长期记忆支撑跨任务复用。一个没有状态的系统只能响应单轮输入；一个有状态的系统才能持续推进目标。
但记忆不是越多越好。值得进入长期记忆的信息通常要满足三个条件：
稳定、明确、未来会复用
真正可用的记忆系统，不是“记得越多越好”，而是：
该记的记，该忘的忘，该查的时候查，查到后谨慎使用。
这要求记忆系统同时设计读路径和写路径：
用户输入
-> 更新短期记忆
-> 判断是否检索长期记忆
-> 召回、排序、过滤相关记忆
-> 注入当前上下文
-> 生成回答或执行动作
-> 提取值得保存的信息
-> 去重、冲突检查、写入长期记忆
错误记忆会污染后续行为，敏感记忆会带来隐私和安全风险。因此记忆系统需要来源、时间、置信度、作用域、过期机制和用户可治理能力。
记忆还有一个关键优先级原则：
当前用户明确指令
> 当前任务约束
> 项目级规则
> 用户长期偏好
> 历史建议或低置信记忆
也就是说，长期记忆只能辅助当前任务，不能覆盖用户此刻的明确要求。
4.4 验证机制让 Agent 从“像完成”变成“真的完成”
Agent 最大的工程陷阱是：输出看起来很完整，但没有证据表明它真的完成了任务。
可靠 Agent 至少要有三层验证：
| 层级 | 方法 | 示例 |
|---|---|---|
| 轻量自检 | 检查格式、遗漏和约束 | 是否包含结论、依据、风险 |
| 工具校验 | 用程序或数据源验证 | 复算数字、运行测试、检查文件 |
| 人工复核 | 高风险或低置信度时确认 | 发邮件前预览、改生产库前审批 |
验证机制是 LLM Agent 与“会编理由的自动补全文本”之间的重要分界线。
4.5 权限边界让自主性可用
Agent 的价值来自自主性，但风险也来自自主性。
一个成熟 Agent 不是“能自动做一切”，而是知道哪些动作可以自动执行，哪些动作需要确认，哪些动作默认禁止。
| 动作类型 | 示例 | 策略 |
|---|---|---|
| 低风险只读 | 搜索、读取公开文档、计算 | 可自动执行 |
| 中风险写入 | 生成文件、更新草稿、修改副本 | 可执行但保留版本 |
| 高风险外发 | 发邮件、提交表单、通知客户 | 必须确认 |
| 高风险破坏性动作 | 删除数据、付款、改生产系统 | 默认禁止或审批 |
这也是为什么 Agent 工程不能只讨论 Prompt。Prompt 决定行为倾向，系统边界决定实际风险。
五、LLM Agent 与传统自动化脚本的本质区别
最容易混淆的问题是：既然 Agent 也会调用工具、执行步骤，那它和自动化脚本有什么不同？
一句话回答：
脚本执行预先写好的路径，Agent 在目标约束下生成和调整路径。
5.1 驱动方式不同：规则驱动 vs 目标驱动
传统脚本的核心是规则：
如果 A 发生，就执行 B；如果 B 失败，就报错退出。
Agent 的核心是目标：
用户给出目标，Agent 理解约束，拆解步骤，选择工具，检查结果，必要时重规划。
脚本的智能主要来自开发者事先写好的流程；Agent 的智能主要来自模型在运行时对目标、上下文和反馈的判断。
5.2 任务形态不同：确定流程 vs 开放问题
| 任务 | 更适合脚本 | 更适合 Agent |
|---|---|---|
| 每天 9 点导出固定报表 | 是 | 否 |
| 把固定格式 CSV 入库 | 是 | 否 |
| 分析本月销售下降原因 | 否 | 是 |
| 根据多个文档生成调研报告 | 否 | 是 |
| 固定网页表单批量录入 | 是 | 视情况 |
| 页面变化后继续完成操作 | 否 | 是 |
脚本适合路径已知、输入稳定、结果可确定的任务。Agent 适合路径不完全确定、需要判断、需要整合信息、需要处理异常的任务。
5.3 错误处理不同：报错退出 vs 反馈重规划
脚本遇到异常，通常只能：
- 重试。
- 走预设分支。
- 报错退出。
- 等人修脚本。
Agent 遇到异常，可以根据反馈判断下一步：
- 换搜索关键词。
- 更换工具。
- 请求用户补充信息。
- 降级输出部分结果。
- 标注不确定性。
- 在风险点停下等待确认。
这不是说 Agent 永远更好，而是说 Agent 的错误处理空间更大。
5.4 抽象层级不同：动作自动化 vs 决策自动化
传统自动化解决“怎么执行动作”：
点击这个按钮，读取这个表，调用这个接口。
Agent 解决“为了目标接下来该做什么”：
当前信息够不够？该查什么？该用哪个工具？结果可信吗？是否该继续？
因此，二者的本质区别可以概括为：
脚本自动化动作，Agent 自动化一部分决策。
5.5 它们不是替代关系，而是能级关系
不要把 Agent 理解成脚本的替代品。更合理的关系是：
脚本：稳定执行确定动作
RPA：在图形界面中模拟固定操作
Workflow：编排已知流程
LLM Agent：在不确定路径中围绕目标决策和执行
Multi-Agent：把复杂目标拆给多个角色协作
好的 Agent 系统经常会调用脚本、RPA、API 和工作流。脚本是 Agent 的可靠工具，Agent 是脚本之上的目标决策层。
六、Agent、ChatGPT、RPA、Workflow 的位置关系
为了避免概念混乱，可以把几类系统放在同一张表里：
| 系统类型 | 输入 | 核心能力 | 是否能行动 | 是否能自我调整 | 适合场景 |
|---|---|---|---|---|---|
| 普通 ChatGPT | 问题或指令 | 回答、总结、生成文本 | 通常不能 | 弱 | 问答、写作、解释 |
| 自动化脚本 | 固定参数 | 按规则执行 | 能 | 很弱 | 定时任务、批处理 |
| RPA | UI 流程 | 模拟点击和录入 | 能 | 弱 | 固定界面操作 |
| Workflow | 流程定义 | 编排多步骤业务流程 | 能 | 中等 | 审批、工单、ETL |
| LLM Agent | 自然语言目标 | 理解、规划、工具调用、验证 | 能 | 强 | 调研、分析、编码、复杂办公 |
| Multi-Agent | 复杂目标 | 多角色分工与协作 | 能 | 强但成本高 | 软件工程、投研、复杂决策辅助 |
这张表的关键不是给概念贴标签，而是帮助判断“什么时候该用 Agent”。
如果任务高度确定，脚本和工作流更好。
如果任务需要理解自然语言、动态规划、跨源整合、异常处理、可验证输出，Agent 才有明显价值。
七、Agent 的能力等级：从 L0 到 L4
Agent 不是非黑即白，而是一条能力等级线。
L0：普通 LLM
只根据输入生成回答，不调用外部工具，不产生真实外部动作。
适合问答、总结、改写、翻译、头脑风暴。
L1：工具增强助手
可以调用工具，但通常由用户明确要求，流程较简单，状态管理较弱。
例子：
帮我搜索这家公司的官网，并总结它的产品。
L2：工作流 Agent
按照相对固定的多步骤流程完成任务，可以自动调用多个工具。
例子：
读取本周销售数据，生成周报，并输出异常地区。
L2 的重点不是完全自主，而是把一个稳定业务流程做成“模型参与的自动化”。
L3：目标型 Agent
用户只给目标，Agent 自己拆解路径，遇到失败可以重规划，需要更强的状态、验证和权限控制。
例子：
帮我分析这个产品最近用户流失的主要原因，并给出优先级最高的三个改进建议。
L3 是多数人讨论的“真正 Agent”的核心层级。
L4：多 Agent 系统
多个 Agent 分角色协作，例如规划者、执行者、研究员、评审者、审计者。
多 Agent 的价值在于分工、并行、互评和专业化；代价是通信成本、协调复杂度、冲突解决难度都会上升。
新人或新项目不应默认从 L4 开始。单 Agent 的工具调用、状态管理、验证机制没有做好，多 Agent 只会把问题放大。
八、LLM Agent 的典型架构
一个实用 Agent 系统通常可以拆成以下组件：
用户目标
-> 任务解释器
-> 上下文构建器
-> 模型
-> 规划器
-> 工具注册表
-> 执行器
-> 验证器
-> 记忆系统
-> 权限与安全策略
-> 日志与监控
8.1 任务解释器
负责把用户的自然语言目标转成任务规格，包括：
- 服务对象。
- 输入和输出。
- 成功标准。
- 约束条件。
- 风险等级。
- 缺失信息。
很多 Agent 失败不是因为模型不会推理，而是任务一开始就没有定义清楚。
8.2 上下文构建器
负责决定哪些信息进入模型上下文：
- 用户目标。
- 当前计划。
- 已完成步骤。
- 工具返回摘要。
- 关键约束。
- 相关记忆。
- 错误和待解决问题。
上下文太少，模型缺信息；上下文太多，模型被噪声干扰，成本也会上升。
8.3 规划器
负责决定步骤顺序。常见模式包括：
| 模式 | 特点 | 适合场景 |
|---|---|---|
| Reactive | 每一步根据当前情况行动 | 简单工具调用 |
| Plan-and-Execute | 先制定计划，再逐步执行 | 报告、调研、分析 |
| 分层规划 | 大任务拆成多层子任务 | 软件开发、复杂项目 |
| Planner + Critic | 一个执行，一个检查 | 高准确性任务 |
| Human-in-the-Loop | 关键节点人工确认 | 高风险业务流程 |
多数项目应从 Plan-and-Execute 开始，因为它直观、可控、容易调试。
8.4 工具注册表与执行器
工具注册表回答“有哪些工具可以用”，执行器回答“如何安全地用”。
一个工具至少应该描述：
- 名称。
- 用途。
- 输入 schema。
- 返回格式。
- 是否有副作用。
- 是否需要确认。
- 超时和重试策略。
- 失败时如何返回错误。
没有工具 schema，模型很容易传错参数；没有执行器边界，模型的错误决策会直接变成外部错误动作。
8.5 验证器
验证器负责判断结果是否满足目标。验证方式可以包括：
- 格式检查。
- 数据复算。
- 代码测试。
- 多来源交叉验证。
- 事实引用检查。
- 人工复核。
一个没有验证器的 Agent，往往只能“看起来完成了任务”，但无法证明自己真的完成了任务。
8.6 记忆系统
记忆系统保存可复用信息，包括用户偏好、历史任务结果、团队术语、常用模板、已验证流程。但它的核心价值不是“存储”，而是“调度”：判断什么时候记、记什么、什么时候查、查出来怎么用。
一个可落地的 Agent 记忆系统可以拆成七个模块：
输入流
-> Memory Collector 收集对话、工具结果、任务状态
-> Memory Extractor 提取候选记忆
-> Memory Validator 去重、过滤、权限和敏感性检查
-> Memory Store 持久化存储
-> Memory Retriever 按需检索
-> Memory Ranker 相关性、时效性、置信度排序
-> Memory Injector 把记忆压缩成可用上下文
-> Agent Response/Action 生成回答或执行动作
这套结构把记忆系统拆成两条路径：
| 路径 | 目标 | 关键问题 |
|---|---|---|
| 写路径 | 从当前交互中沉淀未来可复用信息 | 是否稳定、是否有价值、是否敏感、是否冲突 |
| 读路径 | 从历史记忆中召回当前任务需要的信息 | 是否需要查、查多少、怎么排序、如何压缩注入 |
写入长期记忆前，可以问五个问题：
- 未来是否会复用？
- 是否足够稳定？
- 是否与用户、项目、任务或领域有关？
- 是否已经存在同类记忆？
- 是否涉及隐私、敏感信息或用户不希望保存的内容？
读取长期记忆时，不应每轮全量检索，也不应把 Top-K 原文直接塞进上下文。更稳妥的方式是先用低成本信号触发检索，再把结果整理成短小、可审计的记忆卡片：
相关记忆：
1. [用户偏好][高置信] 用户希望技术文档多用实例，不要只讲概念。
2. [项目事实][中置信] 当前项目文档多采用“章节标题 + 表格 + 示例”的中文教程风格。
3. [历史决策][高置信] 本次任务目标是把 Agent 资料整理成完整知识体系。
使用要求：
- 只使用与当前任务直接相关的记忆。
- 如果记忆与用户当前明确要求冲突，以当前要求为准。
这样做的本质是把长期历史压缩成当前任务可用的约束，而不是让模型在大量原始聊天记录里自行打捞重点。
记忆要可治理：
- 有来源。
- 有时间。
- 有置信度。
- 有作用域。
- 可查看。
- 可修改。
- 可删除。
- 可过期。
- 避免保存敏感信息。
一个稳妥的第一版不必一开始上复杂知识图谱，可以从最小闭环开始：
会话摘要 + 用户偏好 JSON + 项目记忆 Markdown + 向量摘要检索 + 记忆卡片注入
等读写策略、评估指标和冲突治理跑稳后，再扩展到主动预取、多级缓存、知识图谱和元记忆体系。
8.7 权限、安全与观测
越能行动的 Agent，越需要刹车。
安全系统要处理：
- 工具权限。
- 敏感数据。
- 提示注入。
- 高风险动作确认。
- 成本预算。
- 步数限制。
- 异常告警。
- 审计日志。
观测系统要回答：
- Agent 为什么这么做？
- 调用了哪些工具？
- 哪一步失败？
- 成本是多少？
- 延迟是多少？
- 输出有没有通过验证？
没有观测，就没有可调试性；没有权限，就没有生产可用性。
九、从 Prompt 到 Agent：范式层级的变化
LLM 应用的发展路径大致可以看成：
Prompt -> Prompt Chain -> Workflow -> Agent -> Multi-Agent
9.1 Prompt：一次性生成
Prompt 是最小交互单元。用户给指令，模型给回答。它适合单步任务，但不适合长任务推进。
9.2 Prompt Chain：把复杂任务拆成固定链路
Prompt Chain 把任务拆成多个模型调用：
提取信息 -> 总结 -> 分类 -> 生成报告
它比单 Prompt 更稳定，但路径仍然是预设的。
9.3 Workflow：把模型放进业务流程
Workflow 进一步加入工具、条件分支、人工节点和业务系统。它适合企业流程，但自主性仍然有限。
9.4 Agent：运行时决策
Agent 的关键变化是：
下一步不是完全由开发者提前写死，而是由系统基于目标、上下文和反馈动态决定。
这并不意味着完全放手。高质量 Agent 是“有限自主”，不是“无限自主”。
9.5 Multi-Agent：复杂任务的组织形态
Multi-Agent 不是为了显得高级，而是为了解决单个 Agent 难以同时承担的角色冲突：
- 研究者负责收集资料。
- 分析者负责建模和推理。
- 执行者负责调用工具。
- 评审者负责验证和挑错。
- 协调者负责分配任务和合并结果。
当任务确实需要角色分工、并行处理或交叉验证时，多 Agent 才有价值。
十、Agent 的边界：什么场景不该用 Agent
理解 Agent 的价值，也要理解它的边界。
以下场景不适合优先使用 Agent：
| 场景 | 原因 | 更合适方案 |
|---|---|---|
| 输入输出完全确定 | Agent 成本高且不稳定 | 脚本、函数、SQL |
| 流程长期稳定 | 不需要运行时决策 | Workflow、RPA |
| 高并发低延迟 | LLM 成本和延迟较高 | 规则系统、缓存、模型蒸馏 |
| 强一致性事务 | Agent 决策不适合作为最终执行者 | 业务规则引擎 |
| 不可逆高风险动作 | 错误代价太高 | 人工审批、权限系统 |
| 缺少验证标准 | 无法判断是否完成 | 先定义验收标准 |
Agent 的正确位置不是替代所有自动化，而是补上“开放目标、动态路径、复杂判断”这一层。
十一、Agent 的核心矛盾：自主性与可控性
Agent 技术的主线可以概括为一个矛盾：
越自主，越有价值；越自主，越需要可控。
自主性带来效率：
- 可以少问用户。
- 可以连续推进任务。
- 可以处理异常。
- 可以跨工具整合结果。
可控性保证可靠：
- 明确目标。
- 明确权限。
- 明确预算。
- 明确停止条件。
- 明确验证方式。
- 明确人工确认点。
真正成熟的 Agent 不是“完全自主”，而是在边界内自主，在高风险处停下，在不确定时求证。
这也是 Agent 工程的核心判断：
把确定的部分交给规则，把开放的部分交给模型，把高风险的部分交给人类确认。
十二、未来趋势：Agent 会走向哪里
LLM Agent 仍处在早期阶段，但方向已经比较清晰。
12.1 从聊天入口走向任务入口
未来的 Agent 不只是聊天窗口，而会成为任务入口。用户不再逐步操作软件，而是描述目标，由 Agent 调动软件、文件、知识库和业务系统完成任务。
12.2 从工具调用走向环境操作
工具调用会继续扩展：
- Web Agent 操作网页。
- GUI Agent 操作桌面和手机。
- Coding Agent 操作代码库和终端。
- Data Agent 操作数据库和表格。
- Enterprise Agent 操作内部系统。
工具越接近真实环境，权限、审计、验证就越重要。
12.3 从单次任务走向长期记忆
短期 Agent 完成一次任务，长期 Agent 理解用户、组织和项目的历史。长期记忆会让 Agent 更有用，也会让治理问题更重要。
未来可用的记忆系统不只是“保存更多内容”，而是要能判断什么值得记、什么时候过期、如何纠错、如何让用户控制。
这会推动 Agent 从“会话内智能”走向“关系型智能”：它不只是理解当前输入，还能理解用户长期偏好、项目演进历史、组织知识和已验证经验。但这类能力必须建立在治理之上，否则长期记忆会快速变成错误长期保存系统。
因此，记忆系统会成为 Agent 平台的重要基础设施。它至少需要同时优化五个指标：
| 指标 | 核心问题 |
|---|---|
| 召回率 | 该查的有没有查到 |
| 精确率 | 查到的是不是相关 |
| 新鲜度 | 是否用了过时信息 |
| 隐私合规 | 是否保存或注入了不该保存的信息 |
| 成本与延迟 | 检索和注入是否过重 |
长期来看，优秀 Agent 的记忆能力不会表现为“什么都知道”，而会表现为“知道哪些历史信息应该影响当前决策，哪些不应该”。
12.4 从单 Agent 走向组织化协作
多 Agent 系统会从演示走向更实际的协作模式。它不是简单地让多个模型聊天，而是围绕明确角色、协议、交付物和评审机制组织任务。
12.5 从演示效果走向可评估工程
Agent 走向生产，核心指标会从“看起来聪明”转向：
- 任务完成率。
- 事实准确率。
- 工具调用成功率。
- 参数正确率。
- 验证通过率。
- 单任务成本。
- 延迟。
- 权限违规率。
- 用户满意度。
没有评估体系，Agent 很难从 Demo 变成产品。
十三、一个统一的理解框架
现在可以把全文收束成一个完整框架。
从第一性原理看：
Agent = 在环境中围绕目标形成行动闭环的系统
从工程实现看：
Agent = 目标 + 状态 + 计划 + 工具 + 执行 + 验证 + 权限 + 记忆 + 观测
从历史演进看：
符号系统解决规则推理
反应式系统解决环境耦合
强化学习解决反馈学习
自动化脚本解决确定流程执行
LLM 解决开放语言目标下的通用认知
记忆系统解决跨会话状态延续与经验复用
Agent 把这些能力重新组合成目标闭环
从与传统自动化的差异看：
脚本执行预设路径
Workflow 编排已知流程
RPA 模拟界面操作
LLM Agent 在目标约束下动态决策和执行
从产品落地看：
能自动做事不是终点
能在边界内稳定完成任务才是终点
结语
Agent 的历史不是一个新名词突然出现的历史，而是一条人工智能主线的重新汇合：符号主义给了它规则和规划，控制论给了它反馈闭环，强化学习给了它环境交互，自动化工程给了它执行基础，LLM 给了它通用语言认知。
LLM Agent 之所以成立，是因为大模型第一次让“自然语言目标 -> 任务分解 -> 工具调用 -> 反馈修正”这条链路具备了足够通用的认知能力。
但 Agent 的价值不在于表现得无所不能，而在于在清晰边界内可靠地推进任务。一个真正可用的 Agent，必须同时拥有目标感、行动力、验证能力和自我约束能力。
如果用一句话总结：
Agent 不是会调用工具的模型，而是以目标为中心、以反馈为驱动、以工具为手段、以边界为前提的智能执行系统。
参考与延伸
- 点赞
- 收藏
- 关注作者
评论（0）