本文迁移自 mindcarver/91ai · 原始位置 docs/agent/ai-app-tutorials/agent-workflow/agent-fundamentals.md · 由 @阿新聊ai 整理。

Agent 基础认知

TL;DR: Agent 是围绕目标自主运行的 AI 执行系统。2025 年行业共识已从"一切皆 Agent"转向"能简单就简单"——先试 Workflow，只有当路径确实无法提前确定时才上 Agent。理解 Agent 的关键是七个核心组件（目标、状态、上下文、工具、规划器、执行器、评估器）和它的执行循环。

Agent 的定义

Agent 是一个围绕目标运行的 AI 执行系统。它读取当前状态，判断下一步动作，调用工具改变外部世界，根据结果继续调整，直到目标完成、失败或被人工终止。

四个关键词拆开看：

目标。 Agent 不是回答一句话，而是完成一件事。"生成一份行业分析报告"、"修复一个测试失败"、"帮用户完成一次资料收集"——没有目标，就只是对话；有了目标，系统才需要规划、执行和检查。

状态。 Agent 必须知道自己做到哪里了。已经试过什么、哪些信息可靠、哪些任务还没完成。没有状态，它每一步都像重新开始——反复问同一个问题、重复调用同一个工具、忘记前面的限制条件。

动作。 Agent 的价值不只在"想"，而在"做"。搜索网页、读写文件、查询数据库、生成报告、发起审批——只要动作会影响外部系统，就必须考虑权限、审计和回滚。

反馈。 动作执行后要观察结果：工具有没有成功？结果是否推进了目标？有没有新问题？结果不对就换策略，不要机械重复。

Agent 不是"聊天机器人 + 工具"

很多人第一次看到 Agent，会觉得它就是 Chatbot 加上 Function Calling。这个理解漏掉了最关键的一层：自主决策循环。

Chatbot 模式：用户问一句 → 模型答一句 → 下一步由用户决定。

Agent 模式：用户给一个目标 → 系统自己拆任务 → 自己选择工具 → 检查执行结果 → 决定继续、重试、换路或停止。

判断一个系统是不是 Agent 的简单标准：如果用户不继续输入，它还能不能朝目标前进？

Agent 与 Workflow 的区别

2025 年最重要的共识转变来自 Anthropic 的"Building Effective Agents"：不再是二元对立的"Agent vs Workflow"，而是一个复杂性光谱。

Workflow： 代码预定义路径，LLM 在固定节点被调用。确定性执行，可预测、可调试。 Agent： LLM 自主决定执行路径，动态选择工具和行动步骤。

核心区别不在技术实现，在路径由谁决定：

• Workflow：设计时决定流程，运行时执行流程
• Agent：设计时定义目标和边界，运行时决定路径

Anthropic 定义了五种 Workflow 模式，从简单到复杂：

决策框架（从简单到复杂）：

1. 单次 prompt 能解决？→ 直接调用 LLM
2. 有明确顺序步骤？→ Prompt Chaining
3. 不同输入需要不同处理？→ Routing
4. 子任务可以并行？→ Parallelization
5. 复杂但子任务可预测？→ Orchestrator-Workers
6. 输出需要迭代优化？→ Evaluator-Optimizer
7. 开放式、路径无法预知？→ 完整自主 Agent

实践中最常见的做法：Workflow 管大流程，Agent 处理局部不确定性。

比如"企业 AI 诊断"系统，主流程固定（企业背景收集 → 业务流程梳理 → 岗位任务拆解 → AI 机会识别 → 风险审查 → 报告生成），但"岗位任务拆解"内部用 Agent，因为不同行业差异大，需要动态判断。

Agent 的七个核心组件

一个完整 Agent 可以拆成七个组件。理解这些比记住一个框架名字更有用。

Goal → State → Context → Planner → Executor → Tools → Evaluator
 目标    状态    上下文    规划器     执行器    工具     评估器

Goal（目标）——Agent 要完成的事。目标必须能被检查。"写一份报告"太泛，"生成一份包含行业结构、关键岗位、AI 场景、风险清单的 3000 字报告"更可执行。

State（状态）——当前任务的运行记录：已完成步骤、已获得信息、失败记录、待办事项、当前假设。State 不是聊天历史的堆积，而是 Agent 的工作台。

Context（上下文）——本次模型调用真正需要看到的信息。State 可以很大，但 Context 应该经过筛选。2025 年的术语叫 Context Engineering：设计哪些信息进入上下文、以什么格式、什么顺序。这比 Prompt Engineering 更根本。

Tools（工具）——Agent 改变外部世界的能力。工具越强，Agent 能力越强，风险也越高。Anthropic 把工具接口的设计称为 ACI（Agent-Computer Interface），强调要像设计人机界面一样设计工具接口。

Planner（规划器）——决定下一步做什么。可以是模型、规则或混合。简单任务不需要复杂规划；复杂任务通常需要阶段性计划和动态重规划。

Executor（执行器）——把计划变成动作。处理工具参数、调用结果、错误重试、超时、权限限制。很多 Agent 不稳定，不是模型不会想，而是 Executor 太脆弱。

Evaluator / Reflection（评估器）——判断结果是否有效：动作是否成功？成功是否推进了目标？没推进该修正、换工具、回退还是交给人？

Agent 的执行循环

┌─────────────────────────────────────────────┐
│  读取目标和当前状态                           │
│         ↓                                    │
│  选择下一步动作                               │
│         ↓                                    │
│  调用工具或生成中间结果                        │
│         ↓                                    │
│  观察执行反馈                                 │
│         ↓                                    │
│  更新状态                                     │
│         ↓                                    │
│  判断是否完成 ── 否 → 回到"选择下一步动作"     │
│         │                                    │
│        是                                    │
│         ↓                                    │
│  输出结果                                     │
└─────────────────────────────────────────────┘

每一步都有工程难点：

读取状态时，避免上下文过载。模型不需要全部历史，只需要目标、当前进度、关键约束、最近失败和必要证据。

选择动作时，避免"看起来很努力但没有推进"。连续搜索十次只是换关键词、没形成新结论——这不是探索，是循环。

执行动作时，把工具失败当正常情况。网络超时、API 限流、文件不存在——可靠 Agent 必须能处理这些，而不是把错误文本直接喂给模型。

观察反馈时，区分"工具成功"和"任务推进"。搜索返回 10 条结果只说明工具成功，不说明信息足够；测试跑完只说明命令完成，不说明功能正确。

判断完成时，要有验收标准。没有验收标准，Agent 容易在"差不多了"的地方停止，或陷入"还可以优化"的无底洞。

三种主流执行模式

实测数据：Plan-and-Execute 在复杂多步任务上达到 92% 完成率，比纯 ReAct 快 3.6 倍。

当前最佳实践是 ReAct + Plan 混合：规划器给全局结构，ReAct 处理每个步骤内的局部决策。

Agent 的能力边界

适合 Agent 的任务：

• 目标明确，但路径不确定
• 中间结果可以被检查
• 工具调用风险可控
• 允许多步探索和修正
• 失败后可以回退或人工接管

不适合 Agent 的任务：

• 目标含糊，连人也不知道要什么
• 一步错误造成不可逆损失
• 涉及付款、删除、外发、权限变更等高风险动作（除非有审批）
• 需要强合规审计但系统没有日志
• 输出正确性无法验证

三问判断法：

1. Agent 做错了，能不能发现？
2. 发现了，能不能恢复？
3. 不能恢复，是否有人工审批？

三问中任何一个答案是否定的，就不要让 Agent 自动执行到最后。

常见失败模式

Agent 的失败往往不是突然发生，而是在循环中被逐步放大。

一个成熟 Agent 的最低标准

放进真实业务系统的 Agent 至少满足：

• 目标清晰：任务边界和验收标准明确
• 状态可见：能看到做到哪一步、为什么这么做
• 工具受控：每个工具有权限、参数校验和错误处理
• 成本有限：有步数、时间、Token、API 调用上限
• 结果可验：关键事实有来源，关键动作有日志
• 人可接管：高风险节点可以暂停、审批、终止、重试

主流框架（2025-2026）

选型原则： 基于场景选框架，不是基于热度。能用 Workflow 就不要上 Agent，能用单 Agent 就不要上 Multi-Agent。

延伸阅读

• Anthropic: Building Effective Agents — 定义了五种 Workflow 模式和 Agentic Systems 光谱
• OpenAI: Agents SDK Documentation — 三大原语（Agents/Handoffs/Guardrails）
• LangGraph: v1 Release — 生产级持久化执行
• Galileo: 7 Agent Failure Modes — MAST 失败分类法
• Letta: Agent Memory Architecture — 四层记忆模型